go应用需直连shardingsphere-proxy（如localhost:3307），使用逻辑库名，sql中必须显式包含确定的分片键值（如user_id = 12345），不可依赖参数绑定或函数，所有分片规则配置于proxy的config-sharding.yaml中。
ShardingSphere-Proxy 与 Go 应用之间没有直接 SDK 集成
Go 语言本身不提供官方或主流的 ShardingSphere 客户端 SDK。ShardingSphere 的分库分表能力主要通过 ShardingSphere-JDBC（JVM 内嵌）或 ShardingSphere-Proxy（独立数据库代理）暴露，Go 应用只能把它当普通 MySQL/PostgreSQL 实例连——路由逻辑完全由 Proxy 承担，Go 层不参与分片计算。
这意味着：你无法在 Go 代码里调用 shardByKey() 或配置 sharding-algorithm；所有分片规则必须写在 Proxy 的 config-sharding.yaml 里，Go 只负责发标准 SQL。
- 常见错误现象：
ERROR 1146 (42S02): Table 'db.t_order_0' doesn't exist—— Go 直连了真实分片表，绕过了 Proxy - 正确使用场景：Go 连接
localhost:3307（Proxy 端口），而非真实 MySQL:3306 - 参数差异：连接字符串中
database名填逻辑库名（如shop），不是物理库名（如shop_0）
Go 侧唯一可控的路由入口是 SQL 中的分片键值
ShardingSphere-Proxy 路由依赖 SQL 解析结果。Go 应用若想让某条查询落到指定分片，必须确保 SQL 中显式包含分片键（如 user_id），且值为确定量——不能是子查询、函数或参数绑定后无法静态推导的变量。
例如，SELECT * FROM t_order WHERE user_id = ? 在预编译后可能丢失路由能力，取决于 Proxy 版本和驱动是否透传实际值；而 SELECT * FROM t_order WHERE user_id = 12345 总能被正确路由。
立即学习“go语言免费学习笔记（深入）”；
- 容易踩的坑：
WHERE user_id IN (?, ?)多值参数在旧版 Proxy（ - 性能影响：含分片键的
INSERT能精准写入单分片；不含则触发全库插入，严重拖慢吞吐 - 兼容性注意：PostgreSQL 协议下部分语法（如
LATERAL JOIN）可能导致解析失败，路由失效
需要自定义路由逻辑？别动 ShardingSphere，改 Go 数据访问层
如果业务要求“按地区优先查从库”“按订单金额分流到不同 Proxy 集群”，这类非分片键维度的路由，ShardingSphere 不处理，也不该让它处理。得在 Go 里做数据源选择。
典型做法是封装一个 DBRouter 结构体，根据上下文字段（如 region, amount）返回对应 *sql.DB 实例——这些实例分别连向不同的 ShardingSphere-Proxy 地址或直连库。
func (r *DBRouter) GetDB(ctx context.Context, req RouteRequest) (*sql.DB, error) {
switch req.Region {
case "cn":
return r.cnProxyDB, nil
case "us":
return r.usProxyDB, nil
default:
return r.defaultDB, nil
}
}- 关键点：路由决策必须在
sql.Open之后、db.Query之前完成，不能靠中间件动态切换连接 - 为什么这样做：ShardingSphere 的定位是透明分片，不是多活流量网关；混用会破坏其 SQL 解析一致性
- 容易忽略的细节：事务跨 Proxy 时无法保证原子性，
Begin()必须绑定到单一*sql.DB
调试分片行为最有效的办法：看 Proxy 日志 + 慢日志
Go 应用层看不到分片过程，但 ShardingSphere-Proxy 的 sql-federation.log 和 sharding-sql.log 会明确打印路由结果。比如：
[INFO] Actual SQL: ds_0 ::: SELECT * FROM t_order_1 WHERE user_id = 1001
这说明逻辑 SQL SELECT * FROM t_order WHERE user_id = 1001 被正确路由到了 ds_0 数据源的 t_order_1 表。
- 常见错误现象：日志里出现
Actual SQL: ds_0 ::: ...; ds_1 ::: ...多行，说明触发了广播查询——检查 SQL 是否缺失分片键或用了不支持的表达式 - 调试建议：启动 Proxy 时加
--log-level=DEBUG，并在 Go 的sql.DB设置SetMaxOpenConns(1)避免连接复用干扰日志归因 - 真正复杂的地方在于：SQL 重写可能改变执行计划，比如
ORDER BY后带分片键会被下推，不带则在 Proxy 合并结果，延迟不可控
