union、intersect、except在存储过程中非开箱即用：union要求各子查询列数严格一致、类型兼容且order by仅能置于末尾；mysql至今不支持intersect和5.7及更早版except，跨版本应以left join+is null或not exists替代；嵌套集合运算易致执行计划失效，建议拆为临时表或cte。
UNION、INTERSECT、EXCEPT 在存储过程中不是“开箱即用”的安全操作，必须配合结构约束、版本兼容和执行计划风险一起考虑。
UNION 在存储过程中报错：列数或类型不匹配
存储过程里写 SELECT a, b FROM t1 UNION SELECT x, y, z FROM t2 会直接报 ERROR 1222 (21000): The used SELECT statements have a different number of columns——SQL 引擎只按位置比对，不看别名或语义。
- 所有
UNION/UNION ALL子查询的列数必须严格一致 - 对应位置字段类型尽量相同；若需兼容，用显式转换，比如
CAST(id AS SIGNED)或CONVERT(varchar(50), name) -
ORDER BY只能出现在整个UNION语句末尾，不能写在任一子查询里，否则报语法错误 - 别名（如
SELECT id AS user_id）只影响最终结果集列名，不影响匹配逻辑
EXCEPT 在 MySQL 存储过程中根本不可用
MySQL 5.7 及更早版本不支持 EXCEPT，写进去就是 ERROR 1064 (42000): You have an error in your SQL syntax；即使升级到 8.0+，也要求左右查询字段数、类型、顺序完全一致，且不支持 EXCEPT ALL。
- 跨版本兼容首选替代方案：
LEFT JOIN ... WHERE right_table.key IS NULL或NOT EXISTS - 用
NOT EXISTS时，右表关联字段允许为NULL不影响逻辑正确性；而LEFT JOIN的IS NULL判断对NULL敏感，需确认字段是否可空 - Oracle 用户注意：
EXCEPT对应的是MINUS，不能混用
INTERSECT 不是 MySQL 的选项
MySQL 至今（2026 年）仍不支持 INTERSECT，哪怕 8.0+ 也不行。试图使用会触发语法错误，而非运行时失败。
- 等价实现用
INNER JOIN最直观：两个表主键/业务键能对齐即可 - 若需去重且避免笛卡尔积，优先加
DISTINCT或用WHERE EXISTS子查询 - 例如：
SELECT DISTINCT a.* FROM table_a a WHERE EXISTS (SELECT 1 FROM table_b b WHERE b.id = a.id)
嵌套集合运算导致执行计划失效
在存储过程中连写 (SELECT ... UNION SELECT ...) EXCEPT (SELECT ...) 这类结构，会让 SQL Server 或 PostgreSQL 放弃中间结果统计信息推导，后续 JOIN 或 WHERE 很可能走全表扫描。
- 避免多层嵌套集合运算；拆成临时表（
CREATE TEMPORARY TABLE）或 CTE（WITH）更可控 - MySQL 不支持 CTE 中的集合运算嵌套（如
WITH t AS (SELECT ... UNION SELECT ...) SELECT * FROM t EXCEPT ...），必须分步落地 - 大数据量下，务必在关联字段上建索引，尤其
NOT EXISTS子查询里的WHERE条件列
真正麻烦的不是语法写不对，而是你以为它只是“换个写法”，实际上它牵动列结构、数据库版本、执行路径三重约束。一个 UNION 能跑通，不代表换个环境还能跑；一个 EXCEPT 在本地测试通过，上线就可能因版本差异直接失败。
