SQL Server 2016新功能 (2)
SQL Server 2016：伸展数据库 (2)
SQL Server 2016：动态数据屏蔽 (2)
SQL Server 2016：行级安全 (2)
SQL Server 2016：全程加密 (3)
SQL Server 2016：时态表 (3)
SQL Server 2016：内存列存储索引 (3)
列存储索引 (3)
内存优化表 (4)
SQL Server 2016：内存优化表变得更易用了 (4)
内存优化表（Memory-Optimized Tables） (4)
SQL Server 2016 CTP内存优化表 (4)
SQL Server 2016：实时查询统计 (5)
SQL Server 2016：通过Query Store定位回归缺陷 (5)
SQL Server 2016：增加JSON支持 (6)
JSON（JavaScript Object Notation） (6)
SQL Server 2016提供JSON操作原生支持 (6)
SQL Server 2016：增加R语言支持 (6)
R语言 (6)
其它新增功能 (6)
SQL Server 2016新功能
SQL Server 2016：伸展数据库
SQL Server 2016提供了一个新特性“伸展数据库（stretch database）”，使它可以将“热数据（hot data）”存储在本地，并向应用程序提供本地服务器性能，而将不会发生任何变化的老数据存储在云上。该特性的基本应用场景是，一个表包含了少量用户平常关心的热数据和大量应该移到离线归档但用户仍然希望能够查询的老数据。
当启用伸展数据库特性时，它会另外创建一个托管在Azure中的数据库。然后，将一个表标记为“stretch”，SQL Server将自动开始将数据迁移到云上。当前，只有“archive table”模式可用，即假定数据库在操作一张历史表，并迁移所有的行。“archive row”模式目前尚未发布，它会使用WHERE子句确定需要归档的行。常见的场景包括超过一年的行，或者有标记标明不再使用的行（比如已完成的订单）。
查询伸展表的SQL与查询普通表所需的SQL完全相同。查询执行引擎将负责在本地服务器和基于Azure的服务器之间分发查询，该过程是自动完成的。这意味着，用户可以在数据库上启用伸展功能，而不需要修改使用它的应用程序。
当使用这种模型时，备份和恢复需要相应地变化。普通备份只会包含本地管理的数据，包含位于伸展数据库上的数据的完整备份需要不同的过程。
SQL Server 2016：动态数据屏蔽
有时候，用户需要访问数据的子集。例如，信用卡或者社会保险号的后四位。这可以在应用程序层面实现，但会留下犯错的空间。只要一次忘记屏蔽，就会导致敏感信息泄露。
SQL Server 2016试图通过一项名为“动态数据屏蔽（Dynamic Data Masking）”的特性解决这个问题。
如果列在创建列时附加屏蔽，那么它默认只会返回透过屏蔽暴露出来的数据。当前，SQL Server提供了三种类型的屏蔽：
✓Default屏蔽会根据数据类型返回‘XXX’、0或‘01.01.2000 00:00:00.0000000’。
✓Email屏蔽会返回‘aXX@XXXX’，其中“a”是地址的第一个字母，“com”
为顶级域名。
✓Partial屏蔽返回前N个字母、像‘XXX-XX-XX’这样的常量表达式和最后N个字母。
有两种方法可以解除数据屏蔽。第一种是拥有UNMASK全局权限，它可以为用户关闭所有的数据屏蔽。第二种是将屏蔽列转换成底层数据类型。
局限性：由于屏蔽可以通过类型转换消除，所以不应该将这项特性看作是安全特性。确切地说，它是一个可以与诸如加密敏感信息、不允许用户执行“动态查询（ad hoc queries）”这样的最佳实践结合使用的便利功能。
屏蔽可能导致ORM出现问题。如果ORM不支持按字段跟踪变化，那么它可能会在更新操作时用屏蔽值覆盖实际的值。
SQL Server 2016：行级安全
对于SQL Server，一个常见的批评是，其安全模型只能识别表和列。用户如果希望以行
为单位应用安全规则，就需要使用存储过程或表值函数来模拟，然后一种方法，确保它们不会被绕开。
SQL Server 2016（及SQL Azure）中的行级安全基于一个专门设计的内联表值函数。在使用行级安全时，用户无法看到他们不能访问的行。这就好像在访问表时自动增加一个额外的、安全相关的where子句。
由于其作用像一个where子句，所以有一些局限。例如，如果用户在那个列上使用了全文搜索索引，那么数据就可能泄露。此外，数据库还可能遭受旁路攻击。
SQL Server 2016：全程加密
SQL Server 2016将通过新的全程加密（Always Encrypted）特性让加密工作变得更简单，这项特性确保在数据库中不会看到敏感列中的未加密值，并且无需对应用进行重写。为了维持合理的性能，非敏感的列——例如主键列仍将保持未加密。
实际的数据加密与解密过程是由数据库driver这一层处理的，数据库本身只能看到加密后的值，而应用程序代码仅仅是与未加密的数据打交道。在执行某个查询时，driver会自动在Windows Certificate Store（或其它取决于操作系统中的位置）中查主密钥。该主密钥将用于将对应于某一列的密钥进行解密，随后再用解密后的密钥对字段及参数进行加密与解密。
SQL Server 2016：时态表
术语“时态数据（temporal data）”是指那些在数据库中有版本的记录。任何给定的逻辑记录都有一个当前版本和零个或多个先前版本。当前版本和任意先前版本在数据库中都以物理行的形式存在，虽然未必在同一张表中。使用时态表时要努力保证数据完整性。查询时态数据也是个挑战。
SQL Server 2016提供了另外一种选择——新的时态表对象。表面上看，时态表看起来跟普通表一样。它支持大多数列类型、普通索引、列存储索引、外键等等。CRUD类的操作同使用普通SQL或对象关系映射一样。实际上，大多数普通表都可以转换成时态表，而不需要修改使用上述表的存储过程和应用程序。
从实现上来说，时态表实际上是两张表。一张表包含当前值，另一张表管理数据的历史版本。两张表链接在一起，普通表的任何UPDATE或DELETE操作都会自动创建一个相应的历史行。
SQL Server 2016：内存列存储索引
SQL Server 2016的一项新特性是可以在“内存优化表（Memory Optimized Table）”上添加“列存储索引（Columnstore Index）”。
列存储索引
一种按照列而不是行组织数据的索引。每个数据块只存储一个列的数据，最多包含100万行。因此，如果数据为5列1000万行，那么就需要存储在50个数据块中。当只查询部分
列时，这种数据组织策略特别有效，因为数据库不会从磁盘读取用户不关心的列。
列存储索引比表扫描要快得多，但没有传统的B树索引那么快。这特别适合于那种无法预测需要什么索引的即时报表。
内存优化表
一个经过优化并一直驻留在内存中的表。这有许多好处，比如锁无关写，但它也有很大的局限性。比如，只允许有8个索引，这对于用于即时查询的表而言限制太大。
SQL Server 2016部分地弥补了这种限制，它允许那8个索引中的其中一个为列存储索引。但要遵循如下规则：
像内存优化表上的其它索引一样，列存储索引必须在表创建时定义。
列存储索引必须包含基表中的所有列。（在普通表上的列存储索引不存在这种限制。）列存储索引必须包含基表中的所有行。换言之，它不能是“筛选索引（filtered index）”。
一个与内存优化表相关的特性是创建本地编译查询。数据库使用C编译器将这些查询编译成了机器码，而不使用SQL Server解释器。使用列存储索引的查询可以使用这个选项，而不用总是通过解释器运行。
SQL Server 2016：内存优化表变得更易用了
内存优化表（Memory-Optimized Tables）
原是SQL Server 2014的新特性，传统意义上的磁盘表（Disk-Based Tables）是保存在磁盘上的，SQL Server 2014引入了OLTP数据优化，即引入了内存优化表，在内存中实现对该表的增删改查操作，从而提高OLTP的性能。SQL Server 2014测评结果如下：效率：内存表对比普通的磁盘表，在增、删、改方面有非常大的优势，甚至达到了上百倍！但查询方面并没有太大的区别。
可行性：内存表的限制比较大，比如数据库用了内存表之后就不能使用复制、镜像、链接服务器，内存表也不能使用触发器、约束，每行的字节数不能超过8060字节，内存表的结构和索引建立之后就不能修改等等。而且必须配合本地编译的存储过程效率才能提升。仅适用于数据库不需要被限制的功能（复制
、镜像等），而且表的增、删、改非常频繁的情况。
SQL Server 2016 CTP内存优化表
SQL Server 2014中的做法是创建一张临时表，把数据复制过来，删除原来的内存优化表，然后创建并且载入新的内存优化表。对以下操作而言没必要再这样做规避了：
✓改变bucket总数。bucket总数太高会浪费内存，太低则损害性能。
✓增加和移动索引。请注意在ALTER Table命令之外，无法创建或移动索引。
✓改变、增加和移动列。
✓增加和移动约束。
SQL Server 2016：实时查询统计
SQL Server 2016中的“实时查询统计（Live Query Statistics）”为DBA提供了一个执行计划的实时版本，对当前正在执行的步骤进行了详细的注解。
统计信息显示方式同在Visual Studio中运行SQL Server集成服务作业时看到的东西类似，但提供了更底
层的细节，包括“处理的行数、耗时、操作进展，等等。”
server 2016下面是一个来自文档的示例：
该特性只对普通表有效；当查询涉及内存优化表或列存储索引时，不能使用。它也不能查看本地编译的存储过程。该特性默认是不启用的，这可能是因为进展报告会额外增加开销。可以在会话级别启用它，也可以通过启用“扩充事件（extended event）”query_post_execution_showplan在服务器层面启用它。
SQL Server 2016：通过Query Store定位回归缺陷
对于多数开发者来说，一旦出现性能方面的回归缺陷，通常可以追溯到某个特殊的事件，例如用户的大量涌入或代码的变更。而对数据库开发者来说，事情就没有那么简单了。随着索引的重建与统计数据的更新，SQL Server或许会决定“重写”你的代码，重新生成执行计划。如果不到正确的备份以及与生产环境同等级别的硬件，想了解执行计划中的变更基本上是不可能的，至少目前来说是这样。
而在SQL Server 2016中，微软将通过一个名为Query Store的特性对执行计划的历史变动进行保存。一旦启用了Query Store，它就会将每个查询中的信息进行日志记录，包括：执行次数、执行时间、内存占用、逻辑读取、逻辑写入、物理读取、执行计划变更次数。
为了减少对服务器的压力，这些信息是按照固定的时间窗口进行聚合的。如果你需要更详细的数据，应转而使用扩展事件（Extended Events）特性。
要查看这些信息，最简单的方式是直接打开回归查询（Regressed Queries）视图。根据任意一种记录的指标查看回归缺陷。当你到回归缺陷之后，可以选择强制SQL Server使用之前的执行计划。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。