【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
【资源配置】
【附件:截图/日志/监控】
想问下这个query_time 的单位是s 还是ms
【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
【资源配置】
【附件:截图/日志/监控】
慢查询日志中所有时间相关字段的单位都是 “秒”
好嘞 谢谢
好嘞 收到 谢谢
还有一个问题,查询出来这个query_time 是sql 执行的时间吗?我把这条SQL 放在数据库explain analyze
中跑了一下发现重新跑的时间和在INFORMATION_SCHEMA.CLUSTER_SLOW_QUERY 表格中查询的query_time 时间不一致
query_time就是sql执行所消耗时间,历史的sql可能跟你当前sql的where条件值不一样,所以时间可能不一致,你执行最新的然后再去CLUSTER_SLOW_QUERY查对应的sql看下时间呢
CLUSTER_SLOW_QUERY 表中的值实际上也是去操作系统层面的慢日志文件中获取的,因此query_time就是慢SQL的执行时间,重新跑的时间不一样可能是执行计划和之前有差异或者系统负载不同等原因。
我的场景:我从CLUSTER_SLOW_QUERYquery_time >1.5S 的SQL 然后看到一条SQL 显示里面筛选出来然后我在数据库里面explain analyze 了一下,发现当时查询的时间是1S 左右 但是现在执行300MS ,用的执行计划也是一样的,是不是可能会有一种情况,当时这条SQL 执行的比较频繁,压力比较大?理论上来说CLUSTER_SLOW_QUERY里面的query_time 应该是和explain analyze 里的时间差不多的? 可以这样理解吗?
是的,比如当时的业务高峰期数据库负载高,或者当时用的条件结果集比较大,如果还是在高峰期看那时间应该是一样的
好的 谢谢