.jpg)
這里記錄的是很久之前的一個(gè) bug 了，主要給大家介紹了關(guān)于mysql中唯一性約束與null的相關(guān)資料，文中介紹的非常詳細(xì)，對(duì)大家具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面來一起看看吧。
前言
之前做的一個(gè)需求，簡化描述下就是接受其他組的 MQ 的消息，然后在數(shù)據(jù)庫里插入一條記錄。為了防止他們重復(fù)發(fā)消息，插入多條重復(fù)記錄，所以在表中的幾個(gè)列上加了個(gè)唯一性索引。
CREATE?UNIQUE?INDEX?IDX_UN_LOAN_PLAN_APP?ON?testTable?(A,?B,?C);
這時(shí) A,B,C 三列都是不允許 NULL 值的，唯一性約束也是 work 的。
后來由于需求的變化，修改了以前的唯一性約束，又多加了一列。(至于為什么加就不贅述了)。
ALTER?TABLE?testTable DROP?INDEX?IDX_UN_LOAN_PLAN_APP, ADD?UNIQUE?KEY?`IDX_UN_LOAN_PLAN_APP`?(A,?B,?C,?D);
新加的 D 是類型是 datetime, 允許為 NULL，默認(rèn)值為 NULL。之所以默認(rèn)值為 NULL，是考慮到不是所有記錄都有這個(gè)時(shí)間的， 如果強(qiáng)行設(shè)置一個(gè) Magic Value (比如’1970-01-01 08:00:00‘)當(dāng)做默認(rèn)值，看起來很奇怪。
藍(lán)后。。。就出問題了。加了 D 之后，唯一性約束基本就失效了。
Insert?into?testTable?(A,B,C,D)?VALUES?(1,2,3,NULL);?---?OK Insert?into?testTable?(A,B,C,D)?VALUES?(1,2,3,NULL);?---?OK Insert?into?testTable?(A,B,C,D)?VALUES?(1,2,3,NULL);?---?OK
上面的三條 SQL 都是可以執(zhí)行成功的，數(shù)據(jù)庫中會(huì)有多條一樣的記錄。可按照我們以前的構(gòu)想，在執(zhí)行后兩條 SQL 時(shí) 應(yīng)該拋出 ‘Duplicate key’ 的異常的。
后來查了一下，才發(fā)現(xiàn)其實(shí) mysql 官方文檔上已經(jīng)明確說了這一點(diǎn)， 唯一性索引是允許多個(gè) NULL 值的存在的：
A?UNIQUE?index?creates?a?constraint?such?that?all?values?in?the?index?must?be?distinct.?An?error?occurs?if?you?try?to?add?a?new?row?with?a?key?value?that?matches?an?existing?row.?For?all?engines,?a?UNIQUE?index?allows?multiple?NULL?values?for?columns?that?can?contain?NULL.
從下表中也可以看出來不管是采用什么類型的存儲(chǔ)引擎，在建立 unique key 的時(shí)候都是允許多個(gè) NULL 存在的。。。。
細(xì)想想，其實(shí)也蠻合理，畢竟在 MySQL 中認(rèn)為 NULL 代表著“未知”。 在 SQL 中，任何值與 NULL 的比較返回值都是 NULL 而不是 TRUE, 就算 NULL 與 NULL 的比較也是返回 NULL。
所以只能 fix 了。。。解決辦法也蠻簡單粗暴的，直接把線上數(shù)據(jù)刷了一遍，將“1970-01-01 08:00:00”作為默認(rèn)值，然后把那列改為不允許為 NULL 的了，咳咳。
MySQL 官網(wǎng)上也有蠻多人討論過這個(gè)問題，一部分人認(rèn)為這是 MySQL 的 bug， 另一部分則認(rèn)為是一個(gè) feature，附上鏈接。
MySQL Bugs: #8173: unique index allows duplicates with null values
.png)
