在MySQL與PostgreSQL的對比中，PG的JSON格式支援優勢總是不斷被拿來比較。其實早先MariaDB也有對非結構化的資料進行儲存的方案，稱為dynamic column，但是方案是通過BLOB型別的方式來儲存。這樣導致的問題是查詢效能不高，不能有效建立索引，與一些文件資料庫對比，優勢並不大，故在社群的反應其實比較一般。當然，MariaDB的dynamic column功能還不僅限於非結構化資料的儲存，但不在本文進行展開。

MySQL 5.7.7 labs版本開始InnoDB儲存引擎已經原生支援JSON格式，該格式不是簡單的BLOB類似的替換。原生的JSON格式支援有以下的優勢：

• JSON資料有效性檢查：BLOB型別無法在資料庫層做這樣的約束性檢查
• 查詢效能的提升：查詢不需要遍歷所有字串才能找到資料
• 支援索引：通過虛擬列的功能可以對JSON中的部分資料進行索引

1. mysql> create table user ( uid int auto_increment, 
2.     -> data json,primary key(uid))engine=innodb; 
3. Query OK, 0 rows affected (0.01 sec) 
4. mysql> insert into user values (NULL, 
5.     -> '{"name":"David","mail":"
   [email protected]","address":"Shangahai"}'); 
6. Query OK, 1 row affected (0.00 sec) 
7. mysql> insert into user values (NULL,'{"name":"Amy","mail":"[email protected]"}'); 
8. Query OK, 1 row affected (0.00 sec) 

可以看到我們新建了表user，並且將列data定義為了JSON型別。這意味著我們可以對插入的資料做JSON格式檢查，確保其符合JSON格式的約束，如插入一條不合法的JSON資料會報如下錯誤：

1. mysql> insert into user values (NULL,"test"); 
2. ERROR 3130 (22032): Invalid JSON text: "Invalid value" at position 2 in value (or column) 'test'. 

此外，正如前面所說的，MySQL 5.7提供了一系列函式來高效地處理JSON字元，而不是需要遍歷所有字元來查詢，這不得不說是對MariaDB dynamic column的巨大改進：

1. mysql> select jsn_extract(data, '$.name'),jsn_extract(data,'$.address') from user; 
2. +-----------------------------+-------------------------------+ 
3. | jsn_extract(data, '$.name') | jsn_extract(data,'$.address') | 
4. +-----------------------------+-------------------------------+ 
5. | "David" | "Shangahai" | 
6. | "Amy" | NULL | 
7. +-----------------------------+-------------------------------+ 
8. 2 rows in set (0.00 sec) 

當然，最令人的激動的功能應該是MySQL 5.7的虛擬列功能，通過傳統的B+樹索引即可實現對JSON格式部分屬性的快速查詢。使用方法是首先建立該虛擬列，然後在該虛擬列上建立索引：

1. mysql> ALTER TABLE user ADD user_name varchar(128) 
2.     -> GENERATED ALWAYS AS (jsn_extract(data,'$.name')) VIRTUAL; 
3. Query OK, 0 rows affected (0.01 sec) 
4. Records: 0 Duplicates: 0 Warnings: 0 
5. mysql> select user_name from user; 
6. +-----------+ 
7. | user_name | 
8. +-----------+ 
9. | "Amy"     | 
10. | "David"   | 
11. +-----------+ 
12. 2 rows in set (0.00 sec) 
13. mysql> alter table user add index idx_username (user_name); 
14. Query OK, 2 rows affected (0.01 sec) 
15. Records: 2  Duplicates: 0  Warnings: 0 

然後可以通過新增的索引對使用者名稱進行快速的查詢，這和普通型別的列查詢一樣。而通過explain可以驗證優化器已經選擇了在虛擬列上建立的新索引：

1. mysql> explain select * from user where user_name='"Amy"'\G 
2. *************************** 1. row *************************** 
3.            id: 1 
4.   select_type: SIMPLE 
5.         table: user 
6.    partitions: NULL 
7.          type: ref 
8. possible_keys: idx_username 
9.           key: idx_username 
10.       key_len: 131 
11.           ref: const 
12.          rows: 1 
13.      filtered: 100.00 
14.         Extra: NULL 
15. 1 row in set, 1 warning (0.00 sec) 

可以發現MySQL 5.7對於JSON格式堪稱完美，相信PostgreSQL陣營需要尋找新的策略來“攻擊”MySQL了吧。如無意外，還是會停留在優化器這塊，畢竟這塊是目前MySQL必須要克服的最大問題，好在MySQL團隊已經在重構優化器程式碼，相信更好的優化器將會在下一個版本中全面爆發。而一大堆文件資料庫們已經哭暈在廁所了吧。