Справочное руководство по MySQL
В большинстве случаев можно оценивать производительность путем подсчета
дисковых операций. Для маленьких таблиц можно обычно принимать 1 строку за
1 операцию дискового поиска (поскольку индекс, скорее всего, в кэше). Для
больших таблиц можно считать, что (при использовании индексов типа B++
деревьев) для нахождения строки потребуется
log(количество_строк) / log(длина_индексного_блока / 3 * 2 /
(длина_индекса + длина_указателя_на_данные)) + 1
дисковая операция для получения строки.
Обычно в MySQL индексный блок занимает 1024 байта, а указательн - 4 байта.
Для таблицы, содержащей 500000 строк и имеющей длину индекса 3 (medium
integer) потребуется log(500,000)/log(1024/3*2/(3+4)) + 1 = 4 дисковых
операции поиска.
Поскольку вышеупомянутый индекс будет занимать приблизительно 500000 * 7 *
3/2 = 5,2Mб (если учитывать, что индексные буфера обычно заполняются на
2/3), большая часть индекса, скорее всего, окажется в памяти, и для того,
чтобы найти строку, потребуется лишь 1-2 обращения к ОС для чтения.
Для записи, однако, потребуется 4 дисковых запроса (таких, какие
рассматривались выше) чтобы найти место для помещения нового индекса, и
обычно 2 дисковых операции, чтобы обновить индекс и вставить строку.
Обратите внимание: сказанное выше не означает, что производительность
приложения будет ухудшаться в log N раз! Поскольку все кэшируется в OС или
на SQL-сервере, замедление работы при увеличении таблицы будет
незначительным. И лишь после того, как данных станет так много, что они
перестанут помещаться в кэш, замедление работы там, где работа приложения
сводится только к операциям дискового поиска (количество которых растет в
log N), станет гораздо ощутимей. Чтобы избежать этого, следует увеличить
индексный кэш так, чтобы он вмещал возросшее количество данных.
See section 5.5.2 Настройка параметров сервера.
