课程名称：课程版本（301）+ 3.7.3 Optimize query health（查询优化器）
学习时长：
10 分钟
课程收获：
掌握查询过程及耗时的构成，能够识别什么样的查询是健康的，通过统计信息快速定位那些查询不健康
课程内容：
不健康的查询怎么识别？
怎么快速定位不健康的查询？
查询不健康的场景
- 数据库的某个节点是热点，性能瓶颈
- 统计信息过期导致执行计划发生变化
- 读写冲突
通过查询延迟来判断Query 是否健康
- 不健康的Query 查询延迟不稳定
- 不健康的Query 查询延迟很高
Query 的执行过程和耗时描述
耗时信息可以通过以下方式获取
- 通过统计信息， statements_summary
- 通过过慢查询， slow_query
statements_summary 说明
- 是一张系统内存表，tidb重启后，数据会丢失
- 会按照Sql digest 和 Plan digest 分组后进行统计
- summary 的数据会被定时清空（默认30分钟），只展示近一段事件内的信息
- summary_history 的结构和summary 结构完全相同，用于保存历史时间段的统计数据，可以排查和对比定位问题
Sql digest
- original SQL
- 实际的Sql 查询
- Noemalized SQL
- 对SQL 进行提取，去掉实际的变量
- Hash of Noemalized SQL
- 对提取后的SQL 执行Hash 操作，获取Hash 码 （指纹信息）
Plan digest 和Sql digest 类似，也是这样的操作来获取最终的指纹信息（digest）
Slow-Query-File
这个文件中有响应的慢查询的信息，有几个关键字需要注意：
- Query_time
- Parse_time
- Compile_time
- Cop_time
- Digest
- Plan
Slow query 格式和mysql 类似
- Slow_query 是 tidb 的系统表
- slow_query 中的内容的来源为 slow-query-file
- 用SQL 查询 Slow_Query 不用再去查询slow-query-file文件
当前单个tidb服务
- statements_summary
- slow_query
tidb集群服务
- cluster_statements_summary
- cluster_slow_query
单个服务和集群服务，采用了不同的统计信息
学习过程中遇到的问题或延伸思考：
- 问题 1：
- 问题 2：
- 延伸思考 1：
- 延伸思考 2：