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

来源：互联网发布：同花顺编程公式编辑：程序博客网时间：2024/05/21 08:51

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

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

当只有20个值的情况

Java代码

| 1 | 0.00100000 | 顺序 in
| 2 | 0.00300100 | 顺序 n+1
| 3 | 0.02265800 | 随机 in
| 4 | 0.00201200 | 随机 n+1

|        1 | 0.00100000 | 顺序  in|        2 | 0.00300100 | 顺序  n+1  |        3 | 0.02265800 | 随机  in |        4 | 0.00201200 | 随机 n+1

当只有20个值的情况

Java代码

| 6 | 0.00124700 | 顺序 in
| 7 | 0.00614000 | 顺序 n+1
| 8 | 0.00431300 | 随机 in
| 9 | 0.00458700 | 随机 n+1

|        6 | 0.00124700 | 顺序 in  |        7 | 0.00614000 | 顺序 n+1  |        8 | 0.00431300 | 随机 in |        9 | 0.00458700 | 随机 n+1

当只有50个值的情况

Java代码

| 10 | 0.00125100 | 顺序 in
| 11 | 0.00926500 | 顺序 n+1
| 12 | 0.00769100 | 随机 in
| 13 | 0.01016400 | 随机 n+1

|       10 | 0.00125100 | 顺序 in |       11 | 0.00926500 | 顺序 n+1  |       12 | 0.00769100 | 随机 in|       13 | 0.01016400 | 随机 n+1

当只有200个值的情况

Java代码

| 15 | 0.00231500 | 顺序 in
| 16 | 0.06058700 | 顺序 n+1
| 17 | 0.01531700 | 随机 in
| 18 | 0.02295500 | 随机 n+1

|       15 | 0.00231500 | 顺序 in |       16 | 0.06058700 | 顺序 n+1|       17 | 0.01531700 | 随机 in |       18 | 0.02295500 | 随机 n+1

当只有500个值的情况

Java代码

| 1 | 0.00097000 | 顺序 in
| 2 | 0.00182400 | 顺序 n+1
| 3 | 0.00098000 | 随机 in
| 4 | 0.08855100 | 随机 n+1

|        1 | 0.00097000 | 顺序 in |        2 | 0.00182400 | 顺序 n+1|        3 | 0.00098000 | 随机 in |        4 | 0.08855100 | 随机 n+1

当只有1000个值的情况

Java代码

| 6 | 0.01431000 | 顺序 in
| 7 | 0.69286300 | 顺序 n+1
| 8 | 0.04851800 | 随机 in
| 9 | 0.16052700 | 随机 n+1

|        6 | 0.01431000 | 顺序 in |        7 | 0.69286300 | 顺序 n+1  |        8 | 0.04851800 | 随机 in|        9 | 0.16052700 | 随机 n+1

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

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