За последние несколько месяцев мы перенесли несколько таблиц из MYiSAM в InnoDB. Мы теоретически делали это для преимущества блокировки строк, поскольку мы обновляем отдельные строки с помощью нескольких экземпляров веб-скрепок. Теперь у меня есть десятки тысяч медленных запросов, созданных в моем slow_query_log (10). и много полного сканирования таблицы. У меня есть событие очень простых обновлений для одной строки (обновление 4 или 5 столбцов) занимает 28 секунд. (наши входы/выходы и эффективность очень хорошие, а неудачные/прерванные попытки очень низкие < 0,5%)Innodb, кластерные индексы и slow_query_log - повреждены первичным ключом?
Две таблицы, которые мы обновляем, имеют в качестве первичного ключа ID (int 11). В InnoDB первичный ключ является кластеризованным ключом, поэтому записываются на диск, индексированный в порядке идентификатора. НО наши две наиболее важные записи, идентифицирующие столбцы, - BillsofLading и Container (оба varchar22). Большинство наших запросов DML ищут записи на основе этих двух столбцов. У нас также есть индексы на BillsofLading и container. Как я понимаю, InnoDB также использует первичный ключ при создании этих двух вторичных индексов.
Таким образом, я мог бы иметь запись с ID = 1, и BillsofLading = 'г', а другая запись ID = 9 и BillsofLading = 'а'. С индексами InnoDB при обновлении записи на основе SELECT, где BillsofLading = 'a', мне еще не нужно было бы выполнять полную проверку, чтобы найти «a», поскольку индекс основан на ID?
Заранее благодарим за помощь здесь!
Первое, что нужно сделать, это запустить EXPLAIN, чтобы узнать, что такое план выполнения запросов и где используются ресурсы. Используйте GI, например Mysql Workbench или Toad, чтобы запустить объяснение, поскольку они представляют результаты намного лучше. –
@DavidSoussan У меня не было никаких очевидных индикаторов из расширенного EXPLAIN. Интересно, является ли это скорее индикатором обработки приложений, а тем более фактическими операторами DML. – user3242558
SHOW CREATE TABLE - могут быть очевидные вещи. –