版本： 5.4
SQL（简化后）：
explain analyze
select t1.id, t2.id from global_dwb.f_record_progress t1
join global_dwb.f_spot_part_progress t2 on t2.tenant = t1.tenant and t2.org_id = t1.org_id and t2.part_id = t1.part_id and t2.spot_id = t1.spot_id and t2.progress_id = t1.progress_id
数据量：
t1 (f_record_progress) 521万
t2 (f_spot_part_progress) 1156万
使用tiflash引擎跑：
使用tikv引擎跑：
问题：
实际的SQL是出现在update中的，所以只能用到tikv引擎，一跑就OOM了
感觉明显的执行计划不对劲，时间很长而且占用内存非常多
这是什么原因呢？有没有办法解决？
tikv 明显是把数据 都聚合到 tidb 在进行筛选的，
建议先对解决表健康度的问题，然后可以考虑通过索引的方式进行配对，减少回表操作
这个和统计信息相关，统计信息影响执行计划，执行计划会影响效率
参考官网文档
https://docs.pingcap.com/zh/tidb/stable/sql-statement-analyze-table#analyze
通过 SHOW STATS_HEALTHY 可以查看表的统计信息健康度，并粗略估计表上统计信息的准确度。当 modify_count >= row_count 时，健康度为 0；当 modify_count < row_count 时，健康度为 (1 - modify_count / row_count ) * 100。
语法如下：
Copy
SHOW STATS_HEALTHY [ShowLikeOrWhere];
官方文档见以下地址：
https://docs.pingcap.com/zh/tidb/stable/statistics#表的健康度信息
在上个简单表结构，看看索引，主键情况。
表结构涉密的话，show index from tablename;也可以
我改写了一下SQL，用CTE的方式先把t2取到内存中，再去join，看着就比较正常了
所以我认为，原始SQL的执行计划规划的是有bug的
可能是想进行一定程度的优化，但是没做好，反而取了更多次重复的数据，导致oom
explain analyze
with t2 as
(
select tenant, id, org_id, part_id, spot_id, progress_id, design_stat_quantity, design_quantity, design_amount
from global_dwb.f_spot_part_progress
)
select t1.id, t2.id from global_dwb.f_record_progress t1
join t2 on t2.tenant = t1.tenant and t2.org_id = t1.org_id and t2.part_id = t1.part_id
and t2.spot_id = t1.spot_id and t2.progress_id = t1.progress_id
建表时是聚簇表clustered吗？ 怎么全表扫描走了个Index_join。 加上 ```
/*+ HASH_JOIN(t1, t2) */
执行过analyze table 收集2个表的统计信息吗？ 看你的执行计划最初的estRows和actRows差别很大，后面的一致了，如果收集过试试不加hint是否有问题？
用是这么用，可能有些条件下会导致hint也不起作用，建议你还是先收集下统计信息看，健康度高不代表统计信息没问题，健康度只能准确代表数据变化的量
健康度不代表统计信息的准确性，只是说明这个表里从上次收集统计信息有多少行变更了
是用analyze table xxx 吗？有没有其他要注意的？
是的 ，收集期间会消耗较多资源
