(mysql.info.gz) Estimating performance
Info Catalog
(mysql.info.gz) EXPLAIN
(mysql.info.gz) Query Speed
(mysql.info.gz) SELECT speed
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