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

wzszy 2014-09-02 11:19:07
本人的查询语句比较复杂，涉及6个表，其中几个表都是建有索引，在本人本机上（也就是一台普通的计算机），执行速度很快才1秒，查看了下执行计划，没有任何的并行操作，但是我在服务器上执行的时候，执行速度要9秒，查看下执行计划，有很多的并行操作，图标如下。
而这些并行操作占用了不少时间。请问该如何优化？？
...全文
413 38 打赏 收藏 转发到动态 举报
写回复
用AI写文章
38 条回复
切换为时间正序
请发表友善的回复…
发表回复
發糞塗牆 2014-09-03
  • 打赏
  • 举报
 回复
那你贴出你本机和服务器的执行计划来看看
wzszy 2014-09-03
  • 打赏
  • 举报
 回复
引用 30 楼 walkeeper 的回复:
默默的进来顶个帖顺便围观黄大神现场教学~
dba_huangzj姓黄？本菇凉也姓黄，同性三分亲哦！
wzszy 2014-09-03
  • 打赏
  • 举报
 回复
引用 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秒，那应该是数据量的不同导致的，你可以对比一下你本机的执行计划服务器的执行计划
本机和服务器的数据量是一样的，本机的数据是我从服务器中导出去的。其他的我按照您的建议再试下
發糞塗牆 2014-09-03
  • 打赏
  • 举报
 回复
奇怪了，你的每个表只有一个聚集索引，怎么会出现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秒，那应该是数据量的不同导致的，你可以对比一下你本机的执行计划服务器的执行计划
walkeeper 2014-09-03
  • 打赏
  • 举报
 回复
默默的进来顶个帖顺便围观黄大神现场教学~
wzszy 2014-09-03
  • 打赏
  • 举报
 回复
dba_huangzj版主，您真是个大好人
1如下：

2如下：

3如下：
xiaoxiangqing 2014-09-03
  • 打赏
  • 举报
 回复
这个跟数据量大小有关
發糞塗牆 2014-09-03
  • 打赏
  • 举报
 回复
分别贴一下这些命令的结果，我要出门上班了，10点再看,我标了序号，你直接贴1是什么的，2是什么的就可以了 1. sp_help a_client_forzjs_hs 2. sp_help hs_forshs 3.sp_help a_client_forzjs_hs_foryear
wzszy 2014-09-03
  • 打赏
  • 举报
 回复
引用 24 楼 config_man 的回复:
引用 22 楼 wzszy 的回复:
[quote=引用 21 楼 config_man 的回复:] 楼主别废话，回答DBA_Huangzj的问题是王道
我回答了啊，最右面的执行14317行呗，别呢么凶嘛！！
人家问你的是index seek还是index scan，你个2货。[/quote] 别那么凶，对女生温柔点，有点男人风度，学学DBA_Huangzj，又有才又稳重又有风度，ok？？
wzszy 2014-09-03
  • 打赏
  • 举报
 回复
引用 23 楼 DBA_Huangzj 的回复:
引用 22 楼 wzszy 的回复:
引用 21 楼 config_man 的回复:
楼主别废话，回答DBA_Huangzj的问题是王道
我回答了啊，最右面的执行14317行呗，别呢么凶嘛！！
我说是seek还是scan
哦，明白了，是scan呢，昨天还没明白这两啥区别，不好意思哦
霜寒月冷 2014-09-03
  • 打赏
  • 举报
 回复
一直在关注这帖子，我估计是你两边创建表的语句不同.
發糞塗牆 2014-09-03
  • 打赏
  • 举报
 回复
两边的索引应该不同的吧，你对比一下
wzszy 2014-09-03
  • 打赏
  • 举报
 回复
本机的执行计划

服务器的执行计划

黄大神你真好，一直关心我的帖子
發糞塗牆 2014-09-02
  • 打赏
  • 举报
 回复
引用 2 楼 wzszy 的回复:
[quote=引用 1 楼 DBA_Huangzj 的回复:] 到处都是table scan，表越大性能问题越明显，可以先加个聚集索引到主键上，然后再考虑如何加非聚集索引
table scan的用的百分比也不多啊[/quote]并行的原因很有可能是因为数据集太大，而数据集过大又有可能是因为表扫描带来的不必要的数据，所以不能仅看一个操作符
Q315054403 2014-09-02
  • 打赏
  • 举报
 回复
还是2000，建议升级到2008 or 2012 限制并行数，Option (MAX DOP 1) 试下 优化器也不是次次准确，也是根据一些规则确定的
wzszy 2014-09-02
  • 打赏
  • 举报
 回复
引用 1 楼 DBA_Huangzj 的回复:
到处都是table scan，表越大性能问题越明显，可以先加个聚集索引到主键上，然后再考虑如何加非聚集索引
table scan的用的百分比也不多啊
發糞塗牆 2014-09-02
  • 打赏
  • 举报
 回复
到处都是table scan，表越大性能问题越明显，可以先加个聚集索引到主键上，然后再考虑如何加非聚集索引
config_man 2014-09-02
  • 打赏
  • 举报
 回复
引用 22 楼 wzszy 的回复:
引用 21 楼 config_man 的回复:
楼主别废话，回答DBA_Huangzj的问题是王道
我回答了啊，最右面的执行14317行呗，别呢么凶嘛！！
人家问你的是index seek还是index scan，你个2货。
發糞塗牆 2014-09-02
  • 打赏
  • 举报
 回复
引用 22 楼 wzszy 的回复:
引用 21 楼 config_man 的回复:
楼主别废话，回答DBA_Huangzj的问题是王道
我回答了啊，最右面的执行14317行呗，别呢么凶嘛！！
我说是seek还是scan
wzszy 2014-09-02
  • 打赏
  • 举报
 回复
引用 21 楼 config_man 的回复:
楼主别废话，回答DBA_Huangzj的问题是王道
我回答了啊，最右面的执行14317行呗，别呢么凶嘛！！
加载更多回复（17）
java 8实战 清晰带书签
关于本书 简单地说，Java 8中的新增功能是自Java 1.0发布18年以来，Java发生的最大变化。没有去掉 任何东西，因此你现有的Java代码都能工作，但新功能提供了强大的新语汇和新设计模式，能帮 助你编写更清楚、更简洁的代码。就像遇到所有新功能时那样，你一开始可能会想：“为什么又 要去改我的语言呢？”但稍加练习之后，你就会发觉自己只用预期的一半时间，就用新功能写出 了更短、更清晰的代码，这时你会意识到自己永远无法返回到“旧Java”了。 本书会帮助你跨过“原理听起来不错，但还是有点儿新，不太适应”的门槛，从而熟练地进 行编程。 “也许吧，”你可能会想，“可是Lambda、函数式编程，这些不是那些留着胡子、穿着凉鞋的 学究们在象牙塔里面琢磨的东西吗？”或许是的，但Java 8中加入的新想法的分量刚刚好，它们 带来的好处也可以被普通的Java程序员所理解。本书会从普通程序员的角度来叙述，偶尔谈谈“这 是怎么来的”。 “Lambda，听起来跟天书一样！”是的，也许是这样，但它是一个很好的想法，让你可以编 写简明的Java程序。许多人都熟悉事件处理器和回调函数，即注册一个对象，它包含会在事件发 生时使用的一个方法。Lambda使人更容易在Java中广泛应用这种思想。简单来说，Lambda和它 的朋友“方法引用”让你在做其他事情的过程中，可以简明地将代码或方法作为参数传递进去执 行。在本书中，你会看到这种思想出现得比预想的还要频繁：从加入作比较的代码来简单地参数 化一个排序方法，到利用新的Stream API在一组数据上表达复杂的查询指令。 “流（stream）是什么？”这是Java 8的一个新功能。它们的特点和集合（collection）差不 多，但有几个明显的优点，让我们可以使用新的编程风格。首先，如果你使用过SQL等数据库 查询语言，就会发现用几行代码写出的查询语句要是换成Java要写好长。Java 8的流支持这种简 明的数据库查询式编程——但用的是Java语法，而无需了解数据库！其次，流被设计成无需同 时将所有的数据调入内存（甚至根本无需计算），这样就可以处理无法装入计算机内存的流数据 了。但Java 8可以对流做一些集合所不能的优化操作，例如，它可以将对同一个流的若干操作组 合起来，从而只遍历一次数据，而不是花很大代价去多次遍历它。更妙的是，Java可以自动将 流操作并行化（集合可不行）。 “还有函数式编程，这又是什么？”就像面向对象编程一样，它是另一种编程风格，其核心 是把函数作为值，前面在讨论Lambda的时候提到过。 Java 8的好处在于，它把函数式编程中一些最好的想法融入到了大家熟悉的Java语法中。有 了这个优秀的设计选择，你可以把函数式编程看作Java 8中一个额外的设计模式和语汇，让你可 以用更少的时间，编写更清楚、更简洁的代码。想想你的编程兵器库中的利器又多了一样。 当然，除了这些在概念上对Java有很大扩充的功能，我们也会解释很多其他有用的Java 8功 能和更新，如默认方法、新的Optional类、CompletableFuture，以及新的日期和时间API。 别急，这只是一个概览，现在该让你自己去看看本书了
收获不知Oracle
200多M 作者梁敬彬、梁敬弘 上篇　开启惊喜之门——带意识地学Oracle 第1章意识，少做事从学习开始 2 1.1 选择先学什么颇有学问 2 1.1.1 梁老师课堂爆笑开场 2 1.1.2 看似跑题的手机分类 4 1.1.3 学什么先了解做什么 5 1.2 善于规划分类才有效果 7 1.2.1 分类与角色密切相关 7 1.2.2 角色自我认识有讲究 9 1.3 明白学以致用方有意义 11 第2章震惊，体验物理体系之旅 13 2.1 必须提及的系列知识 13 2.2 物理体系从老余开店慢慢铺开 16 2.2.1 老余的三个小故事 16 2.2.1.1 顾客的尺寸 16 2.2.1.2 有效的调整 17 2.2.1.3 记录的习惯 18 2.2.2 体系结构原理初探 20 2.2.2.1 从一普通查询SQL说起20 2.2.2.2 老余故事终现用心良苦23 2.2.2.3 一起体会Oracle代价 27 2.2.3 体系结构原理再探 30 2.2.3.1 从一普通更新语句说起30 2.2.3.2 体系结构中提交的探讨34 2.2.3.3 劳模的评选 38 2.2.3.4 回滚的研究 40 2.2.3.5 一致的查询 43 2.2.3.6 一致读的原理46 2.2.3.7 实践的体会 49 2.3 体系学习让SQL性能提升千倍 65 2.3.1 一起探索体系学习的意义 65 2.3.1.1 同学们不知所学何用 66 2.3.1.2 实际上大有用武之地 67 2.3.2 单车到飞船的经典之旅 70 2.3.2.1 未优化前，单车速度 70 2.3.2.2 绑定变量，摩托速度 72 2.3.2.3 静态改写，汽车速度 74 2.3.2.4 批量提交，动车速度 75 2.3.2.5 集合写法，飞机速度 77 2.3.2.6 直接路径，火箭速度 78 2.3.2.7 并行设置，飞船速度 79 2.3.3 精彩的总结与课程展望 80 2.3.3.1 最大的收获应该是思想80 2.3.3.2 老师的课程展望与规划81 第3章神奇，走进逻辑体系世界 84 3.1 长幼有序的逻辑体系 84 3.2 逻辑体系从老余养殖细细说起 85 3.2.1 农场之体系逻辑结构 85 3.2.2 农场之BLOCK漫谈89 3.2.3 农场之区与段 91 3.2.4 农场之表空间的分类 93 3.2.4.1 表空间与系统农场93 3.2.4.2 表空间与临时农场93 3.2.4.3 表空间与回滚农场94 3.2.5 逻辑结构之初次体会 94 3.2.5.1 逻辑结构之BLOCK 94 3.2.5.2 逻辑结构之TABLESPACE 95 3.2.5.3 逻辑结构之USER 97 3.2.5.4 逻辑结构之EXTENT 97 3.2.5.5 逻辑结构之SEGMENT 98 3.2.6 逻辑结构之二次体会 100 3.2.6.1 BLOCK的大小与调整 100 3.2.6.2 PCTFREE参数与调整 101 3.2.6.3 PCTFREE与生效范围 102 3.2.6.4 EXTENT尺寸与调整 103 3.2.7 逻辑结构之三次体会 104 3.2.7.1 已用与未用表空间情况104 3.2.7.2 表空间大小与自动扩展105 3.2.7.3 回滚表空间新建与切换109 3.2.7.4 临时表空间新建与切换111 3.2.7.5 临时表空间组及其妙用114 3.3 课程结束你给程序安上了翅膀 117 3.3.1 过度扩展与性能 117 3.3.2 PCTFREE与性能120 3.3.3 行迁移与优化 123 3.3.4 块的大小与应用 124 第4章祝贺，表的设计成就英雄 131 4.1 表的设计之五朵金花 131 4.2 表的特性从老余一家展开描述 132 4.2.1 老余一家各施所长 132 4.2.2 普通堆表不足之处 132 4.2.2.1 表更新日志开销较大 133 4.2.2.2 delete无法释放空间 136 4.2.2.3 表记录太大检索较慢 139 4.2.2.4 索引回表读开销很大 140 4.2.2.5 有序插入却难有序读出143 4.2.3 奇特的全局临时表 146 4.2.3.1 分析全局临时表的类型146 4.2.3.2 观察各类DML的REDO量 147 4.2.3.3 全局临时表两大重要特性 149 4.2.4 神通广大的分区表 153 4.2.4.1 分区表类型及原理155 4.2.4.2 分区表最实用的特性 165 4.2.4.3 分区索引类型简述176 4.2.4.4 分区表之相关陷阱177 4.2.5 有趣的索引组织表 184 4.2.6 簇表的介绍及应用 187 4.3 理解表设计的你成为项目组英雄 189 第5章惊叹，索引天地妙不可言 191 5.1 看似简单无趣的索引知识 191 5.2 索引探秘从小余缉凶拉开帷幕 192 5.2.1 BTREE索引的精彩世界 192 5.2.1.1 BTREE索引结构图展现192 5.2.1.2 到底是物理还是逻辑结构 194 5.2.1.3 索引结构三大重要特点198 5.2.1.4 插播小余缉凶精彩故事201 5.2.1.5 妙用三特征之高度较低203 5.2.1.6 巧用三特征之存储列值219 5.2.1.7 活用三特征之索引有序248 5.2.1.8 不可不说的主外键设计265 5.2.1.9 组合索引高效设计要领272 5.2.1.10变换角度看索引的危害289 5.2.1.11如何合理控制索引数量295 5.2.2 位图索引的玫瑰花之刺 297 5.2.2.1 统计条数奋勇夺冠297 5.2.2.2 即席查询一骑绝尘302 5.2.2.3 遭遇更新苦不堪言306 5.2.2.4 重复度低一败涂地309 5.2.2.5 了解结构真相大白311 5.2.3 小心函数索引步步陷阱 315 5.2.3.1 列运算让索引失去作用315 5.2.3.2 函数索引是这样应用的317 5.2.3.3 避免列运算的经典案例319 5.3 索引让一系列最熟悉的SQL飞起来了 325 第6章经典，表的连接学以致用 327 6.1 表的连接之江南三剑客 327 6.2 三大类型从小余跳舞一一道来 328 6.2.1 跳舞也能跳出连接类型 328 6.2.1.1 感觉怪异的嵌套循环 328 6.2.1.2 排序合并及哈希连接 329 6.2.2 各类连接访问次数差异 330 6.2.2.1 嵌套循环的表访问次数330 6.2.2.2 哈希连接的表访问次数337 6.2.2.3 排序合并的表访问次数340 6.2.3 各类连接驱动顺序区别 341 6.2.3.1 嵌套循环的表驱动顺序341 6.2.3.2 哈希连接的表驱动顺序343 6.2.3.3 排序合并的表驱动顺序345 6.2.4 各类连接排序情况分析 347 6.2.4.1 除嵌套循环都需排序 347 6.2.4.2 排序只需取部分字段 347 6.2.4.3 关于排序的经典案例 349 6.2.5 各类连接限制场景对比 350 6.2.5.1 哈希连接的限制 350 6.2.5.2 排序合并的限制 353 6.2.5.3 嵌套循环无限制 355 6.3 你动手装备的表连接威震三军 355 6.3.1 嵌套循环与索引 356 6.3.2 哈希连接与索引 362 6.3.3 排序合并与索引 363 下篇飞翔意识天空——思想与案例的分享 第7章搞定！不靠技术靠菜刀 368 7.1 SQL被一刀剁了 369 7.2 整个模块丢弃了 370 7.3 调用次数减少了 371 7.4 排序不再需要了 372 7.5 大表砍成小表了 373 7.6 排重操作消失了 373 7.7 插入阻碍小多了 374 7.8 迁移事情不做了 375 第8章升级！靠技术改隐形刀 377 8.1 大表等同小表了 378 8.2 大表切成小表了 379 8.3 索引变身小表了 380 8.4 删除动作不做了 380 8.5 清表角度变换了 381 8.6 提交次数缩减了 382 8.7 迁移越来越快了 384 8.8 SQL语句精简了 385 第9章提问，也是智慧的体现 391 9.1 描述要考虑周全 392 9.2 用词要尽量准确 393 9.3 说明要力求简洁 394 9.4 问过的避免再问 396 9.5 能搜能试不急问 396 第10章买鱼，居然买出方法论 398 10.1 小余买鱼系列故事 398 10.1.1 诊断与改进 398 10.1.2 需求与设计 401 10.1.3 资源的利用 403 10.1.4 真正的需求 404 10.2 买鱼买出了方法论 405 10.2.1 一套流程 405 10.2.2 两大法宝 407 10.3 方法论的应用案例 408 10.3.1 从我们的这一套流程说起 408 10.3.1.1 诊断 408 10.3.1.2 改进优化（首次优化） 409 10.3.1.3 需求与设计（再次优化） 410 10.3.1.4 资源利用（花絮） 412 10.3.2 案例映衬了经典两大法宝 412 第11章宝典，规范让你少做事 414 11.1 抓狂，为何事总忙不完 415 11.1.1 技术能力不足的新人们 415 11.1.2 不懂提问智慧的求助者 415 11.1.3 产生各种失误的粗心者 416 11.1.3.1 啊，小黄的DDL惹祸 416 11.1.3.2 惨，老师登错环境了 417 11.1.3.3 糟，小罗忘操作…… 417 11.1.4 解决问题缓慢的技术员 419 11.1.4.1 优化效率低下的小高 419 11.1.4.2 为何老师能快速解决 420 11.1.5 陷入种种困境的开发者 422 11.1.5.1 超长SQL使小郑烦恼 422 11.1.5.2 缺少注释让小叶沮丧 422 11.1.6 总是考虑不全的设计者 423 11.1.6.1 未提前规划的王工 423 11.1.6.2 不了解特性的刘工 424 11.2 淡定，规范少做无谓事 425 11.2.1 学习规范——促成新人快速成长 426 11.2.2 求助规范——引导求助不再迷糊 427 11.2.3 操作规范——协助粗心者不犯错 428 11.2.4 流程规范——保障问题快速解决 429 11.2.4.1 动态整体 429 11.2.4.2 动态局部 432 11.2.4.3 静态整体 439 11.2.4.4 静态局部 448 11.2.5 开发规范——让开发者驾轻就熟 451 11.2.5.1 SQL编写规范 452 11.2.5.2 PL/SQL编写规范 455 11.2.6 设计规范——助设计者运筹帷幄 457 11.2.6.1 表规范 458 11.2.6.2 索引规范 461 11.2.6.3 环境参数规范 467 11.2.6.4 命名规范 469
技术干货 | 如何用MindSpore优化器加速收敛高度逼近最优值？
深度概率学习系列已经介绍完啦，接下来给大家分享下高阶优化器系列，想要看前一个系列的小伙伴们戳下面的地址哦☟本文先跟大家分享下常用的一二阶优化器。深度学习训练过程可以看成是loss下降过程，而每一次loss如何下降，就是优化器做的事情。。优化器可以分为一阶优化器和二阶优化器，深度学习中常用的优化器是一阶优化器，如SGD（Stochastic Gradient Descent）和其算法变种，二阶优化器近年来也被用于深度学习训练，并取得了不错的结果。接下来我们就具体展开来看一下。
大厂之路一由浅入深、并行基础、源码分析一 “J.U.C.L”之重入锁(ReetrantLock)、公平锁、非公平锁及Condition的源码级分析（基于AQS、独占锁）（JDK不同版本对比）
看本文章前，希望先看以下相关文章： 大厂之路一由浅入深、并行基础、源码分析一synchronized关键字,以及相应优化！！ 大厂之路一由浅入深、并行基础、源码分析一Unsafe类、varHandle类、无锁CAS、及其并发包Atomic 大厂之路一由浅入深、并行基础、源码分析一 “JUC锁”之框架 以及 LOCK锁较synchronized的改进 大厂之路一由浅入深、并行基础、源码分析一 “JUC锁”之重入锁(ReetrantLock)、公平锁、非公平锁及Condition的应用 部分文章总结自：
ConcurrentBag 听过没？好家伙高并发知识点十分密集！一种并发优化思路！
面试官问高并发的优化思路？可以试试这个
疑难问题

22,210

社区成员

121,726

社区内容

发帖
与我相关
我的任务
社区描述
MS-SQL Server 疑难问题
社区管理员
  • 疑难问题社区
  • 尘觉
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告
暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章