应优先使用 UNION ALL 替代 UNION，除非明确需要去重；各子查询须显式声明列名并确保类型、顺序一致；复杂场景建议用 CTE 拆分逻辑；字段类型不一致时统一转字符串或 DECIMAL；UNION 各子查询独立优化，无法跨块谓词下推。
用 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 就能过滤掉某个子查询”，该走全表扫还是走全表扫。
