Оптимальная конфигурация временных таблиц (таблиц памяти) MySQL? - PullRequest
6 голосов
/ 09 июля 2010

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

max_heap_table_size = 16M  
tmp_table_size = 32M  

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

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

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 |

1 Ответ

10 голосов
/ 23 февраля 2013

«Использование временного» в отчете 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 не может точно сказать, насколько большими были временные таблицы. Это может варьироваться в зависимости от запроса, поэтому переменные состояния не могут показать это, они могут только показать вам, сколько раз это произошло. И EXPLAIN фактически не выполняет запрос, поэтому он не может точно предсказать, какому количеству данных он будет соответствовать.

Альтернативой является Percona Server , который является дистрибутивом MySQL с улучшениями. Одним из них является регистрация дополнительной информации в журнале медленных запросов . В дополнительные поля включен размер любых временных таблиц, созданных по данному запросу.

...