###生产环境的SQL，监控发现执行了286s，存在全表扫的SQL，
###通过explain analyze + SEMI_JOIN_REWRITE 测试后执行2.s，执行计划没有变，
通过对比全表扫表的 tikv_task 发现scan_detail 扫描的键值量大量减少。执行计划中的memory和disk 均相同 ，为N/A。
问题：如何进一步分析这个SQL的性能？通过binding绑定后，在tidb库执行的执行下原SQL 也在8s可以完成。
3 个赞
4分钟的那个全表扫描的表有21亿，2s的那个全表扫描的只有1900w？
2 个赞
-
关注算子耗时 ：查看
explain analyze结果，特别注意各算子的time和loops信息。例如，若某个算子的time过长，可能表示该算子存在性能瓶颈。 -
对比实际行数与估计行数 ：检查
actRows与estRows的差异，若差异较大，可能是统计信息不准确导致优化器选择了不合理的执行计划。 -
分析执行计划中的并行度 ：查看执行计划中是否存在并行执行的算子，如
hash join或scan data线程的并发数。可根据 CPU 资源调整并发参数，以提高执行效率。例如，默认的hash join并发数可能为 4，可尝试调整为 8 或 16。 -
更新统计信息 ：尝试执行
analyze table命令，更新统计信息，让优化器更好地选择执行计划。 -
监控 TiKV 资源使用情况 ：查看 TiKV 的 CPU、内存、磁盘 I/O 等资源使用情况，确保 TiKV 节点没有成为性能瓶颈。
3 个赞
是的，生产的执行计划是从dashboard上复制下来的。整个SQL使用了union ，可以分为3段的，中间TableFullScan_195的部分差异巨大。
等明天确认下统计信息的情况。
2 个赞
更新统计信息，检查执行计划是否真正改变，关注实际扫描行数和索引选择。使用SQL绑定固化优化后计划。
1 个赞
以 EXPLAIN ANALYZE 为核心 ：详细对比慢、快两种情况下的输出，特别是 time 、process_keys 、total_keys 、seek 和 next 等指标，定位到具体是哪个环节变慢了
更新统计信息 ：执行 ANALYZE TABLE 后，在不使用 binding 的情况下重新运行原 SQL，观察性能是否恢复正常。这是最简单且最应该优先尝试的操作
检查 TiKV 状态 ：利用 TiDB Dashboard 和 Grafana，排查是否存在热点、锁等待、Block Cache 命中率低或硬件瓶颈（CPU / 磁盘 I/O）
*执行 explain analyze 后，通过 TiDB Dashboard → SQL 分析 → 查看对应 SQL 的 “执行详情”，获取每个算子的 “扫描行数”“过滤行数”“耗时占比。
关联算子（如 Hash Join ）的驱动表 / 探测表是否提前过滤了数据，是否因半连接重写导致 “驱动表扫描行数大幅减少”
SEMI_JOIN_REWRITE 会优化子查询与主查询的关联逻辑，避免主表全量扫描后再与子查询匹配，而是先通过子查询过滤出有效数据，再与主表关联，从而减少主表的扫描范围。
有没有analyze table
1 个赞
统计分析用tiflash?
1 个赞
1、看看更新统计信息，检查执行计划是否真正改变
2、关注实际扫描行数和索引选择。
3、使用SQL绑定固化优化后计划
1 个赞
附件很有帮助，省去了不少时间。
2 个赞
确实,这个好看多了
有时候索引走不好,可以绑定变量
是啊，绑定变量会好些。
但是绑定变量一般要dba才有权限, 开发一般只能指定索引