MySQL高级知识-查询与索引优化分析

edrs8863 8年前
   <p>性能下降SQL慢、执行时间长、等待时间长</p>    <ul>     <li>查询语句写的烂</li>     <li>索引失效      <ul>       <li>单值索引</li>       <li>复合索引</li>      </ul> </li>     <li>关联查询太多join(设计缺陷或不得已的需求,除非你能干的过你的产品经理)</li>     <li>服务器调优及各个参数设置(缓冲、线程数等)</li>    </ul>    <p>常见通用的Join查询</p>    <p>SQL执行顺序</p>    <ul>     <li><strong>手写</strong>      <ul>       <li style="text-align:center"><img src="https://simg.open-open.com/show/ba41ce5ac1c7c317b9e5f418b71a81f0.jpg"> <p>手写SQL顺序</p> </li>      </ul> </li>    </ul>    <pre>  <code class="language-sql">SELECT DISTINCT      <select_list>  FROM       <left_table> <join_type>  JOIN <right_table> ON <join_condition>  WHERE       <where_condition>  GROUP BY      <group_by_list>  HAVING      <having_condition>  ORDER BY      <order_by_condition>  LIMIT <limit_number></code></pre>    <ul>     <li><strong>机读(MySQL读取顺序)</strong>      <ul>       <li style="text-align:center"><img src="https://simg.open-open.com/show/9fd77b5955f578577aab149da06bf2b6.jpg"> <p>机读顺序</p> </li>      </ul> </li>    </ul>    <pre>  <code class="language-sql">FROM       <left_table>  ON <join_condition>  <join_type> JOIN <right_table>   WHERE       <where_condition>  GROUP BY      <group_by_list>  HAVING      <having_condition>  SELECT DISTINCT      <select_list>  ORDER BY      <order_by_condition>  LIMIT <limit_number></code></pre>    <ul>     <li>总结-SQL解析顺序      <ul>       <li style="text-align:center"><img src="https://simg.open-open.com/show/5248560beee388b3ccbe5b8c54e87e69.jpg"> <p>SQL解析</p> </li>      </ul> </li>    </ul>    <p>SQL JOINs</p>    <ul>     <li style="text-align:center"><img src="https://simg.open-open.com/show/6d2e0406e724a8f61bd25503337a521e.jpg"> <p>七种JOIN图解</p> </li>     <li>实验:</li>    </ul>    <pre>  <code class="language-sql">-- 建表和数据SQL  CREATE TABLE `tbl_dept` (   `id` INT(11) NOT NULL AUTO_INCREMENT,   `deptName` VARCHAR(30) DEFAULT NULL,   `locAdd` VARCHAR(40) DEFAULT NULL,   PRIMARY KEY (`id`)  ) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;    CREATE TABLE `tbl_emp` (   `id` INT(11) NOT NULL AUTO_INCREMENT,   `name` VARCHAR(20) DEFAULT NULL,   `deptId` INT(11) DEFAULT NULL,   PRIMARY KEY (`id`),   KEY `fk_dept_id` (`deptId`)   #CONSTRAINT `fk_dept_id` FOREIGN KEY (`deptId`) REFERENCES `tbl_dept` (`id`)  ) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;        INSERT INTO tbl_dept(deptName,locAdd) VALUES('RD',11);  INSERT INTO tbl_dept(deptName,locAdd) VALUES('HR',12);  INSERT INTO tbl_dept(deptName,locAdd) VALUES('MK',13);  INSERT INTO tbl_dept(deptName,locAdd) VALUES('MIS',14);</code></pre>    <ul>     <li>练习      <ul>       <li>1、A、B两表共有        <ul>         <li>select * from tbl_emp a inner join tbl_dept b on a.deptId = b.id;</li>        </ul> </li>       <li>2、A、B两表共有+A的独有        <ul>         <li>select * from tbl_emp a left join tbl_dept b on a.deptId = b.id</li>        </ul> </li>       <li>3、A、B两表共有+B的独有        <ul>         <li>select * from tbl_emp a right join tbl_dept b on a.deptId = b.id;</li>        </ul> </li>       <li>4、A的独有        <ul>         <li>select * from tbl_emp a left join tbl_dept b on a.deptId = b.id where b.id is null;</li>        </ul> </li>       <li>5、B的独有        <ul>         <li>select * from tbl_emp a right join tbl_dept b on a.deptId = b.id where a.deptId is null;</li>        </ul> </li>       <li>6、AB全有        <ul>         <li>MySQL Full Join的实现 因为MySQL不支持FULL JOIN,下面是替代方法</li>         <li><strong>left join + union(可去除重复数据)+ right join</strong></li>         <li>实现如下面代码</li>        </ul> </li>       <li>7、A的独有 + B的独有</li>      </ul> </li>    </ul>    <pre>  <code class="language-sql">-- 6、AB全有  SELECT *  FROM tbl_emp a LEFT JOIN tbl_dept b ON a.deptId = b.id  UNION   SELECT *  FROM tbl_emp a RIGHT JOIN tbl_dept b ON a.deptId = b.id;      -- 7、A的独有 + B的独有  SELECT *  FROM tbl_emp a LEFT JOIN tbl_dept b ON a.deptId = b.id  WHERE b.id IS NULL  UNION  SELECT *  FROM tbl_emp a RIGHT JOIN tbl_dept b ON a.deptId = b.id  WHERE a.`deptId` IS NULL;</code></pre>    <p>索引简介</p>    <p>什么是索引</p>    <ul>     <li>MySQL官方对索引的定义为: <strong>索引(Index)是帮助MySQL高效获取数据的数据结构</strong> 。      <ul>       <li>可以得到索引的本质: <strong>索引是数据结构</strong> 。</li>       <li>索引的目的在于提高查询效率,可以类比字典,</li>       <li>如果要查“mysql”这个单词,我们肯定需要定位到m字母,然后从下往下找到y字母,再找到剩下的sql。</li>       <li>如果没有索引,那么你可能需要a----z,如果我想找到Java开头的单词呢?或者Oracle开头的单词呢?</li>       <li>是不是觉得如果没有索引,这个事情根本无法完成?</li>      </ul> </li>     <li><strong>你可以简单理解为“排好序的快速查找结构”</strong>      <ul>       <li>在数据之外, <strong>数据库系统还维护着满足特定查找算法的数据结构</strong> ,这些数据结构以某种方式引用(指向)数据,<br> 这样就可以在这些数据结构上实现高级查找算法。这种数据结构,就是索引。</li>       <li>下图就是一种可能的索引方式示例:        <ul>         <li> <p style="text-align:center"><img src="https://simg.open-open.com/show/381e834cd00a68dfb8a1b4a915b14589.jpg"></p> </li>        </ul> </li>       <li>为了加快Col2的查找,可以维护一个右边所示的二叉查找树,每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针,这样就可以运用二叉查找在一定的复杂度内获取到相应数据,从而快速的检索出符合条件的记录。</li>      </ul> </li>     <li>一般来说索引本身也很大,不可能全部存储在内存中,因此索引往往以索引文件的形式存储的磁盘上</li>     <li>我们平常所说的索引,如果没有特别指明,都是指B+树结构组织的索引 。其中 <p>聚集索引,次要索引,覆盖索引,</p> <p>复合索引,前缀索引,唯一索引默认都是使用B+树索引,统称索引</p> 。当然,除了B+树这种类型的索引之外,还有哈稀索引(hash index)等。</li>    </ul>    <p>索引的优势</p>    <ul>     <li>类似大学图书馆建书目索引, <strong>提高数据检索的效率</strong> ,降低数据库的IO成本</li>     <li>通过索引列对数据进行排序 <strong>,降低数据排序的成本</strong> ,降低了CPU的消耗</li>    </ul>    <p>索引的劣势</p>    <ul>     <li>实际上索引也是一张表,该表保存了主键与索引字段,并指向实体表的记录,所以索引列也是要占用空间的</li>     <li>虽然索引大大提高了查询速度,同时却会降低更新表的速度,如对表进行INSERT、UPDATE和DELETE。因为更新表时,MySQL不仅要保存数据,还要保存一下索引文件每次更新添加了索引列的字段,都会调整因为更新所带来的键值变化后的索引信息</li>     <li>索引只是提高效率的一个因素,如果你的MySQL有大数据量的表, <strong>就需要花时间研究建立最优秀的索引,或优化查询语句</strong></li>    </ul>    <p>MySQL索引分类</p>    <ul>     <li><strong>单值索引</strong>      <ul>       <li>即一个索引只包含单个列,一个表可以有多个单列索引</li>      </ul> </li>     <li><strong>唯一索引</strong>      <ul>       <li>索引列的值必须唯一,但允许有空值</li>      </ul> </li>     <li><strong>复合索引</strong>      <ul>       <li>即一个索包含多个列</li>      </ul> </li>     <li>基本语法      <ul>       <li>创建,两种方式        <ul>         <li>CREATE [UNIQUE ] INDEX indexName ON mytable(columnname(length));          <ul>           <li>如果是CHAR,VARCHAR类型,length 可以小于字段实际长度;</li>           <li>如果是 BLOB 和 TEXT 类型,必须指定 length。</li>          </ul> </li>         <li>ALTER mytable ADD [UNIQUE ] INDEX [indexName] ON (columnname(length))</li>        </ul> </li>       <li>删除        <ul>         <li>DROP INDEX [indexName] ON mytable;</li>        </ul> </li>       <li>查看        <ul>         <li>SHOW INDEX FROM table_name\G</li>        </ul> </li>       <li>使用 Alter 命令        <ul>         <li>有四种方式来添加数据表的索引:          <ul>           <li>ALTER TABLE tbl_name ADD PRIMARY KEY (column_list)            <ul>             <li>该语句添加一个主键,这意味着索引值必须是唯一的,且不能为NULL。</li>            </ul> </li>           <li>ALTER TABLE tbl_name ADD UNIQUE index_name (column_list)            <ul>             <li>这条语句创建索引的值必须是唯一的(除了NULL外,NULL可能会出现多次)。</li>            </ul> </li>           <li>ALTER TABLE tbl_name ADD INDEX index_name (column_list)            <ul>             <li>添加普通索引,索引值可出现多次。</li>            </ul> </li>           <li>ALTER TABLE tbl_name ADD FULLTEXT index_name (column_list)            <ul>             <li>该语句指定了索引为 FULLTEXT ,用于全文索引。</li>            </ul> </li>          </ul> </li>        </ul> </li>      </ul> </li>    </ul>    <p>MySQL索引结构</p>    <ul>     <li>BTree索引      <ul>       <li>检索原理        <ul>         <li> <p style="text-align:center"><img src="https://simg.open-open.com/show/28e67c3d4c40296aa0564ce0c55c8e1a.jpg"></p> </li>         <li><strong>【初始化介绍】</strong>          <ul>           <li>一颗b+树,浅蓝色的块我们称之为一个磁盘块,可以看到每个磁盘块包含几个 <strong>数据项</strong> ( <strong>深蓝色</strong> 所示)和 <strong>指针</strong> ( <strong>黄色</strong> 所示),如磁盘块1包含数据项17和35,包含指针P1、P2、P3。 P1表示小于17的磁盘块,P2表示在17和35之间的磁盘块,P3表示大于35的磁盘块。</li>           <li><strong>真实的数据存在于叶子节点</strong> 即 3、5、9、10、13、15、28、29、36、60、75、79、90、99。</li>           <li>非叶子节点只不存储真实的数据,只存储指引搜索方向的数据项 ,如17、35并不真实存在于数据表中。</li>          </ul> </li>         <li><strong>【查找过程】</strong>          <ul>           <li>如果要查找数据项29,那么首先会把磁盘块1由磁盘加载到内存,此时发生一次IO,在内存中用二分查找确定29在17和35之间,锁定磁盘块1的P2指针,内存时间因为非常短(相比磁盘的IO)可以忽略不计,通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存,发生第二次IO,29在26和30之间,锁定磁盘块3的P2指针,通过指针加载磁盘块8到内存,发生第三次IO,同时内存中做二分查找找到29,结束查询,总计三次IO。</li>           <li>真实的情况是,3层的b+树可以表示上百万的数据,如果上百万的数据查找只需要三次IO,性能提高将是巨大的,如果没有索引,每个数据项都要发生一次IO,那么总共需要百万次的IO,显然成本非常非常高。</li>          </ul> </li>        </ul> </li>      </ul> </li>    </ul>    <p>未完待续</p>    <p> </p>    <p>来自:http://www.jianshu.com/p/2717d4fbd474</p>    <p> </p>