问题是这样的:
有一数据库,里面有很多表,也有很多已存在的数据,这些数据多数都是用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又可能会导致接下来的查询出错。
求助有没有好的办法能只针对这一个表进行以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又可能会导致接下来的查询出错。
求助有没有好的办法能只针对这一个表进行以utf8mb4为编码的操作,并且还不影响其他表的操作。
PS:因为生产环境已经上线一年了已有很多数据和在线用户,而现在测试才报出来有这个问题。数据库整体更新编码实在风险太大,领导的意思是哪有坑先填哪,没发现的坑就假装没看见。
幸运的是生产环境当时搭建系统时是我安装的,mysql一开始就是当时的最新版5.6.26。emoji再转码的方法希望只作为最后的解决办法。