0

我已经在 Amazon EC2（新加坡地区）上发布了我的网站，并且我在同一地区使用了 MySQL RDS 介质实例进行数据存储。

就我而言，大多数选择查询都有一些 COUNT 功能。这些查询显示的结果非常缓慢。我已经在表上创建了适当的索引，并检查了 EXPLAIN 命令来分析这些查询。它向我表明，要获得结果，必须进行全表扫描。

在我的 RDS 介质实例上，我使用以下设置配置了自定义参数组。

log_queries_not_using_index = true,
slow_query_log = true,
long_query_time = 2 sec,
max_connections = 303,
innodb_buffer_pool_size = {DBInstanceClassMemory*3/4}

昨天我的 CPU 利用率超过 95%，我的网站因此而崩溃。客流量没有大的增加。

此外，我将数据转储到本地系统上，并测试了其中一个 COUNT 查询。它在 RDS 上运行大约需要 1.5 秒，而在我的本地系统上运行只需要大约 400 毫秒。我的本地系统（4GB RAM，Intel core 2 duo 2.8GHz）上的配置是：

max_connections = 100,
slow_query_log = true,
long_query_time = 2 sec,
innodb_buffer_pool_size = 72351744

那么，导致 CPU 使用率飙升以及 RDS 与我的本地系统之间的性能时间差异的原因可能是什么？

谢谢，

4

1 回答 1

1

根据表的大小 - RDS 实例使用 EBS 来存储数据 - 如果您正在执行表扫描并且它必须从 EBS 而不是本地缓存的内存中的键获取数据然后扫描它。所以 - 您可能会看到 CPU 所在的 RDS 实例与 SAN 中的 EBS 数据之间的网络延迟增加。当您在本地计算机上执行相同的查询时，唯一的滞后是磁盘磁头寻道时间。

然后是 CPU 时间之间的差异 - 根据 Amazon 对 EC2 单元的定义，m1.medium 的 CPU 时间比 core2 duo 少（因此扫描结果的机会也更少）。

HTH - 一般来说，我会尽量避免在您的查询中执行 COUNT(s)，因为这是一个非常低效的查询（如您所见），当数据库处于真实状态时，它可能并且将继续导致令人讨厌的不希望的结果-随时间变化的负载水平。

R

于 2013-06-10T11:42:34.300 回答