mysql大数据并发下应合理分库分表：按业务维度水平拆分（如user_id%16）、时间维度归档冷热数据、读写分离+连接池优化；禁用盲目垂直拆分、触发器分表和过早单元化。
MySQL大数据并发场景下，拆分数据表是提升性能和稳定性的核心手段。关键不在于“要不要拆”，而在于“怎么拆才合理”——既要缓解单表压力，又要避免过度拆分带来的运维与查询复杂度。
按业务维度水平拆分（分库分表）
当单表数据量超千万、QPS持续高于2000，或写入延迟明显时，优先考虑按业务归属拆分。例如：用户中心表可按 user_id % 16 拆成16个物理表，订单表按 order_no 前4位哈希 或 商户ID取模 分散存储。
- 推荐使用 ShardingSphere-JDBC 或 MyCat 做透明分片，应用层无感接入
- 务必保留全局唯一主键（如雪花ID、UUID+时间戳），禁止自增ID跨分片冲突
- 跨分片关联查询（如用户+订单）改用应用层join或冗余必要字段，避免广播查询
按时间维度归档冷热数据（分区+归档）
日志、流水、监控类表天然适合按时间切分。用 MySQL 原生 PARTITION BY RANGE (TO_DAYS(create_time)) 实现月级/季度级分区，配合定期 ALTER table … DROP PARTITION 快速清理过期数据。
- 分区字段必须是索引的一部分（通常是主键或联合索引最左前缀）
- 历史数据可导出为 .sql.gz 或迁移至对象存储（如OSS/S3），再从原库删除
- 归档后保留最近6个月分区在线，更早的转为只读归档库，降低主库IO压力
读写分离 + 连接池精细化控制
拆表只是起点，高并发下必须配合流量调度。主库专注写入，从库承担报表、搜索、详情页等读请求；但要注意主从延迟敏感场景（如刚注册就查个人信息）强制走主库。
- 用 HikariCP 或 Druid 设置合理连接数（一般 ≤ CPU核数×2），避免连接耗尽
- 对慢查询加 SQL Hint（如 /*+ MAX_EXECUTION_TIME(1000) */）防拖垮整个实例
- 高频小查询（如配置、状态）接入 redis 缓存，缓存穿透用布隆过滤器兜底
不建议盲目做的三件事
有些“优化”看似合理，实则埋雷：
- 不分场景垂直拆分字段：把大文本、jsON字段单独建表，反而增加JOIN开销，除非该字段99%查询都不需要
- 用触发器自动分表：逻辑难维护，事务一致性差，且无法利用分区剪枝
- 一上来就做单元化（按地域/租户彻底隔离）：初期增加架构复杂度，中小业务先用逻辑分片更稳妥
拆分不是目的，稳定支撑业务增长才是。上线前务必压测真实流量路径，重点关注分片键倾斜、跨节点事务、分布式ID生成延迟等细节。不复杂但容易忽略。