mysql in条件内容过多时处理

mysql的in条件查询，是括号里拼接逗号相隔的字串，这个字长里的个数还有限制，网上的说法是1000个，为了避免超出该范围，可专门封装一个方法 1.使用exists写法替代in写法，exists写法是使用条件查询替代in写法里的一长串字串，这个有时候没法使用，比如使用第三方接口查学校一年级2千个学生的考试成绩，你只知道这些学生的id，没有更多的关联条件 2.使用or的写法，将in条件过长的字串拆开，mysql支持以下写法： 方法封装： 测试效果：

in作为查询条件，一般典型有两种用法：一是IN常量，例如下面语句查询一、三年级的学生：SELECT * FROM student WHERE grade IN ('一','三')二是使用子查询，也就是IN（SQL语句），例如下面的语句查询不及格的班级的所有学生：SELECT * FROM student WHERE classno IN (select classno from scores where score<60)

MySQL中使用IN会不会走索引

文章很短，先看下结论，在看下文。

结论：IN肯定会走索引，但是当IN的取值范围较大时会导致索引失效，走全表扫描

navicat可视化工具使用explain函数查看sql执行信息

场景1：当IN中的取值只有一个主键时

我们只需要注意一个最重要的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认为它执行查询时必须检查的行数。

这里可以参考之前写的一篇：用MySQL 执行计划分析 DATE_FORMAT 函数对索引的影响

场景2：扩大IN中的取值范围

此时仍然走了索引，但是效率降低了

场景3：继续扩大IN的取值范围

看上面的图，发现此时已经没有走索引了，而是全表扫描。

在说一下结论

结论：IN肯定会走索引，但是当IN的取值范围较大时会导致索引失效，走全表扫描。

By the way：如果使用了 not in，则不走索引。

---