(08)DBA写给开发的索引经验

标签： dba 开发 索引 | 发表时间：2013-12-05 07:27 | 作者：xcltapestry
出处：http://blog.csdn.net
      索引可是个大事情，翻开任意一本数据库调优的书，索引都会占到比较大的篇幅。这是个人人都很重视的问题，可往往起始阶段还好，但数据库到最后常常还是会陷入由索引起的性能怪圈中。特别是在上线运行过一段时间的系统上表现特别明显. 人们为了提高查询速度，或者说自认为可以提高速度。所以不停的向上面加索引，改索引，加索引。极端的甚至每个字段都建或者是一个有什么查询就建个索引先，种种乱象大把。由此产生太多的无效索引,占用大量系统空间,拖慢相关表的写入性能,增加系统的waits.由此引发一堆的问题 。
      造成这些 往往是开发不会正确的建索引。其实有DBA参与的项目有时也会出现由索引引起的问题，更别说很多项目是没有DBA参与或后期没有DBA了，直到数据库出现严重问题. 
       索引这东西太值得深入研究了，网上有很多很多DBA对它们做各类测试和研究。数据库每次发新版本，也会对这个特性更新点新东西。不过那都离开发稍有点远。 我在这只想介绍一些有用的方法给开发，让他们可以放心的在项目享受索引的魔力，而不用太担心被它所伤。
     先声明一点，调优没那么简单，水深得很。我在这只说些通常情况下我认为大致可行的办法，并不适合所有情况。

    就索引而言，先要明白几个概念：
          索引不是一定能提高性能的。        
          索引也不是越多越好。
          索引本身也是占用空间，牺牲表的写入性能。 
    具体为什么我就不在这占地方写了，大把的文章说这些。 

你加索引时只要知道这几点:
  1.找到说服自己的理由
    在确定要加索引时,首先要搞明白是确实碰到性能问题了,查询要花很多时间?
    还是因为很多SQL的WHERE条或关联需用到这个?
     如果不是这两种情况，那就要再思考一下了。
  2. 多尝试，找出最合适的索引组合。
    你确定要加索引了。现在有几个问题，
      a. WHERE 条件用到表的两个字段，那到底是分别建两个单键索引还是合在一起建一个复合索引? 
      b.或者说，其中一个列已有建一个索引，那我还需要建个复合索引吗？  
      下决定前，你要清楚它们各自的优势在哪。
           查询特定的列的记录，单索引肯定比复合索引快，至于快多少，那很难有个定量的。要靠实际环境的测试。
         复合索引组合对这个同时使用了两个字段的情况肯定提速要明显，而且原来使用了单索引的其它SQL,照样能
         享受到索引的福利。不过复合索引字段多，占的空间相对要大，查询时访问的数据块也要多，消耗的资源也大。
         总之两者各有千秋。 
        你要评估下哪种WHERE条件和连接条件用得比较多，哪些SQL的优先级比较高，有条件最好再实际测试一下速度。
   3. 具体选择什么类型的索引？
 数据库的索引种类非常之多，不要一知半解去玩，很多就玩出问题了，我后面会具体另外花时间写写这个。我在这
只建议就用默认建立的那种索引好了， 其它索引你要确定搞清楚了再用。
    4. 索引增加或重建操作要小心。
          别想当然的去直接操作，其实可不简单有注意事项的。
        a. 操作前要做好检查。
            做过Oracle表设计的都知道一个潜规则，通常会把数据表空间和索引表空间分开，以减少磁盘I/O竞争和便于管理。
            但这说明了一个问题，索引确确实实是占空间的，那你建索引前尤其是大表， 最好评估下索引表空间是否够。
        b. 操作要看时机。
            对于已上线的系统，不到万不得已，尽量尽量不要在业务高峰期操作，尤其是对大表。会消耗掉大量的系统资源。
        并引发不可料的问题。 实际上好多库出问题就出在这种操作上，听我一句劝，不要自己给自己找麻烦。
        
 上面说的是加索引的情况，如果你现在的数据库已经是一团乱麻了，你也分不清这些个索引到底有用没。
     可以看看我下面的方法。
           
     1. 有事没事从em或数据库视图中找出消耗性能最多的SQL，
         找出来，把表关系，表相关的索引拿出来细细分析，确定其合理性。
     2. 从视图中查出索引最多的相关表，看看相关的SQL,是否真需要那么多索引。
     3. 通过索引监控,找出无用的索引.将其去掉.
       对索引做监控时,监控的周期要注意. 有些索引如仓库盘点表上的索引.
       被调用的时隔很长,如刚好不在你的监控周期以内. 你轻易删除了,到用就要
   手忙脚乱地面对由此引起的性能问题. 所以删除时一定要对业务有了解.确认过后再处理.

   对于 如何确定一个索引，到底有用还是没用，可以采用下面的小技巧.
    （再强调下，具体操作命令别在业务高峰期玩）
            11g前，
      先将索引更改为 unusable状态,让删除不需要与表数据同步更新.
      如过了比较长的周期,确认这个是没用的,再将其删除就很保险了.
      万一要重新使用时,只需要用rebuild重建,并更新一下统计信息即可.
      不过,如果索引刚好在一张大表上.这个动作要花的时间可能就会很长.
            11g及以后
             可用 索引不可见.(Index Invisible)这个新特性。让数据库的优化器彻底无视这个索引。
        而这个索引并没有被删除，也同样会与表做同步更新。这意味着，你确定还需要这索引时，
        只要用命令重新让它们可见就好了。无需再去做索引的重建动作了。

     通过上面的这些操作，坚持下去，细水长流，数据库的性能自然会上去。由索引引起的问题也会少很多的。
    
     上面纯是口水文，说到具体的相关技术点可以自己去查，我以后有时间也会再做补充说明。
 总之希望各自的项目都顺顺利利，稳稳当当，天下大同，世界和平。


作者：xcltapestry 发表于2013-12-4 23:27:23 原文链接
阅读：89 评论：0 查看评论

相关 [dba 开发 索引] 推荐：

(08)DBA写给开发的索引经验

- - CSDN博客研发管理推荐文章
      索引可是个大事情，翻开任意一本数据库调优的书，索引都会占到比较大的篇幅. 这是个人人都很重视的问题，可往往起始阶段还好，但数据库到最后常常还是会陷入由索引起的性能怪圈中. 特别是在上线运行过一段时间的系统上表现特别明显. 人们为了提高查询速度，或者说自认为可以提高速度. 所以不停的向上面加索引，改索引，加索引.

DBA工作总结

- - CSDN博客数据库推荐文章
一年以来，本人尊敬领导团结同事、服从安排 遵守纪律，坚持努力学习专业知识，兢兢业业克己奉公努力工作. 总结过去，在知识结构上，能够完成了EBS-DBA的各项工作；在日常工作XX，能够完成EBS-DBA的各项工作任务，适应了DBA工作岗位要求的职责，掌握了EBS-DBA要求的多项技术. 我一年以来的主要工作从以下几个方面说起主要包括日常维护、补丁更新，安装规划，文档整理，最后给出下一步规划.

DBA团队的使命

- 2sin18 - Alibaba DBA Team
DBA团队的使命：提供高可用、高性能、可扩展的数据存储服务. 高可用：可用性是运维的根本，我们不管做什么事情，都要把可用性放在第一位. 高性能：对性能的关注是我们一直坚持、做的最好的一面，仍需要继续做到极致. 可扩展：也就是最适合的，易部署，可线形透明伸缩. 数据存储：不只是关注某个数据库本身，是基于对各种最先进的数据存储技术的精深理解，提供最专业的服务.

DBA Notes 也有 iPhone App 了 ?

- Epile - DBA notes
刚才在我的 Google+ 上发布了一条半开玩笑的信息：DBA Notes 也有 iPhone App 了. 其实没那么神奇，借助于这款 iOS App : Bloapp .. 安装完这个 App 之后，到其网站上"创建"你的 App，其实主要是一些视觉风格的定义，用它扫描生成的这个 QR Code :.

一个DBA眼中的HBase

- - IT技术博客大学习
标签：   HBase.     Hadoop，HBase，NO-SQL是当今业界比较火的一些名词. 满互联网都是对它的他们的赞许，其实光芒的背后还有部分缺点. 本文只是我vogts的一些观点和想法.     HBase的优点：.     分布式，易扩展，高性价比，运维成本低都是它的优点. HBase可以支持海量数据，单张表的数据量不上T，都不好意思出来打招呼.

常用Oracle DBA 查询

- - CSDN博客推荐文章
-- Part1 Oracle常用查询. and t.table_name = 要查询的表 . and au.constraint_type = 'P' and au.table_name = 要查询的表. and au.table_name = 要查询的表 . select * from user_constraints c where c.constraint_type = 'R' and c.table_name = 要查询的表.

MySQL DBA修炼秘籍

- - OurMySQL
本文主要写给那些立志成为MySQL DBA，以及正在学习MySQL的同行们，结合个人及业内其他同行的职业发展经历给大家一些参考，如何成为合格的MySQL DBA. 1、什么是MySQL DBA. 首先，DBA是database administrator(数据库管理员)的简称，在一些招聘网站上，也可能会把职位写成数据库[管理]工程师，MySQL DBA是目前互联网企业中最为炙手可热的岗位需求之一，前(钱)景大好，快到碗里来吧.

如何成为MySQL DBA

- - OurMySQL
       互联网高速发展的成功，得益于MySQL数据库的给力支持. MySQL本身发展的速度较快，性能方面提升显著，让传统企业也有想法使用MySQL提供服务. 目前看来MySQL DBA的缺口非常大. 所以欢迎加入到MySQL DBA的团队中来.       有同学一提到MySQL DBA或是DBA都把高难度入门联系到一块.

MySQL DBA面试全揭秘

- - OurMySQL
本文起源于有同学留言回复说想了解下MySQL DBA面试时可能涉及到的知识要点，那我们今天就来大概谈谈吧. MySQL DBA职位最近几年特别热门，不少朋友让我帮忙推荐什么的，也有很多公司找不到合适的DBA. 原因很简单，优秀的人才要么被大公司圈起来了，要么被创业公司高薪挖走，如果你既不是大公司，又不能出得起高价钱的土豪公司，想要找到优秀人才的几率堪比买彩票中奖的概率，哈哈.

互联网 DBA 需要做那些事

- - CSDN博客数据库推荐文章
很早前就想写篇文章介绍一下互联网DBA需要干的一些事情，但苦于没有时间，忙于平台建设，最近，各个模块都初具规模，故有时间静下心来，介绍一下. 众所周知，互联网DBA与传统行业DBA有很大的不同，那就是管理的机器多，新技术更新快，面对的开发多、网络环境复杂、要求7*24待机；这样就 导致互联网DBA的工作在传统DBA工作之上，增加了更多的复杂性，我们必须考虑如何大批量部署，如何集中化监控、如何解决单点故障而保障7*24，而为 了做到这些，不是靠堆人力，我们必须有一个完整的平台作为支撑，那么数据库平台到底要建成什么样子呢.