问题来源
每个机票订单含有多个票，用符合条件的订单List，去查询对应的票List。
两张表的关联方式是用一个特性的key关联，其中包含，代理商区分标志，订单号，订单类型等，是一个长度在30~50之间的varchar
遍历list一条一条查的话，IO太多，显然不合适。我们就想到用in来实现批量查询
问题发现
在beta测试时，库中表里只有一个月的数据，大约在1000万左右，测试时没有发现问题。
到了线上之后，发现查询数据非常慢，两万左右的in条件，查询起来，时间在10分钟左右，显然出现了慢查询。
针对这个问题，做了几个测试，看了下执行计划，如下所示
数据量小，用了索引
事实上我们看到，在in语句中数据量不大的情况下，索引是有效的，不过这个数量已经是极限了。
使用前缀索引
下面是我的语句
explain
select *
from ticket
where order_key in ('1','2','3','4','5','6','7','8',... ,'15933');
数据量大，in使得索引失效
这里在in里面包含了三万条数据，索引实效了。
无法使用key
这里我们首先想到，强制使用索引会不会有所帮助如下
explain
select *
from ticket force index (uniq_order_key_ticket_id)
where order_key in ('1','2','3','4','5','6','7','8',... ,'29999');
但是，事实上并没有效果，这是结果
强制索引无效
解下来我们分析一下，两个问题，索引为什么会失效
这个问题需要从两个方面入手
1.索引区分度
2.预计扫描行数
3.优化器的选择
先看第一个，索引的区分度，经过随机采样，看着内容还是很高的。
show index from ticket
show index 统计区分度
预计扫描行数
预计扫描行数的话，如前两图所示，基本都走了全表扫描。
优化器的选择
优化器选择时，衡量了回表等操作，综合考虑，这里没有办法继续下去了，只能问到DBA了。
有用的结论
在数据表大时，索引负重较大，同样的情况下，in语句里面数据条数够大时，索引会失效，可以通过force index尝试一下，不过成功的可能行很小，尽量分批去查找，批次数量可配置。
