网站建设存在的问题有哪些,wordpress自定义404,wordpress防下载,个人建设网站程序DB2中合理使用 INCLUDE 关键字创建索引 1. 为何还需要 INCLUDE#xff1f;——从索引的两大痛点说起
查询想“只读索引不回表”#xff0c;却又不想把列都做键 → 联合索引空间膨胀#xff0c;更新放大。唯一索引定位快#xff0c;但只能返回键列数据 → 仍需 I/O 跳回数据…DB2中合理使用 INCLUDE 关键字创建索引 1. 为何还需要 INCLUDE——从索引的两大痛点说起
查询想“只读索引不回表”却又不想把列都做键 → 联合索引空间膨胀更新放大。唯一索引定位快但只能返回键列数据 → 仍需 I/O 跳回数据页。
INCLUDE 的意义就在于在保持唯一键简洁的同时再带几列数据放进索引叶子页让查询可以“即取即用”而不访问表。 2. 三个核心概念先厘清
名称作用关键特征唯一索引 (UNIQUE)保证列组合全球唯一键列全部参与排序与唯一性联合索引多列都做键列越多索引页越大写放大越高INCLUDE 列将非键列复制到叶子页不排序、不唯一但可被查询直接读取 一句话INCLUDE “唯一索引 列副本”便于 Index-Only Scan。 3. INCLUDE 的语法限制与能力边界 只有唯一索引能用并且一次可以带多个列。 维度Db2 限制说明可用索引类型仅 CREATE UNIQUE INDEX在非唯一索引上无法使用可含列数受“索引总列数”上限64–128 列键列 INCLUDE 列合计列参与排序否仍只对键列排序唯一性检查仅检查键列INCLUDE 列不参与
多列示例
CREATE UNIQUE INDEX idx_order_pkON orders(order_id) -- 唯一键INCLUDE (customer_id, order_date, amount); -- 三个附加列4. 典型实战主键范围查询 覆盖字段
SELECT cust_name
FROM temp.customer
WHERE cust_num BETWEEN 0007000000 AND 0007200000;高选择度主键cust_num额外读取字段cust_name
索引Timerons存储UNIQUE(cust_num) INCLUDE(cust_name)12 338.7小联合索引 (cust_num, cust_name)12 363.1大 洞察两者返回速度几乎相同但 INCLUDE 版更轻、更易维护因为 cust_name 不参与排序。 5. 何时用 / 何时不用 INCLUDE ——决策表
场景建议WHERE 已含唯一键且只取 1–3 个小字段用 INCLUDE字段更新频率高或体积大 (BLOB/CLOB)避免 INCLUDE需要按附加列排序 / 分组建联合索引并把排序列放首位非唯一索引场景无法用 INCLUDE只能联合索引 6. 创建示例与常见坑位
CREATE UNIQUE INDEX idx_customer_pkON temp.customer (cust_num) -- 键列INCLUDE (cust_name, created_at) -- 多列PCTFREE 10; -- 预留空间易踩坑
把大字段放进 INCLUDE ⇒ 索引页变“胖”I/O 暴涨。把更新频繁字段放进 INCLUDE ⇒ 每次 UPDATE 都写索引页。忘记唯一限制 ⇒ 编译报错INCLUDE clause is not allowed for non-unique index。 7. 与排序、覆盖访问、优化器的协同
覆盖访问只要 SELECT 的列完全落在 键列 INCLUDE 列 中优化器偏向 INDEX ONLY SCAN。ORDER BY 键列直接输出无需再排序INCLUDE 不帮你排别的列。统计信息叶子页更大 → RUNSTATS 仍要跑确保基数估计准确。 8. 落地 Checklist
锁定高选择度唯一列列清单梳理读多写少 体积小 → 入 INCLUDE建索引UNIQUE ... INCLUDE(...)EXPLAIN 确认出现 INDEX ONLY 即达成目的监控写入高并发 UPDATE 时观察页分裂、锁竞争定期 RUNSTATS保证优化器基数估算不失真 9. 小结
INCLUDE 为唯一索引添上一层“只读副本”
性能Index-Only省一次回表 I/O空间比联合索引小得多维护附加列不排序写放大低 口诀 唯一键 少量、静态、小字段 ⇒ 用 INCLUDE需要排序 / 大字段 / 高频更新 ⇒ 建联合索引 或 保留原表 定位好场景、避开陷阱INCLUDE 就能帮你把“空间-时间比”榨到极致。
