MYSQL 5.7中的原生JSON支持：MYSQL中的JSON数据types有哪些优缺点？
在MySQL 5.7中，添加了用于在MySQL表中存储JSON数据的新数据types。 这显然是MySQL的一个很大的变化。 他们列出了一些好处
文档validation – 只有有效的JSON文档可以存储在JSON列中，因此您可以自动validation您的数据。
高效的访问 – 更重要的是，当您将JSON文档存储在JSON列中时，不会将其存储为纯文本值。 而是以优化的二进制格式存储，以便更快地访问对象成员和数组元素。
性能 – 通过在JSON列中的值上创build索引来提高查询性能。 这可以通过虚拟列上的“function索引”来实现。
方便性 – JSON列的附加内联语法使得在SQL中集成文档查询变得非常自然。 例如（features.feature是一个JSON列）：
SELECT feature->"$.properties.STREET" AS property_street FROM features WHERE id = 121254;
哇 ！ 他们包括一些伟大的function。 现在操作数据比较容易。 现在可以在列中存储更复杂的数据。 所以MySQL现在用NoSQL来调味。
现在我可以想象一个类似于JSON数据的查询
SELECT * FROM t1 WHERE JSON_EXTRACT(data,"$.series") IN ( SELECT JSON_EXTRACT(data,"$.inverted") FROM t1 | {"series": 3, "inverted": 8} WHERE JSON_EXTRACT(data,"$.inverted")<4 );
所以我从来没有想到在MySQL中有一个复杂的模式结构和外键。 我只用几张表来存储复杂的关系。 好吗？ 它是否破坏正常化？ 如果这是可能的，那么我想它会在MySQL列中像NoSQL一样行事 。 我真的很想了解这个function。 MySQL JSON数据types的优缺点
以下从MySQL 5.7带来的性感与JSON听起来不错，
在MySQL中使用JSON数据types比在文本字段中存储JSONstring具有两个优点：
数据validation。 JSON文件将被自动validation，无效的文件将产生一个错误。 改进了内部存储格式。 JSON数据转换为允许以结构化格式快速读取数据的格式。 服务器能够通过键或索引来查找子对象或嵌套值，从而增加了灵活性和性能。
…
NoSQL存储（文档数据库，键值存储和graphics数据库）的特殊风格可能是其特定用例的更好select，但添加此数据types可能允许您降低技术堆栈的复杂性。 价格是耦合到MySQL（或兼容）数据库。 但是这对许多用户来说是一个非问题。
注意关于文件validation的语言，因为这是一个重要的因素。 我猜测需要进行一系列的testing来比较两种方法。 这两个是：
- 带有JSON数据types的Mysql
- Mysql没有
从我所看到的，到目前为止，networking上的mysql / json / performance的主题已经很less了。
也许你的post可以成为它的中心。 或者，也许性能是一个想法后，不知道，你只是兴奋，不创build一堆表。
最近我遇到了这个问题，总结了以下经验：
1，没有办法解决所有问题。 2，您应该正确使用JSON。
一例：
我有一个名为： CustomField的表，它必须有两列： name ， fields 。 name是一个本地化的string，它的内容应该像：
{ "en":"this is English name", "zh":"this is Chinese name" ...(other languages) }
fields应该是这样的：
[ { "filed1":"value", "filed2":"value" ... }, { "filed1":"value", "filed2":"value" ... } ... ]
正如你所看到的， name和fields都可以保存为JSON，并且工作正常！
但是，如果我经常用这个name来search这个表，我该怎么办？ 使用JSON_CONTAINS ， JSON_EXTRACT …？ 显然，把它保存为JSON不是一个好主意，我们应该把它保存到一个独立的表： CustomFieldName 。
从上面的案例来看，我认为你应该牢记这些想法：
- 为什么MYSQL支持JSON？
- 为什么你要使用JSON？ 你的业务逻辑是否需要这个？ 还是还有别的？
- 永远不要懒惰
谢谢
