【大话IT】DBA的痛：SQL优化的讨论（获奖名单已公布）

bellman

还挺热闹，我也来写两句：
1、你觉得开发应该深入学习数据库吗？是的话你觉得什么层次比较好，不是的话，为什么?
  对我来说，这还是问题么？ 不过实际情况可能是现在有些开发分工已经非常细，比如有些专门做前端页面，甚至是前端设计的（也叫开发），对数据库可能就不会有啥要求。 不过对于后台和数据库打交道的开发而言，这确实不应该是问题，这是必须滴。 不谋全局者，不足以谋一隅。虽然现在分工很细了，数据库的设计可能是有专门的开发DBA来做，但如果不懂得设计的初衷和思路，又怎么能够开发出优秀的系统？ 对于不求上进混日子的人来说要求就有些高了。

2、在你工作中遇到什么样恶心的sql，吐槽下?
  写的SQL 我估计过上两个星期拿出来他自己都搞不懂。各类嵌套和连接，生怕别人说他不懂数据库，你才不懂，我写的SQL你都看不懂。
  不懂分区，听说分区表在查询时速度快很多，那我们也搞个分区表，你倒是去网上查查学学啊，分区表是建了，结果查询条件中根本没有使用分区键。拿着五角号码字典查拼音？
   现在流行线程编程啊，人家高手都用线程，我要是不用线程显得我太low，十多个线程一开都照着一个表使劲，原来一个人干活，现在我给你十多个人一起干，系统肯定快上天。
   还有碰到一个入行数十年的资深牛叉架构师，流水记录不删除，没有历史表，没过多久，已经超10亿条记录，求大神指点该咋整（10亿记录对运营商而言可能是毛毛雨，求一般解法，投钱买买买就不要说了）。

3、你觉得当sql 到达设么层次的时候，你需要让开发必须改sql？
   这个确实要区分不同情况，没有一定之规，还要受其他外界因素的影响。 开发一般会拿工作量巨大、风险高等来搪塞。

4、大家有没有为了sql跟开发急眼的时候，分享下。
   关键是着急得有用你才能急，要不就是干着急。 去现场定位到问题模块甚至具体SQL，不过现场说这是大牛设计滴，文档也木有，改不了。改不了就改不了，那就继续让客户骂死，把客户惹急眼把公司扫地出门，总不能系统DBA冲上去给人家改代码么？ 有能力改好么？改好了你也得罪了一大批。    所以这个世界其实很简单，大家各按其职，守其责，世界就太平。问题是有些人非要把事情搅乱了，把事情混在一起说，所以称之为“混”蛋。

kisscactus

1、        你觉得开发应该深入学习数据库吗？是的话你觉得什么层次比较好，不是的话，为什么?
a.        如果需要依赖数据库完成复杂业务逻辑处理，特别是开发并发性较高的OLTP系统，这个岗位的人员应该深入学习数据库开发知识和基本的调优知识。
b.        如果开发岗位分明，有专门的数据库开发人员和应用开发人员，各自提供接口，这样非数据库开发人员不必要深入学习数据库相关知识，若要系统长期、较稳定的运行，数据库开发人员很有必要深入学习所涉及的数据库。
2、在你工作中遇到什么样恶心的sql，吐槽下?
无数，列举一二
a.        过于频繁的使用不必要游标: Select xxxx from dual; 每小时执行千万次级别。因为程序里面调用类似select sysdate into v_date from dual;
b.        为了简便乱用函数导致无法走索引：TRUNC(XXXX_YM)  <=  TRUNC(TO_DATE(TO_CHAR(SYSDATE + 1,  'yyyy-mm-dd'), 'yyyy-mm-dd')); TRUNC(NVL(XXXX_TM, SYSDATE)) <= TRUNC(LAST_DAY(ADD_MONTHS(LAST_DAY(SYSDATE) + 1, -2))) 等等
c.        Update没有where条件，导致日志一小时切换98次，且写得比较不易发现，在awr报告中也没能体现。Update table_name a set a.col1=(select b.col from table2 b where a.colN=b.colM and b.colR in (xxxx) and …);
d.        为了防止数据被同时更新，且是唯一约束更新，用for update先锁住再更新的。
e.        集合操作乱用的，distinct乱用的，where 1=1再各种拼接的。-------where 1=1在多个系统都见到过（各行各业的），多因为为了后续好拼接and而生，没有必传条件的话，就不知道where后面接什么，这个遇到的坑不少。
f.  分区表不加分区条件读取的
……

3、你觉得当sql 到达设么层次的时候，你需要让开发必须改sql？
客户反馈问题，操作反应慢，需要的工作、流程等不能按时完成。要考虑到长期、较稳定的情况，最好是对SQL有审核
4、大家有没有为了sql跟开发急眼的时候，分享下。
相对较少。与分工、业务了熟悉程度、问题紧急程度有关系，讨论、争论是避免不了的，好的写法并不一定立即体现出效果，整改比较麻烦的话如果开发要我们回答可提高性能多少，这个量化比较难做。

531968912

1、你觉得开发应该深入学习数据库吗？是的话你觉得什么层次比较好，不是的话，为什么?
    我认为开发dba和运维dba的方向不同，开发dba应该侧重开发技术方面的，但同时oracle体系结构要深入的学习一下；
2、在你工作中遇到什么样恶心的sql，吐槽下?
   遇到最恶心的sql是多个unionall相关联，特别消耗cpu，内存，很是郁闷，现在还没有找到解决放啊；
3、你觉得当sql 到达设么层次的时候，你需要让开发必须改sql？
     逻辑存在bug时，或者是很消耗资源，有更好的sql写法时；
4、大家有没有为了sql跟开发急眼的时候，分享下。
     有的，怎么可能会没有呢，但是静下心来，仍然要和开发心平气和的进行沟通，大家都是为了共同的事业吗

风铃中の鬼

1、你觉得开发应该深入学习数据库吗？是的话你觉得什么层次比较好，不是的话，为什么?

我个人希望开发深入学习数据库，但是实际情况是我还没见过深入学习数据库的开发。。。
原因基本有两个：
一是没有精力，国内的公司大多没有留给开发很多的自学的时间，在有限的业余时间内还愿意精进自己擅长的领域就已经很了不起了，同时还要求开发深入学数据库确实强人所难。
二是没有兴趣，大多做开发的人对数据库都缺乏兴趣，在这个需要兴趣驱动的行业里打滚，这点还是满重要的。

所以我个人虽然"希望",但其实理性说的话，我认为开发没有一定要深入学习数据库的必要，但是，浅学还是有必要的，数据库原理不必理解，写SQL的话甚至基本的行列转换也可以不会，但开发人员最起码应该了解两个东西：
一是索引，要知道索引的原理以及让多数情况下，让SQL走索引的必要性，了解最常见的2,3种会导致不走索引的SQL写法。
二是要了解SQL能做到什么，什么是SQL做不到的，我经常见到开发人员自认为SQL做不到，所以用复杂的程序去实现某个功能，反过来的例子也有，一些开发或需求分析人员总觉得SQL能做到，然后冒然的从客户那里把需求谈妥。所以说开发和需求人员没必要深入学习，但有必要了解数据库的能力所及

2、在你工作中遇到什么样恶心的sql，吐槽下?

我遇到过的，主要就是两个：
一是滥用标量子查询的，尤其很多半吊子数据库开发人员，自打知道了子查询也可以写在SELECT里之后好像遇到救世主一样，我见过最夸张的，一个SQL几乎所有字段都是标量子查询，然后跑不出来找我优化，这能快都新鲜了，这就是典型的基础没打好就去玩高端写法的后果。
第二个是一次分组函数rollup的问题，这个凭良心说不怪开发，事发原因是某个需求要把oracle版SQL改成informix版实现，其实需求本身很简单，就是要带上成吨的各种合计小计，oracle的SQL用了rollup，但没有同样功能的另一个库就愁人了，我自己都不记得当时写了多少个UNION ALL，这里只能吐槽别的数据库对SQL的支持太差

3、你觉得当sql 到达设么层次的时候，你需要让开发必须改sql？
关于这点，其实我想说作为负责优化SQL的人，通常都只能在"事后"才拿到SQL，毕竟你不能要求开发人员写的每个SQL都先拿给你评审，在大公司的话这点尤其没辙，开发人员每天写出来的SQL的数量足以占用有限的DBA所有的工作时间，因此我只有一个条件，不管什么层次，SQL慢就必须改。快的话就一切OK。

4、大家有没有为了sql跟开发急眼的时候，分享下。
没有。。工作中心态很重要，虽然偶尔会拿到让人抓狂的SQL，但实在没必要跟开发急眼，这跟刚才第一点很有关系，你实在不能要求开发人员有很强的SQL能力，而作为专家的我们，优化这些SQL就是你的工作职责，说句不中听的，你总抱怨开发人员的SQL写的糟糕给你添麻烦，那如果开发人员都牛逼到写SQL不需要你出马优化的程度，那公司削你两成的薪水是不是也合情合理呢

peter1166

我也来吐槽一下，只吐槽一个吧。 只是个人观点。

跟开发急眼... ...

急眼犯不上， 但急眼前有没有想过下面这几个问题。

1. 你设计的表结构真的合理么？有没有想过 SQL 优化跟表设计的关系？

地基都没打好，在上面的盖的房子能好到哪里去。

SQL优化是瓶颈的，其中一个瓶颈就来自于地基没打好，系统都上线了， 不可能再伤筋动骨重新设计了。

什么样的设计是合理的？简单来说就是，先按范式，再违反范式。

什么情况是设计不合理的？ 例如， 如果 子查询里有 MIN ，MAX 的，有可能就是设计有问题的，只是有可能不是绝对。 这种情况一般关系不明确才加了 MIN ，MAX 的。

2. 项目组内有没有详细的SQL规范，并对此给开发人员进行过培训？

SQL规范，越详细越好。详细到大小写，对齐方式，几个空格还是用TAB，逗号是写在字段前还是字段后，还有常见影响性能的SQL例子等。

这样做的好处是：
1）所有开发人员些的SQL，像一个人写的。看着方便，提高速度。
2）从根源开始减少常见性能问题SQL的发生。

3. 有没有 SQL 审核制度？

开发人员写的 SQL 需要审核通过后才能部署到正式系统上。
检查是否满足SQL规范， 是否会有性能问题， 是否需要建立相应索引等。

stilllovekk

有的时候光从技术上去优化是不太管用的。
必须从业务上去处理。

i2235932666

kisscactus 发表于 2016-6-27 23:57
1、        你觉得开发应该深入学习数据库吗？是的话你觉得什么层次比较好，不是的话，为什么?
a.        如果需要依赖数 ...

说的好，支持

i2235932666

peter1166 发表于 2016-6-29 17:34
我也来吐槽一下，只吐槽一个吧。 只是个人观点。

跟开发急眼... ...

说的好，写好SQL，不仅仅是开发这么简单

dqy-dqy

1、你觉得开发应该深入学习数据库吗？是的话你觉得什么层次比较好，不是的话，为什么?
基于数据库应用开发的程序员，深入学习数据库知识是有必要的，针对数据库内核运行机制原理的理解和研究，有助于程序的规划设计。

2、在你工作中遇到什么样恶心的sql，吐槽下?
程序员的怪病，都是自己写的好，看别人写的程序，大部分不顺眼；看到最多的是初级程序员，写的sql存储过程，犹如老太太裹脚丫，又臭又长，性能还低。

3、你觉得当sql 到达设么层次的时候，你需要让开发必须改sql？
实际工作中，发现sql比较差的代码，最后还是亲自动手，开发程序员也想把sql写好，但缺乏对数据库深层次的研究，很难写出了。

4、大家有没有为了sql跟开发急眼的时候，分享下。
急眼也没用，他们也想把sql写好，但是出于对数据库运行机制的了解，很难有性能高的sql。

hai503

活动最后一天了，过来看看