物化视图是唯一真正能提速的方案，它将复杂查询结果物理存储并支持建索引，如PostgreSQL中创建mv_paid_orders并为其字段建索引，配合并发刷新机制，在读远大于写的报表场景下显著提升性能。
视图本身不存储数据，千万级下慢的从来不是“视图”，而是背后查询的执行计划。直接给视图加索引没用，必须从底层查询逻辑和物理结构入手。
物化视图是唯一真正能提速的方案
普通视图每次调用都重跑 SQL，面对千万级表，哪怕只是 SELECT * FROM orders WHERE status = 'paid'，也会触发全表扫描或低效索引查找。物化视图（如 PostgreSQL 的 MATERIALIZED VIEW、Oracle 的物化视图、SQL Server 的索引视图）把结果固化成物理表，并可建索引。
- PostgreSQL 示例：
CREATE MATERIALIZED VIEW mv_paid_orders AS SELECT id, user_id, amount, created_at FROM orders WHERE status = 'paid'; CREATE INDEX ON mv_paid_orders (user_id, created_at); - 刷新策略必须明确：
REFRESH MATERIALIZED VIEW CONCURRENTLY mv_paid_orders;（注意并发刷新需主键或唯一约束） - 缺点很实在：存储翻倍、刷新期间可能 stale、不支持所有 DML 场景；但对读远大于写的报表类场景，这是最直接有效的加速手段
视图里嵌套 ORDER BY + LIMIT 会彻底失效
很多开发者试图在视图定义里写 ORDER BY id LIMIT 100 来“预排序”，这毫无意义——SQL 标准规定视图不保证顺序，且 LIMIT 在视图中会被忽略或导致错误（如 MySQL 报错 ERROR 1356）。更糟的是，它会让优化器误判可下推条件，反而禁用索引。
- 正确做法：排序和分页一律放在视图调用方，例如
SELECT * FROM user_activity_view WHERE tenant_id = 123 ORDER BY event_time DESC LIMIT 20 OFFSET 0; - 如果视图已含复杂 JOIN，务必确认
ORDER BY字段在驱动表上有索引，否则ORDER BY会触发 filesort，千万级时可能耗时数秒甚至分钟 - 特别警惕 MySQL 中视图字段别名与原始列名不一致时，
ORDER BY 别名可能无法利用索引
视图引用字段必须严格对齐底层索引顺序
视图只是语法封装，最终执行仍依赖基表索引。若视图查询条件是 WHERE biz_type = 'login' AND created_at > '2025-01-01'，而基表只有 (created_at, biz_type) 复合索引，那该索引大概率不会被选中——因为索引最左前缀不匹配。
- 检查执行计划：对视图做
EXPLAIN ANALYZE SELECT * FROM my_view WHERE ...，看是否走了预期索引，还是 fallback 到 seq scan - 复合索引字段顺序必须和 WHERE 条件中高选择性字段+范围字段顺序一致，例如高基数
biz_type在前，时间范围created_at在后 → 建(biz_type, created_at) - 避免在视图定义里用函数包装索引字段，比如
WHERE DATE(created_at) = '2025-06-01'会令created_at索引完全失效
别把 UNION ALL 视图当万能解药
为合并多张分表写 CREATE VIEW v_logs AS SELECT * FROM log_202501 UNION ALL SELECT * FROM log_202502 ... 很常见，但千万级下极易踩坑：优化器无法智能裁剪分区，可能全表扫描所有子表；各子表缺失统一索引时，性能雪崩。
- 确保每个子表都有相同结构、相同命名的索引，且 WHERE 条件能明确路由到单个子表（如
WHERE log_date BETWEEN '2025-01-01' AND '2025-01-31'） - MySQL 8.0+ 支持 CHECK CONSTRAINT + 分区裁剪，比手工 UNION ALL 更可靠；PostgreSQL 分区表原生支持自动裁剪
- 如果业务允许，优先用原生分区表替代 UNION ALL 视图，避免视图层额外解析开销
真正影响性能的从来不是“视图”这个词，而是你有没有让每一行扫描都有索引可依、让每一次聚合都有物化可托、让每一个分页都不再依赖 OFFSET。这些事，得在建表和写查询时就定下来，而不是等视图跑慢了再补救。
