The problem is this:
There is a database with many tables and a lot of existing data. Most of these data are stored in utf8 (not all, there are also latin1).
We encountered a problem where users failed to store emojis. It is known that utf8mb4 is required for correct storage.
Mysql has been upgraded from 5.1 to 5.6.26. Next thoughts and existing attempts:
1. If the entire database is updated to uft8mb4, the risk is too high, because the various calling places are messy and poorly maintained. If it is directly changed to utf8mb4, the entire system may not be normal.
2. Consider updating only the table where users can store emoji (hereinafter referred to as Table E) to uft8mb4. However, the system here is written in thinkphp, and the encoding settings are placed in config.php. If you modify this, thinkphp It was all destroyed.
3. If we consider 2, the main body of thinkphp still uses uft8 unchanged, and only temporarily uses uft8mb4 when querying this table E. Try M()->query('SET NAMES 'utf8mb4'');
The result is an error: SQLSTATE[HY000]: General error
4. Still considering method 2 will not work. Because even after successfully querying this table E, operations on other tables will be performed, and uft8mb4 may cause errors in the subsequent query.
Is there a good way to perform utf8mb4-encoded operations on only this table without affecting the operations of other tables?
PS: Because the production environment has been online for a year and has a lot of data and online users, this problem has only been reported in testing now. It is too risky to update the coding of the entire database. The leader's idea is to fill in the pitfalls first, and pretend not to see the pitfalls that are not discovered.
Fortunately, I installed the production environment when I built the system. MySQL was the latest version 5.6.26 at the beginning. I hope the method of re-coding emoji will only be used as a last resort solution.
The problem is this:
There is a database with many tables and a lot of existing data. Most of these data are stored in utf8 (not all, there are also latin1).
We encountered a problem where users failed to store emojis. It is known that utf8mb4 is required for correct storage.
Mysql has been upgraded from 5.1 to 5.6.26. Next thoughts and existing attempts:
1. If the entire database is updated to uft8mb4, the risk is too high, because the various calling places are messy and poorly maintained. If it is directly changed to utf8mb4, the entire system may not be normal.
2. Consider updating only the table where users can store emoji (hereinafter referred to as Table E) to uft8mb4. However, the system here is written in thinkphp, and the encoding settings are placed in config.php. If you modify this, thinkphp It was all destroyed.
3. If we consider 2, the main body of thinkphp still uses uft8 unchanged, and only temporarily uses uft8mb4 when querying this table E. Try M()->query('SET NAMES 'utf8mb4'');
The result is an error: SQLSTATE[HY000]: General error
4. Still considering method 2 will not work. Because even after successfully querying this table E, operations on other tables will be performed, and uft8mb4 may cause errors in the subsequent query.
Is there a good way to perform utf8mb4-encoded operations on only this table without affecting the operations of other tables?
PS: Because the production environment has been online for a year and has a lot of data and online users, this problem has only been reported in testing now. It is too risky to update the coding of the entire database. The leader's idea is to fill in the pitfalls first, and pretend not to see the pitfalls that are not discovered.
Fortunately, I installed the production environment when I built the system. MySQL was the latest version 5.6.26 at the beginning. I hope the method of re-coding emoji will only be used as a last resort solution.