目录整体库容量MySQL各表体量排序最大表一定是【充电实时流水 / 充电明细表】1、充电明细表 charge_detail ——最大表2、充电订单主表 charge_order业务订单3、订单计费分片 / 计价日志 charge_bill_item4、设备状态日志 device_status_log5、用户表、场站、充电桩基础表6、告警记录表 alarm_record总结核心结论中型生产落地方案面试可直接背诵的量化话术定义中型场站几十两三百座充电桩 500‑3000 枪日充电订单 3 千2 万单用户数万级别SpringCloud 微服务MySQL 主库冷热分离配合 ES 存明细。整体库容量MySQL全量 MySQL含历史不做归档80GB‑250GB如果做冷热归档历史充电明细迁移归档 / ES活跃库20‑60GB真实生产不会把几年全部充电流水都留在 MySQL 主库超过 6‑12 个月明细一般会归档。各表体量排序最大表一定是【充电实时流水 / 充电明细表】1、充电明细表charge_detail——最大表存储每一笔充电过程上报电压、电流、功率、SOC、时间戳设备几秒上报一条这是整个系统数据量之王。上报频率3‑10s 一条 / 枪2000 枪满负荷一天明细行数 ≈ 2000 枪 × (86400/5s) ≈ 3400 万行 / 天现实不会全部枪同时跑实际日新增 200 万1200 万行单行400‑600 字节不归档 3 个月2 亿‑10 亿行80‑180GB生产绝对不能把这张表长期放 MySQL 主库。明细不适合 MySQL 查询扔 ESMySQL 只存订单摘要。2、充电订单主表charge_order业务订单一笔充电会话对应一条订单用户真正结算订单。日订单3000‑20000 条一年100 万‑700 万行单行≈300 字节1 年数据300MB‑2GB3 年最高 5‑7GB这张表业务核心MySQL 保留可按时间分区。3、订单计费分片 / 计价日志charge_bill_item一次订单内部多段计价峰谷切换、费率变更切分一个订单拆出多条计费子项。 一般是订单数量的 2‑5 倍。一年200 万‑3000 万行1‑8GB4、设备状态日志device_status_log充电桩心跳、状态变更待机、充电、故障、离线。日新增几十万行不归档半年可达千万级3‑10GB。5、用户表、场站、充电桩基础表数据量很小万十万级别几十 MB 级别可忽略。6、告警记录表alarm_record看故障多少中型系统日几千几万条一年千万行2‑6GB。总结核心结论MySQL 里最大表不是业务订单表是充电过程明细charge_detail这张表极易膨胀几十‑上百 GB生产最佳实践明细存入 ElasticsearchMySQL 只存订单摘要。如果强行全部明细压 MySQL中型系统跑 3 个月就上百 GB查询、备份、DDL 压力爆炸。订单表本身体量不大百万‑千万级别真正吃存储的是设备高频上报时序数据。中型生产落地方案MySQL订单、账单、用户、场站设备、告警按月份分区超过 18 个月归档到归档库。Elasticsearch接收充电过程明细、设备实时上报点做历史轨迹查询。Redis实时充电会话、设备在线状态、计价中间计算。定时任务定期迁移历史明细防止 MySQL 膨胀。面试可直接背诵的量化话术我们中型智慧充电项目充电桩规模 2000 枪左右日完成充电订单约 1.2 万笔。充电过程明细每秒上报是数据量最大来源日新增约 600 万行这部分时序明细不落地 MySQL写入 ES 做轨迹查询。MySQL 主库只保留业务订单订单表一年约 400 万行整体活跃 MySQL 库维持在 40G 左右历史超过一年半的数据会做归档处理。