一、OLTP 在线业务：MySQL 绝对主力（所有用户、内容、评论、交易）
- 招聘 JD 明确要求后端熟悉 MySQL、分库分表、gh-ost 在线改表、主从架构；
- 评论、车友圈、文章、短视频、用户账号、经销商线索、购车报价、后台 CMS 全部跑 MySQL；
- 架构标准：
- 多套独立 MySQL 集群垂直拆分：用户库、内容库、UGC 评论库、交易线索库；
- 高增长大表（评论、动态）水平分表，Sharding 分片；
- 一主多从读写分离，查询全走从库，主库只扛写入；
- 大表扩字段、改结构统一 gh-ost 无锁迁移（仅适配 MySQL）；
- 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 物理隔离，不影响前端访问性能。
整套分层一句话总结
- 在线可事务、高并发读写业务（人、内容、评论、订单）：MySQL InnoDB 主库 + 读写分离分库分表；
- 热点缓存：Redis；
- 全文搜索：ES；
- 海量时序日志、统计报表：ClickHouse；
- 离线大数据归档分析：Hive/Spark；
- 复杂嵌套配置文档：少量 MongoDB。
对应你之前关心的大表、预发环境关键点
- 为什么懂x帝亿级评论表能稳定跑？底层是 MySQL + 水平分片 + gh-ost 无损改表；
- www-lf 预发环境完全复刻一套 MySQL 分片集群，每日同步生产全量数据，所有 ALTER、加索引先在预发压测验证；
- 纯流水埋点剥离 MySQL，避免海量日志拖垮业务库，和你 OEE 设备采集时序数据思路完全一致。
落地到你的企业人事 / OEE 系统参考
- 人事员工、培训课程、工单、设备基础台账 → MySQL；
- 设备秒级上报流水、历史统计报表 → ClickHouse；
- 首页菜单、课程缓存、登录会话 → Redis；
- 内网 hr-lf 预发同步一套完整 MySQL，所有扩字段、改表结构提前验证。
