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

#1

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

【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集群查询的结果

image
image.png902×475 19.2 KB

查询了2000秒还没出来结果

expain分析的结果

image
image.png1519×654 33.4 KB

这是mysql查询的结果

image
image.png1039×617 21 KB

我们的数据库脚本已上传腾讯云盘
https://share.weiyun.com/pcoBjElF

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

image
image.png1227×386 14.3 KB

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

#2

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

#3

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

现在explain的查询结果有变化

image
image.png1179×644 31.5 KB

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

image
image.png1203×654 36.8 KB

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

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

#4

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

#5

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

image
image.png1412×667 22.4 KB

#6

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

#7

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

#8

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

#9

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

#10

这是mysql查询的结果

image
image.png1418×384 20.1 KB

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

image
image.png1425×628 9.59 KB

#11

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

#12

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

#13

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

#14

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

#15

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

#16

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

image

#17

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

#18

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

#19

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