Сначала я пытаюсь найти медленные запросы среди моих скриптов. И одна из вещей, которые меня беспокоят, это INSERT
запросы, так как у меня есть пара индексов в таблице (насколько я понимаю, вставка не будет мгновенной в этом случае, так как индексы должны пересчитываться каждый раз).
Моя хостинговая компания (siteground) ограничивает мне доступ к журналам MySQL, чтобы исследовать реальную ситуацию с медленными запросами. Поэтому мне нужно искать любой обходной путь, чтобы найти проблемы.
Теперь я просто выполняю подозрительный запрос в phpmyadmin и проверяю, нормально ли время, затраченное на запрос, или нет.
Однако я вижу некоторые слабые стороны этого подхода:
Я получу время выполнения, основываясь на текущей загрузке сервера. Так что, если сервер был занят в то время, я получу завышенное время.
Если запрос был кэширован, я получу заниженное время.
Мне нужно изменить данные БД для реального, чтобы проверить запрос. Это нормально для таких запросов, как SELECT
, но это становится сложно для DELETE
а также UPDATE
,
Так что гораздо лучше использовать другой подход. EXPLAIN
может быть хорошим решением, если:
EXPLAIN
будет работать только для SELECT
запрос на моем сервере БД (у меня есть версия 5.5.32 сервера MySQL, цитата из DOCs: До MySQL 5.6.3 SELECT является единственным объяснимым утверждением). Я мог бы объяснить UPDATE
а также DELETE
от EXPLAIN SELECT
замена (это верно?) но EXPLAIN INSERT
все еще большой вопрос.Итак, вопросы:
Я прав, что INSERT
Можно быть медленным, если есть хотя бы один индекс?
Могу я EXPLAIN UPDATE
а также DELETE
от EXPLAIN SELECT
замена?
Какие подходы можно использовать для исследования скорости запросов в дополнение к упомянутому выполнению phpmyadmin и EXPLAIN?
я использую InnoDB
двигатель.
INSERT
необходимо обновить все индексы для каждой вставленной строки. Однако для одного ряда мы говорим не более миллисекунд.
INSERT ... SELECT ...
можно вставлять произвольное количество строк — проблема может быть либо в SELECT, либо в INSERT.
INSERT ... VALUES (1,2,3), (4,5,6), ...
(«пакетная» вставка) быстрее, чем отдельные вставки, но все же не должна быть большой проблемой.
DELETE
а также UPDATE
может, конечно, касаться сколь угодно большого количества строк, следовательно, быть довольно медленным. Преврати их в SELECT
тогда делай EXPLAIN SELECT ...
и время это.
Для более конкретной помощи, пожалуйста, покажите нам SHOW CREATE TABLE
, скажите нам, сколько у вас оперативной памяти и значение innodb_buffer_pool_size (которое должно составлять около 70% доступной оперативной памяти).
На чем написаны ваши «сценарии»? Положите таймеры вокруг них. Например, в PHP используйте microtime(true)
, В Perl используют Time::HiRes
,
Других решений пока нет …