17,086
社区成员
发帖
与我相关
我的任务
分享ORACLE 有索引还要全表扫描
给这个表 TAB_SALE_PRICE_compensation 建了索引
但是其执行还是全表扫描，而且网上常见不走索引的问题都排查了，实在无奈~
还有就是调用视图时其他表也有类似情况，请各位大神瞅瞅，
有没有可能是数据库配置的问题？
...全文
请发表友善的回复…
发表回复
o_range 2016-08-19
- 打赏
- 举报
关键就是想找到慢的原因，这个表也就百万条数据，而且之前是好好的，查询很快，自从上次临时表空间爆掉之后就特别慢了；
大神，我不会看trace文件
[/quote]
贴上来，或者q给我 212646490[/quote]
好，多谢大神！
ghx287524027 2016-08-19
- 打赏
- 举报
关键就是想找到慢的原因，这个表也就百万条数据，而且之前是好好的，查询很快，自从上次临时表空间爆掉之后就特别慢了；
大神，我不会看trace文件
[/quote]
贴上来，或者q给我 212646490
o_range 2016-08-19
- 打赏
- 举报
关键就是想找到慢的原因，这个表也就百万条数据，而且之前是好好的，查询很快，自从上次临时表空间爆掉之后就特别慢了；
大神，我不会看trace文件
ghx287524027 2016-08-19
- 打赏
- 举报
关于组合索引有一点需要注意：当使用基于规则的优化器（RBO）时，只有当组合索引的前导列（第一列）出现在SQL语句的where子句中时，才会使用到该索引。但是即使走索引，效率也不一定就比其他方式高
o_range 2016-08-19
- 打赏
- 举报
试过了，不行~
js14982 2016-08-19
- 打赏
- 举报
把你索引第一个字段GOODSID，添加进关联试试
o_range 2016-08-19
- 打赏
- 举报
组合索引，我现在试下trace
ghx287524027 2016-08-19
- 打赏
- 举报
利用10053事件生成一个 SQL 分析过程的 trace 文件，分析一下执行计划的生成过程，看看到底是没有使用索引还是因为索引的成本比较大而选择了全表扫描。
先进行表分析：
exec dbms_ststs.gather_table_stats(user,'tablename',cascade=>true);
开启10053事件：
alter session set events '10053 trace name context forever,level 1';
执行sql：
explain plan for 要运行的sql
关闭命令：
alter session set events '10053 trace name context off';
trace 文件的目录：$ORACLE_BASE/admin/sid/udump
---------------
索引是这些列的组合索引还是每一列上都有索引？
o_range 2016-08-19
- 打赏
- 举报
名： IND_SALE_PRICE_COMPENSATION 列：GOODSID, CUSTOMID, CGAGENTID, CREDATE, ORG_ID, SUPPLYID。。
查了表里各项索引列的值，没有为空的
ghx287524027 2016-08-19
- 打赏
- 举报
分析表了吗？另外你的索引是怎么建的？
