时间:2021-07-01 10:21:17 帮助过:77人阅读
SELECT <所需列> --列太多,不一一列出
FROM study1
INNER JOIN series1
ON (study1.study_uid_id = series1.study_uid_id) --连接条件1
INNER JOIN image1 image1
ON (series1.series_uid_id = image1.series_uid_id) --连接条件2
where ((study1.user_group &8) != 0) --过滤条件1
and (series1.modality) not in (‘PR‘, ‘KO‘, ‘SR‘, ‘AU‘) --过滤条件2
and study1.study_uid =‘xxx‘ --过滤条件3
order by <排序列>; --列太多,不一一列出
第一部分:执行计划怎么看? 1.从右往左看 + 从上往下看 同一行的执行计划步骤,右边的先执行。同一列的执行步骤,上边的先执行。 SQL Server优化器根据统计信息生成执行计划,由返回行数和统计信息直方图决定执行的先后顺序和表连接方式,但是最基本的一点:过滤条件先于与连接条件执行还是要遵守的。 表连接方式包含nested loop,merge join,hash join这三种,三种连接方式的区别有兴趣可以bing搜索查看,与Oracle的三种表连接方式一样,这里不再详述。 步骤一:根据统计信息发现3个where条件中【过滤条件3】的选择性最好,预估行数最少,于是放在执行计划最右。由于study_uid是主键,无需回表(即无需书签查找),因此实际上步骤一的聚集索引查找同时还兼顾了【((study1.user_group &8) != 0)】这个【过滤条件2】。 步骤一对应过滤条件1、3。 步骤二:这个index seek是根据步骤一得到的study_uid_id结合【连接条件1】,对series_index进行的索引查找,series_index是series表的study_uid_id这列的索引。 步骤三:步骤一和步骤二通过【连接条件1】进行nested loop合成一个中间表,这个中间表中有从series_index中拿到的series表的主键值,有了这个主键值我们就可以在步骤四中进行针对series的主键键查找。 步骤三对应连接条件1。 步骤四:这一步的目的就是通过步骤三得到的series表主键值,到series的聚集索引中找到主键对应的完整的行,在完整行记录中找到对应【过滤条件2】的行记录。 步骤四对应过滤条件2。 步骤五:步骤三、四通过nested loop合成一个中间表,这里的nested loop并不对应某个连接条件,只是纯粹的为了生成一个中间表。 步骤六:根据步骤五中间表里的series_uid_id值到image1表中进行索引查找,image_index就是image1.series_uid_id列的索引。 步骤七:步骤五、六进行nested loop生成中间表,这个中间表中含有image1表的主键值,这个主键值是执行步骤六时从image_index中拿到的。拿到这主键值我们就可以在步骤八中去取到最终我们需要的所有image1表的列了。 步骤七对应连接条件2。 步骤八:根据步骤七中间表中的image1主键值,到image1的主键聚集索引中去取我们需要的image1的列数据。 步骤九:步骤七、八进行nested loop生成最后的中间表。 步骤十:对步骤九中生成的中间表进行排序。 最终,我们就取到了需要的、排序好的所有数据。 2.查看每一步的详细信息 在出现错误的执行计划时,有时我们需要判断为什么优化器选错了执行计划,由于选错执行计划很有可能导致SQL语句变慢,因此搞清其中的原因是很有必要的。 将鼠标移到每一个执行计划node,会出现如下图所示的详细信息。 我们需要关注的主要有以下几点:
SQL Server 执行计划解析
标签:oracle 结合 oda 数据 ... logic 连接方式 逻辑运算 ati