Home » Mysql » Native JSON support in MYSQL 5.7 : what are the pros and cons of JSON data type in MYSQL?

Native JSON support in MYSQL 5.7 : what are the pros and cons of JSON data type in MYSQL?

Posted by: admin November 1, 2017 Leave a comment


In MySQL 5.7 a new data type for storing JSON data in MySQL tables has been
added. It will obviously be a great change in MySQL. They listed some benefits

Document Validation – Only valid JSON documents can be stored in a
JSON column, so you get automatic validation of your data.

Efficient Access – More importantly, when you store a JSON document in a JSON column, it is not stored as a plain text value. Instead, it is stored
in an optimized binary format that allows for quicker access to object
members and array elements.

Performance – Improve your query
performance by creating indexes on values within the JSON columns.
This can be achieved with “functional indexes” on virtual columns.

Convenience – The additional inline syntax for JSON columns makes it
very natural to integrate Document queries within your SQL. For
example (features.feature is a JSON column): SELECT feature->"$.properties.STREET" AS property_street FROM features WHERE id = 121254;

WOW ! they include some great features. Now it is easier to manipulate data. Now it is possible to store more complex data in column.
So MySQL is now flavored with NoSQL.

Now I can imagine a query for JSON data something like

WHERE JSON_EXTRACT(data,"$.series") IN 
SELECT JSON_EXTRACT(data,"$.inverted") 
FROM t1 | {"series": 3, "inverted": 8} 
WHERE JSON_EXTRACT(data,"$.inverted")<4 );

So I never think of a complex schema structure and foreign keys in MySQL. I store complex relations using only a few tables. Is it good? Does it break normalization. If this is possible then I guess it will act like NoSQL in a MySQL column. I really want to know more about this feature. Pros and cons of MySQL JSON data type.


The following from MySQL 5.7 brings sexy back with JSON sounds good to me:

Using the JSON Data Type in MySQL comes with two advantages over
storing JSON strings in a text field:

Data validation. JSON documents will be automatically validated and
invalid documents will produce an error. Improved internal storage
format. The JSON data is converted to a format that allows quick read
access to the data in a structured format. The server is able to
lookup subobjects or nested values by key or index, allowing added
flexibility and performance.

Specialised flavours of NoSQL stores
(Document DBs, Key-value stores and Graph DBs) are probably better
options for their specific use cases, but the addition of this
datatype might allow you to reduce complexity of your technology
stack. The price is coupling to MySQL (or compatible) databases. But
that is a non-issue for many users.

Note the language about document validation as it is an important factor. I guess a battery of tests need to be performed for comparisons of the two approaches. Those two being:

  1. Mysql with JSON datatypes
  2. Mysql without

The net has but shallow slideshares as of now on the topic of mysql / json / performance from what I am seeing.

Perhaps your post can be a hub for it. Or perhaps performance is an after thought, not sure, and you are just excited to not create a bunch of tables.


I got into this problem recently, and I sum up the following experiences:

1, There isn’t a way to solve all questions.
2, You should use the JSON properly.

One case:

I have a table named: CustomField, and it must two columns: name, fields.
name is a localized string, it content should like:

  "en":"this is English name",
  "zh":"this is Chinese name"
   ...(other languages)

And fields should be like this:


As you can see, both the name and the fields can be saved as JSON, and it works!

However, if I use the name to search this table very frequently, what should I do? Use the JSON_CONTAINS,JSON_EXTRACT…? Obviously, it’s not a good idea to save it as JSON anymore, we should save it to an independent table:CustomFieldName.

From the above case, I think you should keep these ideas in mind:

  1. Why MYSQL support JSON?
  2. Why you want to use JSON? Did your business logic just need this? Or there is something else?
  3. Never be lazy