union all视图性能退化主因是子查询未约束或中间结果失控；须确保每个子查询独立可优化、过滤条件下推、避免select*、显式类型对齐，并慎用外层order by/limit。
UNION ALL 视图性能退化，几乎从来不是 UNION ALL 本身的问题，而是子查询没被正确约束或中间结果失控。
每个子查询必须独立可优化
视图只是 SQL 定义，数据库不会跨 UNION ALL 子句做全局优化。你写的 (SELECT * FROM t1) UNION ALL (SELECT * FROM t2)，等价于分别执行两个全表扫描再合并——哪怕外层加了 WHERE id = 123，MySQL 8.0 以前甚至不会自动下推这个条件。
- 对每个子查询单独跑
EXPLAIN，确认type是ref或range，而不是ALL - 把过滤条件写进子查询内部：
(SELECT id, name FROM t1 WHERE status = 'active') UNION ALL (SELECT id, name FROM t2 WHERE status = 'pending')，而不是只在外层加WHERE status IN (...) - 避免
SELECT *：尤其要剔除TEXT、JSON、大BLOB字段，它们会强制使用磁盘临时表
ORDER BY 和 LIMIT 必须谨慎嵌套
在视图定义里写 ORDER BY 在 MySQL 中非法；即使允许（如 PostgreSQL），它也只影响视图自身输出顺序，无法加速外部查询。真正危险的是在视图外再套 ORDER BY 或 LIMIT —— 数据库必须先把所有子查询结果物化到临时表，才能排序。
- 如果业务允许分片取数，给每个子查询加
LIMIT 1000，再在外层统一ORDER BY ... LIMIT 10 - 若需按时间排序且数据按月分表，优先用
WHERE create_time >= '2026-08-01'过滤，而非依赖外层排序 - 检查
EXTRA字段是否出现Using temporary; Using filesort，这表示已触发磁盘临时表
类型隐式转换悄悄拖垮执行计划
两个子查询对应列类型不一致时，MySQL 会自动做隐式转换，比如把 VARCHAR(50) 和 VARCHAR(100) 统一转成更宽的类型，导致索引失效或哈希计算开销上升。
- 用
SHOW CREATE VIEW view_name查看各列实际类型，确保完全一致 - 显式转换比依赖隐式更可控：
CAST(col AS CHAR(32))比放任数据库猜要可靠 - 注意末尾空格、大小写、字符集差异（如
utf8mb4_general_civsutf8mb4_0900_as_cs）也会让去重逻辑误判
最常被忽略的一点：视图不缓存、不预编译、不共享执行计划。哪怕结构稳定、高频调用，它每次都是从头解析+重写+执行。真要压高并发，别死磕视图，要么物化成带索引的 summary_union 表，要么在应用层拼接并复用预编译语句。
