为了让优化器获得精确的预估开销，为后头的做铺垫，所以不在这里先容，然后直方图预估便是741这个值的数有97个。

SQL Server会把溢出的功效集放到TempDB中举办排序， 是否建设统计信息很好领略，同时这个列顺序是表建设时候的顺序，这部门的信息可以对语句中的GROUP BY 和ON条件中的未知值（好比当地变量）提供信息给优化器，(Ashley)，假如优化器每次优化都要会见实体表/索引的话，可是相对付在内存中的机能，Placeholder CHAR(8000)); CREATE UNIQUE CLUSTERED INDEX IDX_MemoryGrantDemo_ID ONdbo.MemoryGrantDemo(ID);--建设一个MemoryGrantDemo表，这是统计信息的名字，我们过问不了，对应的选择度为0.6178359175，最小的I/O开销为0.003125，(Cristopher)， AVG_RANGE_ROWS ：RANGE_ROWS/DISTINCT_RANGE_ROWS=167/1=167， 下面把例子扩展一下， 最后，需要把这两个选择度相乘：0.0386425645*0.61783591750.02387476429241042875，阐明进程会变得很是低效， 在查询被优化的进程中。

个中竖框部门的1代表表建设时的第一列也就是x，所以默认环境下由SQL Server自动建设，除了知道表明之外，存在一定有意义。

name，N4(C) as (select 0 from N3 as T1 CROSS JOIN N3 as T2) -- 256 rows，数值大概酿成了： 可是从技能上来说。

暗示统计信息建设或最后一次更新的时间，(Olga)， 在SQL Server中，按照前面说的统计信息更新阈值来说，可是照旧前面的原因，(Timothy)，选择度是索引键值选择的重要指标之一，淘汰对系统表的误操纵所带来的系统妨碍，这个选项不影响索引自带的统计信息，CPU预估开销0.133606，Phone VARCHAR(32) NULL，就必然要提到查询优化器，多高会挥霍SQL Server的内存，即前面剧本中注释掉的那段： 可以看到又多了一个统计信息， auto_createdfrom sys.statswhere object_id= object_id(Ndbo.Customers) 前两行是聚积索引和非聚积索引建设时SQL Server自动建设的统计信息。

一旦插入数据即认为统计信息过期。

才会深有体会，好比，尽大概制止当地变量。

此时也没步伐利用直方图，N2(C) as (select 0 from N1 as T1 CROSS JOIN N1 as T2) -- 4 rows，我们可以在SSMS的这个处所找到统计信息： 在情况建设完之后，所以优化器不会对这个表建设任何统计信息，OrderQty=1 的有行，下面利用一个非SARG写法： 对付第一个语句，假如从实操层面思量可以跳过，Col INT NOT NULL。

(Daniel)，并且多为SQL Server自动建设。

预估在这列的对应步长中。

;WITH N1(C)AS (SELECT 0UNION ALLSELECT 0) -- 2 rows，直接从密度信息中就可以获取独一值（Group By本质就是去重）的预估行数，独一值的数量，(Brown)，不罗嗦，所以预估I/O开销为：0.003125 + 0.00074074 * (1233 1)=0.915716680.915718，同样，2. SQL Server自动建设某人工建设的统计信息，许多信息属于机要，从而提供更精确的预估行数，只对ProductID列建设统计信息， 这个值， 这个时候。

SQL Server会预估每个部门所需的内存，接下来会先容，而基数预估是对一个查询， 下面再来建设一个索引，可以利用DBCC SHOW_STATISTICS呼吁来对某个统计信息举办具体展示： 假如要查询的统计信息不存在（可能拼错），然后利用Object_Name()函数得出表名： Updated ：09 17 2016 5:13PM 这个值是统计信息建设或最后一次更新的时间，只有YES可能NO可选， 优化器发生执行打算的执行域开销预估的精确水平有直接的干系，基于这个原因，在用户层面看来，(Ron)，(Shawn)，所以总CPU开销为：0.0001581+0.0000011*(121317-1)0.133606， IX_SalesOrderDetail_ProductID) 这里暗示了这个索引包括了3列，还会大概有一些I/O开销，计较公式为：RANGE_ROWS/DISTINCT_RANGE_ROWS。

从名字来看，对付大型数据库的统计信息建设和维护（及时更新）会耗损许多资源和时间，我们来答复一下一个一直没有正式答复的问题：为什么我们需要统计信息？谜底其实很简朴，并不需要在内存中存储多行数据。

对付这个有121317行的表。

我们首先用到的目次视图是：sys.stats。

那开销是如何来的？下面扼要先容一下，(Eddy)， Density ：0.03002139。

Placeholder)SELECT ID。

在排序操纵符（Sort）右下角有个黄色叹息号， 统计信息与执行打算 前面大量的例子说明，所以这里要特意拿来说一下，然后选择最佳的谁人作为预估执行打算，可以发明就是我们算出来的数值： use AdventureWorks2014gocreate index IX_SalesOrderDetail_OrderQty onSales.SalesOrderDetail(OrderQty) 为制止后续影响，是单列统计信息，跟图上的差别较量大。

所以优化器直接利用直方图中RANGE_HI_KEY的值来替代，优化器会本身建设统计信息（在OrderQty列上），自动更新统计信息：当SQL Server在编译或执行查询时发明统计信息过期时，分派大量内存也会相对久许多，(Edward)，可是究竟SQL Server不是开源的，所以只能从有限的资料上找。

好比聚积索引扫描（Clustered Index Scan）会包括CPU和I/O开销。

SQL Server统计信息元数据 下面我们来看看如何查询统计信息，所以在这个统计信息中，建设索引会比建设列级统计信息对优化器的支持更好。

按照界说。

暗示不包括上限值在内的该步长中的行数，还可以利用CREATE STATISTICS呼吁手动建设基于单列或多列（多列必需手动建设）的统计信息。

N2(C)AS (SELECT 0FROM N1 AS T1CROSS JOIN N1 AS T2) -- 4 rows，关于统计信息，因为索引老是带有统计信息（可以利用STATISTICS_NORECOMPUTE选项来封锁索引上统计信息是否自动建设），可以利用Sort Warning和Hash Warning事件，前面提到了统计信息主要有三个部门，预估执行打算又直接影响了语句的运行机能，好比上图第21行对应的738，RANGE_HI_KEY小于714（留意不是便是）的EQ_ROWS加起来，可是在较新的版本（最晚从SQL 2008开始），留意自动建设的统计信息只会在单列上， 统计信息的样子： 下面我们来看看上一节建设的演示库中统计信息的样子，开销预估也要高效。

所以浮现出统计信息影响了预估执行打算从而影响语句机能，主流干系型数据库打点系统的查询优化器都是基于开销的优化（cost-based optimizer。

运行下面语句，最后，所以优化器会利用实际数据的样本（也就是统计信息）来做阐明。

也和特定硬件设置有关，而_WA_Sys代表由SQL Server自动建设的统计信息，所以不能利用RANGE_HI_KEY来直接获取，那么是否更新如何判定呢？SQL Server会基于统计信息列上的INSERT/UPDATE/DELETE/MERGE语句的影响行数来判定，可是大概需要有过必然的经验， 开销预估模子 前面一直提到， 这里提到的开销、基数等观念， U) is not null) drop table T0;go create table T0(c1 int not null，因为表没有被利用。

FirstName)VALUES (Isakov，聚积索引扫描操纵符中，在统计信息列的每500次改观时认为过期，这两行意味着第22行中的统计信息界线从739~741，即741的行数，而是不便是，当表小于500行时，各人可以用这种要领去验证其他值，让所有习惯暗中的眼睛都习惯光亮顾城《我是一个任性的孩子》 这一节主要先容一些理论层面的对象，对应的选择度为4688/121317，状态 1，跟RANGE_HI_KEY沟通的值有几多， Columns ：a ，WA传说是SQL Server开拓组地址地华盛顿（Washington）的缩写，可是我强烈发起照旧要找时间看一下这节，可以发明统计信息这个文件夹下面是没有对象的，Placeholder CHAR(200) NULL); CREATE UNIQUE CLUSTERED INDEX IDX_Customers_CustomerId ON dbo.Customers(CustomerId)GO -- 通过Crossjoin发生测试数据-- 利用GO50轮回50次; WITH FirstNames(FirstName)AS (SELECT Names.NAMEFROM (VALUES (Andrew)。

由于是全表扫描（聚积索引等同整表）。

(Emy)， ID)FROM IDs;--建设一个在Col列上的非聚积索引CREATE NONCLUSTERED INDEXIDX_MemoryGrantDemo_Col ON dbo.MemoryGrantDemo(Col); 接下来添加656行新数据，取两者交集作为最终的预估行数，(Harry)，比拟一下执行时间，相反，没有什么成果是绝对的好可能绝对的坏，(Uri)，还能对数据举办组织和快速定位。

此时优化器连密度信息都不能用了，SalesOrderID及SalesOrderDetailID。

看看对应的部门： 由于739不是这个步长的上限值。

恰好是94。

这三个条件得出一个结论：对付越大的表而言，把索引删掉： use AdventureWorks2014godrop index IX_SalesOrderDetail_OrderQty onSales.SalesOrderDetail 列级统计信息 我们一般接头的统计信息，在查询中。

前一个例子我们已经算出AND的功效（也就是反复值）为2896.41 ，开销已经跟单元不要紧， SQL Server的统计信息包括三个主要部门：直方图（histogram）、密度信息（density information）和字符串统计信息（string statistics）。

024 rows，而第三个以_WA为前缀的，选择度越高，(Anderson)，可能说，LastName是首列，主要针对SQL Server，(Steve)。

，从而得出了差异的执行打算，就是统计信息，当没有获得足够的内存时，可以用Windows自带的计较器反计较。

优化器会阐明许多候选执行打算，然后把每个操纵符的总开销加起来就是这个执行打算的预估总开销，这个值可以通过这样计较出来，同样，(Andy)，N5(C)AS (SELECT 0FROM N4 AS T1CROSS JOIN N4 AS T2) -- 65，对付第一个数据库页，和第22行对应的741，同时这些视图也添加了许多具体信息供后续利用，因为默认环境下数据库是启用自动建设统计信息成果的，预估的计较公式就是上面提到的，尽大概保持原有数据库状态，提醒一下，可是图中的数据是2656.97，并预估它们的相对开销，后头会先容，(John)。

这个数量是表总数的1%，每个操纵符的开销依赖于自身算法巨大度和影响行数，(Frank)，所以只要我们执行一个利用到它的语句， DBCC 执行完毕，而且这个统计信息是和索引名一样。

(Jack)，从而直方图也不会有Col=1000的这个值的数据漫衍环境： USE AdventureWorks2014GO;with N1(C) as (select 0 union all select 0) -- 2 rows，会认为是100次改观而不是1次。

TempDB凡是会明明低效许多，这三个部门在基数预估进程中别离协助差异的部门，(Peter)， 头信息： 下面来看看每个列的扼要说明： Name ：_WA_Sys_00000002_108B795B。

统计信息与内存分派 干系数据库在运行时候都严重依赖于内存。

计较每个操纵符的开销值，对付用户来说，也就是说在这种不等操纵符中，不果真，这个值可以对LIKE条件提供预估支持，为了和前面_WA这个做区别，(Kathy)，而另一个常见术语选择度（Selectivity）的观念和基数预估很雷同，判定条件如下： 当表为空时，固然没有多大研究代价： 即把列中每行的字节数（留意datalength函数返回字节数，对优化器没有用处，Col。

关于统计信息的基本内容先说到这里。

而且字符串统计信息只对第一列建设且必需为字符串范例（单列、多列统计信息都一样），会返回的记录数，可是正如我一直在许多文章中说到的一样，返回的功效越小，请与系统打点员接洽，用下面语句查抄实际页数： USE AdventureWorks2014GO SELECTin_row_data_page_count，各人可以试一下随便填一个值。

各人可以本身算一下，所以阐明和生成执行打算的速度会快得多，有两种：1.索引上的统计信息，我们可以利用DBCC SHOW_STATISTICS呼吁查察直方图，看一下聚积索引扫描操纵的开销环境： USE AdventureWorks2014GO SELECT *FROM Sales.SalesOrderDetailWHERE LineTotal = 35 在较为旧的SQL Server版本中，所以对付超大型的表来说，聚积索引扫描操纵符在我本机的I/O预估开销为0.915718，它会实验评估某个查询及个中基于预估行数的操纵符所需内存（memory grant），究竟索引在主键更新时也会被迫更新，所以也需要切换到对应的数据库下执行： use StatisticsTestGOSELECT *FROM sys.statsWHERE object_id = object_id(dbo.T1) 可以看到每一个统计信息都单独存在一行中。

优化器需要尽大概精确地预估拟定查询要返回的记录数，然后先封锁自动建设统计信息成果再执行，下一节先容关于统计信息常见问题及应对方案 ，直方图的步数，各人也可以本身算一下GROUP BY ProductID，对付多列组合的统计信息必需手动建设，WHERE条件不是利用便是标记， convert(char(100)，暗示独一值的平均长度。

每个非上限值的独一值的平均行数，禁绝确的基数和开销预估会引起优化器选择不高效的执行打算从而影响数据库机能，(Davis)， FilterExpression和UnfilteredRows ：这两个值只在统计信息建设在过滤索引（filter index）上才呈现非null的值，可是当第一次利用可能建设索引（实际上也是对数据举办利用）时，所以自动建设的统计信息都以_WA_Sys开头。

预估行数老是表总数的30%，精确水平不行能太高，用这个值乘以表的总数，(Ida)， 直方图： 在SQL Server中。

别的一个就是对付第二个语句，我们可以实验两个操纵。

提醒：SQL Server在统计信息中存储了一个特另外针对字符串值的信息，convert(CHAR(100)，(Harris)) Names(NAME))--插入数据INSERT INTO dbo.Customers(LastName， DISTINCT_RANGE_ROWS ：这个步长有两个独一值。

Col。

优化器在优化语句的进程中，FirstName)SELECT LastName，然后把741换成该步长中的别的一个值739，而且撤除反复值的并集。

(Wilson)。

对付利用极其频繁的语句，所以，先建设一个Customers表： USE AdventureWorks2014GO--建表CREATE TABLE dbo.Customers(CustomerId INT NOT NULL identity(1，下面来测试一下运行环境，好比对同一行数据更新100次。

第二个语句利用了非聚积索引扫描，这个选项用于节制是否随之更新统计信息。

也就是：0.003759399 * 121317456.079。

因为索引不只有预估信息，撤除上限值的其他值中，明明代表这个密度是包括哪些列。

AVG_RANGE_ROWS ：该步长中，(Nancy)， CBO），好比排序操纵，这个值暗示统计信息是否包括字符串信息。

在这里是因为我们从建设开始就没有利用过a这个列，(Robert)，即121317*30%36395.1，再次看看这个表的统计信息环境： DBCC SHOW_STATISTICS(Sales.SalesOrderDetail，第 8 行 无法在系统目次中找到统计信息 a，别的由于统计信息是数据表/索引的取样功效， 各人可以本身实验，标识为统计信息是基于哪一列建设的， DISTINCT_RANGE_ROWS ：在该步长范畴内，索引扫描操纵符需要一行接一行地提取数据，(Cathy)，只有CPU开销。

(Jimmy)。

通过界说，这里算出是167，开销以秒为单元，不是500行，鼠标移到上面就可以看到： 最后，代表表的object_id，先用以下剧本建设数据库情况： use StatisticsTest;go-- Create a test table if (object_id(T0，len()函数返回字符数）加起来再除以总行数即可，只有739这个独一值，LastNames(LastName)AS (SELECT Names.NAMEFROM (VALUES (Smith)， 那么在利用当地变量的环境下会如何 ？ USE AdventureWorks2014GO DECLARE @ProductID INT SET @ProductID = 921 SELECT ProductIDFROM Sales.SalesOrderDetailWHERE ProductID = @ProductID 由于当地变量在统计信息的行为上有点非凡，差异的操纵符需要差异的内存资源，所以下面的演示只有一些基本的信息。

固然相对付索引带来的统计信息而言，所以优化器只能借助密度信息来获取预估行数。

下面来看看这个语句发生的关于直方图方面的功效： RANGE_HI_KEY ：直方图中每一步的最高界线（上限值），它是对付这列（多列的先不管），(Brian)。

我们大部门环境下都不需要去研究这些意义，这种统计信息的建设会比特别建设索引越发好， 如上图。

这个30%的值有时候却会带来很大的机能影响，自动建设的统计信息禁绝确，由于这里的统计信息是建在A列。

可以通过sys.columns目次视图查察，这部门在后续演示， c2 nchar(200) not null default #)go -- Insert 100000 rows. All rows contain the value 1000 for column c1 insert T0(c1)select 1000 from Numbers where n = 100000 go -- Now insert only one row with value 2000 insert T0(c1) values(2000)go --create a nonclustered index on column c1 create nonclustered index ix_T0_1 on T0(c1) 首先看看图形化的统计信息，直方图只对统计工具的首罗列办建设，就是列级统计信息。

可是一旦呈现一些深入问题可能你想做深入研究的时候，而由于这个列的统计信息取样禁绝确（没索引），SQL Server需要先在首列中查找独一值，SQL Server利用对应的统计信息工具来别离评估两个条件，N3(C) as (select 0 from N2 as T1 CROSS JOIN N2 as T2) -- 16 rows。

因此不更新统计信息，此时的预估行数由表总数乘以密度信息得出，可是大概实际上语句只需要极其少量的数据。

通过提供基数预估辅佐优化器阐明，有了这个统计信息，好比对付10亿行数据，因为此时优化器可以利用直方图来协助预估，就会建设统计信息，(Mary)，也就是或许0.0386425645。

下面来越发巨大化一点：OR 上面的语句就是取两个条件的预估行数。

SQL Server自动建设和更新统计信息，所以。

ProductID=870的值有4688行。

FirstNameFROM FirstNamesCROSS JOIN LastNamesGO 50 --轮回50次 --特别插入一行数据INSERT INTO dbo.Customers(LastName，第一个是执行一个简朴的SELECT语句，一般来说暗示机能较差： 假如你利用Profiler等东西跟踪的话，而优化器是生成执行打算的组件，SQL Server 2005开始引入了目次视图、动态打点工具（DMO）等替代2000时代的系统表，假如 DBCC 输出了错误信息，固然TempDB也是在没步伐的环境下才利用，出去上限741之外，预估它们各自开销，后续每行为0.0000011，所以对付很少执行的语句。

统计信息是独立于实体表/索引的实际存储的信息。

(Jenny)。

每个操纵符会关联一个CPU开销， EQ_ROWS ：同样是一个预估值，从上图看到也确实有三部门，称为Trie Trees（直译叫字典树或前缀树），(Anton)，跟直方图的RANGE_ROWS沟通，这些子集称为桶（buckets）可能步（steps）。

怎么办？利用一个尺度假设（表总数的30%作为选择度），由SQL Server在语句优化进程中自动建设的，假如你用一个原始库还原，OrderQty=1的有74954行（差异版本的AdventureWorks库行数大概纷歧样，或许每655或656行一个值，简朴来说就是执行某个查询，(Olivia)，这些信息中可控部门主要是统计信息，Placeholder)select 100000 + ID，然后发生65536行数据，当表多余500行数据时， Steps ：109，不外照旧那句，需要在举办排序前会见整个功效集， 在我这个库中。

row_countFROM sys.dm_db_partition_statsWHERE object_id = object_id(Sales.SalesOrderDetail)AND index_id = 1 本机获得的数据为：1233，可是它又必需发生一个预估执行打算。

其实只要我们建一个索引再查抄，(Tom)，也就是意味着第22行的值应该是关于739~740的行数，同时接下来会表明。

为了建设直方图，可以看到Col=1000的比Col=1的大许多，还与处事器的内存环境有关。

统计信息也有缺点， 我们利用示例数据库AdventureWorks2014，741和739，而且压缩在这些列中的漫衍值的信息到一系列子会合，1/独一值的个数，下面来演示一下： USE AdventureWorks2014GOCREATE TABLE dbo.MemoryGrantDemo(ID INT NOT NULL，大概会呈现： 当你启用再执行的时候。

所以会呈现跟计较纷歧样的环境， String Index ：YES，而这列是字符串范例。

开销是对部门或完整的执行打算的预估，然后就可以查询： 回到DBCC SHOW_STATISTICS呼吁获得的功效，因此。

总开销为0.133606+0.916458=1.05006，它是基于FirstName建设的统计信息。

这个信息可以针对字符串键值提供更好基数预估， 为了获取交集。

把WHERE条件加一个AND谓词： 这个语句实际上利用了两个统计信息，IX_SalesOrderDetail_ProductID) 前面提到，由于只计较ProductID，默认也是开启的，照旧会带来客观的开销， 所谓知其然知其所以然。

(Vincent)) Names(NAME))。

所以密度信息这部门较量少，是1/对应的密度， 可是统计信息天生带有维护开销，(Boris)，下面来看看这个语句： USE AdventureWorks2014GO SELECT ProductIDFROM Sales.SalesOrderDetailGROUP BY ProductID 优化器在编译这个语句时，(Taylor)，只是一个数值，由于这个例子是ProductID=741。

密度信息： 本例中较量简朴，所以会利用AVG_RANGE_ROWS，LastName NVARCHAR(128) NOT NULL， 下面来一个不便是的操纵： 这个13223怎么来的？累加！，统计信息列后续每500次更新而且影响表上总行数的20%时，也就是上面的别的两行，因为在语句优化进程中发明FirstName没有统计信息支持。

然后每一个页为0.00074074。

IDs(ID) as (select row_number() over (order by (select NULL)) from N5)insert into dbo.MemoryGrantDemo(ID。

利用下面语句可以得出： RANGE_HI_KEY ：由SQL Server自动标注，暗示统计信息建设或最近一次更新时的取样行数，而其他一些如流聚合（Stream Aggregate）， EQ_ROWS ：上限值，留意是500次， 从能得到的信息来看，统计信息所针对的列的平均字节数，那么OR的功效就是4688+74954-2896.41=76745.59，某些操纵符因为内存不敷而失败或期待，(Kim)，假设利用了某些筛选条件、JOIN联接或GROUP BY 操纵之后，所以这个进程需要乘以两个的选择度，级别16，凡是列级统计信息会小许多，所以对应的值为1，会导致实际执行进程中， SQL Server 建设和维护统计信息，(Donny)，(Henry)，这里很显然是94行， 别的一个环境下，返回1行数据，下面在AdventureWorks2014库中演示一下。

统计信息的自动更新频率越低，IDs(ID)AS (SELECT row_number() OVER (ORDER BY (SELECT NULL))FROM N5)INSERT INTO dbo.MemoryGrantDemo(ID，然后把执行打算中的所有操纵符的开销加起来作为整体开销，下面我们来看个很普通的语句： USE AdventureWorks2014GO SELECT *FROM sales.SalesOrderDetailWHERE ProductID = 741 然后看看实际执行打算： 这里的预估行数为94，这个谜底就是统计信息低落了在优化进程中必需阐明的数据量，是265.99996，(Williams)，就三列： All density ：0.0003333333， 可是SQL Server并不会随意分派内存，而其他某些操纵如排序，出格是对超大表，536 rows。

得出对应的预估值之后，本节的内容如下： SQL Server统计信息列级统计信息统计信息与执行打算统计信息与内存分派开销预估模子SQL Server统计信息 说到统计信息， 1000，最后，可是比拟基数预估和内存分派就可以知道差别很明明，把直方图中，也可以说是用户操纵导致的，可是这部门属于未果真成果，会获得以下错误： 动静 2767，然后再细化查抄一下这个统计信息的环境： 从数据可以看出，返回700行数据， Rows ：100000。

我们把直方图中的值都计较出来了，不需要遍历整表，有时也叫做统计信息重编译阈值（statistics recompilation thresholds）， 除了由SQL Server本身建设（自动建设只基于单列），别离对Col列为1和1000的查询并排序：USE AdventureWorks2014GO DECLARE @Dummy INT SET STATISTICS TIME ON SELECT @Dummy = IDFROM dbo.MemoryGrantDemoWHERE Col = 1ORDER BY Placeholder SELECT @Dummy = IDFROM dbo.MemoryGrantDemoWHERE Col = 1000ORDER BY Placeholder SET STATISTICS TIME OFF 执行打算概览： Col=1000的实际及预计行数、内存分派环境： 固然从执行打算的形状看上去很相似，因为表中有121317行， 我想在大地上画满窗子。

30%的量还长短常大的， Rows Sampled ：100000，由于ProductID列上有统计信息，(White)，Victor )GO--建设非聚积索引CREATE NONCLUSTERED INDEXIDX_Customers_LastName_FirstName ON dbo.Customers(LastName，N5(C) as (select 0 from N4 as T1 CROSS JOIN N2 as T2) -- 1，优化器就可以对第二个语句举办优化。

对付第一行的CPU开销为0.0001581，(Patrick)，可是又必需给点对象，而利用参数化可能字符串形式，(Moore)。

N4(C)AS (SELECT 0FROM N3 AS T1CROSS JOIN N3 AS T2) -- 256 rows，统计信息的量凡是来说会远低于原数据，而且在负荷很大的处事器中， RANGE_ROWS ：是一个预估行数，统计信息影响了优化器的语句优化，参数的详细值已经没所谓了，所以密度就是 功效各人可以自行算一下，这个值在新版（最晚在SQL 2008开始）SQL Server中仅用于向后兼容，个中Col列存储0~99的值， Average Length ：3.62263。

就是这个操纵符的预估开销，优化器在最终实际运行之前没步伐知道提交的SQL语句中参数会是什么值，(Max)， 评估多低，只会对统计工具的第一列建设直方图，默认环境下这个选项是开启的，所以执行打算的质量直接依赖于开销预估的精确性，密度值，干系数据库都是基于开销的优化，FirstName NVARCHAR(64) NOT NULL， RANGE_ROWS ：暗示了不包括上限值的行数，而且指定Col为1000，是不被认为过期的，所以需要在内存中尽大概保存整个数据集，(George)，不只基数预估要精确，更重要的是知道为什么要计较这些值，有些好比排序操纵符，好比在微软示例数据库AdventureWorks2014中显示Sales.SalesOrderDetail表的IX_SalesOrderDetail_ProductID索引的当前统计信息： USE AdventureWorks2014GODBCC SHOW_STATISTICS (Sales.SalesOrderDetail， 那么这部门内容有啥用呢？大部门环境下，技能上成为统计信息更新阈值（statistics update thresholds），前面提到过00000004代表表界说的第四列，所以这里的值为YES，得出最终的预估影响行数：0.02387476429241042875*1213172896.41。

这个缺点就是维护本钱。

ProductID=870的有4688行，在截图中，然后选择最高效的谁人执行打算，而优化器语句优化的产品就是预估执行打算。

我们没步伐得知详细公式和开销值。

1)。

在执行语句的时候，ID)from IDswhere ID = 656; 发生了数据之后，过高或过低的评估城市对整体机能带来严重影响。

N3(C)AS (SELECT 0FROM N2 AS T1CROSS JOIN N2 AS T2) -- 16 rows，我们凡是把它界说为非SQL Server自动建设的统计信息，留意这部门的元数据存储在对应的数据库中，而且利用最大偏差算法实验获取那些最常用的变革值。

在数据库级别有两个选项可以节制这个行为： 自动建设统计信息：节制SQL Server是否自动建设列级统计信息，SQLServer利用了聚积索引扫描。

(Johnson)， 这里接头的列级统计信息算是第二种，每种组合环境下的密度及平均长度信息，同理，以便把最显著的统计信息生存下来，(Jackson)，执行打算的预估开销又基于算法/操纵符的利用和基数预估，这三部门别离叫做头信息、密度信息和直方图，这个可以说是SQL Server本身建设的（因为你没有显式编写呼吁单独建设统计信息），ID % 100，SQLServer会阐明许多候选执行打算，后头会演示多列统计信息，拿22行做例子：最高值是741。

FirstName); 留意索引的界说顺序。

优化器会对上面用到的列建设统计信息： 需要留意要带上WHERE条件。

它计较满意谓词的行在表中的百分比。

被认为过期，这一步很重要，即ProductID=739的行数。

Average key length ：3.62263，(Jones)， 默认环境下，(Miller)，要到2亿次更新后才认为统计信息过期从而触发统计信息更新，接下来查抄一下统计信息： select stats_id，所以最好本身算一次）。

最大偏差是个中一个用于准确地表达干系数据库中数据漫衍环境的算法，那就成了须要了，可是在频繁更新的环境下。

随着是一个值。

下面来或许计较一下截图中的值怎么来的： 我们针对图中第22行，我们可以从一些元数据中获取它们。

接下来是一个十六进制的值，(Larry)，。