order by 字段到底要不要加索引?[大坑]

MySQL是一种常用的关系型数据库管理系统，广泛应用于互联网领域。在进行MySQL优化时，其中一个重要的问题是是否给order by字段加索引。本文将围绕这一问题展开，就order by字段是否需要加索引进行深入讨论和分析。

首先，我们需要了解order by的作用和原理。order by用于对查询结果进行排序，可以根据一个或多个字段进行排序，常见的排序方式有升序和降序。在执行order by操作时，MySQL会对查询结果进行排序并返回结果集。

对于order by字段是否需要加索引这个问题，我们需要从以下几个方面进行考虑。

一、字段的选择
首先需要明确的是，不是所有的字段都适合加索引。在选择是否给order by字段加索引时，需要考虑字段的选择。一般来说，如果order by的字段是经常被查询的字段，且查询的结果集比较大，那么给该字段加索引可能会对提升查询性能有较大的帮助。否则，如果字段的查询频率不高或者查询结果集较小，给该字段加索引可能会带来反效果。

二、数据的分布和排序结果
其次需要考虑的是数据的分布情况和排序结果。如果order by的字段在数据中的分布比较均匀，那么给该字段加索引的效果可能会比较好。因为索引可以帮助MySQL快速定位到需要排序的数据位置，减少排序的开销。而如果order by的字段在数据中的分布不均匀，那么给该字段加索引可能并不能带来明显的效果，甚至可能导致性能下降。

三、索引的选择
再者需要注意的是索引的选择。在给order by字段加索引时，需要选择合适的索引类型。一般来说，对于单个字段的排序，使用B-Tree索引就可以满足需求。而对于多个字段的排序，可以考虑使用复合索引。复合索引可以将多个字段的值组合到一个索引中，减少索引的个数，提高查询的效率。

四、查询优化器的作用
最后需要考虑的是查询优化器的作用。MySQL的查询优化器可以根据查询的条件和统计信息，选择合适的执行计划。当给order by字段加索引时，查询优化器可以根据索引的选择性和查询的条件，判断是否使用该索引进行排序。如果查询优化器认为使用索引进行排序比全表扫描更高效，那么会选择使用索引进行排序。

综合以上几个方面的考虑，对于order by字段是否要加索引可以得出以下结论：

1. 如果order by字段是经常被查询的字段，查询结果集比较大，且数据分布比较均匀，可以考虑给该字段加索引。
2. 如果order by字段的查询频率不高，查询结果集较小，或者数据分布不均匀，不推荐给该字段加索引。
3. 在给order by字段加索引时，需要选择合适的索引类型，如单个字段使用B-Tree索引，多个字段使用复合索引。
4. 在实际应用中，应该根据具体的需求和实际情况来决定是否给order by字段加索引。可以通过测试和性能调优来确定是否需要加索引以及选择合适的索引。

最后需要注意的是，在进行MySQL优化时，除了是否给order by字段加索引外，还有其他优化手段可以使用，如使用合适的索引、优化查询语句、调整服务器参数等。可以综合运用这些优化手段，以达到提升MySQL性能的目的。

综上所述，order by字段是否要加索引是一个需要根据具体情况来决定的问题。需要综合考虑字段的选择、数据的分布和排序结果、索引的选择以及查询优化器的作用等因素，最终确定是否给order by字段加索引，以及选择合适的索引类型。只有在合适的情况下给order by字段加索引，才能真正提升查询性能，达到优化的效果。

SQL是上午执行的，生产故障是立马就有的！

10:08加的索引，10.20报的错，生产服务卡死

运维定位SQL，就妥妥定位在我周一申请的sql优化部分，明明就加了个索引，为何导致生产服务直接挂掉？

desc select  a.No,  -  -  -  -  -  (find_in_set(xx, a.Id))from   aleft join  r on  a.No = r.Nowhere  ( a.xxx = 1  or a.xxx = 1 )  and a.xx = 3  and r.xxx is null  and DATEDIFF(DATE_add(a.xxx,  interval 0 day ),  current_date()) >= 0order by  a.submitTime desclimit 0 ,10

生产单表a表450万数据，b表实际450万数据

生产分析

可以看出，我新建的索引已经命中，并且物理扫描行数大大减少，那么为何在生产上查不出数据？？？

为了紧急修复问题，杀死所有服务后，删除我建的索引再次执行，4S后返回

那么实际执行的扫描行数是9行为什么还如此的慢？

猜测:由于数据量较大，在执行索引操作时，进程正在进行加索引操作，此时刷新造成查询时不走任何索引，导致所有索引失效，或者前期进程有阻塞，造成加索引操作未完成

那么条件是根据用户来查询的，极端情况下理应查出最多数据在几百条，且limit后并不会太多啊？

https://blog.csdn.net/sky_jiangcheng/article/details/79513420

强制走索引生效吗？本地环境试了是不生效的，而且生产没那么长时间给你去试

本地环境，未加order by索引全表扫描，不走索引

加了order by 索引,索引命中，物理扫描行数急剧减少

https://blog.csdn.net/asdasdasd123123123/article/details/106783196/

order by 字段到底要不要加索引?

优化器直接从索引中找到了最小的10条记录，然后回表取得结果集返回。相比上一个执行计划，省去了全表扫描，省去了排序，所以执行时间和系统资源消耗都大大减少。
在这里作一个简单的分析，首先索引和数据不同，是按照有序的排列存储的，当结果集要求按照顺序取得一部分数据时，索引的功效会体现的非常明显，本次查询就是要取得object_id最小的10条记录。其次，建立索引系统只需要消耗一次资源完成排序过程，而如果没有索引，执行不同的语句可能每次都要经历排序的过程，会消耗更多的系统资源。从这个实验看，在order by字段建索引是非常划算的，而且order by字段并不一定非要加入到where条件中也可以生效。

如果这一列存在NULL值，NULL值是没有大小这一说法的，而且不会被保存在索引中。如果优化器无法确定该列没有NULL值，为了保证结果集的准确性，宁愿选择更慢的全表扫描，也不会选择走可能存在NULL的索引，即使用户指定了hint也不会选择

百思不得其解，还是问问运维老大

对于order by字段加入索引本身这个问题，如果最终的结果集是以order by字段为条件筛选的，将order by字段加入索引，并放在索引中正确的位置，会有明显的性能提升。

优化有风险，生产需谨慎！