Should a table be split if only a particular column gets updates?
-
29-09-2020 - |
Question
I have a table in my MySQL 5.7 database, which has 9 columns. One column is an AUTO INCREMENT PRIMARY KEY
, where as the other 6 contain some data, which isn't going to be updated in a year. Now, the last 2 columns are of type JSON
and they are going to be updated frequently, multiple times in a second(could be 5 times a second, and as system scales could be much more than that).
My question is, should i split my table into 2 tables, having a one to one relationship? So that all the non changing data goes in one table and the 2 columns which are to be updated frequently go to the other table.
Solution
It depends.
Will you be accessing (SELECTing
) only the 'static' data frequently? With complex WHERE
clauses? If so, "vertical partitioning" is beneficial. It would keep the SELECTs
from interfering with the UPDATEs
.
Will the JSON
columns be large, and the 'static' columns be relatively small? If so, that adds to the argument for vertical partitioning.
When you are ready to update a JSON field, do you have the PRIMARY KEY
in hand? Searching around for which row to change may interfere with other UPDATEs
.
Sorry there is no straightforward answer; "your mileage may vary".
Rephrasing
(This discussion applies to any InnoDB table with "big" fields -- TEXT
/BLOB
/etc.)
If you usually access the big field (JSON, in your case) --> 1 table
If you often don't look at the big field --> 2 tables
If you usually do a "point query" (ie, you have the id of the row and don't need to search for it) --> 1 table
If you often check lots of rows to find the one (or few) to fetch/update --> 2 tables
But... If most rows are bigger than 8KB (and you are using InnoDB), then, because of the way 'large' columns are stored off-block, there is not much advantage for 2 tables.