目录

• • • 1.通过慢查询日志定位到具体那一条SQL
    • 2. 分析慢查询的原因
    • 3.具体优化方案

 

1.通过慢查询日志定位到具体那一条SQL

通过配置两个参数来输出慢查询sql：
① set global slow_query_log = on （开启慢查询日志）
② set global long_query_time = 1000 （设置sql执行时间超过多少就打印日志，以毫秒为单位，所以这里是超过1秒的sql语句都会输出在slow log）

默认输出在mysql安装路径的data路径下

可以看到具体的查询消耗时间，阻塞时间，扫描行数，返回的行数等

---

2. 分析慢查询的原因

分析Explain：
     ① type：索引是否失效（是否走了预想的索引）。
     ② rows：是否扫描了额外的记录慢sql查找优化
     ③ key，possible_key：同①，结合type分析。
这一步的分析个人觉得，主要是判断出是数据导致的慢查询（如一次查询数据过多），还是sql语句的错误攥写导致的慢查询。数据导致的就改库表结构或重构sql，sql语句导致的就看sql哪写的不好

---

3.具体优化方案

重构查询：
     ① 根据具体情况决定将sql写成一个复杂查询，还是多个简单查询（在应用程序合并结果集）。
     ② 切分操作（例如：删10万条数据拆分成10次操作）
     ③ 分解关联查询（分为单表查询，将结果集在应用程序进行关联）
     ④ 尽量让二级索引实现覆盖索引，避免回表

大表优化：
     ① 优化sql，索引
     ② 加缓存（如Redis）
     ③ 限定访问数据的范围
     ④ 读/写分离（主库写，从库读）
     ⑤ 垂直分表（优点：缩小结构，易于维护。缺点：主键冗余等）
     ⑥ 水平分表（分表帮助小，最好分库）

针对慢sql优化思路整理，一共可以分为以下三步

一、开启慢查询

二、通过explain关键字进行sql语句的分析

三、具体的优化步骤

1、首先要避免全表扫描，检查是否有索引

2、查看索引是否生效(以下是索引失效的部分场景)

3、sql结构的优化

4、数据库表设计的优化

一、开启慢查询

开启慢查询有两种方式：

1⃣️修改配置文件

windows下：配置文件为my.ini，一般在mysql的安装目录下，或c:\\windows下

linux下：配置文件为my.cnf，一般在/etc下

在配置文件的[mysqld]下加入如下语句

[mysqld]
slow_query_log = ON
slow_query_log_file = /usr/local/mysql/data/slow.log
long_query_time = 1

2⃣️通过数据库开启慢查询

修改配置文件需要重启mysql sever进程mysqld才会生效，线上环境可以通过指令来开启慢查询

set global slow_query_log = 'ON'：设置参数为ON，开始慢查询
set global slow_query_log_file = '/slowlog/log.log'：记录超时的语句的文件夹
set global long_query_time = 2：超过该时间的语句会被记录到日志中

二、通过explain关键字进行分析

其中比较重要的几个参数

1、possible_keys：可能使用到的索引
2、key：实际上使用到的索引
3、type：查询使用的类型
4、rows：查询到需要的数据，扫描了多少行

对于type，从坏到好all < index < range < ref < eq_ref < const

一般保证达到range，ref最好（const写死一个常量、eq_ref针对主键或唯一键查询结果唯一、ref针对非唯一键查询多个、range索引范围查询、index全索引扫描、all全表扫描)

三、具体的优化步骤

1、首先要避免全表扫描，检查是否有索引

• 没有索引考虑是否建立索引(可以在经常需要查询的列上、需要排序的列上添加索引)

2、查看索引是否生效(以下是索引失效的部分场景)

• 不满足最左匹配原则
• like以%开头或者全模糊
• >、<号右边的索引会失效
• or也会导致索引失效(在or的两边都加索引才不会失效或者使用union(去重)、union all(不去重)替代or)
• !=、<>也会导致索引失效
• 在where子句中使用表达式操作、函数操作等

3、sql语句结构的优化

• 避免使用select*，不要返回不必要的字段，增加索引覆盖的概率
• 尽量减少子查询(子查询会创建临时表，查询完毕删除临时表)
• 调整where子句的连接顺序，将过滤数据多的条件放在前面，最快速度缩小结果集
• 尽量减少联表查询，联表查询是笛卡尔乘积的形式，检索的数据几何倍上升
• 一次查询的结果最好不要过大，可以使用分页查询

4、数据库表设计的优化

• 单表的字段最好不要超过20个。如果是比较大的表，有的字段使用的多，有的字段使用比较少，使用频率比较少的会拖慢查询速度
• 表的结构是否合理(范式、反范式需要结合实际场景来决定)
• 列类型的选择是否合适(能用int却用了bigint等)

参考资料：官方文档SQL Tuning Guide

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/tgsql/sql-performance-fundamentals.html#GUID-DD9CAA74-3E0B-48C9-8770-AADB614BC992

Oracle Database 2 Day + Performance Tuning Guide

Oracle Performance Tuning Guide

如何发现慢SQL

主动发现

DBA和开发人员均可通过平台来发现某时间段、某数据库实例上的慢SQL信息。但平台中只能简单的查看一些执行计划以及执行过程的统计信息，需要更详细信息还是要去数据库查询，目前慢优化这块待完善。

通过ASH&AWR去发现

从ash查看某段时间SQL的等待总次数，CPU、IO等维度

col type for a10 
select * from ( 
select 
     ash.SQL_ID , ash.SQL_PLAN_HASH_VALUE Plan_hash, aud.name type, 
     sum(decode(ash.session_state,'ON CPU',1,0))     "CPU", 
     sum(decode(ash.session_state,'WAITING',1,0))    - 
     sum(decode(ash.session_state,'WAITING', decode(wait_class, 'User I/O',1,0),0))    "WAIT" , 
     sum(decode(ash.session_state,'WAITING', decode(wait_class, 'User I/O',1,0),0))    "IO" , 
     sum(decode(ash.session_state,'ON CPU',1,1))     "TOTAL" 
from v$active_session_history ash, 
     audit_actions aud 
where SQL_ID is not NULL  
   and ash.sql_opcode=aud.action 
   and ash.sample_time > sysdate - &minutes /( 60*24) --最近几分钟的时间范围
 --and ash.sample_time between to_timestamp('&begin_time','yyyy-mm-dd hh24:mi:ss') and to_timestamp('&end_time','yyyy-mm-dd hh24:mi:ss') --某段时间范围
group by sql_id, SQL_PLAN_HASH_VALUE   , aud.name 
order by sum(decode(session_state,'ON CPU',1,1))   desc 
) where  rownum < 20;  --取TOP 20条等待次数最多sql

从AWR报告查看TOP SQL

awr中重点关注某问题段时间一般间隔为15分钟，top sql，主要关注平均每次执行的时间以及执行sql耗用资源情况。

 

按照某top sql维度从awr基表中批量获取慢SQL

适合做营销活动前主动的从awr资料库里面抓取最近几天的所有慢SQL

select dbms_lob.substr(sql_text, 100) sqla, AA.*, BB.SQL_TEXT
  from (select sql_id,
               plan_hash_value,
               object_name,
               BUFFER_GETS,
               EXECUTIONS,
               BUFFER_GETS / decode(nvl(EXECUTIONS, 1), 0, 1, EXECUTIONS) as BUFFER_GETS_Per_Exec,
               DISK_READS / decode(nvl(EXECUTIONS, 1), 0, 1, EXECUTIONS) as DISK_READS_Per_Exec,
               ELAPSED_TIME / 1000000 as to_time,
               io_wait / 1000000 as io_time,
               round(io_wait / ELAPSED_TIME * 100) || '%' ioa_time,
               -- round(CPU_TIME/ELAPSED_TIME*100)||'%' cpua_time,
               row_processed / decode(nvl(EXECUTIONS, 1), 0, 1, EXECUTIONS) rows_processed_1exec,
               ELAPSED_TIME / decode(nvl(EXECUTIONS, 1), 0, 1, EXECUTIONS) /
               1000000 as ELAPSED_TIME_Per_Exec,
               CPU_TIME / decode(nvl(EXECUTIONS, 1), 0, 1, EXECUTIONS) /
               1000000 as CPU_TIME_Per_Exec
          from (select b.sql_id sql_id,
                        b.plan_hash_value,
                        o.object_name,
                        sum(nvl(b.EXECUTIONS_DELTA, 3)) as EXECUTIONS,
                        sum(nvl(b.DISK_READS_DELTA, 3)) as DISK_READS,
                        sum(nvl(b.iowait_DELTA, 3)) as io_wait,
                        sum(nvl(b.BUFFER_GETS_DELTA, 0)) as BUFFER_GETS,
                        sum(nvl(b.CPU_TIME_DELTA, 0)) as CPU_TIME,
                        sum(nvl(b.rows_processed_delta, 0)) as row_processed,
                        -- b.rows_processed_delta
                        sum(nvl(b.ELAPSED_TIME_DELTA, 0)) as ELAPSED_TIME
                   from DBA_HIST_SQLSTAT  b,
                        dba_hist_snapshot a,
                        dba_hist_sql_plan p,
                        dba_objects o
                  where /*b.sql_id in
                                                                          (select distinct (sql_id)
                                                                             from dba_hist_active_sess_history t
                                                                            where session_id in (708,978)
                                                                              and sql_id is not null
                                                                              and to_char(t.sample_time, 'yyyy-mm-dd hh24-mi-ss') >=
                                                                                  '2016-05-26 21-00-00'
                                                                              and to_char(t.sample_time, 'yyyy-mm-dd hh24-mi-ss')<=
                                                                                  '2016-05-26 23-50-00')
                                                                      and  */
                  b.snap_id = a.snap_id
               and b.parsing_schema_name in ('CCIC', 'CCICAGT')
               and b.instance_number = a.instance_number
               and b.sql_id = p.sql_id
              -- and p.options = 'FULL'
               and p.object_name=o.object_name
               and to_char(a.begin_interval_time, 'yyyy-mm-dd hh24-mi-ss') >=
                  '2016-06-02 09-00-00'
               and to_char(a.end_interval_time, 'yyyy-mm-dd hh24-mi-ss') <=
                  '2016-06-02 17-40-00'
                 --and b.snap_id >= 67040
                 -- and b.snap_id <= 67050
                  group by b.sql_id, b.plan_hash_value,o.object_name)) aa,
       dba_hist_sqltext bb
 where AA.sql_id = BB.sql_id
   and BUFFER_GETS_Per_Exec > 10000
 order by -- to_time desc
          BUFFER_GETS_Per_Exec desc

被动发现

1、慢SQL监控告警：

2、开发人员主动找到DBA说有慢SQL

 

3、数据库出现性能问题告警

阻塞会话告警

活跃会话数告警

CPU、IO等告警

分析并优化慢SQL

开发人员反馈某个应用的SQL卡住了， 一直未返回结果

现象：开发人员发现某业务SQL没有反应，应用接口其它SQL正常。 DBA接收到阻塞会话和活跃会话告警信息。

一般是dba先接收到告警。这时候可以先去查看活跃会话，看看数据库当前节点在忙些啥？

接收到的告警：

同一时间开发人员反馈执行有问题的SQL

问题原因分析：

造成活跃会话升高原因基本上都是被瓶颈问题阻塞了，常见的有频次高的慢SQL，应用接连不断的发送sql 但执行比较慢，累积的越来越多活跃会话。阻塞会话过多，8成是遇到锁特别是行锁。

先看看活跃会话情况：

set linesize 200 
col sid format 999999 
col s# format 9999999 
col username format a15 
col event format a40  
col BLOCKING_SESSION format 999999  
col machine format a20 
col p123 format a30 
col wt format 999 
col spid format a15 
col SQL_ID for a18 
   SELECT /* XJ LEADING(S) FIRST_ROWS */
    S.SID,
    S.SERIAL# S#,
    S.USERNAME,
    S.MACHINE,
    S.EVENT,
    S.BLOCKING_SESSION,
    S.P1 || '/' || S.P2 || '/' || S.P3 P123,
    S.WAIT_TIME WT,
    NVL(SQL_ID, S.PREV_SQL_ID) SQL_ID
     FROM V$SESSION S
    WHERE S.STATUS = 'ACTIVE' and S.TYPE <>'BACKGROUND';

查询结果如下：

从活跃会话查询结果中看到，sql ba2wr7m4xcrzx的等待事件都是关于行锁的enq:Tx - row lock contention，并且阻塞者的会话是6829，阻塞源头基本断定是6829，后面看看会话6829在干啥。

执行查询sql:

set linesize 200 
col sid format 999999 
col s# format 9999999 
col username format a15 
col event format a40  
col BLOCKING_SESSION format 999999  
col machine format a20 
col p123 format a30 
col wt format 999 
col spid format a15 
col SQL_ID for a18 
col PROGRAM for a18 
col MODULE for a18 
alter session set cursor_sharing=force; 
   SELECT /* XJ LEADING(S) FIRST_ROWS */
    S.inst_id,
    S.SID,
    S.SERIAL# S#,
    S.USERNAME,
    S.MACHINE,
    S.PROGRAM,
    S.MODULE,
    S.EVENT,
    S.BLOCKING_SESSION,
    S.P1 || '/' || S.P2 || '/' || S.P3 P123,
    S.WAIT_TIME WT,
    NVL(SQL_ID, S.PREV_SQL_ID) SQL_ID
     FROM gV$SESSION S
    WHERE S.TYPE <>'BACKGROUND' 
       and S.sql_id = '&sql_id'
       order by 1,2; 

执行结果：

接下来在看看会话6829上sql 5haaxd3zxbqgc在跑啥？

select sql_id,sql_fulltext from v$sql where sql_id='5haaxd3zxbqgc' and rownum=1;
或者直接查看执行计划以及sql文本，看的信息更多一些
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(to_char('&SQL_ID'),&child_NULL,'ADVANCED'));

发现是阻塞者和被阻塞者都是在更新同一张表中的某些行数据，更新到相同的行就会造成行锁冲突。解决也很简单，kill掉阻塞源头就可以，但DBA这个时候要作出评估。

1）、立马把SQL语句丢到开发沟通群，快速询问 这是阻塞源头是否可以立马kill掉，请尽快评估kill掉对业务是否有影响

2）、多次查询活跃会话，持续关注该库上的告警信息，看活跃会话和阻塞会话是否一直在快速增加

如果活跃会话和阻塞会话一直增加，数据库性能不可控。DBA要果断kill该阻塞源头。

alter system kill session '6829,43685' immediate;
或者通过sql_id生成相关kill语句
SELECT q'[alter system kill session ']'||S.SID||','||S.SERIAL#||q'[' immediate;]' sql_text from V$SESSION S
 WHERE S.sql_id = '&sql_id' 
   AND S.STATUS = 'ACTIVE'; 

如果数据库性能暂时可控，告知开发后果后，等待他们答复后再处理。等开发人员做好准备工作后就可以kill该会话。

 

收尾工作：

持续关注该库上的告警信息，同时关注因kill掉了大事物的DML语句，关注数据库回滚情况。

alter session set NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS'; 
 select usn, state, undoblockstotal "Total", undoblocksdone "Done", undoblockstotal-undoblocksdone "ToDo", 
            decode(cputime,0,'unknown',sysdate+(((undoblockstotal-undoblocksdone) / (undoblocksdone / cputime)) / 86400)) 
             "Estimated time to complete" 
  from v$fast_start_transactions; 

如果回滚事物太慢，可以考虑调整参数：

alter system set "_rollback_segment_count" = 2000;

 

开发人员反馈同样SQL昨天好好，今天突然变慢

一般分这几种情况：

1）、执行计划变了，最常见

2）、之前绑定的执行计划，随着数据量的增长已经不合适了。

3）、修改了数据库参数，特别是优化器相关的参数，问题sql是定时跑的，并没有立马体现出来。比较少见。

分析思路与解决方案：

执行计划抖动，绑定

开发人员给出的sql往往是sql文本，并且很有可能是同一张表雷同SQL,只是有细微差异，体现在数据库中的是不同SQL_ID。这种情况不能完全相信开发人员给出的sql，一定要根据提供的信息去数据库里面再找找，把所有雷同的sql列出来。解决问题不仅要解决问题点，还要覆盖到问题面。

核对慢sql 看平台上慢SQL，以及查v$SQL

select sql_id,sql_fulltext from v$sql where sql_text like '%sql注释部分%'

查看sql执行情况，对比性能好时段和变差时段执行计划变更情况

col PLAN_HASH_VALUE for 9999999999 
col instance_number for 9 
col snap_id heading 'SnapId' format 999999 
col executions_delta heading "No. of exec" 
col date_time heading 'Date time' for a20 
col avg_lio heading 'LIO/exec' for 999999999999 
col avg_cputime_s heading 'CPUTIM/exec' for 99999 
col avg_etime_s heading 'ETIME/exec' for 999999 
col avg_pio heading 'PIO/exec' for 999999999 
col avg_row heading 'ROWs/exec' for 9999999999 
col sql_profile format a35 
SELECT distinct 
s.snap_id , 
s.instance_number, 
PLAN_HASH_VALUE, 
to_char(s.BEGIN_INTERVAL_TIME,'mm/dd/yy_hh24mi')|| to_char(s.END_INTERVAL_TIME,'_hh24mi') Date_Time, 
SQL.executions_delta, 
SQL.buffer_gets_delta/decode(nvl(SQL.executions_delta,0),0,1,SQL.executions_delta) avg_lio, 
(SQL.cpu_time_delta/1000000)/decode(nvl(SQL.executions_delta,0),0,1,SQL.executions_delta) avg_cputime_s , 
(SQL.elapsed_time_delta/1000000)/decode(nvl(SQL.executions_delta,0),0,1,SQL.executions_delta) avg_etime_s, 
SQL.DISK_READS_DELTA/decode(nvl(SQL.executions_delta,0),0,1,SQL.executions_delta) avg_pio, 
SQL.rows_processed_total/decode(nvl(SQL.executions_delta,0),0,1,SQL.executions_delta) avg_row, 
SQL.sql_profile 
FROM dba_hist_sqlstat SQL,dba_hist_snapshot s 
WHERE 
SQL.dbid =(select dbid from v$database) 
and s.snap_id = SQL.snap_id 
and sql.instance_number = s.instance_number 
AND sql_id in ('&sql_id') order by s.snap_id; 

如果结果中看出来执行计划变更了，那就要考虑把问题sql的执行计划绑定。

使用COE脚本绑定步骤：

脚本下载地址：https://github.com/AlbertCQY/scripts/blob/master/oracle/sql_profile_new2.sql

脚本简单说明：原始coe脚本出自oracle MOS官方，sql_profile_new2.sql脚本是oracle官方高级售后DBA修改的增强版。可以绑定执行计划、替换执行计划。

@sql_profile_new2.sql
Parameter 1:
SQL_ID (required)

Enter value for 1:  --这里传入需要优化的sqlid
Parameter 2:
PLAN_HASH_VALUE (required)

Enter value for 2:  --这里传入正确执行计划的PLAN_HASH_VALUE，可以不是Parameter 1对应sqlid的plan_hash

最后在当前目录下生成一个要执行的脚本，包含sql_id和plan hash
比如：coe_xfr_sql_profile_62159umsg6z8m_4105682492.sql
绑定执行计划就直接执行上面生成的脚本。

刷新sql执行计划游标:

select PLAN_HASH_VALUE,q'[exec sys.dbms_shared_pool.purge(']'||address||','||hash_value||q'[','C');]' as flush_sql 
  from v$sqlarea where sql_id='63u74y7gdafzf';
 得到刷新语句后直接执行即可。
                                                                                            

绑定执行计划后重新查看下sql执行计划信息，如果还是原来的执行计划则有可能是coe绑定成功了，但由于sql正在执行中 导致执行计划游标刷出失败。需要和开发沟通是否可以kill掉正在执行sql的会话，然后再去刷新即可。

 

构造新的执行计划，解绑->绑定新的

如果发现sql上面已经绑定了执行计划，但随着表上数据量的增长，以及业务逻辑的变更，绑定的执行计划已经不适合了，需要解绑并替换为更优的执行计划。

构造想要的执行计划：hint提示方法

由于业务评估失误以及数据量的不断增长，该sql在项目开始时候评估下来适合走object_id列上的索引，并且也做了执行计划的绑定。

现在业务数据产生了变化，需要按照预定方式走object_name列上的索引idx_name

原来sql(fvscnttfnqvkf)  select * from t_testplan where object_id=1 and object_name='test'
Plan hash value: 2317386271

------------------------------------------------------------------------------------------
| Id  | Operation                   | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |            |     8 |  1656 |     2   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS BY INDEX ROWID| T_TESTPLAN |     8 |  1656 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IDX_ID     |    14 |       |     1   (0)| 00:00:01 |
------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("OBJECT_NAME"='test')
   2 - access("OBJECT_ID"=1)

加hint后sql(9xtcn2g6n7gsw)  select /*+INDEX(t_testplan idx_name) */ * from t_testplan where object_id=1 and object_name='test'
Plan hash value: 1801285354

--------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |            |     7 |  3367 |    12   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS BY INDEX ROWID BATCHED| T_TESTPLAN |     7 |  3367 |    12   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN                  | IDX_NAME   |    16 |       |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("OBJECT_ID"=1)
   2 - access("OBJECT_NAME"='test')

现在需要把fvscnttfnqvkf的执行计划替换为9xtcn2g6n7gsw的执行计划

 

第一步：删除绑定的执行计划(解绑profile)

 

select name from dba_sql_profiles where name like '%fvscnttfnqvkf%';

BEGIN 
DBMS_SQLTUNE.DROP_SQL_PROFILE(name => 'SYS_SQLPROF_fvscnttfnqvkf'); 
END; 
/

 

第二步：绑定执行计划

@sql_profile_new2.sql
Parameter 1:
SQL_ID (required)

Enter value for 1:  --这里传入需要优化的sqlid fvscnttfnqvkf
Parameter 2:
PLAN_HASH_VALUE (required)  

Enter value for 2:  --这里传入加Hint后的9xtcn2g6n7gsw执行计划PLAN_HASH_VALUE 1801285354

参照之前的步骤，刷新执行计划游标。

 

开发人员反馈应用OOM告警，需要看下SQL是否有异常

场景分析：应用server内存OOM后，开发人员在分析应用代码以及框架没问题后，一般会找DBA查找SQL的原因。

1）、开发人员提供的SQL有很明显的全表扫描语句

比较少见，一般添加合适的索引即可。

2）、开发人员提供的带绑定变量的sql，并且dba提供了完整测试语句

开发提供的sql在数据库上测试了下，性能很好，返回的结果集也很小。但真的是这样么？这时候就要怀疑是不是没有给到出现OOM时绑定变量真正的传参值。

出现这种比较奇怪的信息不对称情况时，其实也挺好求证。查看该SQL历史执行情况，和之前的逻辑读、物理读、返回行数等对比下就知道了。如果问题时段这些指标相对高，那么八九不离十就是传参倾斜导致。

 

新上线了功能，第二天发现一堆性能告警

场景分析：新上线的SQL由于性能评估不到位，过段时间在业务高峰时段，逐渐暴露出来性能问题。

常见有缺少必要的索引：DBA根据表结构以及各列的统计信息来判断，下面分享两个常用的脚本

 

表维度，查看表上结构信息、统计信息等，tabstat.sql脚本：传入用户名+表名

https://github.com/AlbertCQY/scripts/blob/master/oracle/tabstat.sql

SQL维度，SQL语句所有关联的表上结构信息、统计信息等，sql10.sql脚本：传入sql_id

https://github.com/AlbertCQY/scripts/blob/master/oracle/sql10.sql

 

创建索引指导建议：

适合创建索引的列

• 索引覆盖(只select索引列)、避免排序(order by索引列)
• 复合索引尽量兼顾更多SQL(索引具有较多的使用场景)
• 该列在表中的唯一性特别高、有些状态列有倾斜值(符合少数)
• 复合索引等值谓词条件字段做前导列，非等值谓词条件字段放在后面
• 表关联使用Nested Loop 被驱动表的关联字段上建议创建索引
• SQL语句是主流的业务，具有高并发，where条件中出现的列可以考虑创建复合索引

不适合创建索引的列

• DML频繁的表不适合创建索引，索引会带来额外的维护成本
• 为了少数查询，并且频次不高的查询列上建索引(这类SQL考虑放读库执行)
• Where条件中不会使用的列也不适合创建索引

 

 

如何解决一条复杂的SQL

Oracle数据库不仅对OLTP型短平快的sql支持很好，OLAP型复杂的分析SQL同样支持很好。一般来说复杂SQL执行计划特别长，甚至超过200行，关联5张以上表或视图，无法快速分析出执行计划是否有问题，甚至执行计划还经常抖动。

 

优化思路：不管SQL写的多复杂，执行计划超级长，只需要抓住sql最影响性能的地方即可。

借助脚本plan_ash.sql或者sql10.sql脚本可以展示出最消耗性能的部分：https://github.com/AlbertCQY/scripts/blob/master/oracle/plan_ash.sql

比如下面这个执行计划，发现性能瓶颈在逻辑读上面，优化掉db file sequential read(2)(40%) 这一步骤的性能问题，该复杂SQL问题也就解决了。

 

Oracle官方工具篇：

Oracle官方提供了丰富的sql调优工具，面对复杂SQL善于使用官方提供的工具也是个不错的方法。

Oracle真的是博大精深,学习永无止境...

Information Center: Sql Performance Tuning: Troubleshoot (Doc ID 1516522.2)

 

SQL Tuning Advisor:

SQL Tuning Advisor (Doc ID 2582636.1)

Automatic SQL Tuning and SQL Profiles (Doc ID 271196.1)

Using the DBMS_SQLTUNE Package to Run the SQL Tuning Advisor (Doc ID 262687.1)

Example: SQL Tuning Task Options (Doc ID 2461848.1)

SQL Performance Analyzer Summary (Doc ID 1577290.1)

 

SQL Tuning Health-Check Script (SQLHC) (Doc ID 1366133.1)

NOTE:243755.1 - Script to produce HTML report with top consumers out of PL/SQL Profiler DBMS_PROFILER data

NOTE:1482811.1 - Best Practices: Proactively Avoiding Database and Query Performance Issues

NOTE:1460440.1 - Script PXHCDR.SQL: Parallel Execution Health-Checks and Diagnostics Reports

NOTE:1477599.1 - Best Practices: Proactive Data Collection for Performance Issues

NOTE:224270.1 - TRCANLZR (TRCA): SQL_TRACE/Event 10046 Trace File Analyzer - Tool for Interpreting Raw SQL Traces (NO LONGER SUPPORTED - Use SQLTXPLAIN sqltrcanlzr.sql)

NOTE:1627387.1 - How to Determine the SQL_ID for a SQL Statement

NOTE:1455583.1 - SQL Tuning Health-Check Script (SQLHC) Video

NOTE:215187.1 - All About the SQLT Diagnostic Tool

NOTE:1417774.1 - FAQ: SQL Health Check (SQLHC) Frequently Asked Questions

 

最后分享一个丁俊老师的一篇文章：

https://dbaplus.cn/news-10-1314-1.html