TiDB 慢查询排查和优化

前段时间，我们升级了TiDB 3.0版本，我日常负责解决数据库慢查询的问题；

众所周知，对于OLAP业务，资源限制一直是让人头痛的问题，有的job过多会影响整体调度系统的性能。而对于OLTP业务，同样存在着类似的卡点，即业务慢查询会对实时数仓的服务能力产生很大影响。

举个例子：在数据聚合接口平台有百余个接口，这些接口实时的去查询数仓ODS层，而ODS层的数据也是实时从业务系统同步的，聚合接口平台作为数据中台对外提供接口服务的载体，它的接口响应时长有很硬性的指标，而接口响应时长9成受数据库查询速度的影响，所以分析SQL查询缓慢的原因是一个很重要的能力；

那么如何在数仓的OLTP业务中，优化存储系统的慢查询问题？

 

关于慢查询的排查：

通常存储系统都会对慢SQL进行记录，如mysql等，对于tidb它存储在这里，需要说明：此表中所有的时间描述单位都是：秒！

show create table slow_query_log.slow_query_history;

注释：

Time：表示日志打印时间
Txn_start_ts：表示事务的开始时间戳，也是事务的唯一 ID，可以用这个值在 TiDB 日志中查找事务相关的其他日志
Query_time：表示执行这个语句花费的时间（重要）
Parse_time：语句解析耗时
Process_time：执行 SQL 在 TiKV 的处理时间之和，因为数据会并行的发到 TiKV 执行，这个值可能会超过 Query_time（重要）
Memory_max：表示执行期间 TiDB 使用的最大内存空间，单位为 byte
User：表示执行语句的用户名
Conn_ID：表示用户的链接 ID，可以用类似 con:3 的关键字在 TiDB 日志中查找该链接相关的其他日志

 

 

需要留意一下几个字段的值，在进行优化时比较重要：

Process_keys：表示 Coprocessor 处理的 key 的数量。相比 total_keys，processed_keys 不包含 MVCC 的旧版本。如果 process_keys 和 total_keys 相差很大，说明旧版本比较多
Process_time：执行 SQL 在 TiKV 的处理时间之和，因为数据会并行的发到 TiKV 执行，这个值可能会超过 Query_time（重要）
Query：表示 SQL 语句。慢日志里面不会打印 Query，但映射到内存表后，对应的字段叫Query
Wait_time：表示这个语句在 TiKV 的等待时间之和，因为 TiKV 的 Coprocessor 线程数是有限的，当所有的 Coprocessor 线程都在工作的时候，请求会排队；当队列中有某些请求耗时很长的时候，后面的请求的等待时间都会增加
Succ：表示语句是否执行成功
Index_ids：表示语句涉及到的索引的 ID

 

扩展字段：这些字段我一般看的比较少

Request_count：表示这个语句发送的 Coprocessor 请求的数量。

Total_keys：表示 Coprocessor 扫过的 key 的数量。

Cop_proc_avg：cop-task 的平均执行时间。

Cop_proc_p90：cop-task 的 P90 分位执行时间。

Cop_proc_max：cop-task 的最大执行时间。

Cop_proc_addr：执行时间最长的 cop-task 所在地址。

Cop_wait_avg：cop-task 的平均等待时间。

Cop_wait_p90：cop-task 的 P90 分位等待时间。

Cop_wait_max：cop-task 的最大等待时间。

Cop_wait_addr：等待时间最长的 cop-task 所在地址。

 

查看此用户近期的前30个慢查询：

 select Time,Query_time,Process_time,Wait_time,Process_keys,Index_names,Query from slow_query_log.slow_query_history where Query_time>5 and user like '%api_platform%' and Time > "2019-12-16" order by Query_time desc limit 30 \G