应使用pgx/v5而非database/sql默认驱动，因其原生支持load_balance、target_session_attrs等ysql特有参数，避免连接池卡顿和单点访问；需配置sslmode、application_name，建表时显式指定primary key与distributed by策略，并慎用select for update，改用乐观锁及带版本号的update。
用 pgx 连接 YugabyteDB，别碰 database/sql 的默认驱动
YugabyteDB 兼容 PostgreSQL 协议，但 database/sql 默认的 lib/pq 驱动在高并发下容易卡住连接池，且不支持 ysql 特有的负载均衡参数（比如 load_balance=true）。直接换 pgx/v5 —— 它原生支持连接字符串里的 load_balance、target_session_attrs，还能复用连接池做 prepared statement 缓存。
实操建议：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 导入
github.com/jackc/pgx/v5/pgxpool，不是pgxpool.Connect，而是用pgxpool.New+ 自定义pgxpool.Config，方便控制MaxConns和HealthCheckPeriod - 连接字符串必须带
load_balance=true，否则客户端永远只连第一个节点，失去分布式读能力 - 加
sslmode=disable（开发环境）或sslmode=require+sslrootcert=...（生产），YugabyteDB 默认启用 SSL，但pgx不会自动 fallback - 别漏掉
application_name参数，方便在yb-admin或ysqlsh里快速识别连接来源
建表时显式指定 PRIMARY KEY 和 DISTRIBUTED BY
YugabyteDB 不是“兼容 PostgreSQL 就能照搬 DDL”。它默认按主键哈希分片，但如果你的主键是 UUID 或时间戳，会导致热点——所有写请求打到同一个 tablet。必须人工干预分片策略。
实操建议：
-
CREATE TABLE必须带PRIMARY KEY，且主键字段不能是UUID类型（除非你加DISTRIBUTED BY显式指定分片列） - 高频查询字段如果常用于
WHERE，优先设为复合主键的一部分，比如(tenant_id, id)，让数据按tenant_id分片 - 想按范围分片？用
DISTRIBUTED BY RANGE (created_at)，但注意：YugabyteDB 的 range 分片不支持自动 split，得靠yb-admin手动 split tablet - 避免
serial或bigserial，改用GENERATED ALWAYS AS IDENTITY，否则序列值可能跨节点不连续
事务里慎用 SELECT FOR UPDATE，优先走乐观锁
YugabyteDB 的分布式两阶段提交（2PC）会让 SELECT FOR UPDATE 变慢，尤其跨多节点时，锁等待时间不可控。线上服务一旦出现长事务，很容易触发 TransactionAborted 错误。
实操建议：
- 把
SELECT ... FOR UPDATE换成带版本号的更新：UPDATE t SET x = ?, version = version + 1 WHERE id = ? AND version = ?，检查RowsAffected()是否为 1 - 如果真要悲观锁，限定语句必须走单节点：主键等值查询 +
WHERE条件能命中唯一分片（比如WHERE tenant_id = 'abc' AND id = 123） - 设置
pgx.TxOptions{IsoLevel: pgx.ReadCommitted}，别用Serializable—— YugabyteDB 的 serializable 实现开销大，且和 PG 行为不完全一致 - 超时必须设：用
context.WithTimeout包裹BeginTx，YugabyteDB 默认事务超时是 60 秒，但 Go 层不感知，容易 hang 住 goroutine
健康检查别只 ping，要查 system_schema.tables
很多项目用 conn.Ping() 做健康检查，但这只测 TCP 连通性，不验证 YSQL 层是否就绪。YugabyteDB 节点重启后，YSQL 服务可能延迟数秒启动，此时 Ping() 成功但 SELECT 1 失败。
实操建议：
- 健康检查 SQL 改用
SELECT COUNT(*) FROM system_schema.tables LIMIT 1，这个表始终存在，且访问不触发复杂元数据锁 - 连接池初始化后，主动执行一次健康检查再标记 ready，避免刚启动时流量打进去全失败
- 如果用了
pgxpool.Config.AfterConnect，在里面加简单查询（如SELECT 1），过滤掉刚连上却还没 ready 的连接 - Kubernetes liveness probe 不要直接调 HTTP 接口，而是 exec 到 pod 里跑
ysqlsh -c "SELECT 1;"，更贴近真实链路
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
