SQL Server In-Memory OLTP Internals for SQL Server 2016这份白皮书是在上一份《SQL Server In-Memory OLTP Internals Overview》基础上的，很多东西都是一样的不再介绍，只介绍不相同的部分。
行和索引存储
Range索引
的时候还是不支持的。Range index 使用bwtree数据结构。Bwtree和btree一样有叶子结点和中间节点。最重要的不通点是，bwtree page指针是一个逻辑的page id，而不是物理的page no。PID表示mapping table 上的位置，mapping table把PID和物理内存地址关联。Bwtree的index page是从来不更新的，而是增加一个新的，然后让mapping table的相同PID指向一个不同的物理内存地址。
具体的bwtree的算法可以看：http://www.cnblogs.com/Amaranthus/p/4375331.html
列存储索引
列存储索引基本结构
SQL Server 2016内存优化表支持聚集的列存储索引。列存储索引是高复合的索引，并不是由行来组织，而是用列来组织的。行被分为多个组，一个组最多可以有2^20行，然后把某一列的数据放入行组中，不会去管剩下的行。
每个行组，SQL Server都会使用Vertipaq压缩算法，重新编码和排列行组中的顺序来打到最有的压缩效果。每个行组中的列都是独立保存的，这个结构称之为段(segment)，每个段都是一个LOB，保存在LOB的分配段元中。段是数据读写的基本单元，如图，表示吧一组多个索引列转化为几个段
个段。
万行)，SQL Server会吧这些行转化为新的压缩的行组。
内存优化表中聚集列存储索引和内存优化表的非聚集索引是分开保存的，是数据的一个副本。实际上，内存优化表的聚集列存储索引你可以理解为，保存了所有列的非聚集列存储索引。因为数据是高效压缩的，因此开销比较少。因为类存储索引可以压缩到原始数据的10%，因此开销也只有10%。
所有的类存储索引段都是在内存中的。为了恢复的目的，每个行组在内存优化文件组中都保存成一个独立的文件类型为LARGE DATA，在文件中对于某个行组，所有的段都是存放在一起的。SQL Server也维护了一个指针，指向每个段并且可以访问这个段，特别是访问了部分列的时候。这个部分会在下面CHECKPOINT FILES的时候介绍。新的行会被以列存储索引保存，但是并不会马上加入到压缩行组中，新的行只能使用内存优化表的其他索引来访问。如图，新的行和整个表分开维护的。你可以认为这些行是“delta rowgroup”和磁盘表的Delta Store类似，但是这些行是内存优化表的一部分，但是不是技术上的列存储索引的一部分。实际上是课件的delta rowgroup
个varheap，一个用于压缩行组，另外一个用来保存新行，可以让SQL Server快速识别哪些行还没有进入压缩段，这些行也在可见的delta rowgroup中。
个操作：
- 行会被复制到一个或者多个行组，每个段都会被压缩转化变成聚集列存储索引的一部分。
- 行会从特定的内存分配器移到常规的内存存储。
万行那么这些行还是会被留在原来的地方。
万才会被压缩到常规的列存储索引行组中。
当行被转换到压缩rowgroup之后，所有删除的行都会被放到Delete Rows表中，和磁盘表的聚集列存储索引。当行多的时候查询会很没有效率。这种情况下重组列存储索引并没有什么用，除非删除并且重建索引。一旦rowgroup中90%的行被删除，剩下的10%会自动被插入到未压缩的varheap，在内存优化表的Delta rowgroup中。Rowgroup的存储会被进行垃圾回收。
Note:
前面提到的，如果内存优化表有任何LOB或者溢出列，列存储索引不能在上面被创建。因为最大的行不能超过8060字节。另外一旦内存优化表有一个列存储索引，就不能使用alter table操作。需要先删除列存储索引，alter，然后再创建列存储索引。
分钟。
USE master;GOSET NOCOUNT ON;GODROP DATABASE IF EXISTS IMDB;GOCREATE DATABASE IMDB;GOALTER DATABASE IMDB ADD FILEGROUP IMDB_mod_FG CONTAINS MEMORY_OPTIMIZED_DATA;GOALTER DATABASE IMDB ADD FILE ( NAME = ‘IMDB_mod’ , FILENAME = ‘c:\HKData\IMDB_mod’ ) TO FILEGROUP IMDB_mod_FG;GOUSE IMDB;GODROP TABLE IF EXISTS dbo.OrderDetailsBig;GOCREATE TABLE dbo.OrderDetailsBig ( OrderID INT NOT NULL , ProductID INT NOT NULL , UnitPrice MONEY NOT NULL , Quantity SMALLINT NOT NULL , Discount REAL NOT NULL INDEX IX_OrderID NONCLUSTERED HASH ( OrderID ) ) , INDEX IX_ProductID NONCLUSTERED ( ProductID ) , CONSTRAINT PK_Order_Details PRIMARY KEY NONCLUSTERED ( OrderID , ProductID ) , INDEX clcsi_OrderDetailsBig CLUSTERED COLUMNSTORE ) )WITH ( MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA );GOSELECT OBJECT_NAME(c.object_id) AS table_name , a.xtp_object_id , a.type_desc , minor_id , memory_consumer_id AS consumer_id , memory_consumer_type_desc AS consumer_type_desc , memory_consumer_desc AS consumer_desc , ) AS allocated_MB , ) AS used_MBFROM sys.memory_optimized_tables_internal_attributes a JOIN sys.dm_db_xtp_memory_consumers c ON a.object_id = c.object_id AND a.xtp_object_id = c.xtp_object_id LEFT JOIN sys.indexes i ON c.object_id = i.object_id
AND c.index_id = i.index_id;
返回的结果：
个内部表，xtp_object_id都不相同。每个内部表为了访问方便至少有一个索引用于数据访问。四个内部表：ROW_GROUP_INFO_TABLE(+hash索引)，SEGMENTS_TABLE(+2个hash索引)，DICTIONARIES_TABLE(+hash 索引),DELETED_ROW_TABLE（+hash索引）。（这些内部表的细节白皮书没有介绍）
除了看内存消费者之外，另外一个要检查的DMV是sys.dm_db_column_store_row_group_ physical_stats，这个视图不单单是显示了每个COMPRESSED并且OPEN的rowgroup的行数。你可以用一下脚本查看：
BEGIN TRAN;; ) BEGIN INSERT INTO dbo.OrderDetailsBig , 0.5 ); ; ) BEGIN COMMIT TRAN; BEGIN TRAN; END; END;COMMIT TRAN;SELECT row_group_id , state_desc , total_rows , trim_reason_descFROM sys.dm_db_column_store_row_group_physical_statsWHERE object_id = OBJECT_ID(‘dbo.OrderDetailsBig’)ORDER BY row_group_id;GO
那么就显示NO_TRIM。因为OPEN的rowgroup是不压缩的，因此为null，若为STATS_MISMATCH表示行太少，若为SPILLOVER表示有移除导致。
