Oracle执行计划&统计信息

忙忙碌碌过完了一周，周四晚上睡的晚，周五又忙了一天，晚上九点左右一直睡到周六七点多，能睡吧，哈哈。上篇说到几天时间，谁能料到拖了一周，拖延症很严重，大家勿学毛竹哈，闲言少叙，书归正文，本片主要讲两大部分内容：执行计划和统计信息。
1执行计划
1.1什么是执行计划
SQL执行计划即一条查询语句执行过程或访问路径的描述，一般地，我们要分析某条SQL语句的性能问题，需要首先查看SQL的执行计划，通过执行计划可以定位性能问题，通过修改sql语句等方式达到优化SQL性能的效果。
1.2如何获取执行计划
说到怎么获取，之前毛竹有一次回单估计能被人家嘲笑死，我说我们就在PL/SQL Developer中查看，人家问如果客户不允许连接服务器，我就说那我们把库拉回来。想想互联网公司的数据库多大，得多久呀，后来我就反问人家，还好那人比较友善告诉了毛竹，从数据字典获取。其实高手都是玩命令的，我们都是借助工具的，所以有些事情并不是你不知道，而是你没有接触它的机会，书本终究是书本，实操才是王道。
获取执行计划的凡是有五种，下面我就逐一介绍一下。
1.SET AUTOTRANCE，不实际执行，执行计划不一定准确
2.explain plan for SQL，不实际执行，执行计划不一定准确
3.10046或SQL Trace，实际执行，借助tkprof
4.V$SQL_PLAN，数据库中实际执行的SQL
5.PL/SQL/SQL developer
1.2.1设置autotrace
SET AUTOTRANCE有四种

1.2.2explain plan for SQL
步骤：
1.explain for +SQL
2.select plan_table_output from table(DBMS_XPLAN.DISPLAY(‘PLAN_TABLE’));
3.select * from table(dbms_xplan.display);
与上一步结果相同。
特别提示：单词一定要敲正确哈。
1.2.3SQL Trace
关于SQL Trace这边比较好，供参考《sql trace的使用说明一》。
《Oracle sql trace用法》
1.2.4有乱码，图片代替吧
该语句执行后需要输入上一步获得的hash_value。
1.2.5PL/SQL/SQL developer
方式很简单，下图按钮/F5/工具–>解释计划三种方式都可以。

同时，我们还需要添加或删除一些选项，可以再工具–>首选中做配置，一般常用的有计数、字节、耗费、时间等。
基数（Rows）：Oracle估计的当前操作的返回结果集行数
字节（Bytes）：执行该步骤后返回的字节数
耗费（COST）、CPU耗费：Oracle估计的该步骤的执行成本，用于说明SQL执行的代价，理论上越小越好（该值可能与实际有出入）
时间（Time）：Oracle估计的当前操作所需的时间

好了，获取执行计划就说到这，下面干货来了，以PL/SQL Developer为例，谈谈执行计划中的琐琐碎碎。
我也看到有人介绍了6中，每种侧重点不同，如果想要了解更多，可关注《oracle执行计划（二）----如何查看执行计划》。
1.3怎么查看执行计划

执行顺序：
缩进最多的最先执行，缩进相同的先执行最上面的。
同一级如果某个动作没有子ID最先执行，同一级的动作执行时遵循最上面最右边最先执行原则。
当然了不知道怎么执行，可以点击按钮查看。
下面这个图要把手机/屏幕转动啦，知识点有点多。

Hash蛮重要的，大数据好多排序算法中用到hash排序，还有hashmap的源码等等，都是重点，有需要深入了解的自行查阅资料。
2统计信息
2.1什么是统计信息
描述数据库中表，索引的大小，规模，数据分布状况等的一类信息。例如，表的行数，块数，平均每行的大小，索引的leaf blocks，索引字段的行数，不同值的大小等，都属于统计信息。CBO正是根据这些统计信息数据，计算出不同访问路径下，不同join 方式下，各种计划的成本，最后选择出成本最小的计划。
2.2怎么获取
统计信息是存放在数据字典表中的，如tab$，一般可通过察看某些视图来获取统计信息状况，如DBA_TABLES,DBA_INDEXES,DBA_TAB_COL_STATISTICS, DBA_TAB_HISTOGRAMS等。在这些视图中包含表示统计信息的一些字段，这些字段只有搜集过统计信息之后才有值，否则是空的。例如，last_analyzed 字段表示上次统计信息搜集的时间，可以根据这个字段，快速的了解最近一次统计信息搜集的时间。
一般我们统计如下信息：

2.3统计信息有什么影响
在CBO(基于代价的优化器模式)条件下，SQL语句的执行计划由统计信息来决定，若没有统计信息则会采取动态采样的方式决定执行计划！可以说统计信息关乎sql的执行计划是否正确，属于sql执行的指导思想，oracle的初始化参数statistics_level控制收集统计信息的级别，有三个参数值:
BASIC :收集基本的统计信息
TYPICAL：收集大部分统计信息(数据库的默认设置)
ALL：收集全部统计信息
2.4实操
毛竹之前在开发中遇到有张表频繁的做DML（数据操作语言，insert、update、delete、merge），导致统计信息不准确，从而影响查询效率，可通过查询统计信息做适当操作，使得统计信息更准确。
当然了，这只是我们在工作中遇到此类问题最简单粗暴的办法，而且这这张表与其他表的没有主外键约束，但建议慎用。
2.5大表优化之高水位（HWM）
关于高水位，只需要记住这句话，“高水位线在日常的增删操作中只会上涨，不会下跌”。如2.4中介绍一样，我们需要处理折中高水位问题。
参考
《oracle 高水位线详解》
3.SQL优化必备概念
《SQL优化之基本概念》

4.SQL优化利器
Oracle SQL monitor
《被埋没的SQL优化利器——Oracle SQL monitor》
《Oracle SQL 调优利器之Oracle Real-Time SQL Monitor》
5.写在最后
其实吧，SQL优化部分涉及到内容太多，毛竹在这篇引用好多前辈总结，还是那句话，很多事情也罢，东西也罢，没有最好，只有合适不合适，技术亦是如此。
说了这么多，必须总结呀，对吧，兑现之前的承诺，怎么回答SQL优化问题。还是上篇框架：
主题：SQL优化
框架：what-how-why
1.执行计划，怎么获取，怎么查看，表的链接方式、索引的访问方式、语句执行顺序等等；
2.统计信息：涉及到高水位，如果被问到大表优化，可以谈谈高水位问题；
3.书写规范，比如上篇总计的like，前模糊或全模糊不走索引等等；
4.其他：缩小数据量（先过滤主表的数据）、分区条件、等等。
数据+故事：可以谈一个之前优化的例子，优化前大概多久，优化后大概多久等等。
总之，SQL优化离不开执行计划和统计信息，也只有把执行计划和统计信息搞明白，SQL优化问题一定可以让对方满意。最近蚂蚁集团上市造就了大批百万富翁，正如齐俊杰评论一样，互联网行业是一个你努力就有汇报的行业，而且回报很高，而其他行业努力了不一定有回报。毛竹上周基金前四天还可以，最后一天跌了不少，感觉一周赚的又输回去了。总之，这个时代，仅仅靠工资收入来维持生计总有些吃力，再次还是建议拿出部分收入做一些保本的理财还是可以滴，加油。下周开始讲一些Java内容把，下周见。