gocql.Dial() 连接失败却无报错，主因是 ConnectTimeout 默认仅600ms过小，需显式设为≥2s；务必检查 session != nil 且执行 session.Query("SELECT now()").Exec() 验证连通性。
gocql.Dial() 连接失败但没报错？检查 Timeout 和 ConnectTimeout 区别
ScyllaDB 响应快，但 gocql 默认的 Timeout（用于查询）和 ConnectTimeout（仅用于初始握手）是两个独立配置。很多连接卡住或静默失败，其实是 ConnectTimeout 太小（默认 600ms），而 ScyllaDB 在高负载或跨 AZ 部署时首次握手可能略超时，但不会抛出明显错误，而是返回 nil session + 无提示。
-
ConnectTimeout必须显式设为至少2 * time.Second，尤其在容器/K8s 网络或多数据中心场景 -
Timeout控制后续查询，建议按业务设（如5 * time.Second），别和ConnectTimeout混用 - 别依赖
err判断连接是否成功：要检查session != nil且调用一次session.Query("SELECT now()").Exec()确认可通
批量写入吞吐上不去？关掉 SerialConsistency 并用 Batch 而非串行 Query
ScyllaDB 的轻量级事务（LWT）和串行一致性会显著拖慢写入。gocql 默认不启用 LWT，但如果你手动设置了 SerialConsistency（比如 gocql.SERIAL），哪怕只写普通表，也会触发 Paxos 流程，吞吐直接跌 5–10 倍。
- 确认没在
ClusterConfig或单条Query上设SerialConsistency；99% 的写入场景用LocalQuorum或One就够 - 批量插入必须用
session.NewBatch(gocql.UnloggedBatch)，不是循环调session.Query(...).Exec()—— 后者每条都走完整网络 round-trip - 单个
Batch不宜超过 64 条语句；超过就拆分，否则 ScyllaDB 会拒绝（"batch too large"错误）
为什么 Scan() 取不到 time.Time？注意 ScyllaDB 的 timestamp 类型映射
ScyllaDB 的 timestamp 存的是毫秒级 Unix 时间戳，但 gocql 默认把它解码成 int64，不是 time.Time。如果你 struct 字段声明为 time.Time，Scan() 会静默失败（字段保持零值），也不报错。
- 两种解法：要么把 struct 字段改成
int64，自己转time.Unix(0, ts*1e6)；要么用gocql.Timestamp类型（它实现了sql.Scanner，能自动转time.Time） - 别信文档里“自动支持 time.Time”——那是针对 CQL
date或time类型，timestamp是特例 - 用
session.Query("SELECT ts FROM t").Scan(&ts)时，先打印fmt.Printf("%T", ts)确认类型，比猜靠谱
连接池打满、goroutine 泄漏？别复用 ClusterConfig 实例，但要复用 Session
gocql 的 ClusterConfig 是可变对象，内部缓存了 DNS 解析结果和连接状态。如果多个地方用同一个 ClusterConfig 实例调 gocql.NewSession()，第二次调用会复用第一次的连接池，导致连接数失控、健康检查错乱，甚至 goroutine 卡在 hostUp 里不退出。
立即学习“go语言免费学习笔记（深入）”；
- 每次新建
Session，都 new 一个干净的gocql.ClusterConfig{...}；不要全局单例复用 - 但
Session本身必须复用：它是线程安全的，内部有连接池和重试逻辑，每个请求都 newSession是灾难 - 用完不需手动 close ——
Session.Close()是终结整个连接池，只应在服务退出时调一次
ScyllaDB 的高性能很依赖客户端行为是否“克制”。最常被忽略的，是把 ClusterConfig 当成配置结构体来共享，其实它带状态；还有就是以为 time.Time 能直通 timestamp 字段，结果数据全丢了也不报错。
