随着虚拟化逐渐成熟，将SQLServer实例迁移到虚拟化服务器上也越来越流行。物理机的数目在减少，随之而来的是耗电量的减少和License成本的降低，而且更易于管理。听起来很有优势，但并不是所有场景都适合SQL Server虚拟化。

　　虚拟化使I/O性能降低

　　要想有好的性能，数据库需要的最多的单个资源除了CPU外就是磁盘I/O了。当物理服务器只专用于一个SQL Server实例时更容易改善I/O瓶颈问题。如果IOPS (每秒的输入输出操作)投入产出比合适的话，你可以将传统硬盘换为更快的固态硬盘，或者增加更多的内存以增大缓存。主要的考量是权衡成本，因为这种升级不会太便宜。

　　在SQL Server虚拟化期间，尽管硬件一定会比迁移前的服务器要好，至少是要一样好。而对I/O指标来说就不一定，因为你最后要实现的就是要共享I/O带宽以充分使用数据库。有些迁移的方法，例如：你可以将数据库存储放在物理轴和I/O通道上，这样就可以做到与其他虚拟机隔离，但是这必须在迁移到虚拟机之前完成。

　　这是个常见的例子：许多专用的数据库服务器在存储阵列中使用RAID 1+0(即RAID10)，这种方案成本高但效果很好。而另一方面，虚拟机可能使用RAID5 以平衡性能和冗余。之前对硬件优化的工作负担会在后面受损，除非你能直接将物理磁盘挂在虚拟机上而非原来的RAID1+0的设置上。

　　这并不是说磁盘一定要放在本地存储。在虚拟机上的SAN有可能比物理机上的本地磁盘还要好，至少是不相上下。那么IOPS呢?其实并不是一个一定要达到的精确技术指标。

　　如果是自己构建虚拟主机，你就能对其控制。但是如果是使用别人的虚拟主机，就只能使用大小统一设置的主机。

　　当虚拟内存不够时

　　物理内存对数据库有很多好处：内存是执行操作和缓存I/O的地方。所以SQL Server在独立的机器上工作得最好就是这个原因，因为它能随意根据需要供应内存，不用直接与同一台机器上的其他应用竞争内存。拇指规则就是使整个数据库有足够的内存可用，或者至少是最常用的部分只要有可能就被缓存在内存中。

　　相同的数据库服务器的虚拟化版本需要有与物理服务器等量的内存，或者比物理服务器内存还要更多。许多虚拟系统都通过内存共享技术允许多个虚拟机共享一致的内存页。但是这种共享是对每个虚拟机上运行的操作系统而言的。这些内存大多在虚拟机之间可共享，而并非是数据库本身的组成部分。

　　这是另外一个领域，为SQL Server实例做内存消耗统计是有帮助的。这样你就能看到产品数据库到底需要使用多少内存，你最好能及时得到通知，了解在虚拟机中如何根据内存需求调整资源的分配。

　　除非必要 否则不要使用虚拟化

　　另外，还会迫不得已使用虚拟化的情况，这意味着计划中就没有把虚拟化的优点考虑在内，只是在没上这个技术的时候，系统的表现更糟糕，而希望虚拟化能够解决一些问题。

　　例如，如果你有一个历史遗留的SQL Server，独占一台Server。按如今的硬件标准，如果对服务器的访问量不大，这种情况比较适合做虚拟化。机器越老或越慢，你越能从虚拟化中获得更多优势。合并多台服务器意味着消耗的电力更少，制冷和空间占用也都减少了。

　　另一方面，如果是一个完整的SQL Server集群，想通过虚拟化节约成本或获得性能优势。将集群虚拟化可能在耗电量和制冷方面有所节省——但如果虚拟化是以整体性能为代价的，那最好还是不要做虚拟化。

　　SQL Server虚拟化只应该在有好的业务需求的时候实施，而且在此过程中也不应失去整体IOPS或内存。尽管这些优点使虚拟化看上去很神奇，但重要的是要记住虚拟化只是个工具而不是所谓的万能药。