Как определить медленные запросы без индекса?

Question

Использование SET GLOBAL log_slow_verbosity = 'query_plan, объясните'; в медленном журнале я получаю много выходных данных, но я изо всех сил пытаюсь понять объяснение.

# User@Host: root[root] @  [10.0.1.5]
# Thread_id: 31  Schema: enterprise  QC_hit: No
# Query_time: 0.654855  Lock_time: 0.000245  Rows_sent: 50  Rows_examined: 279419
# Rows_affected: 0
# Full_scan: Yes  Full_join: Yes  Tmp_table: Yes  Tmp_table_on_disk: Yes
# Filesort: Yes  Filesort_on_disk: No  Merge_passes: 0  Priority_queue: Yes
#
# explain: id   select_type     table   type    possible_keys   key     key_len ref     rows    r_rows  filtered        r_filtered      Extra
# explain: 1    SIMPLE  external_property_groups_areas  ALL     unique_id_area,search_id_area,search_country    NULL    NULL    NULL    20      20.00   100.00  100.00  Using temporary; Using filesort
# explain: 1    SIMPLE  external_property_level_1_buildings     ref     unique_id_building,building_id_area_id  building_id_area_id     5       enterprise.external_property_groups_areas.id_area        3  6.00     100.00  100.00
# explain: 1    SIMPLE  external_property_level_2_units ref     unit_building_id,property_level_2_created_by    unit_building_id        4       enterprise.external_property_level_1_buildings.id_building  25.13    100.00  100.00  Using index condition
# explain: 1    SIMPLE  ut_unit_types   eq_ref  unique_property_type,query_optimization_designation      unique_property_type     1022    enterprise.external_property_level_2_units.unit_type  1       1.00    100.00  100.00  Using where; Using index
# explain: 1    SIMPLE  property_level_2_units  eq_ref  PRIMARY,property_level_2_organization_id        PRIMARY 1530    enterprise.external_property_level_2_units.external_id,enterprise.external_property_level_2_units.external_system_id,enterprise.external_property_level_2_units.external_table,const   1       0.98    100.00  100.00
# explain: 1    SIMPLE  a       eq_ref  unique_id_unit,unit_building_id unique_id_unit  4       enterprise.property_level_2_units.system_id_unit 1       0.98    100.00  100.00  Using where
# explain: 1    SIMPLE  c       eq_ref  unique_id_building      unique_id_building      4       enterprise.a.building_system_id  1       1.00    100.00  100.00  Using index
# explain: 1    SIMPLE  b       ref     property_property_type  property_property_type  4       const   142     458.00  100.00  0.17    Using where
# explain: 1    SIMPLE  property_groups_countries       ALL     country_names,coutnry_codes     NULL    NULL    NULL    245     245.00  100.00  0.31    Using where; Using join buffer (flat, BNL join)
#

• Как определить медленные части, к которым они запрашивают?
• Есть ли ярлык для быстрой идентификации отсутствующих индексов?

Также есть скринкаст моего сеанса

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

Answer 1

Ваш вопрос довольно общий, поэтому я отвечу на ваши конкретные вопросы, а затем отправлю вам, где вы сможете найти дополнительную информацию.

Объяснения в журналах в порядке, но вы не одиноки в том, что не можете их прочитать. Используйте журналы, чтобы идентифицировать ваши медленные запросы. Используйте EXPLAIN позже (и другие инструменты) для отладки происходящего. Хорошо иметь его в журнале, но, пожалуйста, отформатируйте его вживую в вашей базе данных, чтобы улучшить читабельность:

Отвечая на ваши вопросы:

Как узнать, не используется ли индекс?

type (и key) столбцы скажут вам. тип ALL означает, что используется полное сканирование таблицы, и возможные ключи / клавиши будут NULL. Это для сканирования. тип const, ref или range обычно предпочтительнее (есть больше стратегий). Для сортировки (и других вопросов) вы найдете на Extra: строку Using filesort. Это означает, что необходим второй проход для сортировки результатов, а в некоторых случаях индекс поможет получать результаты автоматически по порядку.

Вот пример другого запроса, на этот раз с использованием индекса:

Это упрощение, поскольку существует множество способов использования индекса для ускорения результатов (ICP, охватывающий индекс, max (), ...).

Здесь недостаточно места, чтобы поговорить также о JOIN s и подзапросах, где порядок и переписывание позволяют получить лучшие стратегии.

Как определить медленные части, к которым они запрашивают?

Есть 2 варианта:

• профилирование запроса (который даст вам время, затрачиваемое на каждый этап запроса), что можно сделать с помощью show profile или включить его с помощью performance_schema для определенных запросов. Типичный выход:

  SHOW PROFILE CPU FOR QUERY 5;
  +----------------------+----------+----------+------------+
  | Status               | Duration | CPU_user | CPU_system |
  +----------------------+----------+----------+------------+
  | starting             | 0.000042 | 0.000000 |   0.000000 |
  | checking permissions | 0.000044 | 0.000000 |   0.000000 |
  | creating table       | 0.244645 | 0.000000 |   0.000000 |
  | After create         | 0.000013 | 0.000000 |   0.000000 |
  | query end            | 0.000003 | 0.000000 |   0.000000 |
  | freeing items        | 0.000016 | 0.000000 |   0.000000 |
  | logging slow query   | 0.000003 | 0.000000 |   0.000000 |
  | cleaning up          | 0.000003 | 0.000000 |   0.000000 |
  +----------------------+----------+----------+------------+
  

• статистика обработчика , которая даст вам независимый от времени показатель стратегии сканирования и количество строк, отсканированных для каждой из них:

  

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

Есть ли ярлык для быстрой идентификации отсутствующих индексов?

Да, если вы включили performance_schema и имеете доступ к базе данных sys, 1080 * предоставит вам столбец с именем "full_scan", который даст вам запросы, которые выполняют полное сканирование (сканирование без использования индексов). , Затем вы можете заказать по rows_examined, rows_examined_avg, avg_latency и т. Д. В порядке важности.

Если вы не хотите или не можете использовать performance_schema, используйте журналы, чтобы получить эти числа, агрегированные с pt-query-digest из percona-toolkit :

Если проверенные строки очень велики по сравнению с отправленными строками, вероятно, причиной является индекс.

Таким образом, журналы подходят для идентификации запросов - используйте их, чтобы объединить их с performance_schema или pt-query-digest. Но как только вы определили худшие запросы, используйте для отладки другие инструменты.

Более подробно я расскажу о том, как идентифицировать медленные запросы, и о том, как оптимизировать запросы на моих слайдах. " Оптимизация запросов с MySQL 8.0 и MariaDB 10.3 " . Я делаю это для жизни, и оптимизация запросов - моя страсть, я предлагаю вам взглянуть на них (я не продаю вам книги, они бесплатные и с лицензией Creative Commons).

Answer 2

"медленные запросы без индекса" - кого это волнует?То, что вы должны заботиться, это "медленные запросы". Затем , пытаясь выяснить, почему запрос медленный, вы можете или не обнаружить проблему с индексом.

Используйте дайджест, описанный jynus, и покажите нам«худший» запрос.Укажите SHOW CREATE TABLE для таблиц, которые он использует, и EXPLAIN SELECT ....Тогда мы можем пройти через это и выяснить, виноват ли индекс.Или что виновато.

Подробнее о переваривании и т. Д .: http://mysql.rjweb.org/doc.php/mysql_analysis#slow_queries_and_slowlog