P.S. 基于mysql 5.6，數(shù)據(jù)庫引擎是 InnoDB

解決方案：

1 、使用INSERT ... ON DUPLICATE KEY UPDATE Statement 語法；官網(wǎng)手冊(cè)地址

2、 使用REPLACE statement 官網(wǎng)手冊(cè)地址

3、邏輯層處理，先判斷是否存在記錄，有則修改數(shù)據(jù)然后提交(刪除然后插入)，否則直接插入

方案一詳解

1、語法INSERT ... ON DUPLICATE KEY UPDATE ...

2、例子INSERT INTO t1 (a,b,c) VALUES (1,2,3)

ON DUPLICATE KEY UPDATE c=c+1;

3、說明如果數(shù)據(jù)庫表t1的字段a 為主鍵(Primary key)或者唯一索引(Unique Index)，則上面的操作在遇到數(shù)據(jù)庫已經(jīng)存在a=1的情況下，則會(huì)進(jìn)行c自增1的效果，否則就是插入一條記錄。

如果是插入一條新記錄，則影響的行記錄數(shù)量是1；如果是更新，則返回的是2；沒有變化則返回0。

如果a的屬性是AUTO INCREMENT，則LAST_INSERT_ID()方法獲取到的是自增值(AUTO_INCREMENT VALUE)，而不是影響的行數(shù)。

UPDATE 后面可更新多個(gè)字段，他們用英文逗號(hào)分割。

UPDATE 后面的賦值表達(dá)式，可以使用values(col_name)函數(shù)獲取到INSERT字段插入的值：INSERT INTO t1 (a,b,c) VALUES (1,6,3)

ON DUPLICATE KEY UPDATE c=VALUES(a)+VALUES(b);

如果，數(shù)據(jù)庫中已經(jīng)存在a=1的記錄，那么c=1+6，用values(col_name)獲取col_name字段欲被分配的值，從而避免duplicate-key conflict。DELAYED選項(xiàng)在這個(gè)語句中無效。

方案二詳解

1、語法REPLACE [LOW_PRIORITY | DELAYED]

[INTO] tbl_name

[PARTITION (partition_name [, partition_name] ...)]

[(col_name [, col_name] ...)]

{VALUES | VALUE} (value_list) [, (value_list)] ...

REPLACE [LOW_PRIORITY | DELAYED]

[INTO] tbl_name

[PARTITION (partition_name [, partition_name] ...)]

SET assignment_list

REPLACE [LOW_PRIORITY | DELAYED]

[INTO] tbl_name

[PARTITION (partition_name [, partition_name] ...)]

[(col_name [, col_name] ...)]

SELECT ...

value:

{expr | DEFAULT}

value_list:

value [, value] ...

assignment:

col_name = value

assignment_list:

assignment [, assignment] ...

2、例子REPLACE INTO test VALUES (1, 'Old', '2014-08-20 18:47:00');

3、說明在沒有主鍵Primary key或者Unique index沖突時(shí)，和INSERT功能一樣；沖突時(shí)，它先刪除舊紀(jì)錄，然后插入新記錄來完成更新，這也意味著執(zhí)行sql語句的用戶有插入和刪除的權(quán)限。

REPLACE時(shí)沒有指定的字段，其值會(huì)被設(shè)置為Default value，且沒有辦法獲取到舊紀(jì)錄該字段的值然后把他應(yīng)用到新記錄中(即沒辦法像方案一中使用VALUES()函數(shù))。

返回影響的行數(shù)值是刪除和增加的總和，如果返回1，說明只進(jìn)行了增加。

由于REPLACE INTO的結(jié)果依賴SELECT的結(jié)果集記錄順序，而且這個(gè)順序無法保證，這有可能造成日志記錄數(shù)據(jù)不一致。因此，這個(gè)操作被標(biāo)記為在聲明式備份時(shí)"不安全"，且在聲明模式下，會(huì)在錯(cuò)誤日志文件中記錄一個(gè)警告，然而在使用混合(MIXED)模式時(shí)，警告會(huì)基于行的格式被寫進(jìn)一個(gè)二進(jìn)制日志文件。

如果表是聯(lián)合主鍵，則更新時(shí)，這些主鍵都要相同才能認(rèn)為是主鍵沖突，如果只有其中部分主鍵相同，則直接進(jìn)行插入操作。

使用的算法是：嘗試直接將數(shù)據(jù)插入；

如果因?yàn)橹麈I沖突造成插入失敗：刪除表中含有該主鍵的記錄；

插入新記錄；

方案三

有上述兩個(gè)方案，問題可以由代碼邏輯實(shí)現(xiàn)，但是，以上操作是保證了數(shù)據(jù)庫的原子操作，如果是自己實(shí)現(xiàn)，要保證這一條。

后記

產(chǎn)生這篇文章的起因是：有個(gè)新增用戶的業(yè)務(wù)需求，我想將新增和更新封裝為一個(gè)API，所以使用了ON DUPLICATE KEY UPDATE，開始是使用數(shù)據(jù)庫ID作為主鍵，但是，后來還需要保證用戶的手機(jī)號(hào)唯一，所以給手機(jī)字段添加了UNIQUE屬性，在新增用戶的時(shí)候，并不會(huì)觸發(fā)DuplicateKeyException，所以開始找ON DUPLICATE KEY UPDATE有沒有條件只需要確認(rèn)primary key沖突即可，發(fā)現(xiàn)，只能換個(gè)思路實(shí)現(xiàn)：

1、查詢手機(jī)號(hào)是否存在；

2、存在則返回提示，否則，進(jìn)行插入；

3、根據(jù)是否傳入數(shù)據(jù)庫ID作為更新還是新增的條件，進(jìn)行新增更新操作。

總結(jié)

以上是生活随笔為你收集整理的mysql 值到99999后不增值了_Mysql 增加新数据，若存在则更新的问题的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。