从零到一：用ShardingSphere-Proxy 5.4.1给MySQL 8.0做个‘分库分表’手术（附Navicat验证）
从零构建MySQL分库分表架构：ShardingSphere-Proxy 5.4.1实战指南
当单表数据突破千万级时，查询性能的断崖式下跌总会如期而至。去年我们电商平台的订单表就遇到了这个经典问题——一个简单的用户历史订单查询需要8秒响应。这就是为什么我们需要给数据库做"横向拆分手术"，而ShardingSphere-Proxy正是这场手术的智能手术刀。
1. 环境准备与工具选型
工欲善其事，必先利其器。在开始前需要确认以下环境就绪：
Java环境：ShardingSphere基于Java开发，需JDK 1.8+
java -version # 应显示类似：openjdk version "1.8.0_352"数据库组件：
- MySQL 8.0.35社区版（注意版本兼容性）
- MySQL Connector/J 8.0.32驱动
- ShardingSphere-Proxy 5.4.1二进制包
可视化工具：Navicat 16+（用于直观验证分片效果）
提示：所有组件建议从官网下载，避免第三方渠道的版本篡改风险。特别是MySQL Connector的版本必须与Proxy兼容，否则会出现诡异的"Commands out of sync"错误。
安装过程中的版本匹配至关重要，以下是经过验证的组件组合：
| 组件 | 推荐版本 | 备注 |
|---|---|---|
| ShardingSphere-Proxy | 5.4.1 | 注意lib目录权限问题 |
| MySQL Server | 8.0.35 | 需配置lower_case_table_names=1 |
| Connector/J | 8.0.32 | 必须放在Proxy的lib目录下 |
2. MySQL基础环境配置
首先初始化两个物理数据库作为分片节点：
-- 创建分片用的物理数据库 CREATE DATABASE demo_ds_0 CHARACTER SET utf8mb4; CREATE DATABASE demo_ds_1 CHARACTER SET utf8mb4; -- 确认创建成功 SHOW DATABASES LIKE 'demo_ds%';关键配置项需要写入my.ini文件：
[mysqld] lower_case_table_names=1 # 避免表名大小写问题 default_authentication_plugin=mysql_native_password常见踩坑点：
- Windows系统默认安装MySQL服务时可能遗漏环境变量配置，需手动添加bin目录到PATH
- 初始化密码包含特殊字符时，建议立即修改：
ALTER USER 'root'@'localhost' IDENTIFIED BY 'NewPass123!';
3. ShardingSphere-Proxy核心配置解析
进入ShardingSphere-Proxy的conf目录，需要重点配置两个文件：
3.1 server.yaml - 权限控制
authority: users: - user: root@% password: root - user: sharding password: sharding这个配置定义了连接Proxy的认证信息，与实际MySQL的账号体系完全隔离。建议生产环境使用强密码并配置IP白名单。
3.2 config-sharding.yaml - 分片规则
这是整个分库分表架构的核心大脑，主要包含三大模块：
数据源配置
dataSources: ds_0: url: jdbc:mysql://127.0.0.1:3306/demo_ds_0?serverTimezone=UTC username: root password: root ds_1: url: jdbc:mysql://127.0.0.1:3306/demo_ds_1?serverTimezone=UTC username: root password: root分表策略示例
tables: t_order: actualDataNodes: ds_${0..1}.t_order_${0..1} tableStrategy: standard: shardingColumn: order_id shardingAlgorithmName: t_order_inline分片算法定义
shardingAlgorithms: database_inline: type: INLINE props: algorithm-expression: ds_${user_id % 2} # 按用户ID奇偶分库 t_order_inline: type: INLINE props: algorithm-expression: t_order_${order_id % 2} # 按订单ID奇偶分表重要提示：yaml文件对缩进极其敏感，建议使用专业的文本编辑器（如VS Code）并安装YAML插件进行语法检查。
4. 分片效果验证与实践
启动Proxy服务后，通过Navicat建立到Proxy的连接（端口3307），可以看到逻辑库sharding_db。此时执行建表语句：
CREATE TABLE t_order ( order_id BIGINT PRIMARY KEY, user_id INT NOT NULL, amount DECIMAL(10,2), create_time DATETIME );神奇的事情发生了：虽然在Proxy中只执行了一次建表语句，但在后端物理数据库中：
- demo_ds_0库出现t_order_0和t_order_1表
- demo_ds_1库同样出现t_order_0和t_order_1表
这就是分库分表的魔法——逻辑上是一个表，物理上是四个表的联合。
插入测试数据验证分片规则：
-- 用户1001的订单（user_id % 2 = 1）会进入ds_1 INSERT INTO t_order VALUES(1, 1001, 99.9, NOW()); -- 用户1002的订单（user_id % 2 = 0）会进入ds_0 INSERT INTO t_order VALUES(2, 1002, 199.9, NOW());在Navicat中分别查看两个物理库，可以直观看到：
- demo_ds_1.t_order_* 包含user_id为奇数的订单
- demo_ds_0.t_order_* 包含user_id为偶数的订单
5. 高级配置与性能调优
基础分片实现后，还需要考虑以下生产级配置：
5.1 分布式主键策略
避免使用自增ID，改用Snowflake算法：
keyGenerators: snowflake: type: SNOWFLAKE props: worker-id: 1235.2 连接池优化
调整Proxy与MySQL的连接参数：
dataSources: ds_0: # ...其他配置 connectionTimeoutMilliseconds: 30000 maxPoolSize: 50 minPoolSize: 55.3 绑定表关系
确保关联表使用相同的分片规则：
bindingTables: - t_order,t_order_item实际项目中我们发现，当单表数据超过3000万时，分片后的查询性能提升可达5-8倍。但要注意，跨分片的JOIN操作仍然代价高昂，需要业务层做相应改造。