MySQL中FIELD()函数用于自定义排序，语法为FIELD(value,val1,val2,...)，匹配返回从1开始的位置，未匹配或NULL返回0；不支持变量、函数或子查询，且区分大小写和空格，须在ORDER BY中使用才生效。
MySQL 用 FIELD() 最快最直接；其他数据库必须改用 CASE WHEN，不能偷懒照搬。
MySQL 中 FIELD() 的正确写法和常见翻车点
它只接受字面量（如 'draft'、'shipped'），不能传变量、函数或子查询。写成 FIELD(status, UPPER('draft')) 会报错。
- 匹配成功返回位置（从 1 开始），没匹配上一律返回 0 → 所有未列出的状态都挤在结果最前面
- 如果
status字段含空格或大小写不一致（比如数据里是'Draft'但FIELD()写了'draft'），就完全不匹配 - NULL 值也会返回 0，得提前用
COALESCE(status, 'unknown')处理，否则可能把 NULL 和真实未列状态混在一起 - 别把它写在
SELECT里却忘了在ORDER BY中引用——ORDER BY才是真正起作用的地方
PostgreSQL / SQL Server / SQLite 怎么等价实现
这些数据库不认 FIELD()，但可以用 CASE WHEN 映射成数字序号，逻辑一样，只是更啰嗦。
- 必须写全
ELSE分支，否则没匹配上的行排序值为NULL，而NULL在ORDER BY中行为取决于数据库配置（NULLS FIRST还是NULLS LAST），不如FIELD()可控 - PostgreSQL 可用
ARRAY_POSITION(ARRAY['draft','confirmed'], status)，但要求status类型与数组元素严格一致，且数组不能含 NULL - SQLite 没原生函数，常用
INSTR(',draft,confirmed,', ','||status||',')，但要注意前后加逗号防子串误匹配（比如'paid'被'unpaid'包含）
为什么不能只靠 ORDER BY 配合原始字段排序
因为分组字段本身（比如 status）的值是离散字符串，按字母序排出来的“cancelled, completed, confirmed”完全不符合业务流转逻辑。
-
GROUP BY不保证输出顺序，ORDER BY是最后一步，只影响最终结果排列，不影响分组过程 - 想让“draft → confirmed → paid → shipped → completed”这个顺序生效，必须把它们转成可比较的数值（1→2→3→4→5），再按这个数值排
- 如果分组基数大（比如上万种 status 值），但
FIELD()只列了几十个，其余全归为 0，会导致大量同序号项，ORDER BY稳定性下降——这时建议前置过滤或用HAVING限制输出范围
真正麻烦的不是写法，而是业务状态是否全量覆盖、NULL 和空字符串怎么归类、以及不同环境数据库版本是否支持对应函数——上线前最好拿真实数据跑一遍，别只看测试库那几条样例。
