MySQL Character Set and copy_and_convert

MySQL Character Set and copy_and_convert about copy_and_convert when conducting a business stress test on MySQL, we found in the perf results that copy_and_convert is a cpu-consuming operation. This function refers to content conversion between character sets. If the source and target character sets are the same, you can directly use memcpy, which is obviously faster than character set conversion (copying by byte or word length, and saves cpu) when the entire system is a CPU bottleneck, we hope to reduce this cpu consumption. The copy involved in a query at www.2cto.com. If we execute a simple select statement, it involves two parts: metadata and data. The MySQL return package can be "self-parsed", that is, not only the content, but also the description information. These descriptions are called metadata. When these two pieces of information are returned to the client, string copying is involved. If the source character set is different from the target character set, conversion is required. Part 1 that can be defined in the character set. For example, we CREATE the following TABLE www.2cto.com create table 'T' ('C' int (11) default null, 'D' varchar (50) default null) ENGINE = InnoDB default charset = gbk; this defines the character set of the table and requires data to be stored in gbk format. During our query, the data read from the table is the "source Character Set" we mentioned above. Here it is gbk. for example, Insert t values (2012, 'Very cold South'); 2. When connecting the character set, you can specify the mysql-default-character-set = gbk parameter on the mysql client, it indicates that the content we receive is encoded in gbk. This is the "target Character Set" mentioned above ". We generally recommend that you use the same connection character set as the table character set. Some articles say that it is not possible to prevent garbled characters. The actual reason is to avoid Character Set conversion during content copying. But even if we do this, we will still find that copy_and_convert will be called during stress testing (or gdb. There are two reasons for www.2cto.com: first, the metadata section is fixed with utf8. The value can be seen from the results of show variables like 'character _ set_system '; the configuration cannot be modified. Secondly, although we define that the table character set is gbk, the integer field is stored in Latin1, # define my_charset_numeric my_charset_latin1, And the configuration cannot be modified. Therefore, in our above settings, a query requires utf8-> gbk when returning metadata. In the returned result, the field c needs latin1-> gbk. the problem and suggestion are analyzed above. The problem is that this conversion cannot be completely avoided no matter how users set it. After the numeric type is converted to a string, all character sets occupy the same space. 1) The simplest code modification can be as follows: change # define my_charset_numeric my_charset_latin1 to # define my_charset_numeric my_charset_utf8_general_ci, which is the same as that of metadata, and then use UTF-8 for. 2) to be more flexible, change character_set_system to configurable, and then store integer data in accordance with user-defined character sets.