是，列顺序直接影响排序逻辑：MySQL从左到右依次排序，先按第一列分组，相同值再按第二列排；升序降序需显式声明；NULL排序行为依赖版本和SQL mode；自定义枚举序优先用FIELD()或生成列+索引；函数排序导致索引失效；深分页应避免OFFSET而用游标分页。
ORDER BY 多列排序时，列顺序真的影响结果吗？
影响非常大。MySQL 按 ORDER BY 中从左到右的列依次排序：先排第一列，相同值的行再按第二列排，以此类推。不是“同时比较所有列”。
- 错误写法：
ORDER BY status, created_at本意是“先看状态，再看时间”，但如果status值大量重复（比如多数是'active'），实际起作用的往往是created_at—— 这容易让人误以为排序没生效 - 升序降序混用必须显式声明：
ORDER BY priority DESC, updated_at ASC；不写默认全是ASC，DESC不会“传染”给后面列 - NULL 值默认排在最前（
ASC）或最后（DESC），和具体 MySQL 版本及 SQL mode 有关，不能假设一致
想按「待处理→处理中→已完成」这种非字典序排，怎么写？
用 FIELD() 函数最直接，它按参数出现顺序返回索引（从 1 开始），适合有限、固定的枚举值。
-
ORDER BY FIELD(status, 'pending', 'processing', 'done')—— 值为'pending'的排最前，'done'最后 - 如果
status可能有新值（比如后期加了'cancelled'），它会被排在最后（因为FIELD()找不到时返回 0），要提前预留或改用CASE WHEN - 性能上，
FIELD()是逐行计算，无法走索引；数据量大且该字段常用于自定义排序时，建议加生成列 + 索引：ALTER TABLE tasks ADD COLUMN status_sort TINYINT GENERATED ALWAYS AS (CASE status WHEN 'pending' THEN 1 WHEN 'processing' THEN 2 WHEN 'done' THEN 3 ELSE 4 END) STORED，再对status_sort建索引
ORDER BY 里用了函数或表达式，为什么索引失效了？
因为 MySQL 无法直接用索引匹配计算后的值。例如 ORDER BY UPPER(name) 或 ORDER BY created_at + INTERVAL 1 DAY，都会导致全表扫描+filesort。
- 常见陷阱：
ORDER BY DATE(created_at)—— 即使created_at有索引也没用；应改用范围查询 + 索引排序，比如先查某天的数据，再在应用层分页 - 替代方案优先级：① 改用生成列+索引（如上）；② 把计算逻辑提到写入侧（比如存一个
created_date字段）；③ 实在不行，确认执行计划中Extra是否含Using filesort，并评估是否可接受 - 注意：JSON 字段里的值用
->提取后排序，同样无法走索引，属于同类型问题
ORDER BY 和 LIMIT 一起用，为什么分页偏移大时特别慢？
MySQL 必须先按 ORDER BY 排出全部结果，再跳过前 N 行。比如 LIMIT 100000, 20，它得排序至少 100020 行才取最后 20 条。
- 根本解法是避免
OFFSET：用上一页最后一条记录的排序字段值做条件，例如WHERE id > 12345 ORDER BY id LIMIT 20（要求排序字段唯一且有索引） - 如果排序字段不唯一（比如按
created_at），必须组合主键去重：WHERE (created_at, id) > ('2024-01-01 12:00:00', 99999) ORDER BY created_at, id LIMIT 20 - 别依赖
SQL_CALC_FOUND_ROWS，它在高并发下开销大且已废弃；总条数单独查COUNT(*)更可控
真正麻烦的是「既要精确总数，又要深分页」——这两个需求本质冲突，得在业务上妥协，比如只允许查前 100 页，或改用搜索型分页。
