(mysql.info.gz) Estimating performance

 
 7.2.2 Estimating Query Performance
 ----------------------------------
 
 In most cases, you can estimate the 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 will 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 1024 bytes and the data pointer is
 usually 4 bytes. For a 500,000-row table with an index length of 3
 bytes (medium integer), 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 will
 probably have much of the index in memory and you will probably need
 only one or two calls to read data to find the row.
 
 For writes, however, you will need four seek requests (as above) to find
 where to place the new index and normally two seeks to update the index
 and write the row.
 
 Note that the preceding discussion doesn't mean that your application
 performance will slowly degenerate by log N!  As long as everything is
 cached by the OS or SQL server, things will become only marginally
 slower as the table gets bigger. After the data gets too big to be
 cached, things will start to go much slower until your applications is
 only bound 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.   Server parameters.
Info Catalog
(mysql.info.gz) EXPLAIN
(mysql.info.gz) Query Speed
(mysql.info.gz) SELECT speed
automatically generated byinfo2html