MySQL表加密是鸡肋吗？
MySql社区版从5.7.11开始支持基于表的数据加密方案，模块名为keyring_file，支持加密整张表。这种是加密方式其实是基于文件加密的，一旦mysqld读取key启动后，将会解密整张表的数据，在mysql服务内，读取的数据都是解密后的，也就是说对客户端而言是无感知的。而这个key是本地存放的，mysql服务拥有读写这个key的权限。
针对已有的项目面对客户的安全审查需求，要对mysql进行表加密吗？
表加密影响性能吗？
对主从复制有没有影响？加密后对业务系统有影响吗？
对备份恢复有没有性能影像？
大数据量情况下，加密解密耗时吗？
加密后会增加存储空间占用吗？
数据库的有些特性通常都是双刃剑，有利也有弊，当然要测试过才知道。
以客户现场业务数据库数据量为基准，做如下测试：
1：增删改查加密前和加密后的性能对比
2：主从复制加密后系统主流程功能验证
3：加密前和加密后备份恢复时间对比
4：加密，解密耗时测试
5：加密前加密后占用存储空间对比
整个测试流程如下：
1.把现场数据拷回来，再进行还原到两台相同配置的服务器（8核16G内存），一台服务器所有表未加密，一台服务器所有表都加密；
2. 把现场业务系统的主要工作流的sql拿来，使用jmeter做并发性能测试对比；
3.设置主从，测试加密情况下，主从同步是否正常，同步是否及时；
考虑理论上应该没什么大问题，这里只简单的通过导入一个大批量插入数据的sql，来测试是否及时同步到从库。
4.在对第二台服务器中的所有业务数据表进行加密时，顺便记录加密耗时，以及加密后的空间占用计算空间增长，以及解密耗时；
5.分别测试加密和没有加密情况下的备份恢复时间。
经过两天的测试，基本结论如下：
1：表加密后业务系统的增删改查操作没有出现明显的性能降低
2：备份恢复的性能也没有明显的影响；
3：不影响主从复制，主从同步的及时性方面基本不受影响，没有出现明显的延迟；
4：空间增长方面，加密后反倒占用空间变小了；但是加密解密需较多的存储空间
由于数据库中设置了innodb_file_per_table=1,每个表独占一个表空间，分别单独加密。很明显的看到加密后的文件反倒比加密前变小了，估计是加密过程中去掉了文件中的碎片？
但是加密过程中需要有和原表文件大小差不多的空闲空间，否则加密会失败，解密也是一样。
因为mysql表加密采用AES加密算法，实际上源文件不变，Mysql会新生成一个临时文件，把原表文件的数据，不断读取写入到新文件，直到加密完成，再删除原文件，把加密后的文件替换到原文件。解密也是一样。
如果是单用户串行操作完成整个数据库的加密，可以简单的估算，加密解密额外需要的表空间大小为：需要加密的数据库中单个表文件占用空间最大的表，所占用的空间。
例如一个300G的数据库中，最大的表占用70G，如果是串行加密所有的表，整个加密所需要的额外的磁盘空间为70G。解密也是同样如此。
如果是多个会话并行执行加密操作，需要的空间就是各自需要加密的表中最大的表空间占用大小之和。
5：加密，解密非常耗时，在生产环境不可接受
如果上面说的空间占用情况还可以接受，可耗时问题就让人觉得mysql的加密非常鸡肋了。
测试下来，一个亿不到的业务量的情况下 整个系统的所有表加密完成时间需要整整一个晚上才行。
测试数据如下：测试环境，8G内存，4核CPU
| 表（行数） | 加密耗时 | 解密耗时 |
| 业务表1，字段不多（369928） | 24秒 |
3分56秒 |
| 业务表2，含有较多大文本字段（460436) | 4分35秒 | 25分34秒 |
| 业务表3(135185) | 8秒 |
11秒 |
| 业务表4,结构同表3，行数变多(21874128) | 15分56秒 |
13分48秒 |
| 业务表4(39948892) | 15分56秒 |
13分48秒 |
| 业务表5(95117965） | 1小时3分16秒 |
31分49秒 |
| 业务表6(2880473)） | 8分5秒 |
4分12秒 |
| 业务表7(95123072) | 2小时48分46秒 |
1小时40分 |
| 业务表8(490925) | 59秒 |
1分57秒 |
| 业务表9(411934) | 34秒 |
1分4秒 |
| 业务表10(95117965) | 6小时30分 |
超过6小时未完成 |
同样是9千多万的数据量，业务表10比表5字段少很多，只是多了一个varchar（500）类型的字段，存储文件的磁盘完整路径的。然而加密耗时却多了几倍。
6：在不停止业务系统的情况下，加密加密不会阻塞数据查询操作，但是会阻塞增删改操作。
根据执行时间直到加密解密操作完成才执行额外发起的增删改操作，成功或者超时，而对业务系统来说，多半都是会超时失败。
总结：
mysql的 加密解密虽然不需要停机操作，但是会阻塞对数据库的增删改操作。要想快速完成加密解密操作，最好是先停止业务系统读写数据库，再执行。
然而，加密解密的耗时决定了停机肯定会超出用户的能接受的停机时间！
再来看安全性方面，虽然数据库文件是加密的，但是只要能有mysql服务的账户，访问数据都是自动解密的，加密的意义又在哪里呢？而对于加密key来说，熟悉mysql加密原理的，完全可以把key一定带走。可以预见，社区版的加密的安全性方面只不过是掩耳盗铃罢了！
不知道大家的项目中是否也有数据库加密的需求呢？是否有别的更好的方式，在不购买企业版的情况下？