sql查询未走索引问题分析之查询数据量过大

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了sql查询未走索引问题分析之查询数据量过大相关的知识,希望对你有一定的参考价值。

前因:

客户咨询,有一个业务sql(代表经常被执行且重要),全表扫描在系统占用资源很高(通过ash报告查询得到信息)

思路:

1.找到sql_text,sql_id

2.查看执行计划

3.查询sql涉及对象的对象数据量,段大小,行数量,where条件列,是否存在索引,列的选择读情况如何

4.总结,优化整改

1.找到sql_text,sql_id

094cmrxrahdy2
SELECT 8~10个列名称(由于设计用户信息,因此部分信息不再详细说明)
FROM Prescription 
WHERE ProcFlg=0 AND(Group_No=0 OR Group_No=1 OR Group_No=99) AND MachineNo<>99 ORDER BY Presc_Class DESC, PrescriptionNo, SeqNo;

2.查看执行计划

SQL> select * from table(dbms_xplan.display_cursor(094cmrxrahdy2,format=>iosTATS LAST));
PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------
Plan hash value: 1208083363
----------------------------------------------------
| Id | Operation | Name | E-Rows |
----------------------------------------------------
| 0 | SELECT STATEMENT | | |
| 1 | SORT ORDER BY | | 335K|
|* 2 | TABLE ACCESS FULL| PRESCRIPTION | 335K|
----------------------------------------------------
PLAN_TABLE_OUTPUT
-----------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(("PROCFLG"=0 AND INTERNAL_FUNCTION("GROUP_NO") AND "MACHINENO"<>99))
INTERNAL_FUNCTION 内部函数,一般执行计划看到这个需要特殊关注,但是本次确认输入的数值类型等同于字段类型

GROUP_NO NOT NULL NUMBER(2)

3.查询sql涉及对象的对象数据量,段大小,行数量,where条件列,是否存在索引,列的选择读情况如何

1)查询表所在的用户
select owner,object_name,object_type,status from dba_objects where object_name=PRESCRIPTION OWNER OBJECT_NAME OBJECT_TYPE STATUS -------------------- -------------------- ------------------- ------- PUBLIC PRESCRIPTION SYNONYM VALID PHARMACY PRESCRIPTION TABLE VALID
2)查询表的段大小

select sum(bytes)/1024/1024 from dba_segments where segment_name=‘PRESCRIPTION‘ and owner=‘PHARMACY‘;
SUM(BYTES)/1024/1024
--------------------
450

3)查询表上的索引,及索引对应列名称

select index_owner,index_name,column_name,COLUMN_POSITION from dba_ind_columns where table_owner=‘PHARMACY‘ and table_name=‘PRESCRIPTION‘

INDEX_OWNER INDEX_NAME COLUMN_NAME COLUMN_POSITION
------------------------------ -------------------- -------------------- ---------------
PHARMACY PRESCRIPTION_IDX1 PRESC_CLASS 1
PHARMACY PRESCRIPTION_IDX1 PRESCRIPTIONNO 2
PHARMACY PRESCRIPTION_IDX1 SEQNO 3
PHARMACY PRESCRIPTION_IDX2 PROCFLG 1
PHARMACY PRESCRIPTION_IDX3 PROCFLG 1
PHARMACY PRESCRIPTION_IDX3 GROUP_NO 2
PHARMACY PRESCRIPTION_IDX3 MACHINENO 3
PHARMACY PK_PRESCRIPTION PRESCRIPTIONNO 1
PHARMACY PK_PRESCRIPTION SEQNO 2

9 rows selected.

--第一,where 条件的三个列,再上述结果中,均存在对应的记录,所以基本可以排除无索引导致全表扫描的问题

--第二,产生疑问,存在索引,为何未使用索引???  猜测数据倾斜严重,SQL查询数据量过大,统计信息不准确等信息导致的问题,需要进一步进行分析

 

4)查询表行数量,及最后一次收集统计信息的时间

SQL> select num_rows,last_analyzed  from dba_tables where owner=‘PHARMACY‘ and table_name=‘PRESCRIPTION‘;

NUM_ROWS    LAST_ANALYZED
-----------------------------
1560341    2018-11-27 22:01:31

5)查询where 条件列的选择性(及去重后的行数量)

WHERE ProcFlg=0 AND(Group_No=0 OR Group_No=1 OR Group_No=99) AND MachineNo<>99 

 

看起来最差的选择性<>条件MachineNo列

查询发现,表总160万行,MachineNo列只有一个值1,也不存在Null值,where条件<>99,是无价值的条件,但是不至于影想走索引,此条件近乎无用

SQL> select count(*),count(distinct MachineNo) from PHARMACY.PRESCRIPTION;
COUNT(*) COUNT(DISTINCTMACHINENO)
---------- ------------------------
1604912 1
--
SQL> select MachineNo,count(*) from PHARMACY.PRESCRIPTION group by MachineNo;
MACHINENO COUNT(*)
---------- ----------
1 1604912



看起来选择性最好的条件ProcFlg=0, 符合这个条件的数值表中存在49万条记录,占表中记录的1/4,选择性已经很差了

SQL> select count(*),count(distinct ProcFlg) from PHARMACY.PRESCRIPTION;
COUNT(*) COUNT(DISTINCTPROCFLG)
---------- ----------------------
1604912 4
select ProcFlg,count(*) from PHARMACY.PRESCRIPTION group by ProcFlg;
PROCFLG COUNT(*)
---------- ----------
-1 7
1 1110365
2 995
0 493545 


看起来选择性中等的Group_No=0 OR Group_No=1 OR Group_No=99--符合条件的数值足有110万条记录

select count(*),count(distinct Group_No) from PHARMACY.PRESCRIPTION;
COUNT(*) COUNT(DISTINCTGROUP_NO)
---------- -----------------------
1604912 2
select Group_No,count(*) from PHARMACY.PRESCRIPTION group by Group_No;
GROUP_NO COUNT(*)
---------- ----------
1 1111367
2 493545 

--组合过滤后,只有4种可能性,对于本次sql,

--条件ProcFlg=0 存在50万条记录
--Group_No 1 or 0 or 99 返回110万行记录

--全表 1604912 --160万行记录,提取记录110/160=68.5%数据量,执行效率过低,还不如走全表扫描

SQL> select count(*),count(distinct ProcFlg||‘ ‘||Group_No) from PHARMACY.PRESCRIPTION;

COUNT(*) COUNT(DISTINCTPROCFLG||‘‘||GROUP_NO)
---------- ------------------------------------
1604914 4

 

 4.总结,优化整改

1)该SQL走全表扫描是正确的,全表扫描比回表查询65%全表数据量更快

2)提高该SQL性能,无法从索引入手,因为SQL是查询10个列,且数据量过大,不适用索引快速检索数据

3)建议开发人员,重新针对业务逻辑,规划新表:

01对每个表建立主键约束(唯一值),让业务SQL能快速定位一个唯一的记录,通过索引,快速检索少量数据,减少资源的消耗(逻辑读等消耗);

02或者根据应用需求,将此表进行拆分多个小表,这样即使是全表扫描,相对来说量级别减少,查询时间可能会提升,但是资源消耗并未降低(逻辑读等消耗);

 





















































以上是关于sql查询未走索引问题分析之查询数据量过大的主要内容,如果未能解决你的问题,请参考以下文章

如何查询慢SQL产生的原因

戈多编程-小谈sql语句的优化分析

优化SQL Server数据库查询方法

MyBatis中使用流式查询避免数据量过大导致OOM

50种方法优化SQL Server数据库查询

50种方法优化SQL Server数据库查询