Oracle 5.0 Reference Manual page 721

containing at least
key_cache_division_limit
a parameter that can be set per cache.
When an index block is read from a table into the key cache, it is placed at the end of the warm sublist.
After a certain number of hits (accesses of the block), it is promoted to the hot sublist. At present, the
number of hits required to promote a block (3) is the same for all index blocks.
A block promoted into the hot sublist is placed at the end of the list. The block then circulates within
this sublist. If the block stays at the beginning of the sublist for a long enough time, it is demoted to
the warm sublist. This time is determined by the value of the
component of the key cache.
The threshold value prescribes that, for a key cache containing
the hot sublist not accessed within the last
moved to the beginning of the warm sublist. It then becomes the first candidate for eviction, because
blocks for replacement always are taken from the beginning of the warm sublist.
The midpoint insertion strategy enables you to keep more-valued blocks always in the cache. If you
prefer to use the plain LRU strategy, leave the
default of 100.
The midpoint insertion strategy helps to improve performance when execution of a query that
requires an index scan effectively pushes out of the cache all the index blocks corresponding to
valuable high-level B-tree nodes. To avoid this, you must use a midpoint insertion strategy with the
key_cache_division_limit
are preserved in the hot sublist during an index scan operation as well.
8.6.1.4. Index Preloading
If there are enough blocks in a key cache to hold blocks of an entire index, or at least the blocks
corresponding to its nonleaf nodes, it makes sense to preload the key cache with index blocks before
starting to use it. Preloading enables you to put the table index blocks into a key cache buffer in the
most efficient way: by reading the index blocks from disk sequentially.
Without preloading, the blocks are still placed into the key cache as needed by queries. Although the
blocks will stay in the cache, because there are enough buffers for all of them, they are fetched from
disk in random order, and not sequentially.
To preload an index into a cache, use the
following statement preloads nodes (index blocks) of indexes of the tables
mysql> LOAD INDEX INTO CACHE t1, t2 IGNORE LEAVES;
+---------+--------------+----------+----------+
| Table | Op
+---------+--------------+----------+----------+
| test.t1 | preload_keys | status
| test.t2 | preload_keys | status
+---------+--------------+----------+----------+
The
IGNORE LEAVES
Thus, the statement shown preloads all index blocks from t1, but only blocks for the nonleaf nodes
from t2.
If an index has been assigned to a key cache using a
index blocks into that cache. Otherwise, the index is loaded into the default key cache.
8.6.1.5. Key Cache Block Size
It is possible to specify the size of the block buffers for an individual key cache using the
key_cache_block_size
index files.
The
MyISAM
key_cache_division_limit
[460] is a component of structured key cache variables, so its value is
[460] set to much less than 100. Then valuable frequently hit nodes
| Msg_type | Msg_text |
| OK
| OK
modifier causes only blocks for the nonleaf nodes of the index to be preloaded.
[460] variable. This permits tuning of the performance of I/O operations for
Key Cache
[460] percent of the key cache blocks.
key_cache_age_threshold
N
N * key_cache_age_threshold / 100
key_cache_division_limit
LOAD INDEX INTO CACHE
|
|
CACHE INDEX
701
blocks, the block at the beginning of
hits is to be
[460] value set to its
statement. For example, the
and t2:
t1
statement, preloading places
[459]