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

lorikyo

1、你觉得开发应该深入学习数据库吗？是的话你觉得什么层次比较好，不是的话，为什么?
看深入到什么程度吧，起码一些建表的原则 ，SQL写法的常见错误 要避免！
在我工作的环境 起码 绝大多数开发是需要进一步提高自己写SQL的水平 和深入了解一些数据库方面的知识的。

2、你工作中遇到什么样恶心的sql，吐槽下?
工具生产的最恶心，抓出来的SQL 光代码就有十多页 或者几十页，人工看到都蒙了。完全不知道从何下手。
改写就不说了 看都看不懂，只能看执行计划从局部成本高的地方下手。

3、你觉得当sql 到达设么层次的时候，你需要让开发必须改sql？
对性能影响大的 ，而且从DBA层面无法优化 ，比如 加索引 分区。然后写的烂的各种笛卡尔积，各种没有必要的外连接，各种关联无关的表
各种写法上 很基础常见的错误等等。
4、大家有没有为了sql跟开发急眼的时候，分享下。
一般还有 有问题 提出问题解决问题，大家都是为了工作吗。
还有就是有些系统开发都换了几茬了，你想急也找不到人急啊  哈哈！

初识orcl

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

甄嬛真牛B啊

kavin7777

1、你觉得开发应该深入学习数据库吗？是的话你觉得什么层次比较好，不是的话，为什么?
不用太深入，不过基本的一些错误要避免。
2、在你工作中遇到什么样恶心的sql，吐槽下?
语句嵌套了14层，你要知道那个语句剥了好久好久
3、你觉得当sql 到达设么层次的时候，你需要让开发必须改sql？
影响业务使用，例如查询的时候等的让客户受不了，晚上跑的存储过程能给你跑过周期。
4、大家有没有为了sql跟开发急眼的时候，分享下。
那个时候出差，60块的电话费直接一天打爆，那些年打接电话都是0.39元。

IT16880

什么活动

sap狐狸

1、你觉得开发应该深入学习数据库吗？是的话你觉得什么层次比较好，不是的话，为什么?
个人觉得至少后端开发是必须的。开发人员能尽可能保证SQL语句的查询质量会比较好。

2、在你工作中遇到什么样恶心的sql，吐槽下?
多重循环查询，两层已经反感了，还碰上四层循环的，数据读取慢成蜗牛。

3、你觉得当sql 到达设么层次的时候，你需要让开发必须改sql？
觉得业务逻辑变复杂，涉及多重循环，严重拖累数据库查询速度的时候

4、大家有没有为了sql跟开发急眼的时候，分享下。
没有，有问题拿出来大家沟通清楚，一起解决，毕竟人无完人。

fly518

1、你觉得开发应该深入学习数据库吗？是的话你觉得什么层次比较好，不是的话，为什么?
   不是应该，而是必须，每次新上线一个功能，第二个就要看着系统，担心有慢查，系统越来越多，人越来越累。至少需要能优化简单的sql，能知道添加索引可以解决sql慢的问题。

2、在你工作中遇到什么样恶心的sql，吐槽下?
    什么样的sql都有，开发普遍的sql水平比较低，尤其是那些个跑了成千上万秒的

3、你觉得当sql 到达设么层次的时候，你需要让开发必须改sql？
     sql不要写的太复杂，3个表以内的关联，运行时间不能超过5s

4、大家有没有为了sql跟开发急眼的时候，分享下。
    太多了，我现在准备写个自动kill慢查的工具，然后倒逼开发去优化sql，不优化，你的功能就没法用，就等着被投诉吧，哈哈

匆匆的烟斗

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

合起来谈谈，我们这开发主攻开发（功能实现），DBA主攻DB搭建、维护，系统的 performance 由一个跨功能的部门负责，恰巧我在这个跨功能的部门。我觉得DB学习到逻辑不出错，再学习一些限制。关于performance，这个有点高深。我遇到比较恶心的SQL么，呃，不好形容。但是大表见过，GLPCA， 那表120G，7个Index大的20G,小的5G, 脑补一下，你就够了。 我们提升performance通常会有一个分析，定位消耗时间的点，然后针对性处理。是GUI time, cpu time, db response time, network time？ SQL只是db response time这一小节上的一个点。 只是提升SQL，个人经验效果一般，属于事倍功半。

yehuafeilang

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

现在我们开发的软件大多是应用软件，应用软件是肯定要用到数据的，数据的保存就需要数据库了，所以学习数据库当然是至关重要的了，当然了，如果能做到非常深入那是非常好的，可是往往开发人员是没有那么多精力去非常深入的学习数据库的，我想的话，能够达到OCA的标准就够用了，再深入点也可达到OCP的标准，大师级的暂时可以不用想了。

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

   大家知道，Oracle的SQL语句是从下到上处理Where子句中的多个查询条件，所以表连接语句应写在其他WHERE条件前，可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾。结果某人习惯性把这种条件放到前面去。。。。结果可想而知。

3、你觉得当sql 到达设么层次的时候，你需要让开发必须改sql？
举几个例子吧：
一是复杂操作，比如说UPDATE、SELECT 语句 写得很复杂（经常嵌套多级子查询），这个时候就可以考虑适当拆成几步，先生成一些临时数据表，再进行关联操作。还有就是尽量避免在一个复杂查询里面使用 LIKE '%parm1%'， 百分号会导致相关列的索引无法使用，最好不要用。
二是在可以使用UNION ALL的语句里，使用了UNION，UNION 因为会将各查询子集的记录做比较，故比起UNION ALL ，通常速度都会慢上许多。一般来说，如果使用UNION ALL能满足要求的话，务必使用UNION ALL。还有一种情况大家可能会忽略掉，就是虽然要求几个子集的并集需要过滤掉重复记录，但由于脚本的特殊性，不可能存在重复记录，这时便应该使用UNION ALL，如xx模块的某个查询程序就曾经存在这种情况，见，由于语句的特殊性，在这个脚本中几个子集的记录绝对不可能重复，故可以改用UNION ALL
三是在WHERE 语句中，尽量避免对索引字段进行计算操作，这个常识相信绝大部分开发人员都应该知道，但仍有不少人这么使用，我想其中一个最主要的原因可能是为了编写写简单而损害了性能，那就不可取了。
四是排序的时候避免使用耗费资源的操作，带有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL语句会启动SQL引擎 执行，耗费资源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要执行两次排序。
等等。。。

4、大家有没有为了sql跟开发急眼的时候，分享下。

当然是有的，在应用系统开发初期，由于开发数据库数据比较少，对于查询SQL语句，复杂视图的的编写等体会不出SQL语句各种写法的性能优劣，但是如果将应用系统提交实际应用后，随着数据库中数据的增加，系统的响应速度就成为目前系统需要解决的最主要的问题之一。系统优化中一个很重要的方面就是SQL语句的优化。对于数据量大的情况，劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍，所以为了sql跟开发急眼很正常。

山不高有仙名

围观一下，本身不是DBA，不过对Oracle数据库确实情有独钟，非常喜欢，有机会再改行。

lucas_dingzf

1、你觉得开发应该深入学习数据库吗？是的话你觉得什么层次比较好，不是的话，为什么?        我觉得这是一个各种行业都会探讨的问题，就是相关工作分工，是否需要互相学习。我个人觉得，当然要。但是这不是必须，而是一个技术人员的自我修养和自我需求。夸边界学习的效果是显而易见的，懂得一些数据库工作原理，甚至懂一些sql语句效率的开发人员，会更容易写出一些执行效率高的sql，至少是有意识的向着这方面努力。
        但是学习是有成本的。对于企业而言，我觉得可以定期或不定期的请资深DBA办一些讲座，或者交流活动。既可以普及一些必要的知识，也可以增进各部门间的交流。另外，对于一些关键的开发项目，开发人员的SQL语句，应该要通过DBA的效率审查。我觉得这是可以写进开发流程中的。
2、在你工作中遇到什么样恶心的sql，吐槽下?
      恶心的sql就不多说了，很多是什么图省事儿的全字段读取，或者画蛇添足的hint或者“好心办坏事儿”，DBA都有体会。
      当然，还要警惕一些已经过期没用，但是还是在占用资源的scheduled sql。
3、你觉得当sql 到达设么层次的时候，你需要让开发必须改sql？
      有需求，才有优化。不影响工作生产，就没有优化的必要。多思考，少做事，也是我认为dba的工作灵魂之一。