"工作集"：缓存单位放大让聚簇索引选择影响缓存效率

数据库不需要把全部数据都塞进内存才能获得最佳性能，只需要把”工作集” 放进内存就够了——工作集是指完成当前工作实际会被用到的那部分数据， 就像办公桌只需要放当下要用的文件，其余的留在抽屉（磁盘）里即可。工作 集占总数据量的比例因应用而异，可能是1%也可能接近100%；更实用的 定义方式是按时间窗口来算百分比（比如”过去一小时访问过的页面占多 大比例”），因为窗口拉长后工作集通常会变大——一小时内只用到1%的数据， 拉到24小时可能就涉及20%的数据。判断工作集是否完全放进了内存，不能 只看I/O访问这类外部资源指标，因为一次磁盘I/O读入的页面之后可能会被 在内存里重复访问几百万次，从I/O层面完全看不出这种复用，必须从应用 内部对逻辑访问的实际统计入手。这个概念还牵出一个容易被忽视的放大 效应：缓存是按”缓存单位”（存储引擎的最小读写粒度，如InnoDB默认16KB 的页）为单位进行的，不是按行。随机访问一行100字节的数据，InnoDB要把 它所在的整个16KB页都读进缓冲池，索引树上被访问到的部分也要按16KB 的索引页缓存，一次访问一行小数据实际占用的缓存空间可能达到32KB甚至 更多——这意味着即使单行数据很小，工作集在缓存里占用的实际空间也会 被按页放大。这正是InnoDB聚簇索引（见 [[InnoDB聚簇索引让二级索引必须携带主键因此主键要尽量小]]）的选择要 格外讲究的另一层原因：聚簇索引把物理上相关的行存在同一页里，能让一次 页面读取覆盖到更多真正会被一起访问的数据，从而让缓存空间更集中地 装下工作集，而不是被无关数据的”顺带读入”浪费掉。