真正解决大字段问题的核心是切存储方式而非分库分表，MySQL中TEXT超64KB易触发Row size too large或innodb log file is full错误，PostgreSQL中JSONB单值安全上限建议≤200MB，超限应剥离主表存对象存储并用hash索引。
大字段（如 TEXT、JSON、长 Markdown 内容）不能靠「分库分表」或「数据库原生分区」自动拆分——它们只是单行里的一个列，再大的字符串也只属于一条记录。真正要解决的，是「单条记录过大导致写入失败、复制延迟、备份膨胀、查询变慢」这四个问题。核心思路不是切数据，而是切存储方式。
MySQL 中 TEXT 超过 64KB 就会触发 innodb_log_file_size 报错
MySQL 的 InnoDB 对单条记录有硬限制（约 8000 字节/页内），超长 TEXT 实际存为外部溢出页，但写入时仍需完整加载进 buffer pool，容易触发 ERROR 1118 (42000): Row size too large 或 innodb log file is full。
- 别用
MEDIUMTEXT或LONGTEXT无脑顶替 —— 它们不解决根本问题，只是把崩溃点往后推 - 写入前强制截断校验：
if len(content) > 1024*1024 { return errors.New("content too long") } - 真正超长内容（如日志原文、导出文件）应剥离主表：用
content_hash（如 SHA-256）做索引，真实内容存对象存储（S3/MinIO），数据库只留元数据 - 若必须存 DB，改用
COMPRESS()+UNCOMPRESS()（MySQL 5.7+），但注意 Go 驱动默认不支持二进制返回，需显式设置parseTime=true&binary=true
PostgreSQL 中 JSONB 超过 2GB 会直接拒绝插入
PostgreSQL 单值上限是 1GB（实际安全线建议 ≤200MB），JSONB 还额外消耗解析开销。错误信息通常是 ERROR: string is too long 或事务中途 panic: pq: out of memory。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 别依赖 ORM 自动序列化大结构体 —— GORM 或 sqlc 默认把整个 struct 当
JSONB插入，极易爆内存 - 写入前用
json.Marshal+len()检查长度，超过 10MB 就该走外部存储 - 需要局部更新时，用
jsonb_set()替代全量覆盖，避免重写整字段（尤其对高频更新场景） - 如果字段含大量重复结构（如聊天消息列表），考虑反范式：拆成独立子表，用
message_id关联，而非塞进一个JSONB数组
Go 层如何安全路由大字段读写路径
不是所有字段都该进主表，也不是所有大内容都要“分片”。关键是让 Go 代码在写入前就决策：存 DB 还是存对象存储？存哪张物理表？用什么压缩/编码？
立即学习“go语言免费学习笔记（深入）”；
- 定义统一接口：
type BlobStore interface { Put(key string, data []byte) error; Get(key string) ([]byte, error) }，实现 S3、本地文件、甚至 Redis - 在业务逻辑里判断：
if len(msg.Content) > 512*1024 { store.Put(hash, msg.Content); msg.ContentRef = hash } - 查询时透明还原：
if msg.ContentRef != "" { msg.Content, _ = store.Get(msg.ContentRef) }，避免 N+1 查询 - 绝不把大字段当普通参数拼进
INSERT—— pgx 的CopyFrom不支持JSONB大对象，MySQL 的LOAD DATA也不处理嵌套结构，必须提前切分或转储
最容易被忽略的点：大字段的「可检索性」和「一致性」无法靠分片补救。你把一个 50MB 的 PDF 元数据分到 10 张表，它还是没法被全文搜索；你把日志按天分区，但单条日志超限照样写不进。真正的分片，是从设计第一行结构时就拒绝让它长大。
