这张表有个特性就是，update的同时，也有查询
我看tidb的方案是update会表会生成快照给查询用 ，每次update都会。
然后查询的时候会扫描所有的快照。才导致的查询慢。
等下次GC回收了之后又会变快。
再“慢SQL”页面，具体看看SQL的执行计划是否变了。
频繁更新，就会导致统计信息不准，执行计划也不稳。可以单独提高这个表的统计信息收集频率。
统计信息 检查一下自动收集策略，是否在某个时间 dml 大量操作导致统计信息触发，导致执行计划问题。另外如果是有分区表，可以把统计信息提前导入然后锁住不收集。执行计划 如果确定是典型海量 update 业务场景的查询，total key 和 process key 命中率低，可以看看要不要开启 IME 配置，提高内存命中率。
查询变的时候执行计划是变了，之后这条执行计划又没了。很奇怪这个是有啥机制控制的
您指的是频繁的update数据的操作会导致执行计划的变更吗
如果是的话，有啥办法可以避免吗
开启 IME有具体的操作指导书么
这个截图看起来就是你有两个执行计划，第二个执行计划应该不太好导致的。
1、可以定期收集统计信息保证统计信息的准确性
2、可以加 bind 来固定执行计划：https://docs.pingcap.com/zh/tidb/stable/sql-plan-management/
这个情况就出现了一次，很奇怪，之后刷新了计划任务就只有一个了
执行计划跳变本身也是低概率事件。。。。或者是不是 sql 给的传参不一样？
比如查 1 天和查 1 年的数据分布肯定是不一样的。
性能问题比较难查
先看执行计划
1 个赞
收集统计信息，固定执行计划看看
1 个赞
怪怪，这么多信息啊，麻了~
是呀，SQL有问题先考虑看看执行计划
1 个赞
SQL有问题先考虑看看执行计划
固定执行计划
这是个很常见的SQL性能问题
执行计划有异常吗