JSON 列是否應該與 MySQL 中的寬表分開？
JSON 的儲存方式類似於LONGTEXT 數據類型。MySQL 文件建議 TEXT 數據類型：
如果表包含名稱和地址等字元串列，但許多查詢不檢索這些列，請考慮將字元串列拆分到單獨的表中，並在必要時使用帶有外鍵的連接查詢。當 MySQL 從行中檢索任何值時，它會讀取包含該行的所有列（可能還有其他相鄰行）的數據塊。保持每行較小，只包含最常用的列，可以讓更多的行適合每個數據塊。這種緊湊的表減少了常見查詢的磁碟 I/O 和記憶體使用。
我有一張桌子
- 整數主鍵
- 20 列（主要是整數，一些 VARCHAR <= 191 個字元）
- 100,000 行
- 一個 VARCHAR(1000) 列
- 2 個 JSON 列
JSON 和 VARCHAR(1000) 列永遠不會被索引或過濾。僅在使用 pimary 鍵作為索引時讀取整行以用於數據顯示目的時才會讀取它們。JSON 列將始終保持在 3000 個字元以下。
該表每天更新，每天不到 10 次。
如果我從文件中獲得建議，我應該將 JSON 列分開。我還應該分開 VARCHAR(1000) 嗎？
在我的案例中處理兩個單獨的表的額外開發工作是否合理？
我問，因為我從來不知道如何有效地儲存 JSON 數據類型。它是否應該始終存在於經常更新的事實表之外？還是我只是過早地優化？
您從文件中引用的建議很舊，可能僅適用於 MyISAM 表。
對於 InnoDB 表，您可以讓查詢跳過讀取長數據類型（TEXT/BLOB/VARCHAR/JSON），只需從選擇列表中省略它們即可。
也就是說，不要使用
SELECT *，而是僅按名稱選擇要讀取的列。InnoDB 將跳過讀取從選擇列表中省略的長列的額外頁面。這對您來說可能是一個足夠的優化，並且不需要您拆分錶。誠然，如果合適的話，InnoDB 可以將短字元串與行的其餘部分儲存在同一頁上。也就是說，如果您有一個 JSON 列，但在給定的行上，它恰好足夠短以適合與相應行的其他列在同一頁面中，然後 InnoDB 將它們儲存在一起。
因此，確實存在這樣的場景，其中可能需要將 JSON 列分離到自己的表中，以獲得最後 0.0001% 的優化。但是您還沒有描述您正在以需要這樣做的規模運營。
你過早地優化。這幾乎是根據定義，如果您沒有實際測量性能以表明您有與將列儲存在一起的問題，並且替代設計解決了該問題。
電腦科學是一個科學領域是有原因的。您應該像科學家一樣思考，並進行實驗以測量兩種表格設計的性能。然後你就會知道你沒有過早地優化。