讨论：db2得索引

显示全部楼层 · 2014-3-10 14:09:19

刚才看到大菠萝的问题，突然联想到很多东西自己也不大明白，特开帖讨论。
普通索引，正向索引，逆向索引，ALLOW REVERSE SCANS索引……这些在运用起来有什么不同？为什么？
俺先说俺对索引的理解：索引不过是根据磁盘中数据与用户定义的列所创建的B+树，当使用时，根据优化器的请求将请求范围之间所有数据的RID返回（这里所说的是start/stop key predicate）
所以问题就来了，当创建了索引以后，对于B+树为什么还需要定义是否allow reverse scan呢？在其表面下隐藏了什么东西？
感觉普通的B+树应该完全支持从后往前或者从前往后的检索呀……
（这里俺说的意思是对于唯一的一个索引列，如果有多个索引列自然会有很大不同）
如果大家不赞同俺的理解或者是有什么新的想法欢迎跟帖讨论……

千问 · 2014-3-10 14:09:19

?
要有效地搜索，决定对键使用升序还是降序，这取决于将最常使用的顺序。尽管当在 CREATE INDEX 语句中指定了 ALLOW REVERSE SCANS 参数时可以按逆向方向搜索值，但是，执行按指定索引顺序的扫描比执行逆向扫描稍微更快一些。这是DB2 V8的规定，DB2 V9默认情况下就是ALLOW REVERSE SCANS

千问 · 2014-3-10 14:09:19

在同一个列上（如果索引键只有一个）创建一个索引后，再创建一个索引，会失败，DB2会返回
SQL0605W 未创建索引，因为已经存在具有匹配定义的索引 ""。
SQLSTATE=01550

千问 · 2014-3-10 14:09:19

恩……正向比逆向要快……有意思，很想知道为什么的说~~~而且在index中只包含一列的情况下也是这样吗？
感觉对index的理解还是不能完全融会贯通，请大家再多多补充哦

千问 · 2014-3-10 14:09:19

在 DB2V9 中，缺省情况下所有主键、唯一键和索引（除了扩展的索引）都允许逆向扫描。受此影响，优化器可能在某些 SQL 语句中使用逆向索引扫描，因此访问方案可能会更改，并且查询执行时间可能会缩短。此功能还会改进索引维护。
在以前的 DB2 版本中，某些 DB2 用户创建一个正向扫描索引和一个逆向扫描索引以提高应用程序的速度。但是，缺点是要维护两个索引。既然在 DB2 9.1 中缺省启用了逆向扫描，那么上述两个索引就可由启用了逆向扫描的一个索引来代替。
注意:
如果在同一个表中创建了两个索引（一个指定 ASC，另一个指定 DESC）而未在 CREATE INDEX 语句中指定 DISALLOW REVERSE SCANS 选项，则这两个索引将缺省为 ALLOW REVERSE SCANS。在此情况下，将不会创建这两个索引中的第二个索引，同时 DB2 会发出索引重复的警告消息。

千问 · 2014-3-10 14:09:19

当然你也可以在创建索引的时候指定DISALLOW REVERSE SCANS，这样在V9中你也可以分别使用一个升序一个降序索引

千问 · 2014-3-10 14:09:19

当然你也可以在创建索引的时候指定DISALLOW REVERSE SCANS，这样在V9中你也可以分别使用一个升序一个降序索引，是做不到的，一个列上不能创建两个索引

千问 · 2014-3-10 14:09:19

这个讨论相当好，呵呵

千问 · 2014-3-10 14:09:19

呵呵，看起来ibm果然将allow reverse scan作为默认了，到也免了俺去苦苦寻找答案的说……
但是对于table partition中的index大家有什么见解？当用户进行rollout的时候(DETACH)，操作可以在很短的时间内进行，个人感觉对于index的维护将在AIC阶段完成。这个时候，如果用户对基表进行检索，其index不是与磁盘数据不能完全吻合么？而新生成的表是否还有对相同列的索引？索引名城又是什么呢？

千问 · 2014-3-10 14:09:19

table partition 的index问题，Infocenter中并未过多的提及. 我觉得，detach的时候，和data partition 相关的RIDs会变成invalid,而Index scans 会忽略invalid RIDs，在AIC的阶段统一除去