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

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

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

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

desc select
  a.No,
  -
  -
  -
  -
  -
  (find_in_set(xx, a.Id))
from
   a
left join  r on
  a.No = r.No
where
  ( 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()) >= 0
order by
  a.submitTime desc
limit 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字段加入索引，并放在索引中正确的位置，会有明显的性能提升。

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