其他问题
SQL 执行的并发度不足
在 OLAP 场景下，我们需要查询大量数据需要进行聚合统计分析，此时 TiDB 默认的算子并发度会偏保守，需要我们手动调整相应的参数。
-
解决办法
建议以下参数设置 session 级别的，先进行对应语句的测试通过调整对应参数 参考 参数调整
-
参考资料
tidb_allow_batch_cop
tidb_distsql_scan_concurrency
tidb_projection_concurrency
tidb_hash_join_concurrency
tidb_index_join_batch_size
tidb_index_lookup_concurrency
tidb_index_lookup_join_concurrency
聚合函数的优化
在 TP 场景为了提升并发度一般推荐采用 stream agg 算子进行 聚合统计。但在 AP 场景 更适合使用 hash agg 进行多并发的数据统计，可有效提升聚合函数的效率，并且通过加大 hashagg 算子的并发线程数还可以进一步提升效率。
- 解决办法
使用 hash_agg() hint 提示执行计划使用 hashagg 聚合算子。
另外 也可以通过调整参 tidb_hashagg_final_concurrency、tidb_hashagg_partial_concurrency 来提升 hashagg 算子的并发线程数。还可以尝试将聚合算子进一步下推，加速聚合处理操作 相关参数 tidb_opt_agg_push_down、tidb_opt_distinct_agg_push_down
超范围数据的估算错误
在之前的 TiDB 版本，当查询值不在统计信息 bucket 的 最小值与最大值的范围内，就会导致估算的选择率大大超出了预期，尤其在表的数据更新非常少的场景下，这个估算结果的偏差会更加严重
- 解决方法
升级到 3.0.18 或 4.0.5 以后版本的 TiDB具体 PR 可以参考
https://github.com/pingcap/tidb/pull/18821
MVCC 旧版本过多
在日常使用 TiDB 时候为了防止数据误删除，我们会把 GC Life time 设置一个比较长的时间，譬如 24H。由于目前此设置是一个全局设置，在某些表更新非常频繁的情况情况下就会有大量的 MVCC 比较旧的版本存在，如果版本过多会对查询性能有较大影响
-
问题定位
通过查看 slow query 或 statment summary 表中 Processed ed Keys 与 Total Keys 的值 。与 total keys 相比，processed keys 不包含 MVCC 的旧版本。如果 processed keys 和 total keys 相差很大，说明旧版本比较多。 -
解决办法
调整 GC Life Time 到一个比较合理的时间范围，未来有计划根据不同的表设置不同的 GC Life Time