DB2 的部分加密并不是通过一个参数独立完成的，它需要原生加密体系、keystore 和目标表空间共同配合。opt_enable_partial_encryption 这一参数通常以注册表变量 DB2_OPT_ENABLE_PARTIAL_ENCRYPTION 表示，主要作用是让优化器和存储引擎在同一个 SQL 执行期间正确处理加密与非加密数据页的混合访问。开启之前，实例即使已经存在加密表空间，某些跨加密表和普通表的连接、排序或子查询操作也可能受到限制，或者优化器会采取更保守的执行策略。
一、部分加密的底层机制与前提条件
DB2 原生加密落在表空间级别时，每个加密表空间会通过 master key 派生出的 data encryption key 对数据页进行加密。写入时，缓冲池中的脏页在刷新到磁盘前完成加密；读取时，已加密页被读入内存后解密成普通数据页。这个过程对 SQL 应用透明，但 CPU 开销并不可忽略。启用 DB2_OPT_ENABLE_PARTIAL_ENCRYPTION 后，DB2 不再假设数据库是统一加密或统一明文，而是能够根据表空间的加密属性动态判断哪些页需要解密、哪些页可以直接读取。
需要特别注意的是，该参数并不负责生成密钥，也不会自动把某张表标记为敏感表。实际环境中，必须先完成 keystore 配置，并且通过 CREATE TABLESPACE ... ENCRYPT 明确指定哪些表空间需要加密。如果只设置注册表变量而没有加密表空间，实例不会产生任何加密行为，也不会有性能变化。
从配置层面看，opt_enable_partial_encryption 更像一个允许混合存储布局的开关。关闭时，DB2 仍支持全库加密或全库明文，但遇到一个查询里同时出现加密页和明文页时，可能采用临时表物化、排序溢出或更保守的访问路径；开启后，优化器可以把两类页的读取都纳入同一个成本模型，从而减少不必要的物化。
db2set DB2_OPT_ENABLE_PARTIAL_ENCRYPTION=ON db2stop force db2start
Windows 环境下，如果 db2set 不在 PATH 中，可以切换到 C:\IBM\SQLLIB\BIN 目录再执行。反斜杠路径不会影响注册表变量的生效。
二、创建加密表空间并验证混合访问
注册表变量开启后，下一步是选择需要加密的表空间。假设业务库中只有 customer_info 表存放身份证号和银行卡号，而订单表 orders 以分析查询为主，敏感性较低，就只对前者所在的表空间启用加密。
CREATE TABLESPACE sensitive_ts MANAGED BY AUTOMATIC STORAGE ENCRYPT; CREATE TABLE customer_info ( cust_id BIGINT NOT NULL, card_no VARCHAR(19), PRIMARY KEY (cust_id) ) IN sensitive_ts; CREATE TABLE orders ( order_id BIGINT NOT NULL, cust_id BIGINT NOT NULL, region VARCHAR(20), PRIMARY KEY (order_id) ) IN user_ts;
上面的 sensitive_ts 被显式标记为 ENCRYPT，而 user_ts 保持明文。接下来执行一条跨加密表空间与明文表空间的连接查询，验证部分加密参数是否真正影响执行路径。
SELECT c.cust_id, c.card_no, o.region FROM customer_info c JOIN orders o ON c.cust_id = o.cust_id WHERE o.region = 'EAST';
如果参数未开启，优化器可能先把 orders 的筛选结果物化，再进入加密侧读取 customer_info，以避免在加密页上反复执行随机访问。开启 DB2_OPT_ENABLE_PARTIAL_ENCRYPTION 后，DB2 可以直接在连接键上计算成本，选择哈希连接或嵌套循环连接，而不必因为表空间加密属性不同就强制生成临时表。
通过表空间监控函数可以确认加密属性已经生效：
SELECT VARCHAR(TABLESPACE_NAME, 30) AS TABLESPACE_NAME,
ENCRYPTION_ALGORITHM
FROM TABLE(MON_GET_TABLESPACE('', -2)) AS t
WHERE TABLESPACE_NAME IN ('SENSITIVE_TS', 'USER_TS');
结果中 SENSITIVE_TS 会显示加密算法，USER_TS 通常为空或 NOT_ENCRYPTED，说明实例里已经同时存在两类表空间。
三、执行计划与性能观察
部分加密对性能的影响需要从执行计划入手。可以先在关闭和开启参数两种状态下分别生成访问计划，对比是否存在额外的排序、临时表物化或表空间扫描。DB2 的 db2exfmt 工具可以输出详细计划，重点关注 TBSCAN、HSJOIN 和 FETCH 等算子是否仍然存在。
db2 "EXPLAIN PLAN FOR SELECT c.cust_id, c.card_no, o.region FROM customer_info c JOIN orders o ON c.cust_id = o.cust_id WHERE o.region = 'EAST'" db2exfmt -d sample -g TIC -w -1 -o mixed_plan.txt
这里使用 -g TIC 只输出图形化计划中的表、索引和连接信息，便于快速定位物化节点。通常情况下，开启部分加密后，计划不会出现专门为解密而生成的 TEMP 表，加密表空间的读取成本也会更加贴近明文表空间。
性能方面，部分加密并不能完全消除 CPU 开销，只要查询涉及加密页，解密操作仍然存在。但它可以把这种开销限制在真正敏感的数据范围内。例如一张 200GB 的日志表如果因为全库加密而被反复加解密，CPU 时间会明显上升；将日志表放在明文表空间后，只有访问敏感客户表时才触发解密，整体吞吐量可以提升很多。
四、备份恢复与安全管理中的注意事项
启用部分加密后，备份策略必须同步调整。DB2 备份会原样保留表空间的加密状态，加密表空间的数据在备份文件中仍然处于加密状态，恢复时需要访问同一个 keystore 或对应的主密钥。如果只备份了数据库而没有备份 keystore，一旦主密钥丢失，加密表空间的数据将无法读取。因此，keystore 文件和密码的保存与数据库备份同等重要。
权限管理上，部分加密不会改变表空间访问控制。对 customer_info 表的读取权限仍然由数据库用户、角色和权限决定。加密解决的是磁盘介质丢失后的数据泄露问题，例如服务器硬盘被盗、存储快照被复制，而不能替代行级权限或列级掩码。
另一种常见误区是认为设置了 DB2_OPT_ENABLE_PARTIAL_ENCRYPTION 后，所有新建表空间都会自动加密。实际情况并非如此，建表空间时如果省略 ENCRYPT，该表空间仍然是明文。DBA 应该在开发规范中明确哪些业务域必须使用加密表空间，并在代码评审或发布脚本中检查 ENCRYPT 关键字是否遗漏。
| 对比项 | 全库加密 | 部分加密 |
|---|---|---|
| 加密范围 | 所有表空间与系统表空间 | 仅显式声明 ENCRYPT 的表空间 |
| CPU 开销 | 所有读写都受影响 | 只影响访问加密表空间的操作 |
| 运维复杂度 | 配置简单，性能调优较难 | 需要按业务域规划表空间 |
| 适用场景 | 合规要求极高、全库都需要保护 | 敏感数据集中在少数表或列 |
还需要监控加密表空间的读写频率。如果某个加密表空间承载了大量非敏感数据，或者经常参与全表扫描，说明表空间划分可能不合理，可以考虑迁移部分表到明文表空间来降低成本。迁移可以使用 db2move 或在线表重组工具，过程中要注意目标表空间是否显式带 ENCRYPT。
db2move sample export -tn customer_info -u db2inst1 -p password db2move sample import -io insert -tn customer_info -ts sensitive_ts -u db2inst1 -p password
上述命令只是示例，实际操作前需要备份数据和权限脚本，避免覆盖已有表结构。部分加密的优势也体现在这种迁移过程中：敏感表迁移到加密表空间，普通表继续留在明文表空间，无需重建整个数据库。
总之，opt_enable_partial_encryption 的价值在于让 DB2 实例能够同时管理加密与明文表空间，并在查询优化阶段正确处理混合访问。它不会自动识别敏感数据，也不会替代 keystore、权限和审计。只有把参数配置、表空间规划和备份恢复策略放在一起考虑，才能让部分加密真正落地。
DB2部分加密opt_enable_partial_encryption数据库加密修改时间：2026-09-18 00:29:17