一条普通的SQL脚本,TiDB查询时间很长,mysql查询很快

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:

【TiDB 版本】TiDB v4.0.9 MySQL8.0.14

【问题描述】我们项目发现有一条SQL语句在mysql下查询很快,0秒就能查询出结果,但在tidb数据库集群里面查询很慢,查询一次2000秒还没出来结果,请帮忙看下是什么原因导致的,谢谢

SQL查询语句:
SELECT m.id,message_id AS messageId,send_user_id AS sendFrom,receive_user_id AS sendTo,send_time AS sendTime,receive_time AS receiveTime,content AS message,system_id,customer_id, send_user_name AS sendFromName,receive_user_name AS sendToName, s.system_code, m.customer_id
FROM tbl_message AS m
LEFT JOIN tbl_system AS s ON m.system_id = s.id
WHERE receive_user_id = 131503 AND IFNULL(receive_time,0) = 0
ORDER BY send_time ASC

这是我们TiDB集群查询的结果


查询了2000秒还没出来结果

expain分析的结果

这是mysql查询的结果

我们的数据库脚本已上传腾讯云盘

整个tidb集群状态都工作正常

请帮忙看下是什么原因导致的?查询为什么会非常慢

看 tidb 的执行计划中,表 s 是一个全表扫,然后 stats 的状态是 pseudo,说明统计信息不准,建议 analyze table s 之后再试下。如果还是不行,请参照官网操作,将这两张表的统计信息导出来提交,并先用 hint 强制走 nestloop 的方式绕过。

我们生产环境分别执行了以下sql语句,
analyze table tbl_message;
analyze table tbl_system;

现在explain的查询结果有变化

查询比之前要快很多,但还需要四五十秒才能查询出结果,感觉不正常,

“请参照官网操作”,这个有文档链接吗,

“并先用 hint 强制走 nestloop 的方式绕过”。具体是怎么操作的?sql语句要怎样修改,没看明白

MySQL对于热点数据进行缓存,TiDB每次都是重新计算,没做缓存。尝试重启MySQL,查看是否查询时间也很短

我把mysql服务重新之后再查询,还是0秒

上面有数据库的建表SQL语句,建议在本地运行模拟下试试

能否尝试利用命令行SSH登录到MySQL集群实例和TiDB集群实例,分别执行查询SQL。截图结果集后面显示的时间。我之前遇到过Navicat等工具统计的时间和命令行执行时间相差很多。

我们生产环境和测试服环境现在都是tidb集群,项目从mysql迁移到tidb集群了,mysql只有我本机电脑有,是个单机数据库,tidb集群不管是测试服还是正式服查询上面的sql语句都很慢,这条sql语句也没什么特别之处,数据量也不大,tbl_message记录数3204条,tbl_system记录数11条,会不会是tidb的缺陷呢?tbl_message表有个longtext字段

我等下ssh登录服务器再尝试查询下,再截图贴上来

这是mysql查询的结果

这是tidb集群服务器查询的结果

知道原因了,longtext字段内容太长,下载导致的时间过长

我没太没明白,下载指的是什么呢?有点困惑

数据库服务端到客户端 client,这里指 navicat 的耗时

还有个问题不太明白,什么情况下会导致表的统计信息不准呢

这是导出统计信息时候的预步骤,希望对你有帮助。 SHOW STATS_HEALTHY 命令看下,如果表的健康度在 90 以下,可以通过 analyze table 收集一下统计信息再执行 SQL

刚使用SHOW STATS_HEALTHY 命令查了下,发现还有很多表Healthy是0,这些都要执行analyze table 修复吧

image

对的,每次导出统计信息都注意查看下表的健康状态,具体参看:https://docs.pingcap.com/zh/tidb/stable/statistics#导出统计信息。希望对你有帮

SHOW STATS_HEALTHY 命令,这条命令需要人工经常主动去查看吗?tidb系统能做到自动化健康状态检查与修复吗

可以看一下上个帖子恢复的文档,有自动更新,但是要结合你自己的表数据看看能否达到自动更新的规则条件。