虚拟化技术逐渐成熟，将SQL Server实例迁移到虚拟化服务器上也越来越流行。物理机的数目在减少，随之而来的是耗电量的减少和License成本的降低，而且更易于管理。听起来很有优势，但并不是所有场景都适合SQL Server虚拟化。
虚拟化使I/O性能降低
要想有好的性能，数据库需要的最多的单个资源除了CPU外就是磁盘I/O了。当物理服务器只专用于一个SQL Server实例时更容易改善I/O瓶颈问题。如果IOPS(每秒的输入输出操作)投入产出比合适的话，你可以将传统硬盘换为更快的固态硬盘，或者增加更多的内存以增大缓存。主要的考量是权衡成本，因为这种升级不会太便宜。
在SQL Server虚拟化期间，尽管硬件一定会比迁移前的服务器要好，至少是要一样好。而对I/O指标来说就不一定，因为你最后要实现的就是要共享I/O带宽以充分使用数据库。有些迁移的方法，例如：你可以将数据库存储放在物理轴和I/O通道上，这样就可以做到与其他虚拟机隔离，但是这必须在迁移到虚拟机之前完成。
这是个常见的例子：许多专用的数据库服务器在存储阵列中使用RAID1+0(即RAID10)，这种方案成本高但效果很好。而另一方面，虚拟机可能使用RAID5以平衡性能和冗余。之前对硬件优化的工作负担会在后面受损，除非你能直接将物理磁盘挂在虚拟机上而非原来的RAID1+0的设置上。
这并不是说磁盘一定要放在本地存储。在虚拟机上的SAN有可能比物理机上的本地磁盘还要好，至少是不相上下。那么IOPS呢?其实并不是一个一定要达到的精确技术指标。
如果是自己构建虚拟主机，你就能对其控制。但是如果是使用别人的虚拟主机，就只能使用大小统一设置的主机。
当虚拟内存不够时
物理内存对数据库有很多好处：内存是执行操作和缓存I/O的地方。所以SQL Server在独立的机器上工作得最好就是这个原因，因为它能随意根据需要供应内存，不用直接与同一台机器上的其他应用竞争内存。拇指规则就是使整个数据库有足够的内存可用，或者至少是最常用的部分只要有可能就被缓存在内存中。
相同的数据库服务器的虚拟化版本需要有与物理服务器等量的内存，或者比物理服务器内存还要更多。许多虚拟系统都通过内存共享技术允许多个虚拟机共享 一致的内存页。但是这种共享是对每个虚拟机上运行的操作系统而言的。这些内存大多在虚拟机之间可共享，而并非是数据库本身的组成部分。
这是另外一个领域，为SQL Server实例做内存消耗统计是有帮助的。这样你就能看到产品数据库到底需要使用多少内存，你最好能及时得到通知，了解在虚拟机中如何根据内存需求调整资源的分配。
除非必要否则不要使用虚拟化
另外，还会迫不得已使用虚拟化的情况，这意味着计划中就没有把虚拟化的优点考虑在内，只是在没上这个技术的时候，系统的表现更糟糕，而希望虚拟化能够解决一些问题。
例如，如果你有一个历史遗留的SQL Server,独占一台Server.按如今的硬件标准，如果对服务器的访问量不大，这种情况比较适合做虚拟化。机器越老或越慢，你越能从虚拟化中获得更多优势。合并多台服务器意味着消耗的电力更少，制冷和空间占用也都减少了。
另一方面，如果是一个完整的SQL Server集群，想通过虚拟化节约成本或获得性能优势。将集群虚拟化可能在耗电量和制冷方面有所节省–但如果虚拟化是以整体性能为代价的，那最好还是不要做虚拟化。
SQL Server虚拟化只应该在有好的业务需求的时候实施，而且在此过程中也不应失去整体IOPS或内存。尽管这些优点使虚拟化看上去很神奇，但重要的是要记住虚拟化只是个工具而不是所谓的万能药。
