order by 默认是升序（asc），符合 sql 标准，mysql、postgresql、sql server、sqlite 等均一致；未显式指定方向时等价于 asc。

ORDER BY 默认是升序还是降序

ORDER BY 默认按升序（ASC）排列，不是“看数据库类型决定”，也不是“有时升有时降”——这是 SQL 标准行为，MySQL、PostgreSQL、SQL Server、SQLite 全都一样。如果你没写明方向，就等价于写了 ORDER BY col ASC。

常见错误现象：
– 查询结果看起来“乱序”，其实只是按主键或插入顺序偶然有序，误以为 ORDER BY 没生效
– 用 ORDER BY col DESC 后发现 NULL 值总排最前/最后，和预期不符（不同数据库对 NULL 的排序策略不同）

实操建议：
– 显式写出 ASC 或 DESC，别依赖默认，尤其在团队协作或跨库迁移时
– 如果要控制 NULL 位置，PostgreSQL 支持 NULLS FIRST/NULLS LAST；MySQL 8.0+ 和 SQL Server 也支持类似语法；旧版 MySQL 只能靠 IS NULL 补丁处理
– 多列排序时，每列方向独立，比如 ORDER BY status DESC, created_at ASC

多个字段排序时的优先级和执行顺序

ORDER BY 是从左到右逐列比较的：先按第一列分组，组内再按第二列排，依此类推。它不是“加权合并”，也不是“先全量排 A 再整体排 B”。

使用场景：
– 查用户列表，希望“激活用户在前 → 按注册时间倒序 → 时间相同时按昵称字典序”
– 日志分析，先按错误等级（level）降序，同等级再按时间升序

实操建议：
– 列顺序直接影响结果逻辑，调换 ORDER BY a, b 和 ORDER BY b, a 得到的是完全不同的序列
– 不要指望数据库“智能优化”多列顺序——你写的顺序就是执行顺序
– 对非主键字段排序，记得确认该字段有索引，否则大表会慢；复合索引需匹配 ORDER BY 的最左前缀（如索引是 (a, b)，则 ORDER BY a, b 可走索引，但 ORDER BY b, a 不行）

字符串排序为什么 ‘apple’ > ‘Banana’

因为绝大多数数据库默认用 ASCII 或 Unicode 码点排序，而大写字母 A-Z 的码点（65–90）小于小写字母 a-z（97–122），所以 'Apple' 'banana'，但 'apple' > 'Banana'。

常见错误现象：
– 前端显示“按名称排序”点了两次（升→降），结果大小写混排，用户觉得“没排好”
– 搜索结果里 “user10” 排在 “user2” 后面（字典序导致）

实操建议：
– 需要忽略大小写时，用 ORDER BY LOWER(name) 或数据库特定函数（如 MySQL 的 COLLATE utf8mb4_general_ci）
– 数字字符串想按数值排？别直接 ORDER BY version，改用 ORDER BY CAST(version AS SIGNED) 或正则提取数字部分
– 注意 COLLATION 影响排序和索引使用，修改它可能让已有索引失效

ORDER BY 在分页查询中的陷阱

用 LIMIT + OFFSET 分页时，如果排序依据不唯一，同一查询执行两次可能返回不同结果——特别是高并发写入场景下，新数据插入可能导致“跳行”或“重复”。

性能影响：
– OFFSET 10000 不是跳过前 10000 行再取，而是扫描并丢弃前 10000 行，越往后越慢
– 如果 ORDER BY 字段没有索引，整个分页过程可能触发全表扫描

实操建议：
– 关键分页必须搭配唯一、稳定、有索引的排序字段，推荐组合主键，例如 ORDER BY status, id（假设 id 是自增主键）
– 替代 OFFSET 的游标分页：记录上一页最后一条的 (status, id) 值，下一页查 WHERE (status, id) > ('active', 12345) ORDER BY status, id LIMIT 20
– 不要对 SELECT * 加复杂 ORDER BY 后再 LIMIT，先用子查询或 CTE 把排序范围缩小

容易被忽略的一点：ORDER BY 的表达式不能直接引用 SELECT 中的别名（除非数据库明确支持，如 PostgreSQL），写 SELECT price * 1.1 AS final_price ORDER BY final_price 在 MySQL 会报错，得写成 ORDER BY price * 1.1。