MySQL InnoDB中加密邮箱字段应选用何种数据类型与长度？

好问题！咱们一步步拆解你的方案，确认它是否靠谱：

核心计算逻辑的正确性 #

你对AES加密后长度的计算是完全正确的：

• AES是块加密算法，固定块大小为16字节，当明文长度不是16的整数倍时，会自动使用PKCS#7填充（MySQL的AES_ENCRYPT()默认采用这种填充方式）。
• 加密后的长度公式确实是 16 × (FLOOR(明文字节数 / 16) + 1)。
• 针对你设定的最大32字节的邮箱明文，计算得 16 × (32/16 + 1) = 48 字节，这个结果准确无误。

VARBINARY(60)方案的可行性 #

你的选择完全可行，理由如下：

1. 足够容纳加密结果：48字节的加密后数据远小于60字节的存储上限，不会出现截断问题。
2. 预留了安全余量：额外的12字节可以应对一些特殊情况，比如：
   • 偶尔出现的邮箱长度轻微超出32字节（只要明文不超过47字节，加密后仍为48字节，不会触及60的上限）；
   • 避免因字符集误解导致的字节数偏差（比如如果原邮箱是多字节字符集，但实际使用中字符的字节数未超过预期）。
3. 数据类型选择合理：VARBINARY是存储二进制加密数据的最优选择之一，它属于行内存储，比BLOB更高效，同时避免了字符集转换可能带来的乱码或长度变化问题。

额外注意事项 #

• 字符集的影响：如果你的邮箱字段使用的是多字节字符集（比如utf8mb4），VARCHAR(32)指的是32个字符，对应的字节数可能超过32（比如每个字符占4字节时，32字符就是128字节）。这种情况下加密后的长度会变成 16 × (128/16 +1) = 144 字节，此时VARBINARY(60)就不够用了。请确认你的邮箱字段实际的字节数上限，确保加密后长度不超过存储类型的上限。
• 未来扩展性：如果以后可能需要扩展邮箱的长度上限，建议直接选择更大的VARBINARY长度（比如VARBINARY(255)），这样无需修改表结构就能兼容更长的邮箱加密需求。

总的来说，你的方案在当前设定的场景下是安全且合理的，可以放心使用。

内容的提问来源于stack exchange，提问作者some1 here