FIELD()函数将字段值映射为匹配位置（从1开始），未匹配或NULL返回0；ORDER BY中需配合CASE或IF处理未匹配项置后，且大表应避免裸用以保障性能。
FIELD() 函数怎么用：先搞清返回值逻辑
FIELD() 不是排序函数，它只是把字段值映射成一个整数（匹配位置从 1 开始），然后交给 ORDER BY 去排序。它的行为很明确：
- 字段值等于第一个参数 → 返回
1 - 等于第二个 → 返回
2 - 不匹配或为
NULL→ 统一返回0
所以 ORDER BY FIELD(status, 'onsale', 'sold', 'deleted') 实际上等价于按一个隐藏的数字列升序排：0（未匹配/NULL）→1→2→3。如果你希望未匹配项排最后，不能靠默认行为，得手动干预。
多条件组合排序：FIELD + 其他字段怎么写
多个 FIELD() 可以并列写在 ORDER BY 后，MySQL 会逐级比较。比如要按「是否新项目」优先、「状态」自定义顺序、「利率」降序、「起购时间」升序：
ORDER BY is_new_proj DESC, FIELD(project_status, 'draft', 'reviewing', 'published', 'closed'), loan_apr DESC, gmt_buy_start ASC
注意点：
- 每个条件之间用英文逗号分隔，不要加括号包裹整个列表
-
FIELD()本身只控制单个字段的相对顺序，它后面的条件（如loan_apr DESC）只对FIELD()值相同的数据生效 - 如果某字段有
NULL，而你又没在FIELD()列表里列出NULL（它无法被列出），那这些行默认排最前——这常被误认为“乱序”，其实是设计如此
未匹配值想放最后？别信默认，用 CASE 包一层
直接靠 FIELD() 无法让不匹配项排最后，因为返回 0 就是升序最小值。常见错误写法是加 DESC：FIELD(x, 'a','b') DESC，结果反而把匹配项全压到后面去了。
正确做法是用 CASE 把匹配和未匹配拆开赋权：
ORDER BY
CASE
WHEN FIELD(project_status, 'draft', 'reviewing', 'published') = 0
THEN 9999
ELSE FIELD(project_status, 'draft', 'reviewing', 'published')
END
这样未匹配的统一变成 9999，自然排最后。更简洁的写法（MySQL 5.7+）：
ORDER BY IF(FIELD(project_status, 'draft', 'reviewing', 'published') = 0, 1, 0), FIELD(project_status, 'draft', 'reviewing', 'published')
第一层用 IF 把未匹配打标为 1、匹配打标为 0，升序后匹配组整体在前；第二层再在匹配组内精细排序。
性能和兼容性：别在大表 ORDER BY 里裸用 FIELD()
FIELD() 是逐行计算的标量函数，没有索引支持。在百万级表上直接 ORDER BY FIELD(id, ...) 会导致 filesort，且无法利用 project_status 字段上的索引。
- 如果只是偶尔导出、后台管理页用，影响不大
- 如果是高频查询，且自定义顺序固定（比如状态流转只有 4 种），建议加一个生成列（generated column）+ 索引：
ALTER TABLE projects ADD COLUMN status_sort TINYINT AS (FIELD(project_status, 'draft','reviewing','published')) STORED;
再建索引：CREATE INDEX idx_status_sort ON projects(status_sort); - Oracle / PostgreSQL 不支持
FIELD()，跨库迁移时必须改写为CASE表达式
真正容易被忽略的是：FIELD() 的参数列表长度没有硬限制，但过长（比如传 200 个字符串）会让 SQL 解析变慢，也增加网络传输开销——业务上真需要排 200 个值？大概率该反思数据建模了。
