问题是这样的：
有一数据库，里面有很多表，也有很多已存在的数据，这些数据多数都是用utf8存储的（不全是，还有latin1的）。
遇到了用户存emoji导致存储失败的问题，已知是需要utf8mb4才能正确存储。
已经把mysql从5.1升级到5.6.26了。接下来的想法和已有的尝试：
1、如果把整个数据库都更新成uft8mb4的话，风险太大，因为各种调用的地方乱七八糟，维护不良，直接变成utf8mb4的话可能整个系统都不正常。
2、考虑只把用户会存储emoji的表（以下简称表E）更新成uft8mb4，然而这里系统用的是thinkphp写的，编码设置是放在config.php中的，修改这里的话，thinkphp就全灭了。
3、接着2考虑的话，thinkphp主体仍然用uft8不变，仅在查询这个表E的时候临时使用uft8mb4进行查询。尝试M()->query('SET NAMES \'utf8mb4\'');结果报错：SQLSTATE[HY000]: General error
4、仍然考虑2的方法发现也不行。因为即使查询了这个表E成功之后，又会进行其他表的操作，uft8mb4又可能会导致接下来的查询出错。
立即学习“PHP免费学习笔记（深入）”；
求助有没有好的办法能只针对这一个表进行以utf8mb4为编码的操作，并且还不影响其他表的操作。
PS:因为生产环境已经上线一年了已有很多数据和在线用户，而现在测试才报出来有这个问题。数据库整体更新编码实在风险太大，领导的意思是哪有坑先填哪，没发现的坑就假装没看见。
幸运的是生产环境当时搭建系统时是我安装的，mysql一开始就是当时的最新版5.6.26。emoji再转码的方法希望只作为最后的解决办法。
回复内容：
问题是这样的：
有一数据库，里面有很多表，也有很多已存在的数据，这些数据多数都是用utf8存储的（不全是，还有latin1的）。
遇到了用户存emoji导致存储失败的问题，已知是需要utf8mb4才能正确存储。
已经把mysql从5.1升级到5.6.26了。接下来的想法和已有的尝试：
1、如果把整个数据库都更新成uft8mb4的话，风险太大，因为各种调用的地方乱七八糟，维护不良，直接变成utf8mb4的话可能整个系统都不正常。
2、考虑只把用户会存储emoji的表（以下简称表E）更新成uft8mb4，然而这里系统用的是thinkphp写的，编码设置是放在config.php中的，修改这里的话，thinkphp就全灭了。
3、接着2考虑的话，thinkphp主体仍然用uft8不变，仅在查询这个表E的时候临时使用uft8mb4进行查询。尝试M()->query('SET NAMES \'utf8mb4\'');结果报错：SQLSTATE[HY000]: General error
4、仍然考虑2的方法发现也不行。因为即使查询了这个表E成功之后，又会进行其他表的操作，uft8mb4又可能会导致接下来的查询出错。
立即学习“PHP免费学习笔记（深入）”；
求助有没有好的办法能只针对这一个表进行以utf8mb4为编码的操作，并且还不影响其他表的操作。
PS:因为生产环境已经上线一年了已有很多数据和在线用户，而现在测试才报出来有这个问题。数据库整体更新编码实在风险太大，领导的意思是哪有坑先填哪，没发现的坑就假装没看见。
幸运的是生产环境当时搭建系统时是我安装的，mysql一开始就是当时的最新版5.6.26。emoji再转码的方法希望只作为最后的解决办法。
