Mysql字符类型比较

1、 binary和char比较：

• binary 字节为单位，char字符为单位，字符占几个字节取决于字符集
• binary  比较规则基于字节值，char基于字符，即便是_bin的比较规则
• 范围都0-255字节，char对于不一样字符集，能够存取的字节数不一样
• 排序和比较规则都会根据字符码值，而不是词典顺序，若是采用binary那么是区分大小写的，和咱们经常使用的utf8_general_ci相冲突

相同特性，摘自官方文档：

Specifying the CHARACTER SET binary attribute for a character data type causes the column

to be created as the corresponding binary data type: CHAR becomes BINARY, VARCHAR becomes VARBINARY , and TEXT becomes BLOB . For the ENUM and SET data types, this does not occur;

如下两种表定义是等义的：

CREATE TABLE t

(

c1 VARCHAR(10) CHARACTER SET binary,

c2 TEXT CHARACTER SET binary,

c3 ENUM('a','b','c') CHARACTER SET binary

);

CREATE TABLE t

(

c1 VARBINARY(10),

c2 BLOB,

c3 ENUM('a','b','c') CHARACTER SET binary

);

占用空间比较，测试uuid在不一样字符集下的占用空间，主要是考虑到uuid是否适合业务主键的问题

建立4个表，第一个表是utf8字符集比较规则是utf8_bin

mysql> create table tc1(synid char(36) character set utf8 collate utf8_bin);
Query OK, 0 rows affected (0.07 sec)

mysql> create table tc2(synid char(36) character set utf8 collate utf8_general_ci);
Query OK, 0 rows affected (0.08 sec)

mysql> create table tc3(synid char(36) character set binary);
Query OK, 0 rows affected (0.06 sec)

mysql> create table tc4(synid binary(36));                  
Query OK, 0 rows affected (0.11 sec)

插入相同的数据1000条数据，表大小相同：

mysql> SELECT table_name,SUM(data_length) AS data_length
    -> FROM information_schema.TABLES WHERE  
    -> table_name IN ('tc1','tc2','tc3','tc4')
    -> GROUP BY table_name;
+------------+----------------+
| table_name | data_length |
+------------+----------------+
| tc1        |        1589248 |
| tc2        |        1589248 |
| tc3        |        1589248 |
| tc4        |        1589248 |
+------------+----------------+
4 rows in set (0.00 sec)

对于相同的缘由主要有两方面：

• Basic Latin letters, digits, and punctuation signs use one byte，mysql支持的utf8编码对于基本的拉丁字母、数字、标点符号用一个字节
• A UUID is a 128-bit number represented by a utf8 string of five hexadecimal numbers in aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee format。利用uuid函数生成的uuid是32个十六进制数表示的字符串（由0-9和a-f组成），中间有4个横线分隔，总共有36个字符。

当时测试以上问题主要是为了讨论uuid适不适合作业务主键，如下是个人一些总结：

• 咱们物理主键采用int自增，可是业务主键采用uuid
• 这样虽然不够友好，可是能够屏蔽从自增id上获取的业务量。
• 存储上虽然比int要多32个字节，可是如今存储很廉价。咱们能够经过去掉无心义的'-'分隔符（32字节），或者采用uuid_short()（20字节）获取全局惟一标识
• 效率依赖于业务，若是是拿uuid查询，那么说明区分度很高了，创建索引效率不成问题。uuid作索引会比主键索引大不少，但在合理内存范围内就不会产生多余IO
• 和SQLServer保持兼容，若是合并停车记录两张表，显然会冲突，用uuid则不会。为了保证兼容sqlserver的Chinese_PRC_CI_AS，建议采用字符集是utf8，比较规则是utf8_general_ci
• 须要注意的是does not work with statement-based replication，主从复制时，基于语句级别的binlog不支持uuid()函数

2、 char和varchar

• 容许建立char(0)类型字段，用于某个字段存在，可是并不用它的值，只存储两个值：null和''
• 范围是0-65535字节，能够存储多少个字符由字符集决定。当字段类型小于255字节时，前缀会存储1个字节；当字段长度大于255时，前缀会存储2个字节
• 当char被存储时，会自动在尾部填充空格到设置的长度。varchar会保留空格。当char被检索时，会移除尾部空格，除非设置了PAD_CHAR_TO_FULL_LENGTH

• 当char被检索时，会移除尾部空格，除非设置了PAD_CHAR_TO_FULL_LENGTH；varchar在检索时会保留尾部空格

• 在严格的SQL mode下，char和varchar类型字段超过最大长度会截断并产生警告，若是截断的是非空字符，那么会阻止插入并报错，在任何SQL mode下，varchar会截断超出长度的空格，char则会截断尾部全部空格
• char和varchar的比较都是忽略尾部空格的，可是除了将尾部空格做为like匹配条件的

注意：须要注意的是，varchar显示是不截断尾部空格的，但在比较的时候忽略空格的，此外varchar存储时会去掉尾部空格，若是该字段被定义成惟一建或主键，去除结尾空格后相同的字符串会违反惟一性约束

3、 binary和vbinary

• binary和vbinary在超过最大设置长度时，在非strict SQL mode下，那么会自动截断并警告；在strict SQL mode下，会阻止插入，并报错。
• binary存储时自动填充值\0(0x00),知足指定长度，例如，char(3),'a '插入变成'a \0'，'a'变成'a\0\0'。在检索的时候，并不去掉结尾的填充值。
• varbinary，存储时不会填补\0，检索时不会去掉结尾\0
• binary和varbinary在比较时，包括order by和distinct，全部的字节都是有意义的。注0x00<space，不相等

注意：一样，vbinary在须要注意在存储时去掉尾部\0，若是该字段被定义成惟一建或主键，去除结尾\0后相同的字符串会违反惟一性约束