MySQL不原生支持分片，需通过Proxy层（如ShardingSphere-Proxy）或应用层（如sharding-jdbc）实现；主从/Group Replication仅解决高可用，不满足水平切分需求。
MySQL 本身不原生支持分布式存储或自动分片，所谓“MySQL 分片”必须靠外部组件或应用层实现，硬上 mysqld 集群不会自动拆表、路由或合并结果。
为什么不能直接用 MySQL 主从/Group Replication 做分片
主从复制和 MySQL Group Replication 解决的是高可用与读扩展，所有节点持有全量数据；分片（Sharding）要求数据按规则水平切分到不同物理库/表，二者目标冲突。常见误操作是把“多个主从集群”当成分片——实际只是多个独立数据库，缺乏全局路由、跨节点事务、聚合查询等能力。
- 没有统一入口：应用需自己判断该查哪个库，
shard_key路由逻辑散落在业务代码里 - 无法执行
JOIN或GROUP BY跨分片：要么改写成多次单库查询+内存合并，要么引入中间件 -
auto_increment主键在分片下极易冲突，需改用UUID、Twitter Snowflake或中心号段服务
主流可行路径：Proxy 层 vs 应用层分片
目前生产环境落地最稳的两种方式：
-
Proxy 层（推荐初试）：部署
MyCat或ShardingSphere-Proxy，对应用透明，支持SELECT/INSERT路由、读写分离、简单跨库UNION。但ShardingSphere-Proxy对 MySQL 协议兼容性要求高（建议 MySQL 5.7+ / 8.0），且不支持存储过程、部分窗口函数 -
应用层分片（更可控）：用
sharding-jdbc（Java）或vitess-go（Go）等 SDK，在 DAO 层完成分片键计算与连接选择。优势是无额外运维组件，缺点是语言绑定强、升级成本高
避坑提示：MyCat 已多年未更新，新项目慎选；Vitess 功能强但学习曲线陡，需熟悉其 vttablet/vtctld 组件生命周期。
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
最简分片部署验证步骤（以 ShardingSphere-Proxy 5.3 + MySQL 8.0 为例）
跳过 Docker 编排，直奔可验证的最小闭环：
- 下载
apache-shardingsphere-5.3.2-shardingsphere-proxy-bin.tar.gz，解压后修改conf/server.yaml：设authentication和props.proxy-backend-flush-threshold: 128（避免小批量插入卡顿） - 在
conf/config-sharding.yaml中定义分片规则：比如将t_order按user_id % 4分到ds_0~ds_3四个数据源，每个数据源指向独立 MySQL 实例（非同一实例的不同库） - 确保所有后端 MySQL 实例已创建对应库（如
ds_0对应db_order_0），且server-id全局唯一、binlog_format=ROW - 启动
bin/start.sh，用mysql -h127.0.0.1 -P3307 -u root -proot连 Proxy 端口，执行INSERT INTO t_order (user_id, order_no) VALUES (1001, 'A001');，观察是否写入db_order_1（因 1001 % 4 = 1）
注意：ShardingSphere-Proxy 默认不支持 SHOW CREATE TABLE 跨库元数据合并，建表需手动在每个真实库中执行。
分片键设计不当会导致灾难性后果
这不是配置问题，而是架构决策点——一旦上线，几乎无法安全变更：
- 避免用时间类字段（如
create_time）做分片键：导致热点写入（所有新订单都挤在最新分片），且冷热数据无法自动分离 - 避免用低基数字段（如
status TINYINT）：分片数虚高，实际只有几个库被频繁访问 - 优先选高频查询 + 高基数 + 稳定不变的字段，例如
user_id（用户中心化场景）或tenant_id（SaaS 多租户） - 如果业务必须按地域查，可考虑复合分片键（如
city_code + user_id），但ShardingSphere的ComplexKeysShardingAlgorithm实现复杂，测试成本高
真正难的从来不是部署几个容器，而是想清楚数据边界在哪、查询模式怎么变、扩容时历史数据怎么搬——这些在 config-sharding.yaml 里一行都写不出来。
