?戳藍(lán)字「TopCoder」關(guān)注我們哦！

平常使用 mysql ，必不可少的會用到 update 語句，不知道小伙伴有沒有這樣的疑問？

如果 update 語句和原數(shù)據(jù)一樣會更新么？更具體的來說，如果更新的數(shù)據(jù)前后是一樣的，MySQL 會更新存儲引擎中(磁盤)數(shù)據(jù)么？

關(guān)于這個問題，在分析之前我們可以思考下：update語句和原數(shù)據(jù)一樣，有必要更新么？理論上來講是沒有必要的。MySQL Server 層在執(zhí)行 sql 時(shí)，其實(shí)是不知道是否是一樣的，因此可以猜想，如果 MySQL 已經(jīng)知道原數(shù)據(jù)的話，這樣可以和 update 語句做對比，這樣一樣的話可以不用更新了。

那么 MySQL 在執(zhí)行update 語句時(shí)，什么時(shí)候會讀取原數(shù)據(jù)呢？這就涉及到 binlog 的數(shù)據(jù)格式，binlog 數(shù)據(jù)格式相關(guān)配置項(xiàng)為binlog_format，該配置取值范圍如下：

• statement：邏輯SQL格式，通過mysqlbinlog工具可進(jìn)行查看，就是sql語句；

• row：記錄的是行更改日志，對于statement格式binlog復(fù)制潛在的問題可通過row來解決；

• mixed：默認(rèn)使用statement格式，某些操作下使用row格式，比如uuid/now/user等不確定函數(shù)。

注意：在msyql 5.1版本之前默認(rèn)都是基于sql語句(statement)級別的，statement格式的binlog會造成某些操作在主從復(fù)制時(shí)出現(xiàn)問題，比如now/rand/uuid等。

row 格式的 binlog 會記錄鏡像數(shù)據(jù)，針對 update 來說，必須是前鏡像數(shù)據(jù)才能判斷出來update 語句是否和原數(shù)據(jù)一樣。針對 row 格式的鏡像數(shù)據(jù)配置，由配置項(xiàng)binlog_row_image來決定(該配置只在 row 模式下才起作用)，該配置項(xiàng)官方文檔如下：

full: Log all columns in both the before image and the after image.

minimal: Log only those columns in the before image that are required to identify the row to be changed; log only those columns in the after image where a value was specified by the SQL statement, or generated by auto-increment.

noblob: Log all columns (same as full), except for BLOB and TEXT columns that are not required to identify rows, or that have not changed.

簡單來說，full會記錄所有列，noblob會記錄除blob和text外的所有列，minimal只會記錄需要的列。對于insert 來說，只有后鏡像沒有前鏡像；對于update來說，有前鏡像和后鏡像；對于delete來說，只有前鏡像沒有后鏡像。對于 full 和 noblob 沒有什么好說的，對于minimal來說，insert 記錄所有列后鏡像，update 和 delete的話要分為幾種情況：

• 當(dāng)存在主鍵索引或者唯一索引時(shí)，update記錄主鍵列前鏡像和更新列后鏡像，delete 記錄主鍵列前鏡像。

• 只有普通二級索引時(shí)，update 記錄所有列前鏡像和更新列后鏡像，delete 記錄所有列前鏡像。

針對minimal的binlog_row_image為什么要這么設(shè)計(jì)呢？有主鍵或者唯一鍵的話，可以通過其定位到唯一一條記錄，因此沒有必要記錄整個列的鏡像數(shù)據(jù)了，在只有二級索引或者其他情況下，只能記錄整個列的鏡像數(shù)據(jù)。

那么日常開發(fā)中，應(yīng)該怎么配置binlog_row_image呢？建議配置成 full 模式，因?yàn)檫@樣可以以空間換取更多的數(shù)據(jù)保證，可以避免binlog 的閃回功能。

回到最初提到的問題，可以知道，在binlog_format=row時(shí)，由于MySQL 需要在 binlog 里面記錄數(shù)據(jù)對應(yīng)字段，因此會進(jìn)行數(shù)據(jù)的讀取操作，此時(shí)就可以進(jìn)行數(shù)據(jù)對比，重復(fù)數(shù)據(jù)的update不會執(zhí)行。具體驗(yàn)證可以通過以下幾個命令：

show?master?status\G
set??binlog_format?='row';?//?statement
show?variables?like?'binlog_format';
update?xxx

針對 uddate 語句和原數(shù)據(jù)一樣時(shí)可能不會進(jìn)行更新操作，因此該場景下返回的影響行數(shù)可能為0。

?推薦閱讀?

• CompletableFuture 應(yīng)用實(shí)踐

• Java線程池實(shí)現(xiàn)原理

• 深入理解Java線程池

• JMM Java內(nèi)存模型

• happens-before那些事兒

• 為什么說LockSupport是Java并發(fā)的基石？

總結(jié)

以上是生活随笔為你收集整理的delete语句与reference约束冲突怎么解决_mysql update语句和原数据一样会更新么的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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