(mysql.info) estimating-performance

 
 7.2.2 Estimating Query Performance
 ----------------------------------
 
 In most cases, you can estimate query performance by counting disk
 seeks. For small tables, you can usually find a row in one disk seek
 (because the index is probably cached). For bigger tables, you can
 estimate that, using B-tree indexes, you need this many seeks to find a
 row: `log(ROW_COUNT) / log(INDEX_BLOCK_LENGTH / 3 × 2 / (INDEX_LENGTH +
 DATA_POINTER_LENGTH)) + 1'.
 
 In MySQL, an index block is usually 1,024 bytes and the data pointer is
 usually four bytes. For a 500,000-row table with an index length of
 three bytes (the size of `MEDIUMINT'), the formula indicates
 `log(500,000)/log(1024/3*2/(3+4)) + 1' = `4' seeks.
 
 This index would require storage of about 500,000 × 7 × 3/2 = 5.2MB
 (assuming a typical index buffer fill ratio of 2/3), so you probably
 have much of the index in memory and so need only one or two calls to
 read data to find the row.
 
 For writes, however, you need four seek requests to find where to place
 a new index value and normally two seeks to update the index and write
 the row.
 
 Note that the preceding discussion does not mean that your application
 performance slowly degenerates by log N. As long as everything is
 cached by the OS or the MySQL server, things become only marginally
 slower as the table gets bigger. After the data gets too big to be
 cached, things start to go much slower until your applications are
 bound only by disk seeks (which increase by log N). To avoid this,
 increase the key cache size as the data grows. For `MyISAM' tables, the
 key cache size is controlled by the `key_buffer_size' system variable.
 See  server-parameters.
Info Catalog
(mysql.info) explain
(mysql.info) query-speed
(mysql.info) select-speed
automatically generated byinfo2html