我正在开发一个 Web 应用程序，并且在我的开发环境和实际环境中遇到了 MySQL 查找速度之间的巨大性能差异。
数据库： 2.5GB，三张表（一张表有2700万条记录）。全文索引和搜索。所有内容都在需要的地方建立了索引。数据库包含英国所有地址的记录。
开发服务器： 使用两年的三星 i5 Ultrabook。运行 XAMPP 的 Windows 8。单SSD。大多数查找时间不到 200 毫秒，故意给系统施加压力，导致最大查找时间为 5 秒。
实时服务器： “混合”VPS（每台服务器最多 8 个节点）。硬件规格为“双 Intel Xeon 处理器，至少 8 个 CPU 内核、24GB RAM、带有 15K SAS 驱动器的 Raid 10 驱动器”。大多数查找大约需要 3-5 秒，压力测试导致查找时间为 30 秒。
我对开发服务器上的数据库性能感到满意，但我确实需要生产服务器来匹配或更好。
在我为应用程序购买专用盒子之前，根据您的经验，瓶颈可能是磁盘 I/O 还是 CPU 时间？
只是发布一个答案作为记录：
我在带有 RAID-ed SSD 的 VPS 上尝试了该应用程序。区别在于白天和黑夜，查找现在甚至比我的开发机器更快。这是默认的 MySQL 安装，没有对缓存、最大内存使用量和其他参数进行任何编辑。
暂时忽略 MySQL - 这对于所有数据库都是相同的。物理学不关心开源。
一般来说，您是 IO 受限的，除非您不是。最后意味着有足够的 RAM 来缓存内存中的所有 IO 操作 - 这对于大型 OLAP 工作负载来说是典型的。但是任何事务性的IO都会比CPU更早地受到限制，除非CPU很糟糕（即你总是可以构建一个强制CPU过载的服务器——原子对于数据库服务器来说可能是一个糟糕的选择）。
哦，生产服务器。有人在购买这个产品时犯了“愚蠢”的错误。
带 15K SAS 驱动器的 Raid 10 驱动器”。
每个驱动器大约 450 IOPS。
单SSD
这大约是 40.000 到 60.000 IOPS - 最高可达 90.000，具体取决于光盘和负载。
看到问题了吗？SSD 正在围绕 SAS 磁盘飞翔 - 它改变了游戏规则。SAS 速度很慢。我在主数据库中使用了大量 10k SAS 磁盘 - 但使用 SSD 作为透明缓存层。
因此，除非您有足够的 RAM 使 SAS 光盘变得无关紧要（将所有内容缓存在内存中），然后预加载（这在只有 2.5g 的小型数据库上是可行的）……它是 IO 绑定的。
在您的特定情况下，我会检查配置。MySQL 标准配置不会使用 IIRC 大量内存，无论它是否存在。对于小型数据库（2.5g），您应该将其全部缓存在内存中。即使在笔记本电脑上也是如此。看起来像是配置问题。