Go语言集成TiDB核心在于适配其分布式事务、快照隔离与网络协调特性：需配置parseTime=true、clientFoundRows=true、loc=Local、合理超时，禁用charset；事务内读不到新写数据是REPEATABLE READ快照隔离的正常行为；批量操作应避免循环Exec，优先用多值语句或Prepare；错误处理须识别TiDB特有可重试语义并手动重试。
Go语言集成TiDB实现大规模分布式数据查询，核心不在于“换驱动”，而在于理解TiDB的分布式事务模型、快照隔离语义和网络协调开销，并在Go代码中做针对性适配。直接复用MySQL连接方式能跑通，但若不做关键配置和逻辑调整，查询会卡顿、结果不一致、批量性能骤降。
DSN配置必须显式启用关键参数
TiDB虽兼容MySQL协议，但默认行为更严格。缺少必要参数会导致连接失败、时间字段解析异常或RowsAffected返回0：
-
parseTime=true：否则DATETIME/TIMESTAMP字段被读作字符串，无法直接Scan到
time.Time -
clientFoundRows=true：TiDB默认返回匹配行数（Matched），而非影响行数（Affected）；不加此参数，
result.RowsAffected()恒为0 -
loc=Asia%2FShanghai（或
loc=Local）：避免时区转换错误，尤其涉及NOW()、CURDATE()等函数时 - timeout/readTimeout/writeTimeout=30s：TiDB分布式事务涉及多节点协调，超时需比单机MySQL设得更宽松
- 不要写
charset=utf8mb4：TiDB 5.0+已默认使用该字符集，硬写可能触发旧版驱动解析异常
事务内查询要适应快照隔离
TiDB默认隔离级别是REPEATABLE READ，基于TSO（时间戳）提供一致性快照。这意味着：
- 同一个
*sql.Tx中，tx.Exec("INSERT ...")后立即tx.Query("SELECT ...")，查不到刚插入的数据——这不是bug，是预期行为 - 如需读己写（read-your-writes），应在事务开始前获取当前TSO，或改用
SELECT ... FOR UPDATE显式加锁（但会退化为悲观模式，降低并发） - 跨事务读取最新数据，依赖TiDB的全局TSO分配机制，无需额外干预，但要注意客户端本地时钟漂移不能超过PD允许范围（默认500ms）
大规模查询性能优化要点
面对千万级以上表的OLAP或混合负载，仅靠SQL调优不够，Go层需配合TiDB架构特点：
立即学习“go语言免费学习笔记（深入）”；
- 避免循环
db.Query单行查询：每次调用都触发一次RPC到TiDB Server，再由其分发至TiKV Region；应尽量合并为IN列表查询或使用Prepared Statement复用执行计划 - 大结果集用
rows.Next()流式处理，配合SetMaxOpenConns和SetMaxIdleConns控制连接池大小（建议MaxOpenConns = 20–50，过高易引发TiDB端连接耗尽） - 聚合类查询优先下推：TiDB支持大部分标准SQL聚合与窗口函数，让计算发生在TiKV层，减少网络传输量
- 高并发点查场景，确认TiDB是否开启
tiflash.replica-read=follower，可将只读请求自动路由至TiFlash副本，减轻TiKV压力
错误处理需识别TiDB特有可重试语义
TiDB采用乐观事务，在写冲突时不会阻塞，而是返回ErrWriteConflict等可重试错误。Go标准库不感知该语义，必须手动处理：
- 使用
github.com/pingcap/tidb/util/errors.IsRetryableError(err)判断是否应重试 - 事务内发生冲突时，不能简单
return err，而应回滚后重新BeginTx并重放逻辑 - 不要依赖
err == sql.ErrTxDone判断事务状态——TiDB可能在Commit()阶段才暴露冲突 - 对幂等性要求高的操作（如扣减余额），建议在应用层加唯一键或版本号控制，避免无限重试
