【 TiDB 使用环境】线上
【 TiDB 版本】
4.0 → 5.3.1
【遇到的问题】
【复现路径】升级后稳定了两三天，然后就会出现内存 3G → 60+G
【问题现象及影响】
tikv出现大量的 scan_table 命令
【核心sql】
uid 数量规模在 100 左右
SELECT xxx FROM `t_user` WHERE `uid` IN (uid1,uid2,..... uid100) LIMIT 1000;
【附件】
Tidb 内存增长图
tidb qps
tikv cmds
请提供各个组件的 version 信息，如 cdc/tikv，可通过执行 cdc version/tikv-server --version 获取。
查下慢SQL（通过dashboard），不行就把资源定为的能力打开（设定好相应的阀值），看看是哪些 SQL 用了 全表扫描
参考这个文档：
https://docs.pingcap.com/zh/tidb/stable/identify-slow-queries
有没有业务上的程序升级？
可以看下 DashBoard
访问 DashBoard：https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/access-dashboard#访问-tidb-dashboard
看下相关慢查询，让开发修改
±-----------------------+
| @@tidb_analyze_version |
±-----------------------+
| 2 |
±-----------------------+
看下执行计划，是不是有变化。升级最容易碰到的问题就是执行计划变化导致的一系列问题。检查下表健康度。
执行计划的确是有变化：
explain SELECT xxx FROM `t_user` WHERE `uid` = 123 LIMIT 1000\G;
id task estRows operator info actRows execution info memory disk
Projection_7 root 1000 d_database.t_user.xxx 2 2 time:601.5ms, loops:2, Concurrency:OFF 3.66 KB N/A
└─IndexLookUp_17 root 1000 limit embedded(offset:0, count:1000) 2 time:601.5ms, loops:2, index_task: {total_time: 584.4ms, fetch_handle: 584.4ms, build: 1.21µs, wait: 2.79µs}, table_task: {total_time: 16.9ms, num: 1, concurrency: 5} 11.7 KB N/A
├─Limit_16 cop[tikv] 1000 offset:0, count:1000 2 time:584.4ms, loops:3, cop_task: {num: 1, max: 584.2ms, proc_keys: 2, rpc_num: 1, rpc_time: 584.2ms, copr_cache_hit_ratio: 0.00}, tikv_task:{time:0s, loops:1}, scan_detail: {total_process_keys: 2, total_process_keys_size: 92, total_keys: 4, rocksdb: {delete_skipped_count: 0, key_skipped_count: 3, block: {cache_hit_count: 10, read_count: 0, read_byte: 0 Bytes}}} N/A N/A
│ └─IndexRangeScan_14 cop[tikv] 1000 table:t_user, index:uid(uid), range:[1595527641,1595527641], keep order:false, stats:pseudo 2 tikv_task:{time:0s, loops:1} N/A N/A
└─TableRowIDScan_15 cop[tikv] 1000 table:t_user, keep order:false, stats:pseudo 2 time:16.8ms, loops:2, cop_task: {num: 2, max: 16.7ms, min: 13ms, avg: 14.9ms, p95: 16.7ms, max_proc_keys: 1, p95_proc_keys: 1, rpc_num: 2, rpc_time: 29.7ms, copr_cache_hit_ratio: 0.00}, tikv_task:{proc max:0s, min:0s, p80:0s, p95:0s, iters:2, tasks:2}, scan_detail: {total_process_keys: 2, total_process_keys_size: 344, total_keys: 2, rocksdb: {delete_skipped_count: 0, key_skipped_count: 0, block: {cache_hit_count: 19, read_count: 0, read_byte: 0 Bytes}}} N/A N/A
*************************** 1. row ***************************
id: Projection_7
estRows: 1.38
task: root
access object:
operator info: d_database.xxx
*************************** 2. row ***************************
id: └─IndexLookUp_17
estRows: 1.38
task: root
access object:
operator info: limit embedded(offset:0, count:1000)
*************************** 3. row ***************************
id: ├─Limit_16(Build)
estRows: 1.38
task: cop[tikv]
access object:
operator info: offset:0, count:1000
*************************** 4. row ***************************
id: │ └─IndexRangeScan_14
estRows: 1.38
task: cop[tikv]
access object: table:t_user, index:uid(uid)
operator info: range:[1595527641,1595527641], keep order:false
*************************** 5. row ***************************
id: └─TableRowIDScan_15(Probe)
estRows: 1.38
task: cop[tikv]
access object: table:t_user
operator info: keep order:false
我看上下执行计划也没太大差别啊。explain analyze看看实际执行的情况呢？
estRows 有明显差别啊，预估行数
哦~实际用的索引和扫描都一样，应该没问题吧。
大佬建议什么排查方向呢
把问题时间段的 tidb 日志看下，看下有没有expensive 的语句。
https://docs.pingcap.com/zh/tidb/v5.3/tidb-configuration-file#mem-quota-query
https://docs.pingcap.com/zh/tidb/v5.3/tidb-configuration-file#oom-action
这俩参数调整下，看看oom-action是不是cancel，不是的话改成cancel，然后看日志，到底是什么sql用了多大内存。
这个没用，改了之后，再上一次，还是OOM
统计信息导致的oom问题不止要改参数，还有把原来v2的统计信息删除了才行，前面回复已经有截图了
如何删除，还有我们升级方式不是直接升级的，是另外一个集群同步过去切换的，不知会不会有影响
貌似可以了，再观察一下，多谢
