tidb5.0
数据表，平时跑一些任务 ，现在没有数据，select * from 表 要5秒多 ，查下原因，最好能提供排查思路，感谢
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
2 个赞
参考这里
2 个赞
这个库中其他表运行都很快，只有这张表空表查询很慢 ，如果mysql 库会考虑是不是碎片的问题 ，tidb 就不知从哪里查起
1 个赞
可以通过analyze table 重新收集一下统计信息，然后再查询试试
1 个赞
空表什么结构？是分区表么？有没有使用PRE_SPLIT_REGIONS？我有张表，做了700多个分区，1W多个region，空表查询10秒多，当然，我不是建着玩，我是还没导数进去。
2 个赞
任务表 ，delete ，insert 这些sql 多一些 ，突然间变的慢了
1 个赞
我试试
1 个赞
那有可能是频繁读写导致热点了吧
1 个赞
如何确认是这个问题 ？
1 个赞
哥，拼写稍有区别： ANALYZE table…
2 个赞
火眼金睛
1 个赞
我正好有个表需要优化，拷贝下来执行没过。。。
1 个赞
trace format=‘row’ select xxx看下
没有数据可以删除或者rename，重新建表
2 个赞
健康情况查看，值为‘0’
这是官方给的建议：
原因
统计信息的收集默认是自动进行的。自动收集需要满足两类条件
新表行数达到 1000，且 1 分钟内没有更新
表的（修改数/当前总行数）大于 tidb_auto_analyze_ratio 默认是 0.5 的时候，并且当前时间在 tidb_auto_analyze_start_time、tidb_auto_analyze_end_time 时间范围内（Time 时间使用的 UTC时间）会自动触发 analyze 语句
当表更新量很大或者表本身很大，还并为达到 auto analyze 的阈值，很有可能导致统计信息不准确的，从而执行优化器制定了错误的执行计划。导致慢语句的产生
问题定位
通过如下命令查询表的健康度，一般如果健康度低于 70%就建议进行手动的统计信息收集。通过如下命令可以快速查看对应表的健康度
SHOW STATS_HEALTHY [ShowLikeOrWhere];
通过如下命令查询表统计信息源数据，当 modify_count >= row_count 时，健康度为 0；当 modify_count < row_count 时，健康度为 (1 - modify_count/row_count) * 100
SHOW STATS_META [ShowLikeOrWhere];
表的基础行数越大，健康度百分比越容易失真，更新频繁的表建议定期进行手动统计信息收集
解决方法
手动收集统计信息
ANALYZE TABLE TableNameList [ WITH NUM BUCKETS TOPN CMSKETCH DEPTH CMSKETCH WIDTH SAMPLES];
为什么健康度低
1、查看了information_schema.slow_query 表记录值，官方的描述是 “如果 processed_keys 和 total_keys 相差很大，说明旧版本比较多”，可能是这个问题引起的
Total_keys: 126468164
Process_keys: 0
2、以下是热点问题的查看，差别不大，不应该是这个问题
整理了表" ANALYZE TABLE 表" ，没效果。。。
以下内容是上图中执行计划信息：
id task estRows operator info actRows execution info memory disk
TableReader_5 root 10000 data:TableFullScan_4 0 time:4.96s, loops:1, cop_task: {num: 321, max: 462.3ms, min: 44.2ms, avg: 224.4ms, p95: 368ms, tot_proc: 1m11.7s, tot_wait: 165ms, rpc_num: 321, rpc_time: 1m12s, copr_cache_hit_ratio: 0.00} 234 Bytes N/A
└─TableFullScan_4 cop[tikv] 10000 table:station_sku_delete_old, keep order:false, stats:pseudo 0 tikv_task:{proc max:461ms, min:43ms, p80:300ms, p95:368ms, iters:321, tasks:321}, scan_detail: {total_process_keys: 0, total_keys: 228254289, rocksdb: {delete_skipped_count: 0, key_skipped_count: 228253968, block: {cache_hit_count: 143295, read_count: 0, read_byte: 0 Bytes}}} N/A N/A
1 个赞
total_process_keys: 0, total_keys: 228254289 ,无数据的表truncate下吧，然后等着GC清理后再试试
1 个赞
统计信息走一波
先truncate，然后再analyze试一下
4 个赞