数据库排序比PHP数组排序快得多，因数据库引擎利用索引和外部归并优化，而PHP需全量加载内存排序；仅当排序逻辑无法SQL表达、数据非数据库来源或数据量极小时才用PHP排序。
数据库排序比PHP数组排序快得多
只要数据来自数据库，优先用 ORDER BY。MySQL、PostgreSQL 等引擎对排序做了大量优化，比如利用索引跳过全表扫描、使用外部归并排序处理大数据集。而 PHP 的 usort() 或 array_multisort() 必须先把所有结果拉到内存里，再逐行比较——10 万条记录可能吃掉几百 MB 内存，响应时间从 20ms 拉到 2s+。
常见错误现象：
- 页面加载明显变慢，尤其翻页后卡顿
- PHP 进程内存溢出（
Fatal error: Allowed memory size exhausted） - 数据库连接池被占满，其他请求超时
适用场景：查询结果 > 1000 行、排序字段有索引、不需要在 PHP 中做复杂逻辑判断。
什么时候必须用 PHP 数组排序
当排序逻辑无法用 SQL 表达，或者数据压根不来自数据库时，才轮到 PHP 出场。
立即学习“PHP免费学习笔记（深入）”；
典型情况包括：
- 把多个 API 返回的数组合并后统一排序（比如聚合商品 + 文章 + 活动）
- 按自定义规则排序：比如“置顶 > 热门 > 新发布”，且状态存在不同字段或表中
- 排序依据是 PHP 运行时计算值（如：
$item['score'] = $item['likes'] * 1.5 - $item['dislikes']） - 数据量极小（
注意：usort() 的回调函数不能直接访问外部变量，需用 use 声明；多维数组按某键排序推荐用 array_multisort() 配合 array_column()，比嵌套 usort() 更稳。
PDO 预处理不能绑定 ORDER BY 字段名
ORDER BY ? 或 ORDER BY ? DESC 会直接报错：SQLSTATE[HY093]: Invalid parameter number。PDO 和 MySQLi 都不支持对列名、表名、关键字（如 ASC/DESC）做参数化绑定。
安全做法只有白名单校验：
- 字段名白名单必须完全匹配，包括大小写和下划线（如
user_name≠username） - 方向只接受
ASC或DESC，且要用strtoupper()统一转换后比对 - 不要自动加反引号（
`$field`），除非你确认所有字段名都符合标识符规范；更稳妥的是白名单里直接存带反引号的字符串 - 示例代码片段：
$allowed = ['id', 'name', 'created_at', 'score'];<br>$field = in_array($_GET['sort'] ?? '', $allowed) ? $_GET['sort'] : 'id';<br>$order = strtoupper($_GET['order'] ?? 'DESC') === 'DESC' ? 'DESC' : 'ASC';<br>$sql = "SELECT * FROM users ORDER BY $field $order";
NULL 值排序行为容易被忽略
MySQL 默认把 NULL 当作最小值：升序时排最前，降序时排最后。这会导致“最新文章没显示在顶部”，因为 published_at 允许为 NULL 的草稿把正常数据挤下去。
修复方式分版本：
- MySQL 8.0.22+：直接用
ORDER BY published_at DESC NULLS LAST - 老版本或兼容写法：用布尔表达式
ORDER BY published_at IS NULL, published_at DESC，把非空值优先排前面 - 如果字段允许 NULL 且业务上不该出现，建表时就该加
NOT NULL约束，比补救排序更彻底
这个细节在测试环境常被掩盖——因为测试数据往往没 NULL，上线后才暴露。
