Я провел много исследований о том, как поддерживать индексы в MySQL, чтобы предотвратить фрагментацию и каким-то образом оптимизировать выполнение некоторых запросов.
Я знаком с этой формулой, которая вычисляет соотношение между максимальным пространством, доступным для таблицы, и пространством, используемым данными и индексами.
Однако мои основные вопросы до сих пор остаются без ответа. Возможно, это связано с тем, что я знаком с ведением индексов в SQL Server и склонен думать, что в MySQL это должно быть как-то похоже.
В SQL-сервере у вас может быть несколько индексов, и каждый из них может иметь разные уровни фрагментации. Затем вы можете выбрать один и выполнить операцию «REORGANIZE» или «REBUILD» в этом конкретном индексе, не затрагивая остальные.
Насколько я знаю, «фрагментация таблиц» как таковая отсутствует, и SQL Server не предоставляет никаких инструментов для устранения «фрагментации таблиц». Он предоставляет инструменты для проверки фрагментации индекса (понимается как отношение числа страниц, используемых индексом к полноте этой страницы и смежности), а также внутренней и внешней фрагментации.
Все это довольно просто понять, по крайней мере, для меня.
Теперь, когда наступает черед поддерживать индексы в MySQL, существует только концепция «фрагментации таблиц», как упоминалось выше.
Таблица в MySQL может иметь несколько индексов, но когда я проверяю «коэффициент фрагментации» с помощью этой известной формулы, я не вижу фрагментации каждого индекса, а таблицы в целом.
Когда я хочу оптимизировать индексы в MySQL, я не выбираю определенный индекс для работы (как в SQL Server). Вместо этого я делаю операцию «ОПТИМИЗАЦИЯ» во всей таблице, которая предположительно влияет на все индексы.
Когда таблица оптимизирована в MySQL, соотношение между пространством, используемым данными + индексами VS, и общим пространством уменьшается, что предполагает некоторую физическую реорганизацию на жестком диске, что приводит к уменьшению физического пространства. Однако фрагментация индекса связана не только с физическим пространством, но и со структурой дерева, которая со временем изменилась из-за вставок и обновлений.
Наконец, я получил таблицу в InnoDB / MySQL. Эта таблица содержит 3 миллиона записей, 105 столбцов и 55 индексов. Это 1,5 ГБ без учета индексов, которые составляют 2,1 ГБ.
Эта таблица подвергается ударам тысячи раз в день за обновление, вставку (на самом деле мы не удаляем записи).
Эта таблица была создана годами, и я точно знаю, что никто не поддерживает индексы вообще.
Я ожидал найти там огромную фрагментацию, но когда я выполню расчет фрагментации, как это предписано
free_space / (data_length + index_length)
получается, что у меня только 0,2% фрагментации. ИМХО, это совершенно нереально.
Итак, большие вопросы:
- Как проверить фрагментацию определенного индекса в MySQL, а не таблицы в целом
- Исправляет ли OPTIMIZE TABLE внутреннюю / внешнюю фрагментацию индекса, как в SQL Server?
- Когда я оптимизирую таблицу в MySQL, перестраивает ли она все индексы в таблице?
- Реально ли думать, что сокращение физического пространства индекса (без перестройки самого дерева) на самом деле приводит к лучшей производительности?