MySql - медленная фаза отправки данных

Один из моих запросов в MySQL 5.0.45 работает медленнее в фазе "отправки данных". Запрос представляет собой простой выбор, возвращает около 300 целых идентификационных полей в качестве набора результатов.

mysql> SELECT source_id FROM directions WHERE (destination_id = 10);
+-----------+
| source_id |
+-----------+
|         2 |
|         8 |
...
|      2563 |
+-----------+
341 rows in set (2.13 sec)

Я не сомневаюсь, почему фаза "отправки данных" настолько медленная и что можно сделать, чтобы сделать ее быстрой. Обратите внимание: я выполняю этот запрос в приглашении MySQL на самом сервере, поэтому не ожидаю, что он потратит так много времени на "отправку данных". Любые подсказки?

Если это помогает, у меня есть 3 текстовых поля в этой таблице, но поскольку они не выбраны, я ожидаю, что они не являются причиной этой медлительности.

Этот запрос выполняется тысячи раз в день и не может позволить себе тратить на него 2 секунды каждый раз.

Результат профилирования:

mysql> show profile for query 4;
+--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| (initialization)               | 0.000003 |
| checking query cache for query | 0.000051 |
| checking permissions           | 0.000007 |
| Opening tables                 | 0.000011 |
| System lock                    | 0.000005 |
| Table lock                     | 0.000023 |
| init                           | 0.00002  |
| optimizing                     | 0.00001  |
| statistics                     | 0.00006  |
| preparing                      | 0.000014 |
| executing                      | 0.000005 |
| Sending data                   | 2.127019 |
| end                            | 0.000015 |
| query end                      | 0.000004 |
| storing result in query cache  | 0.000039 |
| freeing items                  | 0.000011 |
| closing tables                 | 0.000007 |
| logging slow query             | 0.000047 |
+--------------------------------+----------+
18 rows in set (0.00 sec)

ОБНОВЛЕНИЕ: я наткнулся на следующий URL, который говорит

Each time means the time elapsed between the previous event and the new event. So, the line:
| Sending data | 0.00016800 |
means that 0.00016800 seconds elapsed between "executing" and "Sending data". It is, it takes 0.00016800 seconds to execute the query.

http://forums.mysql.com/read.php?24,241461,242012#msg-242012

Может кто-нибудь подтвердить?

Ответ 1

План объяснения обычно является лучшим местом для начала, когда у вас медленный запрос. Чтобы получить один, запустите

DESCRIBE SELECT source_id FROM directions WHERE (destination_id = 10);

Это покажет вам таблицу с описанием шагов, необходимых для выполнения вашего запроса. Если вы видите большое значение в столбце "rows" и NULL в столбце "key", это означает, что ваш запрос должен проверять большое количество строк, чтобы определить, какие из них будут возвращены.

В этом случае добавление индекса в destination_id должно значительно ускорить ваш запрос, при некоторой стоимости вставки и удаления скорости (так как индекс также необходимо будет обновить).

Ответ 2

Вероятно, вы можете посмотреть аппаратную часть сервера mysql. Поскольку Mysql doc говорит:

Отправка данных

Поток - это чтение и обработка строк для оператора SELECT и отправка данных клиенту. Поскольку операции, возникающие во время этого состояния, имеют тенденцию выполнять большие объемы доступа к диску (чтение), это часто является самым продолжительным состоянием в течение времени жизни данного запроса.

Итак, если на вашем сервере медленный ввод/вывод на диске из-за огромного файла db/table или отключенного файла tableperfile. Параметр/фрагментация InnoDB/некорректно сконфигурированный процесс сбоя RAID/диска запущен (дождитесь скорого окончания диска)/любая другая причина диска Медленность ввода-вывода - это может быть причина для значительно увеличенного шага "Отправка данных", поскольку на этом этапе сервер собирает все запрошенные данные с диска и отправляет их клиенту.

Конечно, вы должны попытаться оптимизировать выбор, чтобы сначала использовать индексы и убедиться, что это не проблема программирования, так как в большинстве случаев это влияет на это время этапа.

Ответ 3

У меня была такая же проблема: Отправить Данные были очень медленными, но у меня были правильные индексы и т.д.

После многократного поиска я обнаружил, что мой join сравнивал два поля, которые были проиндексированы, но имел различную сортировку - один был latin1_swedish_ci, а другой был uft8_general_ci.

Как только я отправил их оба в utf8, запрос был значительно быстрее (от 2,7 секунды до 0,002 секунды).

Ответ 4

У вас есть индексы в этой таблице? Вы сказали, что он возвращает около 300. Но сколько нужно искать, чтобы найти эти 300?

Ответ 5

Я испытал это после перехода с MySQL 5.5.x на 5.7.x. Мой запрос с использованием объединений был быстрым на MySQL 5.5 и очень медленным на MySQL 5.7.

Проблема заключалась в том, что MySQL 5.7 выбрал другой набор индексов, чем MySQL 5.5.

Добавление USE INDEX устранило проблему.

Ответ 6

У меня было два индекса (date_index и id),

у меня был WHERE date_index>NOW() - INTERVAL 24 HOURS и ORDER BY id в запросе, MySql предпочел id в качестве индекса и не использовал date_index, что приводило к длительному времени запроса для больших таблиц.

я нашел это в унаследованной системе после 5 лет, что столы были выращены.

Ответ 7

Ваш запрос тратит 2.127019 на выполнить запрос. Вероятно, это потому, что у вас большой объем данных, и у вас отсутствует индекс в столбце destination_id. Попробуйте:

CREATE INDEX index_destination_id НА направлениях (destination_id);

Затем ваш запрос будет работать плавно.