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