大家好呀，我是小米，一個31歲還保持好奇心、天天折騰新技術的程序員。

上周去幫一個朋友做面試輔導，結果第一道題就把他卡住了。

面試官問：“我們系統有一張大表，字段特別多，性能慢，你會怎么優(yōu)化？”

朋友理直氣壯地說：“我會建索引！”

面試官笑了笑又追問：“那如果字段太多，索引也沒法解決呢？”

他愣住了。

于是我在旁邊小聲提醒他一句：“垂直分區(qū)啊，哥！”

他回去查了一天，才發(fā)現這個詞在不同文章里講法千奇百怪，什么“縱向切表”“按模塊拆庫”“字段分表”……越看越亂。

今天，小米就帶你一口氣講清楚：

垂直分區(qū)到底是啥？它和水平分表有什么區(qū)別？在MySQL8.x里又該怎么做？

1.故事開始：那張讓人窒息的“用戶表”

先來看看這張表，你是不是也見過這樣的：

| id | username | password | email | phone | avatar | bio | last_login | login_ip | create_time | update_time | role | status | address | hobby | login_count | last_device | ... |

沒錯，這就是那種“全能用戶表”，把所有字段都往里面塞。

一查一堆字段，幾十個列，有的存字符串，有的存 JSON，部分字段甚至幾乎不用。

結果呢？

• 查詢慢：SELECT * 拉太多無用字段；
• 索引失效：字段太多，覆蓋索引成本高；
• I/O 飆升：每次都要掃描大塊數據；
• 內存 Cache 命中率下降。

這時候，就輪到我們的主角登場了——垂直分區(qū)。

2.什么是垂直分區(qū)？

一句話解釋：

垂直分區(qū)，就是把一張字段很多的大表，按字段維度拆成多張“小表”。

比如，我們把剛才那張“全能用戶表”拆開：

• user_base：存放基礎信息（id, username, password, email, phone）
• user_profile：存放擴展信息（avatar, bio, hobby, address）
• user_login：存放登錄行為（last_login, login_ip, last_device, login_count）

它像是把一個超級胖子切成三塊肌肉勻稱的運動員。這樣做的好處很多：

• 減少I/O開銷：查詢時只掃描需要的字段。
• 提升緩存命中率：更小的數據頁，更高效的內存利用。
• 安全與權限隔離：敏感數據（密碼）單獨存儲、權限控制。
• 維護更方便：表結構清晰，字段職責單一。

3.垂直分區(qū) vs 水平分表

經常有同學搞混：分區(qū)、分表、分庫到底是啥？

來，小米給你一個最通俗的比喻：

一句話總結：

垂直分區(qū)解決“列太多”的問題，水平分表解決“行太多”的問題。

4.那垂直分區(qū)該怎么做？

1）分析字段使用頻率

看看哪些字段經常查、哪些很少查。

比如登錄時只查用戶名和密碼，那擴展信息完全沒必要在同一張表。

2） 按功能拆表

通常我們會這樣拆：

• 基礎表（Core Table）：最核心、最常訪問的數據
• 擴展表（Extension Table）：低頻字段或不定期更新的數據
• 日志表（Behavior Table）：行為類或統計類數據

3）用主鍵關聯

一般都會用同一個主鍵，比如用戶id。

圖片

當然，頻繁 join 的話也要注意性能，可以通過緩存或視圖優(yōu)化。

4）保證事務一致性

垂直分區(qū)后，多表更新可能帶來事務問題。解決方案：

• 使用同一個數據庫事務；
• 或者用消息隊列異步同步非核心表。

5.MySQL8.x 有什么新變化？

MySQL8 對存儲引擎、優(yōu)化器、JSON字段都做了大升級，這對垂直分區(qū)來說是大利好。

1）JSON字段更靈活

如果只是部分可選字段，可以考慮存儲 JSON，而不是立即分表。MySQL8 的 ->> 操作符、索引支持已經非常完善。

2）表分區(qū)（Partitioning）更智能

雖然垂直分區(qū)是邏輯層面的拆分，但 MySQL8 的原生分區(qū)功能也能配合使用，比如按用戶ID做 range 或 hash 分區(qū)，查詢效率更高。

3）CTE + 窗口函數輔助查詢u

在多表 join 后，使用窗口函數做排序、聚合比以前方便太多，性能也更好。

6.實踐案例：我們怎么救活一張“胖表”

還記得開頭那張“全能用戶表”嗎？

我們團隊曾經有一張類似的“產品表”，字段多達 80 個，查詢慢得離譜。

我們做了兩步：

1）拆表：

• product_core：核心字段（id, name, price, stock）
• product_detail：擴展字段（description, spec, image_url）
• product_stat：統計字段（view_count, sale_count）

2）引入緩存：

• 核心字段放 Redis（快速響應）
• 擴展字段懶加載

3）最終結果：

• 查詢性能提升 3 倍
• CPU 使用率下降 40%
• 頁面加載速度從 800ms 降到 200ms

更關鍵的是，業(yè)務邏輯更清晰了。新同事上手時不再被那堆字段嚇到。

7.面試官喜歡追問的 3 個細節(jié)

面試中，答完“垂直分區(qū)”后，面試官可能會追問：

1）分區(qū)后會不會增加 JOIN？性能會不會更差？

回答：短期內 JOIN 會增加，但長期來看查詢集中、緩存命中率提升，整體性能更好。

2）垂直分區(qū)和微服務有什么關系？

回答：垂直分區(qū)是數據庫層面的拆分，微服務是應用層面的拆分。兩者理念相通，但作用層次不同。

3）什么時候不該垂直分區(qū)？

回答：如果字段少、訪問場景簡單，就不要拆。過度設計會適得其反。

8.總結

今天，小米和你聊了一個看似簡單但常被誤解的概念——垂直分區(qū)。

它不是“玄學調優(yōu)”，而是一種結構化思維：把一個復雜臃腫的表，拆成多個專注的表，讓查詢更快、邏輯更清晰。

記住這句話：垂直分區(qū)讓數據庫更“輕”，也讓開發(fā)更“爽”。

最后，留一個小問題給你：如果有一張訂單表，既要頻繁查訂單狀態(tài)，又要保存歷史操作日志，你會怎么分區(qū)？