【TiDB 使用环境】生产环境
【TiDB 版本】v6.5.2
【操作系统】CentOS7.9
【部署方式】虚拟机部署（Vmware）
【集群数据量】1.5TB
【集群节点数】3PD、2TiDB、3TiKV、2Tiflash
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
现象：应用程序发起的SQL执行非常慢，抓取的SQL在mysql客户端执行只需要2-3秒；cluster_processlist中应用发起的执行都需要1-2分钟。TIkv Coprocessor 执行耗时几十分钟；执行计划未使用bind；
使用的统计信息：
cmd_dept:pseudo,mid_incomecostdetails_report:pseudo,bms_way_address:pseudo,bms_receipt_review:pseudo,bms_receipt_review_detail:pseudo,tms_schedulingbill:pseudo,cmd_company:pseudo,tms_operationbill:pseudo,oms_way_legal:pseudo,oms_order_address:pseudo,oms_order_main:pseudo,tms_schedulingbill_detail:pseudo
应用发起执行计划TOP sql.txt (317.8 KB)
mysql客户端执行计划 正常.log (406.0 KB)
影响：SQL执行缓慢，占用大量系统资源，影响其他SQL执行
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】
应用发起的sql的执行计划都是用的过期的统计信息。
而mysql客户端发起的并没有发现这些表的统计信息过期。统计信息更新了？
2 个赞
更新过了。使用analyze talbe 更新统计信息，应用新过来的查询仍然没有改变； SHOW STATS_HEALTHY 显示这些表健康度都是100 。
1 个赞
有猫万事足
4
连接串上是不是设置了什么特别的参数？
mysql客户端连接和应用发起连接，没其他本质区别。
不应该导致看到统计信息都不一致。
1 个赞
Kongdom
(Kongdom)
5
看到pseudo关键字，先执行analyze table 提升表健康度。
1 个赞
连接参数：jdbc:mysql://172.16.89.80:4000/pro_warehouse?serverTimezone=GMT%2B8&characterEncoding=utf-8&allowPublicKeyRetrieval=true&allowMultiQueries=true&rewriteBatchedStatements=true
驱动程序：driver-class-name: com.mysql.cj.jdbc.Driver
有猫万事足
7
1 个赞
看看JDBC里的useServerPrepStmts这个默认值是什么，会不会是预编译导致的?
1 个赞
WalterWj
(王军 - PingCAP)
10
连接到的 tidb-server 是一个节点么？可以考虑滚动重启下应用端，刷一次连接试试。
1 个赞
影响执行计划一般来说就是统计信息。统计信息有会随着索引数据量的变化而变。先确定是否有正确的索引，然后确定索引的统计信息是否正确。如果都正确，使用hit来处理
1 个赞
lllzd
(时光旅行者)
15
因为当前统计信息是pseudo导致执行计划不优，建议先更新统计信息、优化绑定规则与索引设计，并排查网络及资源瓶颈。
1 个赞
手动收集SQL涉及的所有表统计信息，查询表健康度都是100；应用中的该SQL执行统计信息仍然是pseudo。
为啥执行SQL时使用的统计信息不准确呢？
如果在mysql客户端执行是正常的，说明数据库本身没有问题。可以往驱动方向思考，会不会是程序接收数据很慢？返回的数据多不多？可以记录一下从第一条返回，到接收结束一共花多长时间
1 个赞
返回几百条数据，不是网络带宽原因。应用程序执行时TIkv Coprocessor 执行耗时几十分钟。
问题解决了：调试了stats相关参数没有效果，今天重启了TiDB Server服务后，大批量应用查询统计信息为：pseudo的问题消失了。
1 个赞
