视图里写ORDER BY会触发全量排序，因数据库优化器通常无法将外层LIMIT下推至含ORDER BY的视图内部，必须先完成全部数据排序再截断；MySQL强制物化含聚合/子查询的视图，PostgreSQL对CTE/LATERAL视图亦难下推，导致内存溢出。
视图里写 ORDER BY 是内存爆炸的常见起点，不是语法错，但会让数据库被迫全量排序再截断。
为什么视图里的 ORDER BY 会触发全量排序？
数据库优化器通常无法把外层的 LIMIT 下推到含 ORDER BY 的视图内部——它得先按视图定义排完所有行，再取前 N 条。尤其在 MySQL 中，如果视图含 GROUP BY 或子查询，还会强制物化成临时表，内存压力翻倍。
- PostgreSQL 12+ 对简单视图支持下推，但一旦视图里有
CTE或LATERAL，下推就失效 - MySQL 5.7+ 能下推
ORDER BY ... LIMIT，但前提是视图定义里没用HAVING、窗口函数或DISTINCT - 执行
EXPLAIN (VERBOSE, ANALYZE) SELECT * FROM my_view LIMIT 10;，如果Plan Rows接近总行数，说明没下推
如何验证排序是否真的走索引？
别信视图名字，要看实际执行路径。重点查 EXPLAIN 输出里的 Extra 列和 Using filesort 标记。
- MySQL：运行
EXPLAIN SELECT * FROM my_view ORDER BY created_at DESC LIMIT 10;，若出现Using filesort，说明created_at没有效索引或索引未被选中 - PostgreSQL：用
EXPLAIN (ANALYZE, BUFFERS)，关注是否有Sort节点且Sort Method: external merge（表示溢出到磁盘） - 字段类型影响索引效果：
VARCHAR(2000)即使建了索引，也可能因长度超限退化为filesort，需配合innodb_large_prefix=ON
怎么改才真正降低内存压力？
核心是把排序控制权从视图里移出来，让调用方决定顺序，并确保底层能走索引。
- 删掉视图定义里的
ORDER BY，改在外层查询加：SELECT * FROM my_view ORDER BY id DESC LIMIT 10; - 给排序字段建覆盖索引，比如
ORDER BY status, created_at就建INDEX(status, created_at) INCLUDE(name, email)（SQL Server）或INDEX(status, created_at, name, email)（MySQL/PG） - 避免用
SELECT *：视图只暴露必要字段，减少 I/O 和临时表体积 - 如果必须固定顺序（如管理后台默认倒序），优先用主键或带索引的字段，而非业务时间戳
真正卡住内存的，往往不是视图本身，而是排序字段没索引 + 视图定义固化了 ORDER BY。删掉那行 ORDER BY 很容易，但得同步补上对应索引，否则只是把问题从内存转移到磁盘 IO 上。
