个人使用9: in有没有用到索引？

场景:老大来找我了。你对应sql写in来进行匹配，我在我电脑执行了下，速度很堪忧，小老弟你换另一种看看，本地用到了索引。

是一个简简单单的删除语句。用A表的主键去查询A-子表的明细，对应明细id 是B表的主键。然后一波带走删除。 我寻思我思路是ojbk的。对应 A-子表跟B表都可能是数据量很大的大表。这样删除会不会效率很慢？

想归想，闹归闹。总要拿出点证据。所以就去进行sql语句分析。
1.第一步 先在我电脑上直接执行

我的语句大概在0.44s

老大的语句大概在0.53 不过多跑几次 浮动范围是在0.41-0.55波动，上面就稳定很多了。

接下去进行 explain 进行sql运行语句分析。

图片是截图的，可能带模糊 大致我们关注 type 是ref 对应possible_keys 也有对应数据。

第二句也照样可。
二者的解析结果一致。所以下面语句应该没有特别快。或者是对应数据库本身一些进行过优化吗？
所以我再思考是否是数据库不同。
最后追溯过去是这样的。本地mysql数据库版本是8.0.x，老大的是仿线上数据库，对应版本是5.7.9 大版本是5.7 小版本只有9.对应运行结果也的确是下面sql执行用到索引了，对应上面的未使用到索引。
这里也额外百度查询了，对应5.7.17版本是查询问题时候，对应博主的版本号，也说in可以使用到索引。 那么暂时是5.7.17以下存在in无法匹配索引的问题，对应8是一定可以使用到in索引的。

额外补充:
对应来源一个比较好的博客分析 https://www.cnblogs.com/bulushengse/p/12703789.html
1.sql解析简单观察

我们只需要注意一个最重要的type 的信息很明显的提现是否用到索引：

type结果值从好到坏依次是：

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge >
unique_subquery > index_subquery > range > index > ALL

all:全表扫描

index:另一种形式的全表扫描，只不过他的扫描方式是按照索引的顺序

range：有范围的索引扫描，相对于index的全表扫描，他有范围限制，因此要优于index

ref:
查找条件列使用了索引而且不为主键和unique。其实，意思就是虽然使用了索引，但该索引列的值并不唯一，有重复。这样即使使用索引快速查找到了第一条数据，仍然不能停止，要进行目标值附近的小范围扫描。但它的好处是它并不需要扫全表，因为索引是有序的，即便有重复值，也是在一个非常小的范围内扫描。

const:通常情况下，如果将一个主键放置到where后面作为条件查询，mysql优化器就能把这次查询优化转化为一个常量。至于如何转化以及何时转化，这个取决于优化器

一般来说，得保证查询至少达到range级别，最好能达到ref，type出现index和all时，表示走的是全表扫描没有走索引，效率低下，这时需要对sql进行调优。

当extra出现Using filesor或Using temproary时，表示无法使用索引，必须尽快做优化。

possible_keys：sql所用到的索引

key：显示MySQL实际决定使用的键（索引）。如果没有选择索引，键是NULL

rows: 显示MySQL认为它执行查询时必须检查的行数。

对应in 如果取值范围扩大，效率会变慢，大到一定程度。会不走索引，走全表扫描

3. using 是什么？
   using()用于两张表的join查询，要求using()指定的列在两个表中均存在，并使用之用于join的条件。
   举例:

select * from 表1 inner join 表2 on 表1.相同的列=表2.相同的列;
select 表1的列 from 表1 inner join 表2 on 表1.相同的列=表2 .相同的列
等同于 select * from 表1 inner join 表2 using(相同的列);

对应比较好的参考using用到网址: https://blog.csdn.net/qq_38712932/article/details/82558805

最后采用了老大的代码。因为一个是二者都能匹配到索引，并且他那种在低版本也适用。另外就是in 数据越多可能会失效，所以感觉不是很好。

---

漫漫长路，一个小周跟他一个小陈朋友一起努力奔跑。

---