先明确下你的场景：

近期完成服务器迁移：从Windows Server 2008 R2 + MSSQL 2008 R2 STD环境迁移至Windows Server 2012 R2 + MSSQL 2016 STD环境。硬件方面，旧服务器为1271v3处理器、24GB内存，新服务器为1271v6处理器、32GB内存，其余硬件配置一致。数据库通过备份还原方式迁移，新服务器运行无报错，但性能显著低于旧服务器，甚至出现部分异常情况。

既然新服务器硬件更好却没报错，问题基本都出在配置不匹配、查询计划变化或者硬件没被充分利用上，按下面的步骤一步步排查：

1. 先把SQL的内存配置拉到合理上限 #

旧机器24G内存，新机器有32G，但SQL Server默认不会自动吃光所有内存，得手动调整：

• 打开SSMS，右键你的服务器 → 属性 → 内存
• 给Windows系统留4-6G（毕竟2012 R2自身也需要内存），剩下的26-28G全部分配给「最大服务器内存(MB)」
• 记得对比旧服务器的内存分配比例，别新机器给SQL的内存反而比旧的少

2. 升级数据库兼容性级别，别让新SQL用旧逻辑干活 #

备份还原后，数据库的兼容性级别大概率停留在2008 R2的100级，但SQL 2016的优化器是针对130级优化的，不升级等于浪费新功能：

• 跑个查询看看当前级别：SELECT name, compatibility_level FROM sys.databases;
• 如果是100，先在测试库试试改成130（怕旧查询有兼容问题的话，个别查询可以加OPTION (QUERYTRACEON 9481)强制用旧优化器，对比性能差异）

3. 更新统计信息+整理索引，让查询找数据更高效 #

旧库的统计信息到新环境可能过时，而且SQL 2016对索引的判断逻辑有变化：

• 先全库更新统计信息：EXEC sp_updatestats;
• 查下碎片率高的索引，超过30%的就重建：

  SELECT 
      name AS 索引名称,
      avg_fragmentation_in_percent AS 碎片率
  FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED')
  WHERE avg_fragmentation_in_percent > 30;
  

• 也可以对比旧服务器的索引使用情况，看看新环境里是不是有些索引没被正确调用

4. 确认硬件真的在全力输出 #

别以为新CPU就一定跑得快，先检查这几个容易忽略的点：

• 打开任务管理器看SQL进程的CPU占用，如果远低于核心数，看看是不是开了CPU亲和性（把SQL绑到少数核心上了）
• Windows电源计划改成高性能！默认的平衡模式会限制CPU性能，很多人都踩过这个坑
• 磁盘分区对齐也很重要，用diskpart查下：

  diskpart
  select disk 0
  select partition 1
  detail partition
  

  偏移量得是1024KB的整数倍，不然IO性能会打折扣

5. 补全补丁，修复已知性能bug #

SQL 2016初始版本有不少性能坑，Windows Server 2012 R2也得更到最新：

• 打开SQL安装中心看当前版本，去微软官网找对应版本的最新累积更新装上
• Windows系统更新也别落下，底层驱动或组件的问题也可能拖后腿

6. 抓异常查询的执行计划，对比新旧差异 #

用Extended Events或者SQL Profiler把慢查询抓出来，对比旧服务器的执行计划：

• 看看是不是新环境里查询选了更差的计划（比如本来用索引查找，现在变成全表扫描了）
• 有没有参数嗅探的问题？试试给慢查询加OPTION (RECOMPILE)，看性能会不会回升

内容的提问来源于stack exchange，提问作者user1480192