Оптимальные временные таблицы MySQL (таблицы памяти)?

Question

Прежде всего, я новичок в оптимизации mysql. Дело в том, что у меня в моем веб-приложении (около 400 запросов в секунду), запрос, который использует GROUP BY, которого я не могу избежать, и это является причиной создания временных таблиц. Моя конфигурация была:

max_heap_table_size = 16M 
tmp_table_size = 32M 

Результат: временную таблицу на диск процентов + - 12,5%

Затем я изменил настройки, в соответствии с this post

max_heap_table_size = 128M 
tmp_table_size = 128M 

Результат: Темп таблицы на диск % + - 18%

Результаты не ожидались, не понимаю почему.

Неправильно tmp_table_size = max_heap_table_size? Не следует увеличивать размер?

Запрос

SELECT images, id 
FROM classifieds_ads 
WHERE parent_category = '1' AND published='1' AND outdated='0' 
GROUP BY aux_order 
ORDER BY date_lastmodified DESC 
LIMIT 0, 100; 

EXPLAIN

| 1 |SIMPLE|classifieds_ads | ref |parent_category, published, combined_parent_oudated_published, oudated | combined_parent_oudated_published | 7 | const,const,const | 67552 | Using where; Using temporary; Using filesort | 

Answer 1

"Использование временного" в EXPLAIN отчет не говорит нам о том, что таблица температура была на диске. Это говорит только о том, что в запросе предполагается создать временную таблицу.

Таблица временных температур останется в памяти, если ее размер меньше, чем tmp_table_size и меньше, чем max_heap_table_size.

Max_heap_table_size - самая большая таблица, которая может находиться в механизме хранения MEMORY, независимо от того, является ли эта таблица временным или нетемпинговой таблицей.

Tmp_table_size - самая большая таблица, которая может быть в памяти, когда она создается автоматически по запросу. Но в любом случае это не может превышать max_heap_table_size. Таким образом, нет никакой пользы для установки tmp_table_size больше, чем max_heap_table_size. Обычно эти две переменные конфигурации имеют одинаковое значение.

Вы можете отслеживать, как были созданы много временных таблиц, и сколько на диске, как это:

mysql> show global status like 'Created%'; 
+-------------------------+-------+ 
| Variable_name   | Value | 
+-------------------------+-------+ 
| Created_tmp_disk_tables | 20 | 
| Created_tmp_files  | 6  | 
| Created_tmp_tables  | 43 | 
+-------------------------+-------+ 

Примечание В этом примере, были созданы 43 временных таблиц, но только 20 из них были на диске.

Когда вы увеличиваете пределы tmp_table_size и max_heap_table_size, вы позволяете создавать большие временные таблицы в памяти.

Вы можете спросить, насколько вам это необходимо сделать? Вам не обязательно нужно сделать его достаточно большим, чтобы каждая отдельная таблица темпов соответствовала памяти. Вы можете захотеть, чтобы 95% ваших временных таблиц соответствовали памяти, и только оставшиеся редкие таблицы выходят на диск. Те последние 5% могут быть очень большими - намного больше, чем объем памяти, который вы хотите использовать для этого.

Так что моя практика заключается в том, чтобы сохранить tmp_table_size и max_heap_table_size консервативно. Затем посмотрите из Created_tmp_disk_tables в Created_tmp_tables, чтобы узнать, выполнила ли я свою задачу: 95% из них остаются в памяти (или независимо от того, какое отношение я хочу видеть).

К сожалению, у MySQL нет хорошего способа рассказать вам, насколько велики таблицы temp. Это будет зависеть от каждого запроса, поэтому переменные состояния не могут показать это, они могут показывать только количество попыток. И EXPLAIN фактически не выполняет запрос, поэтому он не может точно предсказать, сколько данных он будет соответствовать.

Альтернатива Percona Server, которая представляет собой распределение MySQL с улучшениями. Один из них - log extra information in the slow-query log. В дополнительные поля входит размер любых временных таблиц, созданных данным запросом.