4同行回答
1.DB2 V9.5及以下版本：
db2pd -d DBName -tcb index[all]，在“TCB Index Stats”信息块中，请关注以下两列：Scans、IxOnlyScns。
如果索引没有出现在“TCB Index Stats”中、或其中的Scans值及IxOnlyScns值相对同一表的其他索引的这两个值来说，要小很多，则一般可以认为很少使用的，可以考虑删除。
（注意：由于db2pd是直接读取内存的，其数据是数据库最后一次启动以来的积累，如果数据库启动的时间范围覆盖了所有或大多业务周期是最好的，即该跑的SQL基本跑过了，才更有多参考价值；
数据Active了多久，可以从刚才的输出的前面部分可以看到类似：Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:14:20 -- Date 2015-07-09-19.21.27.429000的情况）
2.DB2 V9.7及以上版本：
查看系统索引视图：syscat.indexes.LASTUSED，表示索引最后一次使用的日期；如果其值在对应表的业务周期（如月类型、年类型、周类型）以前的，则证明索引在最近的业务周期内使用不上了
对于syscat.indexes.LASTUSED，还可以考虑以下两点：
2.1 syscat.indexes.LASTUSED='0001-01-01'，表示索引在创建以后重来没有使用过；结合索引创建时间（syscat.indexes.CREATE_TIME）比较久了,则很有可能是无用索引，否则就要结合业务周期来考虑了。
2.2 syscat.indexes.LASTUSED<>'0001-01-01'，则还要结合上述db2pd，因为最近使用过并不代表是经常使用的。
3.考虑索引与表的聚集度，查询系统视图：SYSCAT.INDEXES.CLUSTERRATIO或对比SYSCAT.INDEXES.FULLKEYCARD与syscat.tables.card的比值，如果比值很小，说明索引行与表数据行的聚集度比较差，
在有UDI操作的表请注意考虑清理此索引。
根据版本不同的，结合教参以上两点，但还有一个很重要的前提，索引的统计信息是已经及时更新的了。
另外，在清理不用、不常用的索引时，请注意索引类型为P（主健）、U（唯一）一定要小心，当初建此类型索引时可能是基于业务约束。收起
db2pd -d DBName -tcb index[all]，在“TCB Index Stats”信息块中，请关注以下两列：Scans、IxOnlyScns。
如果索引没有出现在“TCB Index Stats”中、或其中的Scans值及IxOnlyScns值相对同一表的其他索引的这两个值来说，要小很多，则一般可以认为很少使用的，可以考虑删除。
（注意：由于db2pd是直接读取内存的，其数据是数据库最后一次启动以来的积累，如果数据库启动的时间范围覆盖了所有或大多业务周期是最好的，即该跑的SQL基本跑过了，才更有多参考价值；
数据Active了多久，可以从刚才的输出的前面部分可以看到类似：Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:14:20 -- Date 2015-07-09-19.21.27.429000的情况）
2.DB2 V9.7及以上版本：
查看系统索引视图：syscat.indexes.LASTUSED，表示索引最后一次使用的日期；如果其值在对应表的业务周期（如月类型、年类型、周类型）以前的，则证明索引在最近的业务周期内使用不上了
对于syscat.indexes.LASTUSED，还可以考虑以下两点：
2.1 syscat.indexes.LASTUSED='0001-01-01'，表示索引在创建以后重来没有使用过；结合索引创建时间（syscat.indexes.CREATE_TIME）比较久了,则很有可能是无用索引，否则就要结合业务周期来考虑了。
2.2 syscat.indexes.LASTUSED<>'0001-01-01'，则还要结合上述db2pd，因为最近使用过并不代表是经常使用的。
3.考虑索引与表的聚集度，查询系统视图：SYSCAT.INDEXES.CLUSTERRATIO或对比SYSCAT.INDEXES.FULLKEYCARD与syscat.tables.card的比值，如果比值很小，说明索引行与表数据行的聚集度比较差，
在有UDI操作的表请注意考虑清理此索引。
根据版本不同的，结合教参以上两点，但还有一个很重要的前提，索引的统计信息是已经及时更新的了。
另外，在清理不用、不常用的索引时，请注意索引类型为P（主健）、U（唯一）一定要小心，当初建此类型索引时可能是基于业务约束。收起
我自己的经验是这样的，我会对每个表进行分析是否存在重复索引（唯一索引、主键除外）可参考http://www.db2china.net//home/sp ... 10&do=blog&id=34997[/url]，然后我会自己弄一套编目表保存数据库的每个表和索引的TCB基准信息（9.7版本之前）及重复索引信息，然后我会对比表中被标识"重复"的索引中，使用率如何，再分析表中TCB的UID如何，如果表被更新的数字很大，而该被标识"重复"的索引使用次数很少，我会建议进行删除。另外的是，如果在reorgchk中，索引的F4-F8都被标识*，我会建议先进行重组。收起
浏览548