MySQL中用CASE WHEN实现自定义排序需显式写ELSE分支（如ELSE 999）确保未匹配值排尾，避免NULL导致错位；FIELD()更简洁但仅MySQL支持，两者均使索引失效触发filesort。
ORDER BY 配合 CASE WHEN 实现自定义排序
MySQL 默认的 ORDER BY 只能按字段值自然升序或降序排，但业务常需要“北京排第一、上海第二、广州第三”这类非字典序逻辑。最直接且兼容性好的方式是用 CASE WHEN 构造排序权重。
常见错误是写成 ORDER BY CASE WHEN city='北京' THEN 1 WHEN city='上海' THEN 2 ... END 却忘了加 ELSE 分支——一旦出现未覆盖的 city 值，ELSE 缺失会导致该行排序权重为 NULL，而 NULL 在 MySQL 中默认排在最前（升序）或最后（降序），容易导致数据错位。
- 务必补上
ELSE 999（或一个足够大的数）确保未匹配项靠后 - 如果字段可能为
NULL，需单独判断：WHEN city IS NULL THEN 999 - 权重值建议用整数，避免浮点数引发隐式转换或精度问题
SELECT * FROM users ORDER BY CASE WHEN province='广东' THEN 1 WHEN province='浙江' THEN 2 WHEN province='江苏' THEN 3 ELSE 999 END;
FIELD() 函数：更简洁的枚举值排序
当排序依据是固定枚举值（比如状态码、类型名），FIELD() 比 CASE WHEN 更简洁。它返回某个值在参数列表中的位置索引，位置越小越靠前。
注意 FIELD() 是 MySQL 特有函数，不兼容 PostgreSQL 或 SQLite；且对大小写敏感（取决于字段 collation）。如果字段是 utf8mb4_unicode_ci，则 'A' 和 'a' 视为相同，但 FIELD('a', 'A', 'B') 仍会返回 0（未匹配），因为 FIELD() 不走 collation 规则，只做严格字面匹配。
- 参数列表顺序即期望的排序顺序，不要漏掉任何可能值
- 未出现在列表中的值，
FIELD()返回 0，所以通常要搭配IS NULL或额外条件处理 - 不能用于表达式或计算字段，只接受列名或字面量
SELECT * FROM orders ORDER BY FIELD(status, 'draft', 'pending', 'confirmed', 'shipped');
多级排序中混合使用自然序与自定义序
真实场景往往既要按优先级分组（如地区优先级），组内再按时间倒序。这时不能只写一个 ORDER BY 表达式，得组合多个排序条件。
典型坑是把自定义排序和时间排序写反：比如想“广东用户优先，同地区按最新创建排”，却写成 ORDER BY created_at DESC, FIELD(province, '广东', '浙江', ...) —— 这实际先按时间排，再按省份微调，完全违背意图。
- 自定义排序字段必须放在
ORDER BY的前面位置 - 不同层级之间用逗号分隔，MySQL 从左到右依次比较
- 同一级里可混用 ASC/DESC，例如：
ORDER BY FIELD(type, 'A','B') ASC, updated_at DESC
SELECT * FROM posts ORDER BY FIELD(category, 'hot', 'news', 'tech') ASC, published_at DESC;
性能影响与索引失效风险
所有基于表达式的排序（CASE WHEN、FIELD()、函数调用）都会让 MySQL 无法使用普通 B+Tree 索引进行排序，只能走 filesort。数据量大时，这会显著拖慢查询。
如果该排序逻辑高频且稳定，考虑冗余一个整数字段（如 sort_weight）并建立索引。每次写入或更新时用触发器或应用层同步维护这个权重值，换来查询时的 ORDER BY sort_weight 直接走索引。
-
EXPLAIN中看到Using filesort就说明排序没走索引 - 临时表 + filesort 在内存不足时会落磁盘，IO 开销剧增
- 字符串字段用
FIELD()排序比CASE WHEN略快，但差距不大，别指望靠换函数优化性能
自定义排序本身不难，难的是权衡可读性、兼容性和性能。多数小项目用 FIELD() 足够，但只要 QPS 上千或单表超百万行，就得认真考虑加冗余排序字段了。
