视图中ORDER BY未配索引会导致全表扫描和磁盘排序；需用EXPLAIN或STATISTICS XML分析执行计划，确认Sort节点前是否为索引扫描，并为排序字段建立合适索引（含方向与覆盖列）。
视图里用了ORDER BY，但没配索引，查起来就卡
SQL Server 视图中带 ORDER BY 本身不报错，但一旦配合 TOP 或 OFFSET/FETCH（比如 SELECT TOP 100 * FROM v_user_report ORDER BY create_time DESC），优化器容易误估行数，选错执行计划，最终导致全表扫描或排序溢出临时库，超时频发。
根本问题不是“不能排序”，而是排序字段没走索引——数据库得先把所有数据捞出来再排，数据一过百万，Sort 操作直接吃光内存，写入 tempdb，IO 拉满。
- 用
EXPLAIN（PostgreSQL）或SET STATISTICS XML ON（SQL Server）看执行计划，重点找Sort节点的EstimateRows和ActualRows是否严重偏离；如果Sort前面是Clustered Index Scan或Table Scan，基本就是没走索引 -
ORDER BY字段必须单独建索引，或作为复合索引的最左前缀；例如ORDER BY status, create_time DESC，索引得是CREATE INDEX IX_status_ct ON orders (status, create_time DESC)，不能只建create_time单列索引 - SQL Server 中，如果视图定义含
ORDER BY但没加TOP，该ORDER BY实际被忽略；只有显式加了TOP或调用方再套一层ORDER BY才真正触发排序逻辑，这点常被误判
ORDER BY + TOP 组合在 SQL Server 中特别危险
这个组合会让优化器放弃基于统计信息的成本估算，转而按“小结果集”预估，驱动表选错、并行度降为 1、甚至跳过已有的覆盖索引。线上很多“突然变慢”的视图，回滚到上周快照也没用，就是因为统计信息更新后触发了这个退化路径。
- 检查视图定义里是否含类似
SELECT TOP 1000 * FROM ... ORDER BY updated_at DESC的结构；如果有，优先把TOP拿到调用方，视图里只保留基础SELECT - 若必须保留在视图内，确保
ORDER BY字段有索引，且该索引包含查询中所有SELECT列（即覆盖索引），避免回表；例如视图查id, name, updated_at，索引就得是(updated_at DESC) INCLUDE (id, name) - SQL Server 2016+ 可尝试加查询提示
OPTION (USE HINT('ENABLE_PARALLEL_PLAN_PREFERENCE'))强制并行，但只是临时缓解，不能替代索引修复
PostgreSQL 视图排序字段没索引，会更早暴露问题
PostgreSQL 不允许视图定义里直接写 ORDER BY（除非配合 LIMIT），所以常见写法是调用方加 ORDER BY。但只要没索引，执行计划里必然出现 Sort 节点，且 Buffers: shared read=xxx 数值飙升——这是磁盘读放大信号。
- 用
EXPLAIN (ANALYZE, BUFFERS)查看真实 IO 开销，若Sort节点下Buffers明显高于其他节点，说明排序在刷盘 - PostgreSQL 对函数索引敏感，比如
ORDER BY lower(name)，必须建函数索引CREATE INDEX idx_lower_name ON users ((lower(name)))，普通name索引无效 - 注意
COLLATE设置：如果字段是TEXT COLLATE "C"，但排序用的是默认en_US.UTF-8，即使有索引也会失效；需统一 collation 或建对应 collation 索引
最容易被忽略的细节：排序字段类型隐式转换
字段是 VARCHAR(50)，但查询条件或排序传入的是数字字面量，比如 ORDER BY user_id，而 user_id 实际存的是字符串格式的 ID（如 'U12345'），数据库会自动做类型转换，导致索引完全失效。
- 查
pg_typeof()（PostgreSQL）或SQL_VARIANT_PROPERTY()（SQL Server）确认字段真实类型 - 在应用层确保传参类型与字段一致；Java 用
setString()而非setInt()，Python 用str(id)再拼进参数化查询 - MySQL 同理：整型字段用字符串查询（
WHERE id = '123'）会触发隐式转换，索引失效；SQL Server 中WHERE code = 123查询CHAR(10)字段也会强制转换
排序字段有没有索引，不是“有没有建”，而是“能不能用上”。类型匹配、表达式一致性、索引覆盖范围，三者缺一不可。线上查到慢，第一反应不该是加 NOLOCK 或调超时时间，而是抓执行计划，盯住那个 Sort 节点前面扫的是什么。
