Почему вставки / обновления MySQL InnoDB в больших таблицах очень медленные, когда существует несколько индексов?

Question

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

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

Мои вопросы:

Почему вставки замедляются со временем? Почему воссоздание таблицы и выполнение импорта исправляют это? Есть ли способ перестроить индексы без блокировки таблицы для обновлений?

Answer 1

Производительность InnoDB сильно зависит от оперативной памяти. Если индексы не помещаются в оперативной памяти, производительность может значительно и быстро упасть. Перестройка всей таблицы повышает производительность, поскольку данные и индексы теперь оптимизированы.

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

Answer 2

Звучит так, как будто

• Индекс разбалансирован во времени
• Фрагментация диска
• Фрагментация внутренних файлов данных innodb

Вы можете попробовать analyze table foo, который не берет блокировок, всего несколько индексных погружений и занимает несколько секунд.

Если это не помогает, вы можете использовать

mysql> SET PROFILING=1;
mysql> INSERT INTO foo ($testdata);
mysql> show profile for QUERY 1;

и вы должны увидеть, где большую часть времени проводит.

Очевидно, что innodb работает лучше, когда вставки выполняются в порядке PK, это ваш случай?

Answer 3

отследите использование my.ini и увеличьте key_buffer_size У меня была таблица 1,5 ГБ с большим ключом, где количество запросов в секунду (все записи) уменьшилось до 17. Мне показалось странным, что администрация панель (в то время как таблица была заблокирована для записи для ускорения процесса) выполняла от 200 операций чтения InnoDB в секунду до 24 операций записи в секунду.

Вынужден читать таблицу индекса с диска. Я изменил key_buffer_size с 8M до 128M, и производительность возросла до 150 запросов в секунду, и мне пришлось выполнить только 61 чтение, чтобы получить 240 записей. (после перезагрузки)

Answer 4

Обновление таблицы требует перестроения индексов. Если вы выполняете массовые вставки, попробуйте выполнить их за одну транзакцию (как это делает дамп и восстановление). Если таблица смещена на запись, я бы все равно подумал об отбрасывании индексов или о том, чтобы фоновая работа выполняла обработку чтения таблицы (например, копируя ее в индексированную).

Answer 5

Может ли это быть из-за фрагментации XFS?

Копировать / вставить из http://stevesubuntutweaks.blogspot.com/2010/07/should-you-use-xfs-file-system.html:

Чтобы проверить уровень фрагментации диска, например, расположенного в / dev / sda6:

sudo xfs_db -c frag -r / dev / sda6

Результат будет выглядеть примерно так:

фактический 51270, идеальный 174, коэффициент фрагментации 99,66%

Это реальный результат, который я получил с тех пор, как впервые установил эти утилиты, ранее не имея сведений об обслуживании XFS. Довольно противно. В основном, 174 файла в разделе были распределены по 51270 отдельным частям. Для дефрагментации выполните следующую команду:

sudo xfs_fsr -v / dev / sda6

Дайте ему немного побежать. опция -v позволяет показать прогресс. После его окончания попробуйте снова проверить уровень фрагментации:

sudo xfs_db -c frag -r / dev / sda6

фактическая 176, идеальная 174, коэффициент фрагментации 1,14%

Намного лучше!