MySQL數(shù)值類型在binlog中需要注意的細(xì)節(jié)有哪些

MySQL數(shù)值類型在binlog中需要注意的細(xì)節(jié)有哪些，相信很多沒有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策，為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法，通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。

    MySQL里的數(shù)值類型分得很細(xì)，光整型數(shù)據(jù)就有多種數(shù)據(jù)類型。tinyint,smallint,mediumint,int(integer),還有范圍最大的bigint，它們對(duì)應(yīng)的數(shù)值范圍也大大不同，大體來(lái)說(shuō)就是下面的數(shù)值范圍，從有符號(hào)數(shù)和無(wú)符號(hào)數(shù)來(lái)區(qū)別對(duì)待。

   這一點(diǎn)上Oracle做得很大氣，直接一個(gè)number類型，精度也包了，兩者在這個(gè)地方風(fēng)格截然不同。

   對(duì)于MySQL的數(shù)據(jù)類型，我們來(lái)說(shuō)說(shuō)bigint,如果按照無(wú)符號(hào)數(shù)，最大的值為18446744073709551615，這是一個(gè)相當(dāng)大的數(shù)字，如果從有符號(hào)數(shù)據(jù)的角度來(lái)看就是-1，那么問(wèn)題來(lái)了，在MySQL的binlog里面是否會(huì)區(qū)分signed還是unsigned呢，如果不區(qū)分，這類問(wèn)題該怎么應(yīng)對(duì)。

  我做了如下的測(cè)試,使用conv來(lái)做進(jìn)制轉(zhuǎn)換。

> select conv(-1,10,2);
+------------------------------------------------------------------+
| conv(-1,10,2)                                                    |
+------------------------------------------------------------------+
| 1111111111111111111111111111111111111111111111111111111111111111 |
+------------------------------------------------------------------+

> select conv(18446744073709551615,10,2);
+------------------------------------------------------------------+
| conv(18446744073709551615,10,2)                                  |
+------------------------------------------------------------------+
| 1111111111111111111111111111111111111111111111111111111111111111 |
+------------------------------------------------------------------+從機(jī)制轉(zhuǎn)換的結(jié)果來(lái)看，兩者是沒有差別的，如果是實(shí)際的場(chǎng)景中，這可是天壤之別。

我們換一個(gè)角度來(lái)轉(zhuǎn)換一下。

> 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    |
+-------------------------+這么看來(lái)，讓人有些擔(dān)憂，如果達(dá)到這種數(shù)據(jù)的臨界點(diǎn)，會(huì)發(fā)生什么意料之外的結(jié)果呢。

我們來(lái)創(chuàng)建一個(gè)表，指定兩個(gè)字段，一個(gè)為有符號(hào)類型，一個(gè)為無(wú)符號(hào)類型，然后對(duì)應(yīng)的數(shù)字，從binlog來(lái)看看解析出來(lái)的結(jié)果。

create table t1 (id int unsigned not null auto_increment primary key, col1 bigint unsigned, col2 bigint signed) engine=innodb;接著我們切一下日志，查看一下master對(duì)的狀態(tài)，得到日志的偏移量和binlog名字。

> flush logs; show master status;
+---------------+----------+
| File          | Position |
+---------------+----------+
| binlog.000031 |      107 |
+---------------+----------+這個(gè)時(shí)候我們插入兩列值，一個(gè)無(wú)符號(hào)，一個(gè)有符號(hào)。

insert into t1 (col1, col2) values (18446744073709551615, -1);然后使用flush logs再次切換日志。

查看數(shù)據(jù)的情況，可以從輸出看出兩者是有明顯的差別的。

> select * from t1;
+----+----------------------+------+
| id | col1                 | col2 |
+----+----------------------+------+
|  1 | 18446744073709551615 |   -1 |
+----+----------------------+------+我們從binlog來(lái)解析一下。

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/*!*/;這樣看來(lái)對(duì)于binlog中，有符號(hào)數(shù)和無(wú)符號(hào)數(shù)都會(huì)按照無(wú)符號(hào)數(shù)來(lái)轉(zhuǎn)換，當(dāng)然直接看數(shù)據(jù)類型是沒有標(biāo)識(shí)有符號(hào)和無(wú)符號(hào)的差別的。所以如果是單純要解析binlog處理數(shù)據(jù)就需要考慮到這個(gè)地方的差別，對(duì)此一種思路是查看information_schema中的列信息來(lái)做出更加明確的判斷。

看完上述內(nèi)容，你們掌握MySQL數(shù)值類型在binlog中需要注意的細(xì)節(jié)有哪些的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！