不等于Where子句使用Filesort，但不等于。为什么？

我正在修改我的网站的内部邮件系统，并且遇到了一些我不明白的东西。下面是表：不等于Where子句使用Filesort，但不等于。为什么？

CREATE TABLE `mails` (
    `id` bigint(12) unsigned not null auto_increment, 
    `recipient_id` mediumint(8) unsigned not null, 
    `date_sent` datetime not null, 
    `status` enum('unread', 'read', 'deleted') default 'unread', 
    PRIMARY KEY(`id`), 
    INDEX(`recipient_id`, `status`, `date_sent`), 
    CONSTRAINT FOREIGN KEY (`recipient_id`) REFERENCES `members` (`id`) ON DELETE CASCADE 
) ENGINE=InnoDB; 

CREATE TABLE `mail_contents` (
    `mail_id` bigint(12) unsigned not null, 
    `sender_id` mediumint(8) unsigned not null, 
    `subject` varchar(150) default '', 
    `content` text not null, 
    CONSTRAINT FOREIGN KEY (`sender_id`) REFERENCES `members` (`id`) ON DELETE CASCADE, 
    CONSTRAINT FOREIGN KEY (`mail_id`) REFERENCES `mails` (`id`) ON DELETE CASCADE 
) ENGINE=InnoDB;

而这里的查询：

SELECT * 
FROM mails AS m 
LEFT JOIN mail_contents AS mc ON mc.mail_id = m.id 
WHERE recipient_id = 66 
AND status != 'deleted' 
ORDER BY date_sent DESC 
LIMIT 40\G

的EXPLAIN的查询显示“使用，其中，使用索引;使用文件排序”。但是，如果我将查询更改为：

SELECT * 
FROM mails AS m 
LEFT JOIN mail_contents AS mc ON mc.mail_id = m.id 
WHERE recipient_id = 66 
AND status = 'sent' 
ORDER BY date_sent DESC 
LIMIT 40\G

EXPLAIN显示“使用where;使用索引”。出于某种原因，在第一个查询中使用！=会导致一个filesort，但在第二个查询中使用=不会使用filesort。我很好奇发生了什么事情会导致差异？

来源

2011-05-24 mellowsoon

等于包容，！=是排他性的。 MySQL更有效地找到包容性结果。

“使用的filesort”在这种情况下实际上是负的，因为这意味着查询需要使用临时表来排序（表作为文件），然后返回结果..

来源

2011-05-24 00:41:48 dtbarne

我总是假设filesort是负的。我很好奇为什么包容性和排他性的运营商会做出这样的改变。 – mellowsoon 2011-05-24 01:35:54

的INDEX(recipient_id，status，date_sent）在用于排序的第二查询时，由于第一列2是固定的，并且由顺序使用第三一个date_sent =>无filesort

它不能在第一个查询中使用，因为status不是常量（!= 'deleted'）。

更多的信息在这里：ORDER BY Optimization

来源

2011-05-24 00:49:21 manji

不等于Where子句使用Filesort，但不等于。为什么？

回答

相关问题