MySQL數值類型在binlog中需要注意的細節有哪些

MySQL數值類型在binlog中需要注意的細節有哪些，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

    MySQL里的數值類型分得很細，光整型數據就有多種數據類型。tinyint,smallint,mediumint,int(integer),還有范圍最大的bigint，它們對應的數值范圍也大大不同，大體來說就是下面的數值范圍，從有符號數和無符號數來區別對待。

   這一點上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中需要注意的細節有哪些的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！