MySQL Json有哪些缺點

導讀	今天的分享是再批 json, 去年分享過因為 mysql json 導致的故障，今天的 case 其實是去年的姊妹篇，原理一模一樣。上一篇弱智的 MySQL NULL, 居然有小夥伴留言說，在業務中依賴 NULL 使聯合索引不唯一的特性，比如有的使用者就要多條記錄，有的僅一條。我看了差點一口老血噴出來，把業務邏輯耦合在 DB 中這樣真的合適嘛? 要是外包另當別論，正常專案誰接手誰倒黴。

今天的分享是再批 json, 去年分享過因為 mysql json 導致的故障，今天的 case 其實是去年的姊妹篇，原理一模一樣。有兩個原因不建議用 json:

• Table Schema 就是強一致的，約束開發不要亂搞，json 這種弱約束的就是開後門，時間一長 json 欄位就成了下水道
• MySQL JSON 很垃圾，5.7 系列都有效能問題，測試 8.0 好很多。強烈建義大家，使用前壓測一下

上面提到的兩點有爭議?有爭議就對了，一致認同是垃圾的東西誰會討論它呢？

實現

JSON 有兩種表示方法：文字可讀的在 mysql 中對應 json_dom.cc, binary 二進位制表示的對應 json_binary.cc

If the value is a JSON object, its binary representation will have a 
header that contains: 
 
- the member count 
- the size of the binary value in bytes 
- a list of pointers to each key 
- a list of pointers to each value 
 
The actual keys and values will come after the header, in the same 
order as in the header. 
 
Similarly, if the value is a JSON array, the binary representation 
will have a header with 
 
- the element count 
- the size of the binary value in bytes 
- a list of pointers to each value

原始碼中註釋也寫的比較清楚，二進位制分成兩部分 header + element. 實際上 mysql 只是 server 識別了 json, 各個儲存引擎仍儲存的二進位制 blob

換句話說，底層引擎對 json 是無感知的，就是一條資料而己

json-function-reference[1] 官方有好多在 server 層操作 json 的方法，感興趣的可以看一下

MySQL Client 讀取 json 時是 json_dom 呼叫 wrapper_to_string 方法，序列化成可讀格式資料

寫入 json 時，是由 json_binary 呼叫 serialize_json_value 方法，序列化成上面圖表示的 binary 資料，然後由引擎層儲存成 blob 格式

去年故障也有服務端的問題：載入單條資料失敗主動 panic, 坑人不淺 (理由是資料不一致，寧可不對外提供服務，問題是那條資料恰好是重不重要的一類)。所以這個故事告訴我們: 線上服務的可用性，遠高於資料一致性

慢的原因是 wrapper_to_string 遇到 json array 特別多的情況下反覆 mem_realloc 建立記憶體空間，導致效能下降

其實去年沒有 fix 完整，最近發現寫入也有類似問題，只不過是 serialize_json_value 寫入儲存引擎前反覆 mem_realloc 造成超時。這時前端頁面發現寫入超時了，(人工)重試繼續寫入 json 資料

恰好趕上聯合索引中有 NULL 欄位，由此引出了唯一索引不唯一的現象。那怎麼解決呢?前端按鈕 cooldown 治標不治本，sql 執行 12s 前端肯定又點選提交了，治本還得升級 mysql 8.0 並且移除 NULL 欄位, 那會不會又引入其它問題呢?

專案初期做了錯誤的決定，後人很容易買單。希望我們踩到的坑，能讓你決定使用 json 前猶豫幾秒鐘 ^^

在測試機上發現 8.0 是 ok 的，沒有效能問題，檢視提交的 commit, 2016 年就有人發現並 fix 了，不知道有沒有 back port 到 mysql 5.7 那幾個版本

commit a2f9ea422e4bdfd65da6dd0c497dc233629ec52e 
Author: Knut Anders HatlenDate:   Fri Apr 1 12:56:23 2016 +0200 
 
    Bug#23031146: INSERTING 64K SIZE RECORDS TAKE TOO MUCH TIME 
 
    If a JSON value consists of a large sub-document which is wrapped in 
    many levels of JSON arrays or objects, serialization of the JSON value 
    may take a very long time to complete. 
 
    This is caused by how the serialization switches between the small 
    storage format (used by documents that need less than 64KB) and the 
    large storage format. When it detects that the large storage format 
    has to be used, it redoes the serialization of the current 
    sub-document using the large format. But this re-serialization has to 
    be redone again when the parent of the sub-document is switched from 
    small format to large format. For deeply nested documents, the inner 
    parts end up getting re-serializing again and again. 
 
    This patch changes how the switch between the formats is done. Instead 
    of starting with re-serializing the inner parts, it now starts with 
    the outer parts. If a sub-document exceeds the maximum size for the 
    small format, we know that the parent document will exceed it and need 
    to be re-serialized too. Re-serializing an inner document is therefore 
    a waste of time if we haven't already expanded its parent. By starting 
    with expanding the outer parts of the JSON document, we avoid the 
    wasted work and speed up the serialization.

參考資料

[1]json-function-reference: https://dev.mysql.com/doc/refman/5.7/en/json-function-reference.html

原文來自：