对于我们的某些环境，我们已将SQL版本升级到2017。我们正在做的是获取SQL 2012数据库备份，并通过一些自动化脚本在SQL 2017上将其还原。这些数据库从SQL 2008 R2迁移到SQL 2012的情况也是如此。但是我们数据库的兼容性级别仍为2008和2012，因为基本上我们在迁移过程中不会更新数据库的兼容性级别。唯一的原因是这些SQL版本之间的内存体系结构不同。
那么，如果我们将数据库的兼容性从2012或2008升级到2017，那么有人能帮助我理解可能的影响吗？为了使兼容性级别更改对环境的影响降到最低，我们是否必须启用/使用任何并行功能？
在理解这一点方面的任何帮助将不胜感激。
在我的空间不足时添加评论作为答案：
我怀疑这个问题过于笼统，无法提供全面的答案。最好的方法可能是简单地在测试环境中尝试更改，然后看看会发生什么。产生的影响在很大程度上取决于您的工作量类型和所使用的功能。
根据我的经验，在这些情况下，从2014年前的版本转到发布后的版本时，最大的收获是基数估计器的更改。平均查询速度可能会快一些，但您可能不会注意到，因为它解决的实际问题已被优化。另一方面，将有少数查询对您而言会变慢，您需要识别并修复它们。作为快速的短期解决方案，您可以使用提示OPTION (USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION'))
如果您使用的是MERGE语句，则存在可能会开始引发错误的风险，因为查询死锁本身可能会出现一些已知的错误，我们必须切换到删除一些索引，然后再合并并重新构建它们大量的ETL管道。