您应该使用哪个版本的SQL Server？_sqlserver哪个版本稳定

在安装下一个SQL Server之前，请先等等。您确定使用的是正确的版本吗？

我知道，管理层希望您继续使用较旧的版本，供应商表示他们将仅支持较旧的版本，但是现在您有机会为较新的版本辩护，我将从黑暗时代开始，介绍每个较新的版本。

一、 应考虑使用SQL Server 2008

• 您正在处理的是不再受支持的古老应用程序，例如由供应商编写的第三方应用程序。
• 您仅获得SQL Server 2008的许可。
• 您只有Standard Edition，并且想要支持无限内存（在2008R2中不再支持）
• 您不知道SQL Server 2008和SQL Server 2008 R2 都具有相同的支持终止日期（嗯，现在您知道了，所以排除了一个）
• 您不知道  扩展支持将在2019年7月9日结束。  是的，如果将其托管在Azure VM中，Microsoft将为您提供扩展支持直到2022年，仅此而已。

在今天，SQL Server 2008已不是推荐的版本，因此让我们继续往下看。

二、 应考虑使用SQL Server 2008 R2

您需要从SQL 2008开始添加的这些新功能：

• PowerPivot for Excel（已被替换）
• Utility Control Point（没人使用）
• Master Data Services
• StreamInsight

三、 应考虑使用SQL Server 2012

• 应用程序的最新支持版本仅为SQL Server 2012，而非2014或更高版本。
• 您不愿意安装修补程序（因为SP4于2017年10月发布，此后仅存在一个安全修复程序，仅此而已。）
• 您可以在2年内轻松构建另一个SQL Server（因为支持终止于2022年7月）。
• 您要么不需要强大的备份加密功能，要么愿意购买第三方工具来获取备份。

2012引入了一些新特性——可用性组，列存储索引，contained databases，Data Quality Services等。但在2012时功能十分有限，并不推荐在2012时就使用这些功能。

四、 应考虑使用SQL Server 2014

• 应用程序的最新受支持版本仅为SQL Server 2014，而非2016或更高版本。
• 希望使用Always On可用性组（我甚至不愿意将其放在此处，因为它们在后续版本中将变得更加出色）。我只是将这视为考虑AG的最低起点（忘记2012），因为从2014开始，即使主库故障，从库也可读。
• 您需要对备份进行加密，并且您不愿意购买第三方备份工具。
• 您将日志传送用作报告工具，并且具有严格的权限要求（2014添加了新的服务器级角色，使此操作更加容易）。
• 您需要在不更改代码的情况下提高性能，并且有大量时间进行测试。2014版本的基数预估器（Cardinality Estimator）针对不同的执行计划进行了更改，但总体上效果并不理想。您仍然必须花时间来查找会变慢的查询，并弄清楚如何缓解这些查询。

2014也引入了一些新特性例如：In-Memory OLTP（该版本不适合用于生产环境）、Buffer Pool Extensions, data files in Azure blobs, backing up to a URL, and Delayed Durability.

五、 应考虑使用SQL Server 2016

• 您是一家独立的软件供应商（ISV）。2016 SP1在Standard Edition中为您提供了许多企业功能，这意味着您可以编写适用于Standard版本上的小型客户端和Enterprise版本上的大型客户端的应用程序。
• 您需要一个非常著名的、文档齐全的产品，很容易找到现成的材料并雇用知道如何使用此版本的人员。
• 您需要使用标准版。因为它支持128GB RAM（对于某些内部计划，例如查询计划，甚至可以超过它。）
• 您需要一直使用到2026年。此版本的支持时间比SQL Server 2012/2014更多，因此可以安装一次并使用更长的时间。
• 您对新应用程序有合规性需求。2016添加了始终加密，动态数据屏蔽，行级安全性和临时表，这些功能使您更轻松地构建保护对象并跟踪您的宝贵数据。
• 您想使用列存储索引。我将其称为最低版本，因为它们最终是可更新的，并且列存储索引和行存储索引都可以建在同一表上。参考 What's new in columnstore indexes - SQL Server | Microsoft Learn
• 您需要查询计划监控，并且您买不起第三方工具。查询存储（Query Store）为您提供了一些非常酷的功能。如果明天我再次从事全职的DBA工作，那么它和PowerShell将是我可能掌握的两项技能。

六、 应考虑使用SQL Server 2017

• 您愿意每30-60天安装一次补丁。在这样的较新版本中，修补程序更新非常快，并且它们修复了一些非常重要的问题。
• 您的目标是零RPO和财务风险。2017在AG上新增了最低提交副本设置，可以确保提交被多个副本收到。
• 您希望将来的升级更轻松。从2017开始，您可以在不同版本的SQL Server 间搭建分布式可用性组（Distributed Availability Group）。DAG的功能目前还不太强大、没有完整的文档，但我想将其作为进行更轻松升级的想法。在此之前，AG版本升级是绝对可怕的，并且通常最好建立一个新集群并迁移到该集群。
• 您需要高性能的列存储查询。2017为批处理模式执行计划提供了很多不错的选择。
• 您希望在Linux上运行SQL Server。但是，认真地看一下发行说明，然后单击每个“累积更新”阅读已修复的错误，一些群集错误确实使我大为惊讶。
• 您希望在SQL Server中进行机器学习和R语言。我知道数据人员这样做是一种新潮，但是请记住，您需要为SQL Server许可在每核上花费2,000至7,000 美元来实现这一目标。

是的，我知道，我在2017没有写“您想要一个非常著名的、文档齐全的产品”，但这不是因为产品不好。它与2012/2014/2016相比相对较新，而且很难找到关于分布式可用性组或Linux上的SQL Server之类的优质培训，或者雇用知道如何使用它们的人

它们不是坏功能，它们是很棒的功能，但现在就采用为时尚早，仅凭最佳实践就更难了。不是不可能，只是更难。

七、 应考虑使用SQL Server 2019

• 您需要尽可能长的支持寿命。直到2030年都将得到支持。问题是，整整十年不重新安装SQL Server会很好吗？
• 您愿意每30-60天安装一次补丁。在这样的较新版本中，修补程序更新非常快，并且它们修复了一些非常重要的问题。
• 您有能力通过实验而不是文档来学习。当您使用这些前沿功能时，您的实验和学习时间会增加，因为以下内容在某些方面没有公认的行业最佳实践。
• 您擅长负载和性能测试。2019增加了许多很酷的功能，但是它也对现有的执行计划进行了重大更改。您将采取什么措施来减轻其性能下降？
• 您很大程度上依赖于用户定义的功能。2019可以大大加快这些功能，尽管您需要进行大量测试。
• 您在很大程度上依赖于表变量，并且可以更改代码。

八、 那么正确的答案是什么？

SQL Server 2017对大多数人来说是一个非常令人信服的案例。它在新功能、稳定性和较长的支持时间之间取得了很好的平衡。大多数人无法做到每年升级每台服务器中的数据库，通常是现在安装了2017，然后观察2019的发布情况，并计划在2021年进行2019年的部署。