并行操作的优化，急！！！

[wzszy]

本人的查询语句比较复杂，涉及6个表，其中几个表都是建有索引，在本人本机上（也就是一台普通的计算机），执行速度很快才1秒，查看了下执行计划，没有任何的并行操作，但是我在服务器上执行的时候，执行速度要9秒，查看下执行计划，有很多的并行操作，图标如下。
而这些并行操作占用了不少时间。请问该如何优化？？

[wzszy]

引用 21 楼 config_man 的回复:

楼主别废话，回答DBA_Huangzj的问题是王道

我回答了啊，最右面的执行14317行呗，别呢么凶嘛！！

[發糞塗牆]

引用 22 楼 wzszy 的回复:

引用 21 楼 config_man 的回复:

楼主别废话，回答DBA_Huangzj的问题是王道

我回答了啊，最右面的执行14317行呗，别呢么凶嘛！！

我说是seek还是scan

[config_man]

引用 22 楼 wzszy 的回复:

引用 21 楼 config_man 的回复:

楼主别废话，回答DBA_Huangzj的问题是王道

我回答了啊，最右面的执行14317行呗，别呢么凶嘛！！

人家问你的是index seek还是index scan，你个2货。

[發糞塗牆]

到处都是table scan，表越大性能问题越明显，可以先加个聚集索引到主键上，然后再考虑如何加非聚集索引

[wzszy]

引用 1 楼 DBA_Huangzj 的回复:

到处都是table scan，表越大性能问题越明显，可以先加个聚集索引到主键上，然后再考虑如何加非聚集索引

table scan的用的百分比也不多啊

[Q315054403]

还是2000，建议升级到2008 or 2012 限制并行数，Option (MAX DOP 1) 试下 优化器也不是次次准确，也是根据一些规则确定的

[發糞塗牆]

引用 2 楼 wzszy 的回复:

[quote=引用 1 楼 DBA_Huangzj 的回复:] 到处都是table scan，表越大性能问题越明显，可以先加个聚集索引到主键上，然后再考虑如何加非聚集索引

table scan的用的百分比也不多啊[/quote]并行的原因很有可能是因为数据集太大，而数据集过大又有可能是因为表扫描带来的不必要的数据，所以不能仅看一个操作符

[wzszy]

本机的执行计划

服务器的执行计划

黄大神你真好，一直关心我的帖子

[發糞塗牆]

两边的索引应该不同的吧，你对比一下

[霜寒月冷]

一直在关注这帖子，我估计是你两边创建表的语句不同.

[wzszy]

引用 23 楼 DBA_Huangzj 的回复:

引用 22 楼 wzszy 的回复:

引用 21 楼 config_man 的回复:

楼主别废话，回答DBA_Huangzj的问题是王道

我回答了啊，最右面的执行14317行呗，别呢么凶嘛！！

我说是seek还是scan

哦，明白了，是scan呢，昨天还没明白这两啥区别，不好意思哦

[wzszy]

引用 24 楼 config_man 的回复:

引用 22 楼 wzszy 的回复:

[quote=引用 21 楼 config_man 的回复:] 楼主别废话，回答DBA_Huangzj的问题是王道

我回答了啊，最右面的执行14317行呗，别呢么凶嘛！！

人家问你的是index seek还是index scan，你个2货。[/quote] 别那么凶，对女生温柔点，有点男人风度，学学DBA_Huangzj，又有才又稳重又有风度，ok？？

[發糞塗牆]

分别贴一下这些命令的结果，我要出门上班了，10点再看,我标了序号，你直接贴1是什么的，2是什么的就可以了 1. sp_help a_client_forzjs_hs 2. sp_help hs_forshs 3.sp_help a_client_forzjs_hs_foryear

[xiaoxiangqing]

这个跟数据量大小有关

[wzszy]

dba_huangzj版主，您真是个大好人
1如下：

2如下：

3如下：

[walkeeper]

默默的进来顶个帖顺便围观黄大神现场教学~

[發糞塗牆]

奇怪了，你的每个表只有一个聚集索引，怎么会出现index scan？有几个问题： 1、3个表有isty这列，但是第一个表是int，其他两个表是nvarchar(2)，这个有问题，第一个问题是，通常这种命名的都是标识两个值，一个是是，一个是否，原则上不建议作为索引键。如果我的猜想是对的，把这列从索引定义中去掉。第二个问题，类型不同，如果你这个列不需要存储多语言，也就是说只需要存储数字、英文或者简体中文，就换varchar/char，不要用n开头的类型。另外这三个表的这列数据类型统一起来，也就是用同一个数据类型，避免数据类型隐式转换带来的性能问题。 2. 2000我记得索引定义和where条件的列顺序有严格的关系，所以我建议3个表的join的on条件里面，on xx=xx and xx=xx这种，要按照索引的定义顺序来写，也就是f_id=f_id and sampleid=sampleid and zzrq=zzrq这样写，顺序不能边。 3. sapleid、f_id这两个类型，还是类型问题，确保数据类型及其长度完全一样。并且尽可能避免使用n开头的类型。如果纯粹的数字，那么用int或者更小的数据类型即可。 你先做了这些看看效果再做下一步改进吧。另外记得把执行计划贴出来。至于你说的你本机1秒服务器6秒，那应该是数据量的不同导致的，你可以对比一下你本机的执行计划服务器的执行计划

[wzszy]

引用 31 楼 DBA_Huangzj 的回复:

奇怪了，你的每个表只有一个聚集索引，怎么会出现index scan？有几个问题： 1、3个表有isty这列，但是第一个表是int，其他两个表是nvarchar(2)，这个有问题，第一个问题是，通常这种命名的都是标识两个值，一个是是，一个是否，原则上不建议作为索引键。如果我的猜想是对的，把这列从索引定义中去掉。第二个问题，类型不同，如果你这个列不需要存储多语言，也就是说只需要存储数字、英文或者简体中文，就换varchar/char，不要用n开头的类型。另外这三个表的这列数据类型统一起来，也就是用同一个数据类型，避免数据类型隐式转换带来的性能问题。 2. 2000我记得索引定义和where条件的列顺序有严格的关系，所以我建议3个表的join的on条件里面，on xx=xx and xx=xx这种，要按照索引的定义顺序来写，也就是f_id=f_id and sampleid=sampleid and zzrq=zzrq这样写，顺序不能边。 3. sapleid、f_id这两个类型，还是类型问题，确保数据类型及其长度完全一样。并且尽可能避免使用n开头的类型。如果纯粹的数字，那么用int或者更小的数据类型即可。 你先做了这些看看效果再做下一步改进吧。另外记得把执行计划贴出来。至于你说的你本机1秒服务器6秒，那应该是数据量的不同导致的，你可以对比一下你本机的执行计划服务器的执行计划

本机和服务器的数据量是一样的，本机的数据是我从服务器中导出去的。其他的我按照您的建议再试下

[wzszy]

引用 30 楼 walkeeper 的回复:

默默的进来顶个帖顺便围观黄大神现场教学~

dba_huangzj姓黄？本菇凉也姓黄，同性三分亲哦！

[發糞塗牆]

那你贴出你本机和服务器的执行计划来看看