MySQL 8.0+ 默认拦截无条件JOIN，因优化器检测到缺失ON/WHERE关联条件且预估笛卡尔积超阈值（约10⁶）时直接报错ERROR 1248等，该机制独立于SQL_MODE，由optimizer_switch='condition_fanout_filter=on'控制，唯一合法解是补全有效连接条件。
MySQL 8.0+ 默认拒绝无条件 JOIN
MySQL 8.0.19 起，sql_mode 默认包含 STRICT_TRANS_TABLES 和 ONLY_FULL_GROUP_BY，但真正拦截无条件多表 FROM t1, t2 的是 ANSI_QUOTES 之外新增的隐式限制：当优化器检测到 JOIN 或旧式逗号语法中**缺失有效 ON/WHERE 关联条件**，且该查询可能生成超大中间集时，会直接报错 ERROR 1054 (42S22): Unknown column '...' in 'on clause' 或更常见的 ERROR 1248 (42000): Every derived table must have its own alias（尤其在子查询中漏条件时）。这不是标准 SQL 报错，而是 MySQL 为防笛卡尔积主动设的熔断机制。
它不依赖 SQL_MODE 显式开关，而是由优化器在解析阶段做启发式判断：若两张表无任何等值字段引用、无索引可推导关联路径、且行数预估乘积 > 阈值（默认约 10⁶），就拒绝执行。
- 不是所有版本都启用——MySQL 5.7 不拦截，MariaDB 10.6+ 有类似行为但触发逻辑不同
- 报错不一定出现在
ON缺失处，常发生在后续引用了未定义别名或字段的子句里（比如SELECT * FROM a, b WHERE a.id = c.id中误写c） - 用
EXPLAIN FORMAT=TREE可提前看到"join_type": "CARTESIAN"提示，比等报错再排查快得多
为什么 SET SQL_MODE='NO_ENGINE_SUBSTITUTION' 无法绕过笛卡尔积拦截
很多人试过把 sql_mode 改成 '' 或仅留 NO_ENGINE_SUBSTITUTION，发现依然报错。因为笛卡尔积拦截和 SQL_MODE 无关——它是优化器的独立安全策略，受 optimizer_switch 控制，而非语法兼容性开关。
真正起作用的是这个变量：
SET optimizer_switch = 'condition_fanout_filter=off';
但**强烈不建议关闭**。关掉后，查询不会报错，而是直接执行并返回爆炸结果（比如 10 万 × 10 万 = 100 亿行），瞬间打满内存或磁盘临时表空间。
-
condition_fanout_filter=on（默认）：优化器预估连接膨胀率，超阈值就中止 -
join_cache_level=8等参数影响阈值计算，但不改变拦截本质 - 唯一合法绕过方式是补全条件，而不是调参
LEFT JOIN 漏写 ON 后为什么返回左表 × 右表行数
LEFT JOIN t2 没跟 ON 子句，MySQL 会当作语法错误直接拒绝；但若写了 ON 1=1 或 ON t1.id = t1.id，就变成事实上的 CROSS JOIN —— 因为条件恒真，左表每行都匹配右表全部行。
典型症状：
- 结果行数 =
COUNT(*) FROM t1×COUNT(*) FROM t2 -
EXPLAIN显示type: ALL+Extra: Using join buffer (hash) - 加
WHERE t2.status IS NOT NULL也无法收缩结果（因为LEFT JOIN已把右表全填进来了）
修复只需一行：ON t1.foreign_key = t2.primary_key。注意字段必须分别来自左右表，不能只出现一边。
如何快速定位哪一层 JOIN 导致笛卡尔积
多表连接时，问题常藏在第三张、第四张表上。别从头重写 SQL，用分段验证法：
- 先注释掉所有
JOIN，只留FROM t1，确认基础行数 - 逐个放开
JOIN，每次加一个，并在SELECT中加COUNT(*) OVER()或ROW_NUMBER() OVER(PARTITION BY t1.id)观察单主键对应多少行 - 一旦某次加入后，
MAX(ROW_NUMBER())突增至 > 10，说明这层JOIN缺条件或右表无主键约束 - 对疑似表执行
SELECT COUNT(*), COUNT(DISTINCT join_col) FROM t2，若两者差很多，说明join_col不具备函数依赖性，不能单独作连接依据
最易被忽略的点：视图或 CTE 里已含 JOIN，外部再连一次，等于嵌套笛卡尔积。查 INFORMATION_SCHEMA.VIEWS 看定义体是否暗藏多表逻辑。
