DB2 锁与Sql优化
正在加载中...
资料简介：
包含定位DB2死锁和锁等的详细方法。
尤其是死锁，可以定位到导致死锁的sql和其上下文关联的Sql，帮助您准确定位死锁缺陷。
另外还附上，平常调优常用的sql{:2_30:}
尤其是死锁，可以定位到导致死锁的sql和其上下文关联的Sql，帮助您准确定位死锁缺陷。
另外还附上，平常调优常用的sql{:2_30:}
2011-11-17
页数15
浏览5153
下载208
已下载用户的评价7.60分
您还未下载该资料，不能发表评价；
查看我的 待评价资源
查看我的 待评价资源
没用
以前还是太嫩了，有些地方有错误。如 Select * from employee A where A.type=’01’ or A.type=’08’ 或者 select * from employee where type in (‘01’ ‘08’) 事实上如果type有索引，这个sql完全可以走索引，因为or的两边条件都可以利用索引查询，而如果任意一边无法利用索引，则会全表扫描 哈哈，谢谢各位的指正
以前还是太嫩了，有些地方有错误。如 Select * from employee A where A.type=’01’ or A.type=’08’ 或者 select * from employee where type in (‘01’ ‘08’) 事实上如果type有索引，这个sql完全可以走索引，因为or的两边条件都可以利用索引查询，而如果任意一边无法利用索引，则会全表扫描 哈哈，谢谢各位的指正
没用
我测试了一个实例： 使用多个or时DB2优化器会改写成in谓词，如col='a' or col='b' or col='c' or col='d'，会改写成 con in ('a','b','c','d') 1)在条件字段col上如果有索引，那么in与or的成本一致，采用多次排序操作，采用索引完全扫描+排序+按RID表数据FETCH，这种情况下比union all成本要高出很多，union all采用索引范围扫描+按RID表数据FETCH。 2)在条件字段col上没有索引，那么in与or成本一致，比union all成本要小（多次使用表扫描）很多。 从而得出一个结论：在DB2中or与in效率是一样的，可以使用索引。
我测试了一个实例： 使用多个or时DB2优化器会改写成in谓词，如col='a' or col='b' or col='c' or col='d'，会改写成 con in ('a','b','c','d') 1)在条件字段col上如果有索引，那么in与or的成本一致，采用多次排序操作，采用索引完全扫描+排序+按RID表数据FETCH，这种情况下比union all成本要高出很多，union all采用索引范围扫描+按RID表数据FETCH。 2)在条件字段col上没有索引，那么in与or成本一致，比union all成本要小（多次使用表扫描）很多。 从而得出一个结论：在DB2中or与in效率是一样的，可以使用索引。