我有一个aurora数据库示例有一些性能问题。一个特别奇怪。我有一个wordpress安装与标准wp\u选项表。在这个表中，我在autoload列上添加了一个索引。架构如下：
CREATE TABLE IF NOT EXISTS `wp_options` (
`option_id` bigint(20) unsigned NOT NULL,
`option_name` varchar(64) NOT NULL DEFAULT '',
`option_value` longtext NOT NULL,
`autoload` varchar(20) NOT NULL DEFAULT 'yes'
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1045503 ;
ALTER TABLE `wp_options` ADD PRIMARY KEY (`option_id`), ADD UNIQUE KEY `option_name` (`option_name`), ADD KEY `index_autoload` (`autoload`);奇怪的是，我在慢日志中看到很多这样的查询：从wp\u options中选择option\u name，option\u value，其中autoload='yes'
它甚至可能需要一整分钟才能跑完。我每天都有很多。我得到的唯一提示是（相对）大量的行，即6602行。5913行有autoload='是'
表大小为26.2 mb
2条答案
按热度按时间1tu0hz3e1#
我很高兴你把数据库管理系统里的垃圾清理掉了。
您创建的索引没有帮助，因为它的基数非常低。在典型的wordpress安装中，该列只有两个可能的值。因此，查询规划器可能仍然会执行完整的表扫描并忽略索引。
对于那个特定的查询，一个稍微好一点的索引可能是
(autoload, option_name, option_value). 这是一个覆盖指数。完全可以通过索引满足查询，这在服务器上节省了一点时间。但对你来说可能不是。wordpress查询的部分性能影响来自将数据从dbms机器传输到wordpress主机的不可避免的时间开销。无论是dbms还是wordpress方面，再多的大铁也不会对此起到多大作用。
7uzetpgm2#
删除大量行的问题解决了