Question

我有一张书桌：

CREATE TABLE `books` (
    `id` INT(11) NOT NULL AUTO_INCREMENT,
    `nameOfBook` VARCHAR(32),
    `releaseDate` DATETIME NULL DEFAULT NULL,
    PRIMARY KEY (`id`),
    INDEX `Index 2` (`releaseDate`, `id`)
)
COLLATE='latin1_swedish_ci'
ENGINE=InnoDB

AUTO_INCREMENT = 33029692;

我将两个SQL请求与releaseDate上的sort进行了比较。这两个请求都返回相同的结果。

（简单的）

select SQL_NO_CACHE  id,name, releaseDate  
from books  
where releaseDate <= '2016-11-07'  
AND (releaseDate<'2016-11-07' OR id <    3338191)  
ORDER  by releaseDate DESC, id DESC limit 50;

和

（元组比较或行比较）

select SQL_NO_CACHE  id,name, releaseDate 
from books 
where (releaseDate ,id) < ('2016-11-07',3338191) 
ORDER  by releaseDate DESC, id DESC limit 50;

当我解释请求时，我得到了这个

简单的一个：

"id";"select_type";"table";"type";"possible_keys";"key";"key_len";"ref";"rows";"Extra"
"1";"SIMPLE";"books";"range";"PRIMARY,Index 2";"Index 2";"9";"";"1015876";"Using where; Using index"

我们可以看到它正在解析行的“1015876”

元组比较的解释：

"id";"select_type";"table";"type";"possible_keys";"key";"key_len";"ref";"rows";"Extra"
"1";"SIMPLE";"books";"index";"";"Index 2";"13";"";"50";"Using where; Using index"

我们可以看到它正在解析“50”行。

但如果我检查了exectution时间那么简单：

* Affected rows: 0  Lignes trouvées: 50  Avertissements: 0  Durée pour 1 query: 0,031 sec. */

和元组：

/* Affected rows: 0  Lignes trouvées: 50  Avertissements: 0  Durée pour 1 query: 3,682 sec. */

我不明白为什么根据解释，元组比较更好但执行时间差得多？

Answer 1

多年来，我一直对此感到恼火。 WHERE (a,b) > (1,2)从未被优化过，尽管它很容易转化为另一种表述。直到几年前，即使是其他格式也未得到很好的优化。

使用EXPLAIN FORMAT=JSON SELECT ...可能会为您提供更好的线索。

与此同时，EXPLAIN忽略了LIMIT并建议了1015876.在许多情况下，EXPLAIN提供了一个体面的＆＃34;行估计，但不是其中任何一个。

随意提交错误报告：http://bugs.mysql.com（并在此处发布链接）。

尽管OR在历史上无法优化，但最近对其他配方进行了优化。

where  releaseDate <  '2016-11-07'  
   OR (releaseDate  = '2016-11-07' AND id < 3338191)

为了测量查询优化，我喜欢这样做：

FLUSH STATUS;
SELECT ...
SHOW SESSION STATUS LIKE 'Handler%';

小值，例如＆＃39; 50＆＃39;对于您的情况，表明良好的优化;大值（1M）表示扫描。处理程序编号是准确的;与EXPLAIN中的估算值不同。

更新 5.7.3改进了对元组的处理，又称＆＃34;行构造函数＆＃34;

在mysql中使用元组比较是否有效？

1 个答案: