Go 无法原生接入 ShardingSphere，应将其作为透明数据库代理（如连 host:13306），使用逻辑 SQL；若自研分片，则需 Go 自行实现路由、连接池隔离、事务补偿与分页合并。
Go 语言原生不支持 ShardingSphere，ShardingSphere 是 Java 生态的中间件，直接在 Go 微服务里“接入 ShardingSphere”这个思路本身就有根本性偏差。
ShardingSphere 不是 Go 的库，它跑在 JVM 上
ShardingSphere（如 Proxy 或 JDBC）本质是独立进程或 Java 客户端，Go 服务无法通过 import 方式调用它的分片逻辑。常见误解是想用 Go 写个 client 去“对接”ShardingSphere Proxy 的某个 API——但它不提供标准分片控制 API，只暴露 MySQL/PostgreSQL 协议或管理接口。
- ShardingSphere-Proxy 对外伪装成数据库，Go 服务只需连它（
host:13306），像连普通 MySQL 一样用database/sql+mysql驱动 - 分库分表规则（如
t_order按user_id取模分 4 库 8 表）全在 ShardingSphere 的config-sharding.yaml里配置，Go 层无感知 - 真正要注意的是：Go 代码里所有 SQL 必须是**逻辑 SQL**（比如
SELECT * FROM t_order WHERE user_id = ?），不能写死物理库名或表名（如ds_2.t_order_7），否则 ShardingSphere 无法路由
Go 侧真正要做的分片：绕过 ShardingSphere 自研
如果因性能、协议兼容性或调试需要，必须由 Go 直接控制分库分表（例如用 pgx 连多个 PostgreSQL 实例），那就得自己实现路由逻辑——ShardingSphere 此时退场，Go 成为分片决策者。
- 核心是把分片键（如
user_id）映射到具体数据源：先算哈希或取模，再查map[shardKey]int或用一致性哈希环 - 每个分片需独立维护
*sql.DB或*pgxpool.Pool，不能共用连接池，否则事务和超时策略会冲突 -
INSERT和SELECT必须用同一套分片算法，否则读不到刚写的记录；跨分片JOIN、ORDER BY、GROUP BY得在 Go 层合并结果，不是数据库做 - 示例：按
user_id % 4选库，再user_id % 8选表 → 实际表名拼接为"t_order_" + strconv.Itoa(userID % 8)，库连接从dbPool[userID%4]取
踩得最多的坑：事务与分布式一致性
无论走 ShardingSphere 还是 Go 自研，跨库事务天然不支持 ACID。ShardingSphere 的 XA 或 Seata 集成只对 Java 客户端友好，Go 调 Proxy 时默认是本地事务（单库生效）。
立即学习“go语言免费学习笔记（深入）”；
- ShardingSphere-Proxy 中开启
transaction_type: XA后，Go 驱动需支持 XA 协议（多数不支持），实际几乎不可用 - 自研方案中，别写
tx, _ := db.Begin()然后跨多个*sql.DB执行 ——sql.Tx绑定单个连接，跨库等于多个独立事务 - 真有强一致性要求（如资金转账），得用 Saga 模式：Go 发起 A 库扣款 → 发 MQ → B 库收款 → 回调补偿。这不是数据库层能解决的事
- 分页查询（
LIMIT OFFSET）跨分片时，必须取各分片 top-N 再内存合并排序，否则分页结果错乱
分库分表从来不是加个中间件就完事，关键在分片键设计是否收敛、业务 SQL 是否可下推、以及出错时有没有降级路径。ShardingSphere 在 Go 项目里只是一层透明代理，真正的复杂度全压在 Go 代码的 SQL 编写习惯和错误处理上。
