Почему MySQL создает так много временных таблиц на диске?

Может ли любая ошибка конфигурации привести к созданию слишком большого количества временных таблиц, как показывает mysql..mysql тюнер

Current max_heap_table_size = 200 M
Current tmp_table_size = 200 M
Of 17158 temp tables, 30% were created on disk

table_open_cache = 125 tables
table_definition_cache = 256 tables
You have a total of 97 tables
You have 125 open tables.
Current table_cache hit rate is 3%

Раньше временная таблица была «из 23725 временных таблиц, 38% были созданы на диске», но я изменил max_heap и tmp_table с 200 до 200 метров с 16 до 30%.

Конфигурация:

engine myisam 
group_concat_max_len = 32768
key_buffer_size = 3.7 GB,
thread_stack = 256k,
table_cache = 125
query_cache_limit = 1M
query_cache_size = 16M
join_buffer_size = 2.00 M
max_connections = 800

Другая система с конфигурацией по умолчанию показывает «из 23725 временных таблиц, 1% были созданы на диске» с той же базой данных.

Я попытался изменить значение по умолчанию на машине с этой проблемой, и она по-прежнему показывает «Из 580 временных таблиц 16% были созданы на диске».

Я использую Ubuntu 11.4 64 бит с 48 ГБ оперативной памяти. Кто-нибудь может предложить решение?

Поможет ли это изменить механизм db с «myisam» на «memory» в таблицах с помощью «group by»? Как объяснено здесь: http://www.mysqlperformanceblog.com/2007/08/16/how-much-overhead-is-caused-by-on-disk-teilitary-tables/

mysqltuner редко предоставляет какую-либо полезную информацию. Он использует в основном нерелевантную статистику о «показателях популярности» и устанавливает произвольные ограничения на приемлемое количество виджетов. Если вы не сталкиваетесь с проблемой производительности, вам не нужно решать какие-либо проблемы, которые она вам представляет. Тем не менее, вот небольшая справочная информация о временных таблицах ...

MySQL внутренне использует механизм хранения MEMORY для создания неявных временных таблиц. На дисковых временных таблицах используется механизм хранения MyISAM.

Временные таблицы создаются на диске, когда:

• Присутствуют поля TEXT или BLOB (потому что MEMORY не поддерживает эти типы)
• размер результирующей неявной временной таблицы превышает меньшую tmp_table_sizeилиmax_heap_table_size
• Если столбец с более чем 512 байтами используется с GROUP BY или UNION или ORDER BY

Прочитайте документацию MySQL по внутренним временным таблицам для получения более подробной информации.

Что вы можете сделать по этому поводу? Предполагая, что это на самом деле представляет проблему с производительностью (а не просто беспокоит вас в целом):

• Избегайте полей TEXT / BLOB и, по возможности, используйте поля VARCHAR или CHAR соответствующего размера.
• Если TEXT / BLOB неизбежны, разделите их на отдельные таблицы с отношением внешнего ключа и JOIN только тогда, когда они вам нужны.
• Обрабатывайте большие столбцы размером более 512 байт так же, как и вышеупомянутые поля TEXT / BLOB.
• Убедитесь, что ваши запросы возвращают только тот набор результатов, который вам нужен (соответствующие выборочные предложения WHERE, избегайте SELECT *)
• Избегайте подзапросов и заменяйте их объединениями, особенно если они возвращают большой набор результатов
• В крайнем случае - поднять оба tmp_table_sizeи max_heap_table_size. Не делайте этого, если не обнаружите, что ваши запросы не могут быть оптимизированы.

Если вы беспокоитесь о своей конфигурации MySQL и не можете самостоятельно пользоваться доступными настройками, вы можете обратиться к мастеру настройки Percona в качестве отправной точки.

Поможет ли это изменить механизм db с «myisam» на «memory» в таблицах с помощью «group by»? как объяснено здесь

Нет, не будет и сделает так, чтобы ваши таблицы никогда не сохранялись на диске. Не делай этого.

«использование временных» и «использование файловой сортировки» - это не конец света!

SELECT ... GROUP BY a, b ORDER BY c, d - Требуется 1 или 2 «временных таблицы».

Есть просто времена, когда ваши запросы будут использовать временные таблицы. Временные таблицы могут незначительно замедлить запрос. Но если запрос все еще "достаточно быстр", не беспокойтесь об этом.

Если запрос слишком медленный (с таблицами tmp или без), давайте обсудим это. Пожалуйста, предоставьте SHOW CREATE TABLE, SHOW TABLE STATUS и EXPLAIN.