旧版 SQL Express 2005 运行在低端单 Xeon CPU Dell 服务器、RAID 5 7200 磁盘、2 GB RAM（SBS 2003）上。
我没有对旧的物理服务器进行任何基线测量，但有六个人（可能同时有 2 个人）使用该 Web 应用程序，所以我想“Amazon EC2 实例能有多糟糕？”。
这真是太可怕了：一个屏幕上的加载时间竟然相差 8 秒。
首先，我不是 SQL 专家，但这是我尝试过的方法：
有一个小型实例，现在运行 c1.medium（高 CPU 中）Windows 2008 32 位 R2 EBS 支持的实例，运行 IIS 7.5 和 SQL Express 2008 R2。没有明显的改善。
将页面文件从固定 256 更改为自动。
在磁盘管理中设置带区镜像，其中附加了两个 1 GB EBS 卷。移动数据库和事务日志，其余所有内容留在启动 EBS 卷上。没有明显的变化。
查看内存，大约有 1000 MB 的物理内存可用（总共 1.7 GB）。将 SQL 实例更改为使用至少 1024 RAM；重新启动服务器，内存使用情况没有变化。SQL 仍然只使用大约 28MB 的 RAM（！）。
所以我在想：这个数据库很小（28MB），为什么不把整个东西都缓存在 RAM 中？这肯定会提高性能。事务日志是 241 MB。相比之下似乎有点大——这还没有提交吗？这是性能下降的原因吗？我记得在旅行中曾提到过一些关于恢复模型和日志大小的事情，但不是肯定的。
还有一件事：旧服务器正在运行 SQL Express 2005。不确定这是否有任何影响，但我尝试将兼容级别从 SQL 2000 更改为 2008，但没有效果。
无论如何，我还能在这里尝试什么？在这个东西上投入更多虚拟硬件似乎很荒谬。我知道 I/O 对 EBS 卷来说会很困难，但其他人肯定能在价格合理的实例上成功运行小型 .NET/SQL 应用程序？
答案1
每当我升级数据库时（至少十二年来我一直这么做），我恢复数据库后要做的第一件事就是重新索引所有表。在允许任何人使用数据库之前，我都会这样做。重新索引很简单，在比 2005 年的笔记本电脑更快的计算机上，只需几秒钟就可以重新索引 28 MB 的数据。
确保数据库设置为 AUTOCLOSE = FALSE。某些环境默认将其设置为 TRUE，这对于任何生产服务器来说都是错误的。
正如 cmenke 所说，除非您使用时间点恢复策略，否则您应该将数据库设置为 SIMPLE 恢复模式。SBS 服务器上的数据库是否设置为 SIMPLE 恢复模式？
EC2 上的数据库是否具有与旧数据库相同的索引？您没有提到如何移动数据，因此我们不知道您是否进行了备份和恢复、使用了复制数据库向导还是编写了自己的 SSIS 包。某些移动数据库的方法不会保留索引。对于任何试图在服务器之间移动数据库的本答案的未来读者，您应该始终尝试使用 BACKUP/RESTORE 或复制 MDF 和 LDF 文件。除了最简单的数据库之外，对所有数据库使用 SSIS/DTS 会让您发疯。
如果数据库仍然很慢，请启动 SQL Profiler（在服务器上，而不是在桌面上）并捕获少量流量。问题是一个大而慢的 SQL 语句还是很多很多小 SQL 语句？第一页发出了多少条 SQL 语句？
请记住，您已经对 SQL Server 进行了大量更改，但没有看到任何行为变化。也许问题出在其他地方。您的网页是否以意外的方式与 AD 设置交互？网页上是否有某些东西失败而没有显示任何错误？网页是否在旧 SBS 设置中查找未迁移到 EC2 的内容？如果您有代码和一些开发技巧，我会查看该代码。
答案2
答案是 EBS 对于 SQL Server 来说太慢了。
我进行了广泛的测试。对于 SQL 读取，EBS 非常糟糕。对于 SQL 写入，它的速度太慢，以至于永远不应该使用它。
有具有专用 IOPS 的新 EBS 卷。这是唯一的方法。
设置两个EBS卷：一个用于ldf，一个用于mdf。
调整 IOPS 直到获得良好的性能。
将 tempdb 放在本地实例存储上。
答案3
听起来您的数据库的绝大部分实际上都缓存在 RAM 中。您可以使用 perfmon 中的 SQLServer:BufferManager 缓冲区缓存命中率计数器来查看查询中命中缓存而不是磁盘的百分比。命中率越高越好。
我还建议检查您的磁盘和 CPU 使用情况，您的速度缓慢可能与 RAM 根本无关。
答案4
与数据库大小相比，巨大的事务日志很有趣。我不确定这是否是一个实际问题，但您可以尝试通过执行以下操作来摆脱它：确保数据库的恢复模式设置为“简单”（而不是“完整”！），然后将数据库备份到文件。这应该会触发检查点并允许 SQL Server 截断日志。