一、先讲现状：哪些表是超级大表，数据量级有多恐怖
懂x帝属于内容 + UGC 双高写入媒体，分三类数据表，体量完全不在一个层级：
- 评论、车友圈、用户动态（亿级行） 每条资讯、短视频下面海量评论、回复、点赞、收藏，单逻辑表轻松破亿行，是最恐怖的大表；
- 文章 / 短视频内容库（千万级） 官方评测、车型文章、车主投稿，总量千万级，增长平缓；
- 车型、配置、参数（百万级静态字典） 基础车型数据几乎不增长，属于小表；
- 日志、行为埋点（超大规模时序数据） 用户浏览、点击、设备上报，完全不存 MySQL，直接丢 ClickHouse / 数据仓库。
行业红线：MySQL 单表超过1000 万行B + 树索引层高，随机 IO 爆炸、查询、DDL 全卡死；懂x帝不会让任何一张逻辑单表摸到这条线。
二、四层架构拆分，从根源消灭 “超大单表”（核心玩法）
1. 第一层：垂直分库（按业务拆独立 MySQL 集群）
完全隔离业务读写，互不干扰：
- 内容库：文章、视频、车型资讯（编辑后台、lf 预发共用一套拆分逻辑）
- UGC 库：评论、车友圈、点赞、收藏（写入最高频）
- 用户库：账号、手机号、登录记录
- 交易 / 线索库：4S 店报价、购车线索 好处：评论库写崩，不会影响编辑发布资讯，故障隔离； lf 预发环境同步复刻整套分库结构，预发库也是多套独立实例，和生产拆分逻辑 1:1 对齐。
2. 第二层：水平分表（解决亿级评论大表，最关键）
评论这类爆炸增长表，用分片中间件（Sharding-JDBC / 自研分片） 水平拆分：
- 分片键：
target_id（文章 / 视频 ID）哈希取模 - 一套逻辑评论表，物理拆分成64/128 张子表，均匀分散到多台 MySQL 服务器
- 单张子表严格控制在 800 万行以内，永远不触发索引性能拐点 查询逻辑：打开某条视频评论，路由只查对应分片子表，不会扫全量数据；
3. 第三层：冷热数据分离（大幅降低活跃表体量）
- 热数据：3 个月内新评论、新车友动态，存在高性能 SSD MySQL，实时读写；
- 冷数据：超过 3 个月历史评论，归档到 ClickHouse / 离线数仓，线上前端不展示、不参与实时查询； 线上活跃分片只保留近期热数据，单表压力直接砍 70%；
4. 第四层：大字段垂直分表（减少单行体积，提升缓存命中率）
评论、文章的长文本、图片链接单独拆成content_ext 表：
- comment_base：id、user_id、target_id、点赞数、状态（高频查询，行很小，大量缓存到内存）
- comment_text：id、完整文本、图片地址（低频读取，大字段单独存储） 避免一行数据过大，缓冲池存不下索引，磁盘 IO 飙升。
三、读写分离：扛住海量查询压力
每套业务库标准一主多从：
- 主库：只负责写入（发布文章、发评论、点赞）；
- 从库集群：所有页面查询、列表分页、后台报表全部走从库；
- 预发 lf 环境同样配置主从，每日同步生产全量脱敏数据，从库用来压测、验证慢 SQL； 优势：前端百万次页面查询完全不占用主库 IO，DDL 变更只影响写入，不阻塞用户浏览。
四、重点回答你最关心的：亿级大表扩字段、改结构，怎么做到不影响线上（配合 lf 预发流程）
前提：所有 DDL 变更，必须先在 www-lf 预发完整验证
lf 预发库是1:1 复刻生产分片结构、数据量、硬件磁盘介质，低配硬件靠 cgroup 限流 IO 模拟生产压力，同时回放生产 binlog 复刻并发读写，提前测出锁表、IO 打满风险。
线上分三套方案分级使用：
方案 1：MySQL8.0 INSTANT 轻量新增可空字段（首选，毫秒无锁）
ALTER TABLE comment_0 ADD COLUMN audit_tag TINYINT NULL INSTANT;仅修改元数据，不拷贝数据，千万 / 亿级分片表瞬间完成，业务零感知；
限制：不能加 NOT NULL、不能带默认值。
方案 2：必须加默认值 / 非空、改字段、新增索引（gh-ost 无锁工具）
懂x帝高并发 UGC 表统一用 gh-ost，原理：
- 伪装成 MySQL 从库拉取 binlog 同步增量，不创建触发器，几乎不损耗主库写入性能；
- 新建影子分片表，分批拷贝存量数据，自动限速、主从延迟过高自动暂停；
- 数据完全同步后，原子 RENAME 切换表，毫秒切换，无长时间锁表； pt-osc 触发器会增加主库写入压力，高并发评论库基本不用。
方案 3：极端复杂变更（删字段、改主键、大字段重构）—— 双写迁移，零风险
- 在 lf 预发全分片验证迁移脚本、数据一致性；
- 线上新建一套完整分片（comment_new_0~127）；
- 应用层双写：新增评论同时写入旧分片、新分片；
- 分批迁移历史存量，全量校验 CRC 数据一致；
- 切前端读流量到新分片，稳定运行一周后下线旧表； 全程不执行任何 ALTER 修改原线上大表，彻底杜绝锁表雪崩。
标准化变更流程（懂x帝内部规范）
- 开发在 lf 预发执行 DDL + binlog 流量回放压测，确认无 IO / 锁冲突；
- 低峰凌晨执行 gh-ost/INSTANT 变更，全程监控主库 CPU、IO、主从延迟；
- 变更完成后，lf 预发同步执行相同 DDL，保持预发与生产结构永久对齐。
五、缓存分层：90% 查询不走 MySQL，从源头降低表压力
海量数据不靠数据库硬扛，多级缓存兜底：
- 本地缓存：车型、配置字典、热门文章基础信息，应用内存缓存；
- Redis 集群分片缓存：视频首页评论、文章点赞数、分页列表，热点数据全部缓存；
- 只有缓存未命中，才穿透到 MySQL 从库； 哪怕评论表亿级，日常 90% 用户访问命中缓存，数据库压力极低。
六、时序 / 日志海量数据：直接脱离 MySQL，不用硬扛
用户浏览埋点、设备访问日志、统计指标，完全不进 MySQL：
- 实时写入 Kafka；
- 准实时落地 ClickHouse 做报表、用户行为分析；
- 离线同步 Bytelake 数据仓库做数仓统计（懂x帝二手车数仓方案）； MySQL 只存可修改、带事务的业务数据，纯流水时序数据不占用数据库分片资源。
七、落地到你企业内部系统（人事 / OEE，可直接复用这套思路）
你的 OEE 设备上报、考勤流水、培训记录未来也会变成超大表，照搬这套轻量化简化版：
- 垂直分库：人事库、生产采集库分开；
- 时序流水表（设备上报）按月水平分表；
- 冷热分离：超过 1 年采集数据归档时序库，线上只查近 3 个月；
- 所有扩字段 DDL 先在内网 hr-lf 预发全量数据压测验证；
- 大表变更统一用 gh-ost 在线无锁工具，白天业务完全不受影响；
- 高频查询数据 Redis 缓存，减少数据库并发压力。
一句话总结懂x帝海量数据库核心逻辑
- 用分库分表 + 冷热归档从根源消灭亿级超大单表，把每张物理表控制在千万行内；
- 读写分离 + 多级缓存，绝大多数查询不碰主库；
- 大表结构变更分层工具（INSTANT/gh-ost/ 双写迁移），全程不阻塞线上业务；
- www-lf 预发环境 1:1 复刻分片、数据、压力，所有高危 DDL 提前踩坑；
- 纯时序流水数据剥离 MySQL，用专业时序数仓承载，不拖累业务库。
