摘自《Troubleshooting Oracle Performance》 对于B-树索引 如果在a,b,c三列分别建一个索引，则 … where a = xx and b = xx and c = xx 仍然非常低效 如果在a,b,c三列上建立联合索引，则 … where a = xx and b = xx and c = xx 会高效的多 而… where a = xx and b = xx 也会比较高效，即使c列没有出现在where子句 对于位图索引 如果在a,b,c三列分别建一个索引，则 … where …
Oracle: 索引 与… where a = xx and b = xx and c = xx Read More »
摘自《Troubleshooting Oracle Performance》 1.如果索引建在 a 列上，则 … where upper(a) = XX 用不上索引 … where a = upper(xx) 仍可以用得上索引 2.如果索引建在 upper(a) 这个函数上，或者实现了upper(a)的虚拟列上， 则 … where upper(a) = XX 可以用得上索引
摘自《Troubleshooting Oracle Performance》 … where a like ‘A%’ 可以用上索引，即Index Range Scan 但 … where a like ‘%A’则会导致全表扫描或全索引扫描 也就是说，如果以通配符开头，就会导致效率低的模糊搜索
摘自《Troubleshooting Oracle Performance》 假设 a 列上建了一条索引 1. 对于B-树索引 … where a is null 会导致全表扫描，因为B-树索引不存储NULL值 若a+b上有联合索引，则 … where a is null and b = xx 仍会使用索引 2.对于位图索引 … where a is null 仍然会使用索引，因为位图索引会存储NULL值
摘自《Troubleshooting Oracle Performance》 1. 对于B-树索引 a. 先按索引找到对应的row-id b. 再按row-id获取数据行 2. 对于位图索引 a.先在索引中找到符合条件的索引项 b.然后把该项转换成ROW-ID c.最后按row-id获取数据行
摘自《Troubleshooting Oracle Performance》 Index Unique Scan: 针对唯一性索引，只返回一个rowId Index Range Scan: 用于非唯一性索引，可以返回多个rowId
因为一个位图索引项可能索引数千行，一个位图锁引项修改，会导致数千行数据被锁
摘自《Troubleshooting Oracle Performance》 通过rowid获取数据行是效率最高的方式 典型的场景是： 1. select rowid from t where xx =xx 2. update t set yy=yy where rowid = xxx
摘自《Troubleshooting Oracle Performance》 可以看一下：执行计划中各步骤返回的结果集中，每行所需的逻辑读的数量。 逻辑读数较高，则这一步可能就是低效的 要得到单行的逻辑读数，那你的执行计划结果中需要有这么两列： 1. A-Rows 实际返回的行数 2. Buffers 返回这么多行所需的逻辑读的数量 单行逻辑读数 = A-Rows/Buffers 这个数字<=5 => 不错的访问路径 介于10和15之间 => 可以接受 超过20 => 低效
1. 避免硬解析 — 使用预备语句(JDBC里使用PreparedStatement) 2. 避免软解析 — 重用预备语句(JDBC里用完PreparedStatement后并不关闭，下次查数据库时还用这个对象) 3. 客户端语句缓存 — 重用游标(JDBC3.0 与 连接池共用时，JDBC会透明地替你缓存) 有时候你可能无权修改调用SQL的代码（比如这个代码处于二进制JAR包中），这时就只能在Oracle数据库服务器端作文章了 1. 打开“游标共享” — 数据库引擎会自动将字面量替换成绑定变量，避免硬解析。缺点是这个东西有BUG 2. 打开“服务器端语句缓存”