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

在慢速日志上使用，我得到了很多输出，但我很难理解其中的解释

# 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查询的性能，那就太好了。

您的问题非常笼统，因此我将回答您的具体问题，然后发送给您，您可以在那里找到更多信息

日志上的解释是可以的，但你不是唯一一个不能阅读它们的人。使用日志识别您的慢速查询。稍后使用

EXPLAIN

和其他工具调试正在发生的事情。很高兴将其记录在日志中，但请在数据库中实时设置格式，如下所示，以提高可读性：

回答您的问题：

如何知道索引是否未被使用？

type

（和

key

）列将告诉您。键入

ALL

表示正在使用完整的表扫描，可能的键/键将为

NULL

。那是扫描用的。通常首选类型

const

，

ref

或

range

（有更多策略）。对于排序（和其他问题），您可以在

Extra:

上找到使用文件排序的字符串

。这意味着需要对结果进行第二次排序，在某些情况下，索引将有助于按顺序自动获取结果

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


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

这里没有足够的空间来讨论
JOIN
s和子查询，在这些查询中，排序和重写可以获得更好的策略

如何识别要查询的慢速部件？

有两种选择：


评测查询（这将为您提供每个查询步骤所花费的每个阶段的时间），可以对某些查询使用或启用查询。典型输出：

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


处理程序统计信息，它将为您提供与时间无关的扫描策略度量以及为每个策略扫描的行数：



最后一个可能看起来有点不友好，但一旦您理解了它，您就可以通过了解内部引擎调用的内容轻松地查看索引使用情况和完整扫描

是否有快捷方式快速识别缺失的索引？

是，如果您已启用
性能\u模式
，并有权访问
sys
数据库
SELECT*FROM sys.statement\u analysis
将为您提供一个名为“
完全扫描
”的列，该列将为您提供执行完全扫描（不使用索引的扫描）的查询。然后，您可以按重要性顺序排列
检查的行数
，
检查的行数(平均)
，
平均延迟
，等等

如果您不想或无法使用performance_schema，请使用日志将这些数字汇总为：


如果检查的行与发送的行相比非常大，则可能是索引造成的

总之，这些日志可以用于识别查询-使用它们将它们与性能模式或pt查询摘要聚合在一起。但一旦确定了最严重的违规查询，请使用其他工具进行调试。

在扩展部分，我将详细介绍如何识别慢速查询，以及如何在幻灯片上进行查询优化。我这样做是为了谋生，查询优化是我的爱好，我建议你看看它们（我不是卖给你一本书，它们是免费的，并且有知识共享许可证）。
“不使用索引的慢速查询”——谁在乎呢？你应该关心的是“慢查询”。然后，在试图找出查询速度慢的原因时，您可能会发现索引问题，也可能不会发现

使用jynus描述的摘要并向我们展示“最差”的查询。为它使用的表提供
SHOW CREATE TABLE
，并
EXPLAIN SELECT…
。然后我们可以遍历它，找出一个索引是否有错误。或者什么是错的

更多关于消化等的信息：

重新播放视频

唉，
EXPLAIN
无法告诉您需要什么索引，甚至无法告诉您哪个表需要更好的索引

演示文字时，请使用文字，而不是视频

“Rows”和“r_Rows”值较高时，表示该表可能缺少良好的索引。请提供
SHOW CREATE TABLE
，以便我们可以查看您已有的索引

如果可能，使用短别名；长的会导致很多混乱。
。要查找的内容、未使用键（
ALL
）的表、使用的索引量（键）<如果有很多行，代码>文件排序（实际上是任何排序）都可能很重要。很棒的开始+1，但查询优化还有很多。。MySQL优化器有时可以重写SQL以进行优化，或者在执行完整扫描时选择不使用索引cheaper@RaymondNijl和我在会上谈到了这一点，我不能在这里总结200多张幻灯片：-DAlso跟踪优化器是为这些优秀资源添加建议的一件事。。如果幻灯片中还没有我没有看的内容，没问题，我没有看切片，事实上，你不能将所有信息都放在这里。虽然这个链接可以回答问题，但最好在这里包含答案的基本部分，并提供链接供参考。如果链接页面发生更改，仅链接的答案可能无效。-@特伦顿·麦金尼——你要我干什么都行。我已经写了大约20篇文章，我反复指出，而不是花时间重复我自己。它们已经出现了十年，我不打算把它们取下来。此外，我还喜欢occas