某日,在一LAMP群里,讨论这个,有些人倾向于in,有些人倾向n+1(用union组合结果),还说是baidu的dba去他们公司培训说一定要使用n+1.。
其实,我看未必,使用in的话搜索只需走扫描一次索引就好了,因为是rang,从最小值扫到最大值。而使用n+1的话,每条sql都需从树根开始往下扫描,这样反而遍历的索引数多了。
所以,我的看法是,当值之间比较相近(顺序)的时候使用in,当值之间分隔比较远(随机)的话使用n+1。当然,只是猜测。
在一台机器上实验,存储引擎使用innodb,数据量1m条。
当只有20个值的情况
当只有20个值的情况
当只有50个值的情况
当只有200个值的情况
当只有500个值的情况
当只有1000个值的情况
当顺序的时候,和我猜测的一样,使用in快。
但是随机的时候,还是in快,具体原因没想明白,可能和值的随机性以及sql的解释有关。
如果,in快的原因没猜错的话,可以考虑用混合方式。
不过,我认为如果这类型的sql没给你带来很大的性能问题,就不要再上面浪费时间了。。
其实,我看未必,使用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没给你带来很大的性能问题,就不要再上面浪费时间了。。