Как проверить производительность запроса mysql?

Question

Я изучал оптимизацию запросов, увеличивал производительность запросов и все, но в целом, если мы создаем запрос, как мы можем сказать, что это прекрасно или нет.

Я знаю, что мы можем видеть время выполнения ниже (0,01 с). Но это время зависит (один из) от числа строк справа. Я хочу знать, если я делаю запрос MySQL. Это прекрасно или нет.

Я узнал о выполнении предложений и команд. Но есть ли какие-либо вещи, по которым мы можем проверить эффективность запроса. Производительность здесь не является временем выполнения, значит, есть ли запрос «ok» или нет, без зависимости от данных.

Поскольку мы не можем создать столько данных, которые были бы в живой базе данных. Измерение должно быть независимым от данных.

Answer 1

Общая производительность запроса может быть проверена с помощью команды EXPLAIN в MySQL. См. https://dev.mysql.com/doc/refman/5.7/en/using-explain.html

Он показывает вам, как MySQL планирует выполнить запрос и позволяет выполнить некоторые основные проверки работоспособности, то есть, если движок будет использовать ключи и индексы для выполнения запроса, см., Как MySQL будет выполнять объединения (т. Е. Если внешние ключи не пропали) и многие другие.

Вы можете найти некоторые общие советы о том, как использовать EXPLAIN для оптимизации запросов здесь (наряду с некоторыми хорошими образцами): http://www.sitepoint.com/using-explain-to-write-better-mysql-queries/

Answer 2

Как уже упоминалось выше, правильный запрос всегда data-dependent. До какой-то степени вы можете использовать следующие методы, чтобы проверить эффективность

1. Вы можете использовать Explain понять запроса план выполнения и что может помочь вам исправить некоторые товары. Для получения дополнительной информации: См. Документацию Optimizing Queries with EXPLAIN

2. Вы можете использовать Query Analyzer. Refer MySQL Query Analyzer

Answer 3

Я хотел бросить my cookbook на новичков, потому что они часто не понимают, насколько важно INDEXes являются, или не знаю некоторых тонкостей.

При экспериментировании с несколькими выборами запроса/схемы, я хотел бы использовать

FLUSH STATUS; 
SELECT ...; 
SHOW SESSION STATUS LIKE 'Handler%'; 

Это отсчитывает низкие действия уровня, такие как «прочитать следующую запись». Это существенно устраняет проблемы кэширования, скорость диска и т. Д., И очень воспроизводимо. Часто в этом выходе (или нескольких счетчиках) есть счетчик, который соответствует количеству строк в таблице (иногда +/- 1) - это говорит мне, что есть сканирование таблиц. Это обычно не так хорошо, как если бы использовали INDEX. Если запрос имеет значение LIMIT, это значение может отображаться в некоторых обработчиках.

Действительно плохой запрос, такой как CROSS JOIN, будет показывать значение N * M, где N и M - количество строк для двух таблиц.

Я использовал технику Handler, чтобы доказать, что практически все опубликованные методы «получить меня случайной строки» требуют сканирования таблицы.Затем я мог экспериментировать с маленькими столами и обработчиками, чтобы составить список faster random routines.

Еще один совет, когда время ... Отключите Query_cache (или используйте SELECT SQL_NO_CACHE).