ORDER BY 2 等列序号排序方式因强绑定 SELECT 字段物理位置，一旦字段增删、重排或加表达式，排序语义即错乱且不报错；高危场景包括视图、CTE、存储过程及跨团队 SQL；应优先用字段名或明确别名排序。
ORDER BY 2 这种写法为什么一改就崩
用列序号（如 ORDER BY 2）排序，本质是把排序逻辑和 SELECT 列表的物理位置强绑定。一旦 SELECT 字段顺序调整、增删字段或加了新表达式，序号对应关系立刻失效，排序结果完全错乱，但 SQL 本身不报错——这是最危险的静默故障。
-
SELECT name, age, created_at FROM users ORDER BY 2表示按age排；但如果改成SELECT id, name, age, created_at，ORDER BY 2就变成按name排，业务含义全变 - ORM 或报表工具生成的 SQL 常含动态字段，序号写死会导致下游解析失败，比如前端 expect 第二列是时间，实际却排了状态
- MySQL 5.7 及更早版本中，
ORDER BY引用别名（如ORDER BY full_name）会报错，有人转而用序号“绕过”，结果埋下长期隐患
哪些场景最容易踩中列序号陷阱
不是所有地方都禁用序号，但高风险场景非常集中：视图定义、CTE、存储过程、跨团队共享 SQL 片段。这些地方的维护者往往不是最初编写者，也看不到原始 SELECT 结构。
- 视图里写
ORDER BY 3，下游应用直接SELECT * FROM v_users，结果顺序随视图内部调整而漂移 - 分页查询用
LIMIT+ORDER BY 1，本意是按主键排，但某次加了ROW_NUMBER() OVER(...)到 SELECT 首位，ORDER BY 1就变成按行号排，分页彻底乱套 - 数据库迁移时（如 MySQL → PostgreSQL），序号行为虽一致，但 NULL 处理、默认 collation 差异放大了排序错位的影响，问题更难定位
替代方案：用字段名还是表达式？
优先用原始字段名或明确别名；表达式仅在必要时使用，且必须确保索引支持或性能可接受。
- 安全写法：
ORDER BY status ASC, updated_at DESC—— 字段名稳定，语义清晰，DBA 工具能自动校验存在性 - 允许用别名，但需确认数据库版本支持（PostgreSQL / SQL Server 全支持；MySQL 8.0+ 支持，5.7 不支持）
- 表达式慎用：
ORDER BY UPPER(last_name)会让普通索引失效；若必须大小写不敏感排序，应建函数索引（MySQL 8.0+）或生成列
为什么连“看起来没动”的SQL也可能出问题
即使你没改 ORDER BY 那一行，只要上游 SELECT 中任意字段被重排、别名被修改、或新增了计算列，序号就失准。这不是数据库 bug，而是把耦合藏进了数字里。
- SQL 格式化工具自动重排 SELECT 字段（如 Prettier SQL 插件），
ORDER BY 2指向对象已变 - 开发合并分支时，A 改了 SELECT，B 改了 ORDER BY 序号，Git 不提示冲突，但逻辑已断
- 某些 BI 工具导出 SQL 时会自动补别名或重排字段，粘贴回数据库执行就错
列序号看似省事，实则是把排序契约从“按什么值排”降级为“按第几个位置排”。一旦 SELECT 结构脱离初始设计，它就失去可维护性——而结构变动才是常态。
