用 UNION ALL
代替 UNION
，除非真需要去重
多数业务场景下，多个子查询结果天然不重叠（比如按时间分区、按状态分表），此时用
UNION会触发隐式排序和去重，白白拖慢执行速度。维护时也容易让人误以为“必须去重”，其实只是历史写法惯性。
实操建议：
• 默认写
UNION ALL，并在 SQL 注释里说明“各子集无交集，无需去重”
• 只有明确需要合并后去重时，才用
UNION，并加注释说明去重逻辑依据（例如“订单表与退款表可能含相同 order_id，需 dedup”）
• 避免嵌套多层
UNION，超过 3 个子查询建议拆成临时表或 CTE
列名对齐必须显式写出，禁止依赖 SELECT *
集合查询要求所有
SELECT子句的列数、类型、顺序严格一致。
SELECT *在单表中尚可，在
UNION中等于埋雷：任意一张表加字段或改序，SQL 就报错或返回错列。
实操建议：
• 每个子查询都手写完整列名，哪怕重复（如
id, name, created_at）
• 列别名统一放在第一个子查询，后续子查询只保证顺序和类型一致，不重复写
AS
• 若列来源不同但语义相同（如
user_id和
customer_id），务必用
CAST或
COALESCE对齐类型，避免隐式转换失败
SELECT id, username AS name, created_at FROM users UNION ALL SELECT uid AS id, real_name AS name, add_time AS created_at FROM customers
用 CTE 替代长串 UNION ALL
，尤其当子查询含复杂条件
当集合查询由 4+ 个逻辑块组成，且每个块都有独立
WHERE、
JOIN或聚合时，硬写
UNION ALL会让 SQL 膨胀、缩进混乱、难以定位某一块逻辑。MySQL 8.0+ 支持 CTE，能显著提升可读性与可调试性。
实操建议：
• 每个业务语义块单独定义一个 CTE，命名体现用途（如
recent_orders、
legacy_refunds）
• CTE 内部仍遵守列显式声明原则，不写
*
• 避免在 CTE 中引用外部变量（如存储过程参数），否则迁移或单元测试时易出错
WITH recent_orders AS ( SELECT order_id AS id, 'order' AS source, status, amount FROM orders WHERE created_at > DATE_SUB(NOW(), INTERVAL 30 DAY) ), pending_refunds AS ( SELECT refund_id AS id, 'refund' AS source, 'pending' AS status, -amount AS amount FROM refunds WHERE state = 'init' ) SELECT * FROM recent_orders UNION ALL SELECT * FROM pending_refunds;
字段类型不一致时优先用 CAST(... AS CHAR)
统一为字符串再拼接
集合查询报错 “ERROR 1222 (21000): The used SELECT statements have a different number of columns or incompatible types” 最常见原因不是列数不对，而是某列在不同子查询中被推导为
INT、
DECIMAL、
DATE等不同类型。MySQL 类型兼容规则复杂，强行靠隐式转换容易翻车。
实操建议：
• 对非数值聚合类字段（如状态码、分类标识、ID 字符串化），统一转成
CHAR(32)或
VARCHAR(64)
• 数值类字段若需参与计算，确保全部用
DECIMAL显式声明精度，不用
FLOAT（精度不可控）
• 时间字段统一用
DATE或
DATETIME，避免混用
TIMESTAMP（时区敏感）
最常被忽略的一点：集合查询的执行计划里，
UNION的每个子查询是独立优化的，优化器不会跨子查询做索引选择或谓词下推。所以别指望“主查询加了
WHERE就能过滤掉某个子查询”，该走全表扫还是走全表扫。
