经过几天的研究，我在 c1.medium 实例、Amazon Linux 上建立了一个网站，在 db.m1.instance 上建立了 MySQL 数据库。RDS 运行的是 MySQL 版本 5.6.13。我为数据库实例分配了 100 GB，并将提供的 IOPS 设置为 1,000。该网站以照片为基础，允许用户上传，高峰时段有 400 多名访客。
启用慢查询日志记录后，我发现问题似乎出在 wp_options 表上，当我查看 phpmyadmin 时，我发现其中包含有关 WordPress 插件和主题的信息。例如：
设置时间戳=1390186963；
从 wp_options 中选择选项名称、选项值，其中自动加载 = 'yes'；
时间：140120 3:04:17
用户@主机：xxxx ID：744
查询时间：49.248039 锁定时间：0.000180 发送行数：485 检查行数：538
在试验了几个数据库参数后，我将 query_cache_type 设置为 1，将 query_cache_size 设置为 64MB。我希望启用缓存可以阻止数据库重复调用 wp_options 表，但不幸的是，情况似乎并非如此。有什么建议吗？接下来要采取什么步骤来找出此问题的原因？查看 CloudWatch 指标时，硬件似乎足够，但可能不够？
以下是两个实例的 CloudWatch 指标的屏幕截图。
答案1
Query_time: 49.248039 Lock_time: 0.000180 Rows_sent: 485 Rows_examined: 538
从您的慢查询日志来看，这意味着执行此查询花费了 49 秒。尝试运行
CREATE INDEX wp_options_autoload ON wp_options (autoload);
然后尝试再次加载您的页面。
虽然表中只有 538 行，但这是一个极其该查询运行的时间很长。
答案2
1,000 IOPS 的配置实在是太多了。
当您在磁盘上进行大量读取/写入时，IOPS 会变得有趣。Wordpress 应该使用 90% 的读取和 10% 的写入。您应该大多数时间都使用内存缓存。
如果您的数据库和查询设置正确，则不需要那么多 IOPS。
考虑到使用 Wordpress 的人数（我不知道那个特定的插件）我敢打赌查询配置正确。
RDS 仅限于 InnoDB 引擎。该引擎依赖一个名为 innodb_buffer_pool_size 的参数来在内存中缓存数据。这是首先需要注意的。幸运的是，这个值是由 RDS 自动设置的（RDS 实例内存的一个因素）。
49 毫秒并不算慢。我敢打赌你的问题在别处。尝试一个可以分析你的慢查询（对它们进行排序和聚合）的工具：http://www.percona.com/doc/percona-toolkit/2.2/pt-query-digest.html
获取慢查询日志文件： http://www.palominodb.com/blog/2011/10/20/exporting-mysqlslowlog-table-slow-query-log-format
大多数情况下，您不需要使用 query_cache 参数。如果设置的值太大，甚至可能会影响性能（每次更改数据时，您都需要使受影响的相应查询的缓存无效）。
最后，Cloudwatch 图表显示您的数据库处于休眠状态，但您的 Web 服务器使用了过多的 CPU。
这里的瓶颈肯定不是您的数据库。
答案3
您可以将 wp_options 更改为 MEMORY 类型。为此，您需要将任何 blob 转换为大型 varchar 并增加 RDS 中的堆大小。
然而，通过在 WordPress 前面放置一个缓存服务器来消除请求来解决这个问题可能更明智。