Sco*_*ott 169 mysql sql optimization performance
我想知道下列之间在性能方面是否有任何差异
SELECT ... FROM ... WHERE someFIELD IN(1,2,3,4)
SELECT ... FROM ... WHERE someFIELD between 0 AND 5
SELECT ... FROM ... WHERE someFIELD = 1 OR someFIELD = 2 OR someFIELD = 3 ...
或者MySQL会像编译器优化代码一样优化SQL吗？
编辑:由于评论中陈述的原因,将's 更改为AND's OR.
Cyr*_*ril 242
我肯定需要知道这一点,所以我对这两种方法进行了基准测试.我坚持认为IN比使用更快OR.
不要相信那些给出"意见"的人,科学就是测试和证据.
我运行了1000x等效查询的循环(为了保持一致性,我用过sql_no_cache):
IN:2.34969592094s
OR:5.83781504631s
更新:(
我没有原始测试的源代码,因为它是6年前,虽然它返回的结果与此测试的范围相同)
在请求一些示例代码来测试它时,这是最简单的用例.使用Eloquent简化语法,原始SQL等价物执行相同的操作.
$t = microtime(true);
for($i=0; $i<10000; $i++):
$q = DB::table('users')->where('id',1)
->orWhere('id',2)
->orWhere('id',3)
->orWhere('id',4)
->orWhere('id',5)
->orWhere('id',6)
->orWhere('id',7)
->orWhere('id',8)
->orWhere('id',9)
->orWhere('id',10)
->orWhere('id',11)
->orWhere('id',12)
->orWhere('id',13)
->orWhere('id',14)
->orWhere('id',15)
->orWhere('id',16)
->orWhere('id',17)
->orWhere('id',18)
->orWhere('id',19)
->orWhere('id',20)->get();
endfor;
$t2 = microtime(true);
echo $t."\n".$t2."\n".($t2-$t)."\n";
1482080514.3635
1482080517.3713
3.0078368186951
$t = microtime(true);
for($i=0; $i<10000; $i++):
$q = DB::table('users')->whereIn('id',[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20])->get();
endfor;
$t2 = microtime(true);
echo $t."\n".$t2."\n".($t2-$t)."\n";
1482080534.0185
1482080536.178
2.1595389842987
Erg*_*gec 65
我也为未来的Google员工做过测试.返回结果的总数是10000中的7264
SELECT * FROM item WHERE id = 1 OR id = 2 ... id = 10000
此查询耗时0.1239数秒
SELECT * FROM item WHERE id IN (1,2,3,...10000)
此查询耗时0.0433数秒
IN 是快3倍 OR
bea*_*ach 16
我认为BETWEEN会更快,因为它应该被转换成:
Field >= 0 AND Field <= 5
我的理解是无论如何IN都将被转换为一堆OR语句.IN的值是易用性.(节省必须多次键入每个列名并使其更容易与现有逻辑一起使用 - 您不必担心AND/OR优先级,因为IN是一个语句.使用一堆OR语句,您有确保用括号括起它们,以确保它们被评估为一个条件.)
您问题的唯一真正答案是查询您的查询.然后你就会知道在你的特殊情况下哪种方法最有效.
Fra*_*k V 11
这取决于你在做什么; 范围有多宽,数据类型是什么(我知道你的例子使用数字数据类型,但你的问题也适用于很多不同的数据类型).
这是一个你想要双向编写查询的实例; 让它工作,然后使用EXPLAIN来找出执行差异.
我确信这个问题有一个具体的答案,但实际上,这就是我想出的问题.
这可能会有所帮助:http://forge.mysql.com/wiki/Top10SQLPerformanceTips
问候,
弗兰克
我认为sunseeker观察的一个解释是MySQL实际上对IN语句中的值进行排序,如果它们都是静态值并且使用二进制搜索,这比普通的OR替代更有效.我不记得我读过哪里,但是sunseeker的结果似乎是一个证据.
小智 7
接受的答案没有说明原因。
下面引用了高性能MySQL第三版。
在许多数据库服务器中，IN（）只是多个OR子句的同义词，因为两者在逻辑上是等效的。在MySQL中不是这样，MySQL对IN（）列表中的值进行排序，并使用快速二进制搜索来查看列表中是否包含值。列表的大小为O（Log n），而等效的OR子句序列的列表的大小为O（n）（即，大列表的速度慢得多）
就在你以为安全的时候……
你的价值是eq_range_index_dive_limit什么？特别是，您在IN子句中的条目是更多还是更少？
这将不包括基准测试，但会深入了解内部工作原理。让我们使用一个工具来看看发生了什么——Optimizer Trace。
查询： SELECT * FROM canada WHERE id ...
使用OR3 个值，跟踪的一部分看起来像：
"condition_processing": {
"condition": "WHERE",
"original_condition": "((`canada`.`id` = 296172) or (`canada`.`id` = 295093) or (`canada`.`id` = 293626))",
"steps": [
{
"transformation": "equality_propagation",
"resulting_condition": "(multiple equal(296172, `canada`.`id`) or multiple equal(295093, `canada`.`id`) or multiple equal(293626, `canada`.`id`))"
},
...
"analyzing_range_alternatives": {
"range_scan_alternatives": [
{
"index": "id",
"ranges": [
"293626 <= id <= 293626",
"295093 <= id <= 295093",
"296172 <= id <= 296172"
],
"index_dives_for_eq_ranges": true,
"chosen": true
...
"refine_plan": [
{
"table": "`canada`",
"pushed_index_condition": "((`canada`.`id` = 296172) or (`canada`.`id` = 295093) or (`canada`.`id` = 293626))",
"table_condition_attached": null,
"access_type": "range"
}
]
注意 ICP 是如何给出的ORs。这意味着这OR是不是变成IN，和InnoDB将表演一堆=通过ICP测试。（我觉得不值得考虑 MyISAM。）
（这是 Percona 的 5.6.22-71.0-log；id是二级索引。）
现在 IN() 有几个值
eq_range_index_dive_limit= 10; 有 8 个值。
"condition_processing": {
"condition": "WHERE",
"original_condition": "(`canada`.`id` in (296172,295093,293626,295573,297148,296127,295588,295810))",
"steps": [
{
"transformation": "equality_propagation",
"resulting_condition": "(`canada`.`id` in (296172,295093,293626,295573,297148,296127,295588,295810))"
},
...
"analyzing_range_alternatives": {
"range_scan_alternatives": [
{
"index": "id",
"ranges": [
"293626 <= id <= 293626",
"295093 <= id <= 295093",
"295573 <= id <= 295573",
"295588 <= id <= 295588",
"295810 <= id <= 295810",
"296127 <= id <= 296127",
"296172 <= id <= 296172",
"297148 <= id <= 297148"
],
"index_dives_for_eq_ranges": true,
"chosen": true
...
"refine_plan": [
{
"table": "`canada`",
"pushed_index_condition": "(`canada`.`id` in (296172,295093,293626,295573,297148,296127,295588,295810))",
"table_condition_attached": null,
"access_type": "range"
}
]
请注意，IN似乎没有变成OR.
旁注：请注意，常量值已排序。这在两个方面是有益的：
最后，IN() 有很多值
{
"condition_processing": {
"condition": "WHERE",
"original_condition": "(`canada`.`id` in (293831,292259,292881,293440,292558,295792,292293,292593,294337,295430,295034,297060,293811,295587,294651,295559,293213,295742,292605,296018,294529,296711,293919,294732,294689,295540,293000,296916,294433,297112,293815,292522,296816,293320,293232,295369,291894,293700,291839,293049,292738,294895,294473,294023,294173,293019,291976,294923,294797,296958,294075,293450,296952,297185,295351,295736,296312,294330,292717,294638,294713,297176,295896,295137,296573,292236,294966,296642,296073,295903,293057,294628,292639,293803,294470,295353,297196,291752,296118,296964,296185,295338,295956,296064,295039,297201,297136,295206,295986,292172,294803,294480,294706,296975,296604,294493,293181,292526,293354,292374,292344,293744,294165,295082,296203,291918,295211,294289,294877,293120,295387))",
"steps": [
{
"transformation": "equality_propagation",
"resulting_condition": "(`canada`.`id` in (293831,292259,292881,293440,292558,295792,292293,292593,294337,295430,295034,297060,293811,295587,294651,295559,293213,295742,292605,296018,294529,296711,293919,294732,294689,295540,293000,296916,294433,297112,293815,292522,296816,293320,293232,295369,291894,293700,291839,293049,292738,294895,294473,294023,294173,293019,291976,294923,294797,296958,294075,293450,296952,297185,295351,295736,296312,294330,292717,294638,294713,297176,295896,295137,296573,292236,294966,296642,296073,295903,293057,294628,292639,293803,294470,295353,297196,291752,296118,296964,296185,295338,295956,296064,295039,297201,297136,295206,295986,292172,294803,294480,294706,296975,296604,294493,293181,292526,293354,292374,292344,293744,294165,295082,296203,291918,295211,294289,294877,293120,295387))"
},
...
"analyzing_range_alternatives": {
"range_scan_alternatives": [
{
"index": "id",
"ranges": [
"291752 <= id <= 291752",
"291839 <= id <= 291839",
...
"297196 <= id <= 297196",
"297201 <= id <= 297201"
],
"index_dives_for_eq_ranges": false,
"rows": 111,
"chosen": true
...
"refine_plan": [
{
"table": "`canada`",
"pushed_index_condition": "(`canada`.`id` in (293831,292259,292881,293440,292558,295792,292293,292593,294337,295430,295034,297060,293811,295587,294651,295559,293213,295742,292605,296018,294529,296711,293919,294732,294689,295540,293000,296916,294433,297112,293815,292522,296816,293320,293232,295369,291894,293700,291839,293049,292738,294895,294473,294023,294173,293019,291976,294923,294797,296958,294075,293450,296952,297185,295351,295736,296312,294330,292717,294638,294713,297176,295896,295137,296573,292236,294966,296642,296073,295903,293057,294628,292639,293803,294470,295353,297196,291752,296118,296964,296185,295338,295956,296064,295039,297201,297136,295206,295986,292172,294803,294480,294706,296975,296604,294493,293181,292526,293354,292374,292344,293744,294165,295082,296203,291918,295211,294289,294877,293120,295387))",
"table_condition_attached": null,
"access_type": "range"
}
]
旁注：由于跟踪量很大，我需要这个：
@@global.optimizer_trace_max_mem_size = 32222;
| 归档时间： |
|
| 查看次数： |
72552 次 |
| 最近记录： |