0

我有一个存在一些性能问题的 Aurora 数据库实例。一个特别奇怪。我有一个带有标准 wp_options 表的 WordPress 安装。在此表中，我在自动加载列上添加了一个索引。架构如下：

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`);

奇怪的是我在慢日志中看到很多这样的查询： SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'

它甚至可能需要一整分钟才能运行。我每天都有很多这样的。我唯一的提示是（相对）大量的行，即 6602 行。5913 行有 autoload = 'yes'

表大小为 26.2 MB

4

2 回答 2

1

我很高兴你从你的 dbms 中清除了垃圾。

您创建的索引无济于事，因为它的基数非常低。在典型的 WordPress 安装中，该列只有两个可能的值。因此，查询计划器可能仍会进行全表扫描并忽略索引。

该特定查询的稍微好一点的索引可能是(autoload, option_name, option_value). 那是一个覆盖指数。查询可以完全从索引中得到满足，这在服务器上节省了一些时间。但可能不是你的情况。

对 WordPress 查询的部分性能影响来自将数据从 DBMS 机器传输到 WordPress 主机不可避免的时间成本。DBMS 或 WordPress 方面的任何大铁都不会为此做太多事情。

于 2016-10-05T19:06:30.607 回答
0

问题解决了删除很多很多行

于 2016-10-05T15:05:17.237 回答