Почему все таблицы MySQL InnoDB фрагментированы?


10

По какой-то причине все таблицы InnoDB на моем сервере MySQL отображаются как фрагментированные, когда я запускаю mysqltuner. Я установил сервер всего несколько часов назад (на OSX Lion), и на нем есть куча свежих данных, импортированных из пакетных файлов.

Я попытался преобразовать все таблицы в одной базе данных в MYISAM, и, конечно же, количество фрагментированных таблиц уменьшилось. Как ни странно, как только я преобразовал эти таблицы обратно в InnoDB, количество фрагментированных таблиц снова увеличилось. Это противоречит моим исследованиям, которые показывают, что бег ALTER TABLE table_name ENGINE=INNODB;должен исправить фрагментацию.

После небольшого поиска в Google я побежал:

SELECT table_schema, table_name, data_free/1024/1024 AS data_free_MB 
FROM information_schema.tables
WHERE engine LIKE 'InnoDB' AND data_free > 0

Который предположительно перечисляет все фрагментированные таблицы (он действительно возвращает то же количество результатов, что и выходные данные mysqltuner для счетчика фрагментированных таблиц). Каждая запись имеет одинаковый номер в data_free_MBстолбце (в настоящее время 7.00000000).

Это на самом деле реальная проблема или что-то делает mysqltuner неправильно? Если это проблема, как я могу это исправить?

РЕДАКТИРОВАТЬ

Я становлюсь все более и более подозрительным, что я идиот и что фрагментация 7 МБ предназначена для всего файла, а не для каждой таблицы. Кто-нибудь может подтвердить, так ли это?


Вы действительно думаете, что 7 бесплатных МБ - это проблема?
— Дэвид Шварц

@DavidSchwartz Не знаю, поэтому я и спросил;) Есть 2314 таблиц, каждая из которых свободна по 7 МБ, и я не знаю, что это значит. Я не уверен, почему mysqltuner покажет мне эту цифру, если она не является потенциальной причиной для беспокойства. Я надеялся, что кто-то здесь сможет рассказать мне, как беспокоятся о том, чтобы получить цифры, и что я могу сделать, чтобы смягчить проблему, так как «стандартные» методы не работают
— Клайв

Миграция этого вопроса согласно запросу пользователя во флаге.
— Даниэль Бек

Большинство деталей, которые показывает mysqltuner, только для информации. Не все это проблема. Если это проблема, это будет ясно сказано. Было ли это указано как проблема?
— Джон Гарденье

@JohnGardeniers Я так считаю, сообщение:, [!!] Total fragmented tables: 2314которое, я уверен, указывает на проблему (с двойными красными восклицательными знаками)
— Клайв

Ответы:


5

Согласно моим комментариям выше, не все выходные данные из sqltuner указывают на ошибки. Если в сценарии очень четко не указано, что это проблема, обычно на следующей строке, за которой следуют предложения по исправлению, то это только информационный элемент.


3

Когда вы включили innodb_file_per_table , все, что вы сделали, это настроили протокол для создания любых новых таблиц InnoDB во внешнем .ibdфайле. Все таблицы InnoDB, которые вы создали до этого, все еще встроены в ibdata1.

При отключенном innodb_file_per_table каждый раз при запуске

ALTER TABLE table_name ENGINE=INNODB;

все, что он делает, это добавляет данные таблицы и индексные страницы в ibdata1. Это сделает таблицу существующей на смежных страницах и удалит фрагментацию. Недостатком является то, что ibdata1 быстро растет.

РЕКОМЕНДАЦИЯ

Вам нужно будет экспортировать все данные, удалить ibdata1, ib_logfile0, ib_logfile1 и перезагрузить.

Я написал как и зачем это делать

ОБНОВЛЕНИЕ 2012-08-15 12:05 ПО ВОСТОЧНОМУ ВРЕМЕНИ

Возможно, вы захотите заглянуть в сам скрипт mysqltuner.pl. ИМХО Я думаю, что он использует старую формулу для измерения фрагментации. Убедитесь, что у вас установлена ​​последняя версия mysqltuner.

Что касается измерения фрагментации таблиц InnoDB, хранимых извне, я написал сообщение об этом еще 11 апреля 2012 г. (см. Обновление внизу от 19 апреля 2012 г.)


1
Аааа ладно, теперь все стало намного понятнее, спасибо. В итоге я экспортировал данные, полностью очистил MySQL, затем переустановил (но добавил innodb_file_per_tableв файл conf перед запуском сервера и повторным импортом). До этого я получал всевозможные ошибки InnoDB (действительно плохие виды ... из-за которых мне приходилось работать innodb_force_recoveryна уровне 6 только для того, чтобы получить данные!), И всякие «дата файла журнала находится в будущее!' ошибки. Похоже, они прекратились, но у меня все еще есть несколько фрагментированных таблиц. Я просто буду следить за этим, еще раз спасибо за ввод
— Клайв

здорово! это очень информативно. Спасибо @RolandoMySQLDBA!
— Судхи
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.