讨论送书：收获，不止SQL优化——抓住SQL的本质

bell6248

是好书， 推荐大家阅读购买

fatelyliang

能不能撞大运来一本呢？

1． SQL优化可以用到那些性能工具
     没怎么用工具，MS SQL主要都是monitor来确认性能的语句，通过执行计划来分析的，基本上依靠的还是数据库产品自身的工具，找到性能点都是靠遍历、经验和运气
     除了数据库工具本身，涉及到操作系统的监控、甚至硬件设备如存储的IO监控在一些情况下也是要注意的。windows的资源管理器非常好用。
2． 如何缩短SQL调优时间
     所短SQL调优时间，和实现调优时间这可是两个问题。
     所短调优工作本身的时间，关键在于有效定位性能问题发生的关键点，并根据项目和事项的情况，制定治标或治本的方案。这方面来看的话，经验和经历很重要，但也并非无迹可寻，利用监控迅速定位功能点、sql语句，检查数据量、索引和执行计划，就可以快速明确原因是数据量过大？还是索引无法有效利用？抑或SQL语句本身编写的问题。
     而要实现调优，把语句写的更好、更符合业务逻辑，或是改动数据库结构将活跃数据和静态无效数据分离等等都是最常见的方法，需要项目根据实际情况来选择。
3． 影响性能的常见因素
     1）语句编写不合理，大部分情况下把查询条件修改一下顺序，先执行过滤大部分无效数据的语句，就会有很明显的性能提升（曾有速度提高10倍的案例）
     2）未有效使用到索引、未创建索引、大量数据处理导致索引失效而未及时重建、无效数据量过大未分离而影响活跃数据的处理。过度零散的更新、锁定导致数据库锁和排队等。
     3）业务逻辑不合理算不算？
4． 学习索引的重要性
     头号，必须，极度重要，至少要知道一些基础的知识
5． SQL优化的误区
     1）性能优化不仅仅是一个技术问题，大部分情况下和业务内容、业务数据的发展和变化有关，需要深入分析问题

迷倪小魏

好书，买来好好学习

renfengjun

对于一个运维DBA来说，这些问题着实有些困难。不过常年隐身混迹于Oracle开发板块，结合从前的开发经验，稍微说一下。
1． SQL优化可以用到那些性能工具
AWR：看报告中top
sql，然后对相应的sql语句在特定时间段内执行的报告。里面包含了每一个不同执行计划在时间段里面的执行次数、执行等待、执行计划等。
基本上上面的已经可以找出问题sql了。下面就是调整时间。
2． 如何缩短SQL调优时间
个人感觉最重要的还是根据业务场景，改写SQL语句。其他可以考虑的，分区、SQL改写、稳定执行计划（一般不做）等，毕竟这是一个平衡的游戏，cpu 内存 IO，偏重哪个你说的算。
3． 影响性能的常见因素
这个就很多了，过旧的硬件资源、防火墙、连接池、糟糕的开发逻辑（不断的打开新session并且不释放）、糟糕的sql写法（这个很常见）、没有及时收集统计信息、乱加索引，总有人会认为自己是比别人聪明的（比如我做开发的时候），稍微抖一下小机灵，都很有可能引起性能问题。
4． 学习索引的重要性
任何计算机技能，最重要的还是基础知识。万变不离其宗，现在满大街的新功能能，新特性，要想守住本心，还是学习基础知识吧。所以像要学习Oracle像表、索引、视图等这些基本的数据库对象，都是需要了解一下的。索引很重要。就像一个目录一样，你要找一个人的档案，查下目录，去相应的架子上就可以找到了。如果没有这个目录，你得遍历一遍整个档案室。你说重要不重要。
5． SQL优化的误区
知行合一。多动手多测试，不要迷信教条，不要相信别人说的，别说的都是别人的东西，自己做过了知识才是自己的，多动手多记录。
最最最最重要的，不要迷信百度orz。

drz2030

正在转型做大数据~希望好运求中奖来一本~

铁钉

我买到的是作者两兄弟的签笔版本， 非常开心。

lanhuiboy

1． SQL优化可以用到那些性能工具
   (1) AWR报告
   (2) TOAD中的分析功能，可以针对一个SQL产生多个执行计划，并且分析每个执行计划所占用的花费。 可以提供参考
   (3) PL/SQL中 Test中的Profile功能，可以计算出一个存储过程中的多条SQL语句，所执行的时间，执行次数，占用总时长的比例，从而定位出性能瓶颈，是否是具体某一条或者几条SQL的性能问题所导致
2． 如何缩短SQL调优时间
   (1) 了解业务知识，了解表中数据的增长结构，可以快速判断出执行计划应该先走那步，再走那步可以过滤掉最多的数据，表与表之间的关联方式是怎样。
   (2) 快速定位出性能瓶颈点，是由于索引建立的不合适导致？SQL写法导致索引失效引起？执行计划跑偏导致？网络延迟导致？存储读写速率导致？还是本身的数据量过大所导致？
   (3）针对不同的瓶颈点，有针对性的提供解决方案。例如，创建合适的索引，调整SQL语句，收集统计信息，和DBA讨论，将远端服务器的数据通过数据同步的方式同步到本地等等
   (4) 多延伸了解Oracle体系结构方面的知识。特别是索引，
3． 影响性能的常见因素
   (1) 索引创建不合理
   (2) SQL语句写法
   (3) 表统计信息没有及时收集导致执行计划跑偏
   (4) 通过DBLink等方式，跨服务器查询，导致网络延迟
   (5) 系统的架构本身不合理，服务器层面没有对业务分离，读写并发等待或者热块。
   (6) 一次读写的数据量过多导致的事务问题
4． 学习索引的重要性
  基本上90%以上的问题都是各种索引问题所导致的性能问题，重要性不言而喻。开发人员如果对每一种索引的特性，适用场景都能了解透彻，基本上能解决大部分的SQL导致性能问题。因为熟悉索引的开发人员或者架构师，往往会伴随着前台页面的展现，业务对系统的操作流程的设计，表结构的设计，SQL的编写等各个阶段都会通盘考虑。而不是等出现了性能问题之后再去考虑索引创建是否合适，页面展现设计是否合理等等。
5． SQL优化的误区
  (1) SQL为什么走索引了还这么慢
  (2) SQL为什么全表扫描了，需要创建个索引
  (3) 没用使用绑定变量，容易造成性能问题(不论是OLAP或者是OLTP系统)
  (4) 过于理论化化的一些要求，例如SQL不能用in要用exists等等，不管执行计划怎样走，针对一些SQL语句盲目要求整改。

onlyword

很不错的书，一直没舍得买。好喜欢啊。。。

xuhao167

1． SQL优化可以用到那些性能工具
plsqldevloper自带f5
sqlplus 下：set autotrace traceonly； explain for sql；select * from table(dbms_xplan.display);
awr:awrrpt.sql

xuexiaogang

1． SQL优化可以用到那些性能工具
答：书中提到了一种是不同调优场景的分析，可分为单纯场景的优化和复杂场景的优化；
（这种我平时经常遇到的就算这种，最高纪录是15小时的SQL调到6秒）
而另一种是基于这些场景的工具应用，就是针对单纯场景的优化手段和复杂场景的优化手段。几个工具AWR、ASH、ADDM、AWRDD，EM，执行计划工具都用上。可能需要结合业务或者算法、乃至实现逻辑等都要慎重的考量。

2． 如何缩短SQL调优时间
答：这个有点歧义。是说如何将10S的调到1S。还是说用半个小时做到了调优，怎么能在5分钟内做到同样效果。
如果说是前者我觉得应该是，分析执行慢的原因，是嵌套问题，还是全表扫描导致，是返回行数过多，还是索引失效等各种各样的问题。找到问题选择合适的对策都应该可以解决的。
如果说是后者的话，那么就考验DBA的功底和对系统的熟悉程度。迅速定位的问题所在。这是需要一些功力的。优化的核心就是减轻IO。我记得有一句话说的是，优化就是降低单位时间内的负载。

3． 影响性能的常见因素
答：我经历最多的有以下问题：
没有索引；
有索引但是where的谓词没有用到；
索引为差异度低的列上；
没有用到先导列；
笛卡尔积；
应该关联查询，变成了嵌套查询；
数据查询集量过大；
没有绑定变量；
第一位为%通配符；
没有where条件，全表检索或者多表全表关联；
大量无意义的排序（count时，插入时）；
IO性能低；以及IO争用严重；
单次提交，没有批量提交；
大量insert update 最后delete；
建立了不合适的视图，以此为基础进行大量查询；
死锁；


4． 学习索引的重要性
答：索引不仅仅有普通的B-tree索引，还有位图索引，分区索引，反向索引，全文索引、函数索引等等。
任何一种都有其应用场景，换句话说都有自己的优势和劣势。我们要恰当使用，用它擅长的一面，而不用乱用。否则不仅无助于系统性能提高，反而让系统性能下降。学习到深入就发现，其实Oracle MySQL 还有PG等 查询优化器都是基于成本的。而这些成本就来自于统计信息。Oracle特有还有直方图的概念。只有结合这些设计索引才是好的索引。


5． SQL优化的误区
答：不能觉得比原来快了就是优化好了，而是看看是不是优化到极致了。比如原来10S，现在1S了。不一定是大功告成了，有可能还可以做到10毫秒。
不能仅仅是对SQL的优化，如果仅仅改写SQL，那么优化范围很小。如果提出表设计要改动，那么这个就是一个大的变革了。即优化不仅仅是SQL，还可能是设计。
另外还可以问问业务到底要什么，看看实现上是不是可以改进。这就是逻辑实现了。
还可以根据需求，看看有什么算法可以使用的，而不是简单粗暴的把要求的过滤条件一个个拼接在where后面。
还有一些简单的，不是每一列都来一个单独索引；
也不是强制索引就好；
更加不是一味的提升硬件加内存，加CPU。有时候不仅加了没有用而且就是投入1000倍的成本不见得有1000倍的提升。