SQL Server 2014引入的内存优化表没有写入锁,可以避免磁盘I/O,支持完全编译存储过程,与传统表相比,显著地提升了性能。但是,它也有许多限制,包括无法使用备受NoSQL设计风格青睐的大文档。
\u0026#xD;\n\u0026#xD;\n
在SQL Server 2016中,其中许多限制已经接触。首先是在内存优化表和本机编译存储过程中支持LOB类型。这意味着用户可以使用varChar(max)、nVarChar(max) (都可以包含XML和JSON 数据)和varBinary(max)。8060字节的行大小限制也解除了,即使对于没有包含LOB类型的宽表也是如此。
\u0026#xD;\n\u0026#xD;\n
尽管如此,如果可能的话,微软并不建议使用这个特性。如果可以将所有的数据都存入varChar(8000)或者更小的列中,而不是varChar(max)中,那么就可以避免写入时访问存储大对象的隐藏表的开销。
\u0026#xD;\n\u0026#xD;\n
内存优化表约束
\u0026#xD;\n\u0026#xD;\n
内存优化表的另一个限制是不能创建约束(除了唯一主键)。从应用程序设计的角度来说,这不是绝对必要的,但约束确实降低了多种数据冲突类型发生的可能性。
\u0026#xD;\n\u0026#xD;\n
- 内存优化表之间的FOREIGN KEY约束 \u0026#xD;\n\u0026#xD;\n
- CHECK约束 \u0026#xD;\n\u0026#xD;\n
- UNIQUE约束\u0026#xD;\n
注意,普通表和内存优化表之间的外键约束还不允许。
\u0026#xD;\n\u0026#xD;\n
本机编译存储过程改进
\u0026#xD;\n\u0026#xD;\n
熟悉这个术语的人都知道,一个“本机编译存储过程”在创建时就被编译成了高度优化的机器代码。它只能操作内存优化表,但与普通的存储过程相比(在运行时解释),显著地提升了性能。
\u0026#xD;\n\u0026#xD;\n
除了支持LOB类型外,用户可以在INSERT、UPDATE和DELETE语句中使用OUTPUT子句。这可以减少对单独查询的需求,反过来,这可能减少事务及相关锁定需求。
\u0026#xD;\n\u0026#xD;\n
现在,本机编译存储过程还提供了其他标准SQL特性,包括:
\u0026#xD;\n\u0026#xD;\n
- UNION和UNION ALL \u0026#xD;\n\u0026#xD;\n
- SELECT DISTINCT \u0026#xD;\n\u0026#xD;\n
- OUTER JOIN \u0026#xD;\n\u0026#xD;\n
- SELECT语句中的子查询(EXISTS、IN、标量子查询)\u0026#xD;\n
本机编译函数
\u0026#xD;\n\u0026#xD;\n
现在,用户可以本机编译标量函数。要这样做的话,用户需要使用WITH NATIVE_COMPILATION、SCHEMABINDING作为指令,并将具体的代码封装进一个BEGIN ATOMIC块中。这与本机编译存储过程不同,后者仅使用WITH SCHEMABINDING指令标记。
\u0026#xD;\n\u0026#xD;\n
本机编译触发器
\u0026#xD;\n\u0026#xD;\n
让我们继续这个话题,如果使用了WITH NATIVE_COMPILATION,那么AFTER触发器现在可以置于内存优化表上了。
\u0026#xD;\n\u0026#xD;\n
要了解更多信息,可以查看SQL2016 CTP3新特性和自CTP3以来SQL Server 2016中的内存OLTP新特性。
\u0026#xD;\n\u0026#xD;\n
查看英文原文:SQL Server Now Offers NoSQL Style Memory-Optimized Tables
\u0026#xD;\n\u0026#xD;\n