全量同步是Redis主从复制中从节点首次连接或断连超时后的兜底机制，通过PSYNC ? -1触发，主节点执行BGSAVE生成RDB快照并缓存增量命令，再传输RDB及缓冲区命令完成数据一致。

全量同步不是靠 go-redis 客户端自己完成的

go-redis 本身不提供「从 mysql 或其他源拉取全量数据写入 redis」的能力，它只是个通信客户端。所谓全量同步，本质是业务逻辑：先查出所有数据，再逐条或批量写进 redis。常见错误是以为 rdb.set 或 rdb.hset 调用一次就能同步整张表——其实那只是单 key 操作。

手动实现全量同步的关键步骤

适用于小到中等规模表（比如 t_user 不超过 10 万行），且你控制着源数据库访问权限：

• 用 database/sql 连 MySQL，执行 SELECT * 拉取全量数据（注意加 ORDER BY 避免游标偏移）
• 遍历结果集，按业务规则生成 Redis key 和 value（例如 USER_ + id 作为 key，JSON 字符串作 value）
• 用 rdb.Set 或 rdb.HSet 写入；高并发下建议用 rdb.Pipelined 批量提交，减少 RTT
• 务必设置超时和重试：单条失败不能中断整个流程，需记录失败 ID 后续补推

避免踩坑：大表、分页、类型转换

实际跑起来常遇到三类问题：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 内存溢出：一次性 SELECT * 加载百万行到 Go slice，直接 OOM。改用 sql.Rows 流式读取 + 分批处理（如每 500 行 commit 一次）
• 分页不准：用 LIMIT OFFSET 分页在写入过程中可能漏数据（新插入行挤占位置）。推荐用基于主键/时间戳的游标分页，例如 WHERE id > ? ORDER BY id LIMIT 500
• 空值与类型错乱：MySQL 的 NULL、TIMESTAMP、ENUM 直接扫进 struct 可能 panic。用 sql.NullString 等包装类型，或统一转成 map[string]interface{} 再 JSON 序列化

生产环境更该考虑 go-mysql-transfer 这类工具

如果你要同步的是多个库、多张表，或者要求「全量 + 增量无缝衔接」，硬写 Go 同步脚本很快会失控。go-mysql-transfer 这类 Binlog 工具的 full_init 功能就是干这个的：启动时自动做一次全量 dump，完成后立即切到 binlog 增量监听。它内置了分批、断点续传、失败重试、字段映射（比如 column_underscore_to_camel: true），比手写健壮得多。

真正容易被忽略的点是：全量同步期间，业务仍在写 MySQL。你得确保同步脚本和增量通道之间有明确的位点对齐，否则必然丢数据——这层协调逻辑，手写几乎无法可靠实现。