索引要求：

• 排序列必须是B-tree索引字段。
• 在多表关联查询中，排序列必须是驱动表字段。

优化示例：

• 单表排序：

  select * from sbtest4 t4 order by t4.k desc limit 5;

  当k列是B-tree索引时，MySQL会优先利用索引进行排序。

• 多表关联：

  select * from sbtest4 t4 join sbtest3 t3 on t4.id=t3.id order by t3.k limit 5;

  在驱动表sbtest3中，排序列k需要是B-tree索引。

复合索引的最佳实践：

• 当复合索引的最左前缀是过滤条件时，order by字段配合常量过滤可以高效利用复合索引。
• 避免以下情况：
  • 排序字段涉及多个未覆盖的索引。
  • 排序字段包含升序或降序操作。
  • 排序字段引用了不在索引中的字段。

无法利用索引的情况：

• 排序基准过多，无法满足索引覆盖条件。
• 多个UNION子查询需要排序。
• 需要随机访问结果记录。

特点：

• 排序字段为驱动表字段，且该字段无有效索引。
• 被驱动表关联字段需要通过索引进行过滤。

优化示例：

select * from sbtest4 t4 join sbtest3 t3 on t4.id=t3.id where t3.k < 1000 order by t3.c limit 5;

在执行计划中可以看到Using filesort，表明使用了文件排序。

优化建议：

• 优化where过滤条件，减少驱动表扫描和排序的记录数。
• 尽量避免使用select *，而是只选择需要的字段。

特点：

• 排序字段为被驱动表字段。
• MySQL需要获取多表关联结果后才能进行排序。

优化示例：

select * from sbtest4 t4 join sbtest3 t3 on t4.id=t3.id where t3.k < 1000 order by t4.k limit 5;

执行计划中可以看到Using temporary; Using filesort，表明使用了临时表和文件排序。

优化建议：

• 尽量避免使用order by字段作为被驱动表字段。
• 优化where过滤条件，减少需要排序的记录数。
• 减少select *的使用，避免磁盘临时表的读取开销。

两次扫描算法：

• 适用于包含大字段（如BLOB或TEXT）或需要排序记录较多的情况。
• 优点：减少随机IO读取开销。
• 缺点：需要两次对数据进行扫描。

一次扫描算法：

• 适用于排序记录较少且不超过max_length_for_sort_data的情况。
• 优点：减少IO读取次数。
• 缺点：不适用于包含大字段的查询。

优先队列排序：

• 适用于order by ... limit M, N的场景。
• 优点：减少sort_buffer_size的使用需求。
• 缺点：需要扫描所有记录。