无法选用特定数据库连接算法的场景及适配判断方法咨询

一、你的逻辑计划对应的算法排除判断 #

逐个拆解主流连接算法的硬性使用限制，结合你的逻辑计划（连接列无索引、无预排序节点）来看：

• SMJ（排序合并连接）：必须依赖连接列的有序性——要么表本身有有序索引，要么提前做排序操作。如果你的逻辑计划里既没有排序步骤，连接列也没索引，那SMJ直接用不了，因为数据库没法低成本获取有序的连接列数据。
• INLJ（索引嵌套循环连接）：核心依赖内表连接列的索引，如果内表连接列没建索引，INLJ就失去了存在的意义，会被数据库直接排除。
• NLJ（嵌套循环连接）：理论上没有硬性禁用条件，但如果内表数据量极大，这种逐行匹配的方式性能会差到无法接受，但不是“无法使用”，只是优化器不会优先选择。
• BNLJ（块嵌套循环连接）：是NLJ的优化版，只要内存能放下一批外层数据块就能用，几乎没有绝对禁用的场景，除非数据库本身不支持这个算法。
• Hash Join（哈希连接）：只要求连接列能做哈希计算，且内存能容纳哈希表（就算内存不够，大部分数据库也支持磁盘溢出），只有当连接列是没法哈希的特殊类型，或者是不等值连接时，才会被禁用。

结合你的情况，最可能无法使用的是SMJ，如果内表连接列无索引，INLJ也用不了。

二、快速判断连接算法是否适用的核心依据 #

直接记每个算法的“死穴”即可：

• SMJ：
  • 不能用的情况：连接列无有序索引，且排序成本太高（比如两张超大表，排序的IO开销远大于连接收益）；连接列是无法排序的类型（比如非可比的自定义对象）。
• INLJ：
  • 不能用的情况：内表连接列没有可用索引；内表数据量极大（就算有索引，多次索引查找的开销反而比其他算法高）。
• NLJ：
  • 不适合的情况：内表数据量很大，逐行匹配的时间复杂度O(n*m)会导致性能崩盘。
• BNLJ：
  • 不适合的情况：内存小到连最小的数据块都放不下，退化成NLJ；数据库不支持该算法。
• Hash Join：
  • 不能用的情况：连接列无法做哈希运算；连接是不等值条件（比如>、<=，Hash Join只支持等值连接）；内存极小且数据库不支持磁盘溢出哈希。

内容的提问来源于stack exchange，提问作者Jim