order by 后可跟字段名、列别名、数字位置或表达式，但别名必须在select列表中明确定义且数据库版本支持（如mysql 8.0+默认支持）；多字段排序时各字段asc/desc独立生效，null排序行为因库而异，建议显式控制。
ORDER BY 后面跟字段名还是别名？
直接写字段名最稳妥，别名在 ORDER BY 中可用，但有前提：必须是 SELECT 列表中明确声明的别名，且数据库支持该语法（MySQL 5.7+、PostgreSQL、SQL Server 都支持；SQLite 支持；但某些老版本或严格模式可能报错）。
常见错误是把计算字段的别名用在 ORDER BY，结果发现排序没生效——其实是字段压根没出现在 SELECT 列表里，别名根本没被识别。
建议做法：
- 优先用原始字段名，比如
ORDER BY created_at - 若用别名，确保它出现在
SELECT中，例如SELECT user_id AS uid FROM users ORDER BY uid - 避免对表达式起别名后只在
ORDER BY里引用，比如SELECT name FROM users ORDER BY UPPER(name) AS upper_name是错的——AS在ORDER BY中不合法
多个字段排序时，NULL 值排在哪？
默认行为因数据库而异：MySQL 把 NULL 当最小值（ASC 时排最前），PostgreSQL 和 SQL Server 默认把 NULL 当最大值（ASC 时排最后）。这会导致同样的 SQL 在不同环境结果不一致。
显式控制更可靠：
- 用
ORDER BY status ASC NULLS FIRST（PostgreSQL、Oracle 支持） - MySQL 不支持
NULLS FIRST/LAST，得用IS NULL模拟：ORDER BY status IS NULL, status ASC（IS NULL返回 1/0，先按这个排，再按字段排） - SQL Server 可用
ORDER BY CASE WHEN status IS NULL THEN 0 ELSE 1 END, status
ORDER BY 会拖慢查询速度吗？
会，尤其是没索引支撑时。数据库得先把所有结果查出来，再做内存或磁盘排序，数据量一大就明显卡顿。
优化关键看执行计划：
- 如果
EXPLAIN显示Using filesort（MySQL）或Sort节点（PostgreSQL），说明触发了额外排序 - 给排序字段建索引能消除排序开销，比如常查
SELECT * FROM orders ORDER BY updated_at DESC LIMIT 20，就建INDEX ON orders(updated_at DESC) - 复合索引要注意顺序：
ORDER BY a ASC, b DESC对应索引应为(a, b DESC)；如果写成(a ASC, b ASC)，第二个字段的DESC就无法利用索引 - 注意：
WHERE条件字段和ORDER BY字段一起建联合索引时，WHERE字段必须在前，否则索引可能失效
在子查询或视图里用 ORDER BY 有意义吗？
单独子查询里加 ORDER BY 通常没意义，除非配合 LIMIT 或窗口函数。标准 SQL 规定：子查询本身不保证输出顺序，外层不加 ORDER BY，结果顺序不可靠。
典型陷阱：
-
SELECT * FROM (SELECT id, name FROM users ORDER BY name) t—— 这个ORDER BY不影响最终结果顺序 - 想取“按时间倒序的最新 3 条”，必须写成
SELECT * FROM (SELECT * FROM logs ORDER BY created_at DESC LIMIT 3) t ORDER BY created_at DESC（外层再排一次才保险） - 视图定义里写
ORDER BY多数数据库会直接忽略（PostgreSQL 允许但仅限于带LIMIT的情况；SQL Server 要求必须配TOP）
ORDER BY 必须落在最外层查询。
