带你随便看看DB2那些索引到底是怎么回事，别太正式哈

IBM官方文档、数据库论坛技术贴、DBA经验分享）

咱今天就唠唠DB2里那个天天见又有点神秘的玩意儿——索引，这玩意儿说白了就跟书本的目录一模一样，你想想，一本厚厚的《红楼梦》，要是没前面那个目录，你想找“林黛玉葬花”在哪一回，不得从第一页开始翻到吐血？数据库也是这道理，没索引的话，DB2找数据就得玩“全书扫描”（Full Table Scan）,那速度可快不了。

索引到底是个啥结构？

别被B+树这种词吓到，你就想象成一棵倒着长的树，最上面是树根（根页），中间是树枝（非叶子节点），最底下是树叶（叶子节点），叶子节点最实在，里面一行行地存着索引键的值（比如你按身份证号建索引，这里就存着一堆身份证号）和指向真实数据行的“门牌号”（ROWID），当你查某个身份证号时，DB2就从树根开始，像查通讯录一样快速定位到具体的叶子页，找到那个“门牌号”，然后直接去把数据拎出来,省得它满世界乱翻。

（来源：数据库原理教材的通俗化解读）

DB2里有几种常见的索引？

1. 唯一索引：最较真的一种，它要求索引列的值必须全厂唯一，不能有重复，比如你给员工工号建唯一索引，要是HR手抖输了两条一样的工号，DB2当场就给你弹窗报错，杜绝“双胞胎”，这玩意儿除了快,还管着数据质量。
2. 非唯一索引：这就随和多了，允许列值重复，比如你按部门代号建索引，那“研发部”可能对应几百号人，索引里就能出现一堆相同的部门代号，它主要负责提速,不管数据是否重复。
3. 集群索引：这个有点意思，它不光管索引本身，还影响数据在磁盘上的物理存放顺序，如果你按入职时间建了集群索引，那么相邻工号的员工数据，在硬盘上大概率也是挨着存的，这对于范围查询（比如查2022年全年入职的人）特别友好，因为硬盘读写头不用来回跳，顺序读盘快得多，但注意，一个表只能有一个集群索引,选哪个字段得好好琢磨。
4. 包含性索引：好比你去图书馆，不光目录告诉你书在哪个区（索引键），顺便还把第一章的摘要（包含列）也印在目录上了，这样，如果你只想看摘要（即查询只涉及索引键和包含列），管理员（DB2）直接在目录区就能满足你，连书架都不用跑（无需访问数据页），这招对于那种经常只查几个字段的场景,提速效果拔群。

（来源：DB2 LUW官方管理指南）

建索引不是越多越好

这是个经典误区，很多人觉得索引能提速，那就给每个字段都建一个呗？快打住！索引就像菜刀，用好了是神器，乱用会伤手，每个索引都是一份需要维护的“小抄”，当你增删改数据时，DB2不但要动真实数据，还得去更新所有相关的索引，索引一多，写操作就变成了“磨洋工”，慢得让你怀疑人生，而且索引也占磁盘空间啊，基本原则是：读远多于写的表，适合多建索引；频繁写的表，索引要精简，通常先紧着最常用、最影响性能的查询条件来建。

怎么知道索引用没用好？

DB2有个神器叫“解释工具”（Explain），它能给你生成一份“查询执行计划报告”，你就能看到DB2到底有没有乖乖走你建的索引，还是它偷懒选择了全表扫描，如果发现该走没走，可能得想想是不是索引建得不对，或者表统计信息过时了（DB2靠统计信息来判断走哪个索引快，你得定期运行RUNSTATS命令更新信息，不然DB2就跟用了过期地图一样会迷路）。

（来源：DBA实战经验总结）

最后扯点实际的

日常开发中，别闭着眼SELECT *，只查需要的列，这样更容易让包含性索引发挥作用，避免在索引列上用函数或者计算，比如WHERE UPPER(name) = 'ZHANGSAN'，这种操作通常会让索引失效，DB2又得去全表扫描了，联表查询时,尽量在连接条件上用上索引。

索引就是个“空间换时间”的买卖，也是个体力活加技术活，用得对，查询速度坐上火箭；用错了，系统慢得像蜗牛,希望这点大白话能帮你把DB2的索引看得更透一点。