本文介绍了在升级到TiDB 3.0后，如何针对OLTP业务中的慢查询问题进行排查和优化。重点分析了SQL查询时间、Coprocessor处理的key数量、等待时间和内存使用等方面，并提供了查看和优化慢查询的方法。
前段时间，我们升级了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 日志中查找事务相关的其他日志
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
