CodeIgniter 的 order_by() 未生效最常见原因是 get() 调用触发 _reset_select() 清空排序，或 order_by() 写在 get() 后、传入空参数、子查询中 ORDER BY 被 MySQL 忽略、字段无索引或类型不匹配导致排序失效。
CodeIgniter 的 order_by() 调用后没进 SQL
最常见的情况是：你写了 $this->db->order_by('created_at', 'DESC')->get('users')，但查日志发现生成的 SQL 里根本没有 ORDER BY。根本原因是——get() 方法内部会调用 _reset_select()，而如果你在 get() 之前还调用了其他查询构建方法（比如 from()、join() 或再次 get()），就可能意外覆盖或清空已设置的排序条件。
尤其注意这个陷阱：
- 你在循环中多次调用
get('table', $limit, $offset)，每次都会重置整个查询状态，包括order_by - 你把
order_by()写在get()之后（比如$this->db->get()->order_by(...)），这毫无意义——get()已执行并返回结果，后续调用不改变 SQL - 你混用了链式调用和分步调用，例如先
$this->db->from('a')->join('b')，然后中间插了别的逻辑，再->order_by()->get()，但中间某处触发了隐式get()或reset_query()
order_by() 参数为空字符串或 null 导致静默失效
CodeIgniter 对空值容忍度过高：order_by('', 'ASC') 或 order_by(null, 'DESC') 不报错，但也不会写入 SQL。如果你从控制器传参进来，比如 get_all($table, $where, $order)，而调用时漏传 $order 或传了空字符串，order_by() 就直接跳过。
安全写法是显式判断：
if (!empty($order)) {
$this->db->order_by($order);
}
别依赖“默认不加 order_by 就不排序”——你要的是可控，不是靠运气。
MySQL 层面 ORDER BY 被优化器忽略
即使 CodeIgniter 正确生成了 ORDER BY，MySQL 也可能不执行它。典型场景：
- 子查询里写了
ORDER BY（如FROM (SELECT * FROM t ORDER BY id) AS tmp）：MySQL 5.7+ 明确忽略这种写法，因为子查询结果集本身无序；必须配合LIMIT才生效，或者把ORDER BY提到外层 - 排序字段没有索引，且数据量大：MySQL 可能选择文件排序（
Using filesort），虽仍排序但性能差；更糟的是，如果WHERE条件导致索引失效，ORDER BY就无法利用索引加速，甚至被优化器弃用 - 字段类型是
VARCHAR但按数值意图排序：比如ORDER BY version（值为'1','10','2'），结果是字典序'1', '10', '2'；需改写为ORDER BY version+0强制转整型
分页场景下排序“看起来”失效
这不是 CodeIgniter 的 bug，而是逻辑误解：你用 limit(10)->offset(20)->order_by('id', 'DESC') 查第 3 页，但每页数据本身是倒序的，而你期望“所有数据全局倒序后切片”。问题在于——如果 id 不连续（有删除），OFFSET 分页会导致跳过或重复。更隐蔽的是，若你没加 ORDER BY，MySQL 返回顺序本就不保证，两次分页请求之间数据可能错位。
真正可靠的分页排序必须满足两个条件：
-
ORDER BY字段组合必须能唯一确定每一行（推荐加上主键，如ORDER BY status DESC, id DESC） - 避免纯
OFFSET，改用游标分页（cursor-based pagination），例如记录上一页最后的id，下一页查WHERE id
否则，你调试半天 order_by() 有没有生效，其实是在和 MySQL 的非确定性行为较劲。
