多维群集（Multidimensional clustering ，MDC）
MDC 提供了数据在多个维上的灵活的、连续的和自动的多维群集。它提升了查询的性能，并且减少了在插入、更新和删除期间对 REORG 和索引维护的需要。
多维群集从物理上把表数据同时沿着多个维群集起来，这与使用表上的多个独立的群集的索引类似。MDC 通常用于帮助提高对大型表的复杂查询的性能。这里不需要使用 REORG 来重新群集索引，因为 MDC 会自动地、动态地维护每个维上的群集。
对于一个 MDC，最合适的是那些具有范围、相等和连接谓词的访问多行的查询。千万不要使用具有惟一性的列作为一个维，因为这样会导致一个表不必要地变大。如果具有每种维值组合（即单元）的行不是很多，应避免使用太多的维。为获得非常好的的性能，那么至少需要有足够的行来填满每个单元的块，也就是该表所在表空间的区段大小。
- Concepts ==> Administration ==> Database design ==> Logical ==> Multidimensional clustering (MDC)
- Concepts ==> Administration ==> Database objects ==> Tables ==> Multidimensional clustering (MDC) tables
MQT 可用于提升使用 GROUP BY、GROUPING、RANK 或 ROLLUP OLAP 函数的查询的性能。MQT 的使用对用户来说是透明的，DB2 选择何时使用 MQT 来达到优化的目的。DB2 使用 MQT 在内部维护被查询的分组的总结结果，这样用户就可以直接访问 DB2 维护的分组，而不必去读动辄数 GB 的数据来寻找答案。这些 MQT 还可以在分区间复制，以避免这种信息在分区间的散播，从而帮助提升合并连接（collocated jion）的性能。
对于 30 字节或更少字节的列，应避免使用 VARCHAR 数据类型，因为这种情况下，VARCHAR 类型通常会浪费空间，所以建议使用 CHAR 类型。如果数据量很大，那么空间的浪费往往会对查询时间造成影响。
当使用 IDENTITY或 SEQUENCE时，应至少使用缺省的大小为 20 的缓存（除非编号中的间隔很有干系）。这样一来，就不必在每次需要的时候请求 DBM 生成一个数字，同时也避免了在生成数字时要做的日志记录。
当一个表使用很多空值和系统缺省值时， VALUE COMPRESSION和 COMPRESS SYSTEM DEFAULT可以节省磁盘空间。系统缺省值是指在没有指定特定的值时，为某个数据类型而使用的缺省值。如果量很大，这样还可以帮助缩短查询时间。如果插入或者更新一个值，压缩的列只会招致很少的开销。
对于有大量插入操作的表，使用 APPEND ON以避免在插入过程中搜索空闲空间，而只需将行附加在表的最后。如果要依赖于处于某种特殊顺序中的表，并且无法承受执行 REORG 的开销，那么应避免使用 APPEND ON。
对于只读的表或者独占访问的表，将 LOCKSIZE设置为 TABLE。这样就避免了为行加锁时所费的时间，并且减少了所需的 LOCKLIST 数量。
使用 PCTFREE来维护空闲空间，以助将来的 INSERT、LOAD 和 REORG 一臂之力。PCTFREE 的缺省值是 10；对于具有群集索引和插入量很大的表，可以尝试使用 20-35。如果使用 APPEND ON，则将 PCTFREE 设置为 0。
使用 VOLATILE来鼓励索引扫描。易变（volatile）表明表的基数可以在很大的范围内显著变化，从一个很大的数一直到空。这样就促使优化器不管表的统计数字如何，都使用索引扫描，而不是使用表扫描。不过，只有在索引包含所有被引用的列，或者索引可以在索引扫描时应用谓词的情况下，上述情况才会出现。
使用 NOT LOGGED INITIALLY将事务执行期间（也就是直到 COMMIT）的日志记录关闭掉。
VALUE COMPRESSION和 COMPRESS SYSTEM DEFAULT还可以用在 altER TABLE 命令中。
- Reference ==> SQL ==> SQL Statements ==> CREATE TABLE
- Reference ==> SQL ==> SQL Statements ==> altER TABLE
由于有了 Design Advisor，设计索引的负担已经消除。Design Advisor 用于为特定的 SQL 工作负载（即一组 SQL 语句）推荐和评估索引， 很快我们就将讨论这个工具。
下面仍然是一些您应该知道的跟索引有关的问题：
- 当要在一个合理的时间内结束查询时，应避免添加索引，因为索引会降慢更新操作的速度并消耗额外的空间。有时候还可能存在覆盖好几个查询的大型索引。
- 基数较大的列很适合用来做索引。
- 考虑到管理上的开销，应避免在索引中使用多于 5 个的列。
- 对于多列索引，将查询中引用最多的列放在定义的前面。
- 避免添加与已有的索引相似的索引。因为这样会给优化器带来更多的工作，并且会降慢更新操作的速度。相反，我们应该修改已有的索引，使其包含附加的列。例如，假设在一个表的 (c1,c2) 上有一个索引 i1。您注意到查询中使用了 "where c2=?"，于是又创建一个 (c2) 上的索引 i2。但是这个相似的索引没有添加任何东西，它只是 i1 的冗余，而现在反而成了额外的开销。
- 如果表是只读的，并且包含很多的行，那么可以尝试定义一个索引，通过 CREATE INDEX 中的 INCLUDE 子句使该索引包含查询中引用的所有列（被 INCLUDE 子句包含的列并不是索引的一部分，而只是作为索引页的一部分来存储，以避免附加的数据 FETCHES）。
我们可以创建群集索引来为表中的行排序，并且是按照所需结果集的物理顺序来排序。群集索引可以用 CREATE INDEX 语句的 CLUSTER 选项来创建。为获得非常好的性能，应该在那些小型的数据类型（比如整型和 char(10)）、具有惟一性的列以及在范围搜索中经常要用到的列上创建索引。
群集索引允许对数据页采用更线性的访问模式，允许更有效的预取，并且有助于避免排序。这意味着插入操作要花更多的时间，但是查询操作会更快。当使用群集索引时，应考虑将数据页和索引页上的空闲空间增加到大约 15-35（而不是 PCTFREE 的缺省值 10），以允许大容量的插入。对于会受到大量插入操作的表，考虑使用单维的 MDC 表（或许是使用像 idcolumn/1000 或 INT(date)/100 这样的生成列）。这将导致对数据（在维上）的块索引，而不是按行索引。这样产生的索引会更小一些，并且在插入期间的日志内容也大大减少。
对于只读表上的索引，使 PCTFREE为 0，对于其他索引使 PCTFREE 为 10，以提供可用的空间，从而加快插入操作的速度。此外 ，对于有群集索引的表，这个值应该更大一些，以确保群集索引不会被分成太多的碎片。如果存在大量的插入操作，那么使用 15 ' 35 之间的值或许更合适一些。
使用 ALLOW REVERSE SCANS以便可以对一个索引进行双向（bi-directionally）扫描，也就是说，可以对按升序排列的结果集和按降序排列的结果集进行更快速的检索。这样做还没有负面的性能影响，因为在为这个特性提供支持的过程中，并没有在内部改变索引的结构。
可以使用 INCLUDE将其他没有被索引的列包括到索引页中来，以促进纯索引访问，并避免了从数据页取数据。
可以使用 UNIQUE 列来有效地实施一个列或一组列的惟一性。
TYPE-2 INDEXES可以大大减少 next-key 锁，允许索引列大于缺省的 255 字节，允许在线 REORG 和 RUNSTATS，并且支持新的多维群集功能。在 v8 中，所有新的索引都是以 type-2 类型创建的，只有已经在表上定义了（迁移前） type-1 索引的时候才是例外。可以使用 REORG INDEXES 将 type-1 索引转换为 type-2 索引。
- Concepts ==> Administration ==> Performance tuning ==> Operational performance ==> Table and index management ==> Index planning
- Concepts ==> Administration ==> Performance tuning ==> Operational performance ==> Table and index management ==> Performance tips for indexes
- Reference ==> SQL ==> SQL Statements ==> CREATE INDEX
