SM4存储加密是针对表级别还是列级别？启用后，对已有的数据和后续的查询性能有何影响？

SM4存储加密既支持表级别，也支持列级别。启用后，对已有数据和后续查询性能均有明确影响，主要体现在数据迁移开销和持续的加解密CPU开销上。

一、加密粒度：表级与列级

GBase 8a 的存储加密功能支持两种粒度的加密：

1. 表级加密：对整个表的所有列进行加密。
   • 语法：CREATE TABLE t1 (a int, b varchar(10)) **ENCRYPT**;
2. 列级加密：只对表中指定的敏感列进行加密。
   • 语法：CREATE TABLE t2 (a int, b varchar(10) **ENCRYPT**, c date);

关键特性：

• 加密属性不可变更：一旦表或列被定义为 ENCRYPT，不支持通过 ALTER TABLE 来增加、删除或修改加密属性。

   

• 加密算法选择：通过 _gbase_encrypt_new_mode 参数在 AES（默认值1） 和 国密SM4（值2） 之间选择。一旦有加密数据后，算法不可切换。

• “数据加密功能：1. 支持表级或者列级不同粒度的加密要求；”

   

二、对已有数据的影响：需要迁移与重加密

如果对已存在非加密数据的表启用加密，其影响是一次性的、但可能很重的操作负担。

1. 操作流程：必须创建一个新的、带 ENCRYPT 属性的表，然后将旧表的数据导入（INSERT ... SELECT） 到新表中。系统在数据入库过程中会自动加密。

2. 性能影响：

   • 时间与I/O开销：整个过程涉及全表数据的读取、加密计算、写入，对于大表会非常耗时，并产生显著的磁盘I/O和CPU消耗。
   • 业务中断：在迁移期间，原表可能被锁定（取决于操作方式），影响业务访问。

   “不支持alter表加密属性。” 这意味着无法原地启用加密，必须通过数据迁移实现。

    

三、对后续查询性能的影响：带来可控的CPU开销

加密表在后续的读写操作中，会引入持续的加解密计算开销。

1. 写入（INSERT/UPDATE/LOAD）路径：
   • 数据 -> 压缩 -> **加密** -> 存储
   • 数据在落盘前，会先压缩，再进行加密。
2. 读取（SELECT）路径：
   • 存储 -> **解密** -> 解压缩 -> 数据
   • 数据从磁盘读出后，需先解密，再解压缩，才能被处理。
3. 性能影响评估：

   • 主要开销：加解密是CPU密集型操作。文档指出，GBase 8a的透明加密设计目标是 “加解密负载对整体性能影响小于5%”。

      

   • 影响程度因素：
     • 加密列的数量：全表加密比仅加密个别列的开销大。
     • 查询类型：如果查询只涉及非加密列，则完全无加解密开销。若需扫描加密列，则会产生开销。
     • 硬件性能：支持AES-NI等指令集的CPU能极大加速加解密过程。
4. 功能限制：
   • 不支持DBLINK：加密表不能用于DBLINK操作，这会影响跨集群的数据访问。
   • 事务模式限制：如果使用密文密钥（需要口令），则不能在事务模式下操作加密表。
   • “加密表上不支持dblink操作。” “事务模式下不能使用密文密钥，密文密钥模式下也不能开启事务。”

四、密钥管理对操作的影响

加密功能的使用体验还取决于密钥类型：

五、总结与建议

结论：SM4存储加密是一项强大的数据静态保护功能，但其启用并非零成本。DBA应在数据安全需求与性能开销、功能限制之间做出权衡，通常建议采用列级加密和明文密钥以平衡安全性与运维复杂性，并对加密表的查询性能进行持续监控。