如何识别缺少索引的慢查询？

Question

使用SET GLOBAL log_slow_verbosity='query_plan,explain'; 在缓慢的日志中，我得到了很多输出，但我很难理解解释。

# 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）列会告诉你。typeALL表示正在使用全表扫描，可能的键/键将是NULL. 那是为了扫描。type const，ref或者range通常是首选（有更多策略）。对于排序（和其他问题），您会在Extra:字符串上找到Using filesort. 这意味着需要对结果进行第二次排序，在某些情况下，索引将有助于自动按顺序获取结果。

这是另一个查询的示例，这次使用索引：

这是一种简化，因为有很多方法可以使用索引来加速结果（ICP、覆盖索引、max()、...）。

这里没有足够的空间来讨论JOINs 和子查询，在那里可以通过排序和重写来获得更好的策略。

我如何识别他们查询的慢部分？

有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 |
  +----------------------+----------+----------+------------+
  

• handler statistics，它将为您提供一个与时间无关的扫描策略度量以及为每个扫描策略扫描的行数：

  

最后一个可能看起来有点不友好，但是一旦你理解了它，通过了解内部引擎调用是什么，你可以很容易地看到索引使用和完整扫描。

有没有快捷方式来快速识别缺失的索引？

是的，如果您已启用performance_schema并有权访问sys数据库，SELECT * FROM sys.statement_analysis;则会为您提供一个名为“ 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 ”。我这样做是为了谋生，查询优化是我的热情，我建议你看看它们（我不是卖给你一本书，它们是免费的并且具有知识共享许可）。