Insert為0的記錄導致數據混亂該怎么辦

Insert為0的記錄導致數據混亂該怎么辦，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

環境.MySQL 5.6.14
SQL_Mode:STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION

生產環境 配置表,設置主鍵為自增.
一天某同學讓我幫忙從測試導一批數據到生產.
雖然我對這種方式深惡痛絕,但是沒有辦法..也只能照做.
導入之后的第二天,業務發現很多生產數據錯亂了。
這個禮物的配置表,主鍵原本設計成自增主鍵.
但是后來他們用0表示一種特殊禮物...坑就在這里了。

過程模擬

1. drop table if exists config_gift;
   

2. create table config_gift(
   

3.     GiftID int not null primary key auto_increment,
   

4.     GiftName varchar(32) not null
   

5. ) auto_increment=50000;
   

6. 
   

7. insert into config_gift(GiftName) select '鮮花';
   

8. insert into config_gift(GiftName) select '鞭炮';
   

9. insert into config_gift(GiftName) select '福袋';
   

10. 
    

11. 
    

12. 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的記錄導致數據混亂該怎么辦問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。