MySQL 8.0 supports a native JSON data type that is validated and stored in a binary optimized format. It is useful in cases where schema flexibility is required or when semi-structured data needs to be stored without rigid normalization.

When JSON Is Preferable Over Normalized Tables

1
When storing semi-structured or flexible data where fields vary between rows (e.g., dynamic attributes, settings, metadata).
2
When application-layer objects map directly to JSON, reducing transformation overhead.
3
When you need rapid schema evolution without altering table structures.
4
When storing large, nested objects that would otherwise require multiple join-heavy relational tables.
5
When performance favors fewer joins over strict normalization, especially in read-heavy workloads.

When You Should Not Use JSON

1
When strong relational integrity, foreign keys, or normalization are required.
2
When you frequently filter or aggregate on deeply nested fields (relational structures perform better).
3
When large JSON fields lead to unnecessary data transfer and slower updates.

Internal Storage Behavior of JSON in MySQL 8.0

1
JSON is stored in a binary format (not plain text) optimized for lookup.
2
The structure includes metadata such as element types and offsets for fast access.
3
MySQL validates JSON on insert/update — invalid JSON is rejected.
4
Large JSON values may be stored off-page by InnoDB, similar to TEXT/BLOB.
5
Binary storage allows MySQL to parse only required portions instead of scanning entire JSON strings.

Indexing Behavior in JSON Columns

1
MySQL cannot directly index an entire JSON document.
2
Instead, you index generated (virtual or stored) columns extracted from JSON paths.
3
These generated columns can be indexed normally (BTREE).
4
MySQL 8.0 also supports functional indexes, allowing indexing of expressions like JSON_EXTRACT(data, '$.user.id').
5
Only the generated/indexed part is searchable using the index; the rest of the JSON remains unindexed.
6
No full-document JSON indexing exists in MySQL (unlike PostgreSQL’s GIN indexes).

Example: JSON Column with Generated Column Index

This allows MySQL to index and query details->'$.customer.id' efficiently while keeping the flexibility of JSON.

Performance Considerations

1
JSON values consume more storage than normalized columns due to metadata overhead.
2
Updates to JSON columns rewrite the entire JSON document, not just changed parts.
3
Querying non-indexed JSON paths is slower because MySQL must scan the JSON document.
4
Indexes on generated columns greatly improve performance but require planning.