MySQL中的数据类型binary和varbinary详解
时间:2017-11-22 16:42:58|栏目:MySQL|点击: 次
BINARY和VARBINARY与 CHAR和VARCHAR类型有点类似,不同的是BINARY和VARBINARY存储的是二进制的字符串,而非字符型字符串。也就是说,BINARY和VARBINARY没有字符集的概念,对其排序和比较都是按照二进制值进行对比。
BINARY(N)和VARBINARY(N)中的N指的是字节长度,而CHAR(N)和VARCHAR(N)中N指的是的字符长度。对于BINARY(10) ,其可存储的字节固定为10,而对于CHAR(10) ,其可存储的字节视字符集的情况而定。
我们来看下面的例子。
mysql> CREATE TABLE t (
-> a BINARY(1)
-> )ENGINE=InnoDB CHARSET=GBK;
Query OK, 0 rows affected (0.02 sec)
mysql> SET NAMES GBK;
Query OK, 0 rows affected (0.00 sec)
MySQL> INSERT INTO t SELECT '我';
Query OK, 1 row affected, 1 warning (0.01 sec)
Records: 1 Duplicates: 0 Warnings: 1
mysql> SHOW WARNINGS\G;
*************************** 1. row ***************************
Level: Warning
Code: 1265
Message: Data truncated for column 'a' at row 1
1 row in set (0.00 sec)
mysql> SELECT a,HEX(a) FROM t\G;
*************************** 1. row ***************************
a:
HEX(a): CE
表t包含一个类型为BINARY(1)的列,因为BINARY(N)中N代表字节,而gbk字符集中的中文字符“我”需要占用2字节,所以在插入时给出警告,提示字符被截断。如果SQL_MODE为严格模式,则会直接报错。查看表t的内容,则可发现a中只存储了字符“我”的前一个字节,后一个字节被截断了。如果表t的a列中字符的类型为CHAR类型,则完全不会有上述问题,例如:
mysql> CREATE TABLE t (
-> a CHAR(1)
-> )ENGINE=InnoDB CHARSET=GBK;
Query OK, 0 rows affected (0.02 sec)
mysql> INSERT INTO t SELECT '我';
Query OK, 1 row affected, 1 warning (0.01 sec)
Records: 1 Duplicates: 0 Warnings: 0
mysql> SELECT a,HEX(a) FROM t\G;
*************************** 1. row ***************************
a: 我
HEX(a): CED2
1 row in set (0.00 sec)
BINARY和VARBINARY对比CHAR和VARCHAR,第一个不同之处就是BINARY(N)和VARBINARY(N)中的N值代表的是字节数,而非字符长度;第二个不同点是,CHAR和VARCHAR在进行字符比较时,比较的只是字符本身存储的字符,忽略字符后的填充字符,而对于BINARY和VARBINARY来说,由于是按照二进制值来进行比较的,因此结果会非常不同,例如:
mysql> SELECT
-> HEX('a'),
-> HEX('a '),
-> 'a'='a '\G;
*************************** 1. row ***************************
HEX('a'): 61
HEX('a '): 612020
'a'='a ': 1
1 row in set (0.00 sec)
mysql> SELECT
-> HEX(BINARY('a')),
-> HEX(BINARY('a ')),
-> BINARY('a')= BINARY('a ')\G;
*************************** 1. row ***************************
HEX(BINARY('a')): 61
HEX(BINARY('a ')): 612020
BINARY('a')= BINARY('a '): 0
1 row in set (0.00 sec)
对于CHAR和VARCHAR来说,比较的是字符值,因此第一个比较的返回值是1。对于BINARY和VARBINARY来说,比较的是二进制的值,“a”的十六进制为61,“a ”的十六进制为612020,显然不同,因此第二个比较的返回值为0。
第三个不同的是,对于BINARY字符串,其填充字符是0x00,而CHAR的填充字符为0x20。可能是因为BINARY的比较需要,0x00显然是比较的最小字符,示例如下:
mysql> CREATE TABLE t ( a BINARY(3));
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO t SELECT 'a';
Query OK, 1 row affected (0.00 sec)
Records: 1 Duplicates: 0 Warnings: 0
mysql> SELECT a,HEX(a) FROM t\G;
*************************** 1. row ***************************
a: a
HEX(a): 610000
1 row in set (0.00 sec)
您可能感兴趣的文章
- 05-31MySQL中的 inner join 和 left join的区别解析(小结果集驱动大结果集)
- 05-31MySQL索引失效十种场景与优化方案
- 05-31MYSQL 高级文本查询之regexp_like和REGEXP详解
- 05-31MySQL获取binlog的开始时间和结束时间(最新方法)
- 05-31MySQL索引查询的具体使用
- 05-31基于MySQL和Redis扣减库存的实践
- 05-31关于MySQL的存储过程与存储函数
- 05-31MySQL实战文章(非常全的基础入门类教程)
- 05-31MySQL Flink Watermark实现事件时间处理的关键技术
- 05-31MySQL Flink实时流处理的核心技术之窗口机制
阅读排行
推荐教程
- 05-30Navicat for MySQL 11注册码激活码汇总
- 05-27Mysql误删数据快速恢复
- 05-31VS2022连接数据库MySQL并进行基本的表的操作指南
- 05-30解决seata不能使用mysql8版本的问题方法
- 05-30MYSQL字符集设置的方法详解(终端的字符集)
- 05-30解决MySQL启动报错:ERROR 2003 (HY000): Can't con
- 05-30关于Mysql-connector-java驱动版本问题总结
- 11-22mac下安装mysql忘记密码的修改方法
- 05-30MySQL中的隐藏列的具体查看
- 11-22mysql exists与not exists实例详解