Assume that I create a file like the following:

File1
====
Block1 - max key in block 1 (say 1000 records)
Block2 - max key in block 2 (as above)
....
....
Block10 - max key in block 10 (as above)


1. File1 contains the largest key in an index file for each block (say
a block contains 1000 records).
2. Given a key, I search File1 to determine which block does it
reside.
3. I then retrieve that block of index file to search the exact key I
need (using binary search).
4. The assumption is, if the index is divided into 10 blcok, I can
narrow down to 10% by search File1.

Please comment.

Please note that File1 has only 10 records,

SL Da wrote:
Comment on what? I don't see any question here.

But if this is how you think MySQL should work, I would suggest you
rewrite the code to make it work that way. It's open source, after all.

But it's not going to make any significant difference in your
performance, because that's not your problem.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex (AT) attglobal (DOT) net
==================

For a B+ tree, a program will read (ie disk -read) a block at a time.

A B+ tree of order 1000 will have 3 levels to index 930 million records,
1000^n = 930 000 000, where n = 3 levels.

Thus given a key, it takes 3 disk-reads; after a disk-read, a binary search
can be performed (the time for a search in RAM is negligible compared to a
disk-read).

For a non-B+ tree index, how does it operate in MySQL ?

Thanks.

"Jerry Stuckle" <jstucklex (AT) attglobal (DOT) net> wrote

.... and/or or presumably buy more memory (and let MySQL use it)? Whilst this
wouldn't avoid the 30 disk reads the first time, it would help reduce it for
the next. (I do accept that the effectiveness of this depends on the nature
of the indexs and that we are talking about a lot of RAM to make a
difference.)
--
Brian Cryer
www.cryer.co.uk/brian

On 15 Mrz., 07:51, "sl@my-rialto" <ecp_... (AT) my-rialto (DOT) com> wrote: