共計 1263 個字符，預計需要花費 4 分鐘才能閱讀完成。
Insert 為 0 的記錄導致數據混亂該怎么辦，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
環境.MySQL 5.6.14
SQL_Mode:STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION
生產環境 配置表, 設置主鍵為自增.
一天某同學讓我幫忙從測試導一批數據到生產.
雖然我對這種方式深惡痛絕, 但是沒有辦法.. 也只能照做.
導入之后的第二天, 業務發現很多生產數據錯亂了。
這個禮物的配置表, 主鍵原本設計成自增主鍵.
但是后來他們用 0 表示一種特殊禮物 … 坑就在這里了。
過程模擬
drop table if exists config_gift;
create table config_gift(
GiftID int not null primary key auto_increment,
GiftName varchar(32) not null
) auto_increment=50000;
insert into config_gift(GiftName) select 鮮花
insert into config_gift(GiftName) select 鞭炮
insert into config_gift(GiftName) select 福袋
select * from config_gift;
當時的 SQL_Mode 是:STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION
如果這時執行如下的語句，
insert into config_gift select 0, 蛋糕
insert into config_gift select null, 香水
查看結果竟然如下:
MySQL 如果已經設置了主鍵自動增長, 但是后來卻 插入 0 或者 null 作為主鍵值的話, MySQL 會用自增長的值, 取代原本的 0 或者 null。
業務代碼中寫死了 0 這個禮物 ID 的判斷, 所以導致了大量數據錯亂, 花了很長時間修正.
這種事情猝不及防
業務方定的這個特殊禮物就用 0 表示, 而且也沒有人來通知數據庫 …
數據上線的時候, 都是一批數據, 人力甄別數據似乎也不現實.
改 SQL_mode 保平安吧.
在自增主鍵下, 處理主鍵為 0 的數據
set @@session.sql_mode= STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION,no_auto_value_on_zero
修改 Global 和 Session 級別的 SQL_mode 之后, 主鍵為 0 的禮物可以正確插入了。
主要注意的是, 即使在這個 SQL_mode 下(STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION,no_auto_value_on_zero)
自增主鍵,Insert 主鍵為 null 的數據, 還是會使用自增主鍵的值作為主鍵, 而不是報錯。
關于 Insert 為 0 的記錄導致數據混亂該怎么辦問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注丸趣 TV 行業資訊頻道了解更多相關知識。
