我有一个相当简单的进程在运行，它会定期拉取 RSS 提要并更新 MySQL 数据库中的文章。
articles 表现在已填充到大约 130k 行。对于找到的每篇文章，处理器都会检查该文章是否已存在。这些查询几乎总是需要 300 毫秒，而且大约每 10 或 20 次尝试，它们就会花费超过 2 秒。
SELECT id FROM `articles` WHERE (guid = 'http://example.com/feed.rss') LIMIT 1;
# Query_time: 2.754567 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0
我在 guid 列上有一个索引，但每当遇到新文章时，它就会添加到文章表中——使查询缓存失效(对吧？)。
慢速查询日志中的一些其他字段报告检查了 120 多行。
当然，在我的开发机器上，这些查询大约需要 0.2 毫秒。
该服务器是来自 Engine Yard Solo (EC2) 的虚拟主机，具有 1.7GB 内存和 EC2 目前随附的任何 CPU。
如有任何建议，我们将不胜感激。
更新
事实证明，问题出在椅子和键盘之间。
我在“id”上有一个索引，但查询的是“guid”。
在“guid”上添加索引使每次查询时间减少到 0.2 毫秒。
感谢大家提供的所有有用提示!
最佳答案
运行:
EXPLAIN SELECT id FROM `articles` WHERE (guid = 'http://example.com/feed.rss') LIMIT 1;
注意前面的EXPLAIN。这将告诉您 MySQL 在做什么。很难相信从索引中探测一行可能需要 2.7 秒，除非你的机器严重重载和/或颠簸。考虑到行数为 0，我猜 MySQL 进行了全表扫描但什么也没找到，这可能意味着您没有您认为的索引。
要回答您的其他问题，只要您对 articles 表进行任何更改，涉及该表的所有查询缓存条目都会失效。
关于mysql - 简单的 MySQL 查询需要 2 到 3 秒？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1298241/