预估分片后单库单表真实数据量不能简单用总行数除以分片数，必须结合分片键分布均匀性与业务热点分析；例如user_id哈希分片时，若5% VIP用户贡献60%订单，则部分分片数据量可能超均值3–5倍，需通过7天写入日志抽样、频率直方图识别热点并加盐或改用一致性哈希。
怎么预估分片后单库单表的真实数据量
别直接拿总行数除以分片数。真实写入压力取决于分片键分布是否均匀，以及业务写入是否存在热点。比如用 user_id 做哈希分片，但 5% 的 VIP 用户贡献了 60% 的订单，那部分分片表的数据量可能比平均值高 3–5 倍。必须结合历史日志抽样统计：取最近 7 天的写入 SQL，提取 INSERT 中的分片键值，做频率直方图。如果前 10 个高频 user_id 占总写入量超 20%，就得考虑加盐（如 user_id + rand(0,15)）或改用一致性哈希。
连接数与 QPS 怎么按分片摊薄才不翻车
分库不是简单把连接池配置复制 N 份。MySQL 实例级连接上限（max_connections）和单库连接池大小是两回事。假设源库峰值 QPS 是 8000、连接数打满到 140，拆成 8 个分片后，目标端每个实例的预期 QPS 是 1000 左右，但连接数不能按 140 ÷ 8 = 17.5 来设——因为业务侧连接池通常有最小空闲连接（minIdle），8 个数据源各自维持 10 个空闲连接，光空闲连接就占掉 80，再叠加突发流量，很容易触发 Too many connections。实操建议：
- 目标端每个 MySQL 实例的
max_connections至少设为 300，留出缓冲空间 - 应用层连接池的
maxActive按预估峰值 QPS × 平均响应时间（秒）× 安全系数 1.5 计算，而非简单均分 - 压测时重点观察
Threads_connected和Threads_running的差值，超过 50 就说明空闲连接堆积严重，需调低minIdle
磁盘 IO 和备份窗口怎么同步评估
分片后单实例数据量变小，但总写入吞吐没变，IO 压力未必下降。尤其当多个分片部署在同一物理机或共享存储上，随机读写争抢反而更剧烈。关键看两个指标：
-
iostat -x 1中的%util是否持续 > 85%，>95% 就得考虑分离部署或换 NVMe - 单分片的
mysqldump或mydumper全量备份耗时是否仍能卡在业务低峰期（比如 2 小时内）。如果单分片备份要 3 小时，8 个分片串行备份就是 24 小时——这不可接受。必须改成并行备份，且每个分片备份命令加--compress和--chunk-filesize=256M控制单次 IO 批次
另外，binlog 日志生成速度也要重算：原来一个实例每小时产生 2GB binlog，拆成 8 个后，每个实例约 250MB/h，但归档策略、清理周期、网络传输带宽都要按新节奏调整，否则 binlog 磁盘爆满会直接导致主从中断。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
为什么 DDL 时间不能只看单表规模
分库分表后，DDL 变成批量操作，但工具（如 pt-online-schema-change）默认是单表执行，8 个分片就要跑 8 次，每次锁表窗口叠加，整体风险翻倍。更隐蔽的问题是：不同分片的表数据分布差异大，pt-osc 内部的 chunk 切分逻辑在小分片上可能一次扫完，在大数据量分片上却要切几千次，导致执行时间不可控。实际做法是：
- 先对所有分片表做
SELECT COUNT(*)和SHOW TABLE STATUS，挑出数据量 Top 3 的分片作为 DDL 基准测试对象 - 在基准分片上跑
pt-osc --dry-run，观察chunk-size建议值，再手动设为该值的 0.7 倍（避免大事务） - 所有分片 DDL 必须错峰执行，间隔至少 15 分钟，且避开凌晨自动备份时段
真正容易被忽略的是：分片键字段本身的 DDL（比如给 user_id 加索引）会影响路由中间件的解析逻辑，这类变更必须在所有分片完成后再统一重启中间件，否则会出现路由错乱。
