开发在使用MySQL中,建立比较大的VARCHAR字段来存储SQL执行的语句或者利用MYSQL 来存储什么VARCHAR(1000) VARCHAR(2000) 之类的事情比比皆是，实际上存储超高的字符的字段在MYSQL中是不提倡的,本来可以是JSON格式的数据，非要变成普通字段存储到MYSQL中，或者使用各种怪异的如下图那样的数据存储方式,有必要这样一根筋的这样处理字符吗？实际上MYSQL8本身支持JSON类型的数据输入,并且很容易处理这些信息

细想有必要写一期关于MYSQL 8 如何处理较长字段的问题，在根据需求的基础上怎么能更灵活.（当然优化的还需要一期）

JSON 数据格式是开发中通用的数据交流的一种方式,之前XML 是常用的一种方式,这里并不是说MYSQL处理JSON很OK,而是说,中小批量的数据在MYSQL存储时候,遇到一些比较难以处理的长字段,可以使用JSON, 这里还是建议大量的JSON数据,还是要使用MONGODB来处理,一定是稳稳当当,性能不能再好了(当然你需要知道优化点和相关的MONGODB的一些知识).所以使用MYSQL 提供的JSON TYPE 来存储数据的好处必须要讲讲

1 使用MYSQL 的JSON TYPE 来存储数据,可以直接判断你的数据的格式是不是对的. 举例你一个比较长的字段，还需要很多特殊的符号，如果你不事先判断，输入字符的正确性，等到输入的时候就会报错，那应该是很尴尬的情况。

别问我为什么这样说，因为就有这样的在输入格式错误后，问，你的MYSQL是怎么回事？

2 使用JSON格式来存储数据,提取的时候不需要将整条数据读取到程序内存,在处理,可以将部分内容读入到内存，在进行处理，如果你的是varchar(1000) 2000 那就.......   （数据库原理就不讲了，数据到底都在哪里处理，那样的处理方式，速度能快吗）

那我们实践一下，建立一个表,并且存储同样的数据,用两种方式varchar 和 json的方式,来比较一下.

先创建一个,存储标准VARCHAR 和 JSON 两种数据TYPE 不同的字段

然后我们尝试去插入数据.

insert into Json (id,select_json,select_varchar) values (7,'{"sql":"select * from ttt where select_json like \'%\';"}',"select * from ttt where select_json like \'%\';");

写到这里估计有开发的同学就该说, 切,有什么不同不还是和我一样.  呵呵那我们就来论论.

1  格式化标准化特性

在输入数据的时候,如果是VARCHAR 类型的情况下,是没有函数判断你输入的格式是否是正确的, 而如果使用了JSON 格式情况下,是有函数来判断你输入的数据,至少是格式是不是正确. 注意MYSQL的版本需要8.03以上 老版本有问题

我们通过上面的展示可以很清楚的一点是,如果书写有问题,复杂的字段无法插入, JSON_OBJECT 是可以提前给你判断你的数据是不是正常的.

我们其实就可以通过这样的手段,提前判断数据是不是正常能输入到数据库表中,而不是在输入中报错.

2  灵活性

在MYSQL 中老是有一些顽固分子, VARCHAR (500), VARCHAR(1000)一片片的, 倒是这些数字不花钱,在MYSQL中看到这些数字,这里不想用MYSQL的一些原理来arguement,反倒是我想从开发的角度,来说说咱们的"多态性",到底怎么融合进来,到底想怎样?

1 类似于VARCHAR这样的设置 500  1000 你一定是预留了最大量, 说明你存的值其实你也不知道准确的大小.这又引出另一个问题,字段是否可以有更多的灵活性，和扩展性。

我们来试试到底是你 500 1000的好,还是我灵活性的香

需求:  一个comments的字段, 也就是可以输入一些注释信息, 如果注释信息有新的需求怎么办，比如你的comments 一直输入用户的，赞赏的信息，抱怨的信息，或者投诉你的信息，这些都叫comments

我们来用两种方式来存你的信息， varchar和 JSON TYPE

insert into comments (id,comments,comments_json) values (1,"我不满意你的服务",'{"complain":"我不满意你的服务"}');

那到底上边表达了一个什么含义,如果你用固定的方式来输入信息,他就是一个"死" 的信息. 如果你用后者,那天需求方告诉你,来给我统计一下这一天到底有多少抱怨的信息, 或者有多少个表扬, 你是否还需要修改数据库的表的结构,如果这是你的程序是不是要问问，你的扩展性呢，数据库的信息为什么就是死的呢，如果给自己预留余地，多一个灵活处理的方式， 要不然你打算用几个字段来完成需求的变化呢?

上图，可以输出你要的信息,同时也可以进行相关信息的一般化统计.

那如果我们在改变需求,需求变成,需要在满意的后面带输入,服务人员的名字, 此时如果你还按照原来的思路走, 加字段,改程序, OMG 我都替你累的慌

所以一个字段也能玩出花样, 如果你肯思考，深入需求本身如果能发掘一些可能会变化的字段，那MYSQL JSON TYPE 其实也是体现你开发人员的在数据表方面设计能力一种体现 ，So please be make a special someone , could you?