【大话IT】专家坐堂：SQL优化从索引设计做起！

xkf01

支持！

houbao408

支持  

niezhisheng

这本书写得很好，英文版的我看过几遍了

fatelyliang

看试读前跃跃欲试觉得问题很简单，看完试读觉得自己太肤浅想回炉重造一下了，努力回复争取拿下书本啊~！
1. 索引个数对于SQL解析性能的影响
索引数量不是对SQL性能影响的关键原因，任何一个表、索引的设计和实现，必须要有其应对的业务和应用场景。直接的说，每个表在出现的时候，必须要考虑它的核心作用是什么：做相对静态的数据记录查询，如产品列表和参数？作为频繁的插入、删除和更新，如交易订单?
针对这个表所承载的不同内容，所执行的核心操作，来设定它所应该具备的索引，是聚合的？离散的？还是序列的？同时分析它可能的环境情况匹配相应的基础架构条件，如SSD？SAN？或者是分布式环境？以及在系统的应用层面采用针对性的实现，如缓存？队列？等等。
如果一个表存在大量的索引，而且是不同类型的索引，说明这个表已经负担了大量不同种类的业务操作，要把这些操作都糅合一起必然就会有影响！对于数据库管理系统来说，它当次运行所选取的索引和内容结果的组织方式并不一定是最适合应用的要求，如我查订单，DB按照性别的索引获取……当然这受很多条件影响，但一个结构需要承担多种不同任务的时候，它本身要实现的平衡就很困难，这个困难也是在多层面影响的。
所以如果一个表有多个索引，除了可能会导致SQL解析性能的下降，更关键会导致对表的核心业务运作方式的混乱。当然，也可能是业务对于这个数据的用途在不断发生变化。

2. 如何有效使用索引和表结构来处理SQL语句
索引必须要和表结构、数据内容类型和表最常用的查询语句结合起来！个人水平所限没能力说明，业界关于sql技巧的书倒非常多，不敢班门弄斧。大概理解是SQL语句尽可能使用到索引，不允许在索引列做计算；表结构和数据类型必须与索引种类相匹配，别在性别列用聚集索引……

3. 前瞻性索引设计的核心思想是什么
核心思想应该是在表设计、索引设计和实现的时候，对这些数据可能会有怎么样的业务、使用场景包括数据格式等进行预测和分析。技术必须为业务服务才能体现价值，要成为业务的推进器必须要尽可能符合业务的发展要求。
前瞻性的设计需要预测这一笔业务数据内容和格式会怎么样变化、数据量上如何增长、使用的核心方式会有什么改变（读变写？）

4. 说说您读完试读样章后的启发
        必须拿下这本书，然后回炉重造，：）

niezhisheng

1. 索引个数对于SQL解析性能的影响
索引个数多主要降低了插入的性能，由于能够快速定位数据，大多数时候对删除、修改数据提升了性能。合适的索引，个数再多，都肯定可以提升查询性能。
一张表的索引个数可以比普通人以为的多，具体多少索引个数，需要根据实际情况分析。如果是日志表，可能一个索引都多；如果一张表经常需要多角度查询，7、8个索引也未必多。
2. 如何有效使用索引和表结构来处理SQL语句
   根据sql语句的频繁、重要度来建索引，sql语句用得频繁、重要的建索引——根据sql过滤条件，和返回字段建索引使用的字段，过滤性强的字段在索引中排前。
3. 前瞻性索引设计的核心思想是什么
   前瞻性设计就是在项目上线前，综合、权衡sql应用的使用情况，合理的合并和建立索引，让最少的索引，获得最大的性能提升。
   例如a SQL过滤用了类型字段、身份证，b sql过滤用了身份证，c sql过滤用了国家字段，但国家、类型字段过滤性低，建一个身份证字段索引就可。   

4. 说说您读完试读样章后的启发
    这本书很早就读过了，就说说这本书给我的启发：
    这本书深入的讲解了索引的原理，市面上讲索引讲得如此深入的，精确到用伪代码描述索引执行时间的，仅此一本。
    受这本书讲的索引原理影响，我在工作中用索引用得很灵活，有的日志表，我取消掉索引，满足需求；有的地方，已经有7个索引，开发人员不敢再加索引，我做测试后，发现
    提升了性能，照加不误。

lfree

好像这本是讲索引原理的书,我记得英文版我看了开头,后面没看.

我讲讲我自己遇到的例子:

第1个项目实际上是一个小系统,30多张表,总共才6个索引.我晕啊.好在系统不大,我帮他们建立索引.

第2个项目1000多张表,实际使用400多张表,竟然1半的表没有主键索引,痛苦啊,我优化的项目不是做如何优化,而是从表执行的sql语句中猜测建立主键索引.
后来我才了解到实施人员在导入数据时存在冲突,删除了许多主键.

第3个项目走向另外一个极端,我记得其中一张表竟然有17个索引,开发几乎想把每一个字段都建立了索引,我很清楚记得那一天我所做的动作就是删除删除....
删除将近100多个索引.

第4个项目除了主键以外几乎没有其它索引.又是一个痛苦的优化过程.

我想提的是几个问题:
1.索引谁来建立,开发吗?还是dba,国内许多项目在前期根本没有dba的介入.许多项目一出来就是垃圾.豆腐渣工程.
2.索引优化几乎是立杆见影的事情.就是<品悟性能>的作者说的那样,我仅仅会建索引.
3.国内的开发团队存在许多问题,我问过许多开发,基本上从来没人看过执行计划.
4.我曾经给他们讲课,当你们写出一条sql语句的时候,脑子里想一想oracle会如何执行.即使事前不想,事后也该想想吧.
5.我对国内的开发实在太失望....

alibull

第3个项目走向另外一个极端,我记得其中一张表竟然有17个索引,开发几乎想把每一个字段都建立了索引,我很清楚记得那一天我所做的动作就是删除删除....
删除将近100多个索引.

我们系统中有2张大表也是热表没有17个索引，也有15个吧。那么多索引，先看着就不舒服。

alibull

在删索引前，我会综合以下2条
1.按索引的使用次数。使用次数越小甚至为0，可以删。
2.按照user_indexes的DISTINCT_KEYS（越小越该删），AVG_LEAF_BLOCKS_PER_KEY（越大越该删），AVG_DATA_BLOCKS_PER_KEY（越大越该删）。

有时候很纠结，满足第二条的索引（键值重复高），但是不满足第一条（使用还很频繁），这样的索引，就不敢动手了。。。

〇〇

文库访问有问题，能否把附件贴在这里

lfree

删除索引最复杂,实际上有1些选择率低的很容易确定,但是其它实在不好确定.
表越大,删除索引一定要小心.