欢迎订阅关注公众号：赵KK日常技术记录
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字段加入索引，并放在索引中正确的位置，会有明显的性能提升。
优化有风险，生产需谨慎！
