ORDER BY多字段排序需显式声明每个字段方向，否则仅最后字段生效DESC；NULL值须用NULLS LAST或表达式处理；ThinkPHP动态排序须白名单校验字段与方向；多级排序与加权排名适用场景不同。
ORDER BY 多字段排序的写法必须显式声明每个方向
很多人以为 ORDER BY price, create_time DESC 是让两个字段都降序，其实它等价于 ORDER BY price ASC, create_time DESC——只有最后一个字段生效了 DESC，前面的全按默认 ASC。这在报表里容易导致“状态相同但时间倒着排”的错觉，实际却混着升序。
正确做法是每个字段单独加方向：
-
ORDER BY status ASC, updated_at DESC, id DESC—— 先按状态升序（比如 0 待处理 → 1 已发货 → 2 已完成），同状态内按更新时间倒序，再同时间就按 ID 倒序兜底 - 字段间用逗号分隔，不能重复写
ORDER BY - 数据库执行时严格从左到右：左边字段值不同时，右边字段根本不会参与比较
NULL 值会让排序结果不可控，必须主动干预
比如 updated_at 为空的老数据，和有值的新数据混排时，MySQL 默认把 NULL 排在最前（ASC）或最后（DESC），但业务上你往往希望“有更新时间的优先展示”。直接忽略会导致分页错乱、导出顺序每次都不一样。
解决方法取决于数据库版本：
- MySQL 8.0+ / PostgreSQL：直接加
NULLS LAST或NULLS FIRST，例如ORDER BY updated_at DESC NULLS LAST - 老版本 MySQL / SQLite：用表达式模拟，
ORDER BY (updated_at IS NULL) ASC, updated_at DESC—— 把非空当 1、空当 0，升序后非空自然靠前 - 别用
COALESCE(updated_at, '1970-01-01')填假时间，会污染“最早更新时间”这类统计口径
ThinkPHP 8.0 动态传参排序要防 SQL 注入
用户请求带 sort=price_desc,create_time_asc 这种参数时，不能直接拼进 order()。TP8.0 的 order() 支持数组形式，但字段名和方向必须白名单校验。
安全写法示例：
$allowedFields = ['id', 'price', 'create_time', 'status'];
$allowedOrders = ['ASC', 'DESC'];
$sort = $_GET['sort'] ?? '';
$orderArray = [];
foreach (explode(',', $sort) as $item) {
[$field, $dir] = array_pad(explode('_', trim($item), 2), 2, 'ASC');
$dir = strtoupper($dir);
if (in_array($field, $allowedFields) && in_array($dir, $allowedOrders)) {
$orderArray[$field] = $dir;
}
}
Db::name('goods')->order($orderArray)->select();
- 字段名只允许字母、数字、下划线，且必须在预设白名单中
- 方向只接受
ASC/DESC，大小写都要转大写再判断 - 没过校验的字段或方向会被静默丢弃，不报错也不执行
多条件排序和加权排名不是一回事
业务说“销量优先、好评率其次、上架时间最后”，这是多级排序，直接写 ORDER BY sales DESC, rating DESC, listed_at DESC 就行。但如果说“按销量 × 0.6 + 好评率 × 0.4 综合打分排名”，就得用表达式合成单值，再套 ROW_NUMBER()。
关键区别：
- 多级排序：字段间不抵消，销量高就能压倒低好评率；适合规则明确、优先级清晰的场景
- 加权排名：所有字段合并成一个数值，需要
COALESCE(x, 0)处理空值，乘法前建议CAST(x AS DECIMAL(10,2))防截断 - 索引友好度不同：复合索引
(sales, rating, listed_at)能加速多级排序；加权表达式基本无法走索引，大数据量慎用
真正难的不是写法，而是想清楚业务到底要“分级决策”还是“统一分数”——这个判断错了，后面所有优化都是白忙。
