使用 gocql 执行 `select *` 查询时列数不全，本质是客户端预编译语句未同步 schema 变更 + cassandra 旧版本（
在基于 Cassandra 的 Go 应用中，通过 ALTER TABLE ... ADD COLUMN 动态扩展计数器表（如 stats_dev.log_counters）是一种常见且合理的演进模式。但当后续执行 SELECT * FROM ... WHERE date IN ? 时，gocql 返回的字段数量少于实际列数（例如 30/34），而 cqlsh 却能正确返回全部列——这一差异并非业务逻辑错误，而是由 客户端驱动行为 与 服务端元数据缓存机制 共同引发的典型兼容性问题。
根本原因解析
gocql 的自动预编译（Automatic Query Preparation）
默认情况下，gocql 对重复结构的查询（如带参数的 SELECT *）会自动缓存并复用 Prepared Statement。该语句首次执行时，Cassandra 返回的响应中包含当时快照式的列元数据（column metadata）。此后即使你通过 ALTER TABLE 新增了列，gocql 仍沿用旧的元数据结构解析结果，导致新增列被静默忽略。Cassandra 的服务端元数据缓存缺陷（CASSANDRA-7910）
在 Cassandra 2.1.2 及更早版本中，服务端对 Prepared Statement 的元数据也存在缓存，且不会在 ALTER TABLE 后自动失效。这意味着：即使客户端强制重连或重建 session，Cassandra 仍可能返回过期的列定义。该问题已在 CASSANDRA-7910 中修复，并随 Cassandra 2.1.3+ 版本发布。
推荐解决方案
✅ 方案一：禁用自动预编译（推荐）
在 gocql.ClusterConfig 中显式关闭自动预编译，避免元数据僵化：
cluster := gocql.NewCluster("127.0.0.1")
cluster.Consistency = gocql.Quorum
cluster.DisableInitialHostLookup = true
cluster.ProtoVersion = 4
cluster.DisableAutoPrepare = true // ? 关键配置：禁用自动预编译
session, err := cluster.CreateSession()
if err != nil {
log.Fatal(err)
}启用此配置后，每次 Query() 都将作为普通未预编译语句执行，Cassandra 每次都会返回当前 Schema 下的完整元数据。
✅ 方案二：手动重建查询（适用于必须预编译场景）
若因性能考量需保留预编译，可在检测到 Schema 变更后（如部署新版本、初始化阶段），主动调用 session.Close() 并重建 Session，强制刷新所有 Prepared Statements：
// 示例：Schema 变更后重建 session（需配合外部协调）
func rebuildSession() (*gocql.Session, error) {
cluster := gocql.NewCluster("127.0.0.1")
cluster.DisableAutoPrepare = false
return cluster.CreateSession()
}⚠️ 注意：gocql 当前（v0.0.0–2024）不提供直接清除 stmtsLRU 缓存或单条重准备的公开 API，因此重建 Session 是最可靠手段。
✅ 方案三：动态生成列名（兜底方案）
如无法升级 Cassandra 或修改驱动配置，可按提问者所述，从 system_schema.columns 查询实时列名并拼接 SQL：
func buildSelectAllQuery(session *gocql.Session, keyspace, table string) (string, error) {
var cols []string
iter := session.Query(`SELECT column_name FROM system_schema.columns
WHERE keyspace_name = ? AND table_name = ?
ORDER BY position`, keyspace, table).Iter()
for iter.Scan(&cols) {
// 实际需逐行 Scan，此处简化示意
}
return fmt.Sprintf("SELECT %s FROM %s.%s WHERE date IN ?",
strings.Join(cols, ", "), keyspace, table), nil
}最佳实践建议
- *避免长期依赖 `SELECT **：尤其在 Schema 动态演进的场景下，显式声明所需列（如SELECT date, all, error_count, warning_count ...`）可提升可读性、避免元数据歧义，并规避此类问题。
- 升级基础设施：确保 Cassandra ≥ 2.1.3（或 ≥ 3.0.0），彻底消除服务端元数据缓存缺陷。
- 监控 Schema 变更：将 ALTER TABLE 操作纳入部署流水线，配套执行 session 重建或应用重启，形成闭环治理。
综上，该问题并非设计“愚蠢”，而是分布式数据库演化过程中典型的客户端-服务端协同边界问题。通过禁用自动预编译或升级环境，即可安全、高效地支持动态 Schema 扩展。
