MySQL: почему копирование в таблицу tmp происходит быстрее после оптимизации таблицы.

Question

У нас есть таблица с 130 000 записей. Определенный запрос (4 запроса с некоторыми внутренними соединениями и объединениями) занимает 0.13 секунды. Производительность в порядке. Через несколько часов мы видим, что один и тот же запрос занимает 0,4-0,5 секунды.

Мы делаем таблицу оптимизации и вуаля: тот же запрос снова запускается в среднем на 0,13 секунды.

Может быть, стол со многими индексами теряет работоспособность, которая восстанавливается оптимизацией? (Время для обновления, удаления, вставки хорошо, поэтому индексы не так сильно влияют). У нас есть довольно много индексов в этой таблице, потому что мы думали, что индекс для столбца, который используется для внутреннего соединения, требуется для скорости. Это неправильно?

Пример «Выбрать * из внутреннего соединения B на A.column = b.id», мы делаем индекс на A.column.

PS: Во время тестирования, мы отключаем кэш запросов

EDIT: профилирование информации с реквизитами, которые отличаются, по-видимому, после оптимизации таблицы, копирование в TMP таблицы быстрее.

Плохое исполнение: Копирование в таблице Tmp 244 мс Передача данных 40 мкс Оптимизация 44 мкс статистических данных 141 мкс Подготовка 37 мкс Создание Tmp Таблица 45 мкс Выполнение 8 мкс Копирование в ТМП таблице 213 , 6 мс Передача данных 44 мкс Оптимизация 7 мкс Статистика 25 мкс Подготовка 9 мкс Выполнение 6 мкс

Хорошие показатели: Копирование К таблице Tmp 22,1 мс Передача данных 39 мкс Оптимизация 33 мкс Статистика 105 мкс Подготовка 33 мкс Создание TMP Таблица 42 мкс Выполнение 11 мкс Копирование в ТМП таблице 23 , 1 мс Передача данных 60 мкс Оптимизация 11 мкс Статистика 15 мкс Подготовка 15 мкс Выполнение 8 мкс

Answer 1

Мы «s olved»проблема, заставляя все сортировки Etcetera в памяти:

TMPDIR =/DEV/ГИМ

Запрос теперь всегда работать 0,1 секунды. Это стоило нам некоторой ОЗУ, но нам достаточно, чтобы обменять ее на скорость.