ORDER BY 1 是按 SELECT 列表第 1 列排序，不是表结构第 1 列；1 指 SELECT 子句中从左到右第 1 个字段的位置序号，与表定义顺序无关，执行发生在 SELECT 之后，作用于结果集。
ORDER BY 1 是按 SELECT 列表第 1 列排序，不是表结构第 1 列
ORDER BY 1 中的 1 指的是 SELECT 子句中从左到右数的第 1 个字段（位置序号），和表定义里的字段顺序完全无关。比如 SELECT name, id FROM users 后跟 ORDER BY 1，就是按 name 排，哪怕表里 id 是第一个定义的字段。
常见错误现象：
- 写
SELECT id, name FROM users ORDER BY 1却以为在按表里第 1 列（即id）排——其实没错，但只是巧合；换成SELECT name, id FROM users ORDER BY 1就立刻暴露问题：它排的是name，不是id - 用视图或复杂子查询时，误以为
ORDER BY 1指向底层表字段，结果排序错乱
ORDER BY 1, 2 这种多数字写法怎么生效？
多个数字表示按 SELECT 列表中对应位置的字段依次排序：ORDER BY 1, 2 等价于 ORDER BY , ，先按第 1 列升序，相同值再按第 2 列升序。
使用场景：
- 动态生成 SQL 时字段顺序固定但别名不统一，用数字可避免硬编码字段名
- 临时调试查数据，懒得打完整字段名，
SELECT * FROM t ORDER BY 1快速看首列分布 - 某些 ORM 或报表工具生成的 SQL 会自动用数字引用，需理解其实际含义
注意：ORDER BY 1, 2 和 ORDER BY 2, 1 结果完全不同，顺序不可颠倒。
DISTINCT 和 ORDER BY 数字共用时容易报错
当 SELECT 带 DISTINCT 时，ORDER BY 引用的数字列必须出现在去重后的结果列中。例如 SELECT DISTINCT name FROM users ORDER BY 1 合法，但 SELECT DISTINCT name FROM users ORDER BY 2 会报错 —— 因为 SELECT 列表只有 1 列，2 超出范围。
典型错误信息：ERROR: ORDER BY position 2 is not in select list（PostgreSQL）或类似提示。
参数差异：
- MySQL 允许
ORDER BY引用未出现在 SELECT 列表中的字段（只要在 FROM 表中存在），但标准 SQL 和 PostgreSQL、SQL Server 等严格要求必须出现在 SELECT 列表中 -
GROUP BY同样支持数字引用，规则与ORDER BY一致，但语义是分组依据而非排序
为什么建议少用 ORDER BY 1，优先写字段名？
数字引用看似省事，但可读性和可维护性差，尤其在 SELECT 字段增删或顺序调整后，ORDER BY 1 可能悄无声息地指向了完全不同的字段。
性能/兼容性影响：
- 数据库优化器对字段名能更好利用索引；数字引用不改变执行计划，但让人工审查和索引设计更困难
- 某些旧版 SQLite 或嵌入式数据库对数字引用支持不完整，跨平台迁移时易出问题
- 带表达式或函数的 SELECT（如
SELECT UPPER(name)）中，ORDER BY 1排的是计算结果，不是原始字段，这点常被忽略
真正难处理的不是语法本身，而是当别人接手你写的 SELECT a, b, c, d FROM t ORDER BY 3, 1 时，得翻半天才知道第 3 列到底是哪个字段、有没有被别名覆盖、是否参与了聚合——这些细节全藏在 SELECT 列表里，数字本身不提供任何上下文。
