SQL Server 内存优化表的索引设计

测试的版本:SQL Server 2017

内存优化表上可以创建三种类型的索引,分别是:Hash Index、内存优化非聚集(NONCLUSTERED)索引和聚集(CLUSTERED)列存储索引。

本文着重分享非聚集索引和哈希索引,这两个索引适用的场景是:

  • 非聚集索引   如果查询中包含order by子句、或者包含 where index_column > value等范围扫描操作 ,推荐使用非聚集索引。
  • 哈希索引       如果查询中包含点查找(point lookup),例如 where index_column = value,而不是范围扫描,推荐使用哈希索引。

一,创建内存优化表的索引

在创建内存优化表的索引时,第一种方式是在创建表时定义索引,第二种方式是先创建内存优化表,然后通过alter table命令修改表结构,向表中添加索引,而表级别的索引语法如下所示:

<table_index> ::=
  INDEX index_name
{   [ NONCLUSTERED ] HASH (column [ ,... n ] ) WITH (BUCKET_COUNT = bucket_count)
  | [ NONCLUSTERED ] (column [ ASC | DESC ] [ ,... n ] ) [ ON filegroup_name | default ]
}

举个例子,修改表结构,向表中添加哈希索引,在定义索引时必须设置bucket_count的数量:

ALTER TABLE table_name
    ADD INDEX idx_hash_index_name  HASH (index_key) WITH (BUCKET_COUNT = 64);  

二,内存非聚集索引的内在结构

内存非聚集索引类似于B-Tree结构,称作Bw-Tree,是一个新型的B-Tree结构。从高层次上来看,Bw-Tree可以理解为按照Page ID组织的页面映射。

在Bw-Tree结构中,每个索引Page具有一组有序键值(该结构类似于普通的B树),键值是按照大小顺序排列的,并且索引中包含层次结构,父级别指向子级别,叶级别指向数据行。

差异是Bw-Tree可以把多个数据行连接在一起,级别中的页面指针是逻辑页面的ID,这个逻辑页面的ID实际上是页面映射表的偏移量,该映射表具有每个页面的物理地址,通过偏移量找到每个页面在内存中实际的物理地址。

在内存非聚集索引中,没有索引页的就地更新(in place update),为了实现该目的,引入了新的更新机制:

  • 在更新页时,不需要latch 和lock
  • 索引页不是固定的大小

在非叶子级别中,父级别的页面中存储的键值是它指向的子级页面中的键值的最大值,并且每一行还包含该页面逻辑页ID(偏移量)。叶级数据页不仅包含键值,还包含页面的物理地址。

三,哈希索引的内部结构

哈希索引包含一个由指针构成的数组,数组中的每个元组叫做一个hash bucket:

  • 每个hash bucket占用8Bytes,用于指向key entry构成的链式列表
  • 每个entry主要由索引键的值、对应的数据行的地址和指向下一个entry的指针构成
  • 每个entry有一个指针,用于指向链中下一个entry,通过这种方式,entry构成链式结构

hash bucket的数量必须在索引定义时指定:

  • 哈希索引的hash bucket的最大数量是 1,073,741,824
  • 较短的链式列表比较长的链式列表性能更好
  • hash bucket的数量与表中唯一值的数量的比值越低,每个hash bucket指向的链式列表的长度越长,性能越差。因此,应该适当增加hash bucket的数量。
  • 理想情况下,hash bucket最好是表中唯一值数量的1到2倍。

参考文档:

Index Architecture & Design

原文地址:https://www.cnblogs.com/ljhdo/p/10533688.html

时间: 2024-10-13 21:24:31

SQL Server 内存优化表的索引设计的相关文章

Sql server2014 内存优化表 本地编译存储过程

参考文献:http://www.infoq.com/cn/news/2013/09/Compiled-Queries http://www.bianceng.cn/database/SQLServer/201502/48247.htm SQL Server 2014内存数据库针对传统的表和存储过程引入了新的结构: memory optimized table(内存优化表)和native stored procedure(本地编译存储过程). 内存优化表:  默认情况下Memory optimiz

服务器优化案列分析之SQL server内存优化

状况分析 环境如下: 硬件:IBM3610服务器 系统:windows2003  x32 应用:内部物流系统软件   C/S架构 数据库:SQL Server2000 问题: 因为物流系统架构问题(开发比较早05年开发架构)服务端和客户端都只能运行在32位环境下 这样导致系统内存用不上去,一直在3.25G左右 SQL的运行内存一旦上去退步下来 用户连接量大的时候很卡,并发上不去 最后搜罗了很多方法,进行32位环境下的内存优化,具体如下: 1.Windows 2003 企业版 打开PAE更好的利用

SQLSERVER2014的内存优化表

SQL Server 2014中的内存引擎(代号为Hekaton)将OLTP提升到了新的高度. 现在,存储引擎已整合进当前的数据库管理系统,而使用先进内存技术来支持大规模OLTP工作负载. 就算如此,要利用此新功能,数据库必须包含“内存优化”文件组和表 即所配置的文件组和表使用Hekaton技术. 幸运的是,SQL Server 2014使这一过程变得非常简单直接. 要说明其工作原理,我们来创建一个名为TestHekaton的数据库,然后添加一个内存优化文件组到此数据库 测试环境:Microso

SQL Server 内存中OLTP内部机制概述(四)

----------------------------我是分割线------------------------------- 本文翻译自微软白皮书<SQL Server In-Memory OLTP Internals Overview>:http://technet.microsoft.com/en-us/library/dn720242.aspx 译者水平有限,如有翻译不当之处,欢迎指正. ----------------------------我是分割线---------------

SQL Server 2014 内存优化表

不同于disk-based table,内存优化表驻留在内存中,使用 Hekaton 内存数据库引擎实现.在查询时,从内存中读取数据行:在更新时,将数据的更新直接写入到内存中.内存优化表能够在disk上维护一个副本,用于持久化数据集. Memory-optimized tables reside in memory. Rows in the table are read from and written to memory. The entire table resides in memory.

SQL SERVER全面优化-------索引有多重要?

想了好久索引的重要性应该怎么写?讲原理结构?我估计大部分人不愿意看,也不愿意花那么多时间仔细研究.光写应用?感觉不明白原理一样不会用.举例说明?情况太多也写不全....到底该怎么写呢? 随便写吧,想到哪写到哪!  前面很多篇不管CPU.内存.磁盘.语句等等等都提到了索引的重要,我想刚刚开始学数据库的在校学生都知道索引对语句性能的重要性.但他们可能不知道,对语句的重要性就是对系统的重要性! 抛出一个问题 :你相信一条语句就能让你的大系统挂掉么? 带着问题,首先还是贴出我的座驾 最近不太喜欢红色换了

SQL Server 2014,表变量上的非聚集索引

从Paul White的推特上看到,在SQL Server 2014里,对于表变量(Table Variables),它是支持非唯一聚集索引(Non-Unique Clustered Indexes)和非聚集索引(Non-Clustered Indexes)的.看到这个,我决定在自己的虚拟机里尝试下,因为这将是个卓越的功能.表变量很棒,因为用它可以避免过多的重编译(excessive recompilations).当你创建它们时,它们是没有统计信息,你不会改变数据库架构.它们只是变量,但在Te

3 .6 .4 优化SQL Server内存酉己置

3 .6 .4 优化SQL Server内存酉己置1 .最小和最大服务器内存这两个配置用于控制SQL Server可用内存的大小.对于最小内存,在 SQL Server服务 启动时,不会马上达到这个设置值,而是仅使用最小的需求内存,然后按需增长,一旦增 长到最小内存设置值时,SQL Server将不会再释放内存.最大内存用于设置内存使用的上 限,可以使用SSMS或者sp_COnfigU re来配置.需要提醒的是,这里的"最大内存"实际 上指的是Buffer Pool,在 64位系统中,

SQL SERVER性能优化综述

一个系统的性能的提高,不单单是试运行或者维护阶段的性能调优的任务,也不单单是开发阶段的事情,而是在整个软件生命周期都需要注意,进行有效工作才能达到的.所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项. 一.分析阶段 一般来说,在系统分析阶段往往有太多需要关注的地方,系统各种功能性.可用性.可靠性.安全性需求往往吸引了我们大部分的注意力,但是,我们必须注意,性能是很重要的非功能性需求,必须根据系统的特点确定其实时性需求.响应时间的需求.硬件的配置等.最好能有各种需求的量化的指