全量同步是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。你得确保同步脚本和增量通道之间有明确的位点对齐，否则必然丢数据——这层协调逻辑，手写几乎无法可靠实现。
