在数据库的使用中，数据库的性能往往是至关重要的问题，而数据库的性能问题大部分都是SQL引起的。
SQL执行慢有很多原因，有时候是SQL写法有问题，有时候是缺乏索引、统计信息过期，
还有可能是业务原因，无论那种原因，一般SQL优化我们都需要去查看SQL的执行计划，
了解SQL具体是慢在哪里，才知道从哪里开始优化。

一、获取执行计划常用方法

在日常运维过程中，我们查看执行计划只知道DM管理工具。
实际上，在达梦数据库中获取执行计划有6种，是不是觉的达梦数据库太强大了。
每种方法各有优劣，下面我们一一细看这些方法。

1.使用 EXPLAIN 查看执行计划

EXPLAIN：获得的执行计划是估算的执行计划
优点：
无需真正执行，快捷方便
缺点：
执行计划是估算的执行计划，有可能与真实执行计划存在差别
使用场景：
实用于可以快速返回结果的sql语句

2.使用 AUTOTRACE 查看执行计划

优点：
可以看到真实的执行计划
缺点：
需要等待SQL语句执行完成才会打印执行计划；
使用场景：
和EXPLAIN对比使用，可以判断统计信息有没有收集、过期

3.使用ET函数查看执行计划

SQL> sf_set_session_para_value('MONITOR_SQL_EXEC',1);
DMSQL executed successfully
used time: 0.793(ms). Execute id is 601.
SQL> select * from tb1 where name='张三';

LINEID     ID          NAME   AGE        
---------- ----------- ------ -----------
1          1000000     张三 32

used time: 1.350(ms). Execute id is 602.

优点：能够统计SQL 语句执行过程中每个操作符的实际开销
缺点：需要开启SQL监控：ENABLE_MONITOR、MONITOR_TIME、MONITOR_SQL_EXEC设置为1。sql监控功能的开启将对数据库整体性能造成一定影响，优化工作结束后尽量关闭该功能以提升数据库整体运行效率。
使用场景：通过EXPLAIN无法判断SQL性能，可以使用这种方法。

4.v$cachepln中获取执行计划

SQL> select cache_item, sqlstr from v$cachepln where sqlstr like 'select * from tb1%';           

LINEID     CACHE_ITEM           SQLSTR                                
---------- -------------------- --------------------------------------
1          140208247896176      select * from tb1 where name='张三';
2          140208246225008      select * from tb1 where name='杨凯';
SQL> alter session set events 'immediate trace name plndump level 140208247896176 , dump_file ''/dbms/dm8/dmdbms/log/yangkai.log''';
executed successfully
used time: 6.106(ms). Execute id is 803.

优点：在语句解析生成执行计划后就可以查询到；
缺点：步骤太繁琐
使用场景：SQL执行后长时间无法返回结果，可以使用这种查看。实际运维中很少使用此办法

5.dbms_sqltune系统包查看执行计划

优点：
可以实时监控SQL执行过程中的信息，包括：执行时间、执行代价、执行用户、统计信息等情况。
缺点：
需要开启SQL监控功能，数据库性能有影响
使用场景：
想知道执行计划每一步的代价，对于sql优化更有帮助

6.通过10053事件查看执行计划

SQL> alter session set events '10053 trace name context forever,level 1';
executed successfully
used time: 0.657(ms). Execute id is 1303.
SQL> select * from yangkai.tb1 where name='张三';

LINEID     ID          NAME   AGE        
---------- ----------- ------ -----------
1          1000000     张三 32

used time: 0.992(ms). Execute id is 1304.
SQL> alter session set events '10053 trace name context off';

*** Plan before optimized:
project[0x7f85483727e0]  (0);
select[0x7f85483721b0]  (1); (TB1.NAME = '张三')
 	base table[0x7f8548371b28] (TB1, FULL SEARCH) (0);

<<<<< selectivity estimate of table TB1 >>>>>
*** stdesc 1: column = NAME, scan_type = EQU, key = ('张三')
stat_info(33555468,0,'I')= {
                          #Valid = 'Y',
                          #Type  = 'Freq',
                          #Card  = 1000000,
                          #NDV   = 2,
                          #Nulls = 0,
                          #LP    = 2725,
                          #LVLS  = 2,
                          #CLUF  = 0,
                          #NK    = 0,
                          #NS    = 1000000}
 ---> st = 0.00000

>>>>> total: 1000000, estimate match rows: 1, st: 0.00000; -- st_other: 1.000, n_stdesc: 1

---------------- single table access path probe for TB1 ----------------
*** path 1: INDEX33555466 (FULL search), cost: 128.46251
*** path 2: INDEX33555467 (FULL search), cost: 1028.76071
*** path 3: IDX_NAME (EQU search), cost: 0.06525

>>> best access path: IDX_NAME (EQU search), cost: 0.06525

*** BEST PLAN FOR THIS STATEMENT ***
project[0x7f8548389b98]  (cost: 0.06525, rows: 1);
base table[0x7f854838a828] (TB1, IDX_NAME, EQU SEARCH) (cost: 0.06525, rows: 1);


优点：
可以详细看到每一步的COST
缺点：
需要详细的分析，步骤繁琐，执行计划中的扫描方式不能清晰的展示出来
使用场景：
怕影响性能，不敢开启SQL监控，又想查看详细的执行计划。用10053是个不错的方法。
备注:必须关闭SQL监控参数，才能使用（ENABLE_MONITOR=0。）