目录单表阈值单库内1. InnoDB 单表行数经验红线2. 单表物理文件大小 .ibd单库阈值整个 database区分分区、分表、分库、归档很多人搞混智慧充电各个表应该用什么策略什么时候才真的要上 Sharding‑JDBC 做分库分表面试可直接复述版本坑点面试加分注意阈值是经验值不是硬性标准取决于单行大小、索引数量、查询 QPS、读写压力、硬件。 互联网生产通用经验优先做分区、冷热归档不到万不得已不分库分表分库分表有很重的业务侵入、分布式事务、join、分页、排序坑。单表阈值单库内1. InnoDB 单表行数经验红线500 万行预警线开始关注性能优化索引、分区、归档很多业务到 500 万已经开始变慢1000 万行普遍公认分表 / 归档的触发线 ✅单行小100‑300 字节可以扛到 2000 万单行大、索引多500 万就明显掉性能智慧充电charge_order订单表单行 300 字节左右800 万‑1000 万行就要考虑分区或者分表2. 单表物理文件大小.ibd30GB预警50GB强烈建议分表 / 归档 ✅ibd 文件过大备份慢、DDL 改表锁表时间巨长、碎片严重。 充电明细这种大表轻松冲到上百 GB绝对不要走到分表优先归档到 ES / 归档库。单库阈值整个 database200GB预警线观察 IO、备份耗时300‑500GB大多数公司触发分库 ✅单库超过 500GBmysqldump 备份时间爆炸实例故障恢复时间长物理复制延迟风险升高。 注意现在 SSD 硬件好部分大厂单库可以跑到 800GB但运维压力显著上升中小团队不建议模仿。中型智慧充电如果做好冷热归档活跃库控制在 20‑60GB根本不需要分库分表。区分分区、分表、分库、归档很多人搞混方案适用场景是否改变 SQLMySQL 表分区range 按时间单表千万以内按时间过滤查询居多例如订单、账单、告警几乎不改 SQLMySQL 内部处理分表Sharding‑JDBC 水平分表单表突破 1000 万查询无法大量过滤时间需要跨分片查询业务层改造 SQL分库单库数据量太大实例 CPU/IO 扛不住拆多个 MySQL 实例改造大分布式事务、join 问题冷热归档时序流水、明细数据充电上报点历史很少访问热库删旧数据历史迁移 ES / 归档库智慧充电业务优先级冷热归档 表分区 分表 分库充电明细不走分表直接归档 ES 充电订单优先 Range 按月分区真的订单量暴涨再 Sharding 分表。智慧充电各个表应该用什么策略charge_detail充电过程明细直接归档 ES禁止堆积 MySQL不要想着分表救它。charge_order充电订单按月 RANGE 分区数据持续暴涨再分表。charge_bill_item计费子项跟随订单按月分区。alarm_record告警按月分区旧数据归档。用户、场站、充电桩基础表数据量小完全不需要。什么时候才真的要上 Sharding‑JDBC 做分库分表满足下面部分条件才考虑订单表持续增长单表稳定超过 1000 万行业务不能简单按时间归档老数据频繁查询不能把历史丢归档单库接近 300‑500GB硬件升级 SSD 也解决不了 IO 压力QPS 很高单库 CPU 打满读写分离已经扛不住。中型智慧充电几千枪绝大多数场景到不了分库分表靠分区 冷热归档就搞定。真正需要分库分表是万枪级别大型平台。面试可直接复述版本MySQL 分库分表没有绝对硬性标准行业经验单表一般 1000 万行左右、单表 ibd 文件 50GB 作为分表参考阈值单库整体到达 300‑500GB 考虑分库。 但在智慧充电项目中不会上来就分库分表。充电明细这类高频时序上报数据直接落 ESMySQL 只存业务订单订单表优先使用 MySQL 按月分区 冷热归档把历史数据迁移归档库。只有当单表突破千万、老数据还需要频繁查询归档解决不了问题的时候才引入 Sharding‑JDBC 做分表分库。坑点面试加分不要拿行数当唯一标准单行大500 万就卡单行很小2000 万也能跑。分库分表成本很高跨分片 join、分页排序、分布式 ID、分布式事务、主键唯一、扩容迁移尽量前置用归档、分区规避。很多人踩坑把充电明细堆 MySQL试图分表扛数据量爆炸之后分表也扛不住时序明细优先 ES。