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

stay_sun

在本次图书出版活动中，获得《Oracle编程艺术：深入理解数据库体系结构（第3版）》的网友有：
zergduan  
1983yu
maxwellxu
baijiong998
stay_sun


请以上获奖者在2016年8月11日前将姓名，公司，职务，行业，电话，邮箱，QQ，地址，所选纪念品，站内短信发送给王楠w_n以便及时给您快递奖品。

发不了站短的，请在原帖下方跟帖留言。

至于QQ现因两个编辑轮番值班登陆，可能会有遗漏的情况，有任何问题请尽量在原帖下方跟帖留言或在站务版块反馈，谢谢！

注：因特殊原因，每次活动的获奖者我都会通知各位，如果大家在截止日期之前还未联系到管理员，那么本次活动的得奖资格将被取消，所以请大家及时的与管理员取得联系，谢谢合作！






话题背景：

作为一个dba，我们负责的东西很多，但是真正做的比较多的问题其实也就name几样。
巡检是我们最多的工作，目前用监控可以减少工作量。

备份：备份规划好了基本上问题不大。
恢复：定期做检验，你要是每周恢复生产库。也是要被开的了。
优化：也就是我们今天想讨论的话题。

sql 优化是让人头疼的问题。有时候很多sql。按照不改动sql 去优化真的有瓶颈。
需要改动sql 还要开发去改。我从来认为对待计算机比对待人简单。

你想让开发改sql，  
第一他肯定是不愿意改的  其二 改的话风险确实不小  其三 工作量啊


思考如下问题：

1、你觉得开发应该深入学习数据库吗？是的话你觉得什么层次比较好，不是的话，为什么?
2、在你工作中遇到什么样恶心的sql，吐槽下?
3、你觉得当sql 到达设么层次的时候，你需要让开发必须改sql？
4、大家有没有为了sql跟开发急眼的时候，分享下。


讨论时间：2016年5月31日—6月30日


话题奖励：

活动结束后，我们将会选取5个亮点回复，送《Oracle编程艺术：深入理解数据库体系结构（第3版）》图书一本。



作者： [美] 凯特（Thomas Kyte）    库恩（Darl Kuhn）   
译者： 朱龙春 张宏伟 苗朋 陈刚
丛书名： 图灵程序设计丛书
出版社：人民邮电出版社
ISBN：9787115419576
上架时间：2016-4-7
出版日期：2016 年4月
开本：16开
页码：694
版次：3-1
所属分类：计算机 > 数据库 > Oracle

内容简介：本书是公认的Oracle数据库权威指南，凝聚了世界顶尖的Oracle专家数十年的宝贵经验和真知灼见。书中深入分析了Oracle数据库体系结构，包括文件、内存结构以及构成Oracle数据库和实例的底层进程，利用具体示例讨论了一些重要的数据库主题，同时分析了数据库中的物理结构，如表、索引和数据类型，并介绍采用哪些技术能最优地使用这些物理结构。新版在前两版的基础上，增加了针对Oracle Database 12c诸多特性的介绍。新增内容重点关注12c的云架构，以及可插拔式数据库的应用。作者通过大量示例详解每个特性的原理及应用场景。

样章试读： Oracle编程艺术：深入理解数据库体系结构（第3版）第一章：开发成功的Oracle应用.pdf (2.15 MB, 下载次数: 182)

2016-5-31 14:04 上传

点击文件名下载附件

〇〇

什么活动,只是提问?

王楠w_n

是的，是有奖讨论活动，我稍后会编辑下帖子

hbb239

王楠w_n 发表于 2016-5-31 10:00
是的，是有奖讨论活动，我稍后会编辑下帖子

就说嘛
有奖活动，才有热情。

pure_lotus

1、你觉得开发应该深入学习数据库吗？是的话你觉得什么层次比较好，不是的话，为什么?
应该，特别是有的人不懂基本的数据库性能要求，写的语句太烂，用户抱怨后还难定位问题，花钱提高硬件也不管用，最后发现是开发的问题。
2、在你工作中遇到什么样恶心的sql，吐槽下?
     就是那种定时处理报表的任务，经常长时间占用资源，想做点后台维护，只能等啊，赶紧做，否则又得等下一个维护窗口。
3、你觉得当sql 到达设么层次的时候，你需要让开发必须改sql？
     知道是SQL的时候还好办，你找开发主管，一般都会认； 关键是问题还没定位的时候，开发主管会说内部代码审核做过了，没有问题。
4、大家有没有为了sql跟开发急眼的时候，分享下。
     基本上没机会，项目开发一结束，原来开发的人都走了，后来的人不认，你急他不急，只能找老板，让老板也急。

zergduan

1、你觉得开发应该深入学习数据库吗？是的话你觉得什么层次比较好，不是的话，为什么?
当然应该学些，至少在sql的写法上要有规范，现在看到的一层层嵌套出来实现功能的SQL太多了，都是图省事儿；
当然这本来就是矛盾的，开发人员只在乎功能，并且功能实现前期数据量小，很少能体现出性能问题
出现后期性能的问题，都是项目管理者对开发人员上的仅仅从应用实现和开发速度上考核，说白了就是屁股决定脑袋，没有合作的原因~

2、在你工作中遇到什么样恶心的sql，吐槽下?
即席查询出现在oltp数据库里面，SQL一大堆左外连接星型查询，右侧的表竟然没有过滤条件，结果是一个count(*)，这些表连接是完全没有用处的~
开发说，这些SQL是自动拼接的，我们修改不了~

3、你觉得当sql 到达设么层次的时候，你需要让开发必须改sql？
底线是不能出现毫无逻辑可言的SQL，完全浪费资源，仅仅为了省时省工，完全抄写原来的应用内容，在外层嵌套条件，不评估里面的内容是否有必要~开发人员应该以简洁明了为目的，不能为了省事儿，将SQL复杂化~

4、大家有没有为了sql跟开发急眼的时候，分享下。
没有，为了工作，与同事出现个人矛盾，没有必要~
放平心态，都是来挣钱的，各有各的出发点，心平气和，做事情不是为了怄气~
公司有项目决策者，DBA和开发应该合作，而不是互相指责，问题出现有向决策者反应的途径，每个人有自己的角色，有自己的难处，两拨人私下“急眼”解决不了问题~

1983yu

1、你觉得开发应该深入学习数据库吗？是的话你觉得什么层次比较好，不是的话，为什么?
深入数据库当然好，但是我觉得大部分的开发的还是专注在代码方面比较多，人的精力毕竟有限吧。
不过我觉得起码是要掌握到sql的基本的写法，常见的低效写法还是要知道的。

2、在你工作中遇到什么样恶心的sql，吐槽下?
我讨厌写的很长很复杂的sql，还有jion来去的sql。有时候我真的想说，我也看不懂你写的啥啊。
更别说出现性能问题找我来优化了，真心是不想搞啊。

3、你觉得当sql 到达设么层次的时候，你需要让开发必须改sql？
在我看来无非就是执行次数，执行时间，资源消耗这三个方面，综合衡量下，在可能的高压情况下是否会对
系统造成影响。当然，有些时候能凑合就凑合吧。。。。

4、大家有没有为了sql跟开发急眼的时候，分享下。
急眼。。。。急眼你也没辙的，大部分遇到这种状况都是线上故障异常了，你只能催他们去改，再急也没得鸟用。
鬼知道他上个线新版本会导致什么样的鸟问题

Ryan-liumin

1983yu 发表于 2016-5-31 17:29
1、你觉得开发应该深入学习数据库吗？是的话你觉得什么层次比较好，不是的话，为什么?
深入数据库当然好， ...

甄嬛真牛B啊

sqysl

1、当然懂得越多越好，但也别苛求，如果让dba去深入研究java，.net，是不是觉得过分呢？
2、没什么恶心的，解决了就好，技术人员总是爱站在自己的角度考虑问题，还是尽量变换角度和思路。
3、除了改SQL再也没其他办法解决时，好好和研发沟通。
4、急眼只会让问题更难解决，心平气和和同事沟通比什么都强。没有哪家公司说dba有急眼的特权，dba本身也是个普通技术职位，比研发没什么特别的。
5、很多公司的后台代码有专门的数据库开发团队完成，如果这样，他们有责任做好这块。

luckyrandom

1、你觉得开发应该深入学习数据库吗？是的话你觉得什么层次比较好，不是的话，为什么?
看开发者的定位及职责、角色内容及与数据库关联的紧密程度、应用的重要性、成本控制。一个数据量少、并发少的应用，找个CODER完成任务即可，甚至不需要懂SQL，用框架完成。对数据量大、并发大的应用，框架产生的SQL会累死SVR，必须要一定的开发质量、设计质量、规划质量，就必须了解一定的SQL机制，这个时候通常会有DBA参与协同，职责分配得比较明晰了。通常来说，不熟悉SQL及其机制的开发数据处理相关应用，其质量是可忧的。

2、在你工作中遇到什么样恶心的sql，吐槽下?
框架产生的，产生的SQL抓取出来有127K，惊呆小伙伴
格式凌乱的SQL，看得头晕

3、你觉得当sql 到达设么层次的时候，你需要让开发必须改sql？
对性能有较大影响，或者存在一定逻辑BUG时，必改

4、大家有没有为了sql跟开发急眼的时候，分享下。
DBA不用跟开发急，把事实罗列出来沟通清楚，及提供建议（有些场景可能是强制），开发与有团队、组织，总会有人能理解，能达成共识，解决问题