INTERSECT 不能替代 INNER JOIN，因二者本质不同：前者是要求列数、类型、顺序严格一致的集合运算符，后者是基于ON条件的连接操作；MySQL至今不支持INTERSECT，且NULL处理逻辑也存在关键差异。
INTERSECT 不能替代 INNER JOIN，强行替换会导致语义错误、语法报错或结果偏差。 它俩根本不是同一类操作：INTERSECT 是集合运算符，比对的是「整行内容是否完全一致」；INNER JOIN 是连接操作，靠 ON 条件按指定列做逻辑关联。混用或互换，基本等于拿扳手当螺丝刀使——看起来都在“找共同点”，但发力方式和适用边界完全不同。
INTERSECT 的语法和前提条件很硬性
它要求左右两个 SELECT 语句返回的列数、数据类型、顺序必须严格一致。比如：
SELECT id, name FROM users INTERSECT SELECT user_id, full_name FROM profiles
这条语句会直接失败——id vs user_id 名字不同没关系，但类型不匹配（比如一个是 INT，另一个是 VARCHAR）或列数不等（左边2列，右边3列），SQL 解析器会在语法检查阶段就报错，不会等到执行。
常见错误现象包括：
-
Incorrect syntax near 'INTERSECT'（SQL Server） -
You have an error in your SQL syntax（MySQL，因为根本不支持INTERSECT） - PostgreSQL 报
UNION/INTERSECT/EXCEPT requires compatible types
INNER JOIN 能灵活处理字段不对齐，INTERSECT 不行
假设你有订单表 orders（含 customer_id）和客户表 customers（含 id, email），想找出“下过单且邮箱已验证”的客户。用 INNER JOIN 很自然：
SELECT c.id, c.email FROM customers c INNER JOIN orders o ON o.customer_id = c.id WHERE c.verified = 1
而换成 INTERSECT 就得先让两边 SELECT 的列结构强行对齐，比如：
SELECT id, email FROM customers WHERE verified = 1 INTERSECT SELECT customer_id, CAST(NULL AS VARCHAR) FROM orders
这已经不是“替代”，而是绕路制造麻烦：第二列类型硬转、语义丢失（email 和 NULL 比什么？）、可读性归零。更关键的是，INTERSECT 会把 email 和 NULL 当作同一列比对，结果必然为空。
MySQL 用户注意：INTERSECT 根本不存在
截至 2026 年，MySQL 所有版本（包括 8.0.33+）仍不支持 INTERSECT。任何尝试都会触发解析错误，不是运行时报错，而是压根无法提交。你看到的“教程示例”大概率跑在 PostgreSQL 或 SQL Server 上。
等价实现只能靠其他方式，优先级建议如下：
- 结构一致、需去重 → 用
INNER JOIN+DISTINCT - 结构不一致、但有业务主键 → 用
WHERE EXISTS（更安全，对NULL友好） - 需要模拟 INTERSECT 行为（如多列全等）→ 先
JOIN，再用HAVING COUNT(*) = 2类逻辑聚合校验（仅限小数据量）
例如：
SELECT DISTINCT a.* FROM table_a a WHERE EXISTS (SELECT 1 FROM table_b b WHERE b.id = a.id AND b.status = a.status)
NULL 值处理差异是隐蔽雷区
SQL Server 和 PostgreSQL 中，INTERSECT 认为 NULL = NULL 成立，所以两行都含 NULL 会被当作相同行返回；而 INNER JOIN 默认不认为 NULL = NULL，该行直接被过滤掉。这个差异在清洗脏数据或对接外部系统时极易引发结果不一致，但又很难一眼发现。
如果你的表里存在允许为 NULL 的关联字段（比如 phone），又依赖交集逻辑做去重或校验，必须显式判断：
- 用
INTERSECT：它自动包含NULL匹配，无需额外处理 - 用
INNER JOIN：得写成ON (a.phone = b.phone) OR (a.phone IS NULL AND b.phone IS NULL)
少写这一段，线上核对数据时可能多出几百条“失踪记录”。
