Used to use oracle11g, a Chinese character accounted for 3 bytes, so in the operation of MySQL also has been allocated length.
It's been tested today, and we found it wrong.
You can see that the length of the first is really 15, but why is the second one 5?
Find information on the Internet: Char_length calculates the length of the character, and length calculates the length of the byte, just as I am using UTF8, a Chinese character that occupies 3 bytes and occupies a single character.
Well, it should be right, but curiosity I tried.
Why is this the same? Because it's not Chinese.
Well, now I know that MySQL is the same as Oracle, but also see that the MySQL varchar and Oracle's VARCHAR2 is not the same, the former is in the character unit, the latter is in bytes to do the unit. The VARCHAR2 for oracle11g is measured in bytes in the previous play with Oracle, but MySQL has not been tested, well now under test. I first change the length of the field to look down can be given, the test results are really possible, prove that the MySQL varchar is a character to do the unit, here does not map, we can verify their own.
Summary: Oracle in VARCHAR2 (10) with 10 bytes and 3 kanji
MySQL in varchar (10) both 10 characters and 10 kanji
So now you can reduce MySQL's varchar field by 1/3, and the performance can be improved.
One kanji for MySQL and Oracle for several characters