mysql中批量查询使用in还是n+1？

阅读更多

某日，在一LAMP群里，讨论这个，有些人倾向于in，有些人倾向n+1(用union组合结果)，还说是baidu的dba去他们公司培训说一定要使用n+1.。
其实，我看未必，使用in的话搜索只需走扫描一次索引就好了，因为是rang，从最小值扫到最大值。而使用n+1的话，每条sql都需从树根开始往下扫描，这样反而遍历的索引数多了。
所以，我的看法是，当值之间比较相近(顺序)的时候使用in，当值之间分隔比较远(随机)的话使用n+1。当然，只是猜测。

在一台机器上实验，存储引擎使用innodb，数据量1m条。

当只有20个值的情况

|        1 | 0.00100000 | 顺序  in
|        2 | 0.00300100 | 顺序  n+1  

|        3 | 0.02265800 | 随机  in 
|        4 | 0.00201200 | 随机 n+1

当只有20个值的情况

|        6 | 0.00124700 | 顺序 in  
|        7 | 0.00614000 | 顺序 n+1  

|        8 | 0.00431300 | 随机 in 
|        9 | 0.00458700 | 随机 n+1 

当只有50个值的情况

|       10 | 0.00125100 | 顺序 in 
|       11 | 0.00926500 | 顺序 n+1  

|       12 | 0.00769100 | 随机 in
|       13 | 0.01016400 | 随机 n+1

当只有200个值的情况

|       15 | 0.00231500 | 顺序 in 
|       16 | 0.06058700 | 顺序 n+1

|       17 | 0.01531700 | 随机 in 
|       18 | 0.02295500 | 随机 n+1

当只有500个值的情况

|        1 | 0.00097000 | 顺序 in 
|        2 | 0.00182400 | 顺序 n+1

|        3 | 0.00098000 | 随机 in 
|        4 | 0.08855100 | 随机 n+1

当只有1000个值的情况

|        6 | 0.01431000 | 顺序 in 
|        7 | 0.69286300 | 顺序 n+1  

|        8 | 0.04851800 | 随机 in
|        9 | 0.16052700 | 随机 n+1

当顺序的时候，和我猜测的一样，使用in快。
但是随机的时候，还是in快，具体原因没想明白，可能和值的随机性以及sql的解释有关。
如果，in快的原因没猜错的话，可以考虑用混合方式。

不过，我认为如果这类型的sql没给你带来很大的性能问题，就不要再上面浪费时间了。。