一、OLTP 在线业务：MySQL 绝对主力（所有用户、内容、评论、交易）

1. 招聘 JD 明确要求后端熟悉 MySQL、分库分表、gh-ost 在线改表、主从架构；
2. 评论、车友圈、文章、短视频、用户账号、经销商线索、购车报价、后台 CMS 全部跑 MySQL；
3. 架构标准：
   • 多套独立 MySQL 集群垂直拆分：用户库、内容库、UGC 评论库、交易线索库；
   • 高增长大表（评论、动态）水平分表，Sharding 分片；
   • 一主多从读写分离，查询全走从库，主库只扛写入；
   • 大表扩字段、改结构统一 gh-ost 无锁迁移（仅适配 MySQL）；
4. www-lf 预发环境：完整复刻生产 MySQL 集群、分片结构、全量脱敏数据，DDL 全部先在预发验证。

二、配套缓存层：Redis（火山引擎托管版）

车型基础数据、首页榜单、视频点赞、分页评论、会话缓存全放 Redis，90% 查询击穿不到 MySQL，扛住海量前端访问压力。

三、海量行为日志、统计、报表：ClickHouse（完全不用 MySQL）

用户浏览埋点、点击、播放时长、设备访问流水、运营统计看板，时序海量数据，不进 MySQL：

• 实时写入 Kafka → 落地 ClickHouse；
• 用来做数据分析、流量报表、用户行为画像； 这类数据写入量爆炸，MySQL 扛不住，只做离线统计，不参与线上业务读写。

四、全文检索：Elasticsearch ES

车型检索、文章全文搜索、车友圈内容检索，复杂模糊查询、多条件筛选交给 ES，MySQL 只存基础业务字段。

五、少量半结构化配置：MongoDB（极少）

早期车型复杂多层配置参数，嵌套结构多，少量配置存在 MongoDB；核心交易、评论、用户数据绝不放 MongoDB（事务、并发锁能力不足）。

六、离线数仓：Hadoop/Hive/Spark

长期归档冷数据、大数据分析、二手车市场宏观统计，和线上 MySQL 物理隔离，不影响前端访问性能。

整套分层一句话总结

1. 在线可事务、高并发读写业务（人、内容、评论、订单）：MySQL InnoDB 主库 + 读写分离分库分表；
2. 热点缓存：Redis；
3. 全文搜索：ES；
4. 海量时序日志、统计报表：ClickHouse；
5. 离线大数据归档分析：Hive/Spark；
6. 复杂嵌套配置文档：少量 MongoDB。

对应你之前关心的大表、预发环境关键点

1. 为什么懂x帝亿级评论表能稳定跑？底层是 MySQL + 水平分片 + gh-ost 无损改表；
2. www-lf 预发环境完全复刻一套 MySQL 分片集群，每日同步生产全量数据，所有 ALTER、加索引先在预发压测验证；
3. 纯流水埋点剥离 MySQL，避免海量日志拖垮业务库，和你 OEE 设备采集时序数据思路完全一致。

落地到你的企业人事 / OEE 系统参考

• 人事员工、培训课程、工单、设备基础台账 → MySQL；
• 设备秒级上报流水、历史统计报表 → ClickHouse；
• 首页菜单、课程缓存、登录会话 → Redis；
• 内网 hr-lf 预发同步一套完整 MySQL，所有扩字段、改表结构提前验证。