I believe that many developers optimize SQL statements. Recently, I encountered a pit in optimizing SQL. Let me share with you here;
Through the page crawling to the interface that takes more than 3 seconds, find the corresponding SQL, set the corresponding parameters, analyze through Explain in the test environment, check the execution plan, check whether the scan has gone through the index through analysis, and find that all the indexes are gone through , In the production environment, I have also taken the index, and I have thought of many ways to find the source of the problem.
Finally, I asked a big guy to analyze. He analyzed the structure of the database table and found that the table we produced was utf8mb4, and the test was utf8. The reason was that my colleagues modified the character set of some tables two days ago, which led to the production environment. Some tables use utf8mb4, and some use utf8. The inconsistency of the character set of the associated table causes the SQL to clear the problem of slow indexing.
Then we have to see what is the difference between utf8mb4 and utf8?
utf8mb4 is an encoding added after MySQL 5.5.3, and mb4 means most bytes 4, which is specifically designed to be compatible with four-byte unicode. It is a superset of utf8, and generally defaults to utf8, and utf8 takes up relatively little resources.
The maximum character length of utf8 encoding supported by mysql is 3 bytes, and an exception will be inserted when it encounters a 4-byte wide character. The maximum Unicode character that can be encoded by 3-byte utf8 is 0xffff, which is the basic multilingual plane in Unicode.
In the actual development process, it is recommended to use the utf8mb4 type. After all, the compatibility is good, but using utf8mb4 for the CHAR type will waste space. You can change the CHAR type to the varchar type.