Производительность MYSQL (большой) UPDATE по сути связана с вводом-выводом: какие уроки следует усвоить?
У меня есть эта довольно большая таблица myISAM (более 95 млн строк), которую нужно обновлять раз в день (более 5 млн строк).
Запрос простой
UPDATE main_table a JOIN updated_values b ON a.id=b.id set a.theCount=b.theCount;
Время выполнять
- SSD RAID 5: 960 с
- ramDisk: 124 с
- Таблицы ПАМЯТИ: 20,1 с
Эти рисунки показывают, что вызов UPDATE связан с вводом-выводом (20 секунд для выполнения, когда данные уже находятся в памяти ...). Однако непонятно, что делать. Таблицы RamDisks и MEMORY требуют записи данных на стабильный носитель. Преобразование таблицы из MEMORY в MyISAM занимает вечность. Таким образом, самым быстрым решением является копирование файлов MyISAM на ramDisk, обновление и копирование обратно в рейд SSD, что занимает менее 20 секунд RT.
Есть ли способ настроить буферы mySQL таким образом, чтобы не было необходимости возиться с ramDisk? (эта система работает на Mac)
«Таким образом, самым быстрым решением является копирование файлов MyISAM на ramDisk, обновление и копирование обратно в рейд SSD, что занимает менее 20 секунд RT». Это вызывает проблемы ... Если вы не можете справиться с временем блокировки таблицы (960 с), запрос UPDATE должен рассмотреть возможность перехода на движок InnoDB ..
1. да, оба идентификатора проиндексированы, иначе как еще 5Mx95M завершится за 20 секунд ?? 2. Блокировка таблицы сама по себе не проблема.
Имеет ли значение изменение условия соединения на a.id=b.id and a.theCount<>b.theCount?
Вы также можете попробовать гибридный подход: поместить таблицу updated_values в таблицу MEMORY, оставив большую на диске.
Не пробовали соединение с дополнительным условием по подсчету. Я сомневаюсь, что произойдут существенные изменения, поскольку большинство, если не все показатели, различаются.
Проиндексированы ли
a.idиb.id? Что говоритEXPLAIN [query].. Вы также пробовали профилировать запрос UPDATE с помощью -> dev.mysql.com/doc/refman/5.7/en/show-profile.html