in 会不会走索引？很多人肯定会回答、废话、如果命中了索引、那肯定会走。
其实我和大多数人一样、一开始也是这么想的、直至有一个血淋淋的案子让我有所改观、有所思考。
业务的工单表、我们分了64张、以userId作为分表键、业务实际场景中未使用到搜索引擎、主要是一些B端业务。
业务有一个场景是使用userId作为条件 使用in语句查询工单数据。
这里分析一下、
该需求上线之后、我们发现个别B端使用人员、他需要查询userId为5w左右的条件查询、经日志查询该查询的耗时大概在35S左右、正常查询都是3S以内。当问题发生的时候、我就在分析、in 到底有没有走索引、如下
综合以上初步判断、这么小的量、如果命中索引、那不该需要查询这么长的时间。
既然出现了问题、那肯定是要解决方案的、思考的角度如下：
这里我基于第三点的假设、对于业务代码进行了改造
使用in条件进行查询
限制了每次查询数据库in所包含的userId个数最多是5000个、即时就是我们经常说的批量查询、这样子做、最大量的5w就会分成10批去查询数据库、结果再聚合。而分到每张表的in包含的个数、按平均情况就只有了78个左右了、改成这种写法、从宏观的角度、就是把DB的一部分压力转移到业务服务器上。
新的代码拿到正式环境进行验证之后、使用同样的用户进行测试、in的条件个数仍是5w、但最后的查询结果仅在3S左右就返回了、完成了从35S到3S的质的飞跃的提升。
对于解决问题而言、我们已经是成功的Solver、We are white cat or black cat.
But 这里有仍有两个疑问、
批次的数量具体是哪个值合适2k or 5k、这里我的5k值是与我的正常业务的水平相一致的、所以我说是适合我的、但并不是适合所有场景、所有人。
从最后的结果提升来看、我更倾向于改造后的代码既是走了索引、也为DB减少了压力、才会有这么高的性能提升。