生产系统MOKP表，100多万rows。SISN+EISN是Index。
[@more@]生产系统MOKP表，100多万rows。SISN+EISN是Index。
SISN列和EISN列都是前半段字母+后半段数字。
原SQL：
SELECT COUNT(*)
INTO v_CNT2
FROM MOKP
WHERE SISN <= p_DATA
AND EISN >= p_DATA
AND LENGTH(SISN) = LENGTH(p_DATA)。
结果Cost=1800up，consistent gets=12000多，走INDEX_FFS。
由于执行次数较多，这句便成为整个库第二大buffer gets的SQL。
Tuning的任务摆在面前，我观察了半天，Index 合适阿，又观察了下MOKP的数据分布：
最主要是SISN<=p_DATA<=EISN这个条件太模糊了，造成Index scan的范围太大。然而根据SISN<=p_DATA<=EISN，又从AP人员那里得知SISN和EISN的字母段都是相等的，那不就隐含了p_DATA和SISN的字母段相等么？
改一下：
SELECT COUNT(*)
INTO v_CNT2
FROM MOKP
WHERE SISN <= p_DATA
AND EISN >= p_DATA
AND LENGTH(SISN) = LENGTH(p_DATA) and SISN LIKE SUBSTR(P_DATA,1,6)||’%’;
再看结果：cost=3,consistent gets=3 ，爽快。
还是Tom的那句老话，优秀的design最重要。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/10856805/viewspace-1001168/ ，如需转载，请注明出处，否则将追究法律责任。
-
博文量43
-
访问量150220
最新文章
- Statspack_ORA-00001 奇怪的事
- Oracle: Grant 对high loading system，bind variable的影响
- ORA-00376 运气不好，遭遇这个
- 10.2.0.4 Listener 常挂掉的例子一个
- Oracle 9i DataGuard Failover 发生ORA-16139
- ORA-00600 [2103]的分析
- Oracle多表关联更新的方式选择, Loop or Hash update?
- 适当采用Histogram 让Oracle达成最优Execution Plan
- PL/SQL 批量Bind Forall 的性能表现
- Oracle SQL Like 的优化
