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