【性能分析】sql优化分析思路

【oracle数据库sql分析思路】

1、大表是否有建分区，字段是否有建索引
2、通过plsql的F5查看执行计划，是否走索引查询，还是全表查询；考虑联合索引
3、分页查询，对于一次查询量很大的逻辑
4、如果有多个关联条件，并且可以拆分，建议用UNION ALL进行查询，效率会有所提高
5、在业务中不要随便使用distinct、union、order by、group by操作。排序是比较消耗性能的操作，一次排序操作会导致全表或者全索引的扫描，在排序区内存不充足的情况下，大的排序就会用到临时表，增加了大量的IO操作。
6、索引和数据要放在不同的表空间，以减少IO争用。
7、sql不走索引，导致执行时间很长，这个时候需要加hint让它走强制索引，也是一种优化方法。

执行计分析方法：
执行计划其实就是一棵树，层次最深的最先执行，层次相同的按顺序执行

查询数据库锁表情况：
SELECT p.spid, a.serial#, c.object_name, b.session_id, b.oracle_username,b.os_user_name FROM v$process p, v$session a, v$locked_object b, all_objects c WHERE p.addr = a.paddr AND a.process = b.process AND c.object_id = b.object_id

2、如何解决锁表问题
做表分析、解锁
EXEC DBMS_STATS.GATHER_TABLE_STATS('CCRTQM', 'SUBS_UPP_INST', DEGREE=>3, CASCADE=>TRUE,ESTIMATE_PERCENT=>10);
EXEC DBMS_STATS.GATHER_TABLE_STATS('CCRTQM', 'RTQM_RERATING_SUBS', DEGREE=>3, CASCADE=>TRUE,ESTIMATE_PERCENT=>10);
EXEC DBMS_STATS.GATHER_TABLE_STATS('RBRTQM', 'EVENT_USAGE_C_1406', DEGREE=>3, CASCADE=>TRUE,ESTIMATE_PERCENT=>10);
exec dbms_stats.gather_schema_stats(OWNNAME=>'CCRTQM',CASCADE=>TRUE,ESTIMATE_PERCENT=>DBMS_STATS.AUTO_SAMPLE_SIZE,DEGREE=>4,no_invalidate=>false);

--查看被锁的表 
select b.owner,b.object_name,a.session_id,a.locked_mode from v$locked_object a,dba_objects b where b.object_id = a.object_id;

--查看那个用户那个进程造成死锁
select b.username,b.sid,b.serial#,logon_time from v$locked_object a,v$session b where a.session_id = b.sid order by b.logon_time;

--查看连接的进程 
SELECT sid, serial#, username, osuser FROM v$session;

--查出锁定表的sid, serial#,os_user_name, machine_name, terminal，锁的type,mode
SELECT s.sid, s.serial#, s.username, s.schemaname, s.osuser, s.process, s.machine,
s.terminal, s.logon_time, l.type
FROM v$session s, v$lock l
WHERE s.sid = l.sid
AND s.username IS NOT NULL
ORDER BY sid;
--这个语句将查找到数据库中所有的DML语句产生的锁，还可以发现，任何DML语句其实产生了两个锁，一个是表锁，一个是行锁。

--杀掉进程 sid,serial#
alter system kill session'210,11562';