MySQL数值类型在binlog中需要注意的细节有哪些
发布时间：2021-12-20 10:51:12 所属栏目：通讯 来源：互联网
导读：MySQL数值类型在binlog中需要注意的细节有哪些，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。 MySQL里的数值类型分得很细，光整型数据就有多种数据类型。tinyint,smallint,mediumint,i
 MySQL数值类型在binlog中需要注意的细节有哪些，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。 MySQL里的数值类型分得很细，光整型数据就有多种数据类型。tinyint,smallint,mediumint,int(integer),还有范围最大的bigint，它们对应的数值范围也大大不同，大体来说就是下面的数值范围，从有符号数和无符号数来区别对待。 类型名称 有符号数（signed) 无符号数(Unsigned) tinyint -129~127 0~255 smallint -32768~32767 0~65535 mediumint -8388608~8388607 0~16777215 int(integer) -2147483648~2147483647 0~4294967295 bigint -9223372036854775808~ 9223372036854775807 0~18446744073709551615 这一点上Oracle做得很大气，直接一个number类型，精度也包了，两者在这个地方风格截然不同。 对于MySQL的数据类型，我们来说说bigint,如果按照无符号数，最大的值为18446744073709551615，这是一个相当大的数字，如果从有符号数据的角度来看就是-1，那么问题来了，在MySQL的binlog里面是否会区分signed还是unsigned呢，如果不区分，这类问题该怎么应对。 我做了如下的测试,使用conv来做进制转换。 > select conv(-1,10,2); +------------------------------------------------------------------+ | conv(-1,10,2) | +------------------------------------------------------------------+ | 1111111111111111111111111111111111111111111111111111111111111111 | +------------------------------------------------------------------+ > select conv(18446744073709551615,10,2); +------------------------------------------------------------------+ | conv(18446744073709551615,10,2) | +------------------------------------------------------------------+ | 1111111111111111111111111111111111111111111111111111111111111111 | +------------------------------------------------------------------+从机制转换的结果来看，两者是没有差别的，如果是实际的场景中，这可是天壤之别。 我们换一个角度来转换一下。 > select conv(repeat(1,64),2,-10); +--------------------------+ | conv(repeat(1,64),2,-10) | +--------------------------+ | -1 | +--------------------------+ > select conv(repeat(1,64),2,10); +-------------------------+ | conv(repeat(1,64),2,10) | +-------------------------+ | 18446744073709551615 | +-------------------------+这么看来，让人有些担忧，如果达到这种数据的临界点，会发生什么意料之外的结果呢。 我们来创建一个表，指定两个字段，一个为有符号类型，一个为无符号类型，然后对应的数字，从binlog来看看解析出来的结果。 create table t1 (id int unsigned not null auto_increment primary key, col1 bigint unsigned, col2 bigint signed) engine=innodb;接着我们切一下日志，查看一下master对的状态，得到日志的偏移量和binlog名字。 > flush logs; show master status; +---------------+----------+ | File | Position | +---------------+----------+ | binlog.000031 | 107 | +---------------+----------+这个时候我们插入两列值，一个无符号，一个有符号。 insert into t1 (col1, col2) values (18446744073709551615, -1);然后使用flush logs再次切换日志。 查看数据的情况，可以从输出看出两者是有明显的差别的。 > select * from t1; +----+----------------------+------+ | id | col1 | col2 | +----+----------------------+------+ | 1 | 18446744073709551615 | -1 | +----+----------------------+------+我们从binlog来解析一下。 mysqlbinlog -vv binlog.000031 得到的部分日志如下： ### INSERT INTO test.t1 ### SET ### @1=1 /* INT meta=0 nullable=0 is_null=0 */ ### @2=-1 (18446744073709551615) /* LONGINT meta=0 nullable=1 is_null=0 */ ### @3=-1 (18446744073709551615) /* LONGINT meta=0 nullable=1 is_null=0 */ # at 268 #170519 18:54:47 server id 13386 end_log_pos 295 Xid = 76 COMMIT/*!*/;这样看来对于binlog中，有符号数和无符号数都会按照无符号数来转换，当然直接看数据类型是没有标识有符号和无符号的差别的。所以如果是单纯要解析binlog处理数据就需要考虑到这个地方的差别，对此一种思路是查看information_schema中的列信息来做出更加明确的判断。 看完上述内容，你们掌握MySQL数值类型在binlog中需要注意的细节有哪些的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注亿速云行业资讯频道，感谢各位的阅读！ （编辑：南京站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐
热点阅读