(11)好心办坏事的SQL优化

标签： sql 优化 | 发表时间：2013-12-07 09:02 | 作者：xcltapestry
出处：http://blog.csdn.net
    前面已经说过 在表上乱加不合理索引的问题， 位图索引的问题等，但索引引起的问题实在太多了。我在这在说说另一种
关于索引的好心办坏事的SQL优化情形。
    话说某开发人员对索引非常重视，对索引花了很多时间研究，并在开发测试阶段为了让系统达到最好的效果，在SQL语句
中做了很多工作。其中之一，将认为最有效的索引固定在SQL语句中。所以在他写得代码中 有大量的/*+ */ 存在。他希望一
劳永逸地解决性能问题。
      但应用上线后，实际效果并不全如人意。其中更有些SQL运行表现与测试中相差甚远。原来他没有考虑到实际应用中，
有些表实际增长及变更情况远在预料之外。增长非常快，且有些更新也很频繁。虽然之前测试时有做应用模拟。但又有几
个项目能说模拟得和真实环境差不多的？ 所以之前表现良好的SQL，在新形势下有些执行计划已不太适应新情况了。
    这是典型的过早优化造成的后果。因为数据库的数据是在变化中的，所以最合理的执行计划也是跟着变化的。这也是Oracle
推出自动化分析采集工具的原因之一。 随着数据量的更新，数据库统计信息的完善配合数据库越来越智能的CBO.数据库完全
能够在大多数情况下与时俱进地找到合适的执行计划，而这个执行计划不一定是你所指的那个索引。
    个人认为过早的固定索引，相当于过早的捆住自已的手脚。 在开发阶段，可以依自己的分析建立相关的索引，但基本上无
须强制使用某个索引。如果一定要强制使用，可以在应用上线一段时间后，再加上也不迟。

     除了这个外，还一个 索引重建的问题也很可怕。有人查到说，表在运行一段时间有过大量的增，删改之后，
导致索引中叶子行被删除，造成索引产生碎片。索引碎片越多，索引的I/O成本就越高，为了让索引有最好的性能。
他们很勤奋地给索引重建，以达到最佳速度。 问题是太容易出问题了。由于在生产库上索引重建，搞死一个库，
或者一个大表索引重建花了几个小时甚至几天的等帖子 ITPUB上很多。 
  重建是要很小心的，不过有好消息是，11g 又增强了在线索引重建的特性,可以减少重建过程中对DML操作的阻塞。 
   例子: ALTER INDEX IDX_XCL REBUILD ONLINE; 

     SQL调优的水太深了，调优的书市面上出了一本又一本，我就不多说了，在这就先举这两个例子。
好像没有写证明的实例在上面，原因是我一下也想不到合适的，喷点口水就算了先。



作者：xcltapestry 发表于2013-12-7 1:02:31 原文链接
阅读：218 评论：0 查看评论

相关 [sql 优化] 推荐：

sql优化

- - 数据库 - ITeye博客
是对数据库(数据)进行操作的惟一途径；. 消耗了70%~90%的数据库资源；独立于程序设计逻辑，相对于对程序源代码的优化，对SQL语句的优化在时间成本和风险上的代价都很低；. 可以有不同的写法；易学，难精通. 固定的SQL书写习惯，相同的查询尽量保持相同，存储过程的效率较高. 应该编写与其格式一致的语句，包括字母的大小写、标点符号、换行的位置等都要一致.

sql 优化

- - SQL - 编程语言 - ITeye博客
转：数据库SQL优化大总结之 百万级数据库优化方案. 2014-07-18 09:33 雲霏霏 雲霏霏的博客 字号：. 网上关于SQL优化的教程很多，但是比较杂乱. 近日有空整理了一下，写出来跟大家分享一下，其中有错误和不足的地方，还请大家纠正补充. 网上关于SQL优化的教程很多，但是比较杂乱. 近日有空整理了一下，写出来跟大家分享一下，其中有错误和不足的地方，还请大家纠正补充.

索引SQL优化

- - SQL - 编程语言 - ITeye博客
（一）深入浅出理解索引SQL优化 (转).         实际上，您可以把索引理解为一种特殊的目录. 微软的SQL SERVER提供了两种索引：聚集索引（clustered index，也称聚类索引、簇集索引）和非聚集索引（nonclustered index，也称非聚类索引、非簇集索引）. 下面，我们举例来说明一下聚集索引和非聚集索引的区别：  .

优化sql查询

- - 数据库 - ITeye博客
1、 首先要搞明白什么叫执行计划. 执行计划是数据库根据SQL语句和相关表的统计信息作出的一个查询方案，这个方案是由查询优化器自动分析产生的，比如一条SQL语句如果用来从一个 10万条记录的表中查1条记录，那查询优化器会选择“索引查找”方式，如果该表进行了归档，当前只剩下5000条记录了，那查询优化器就会改变方案，采用 “全表扫描”方式.

sql语句优化

- - 数据库 - ITeye博客
性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能，SQL语句越简单越好. 对复杂的SQL语句，要设法对之进行简化. 1）不要有超过5个以上的表连接（JOIN）. 2）考虑使用临时表或表变量存放中间结果.

SQL Server优化50法

- - CSDN博客推荐文章
虽然查询速度慢的原因很多，但是如果通过一定的优化，也可以使查询问题得到一定程度的解决. 　　查询速度慢的原因很多，常见如下几种：没有索引或者没有用到索引（这是查询慢最常见的问题，是程序设计的缺陷）. 　　I/O吞吐量小，形成了瓶颈效应. 　　没有创建计算列导致查询不优化. 　　内存不足网络速度慢查询出的数据量过大（可以采用多次查询，其他的方法降低数据量）.

oracle sql 优化大全

- - Oracle - 数据库 - ITeye博客
最近遇到了oracle sql优化的问题，找了一下，发现这文章实在不错，跟大家分享一下，如果以后有什么新的改进也会继续补充的. 1     前言… 2 . 2     总纲… 2 . 3     降龙十八掌… 3 . 第一掌 避免对列的操作… 3 . 第二掌 避免不必要的类型转换… 4 . 第三掌 增加查询的范围限制… 4 .

Oracle SQL性能优化

- - 数据库 - ITeye博客
（1）      选择最有效率的表名顺序(只在基于规则的优化器中有效)：. ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子句中写在最后的表(基础表 driving table)将被最先处理，在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表. 如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表.

SQL Server优化50法

- - CSDN博客数据库推荐文章
　　虽然查询速度慢的原因很多，但是如果通过一定的优化，也可以使查询问题得到一定程度的解决. 　　查询速度慢的原因很多，常见如下几种：. 没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷). I/O吞吐量小，形成了瓶颈效应. 查询出的数据量过大(可以采用多次查询，其他的方法降低数据量).

Oracle SQL性能优化

- - 数据库 - ITeye博客
（1）      选择最有效率的表名顺序(只在基于规则的优化器中有效)：. ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子句中写在最后的表(基础表 driving table)将被最先处理，在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表. 如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表.