mysql如何使用json便于开发?
如题，用上json数据类型除了不用频繁因为业务变化变更表结构以及json部分更新功能外还有什么优点呢？有什么奇淫技巧吗？
程序员
没实际用过，自行脑补一些优缺点，先说优点：
1、看起来很符合潮流啊（实际上这点并没有什么卵用……）
2、不用因为需求变化而变更表结构，这个在项目初期需求每天一小改、3天一大改的时候很有用，便于快速出功能、上线发布也方便
3、在某些场景下和前端交互会变得更方便
4、开发快，因为不需要写SQL一个字段一个字段插入了，最少的情况下只要2个字段：id主键、一个json字段，嗯，应该是能比写10个字段要快一点的，更何况实际业务往往远不止10个字段
再脑补一些缺点：
1、几乎完全没有数据库可移植性了啊有木有？当然，如果你就铁了心吊死在MySQL一棵树上就当我没说
2、查询效率应该是比不过一个一个字段的，尤其是数据量上去的时候（这点完全自行脑补，没有任何数据、资料支撑） 【查询效率很慢】
3、某种程度上是对代码要求更高了，因为一个一个字段的时候，数据库表结构还可以作为脏数据的最后一道防线，改成json之后这道防线就没了，得完全靠代码逻辑做数据正确性校验了
【代码要求更高】
从版本5.7开始，Mysql支持json了。
本人的做法是，存储过程的输入输出，都用json解决。尤其是存储过程可以返回多行，这个只能用Json解决。
比如
create function myfunc(p json) returns json
1、 版本5.7以前的function,是无法返回多行数据的，通过json，完美解决；以往返回多个参数是依靠在procedure里定义多个out参数实现，现在也可以在function里通过returns json优雅地替代。
2、传入的参数p，用json后大大增加了灵活性。比如我们要增加一个参数，以往只好修改myfunc的定义，并在所有的调用处一一更改。而现在用了json后，myfunc的参数列表不用改了，调用处就（可能）不用动。
谢邀
json作为一种自带结构的文本使得结构信息与可以与数据库解耦。
这句话稍微有点绕口，我们慢慢解释。
首先在不使用json的时候，如果我们要设计一个User对象。则数据表中的信息如下：
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) NOT NULL, `email` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`) );
那我们设计的这个系统的User的结构信息是这样传递的：
· 表现层（html/css/anjular/reace/vue……）：根据需求展示用户对象各个属性
· 模型层（java/php/c++/pyhton……）：处理用户对象
· DAO层（Mybatis/Hibernate……）:完成对象关系的映射
· 持久层(MySql/SqlServer……):对各个字段进行存储
因此我们可以看到，在这个系统中，User对象的结构信息是从表现层到持久层是完全贯通且一致的。这样的优点是提高了一致性，使得代码更容易阅读。但有一个重要的问题：耦合太高，扩展不不友好。
假设我们要增加给User对象增加一个属性age。那我们各个层都要进行修改，例如数据库层结构需要修改为：
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) NOT NULL, `email` varchar(255) DEFAULT NULL, `age` int(11) DEFAULT NULL, PRIMARY KEY (`id`) );
同时，其他各层都要进行修改。
而引入json进行存储之后。假设我们将主要信息字段id、name字段进行保留，而次要信息字段转为json。则数据表中的信息变为：
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) NOT NULL, `detail` json(255) DEFAULT NULL, PRIMARY KEY (`id`) );
对于已经放入detail中的次要信息而言，User的结构信息是这样传递的：
· 表现层（html/css/anjular/reace/vue……）：根据需求展示用户对象各个属性
· 模型层（java/php/c++/pyhton……）：进行json结构与模型的映射
· DAO层（Mybatis/Hibernate……）:无需完成属性与字段的映射
· 持久层(MySql/SqlServer……):无需了解字段详情
这样，使得User的次要结构信息可以与数据库解耦。当User中再增加一个属性age时，我们只需要在模型层增加一个age属性，甚至连序列化操作都不需要变动就可以直接在表现层进行使用。
NoSql数据库中的文档数据库便多用json进行数据存储，来实现与对象结构的解耦。而Mysql中使用json类型，其实是向这种方式的一种靠拢。我们可以：
· 将经常查询的属性采用独立字段
· 将不经常查询且变动频繁的字段存入json中
从而实现运行效率和可扩展性之间的平衡。
用json代替数据库的字段来实现“解耦”是非常可疑的。
数据库之上，愿意用json在层之间传递是程序员自己的事；
而在数据库里，把age存到json里，看不到任何好处。比如按照age排序咋实现？
所以，在设计时要将这样的字段独立出来。而将一些经常变动，但是又不会独立查询的字段放到json中。
偶尔查询比较复杂，只能用“like”语句了。所以里边还是尽量放不经常查询的字段。
举个例子，备注信息就可以放在里边，而且对于不同的人，备注信息是不同的，有的人备注的是家庭住址，有的人备注的是毕业学校，有的人备注的是常用联系人。。。有的人备注的是前面的一项或者多项。所以这里边的字段很少是作为查询条件出现的。
postgresql json可作为查询条件
是的，听说pq很强而且纯开源
如果只是存储，那和text类型没什么区别。关键是要支持json函数操作。
推荐个我自己的免费视频：
MySQL 8.0新特性
http://www.imooc.com/learn/1102
使用Json是把校验字段类型的工作移动到了应用，嗯，反而增加了工作量。
还是不建议直接用mysql存储JSON，主要是出于扩展性的考虑
最大的好处就是master-detail数据可以一次查询出来，既不需要join，也不需要分两次查询。
json也是key—value结构。只不过是用{}和，分隔的key和value。mysql是以表格储存数据单位的。
以表格储存数据，一个key可以对应多个value，就是为了避免key值重复问题，减少数据重复。
mongodb是完全用key—value储存的，但和json有一些不同。如果你想用内存关系型数据库，mongodb不一定是好的选择，只不过mongodb提供了很多http接口和rpc接口，实现了分布式数据储存。
mysql用key—value储存，还比不过mongodb。
主要是mysql的ACID上完备有众多库支持，mongodb的4.0版本才支持，不想要引入新东西
别把NoSQL的思想用在RDBMS上
你会后悔的
我们一般在mysql之外做json封装给前端，没必要底层就开始封json对象，各自有专攻。