【 TiDB 使用环境】生产环境
【 TiDB 版本】V6.5.8
【遇到的问题：问题现象及影响】从社区的文档里，对hashjoin和indexjoin进行了初步了解【https://docs.pingcap.com/zh/tidb/stable/explain-joins】，不知道大家对这两类join有过性能对比么？ 场景：关联字段行数10万~几百万，理论上来说hashjoin肯定性能更好【不考虑内存消耗】，但不知道性能到底有多大的差距
1 个赞
你都有数据了，加个 hint explain 比对一下就知道了
2 个赞
我这还没有数据，只是想问问大家是否有这种场景的业务数据，从而知道性能差异
不一定，取决于数据分布、索引情况以及查询条件等
不绝对，场景不同，性能不同
通常来说，当连接操作涉及大量数据时，Hash Join 通常是一个不错的选择，因为它可以充分利用硬件资源来加速处理过程;当连接操作涉及一个大表和一个小表时，Nested Join 通常是一个更好的选择，因为它可以有效地利用索引来减少扫描的数据量。
1 个赞
即使走错，Hash Join通常是一个能接受的结果，Index Join则可能被业务投诉
1 个赞
SQL 优化器需要确定数据表的连接顺序，且要判断对于某条特定的 SQL 语句，哪一种 Join 算法最为高效。
先自行建几张关联表，删索引测试一遍，再加索引测试一遍，具体还要看优化器选择了哪种算法，因集群部署差异而不同
中间数据落盘慢
这种直接测试就行了 直接出结果啊
这个结论还是有道理的，哈哈
两个千万级别的表，hash join的速度比index join的速度快个2倍还是没有问题的
表的数量有关系了
- Hash Join：
- 原理：Hash Join 将连接的两个数据集分别构建哈希表，然后通过哈希值进行匹配，适合处理大数据集的连接操作。
- 优点：对于大数据集的连接效率较高，尤其是在内存充足的情况下，可以减少磁盘 IO 的开销。
- 缺点：如果数据无法完全加载到内存中，可能导致频繁的磁盘读写，影响性能。
- Index Join（Nested Loop Join）：
- 原理：Index Join 通过遍历一个表的索引，并使用索引值在另一个表中查找匹配的行，适合处理小数据集的连接操作。
- 优点：适用于其中一个数据集较小的情况，不需要构建额外的数据结构，可以利用索引快速定位匹配行。
- 缺点：当数据量较大时，Index Join 的性能可能受限于磁盘 IO，每次查找都需要访问磁盘。
在实际应用中，选择何种连接算法取决于数据规模、数据分布、索引设计等因素。一般来说，如果两个连接的数据集都比较大，且内存足够，Hash Join 可能更适合；而如果其中一个数据集较小，且有合适的索引支持，Index Join 可能性能更好。
1 个赞
学习了
1 个赞
等我生成数据进行下测试
过来学习了
有测试结果了分享一下
那必须的，这块我会找关联字段从1万，10万，100万，1000万四个场景压测
关联数据量越大hash join越好