当然索引视图亦非从没有过代价，在洗颈就戮程度上就义了数量写入的频率和冗余存款和储蓄，来换取查询的频率
以前大约介绍过索引视图的大器晚成部分特性
这一个主题素材的确郁闷了会儿，整个半天都在想以此难题，因为索引视图本人用的就少，现身此难点更是胡里胡涂，然则谷歌（Google卡塔 尔（阿拉伯语：قطر一下，还大概有一大把看似的主题材料
如下是在google的时候查到的，最先的作品是印度语印尼语，大致敬思如下，非直译。
下面说了，查询重写正是将基于原始表的查询语句，直接在索引视图上询问达成，那么就来看一下询问重写是怎样样子的？
上面来观看这么一个询问，SQL很显眼地是基于原始表做的询问，跟普通查询并无二致，
不过观察施行陈设就能够发觉：
这几个试行布署走了三个索引查找，首先很清楚，HeadTable上的CreateDate是绝非索引的，这里走的目录便是V_IndexViewTest上的CreatDate列上的目录
也便是在索引视图上成立的首个目录。
当然白皮书里有更详尽的牵线，里面索引视图相关的有些逻辑达成和剖析
参谋链接：
索引视图的询问提醒：with(noexpand) 强制不举行，OPTION (EXPAND
VIEWS)强制张开
按道理，索引视图固化结果集，並且遵照景况做了过滤，结果集是原来查询的一片段而已，
用相通的询问条件从索引视图做询问总结，走索引视图代价必然要比原始SQL低，通过强制不实行with(noexpand)提示，证实了这些估计
如下是挟持不张开索引视图的总计音讯，可以看到完全达到了预想的1S以内
本文出处：
总结：
最重大的难题在于，未有强制不展开索引视图（with(noexpand)提示卡塔 尔（阿拉伯语：قطر的景况下，为何平昔不走索引视图呢？
查询重写
索引视图的匹配（查询用索引视图代替而不走原始的根底表卡塔 尔（阿拉伯语：قطر是二个一定昂贵的操作，因而优化器试图透过其余办法飞速转移（生成试行安顿卡塔尔
假定优化器发生了三个相对优化的实践安顿，就足以尽快了结（不必继续生成其余实行安排卡塔尔
主题素材就在于：继续生成其余实践安排的代价要超过已转移的进行安插的代价
听上去有一些别扭，
前边举过这么叁个例证，举个例子便是花3分钟找到叁个相对优化的试行陈设，这些试行布署成功SQL的实行要求2分钟
与花10分钟的时候找到贰个最优化的试行布置，就算这几个试行安插完毕SQL的进行恐怕只须要0.5分钟，固然前者的实施安插更优，但全体代价更加大
优化器的重要对象是及早找到三个充裕好的执行布置（而非总是变化最佳的试行布置卡塔尔
讲话深入分析
常常听Oracle的同室聊起来物化视图，物化视图的效率之一正是足以兑现查询重写，听上去有少年老成种巨大上的痛感，
SQL Server也可以有相仿于Oracle物化视图的效果与利益，只不过叫做索引视图。
说真话，仍旧物化视图听上去相比适当，与平时视图比，物化视图正是平昔将数据存款和储蓄起来了
SQL Server中的索引视图也具备查询重写的意义，
所谓的询问重写，正是只要切合条件的数据在索引视图上，并且查询列都包涵在在索引视图上，此时能够直接通过查询索引视图来替代基于原始表的查询
本文粗浅地剖判了SQL Server
中的索引视图甚至索引视图带给的查询重写成效，通过索引视图固化基表的结果集，
能够在放任自流程度上升高查询效能，越发是在比超级大的多表join的时候，直接将原有结果存为叁个索引视图，
通过对索引视图查询来压缩表之间的join和IO来进步效能,不失为大器晚成种优化增选。
须要注意的是，SQL
Server的目录视图约束超级多，具体能够仿效链接丛书恐怕MSND，并非兼具的情景都得以使用索引视图来促成。
近日支出递交过来多少个询问计算的SQL，说是质量有标题，原来施行须求4-5分钟，那么些专门的学问本身对品质要求又相比较critical，期待是在1s以内
在用尽各类艺术之后（实施陈设，总结消息，索引，改写SQL，有的时候表拆分卡塔尔，依旧未有实质性的转移，
在观看SQL自己的风味之后，
有以下几天性状
1，查询语句全部为多表join，可是种种表本身的数额并不是可怜大，百万级
2，查询结果在主表上贰个非常大的岁月约束的数目开展Count的集纳操作
3，几张表之间除了连接条件，主要是扩充了一些比较复杂的逻辑运算（上面截图能够看见，没有多少IO，CPU时间却超级高卡塔 尔（英语：State of Qatar）
但是表的总是方式都是inner join，主要质量点就在于表关联之间的Hash
join之间的逻辑运算，参考下图（是实践安插的黄金时代局地卡塔 尔（阿拉伯语：قطر
那么将在求证一下，索引视图中的数据是哪些翻新的。
我们做如此几个测量试验，在基表，也等于DetailTable中询问一条数据，看看毕竟在施行陈设中发生了哪些
能够显著地收看，不独有是王DetailTable中写入了一条数据，同有的时候间，基于索引视图的查询也往索引视图中写入了一条数据，
因而得以放心地使用索引视图而没有需求顾虑索引视图中的数据和基表的数额不相符的标题。
在领抽出来原始的查询SQL，创造索引视图，并在索引视图上创制unique
cluster index和客观的nocluster index
通过索引视图改写原始的询问计算SQL语句，
改写后的SQL语句是二个索引视图代替原始的4张表，与此外一个物理表join，发掘功用上一贯不别的校正，
阅览改写后的SQL语句的实行布置，开掘跟原始SQL同样，并不曾走索引视图上的目录，恐怕说是用到索引视图，临时间以为好心塞，实在没招了
试行布置依然是漫漫一大段，然后仍然是一些个Hash
Join.参照他事他说加以调查下图，施行安排跟本文第二个截图一模二样
上边说了询问重写，要是条件允许，基于原始表的查询会直接从索引视图上来达成。
可能有人会不放心，毕竟数据都是基于物理表做增加和删除改的，而索引视图中的数据又是情理存在的，那就就能够有三个忧郁，基于视图的查询会不会不标准？
毕竟是笔者能够的二个询问，你私下认可给本身一定到索引视图上，查询结果会跟原始表查询同大器晚成吗?
小编手艺水平还很菜，说的难堪还请支出，多谢。
通过计算音讯开采，该SQL语句的物理IO并不高,表达索引未有何样难题，通过索引改过IO也许改善空间很单薄
时间根本花销在SQL语句的编译和的Hash join 运算
尝试改写依据SQL之后（纯改写SQL和依赖不时表拆分语句卡塔尔，开采仍然很难绕过Hash
join，首假设表之间的逻辑运算最为耗费时间
最终想到能够先将运算好的的数量物理存款和储蓄起来，然后改写查询的SQL语句落成等价的查询，
制止每回查询都做复杂的逻辑运算，应该能够有比很大的改良，于是就想开了索引视图
上边说了，有个别基于视图的查询，是直接定位到视图，从视图中询问结果重临的，如下图
最终多逼逼一句：
上边的白皮书实在看不懂，只是谷歌（Google卡塔尔国出来讲详细音信请看这么些参照他事他说加以考察资料,
这里只是从风貌去推想优化器在面前遭受索引视图的片段个性，驾驭到内在机制的风流倜傥部分特色，大概潜在的主题材料，以致对应的消除办法
这里又提开源软件了，别讲不开源了，即便是开源了，除了钱的因素，在工夫上，有多少人得以动一下这几个大型软件的为主代码？
作者并不是在黑开源软件啊，只是听有一些人会讲，开源好啊，有源码怎么什么，感觉够装13的，
我国除了bat等个别几家商厦做过改正源码，做过开源数据库的定制，试问还应该有多少家能够修正数据库源码然后上分娩应用
那么功能相比呢?如下截图，粗看起来，那几个效能差距照旧挺大的，可以预知，SQL
Server暗中认可选拔下，载作用上或然有早晚的构思的
方今在学MySQL，继续SQL
Server下去恐怕踏马要失掉工作了，开源，对大许多小卖部来讲，钱才是一个银锭因素呢，尼玛跑题了。
索引视图被开展(expand)的来头剖判
--创建两张表，一张表头，一张明细，仅仅作为DEMO使用
CREATE TABLE HeadTable
(
HeadId INT PRIMARY KEY ,
HeadInfo VARCHAR(50) ,
DataStatus TINYINT ,
CreateDate Datetime
)
GO
CREATE TABLE DetailTable
(
HeadId INT ,
DetailId INT identity(1,1) PRIMARY KEY ,
DatailInfo VARCHAR(50)
)
GO
--写入数据
DECLARE @i int = 0
WHILE @i<200000
BEGIN
INSERT INTO HeadTable values (@i,NEWID(),RAND()*10,GETDATE()-RAND()*100)
INSERT INTO DetailTable(HeadId,DatailInfo) VALUES (@i,NEWID())
SET @i=@i+1
END
GO
第叁次通过索引视图优化SQL语句，以致遭受的一些主题材料，记录一下。
使用索引视图本身并非一个高昂的操作，
而是与潜在索引视图中格外逻辑查询树确实三个代价比较大的一举一动，在查询涉及的视图在优化器优化在此以前曾经被开展
故而优化器并不知道你的询问是还是不是未被了索引视图，他看见的只是展开的查询树
那些浅显地讲正是：
让sqlserver知道，四个查询，能够用索引视图中的结果等价取代视图逻辑中原始的基表，是一个代价很大的进程
因为SQL
Server依照原有的底蕴表，生成意气风发种试行安排之后，就不去看清是或不是能够用索引视图做等价代替。
缘何查询会被重写
