摘要： MySQL8.0對json進行了比較完善的支援, 我們知道json具有比較特殊的儲存格式，通常存在多個key value鍵值對，對於類似更新操作通常不會更新整個json列，而是某些鍵值。 對於某些複雜的應用，json列的資料可能會變的非常龐大，這時候一個突出的問題是：innodb並不識別json型別，對它而言這些儲存統一都是LOB型別，而在之前的版本中Innodb處理LOB更新的方式是標記刪除舊記錄，並插入新記錄，顯然這會帶來一些儲存上的開銷（儘管Purge執行緒會去後臺清理），而寫入的redo log和Binlog的量也會偏高，對於超大列，可能會嚴重影響到效能。
MySQL8.0對json進行了比較完善的支援, 我們知道json具有比較特殊的儲存格式，通常存在多個key value鍵值對，對於類似更新操作通常不會更新整個json列，而是某些鍵值。
對於某些複雜的應用，json列的資料可能會變的非常龐大，這時候一個突出的問題是：innodb並不識別json型別，對它而言這些儲存統一都是LOB型別，而在之前的版本中Innodb處理LOB更新的方式是標記刪除舊記錄，並插入新記錄，顯然這會帶來一些儲存上的開銷（儘管Purge執行緒會去後臺清理），而寫入的redo log和Binlog的量也會偏高，對於超大列，可能會嚴重影響到效能。為了解決這個問題，MySQL8.0引入了LOB列部分更新的策略。
本文僅僅是筆者在理解該特性時做的一些簡單的筆記，，記錄的主要目的是用於以後如果涉及到相關的工作可以快速展開，因此比較凌亂
目前partial update需要通過JSON_SET, 或者JSON_REPLACE等特定介面來進行json列的更新，並且不是所有的更新都能夠滿足條件：
沒有增加新的元素
空間足夠大，可以容納替換的新值
但類似資料長度(10 =>更新成7=>更新成9)是允許的
下面以json_set更新json列為例來看看相關的關鍵堆疊
檢查是否支援partial update
如上所述，需要指定的json函式介面才能進行partial update
mysql_execute_command
|--> Sql_cmd_dml::execute
|--> Sql_cmd_dml::prepare
|--> Sql_cmd_update::prepare_inner
|---> prepare_partial_update
|-->Item_json_func::supports_partial_update
這裡只是做預檢查，對於json列的更新如果全部是通過json_set/replace/remove進行的，則將其標記為候選partial update的列(TABLE::mark_column_for_partial_update)， 儲存在bitmap結構TABLE::m_partial_update_columns
設定partial update
入口函式：TABLE::setup_partial_update()
在滿足某些條件時，需要設定logical diff(用於記錄partial update列的binlog，降低binlog儲存開銷):
binlog_row_value_options設定為”partial_json”
binlog 開啟
log_bin_use_v1_row_events關閉
使用row format
然後建立Partial_update_info物件（Table::m_partial_update_info)， 用於儲存partial update執行過程中的狀態
Table::m_enabled_logical_diff_columns
TABLE::m_binary_diff_vectors
TABLE::m_logical_diff_vectors
建立更新向量
當讀入一行記錄後，就需要根據sql語句來構建後映象，而對於partial update所涉及的json列，會做特殊處理：
Sql_cmd_update::update_single_table
|--> fill_record_n_invoke_before_triggers
|-->fill_record
|--> Item::save_in_field
|--> Item_func::save_possibly_as_json
|--> Item_func_json_set_replace::val_json
|--> Json_wrapper::attempt_binary_update
|--> json_binary::Value::update_in_shadow
|--> TABLE::add_binary_diff
json_wrapper::attempt_binary_update ： 做必要的資料型別檢查（是否符合partial update的條件）後，計算需要的空間，檢查是否有足夠的空閒空間Value::has_space()來替換成新值。
Value::update_in_shadow: 進一步將變化的資料儲存到binary diff物件中(TABLE::add_binary_diff)，每個Binary_diff物件包含了要修改物件的偏移量，長度以及一個指向新資料的const指標
如下例，摘自函式Value::update_in_shadow的註釋，這裡提取出來，以便於理解json binary的格式，以及如何產生Binary Diff
建立測試表：
root@test 10:00:45>create table t (a int primary key, b json);
Query OK, 0 rows affected (0.02 sec)
root@test 10:01:06>insert into t values (1, `[ "abc", "def" ]`);
Query OK, 1 row affected (0.07 sec)
json資料的儲存格式如下：
0x02 – type: small JSON array
0x02 - number of elements (low byte)
0x00 - number of elements (high byte)
0x12 - number of bytes (low byte)
0x00 - number of bytes (high byte)
0x0C - type of element 0 (string)
0x0A - offset of element 0 (low byte)
0x00 - offset of element 0 (high byte)
0x0C - type of element 1 (string)
0x0E - offset of element 1 (low byte)
0x00 - offset of element 1 (high byte)
0x03 - length of element 0
`a`
`b` - content of element 0
`c`
0x03 - length of element 1
`d`
`e` - content of element 1
`f`
更新json列的`abc`為`XY`, 則空出一個位元組出來:
root@test 10:01:39>UPDATE t SET b = JSON_SET(b, `$[0]`, `XY`);
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0
此時的儲存格式為：
0x02 - type: small JSON array
0x02 - number of elements (low byte)
0x00 - number of elements (high byte)
0x12 - number of bytes (low byte)
0x00 - number of bytes (high byte)
0x0C - type of element 0 (string)
0x0A - offset of element 0 (low byte)
0x00 - offset of element 0 (high byte)
0x0C - type of element 1 (string)
0x0E - offset of element 1 (low byte)
0x00 - offset of element 1 (high byte)CHANGED 0x02 – length of element 0
CHANGED `X`
CHANGED `Y` – content of element 0
(free) `c`
0x03 - length of element 1
`d`
`e` - content of element 1
`f`
此處隻影響到一個element，因此 只有一個binary diff
再執行更新：
UPDATE t SET j = JSON_SET(j, `$[1]`, `XYZW`)
第二個element從3個位元組更新成4個位元組，顯然原地沒有足夠的空間，但可以利用其一個element的剩餘空間
0x02 - type: small JSON array
0x02 - number of elements (low byte)
0x00 - number of elements (high byte)
0x12 - number of bytes (low byte)
0x00 - number of bytes (high byte)
0x0C - type of element 0 (string)
0x0A - offset of element 0 (low byte)
0x00 - offset of element 0 (high byte)
0x0C - type of element 1 (string)
CHANGED 0x0D - offset of element 1 (low byte)
0x00 - offset of element 1 (high byte)
0x02 - length of element 0
`X` - content of element 0
`Y` - content of element 0
CHANGED 0x04 - length of element 1
CHANGED `X`
CHANGED `Y`
CHANGED `Z` - content of element 1
CHANGED `W`
這裡會產生兩個binary diff，一個更新offset， 一個更新資料
我們再執行一條update，將字串修改成整數，這種情況下，原來儲存字串offset的位置被更改成了整數，而原來字串佔用的空間變成Unused狀態。這裡只
UPDATE t SET b= JSON_SET(b, `$[1]`, 456)
0x02 - type: small JSON array
0x02 - number of elements (low byte)
0x00 - number of elements (high byte)
0x12 - number of bytes (low byte)
0x00 - number of bytes (high byte)
0x0C - type of element 0 (string)
0x0A - offset of element 0 (low byte)
0x00 - offset of element 0 (high byte)
CHANGED 0x05 - type of element 1 (int16)
CHANGED 0xC8 - value of element 1 (low byte)
CHANGED 0x01 - value of element 1 (high byte)
0x02 - length of element 0
`X` - content of element 0
`Y` - content of element 0
(free) 0x04 - length of element 1
(free) `X`
(free) `Y`
(free) `Z` - content of element 1
(free) `W
型別從string變成int16，使用之前offset的欄位記錄int值，而原來string的空間則變成空閒狀態， 這裡產生一個binary diff。
我們再來看看另外一個相似的函式Value::remove_in_shadow，即通過json_remove從列上移除一個欄位，以下樣例同樣摘自函式的註釋：
json列的值為
{ "a": "x", "b": "y", "c": "z" }
儲存格式：
0x00 - type: JSONB_TYPE_SMALL_OBJECT
0x03 - number of elements (low byte)
0x00 - number of elements (high byte)
0x22 - number of bytes (low byte)
0x00 - number of bytes (high byte)
0x19 - offset of key "a" (high byte)
0x00 - offset of key "a" (low byte)
0x01 - length of key "a" (high byte)
0x00 - length of key "a" (low byte)
0x1a - offset of key "b" (high byte)
0x00 - offset of key "b" (low byte)
0x01 - length of key "b" (high byte)
0x00 - length of key "b" (low byte)
0x1b - offset of key "c" (high byte)
0x00 - offset of key "c" (low byte)
0x01 - length of key "c" (high byte)
0x00 - length of key "c" (low byte)
0x0c - type of value "a": JSONB_TYPE_STRING
0x1c - offset of value "a" (high byte)
0x00 - offset of value "a" (low byte)
0x0c - type of value "b": JSONB_TYPE_STRING
0x1e - offset of value "b" (high byte)
0x00 - offset of value "b" (low byte)
0x0c - type of value "c": JSONB_TYPE_STRING
0x20 - offset of value "c" (high byte)
0x00 - offset of value "c" (low byte)
0x61 - first key (`a`)
0x62 - second key (`b`)
0x63 - third key (`c`)
0x01 - length of value "a"
0x78 - contents of value "a" (`x`)
0x01 - length of value "b"
0x79 - contents of value "b" (`y`)
0x01 - length of value "c"
0x7a - contents of value "c" (`z`)
將其中的成員$.b移除掉：
UPDATE t SET j = JSON_REMOVE(j, `$.b`);
格式為：
0x00 - type: JSONB_TYPE_SMALL_OBJECT
CHANGED 0x02 - number of elements (low byte)
0x00 - number of elements (high byte)
0x22 - number of bytes (low byte)
0x00 - number of bytes (high byte)
0x19 - offset of key "a" (high byte)
0x00 - offset of key "a" (low byte)
0x01 - length of key "a" (high byte)
0x00 - length of key "a" (low byte)
CHANGED 0x1b - offset of key "c" (high byte)
CHANGED 0x00 - offset of key "c" (low byte)
CHANGED 0x01 - length of key "c" (high byte)
CHANGED 0x00 - length of key "c" (low byte)
CHANGED 0x0c - type of value "a": JSONB_TYPE_STRING
CHANGED 0x1c - offset of value "a" (high byte)
CHANGED 0x00 - offset of value "a" (low byte)
CHANGED 0x0c - type of value "c": JSONB_TYPE_STRING
CHANGED 0x20 - offset of value "c" (high byte)
CHANGED 0x00 - offset of value "c" (low byte)
(free) 0x00
(free) 0x0c
(free) 0x1e
(free) 0x00
(free) 0x0c
(free) 0x20
(free) 0x00
0x61 - first key (`a`)
(free) 0x62
0x63 - third key (`c`)
0x01 - length of value "a"
0x78 - contents of value "a" (`x`)
(free) 0x01
(free) 0x79
0x01 - length of value "c"
0x7a - contents of value "c" (`z`)
這裡會產生兩個binary diff，一個用於更新element個數，一個用於更新offset。
從上面的例子可以看到，每個Binary diff表示了一段連續更新的資料，有幾段連續更新的資料，就有幾個binary diff。 binary diff儲存到TABLE::m_partial_update_info->m_binary_diff_vectors中，
寫入logical diff
logical diff 主要用於優化寫binlog
Sql_cmd_update::update_single_table
|--> fill_record_n_invoke_before_triggers
|-->fill_record
|--> Item::save_in_field
|--> Item_func::save_possibly_as_json
|--> Item_func_json_set_replace::val_json
|-->TABLE::add_logical_diff
新的LOB儲存格式
相關程式碼：
storage/innobase/lob/*, 所有的類和函式定義在namesapce lob下面
從上面的分析可以看到，Server層已經提供了所有修改的偏移量，新資料長度，已經判斷好了資料能夠原地儲存，對於innodb，則須要利用這些資訊來實現partial update 。
在展開這個問題之前，我們先來看下innodb針對json列的新格式。從程式碼中可以看到，為了實現partial update, innodb增加了幾種新的資料頁格式：
壓縮表：
FIL_PAGE_TYPE_ZLOB_FIRST
FIL_PAGE_TYPE_ZLOB_DATA
FIL_PAGE_TYPE_ZLOB_INDEX
FIL_PAGE_TYPE_ZLOB_FRAG
FIL_PAGE_TYPE_ZLOB_FRAG_ENTRY
普通表：
FIL_PAGE_TYPE_LOB_INDEX
FIL_PAGE_TYPE_LOB_DATA
FIL_PAGE_TYPE_LOB_FIRST
我們知道，傳統的LOB列通常是在聚集索引記錄內留一個外部儲存指標，指向lob儲存的page，如果一個page儲存不下，就會產生lob page連結串列。而新的儲存格式，則引入了lob index的概念，也就是為所有的lob page建立索引，格式如下：
ref pointer in cluster record
-------
|
FIL_PAGE_TYPE_LOG_FIRST
|
FIL_PAGE_TYPE_LOB_INDEX -----------> FIL_PAGE_TYPE_LOB_DATA
|
FIL_PAGE_TYPE_LOB_INDEX -------------> FIL_PAGE_TYPE_LOB_DATA
|
... ....
Note: 本文只討論非壓縮表的場景， 對於壓縮表引入了更加複雜的資料型別，以後有空再在本文補上。
ref Pointer格式如下（和之前相比，增加了版本號）
欄位 位元組數 描述
BTR_EXTERN_SPACE_ID 4 space id
BTR_EXTERN_PAGE_NO 4 第一個 lob page的no
BTR_EXTERN_OFFSET/BTR_EXTERN_VERSION 4 新的格式記錄version號
第一個FIL_PAGE_TYPE_LOG_FIRST頁面的操作定義在 lob::first_page_t類中格式如下(參考檔案: include/lob0first.h lob/lob0first.cc)：
欄位 位元組數 描述
OFFSET_VERSION 1 表示lob的版本號，當前為0，用於以後lob格式改變做版本區分
OFFSET_FLAGS 1 目前只使用第一個bit，被設定時表示無法做partial update， 用於通知purge執行緒某個更新操作產生的老版本LOB可以被完全釋放掉
OFFSET_LOB_VERSION 4 每個lob page都有個版本號，初始為1，每次更新後遞增
OFFSET_LAST_TRX_ID 6
OFFSET_LAST_UNDO_NO 4
OFFSET_DATA_LEN 4 儲存在該page上的資料長度
OFFSET_TRX_ID 6 建立儲存在該page上的事務id
OFFSET_INDEX_LIST 16 維護lob page連結串列
OFFSET_INDEX_FREE_NODES 16 維護空閒節點
LOB_PAGE_DATA 儲存資料的起始位置，注意第一個page同時包含了lob index 和lob data，但在第一個lob page中只包含了10個lob index記錄，每個lob index大小為60位元組
除了第一個lob page外，其他所有的lob page都是通過lob index記錄來指向的，lob index之間連結成連結串列，每個index entry指向一個lob page，
普通Lob Page的格式如下
欄位 位元組數 描述
OFFSET_VERSION 1 lob data version，當前為0
OFFSET_DATA_LEN 4 資料長度
OFFSET_TRX_ID 6 建立該lob page的事務Id
LOB_PAGE_DATA lob data開始的位置
lob index entry的大小為60位元組，主要包含如下內容(include/lob0index.h lob/lob0index.cc):
偏移量 位元組數 描述
OFFSET_PREV 6 Pointer to the previous index entry
OFFSET_NEXT 6 Pointer to the next index entry
OFFSET_VERSIONS 16 Pointer to the list of old versions for this index entry
OFFSET_TRXID 6 The creator transaction identifier.
OFFSET_TRXID_MODIFIER 6 The modifier transaction identifier
OFFSET_TRX_UNDO_NO 4 the undo number of creator transaction.
OFFSET_TRX_UNDO_NO_MODIFIER 4 The undo number of modifier transaction.
OFFSET_PAGE_NO 4 The page number of LOB data page
OFFSET_DATA_LEN 4 The amount of LOB data it contains in bytes.
OFFSET_LOB_VERSION 4 The LOB version number to which this index entry belongs.
從index entry的記錄格式我們可以看到 兩個關鍵資訊：
對lob page的修改會產生新的lob page（“lob::replace()”） 和新的lob index entry
lob page no及其資料長度，據此我們可以根據修改的資料在json column裡的offset，通過lob index快速的定位到其所在的lob page
每個lob page的版本號: 為了實現mvcc多版本，使用者執行緒先從undo log中找到對應版本的clust record，找出其中儲存的版本號v1，然後在掃描lob index時，如index entry中記錄的版本號<= v1，則是可見的，如果> v1, 那麼就需要根據OFFSET_VERSIONS連結串列，找到對應版本的index entry，並
根據這個老的Index entry找到對應的lob page, 如下所示：
EXTERN REF (v2)
|
LOB IDX ENTRY (v1)
|
LOB IDX ENTRY(v2) —–> LOB IDX ENTRY(v1)
|
LOG IDX …(v1)
多版本讀判斷參考函式 `lob::read`
lob更新lob::update: 根據binary diff，依次replace
Note： 不是所有的lob資料都需要partial update, 額外的lob index同樣會帶來儲存開銷，因此定義了一個threshold（ref_t::LOB_BIG_THRESHOLD_SIZE），超過2個page才去做partial update; 另外row_format也要確保lob列不儲存列字首到clust index ( ref btr_store_big_rec_extern_fields)
寫入binlog
在更新完一行後，對應的變更需要打包到執行緒的cache中(THD::binlog_write_row() –> pack_row())， 這時候要對partial update進行特殊處理，需要設定特定選項:
binlog_row_image = MINIMAL;
binlog_row_value_options=PARTIAL_JSON
如上例第一個update產生的binlog如下：
UPDATE t SET b = JSON_SET(b, `$[0]`, `XY`);
binlog:
`/*!*/;
### UPDATE `test`.`t`
### WHERE
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### SET
### @2=JSON_REPLACE(@2, `$[0]`, `XY`) /* JSON meta=4 nullable=1 is_null=0 */
由於存在主鍵，因此前映象只記錄了主鍵值，而後映象也只記錄了需要更新的列的內容，對於超大Json列，binlog上的開銷也是極小的，考慮到binlog通常會成為效能瓶頸點，預計這一特性會帶來不錯的吞吐量提升
原文連結