所以我有一个基本上像 NoSQL 设置一样使用的表。结构是:
id bigint 主键 数据介质 block 修改时间戳
它有大约 35 万行。在其上运行的查询的结构如下:
从表中选择id=XXX的数据；
表引擎是InnoDB。我注意到有时针对此表运行的查询相当慢。有时他们需要 3 秒才能运行。该表在磁盘上有 3 GB，我给 innodb_buffer_pool_size 4G。
这里有什么我遗漏的吗？是否有任何我可以调整以提高性能的设置？
编辑:按要求解释输出:
+----+-------------+----------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+----------+-------+---------------+---------+---------+-------+------+-------+
| 1 | SIMPLE | cache | const | PRIMARY | PRIMARY | 8 | const | 1 | |
+----+-------------+----------+-------+---------------+---------+---------+-------+------+-------+
创建表:
CREATE TABLE `cache` (
`id` bigint(20) unsigned NOT NULL DEFAULT '0',
`data` mediumblob,
`modified` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
最佳答案
我最初在这里看到两个问题。首先是您有一个 blob 数据类型的查询。当涉及到数据检索时，这将导致速度问题。其次，您正在使用针对写入进行了优化的 InnoDB。这意味着虽然它可能是总体上最好的选择，但在极端读取情况下，它的性能可能不如 MyISAM。这些问题都不一定是交易 killer ，但它们都会增加性能损失。但是，除此之外，我不确定我能否给您一个很好的答案，说明您可以做些什么来更好地优化，而无需先进行分析。这就是我建议你首先做的。分析您的查询以找出执行计划是什么，然后确定执行计划为何如此缓慢。
这是一个很好的 MySQL 优化的“前 10 名”列表。至少有一对夫妇直接申请您的情况:
http://20bits.com/articles/10-tips-for-optimizing-mysql-queries-that-dont-suck/
这是另一篇关于服务器设置的优秀优化文章(特别针对 InnoDB):
http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/
根据您提供的 CREATE TABLE 语句，我确实想到了您应该解决的另一件事(同样，这不是查询 killer ，但它是另一个性能损失)。除非有将 bigint 用于您的 ID 字段的业务案例，否则请选择 int。一个 int 将允许 21 亿行，所以你不应该用完数字。进行此切换将节省磁盘空间并提高查询性能。这是一篇关于它的文章:
http://ronaldbradford.com/blog/bigint-v-int-is-there-a-big-deal-2008-07-18/
关于MySQL查询慢查询主键上的表，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6209836/