gpt4 book ai didi

尽管有索引,mysql select 查询还是很慢

转载 作者:行者123 更新时间:2023-11-29 07:09:04 24 4
gpt4 key购买 nike

好的,这是交易:

我有一个名为 Mails 的 4Gb 小表,我在上面执行以下两个查询:

SELECT * FROM Mails WHERE sent = 1 ORDER BY date ASC LIMIT 600;  // 200ms
SELECT * FROM Mails WHERE sent = 0 ORDER BY date ASC LIMIT 600; // >9000ms

发送类型之间的关系如下:

0    192070
1 1112341
2 11992
3 5369

创建语句是这样的:

CREATE TABLE `Mails` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`idMail` varchar(100) COLLATE utf8_bin NOT NULL,
`type` varchar(100) COLLATE utf8_bin DEFAULT NULL,
`idSender` varchar(100) COLLATE utf8_bin DEFAULT NULL,
`senderfName` varchar(100) COLLATE utf8_bin DEFAULT NULL,
`senderlName` varchar(100) COLLATE utf8_bin DEFAULT NULL,
`senderMail` varchar(100) COLLATE utf8_bin DEFAULT NULL,
`receiverMail` varchar(100) COLLATE utf8_bin DEFAULT NULL,
`reference` varchar(100) COLLATE utf8_bin DEFAULT NULL,
`mailContent` text COLLATE utf8_bin,
`mailSubject` varchar(100) COLLATE utf8_bin DEFAULT NULL,
`sent` int(1) unsigned DEFAULT '0',
`opened` int(1) unsigned DEFAULT '0',
`clicked` int(1) unsigned DEFAULT '0',
`completed` int(1) unsigned DEFAULT '0',
`abstract` varchar(100) COLLATE utf8_bin DEFAULT NULL,
`date` datetime DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `idMail` (`idMail`),
KEY `fk_type` (`type`),
KEY `fk_idSender` (`idSender`),
KEY `fk_senderMail` (`senderMail`),
KEY `fk_receiverMail` (`receiverMail`),
KEY `fk_sent` (`sent`),
KEY `fk_reference` (`reference`),
KEY `fk_date` (`date`)
) ENGINE=MyISAM AUTO_INCREMENT=1321784 DEFAULT CHARSET=utf8 COLLATE=utf8_bin$$

为什么“更重”的查询加载速度更快,或者实际上根本没有加载? self 线索:这都与 order-by 子句有关,因为没有日期排序,两者都快如闪电。坏事,我非常需要那个日期订购。我无法按 id 订购,因为邮件可以生成到 future ,我需要那些已经通过 NOW() 且尚未发送的邮件。

[编辑 2011-04-14]

关于 AJ 减速的正确答案可以在下面找到。我们解决这个问题的方法是创建一个联合索引

KEY `sent` (`sent`,`date`)

绝对解决了所有问题。

最佳答案

使用 EXPLAIN 确定 MySQL 如何缓冲排序结果:

http://dev.mysql.com/doc/refman/5.1/en/using-explain.html

如果您没有足够的排序缓冲区,它将使用磁盘上的临时空间,这会比较慢。另请参阅调整服务器参数和 myisam_sort_buffer_size:

http://dev.mysql.com/doc/refman/5.1/en/server-parameters.html

关于尽管有索引,mysql select 查询还是很慢,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/5652361/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com