数据库 on 姚玉亮的网络日志

分库分表设计：支付与认证场景的水平拆分经验

Fri, 12 Dec 2025 10:30:00 +0800

单表数千万行之后

统一支付平台的订单表和统一认证中心的登录日志表，都长到了单表数千万行。订单查询开始吃紧，日志写入也开始吃紧。

这两张表气质完全不同。订单是按商户维度的高并发写入，登录日志是按用户和时间的海量追加写入。访问模式不同，分片策略就不能套同一个模板。

按商户切订单，按用户切日志

订单表按 merchant_id 哈希，16 库 × 8 表，一共 128 张。商户维度的查询（订单列表、对账）天然落在一个分片内。跨商户的后台统计走 MySQL 到 StarRocks 的离线同步，不做强一致跨片 JOIN。

登录日志按 user_id 分库、再按月份分表。「查某用户最近的登录」落在单片；按月归档清理直接处理整月表，两头都方便。

主键统一用 Snowflake。订单号里嵌入了商户分片位，解析订单号就能直接路由，不用二次查路由表。

订单号里藏着路由

真实项目里我们用 GORM 的 sharding 插件加自研 Resolver，下面是核心路由逻辑的简化版：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


const (
 dbCount = 16
 tableCount = 8
)

func OrderShard(merchantID int64) (db, table int) {
 db = int(merchantID % dbCount)
 table = int(merchantID / dbCount % tableCount)
 return
}

type Order struct {
 ID int64 `gorm:"primaryKey"`
 OrderNo string `gorm:"size:32;uniqueIndex"`
 MerchantID int64 `gorm:"index"`
 Amount int64
 Status int
 CreatedAt time.Time
}

func (o *Order) TableName() string {
 _, t := OrderShard(o.MerchantID)
 return fmt.Sprintf("order_%02d", t)
}

业务侧解析订单号即可路由：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// 订单号 = 13位毫秒时间戳 + 3位商户分片位 + 5位序列号
func GenOrderNo(merchantID, seq int64) string {
 return fmt.Sprintf("%d%03d%05d",
 time.Now().UnixMilli(), merchantID%1000, seq%100000)
}

func RouteOrderNo(orderNo string) (db, table int) {
 if len(orderNo) < 16 {
 return 0, 0
 }
 bucket, _ := strconv.ParseInt(orderNo[13:16], 10, 64)
 db = int(bucket % dbCount)
 table = int(bucket / dbCount % tableCount)
 return
}

登录日志按月分表：

1
2
3


func LoginLogTable(ts time.Time) string {
 return "login_log_" + ts.Format("200601")
}

坑一个一个说

第一个坑是分片键。一旦选错，代价极大。订单按 merchant_id 分片之后，C 端「查我的订单」会变成广播查询。我们的做法是订单再冗余一份按 user_id 分片到查询库（通过 Canal 同步），复杂检索直接走 ES。别指望一个分片键满足所有查询。

第二，跨片事务尽量避免。订单和账户余额落在同一商户分片内，本地事务就够；跨片的清结算用本地消息表保证最终一致，不上 XA。

第三，分库数量提前规划，但别过度。16 库是按未来几年容量估的，扩容用翻倍法（16→32），配合双写加数据校对平滑迁移。

第四，Snowflake 要防时钟回拨。NTP 同步打底，小幅回拨直接拒绝请求，宁可让调用方重试，也不能吐出重复 ID。

第五，跨片分页是噩梦。LIMIT 100000,20 会在每个分片都执行再归并，我们强制查询带时间范围和分片键，并限制深翻页。

第六，数据迁移必须能回滚。新流量双写新旧库，对账任务比对两边，一致后切读，最后停旧写。每一步都要退得回来。

后来

分库分表是「先苦后甜」，苦的不是中间件配置，是想清楚四件事：按什么维度分片、哪些查询必须落在单片、跨片查询去哪查、未来怎么扩容。统一支付平台和统一认证中心两个场景，这四件事的答案就完全不一样。

封面图：mikecogh / Flickr · CC BY-SA 2.0

MySQL 复杂查询优化：从 EXPLAIN 到索引重构

Wed, 26 Nov 2025 10:30:00 +0800

一个 5 秒的检索接口

数据治理服务里有个数据资产检索页，支持按租户、数据集类型、更新时间区间、关键词多条件筛选。底表是几百万行的 dataset 表，还要 LEFT JOIN owner 表拿负责人名字。上线初期一个查询要 3 到 5 秒，ELK 里慢查询日志刷屏。我负责这次优化，目标定得比较克制：不改业务语义，把 P95 压到 500ms 以内。

EXPLAIN 先说话

先跑 EXPLAIN 看执行计划，问题直接摆在脸上：type=ALL 的全表扫描，外加 Using filesort。几百万行先全扫一遍再排一次序，5 秒就是这么烧掉的。

我的思路分四块：为高频过滤条件建联合索引，让 WHERE 和 ORDER BY 走同一棵 B+Tree；LIKE '%关键词%' 这种模糊匹配 MySQL 帮不上忙，卸载给 ES；JOIN 只留必要的，被驱动表走主键；深翻页改成游标分页。

原始 GORM 查询长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


func SearchDatasets(db *gorm.DB, tenantID uint, typ string, from, to time.Time) ([]Dataset, error) {
 var list []Dataset
 err := db.Table("dataset d").
 Select("d.*, o.name as owner_name").
 Joins("LEFT JOIN owner o ON o.id = d.owner_id").
 Where("d.tenant_id = ? AND d.type = ? AND d.updated_at BETWEEN ? AND ?",
 tenantID, typ, from, to).
 Order("d.updated_at DESC").
 Limit(20).Find(&list).Error
 return list, err
}

EXPLAIN 结果（简化）：

1
2
3


id table type key rows Extra
1 d ALL NULL 820000 Using where; Using filesort
1 o eq_ref PRIMARY 1

问题很清楚：dataset 表全表扫外加 filesort。加联合索引：

1
2


ALTER TABLE dataset
ADD INDEX idx_tenant_type_updated (tenant_id, type, updated_at);

优化后让 GORM 走这个索引：

1
2
3
4
5
6
7


err := db.Table("dataset d FORCE INDEX (idx_tenant_type_updated)").
 Select("d.id, d.title, d.type, d.updated_at, d.owner_id, o.name as owner_name").
 Joins("LEFT JOIN owner o ON o.id = d.owner_id").
 Where("d.tenant_id = ? AND d.type = ? AND d.updated_at >= ? AND d.updated_at < ?",
 tenantID, typ, from, to).
 Order("d.updated_at DESC").
 Limit(20).Find(&list).Error

这里 FORCE INDEX 是有意的：统计信息不准的时候优化器会选错索引，干脆指定，不让它猜。

EXPLAIN 变成：

1
2
3


id table type key rows Extra
1 d range idx_tenant_type_updated 1200 Using index condition
1 o eq_ref PRIMARY 1

rows 从 820000 降到 1200，filesort 也消失了。

六个坑

第一个要认的是最左前缀。联合索引 (tenant_id, type, updated_at) 必须 tenant_id 打头才用得上。如果业务里 type 会单独查而 tenant_id 不一定传，就得评估再建一个 (type, updated_at)，别指望一个索引通吃所有查询。

第二，范围列放最后。updated_at 用了 BETWEEN / >= 之后，排在它后面的索引列就没法再用于定位了。不过排序还能吃到这里，所以 ORDER BY 的方向要和索引一致。

第三，LIKE '%xxx%' 走不了 B+Tree，这个没得商量。我们把标题、摘要同步到 ES，MySQL 只承担结构化过滤。异构索引听着重，其实就是让两个引擎各干各擅长的。

第四，别 SELECT *。PDF 解析出来的大 content 字段单独放从表或对象存储，列表查询只取需要的列，回表开销小一大截。

第五，索引不是越多越好。dataset 写入频繁，每加一个索引，写放大就多一分。我们控制在 5 个以内，定期用 pt-duplicate-key-checker 清理冗余。

第六是深翻页。LIMIT 100000, 20 会老老实实扫完前 10 万行再扔掉，改成基于上一页最后一条的 updated_at < ? 游标分页，翻得再深，成本也不涨。

后来

回头看，EXPLAIN 是基本功，重点盯 type、key、rows、Extra 四列；索引设计要贴着真实的 WHERE 和 ORDER BY 来，不是凭感觉给每个字段撒一遍。模糊搜索交给 ES，MySQL 只干它最擅长的结构化查询。这套组合在数据治理服务里稳定扛住了日常的数据资产检索。

封面图：David W. Siu / Flickr · CC BY 2.0

GaussDB 与 MongoDB 在数据集服务中的选型与应用

Thu, 24 Jul 2025 10:30:00 +0800

全塞 MySQL，两个问题都来了

数据集管理服务要管的东西很杂。一头是数据集本身，属性规整：所属团队、可见性、版本号、文件大小、创建时间、计费字段，全是结构化的。另一头是数据集下挂的文档解析结果，高度半结构化：不同来源的 PDF 抽出来的字段千差万别，有的带 DOI，有的带基金项目，有的带表格数据，schema 根本统一不了。

一开始我们图省事，全塞进 MySQL，解析结果用 JSON 列存。结果两个问题都来了：JSON 字段上的查询，要么扫表，要么得靠生成列建索引，写起来很别扭；解析任务又经常要回写嵌套很深的字段（比如某个 chunk 的 embedding 状态），行锁竞争明显。

于是我牵头做了一次存储选型。

两类数据，两个库

原则说白了就一条：让合适的数据库干合适的事。

GaussDB（华为系兼容 PostgreSQL 的关系库，客户侧有信创要求）存核心元数据：数据集、版本、文件、任务、团队配额、计费流水。这部分强一致、要事务、要复杂 JOIN，关系库是正解。

MongoDB 存文档解析结果和中间态：原始文本切片、chunk 元数据、抽取出来的实体和三元组、向量化任务的进度文档。schema 多变、写多读少、嵌套深，文档模型天然契合。

向量本身不进这两个库，走专用的向量库（Milvus 类），MongoDB 只存 chunk 到向量 ID 的映射。

一边建外键，一边嵌文档

GORM 接 GaussDB 走的是 PostgreSQL 驱动，DSN 和 PG 几乎一致：

1
2
3
4
5
6
7


import "gorm.io/driver/postgres"

dsn := "host=gaussdb.internal user=dataset password=*** port=5432 " +
 "dbname=dataset sslmode=disable TimeZone=Asia/Shanghai"
db, err := gorm.Open(postgres.Open(dsn), &gorm.Config{
 Logger: logger.Default.LogMode(logger.Warn),
})

核心元数据模型严格建外键和唯一索引：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


type Dataset struct {
 ID int64 `gorm:"primaryKey;autoIncrement:false"` // Snowflake
 TeamID int64 `gorm:"not null;index:idx_team"`
 Name string `gorm:"size:128;not null"`
 Visibility string `gorm:"size:16;not null"` // private/team/public
 CurrentVer int `gorm:"not null;default:1"`
 Status string `gorm:"size:16;not null"`
 CreatedAt time.Time
 UpdatedAt time.Time
}

type DatasetVersion struct {
 ID int64 `gorm:"primaryKey;autoIncrement:false"`
 DatasetID int64 `gorm:"uniqueIndex:idx_ds_ver"`
 Version int `gorm:"uniqueIndex:idx_ds_ver"`
 Manifest string `gorm:"type:jsonb"` // 文件清单
 Comment string `gorm:"size:512"`
}

新建数据集和版本是一个事务，保证不会出现"有数据集没版本"的中间态：

1
2
3
4
5


err := db.Transaction(func(tx *gorm.DB) error {
 if err := tx.Create(&ds).Error; err != nil { return err }
 ver := DatasetVersion{DatasetID: ds.ID, Version: 1, Manifest: manifest}
 return tx.Create(&ver).Error
})

MongoDB 侧用官方驱动，文档结构按"一个源文档一个 Document"组织：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


type ParsedDoc struct {
 ID primitive.ObjectID `bson:"_id,omitempty"`
 DatasetID int64 `bson:"dataset_id"`
 FileKey string `bson:"file_key"`
 Chunks []Chunk `bson:"chunks"`
 Entities []EntitySnapshot `bson:"entities,omitempty"`
 Extras bson.M `bson:"extras,omitempty"` // 来源相关的杂项字段
 ParseState string `bson:"parse_state"`
 UpdatedAt time.Time `bson:"updated_at"`
}

type Chunk struct {
 Ordinal int `bson:"ordinal"`
 Text string `bson:"text"`
 VecID string `bson:"vec_id,omitempty"`
 Status string `bson:"status"` // pending/vectorized/failed
}

更新某个 chunk 的向量化状态不需要拉回整文档，用位置运算符：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


filter := bson.M{
 "_id": docID,
 "chunks.ordinal": ord,
}
update := bson.M{
 "$set": bson.M{
 "chunks.$.status": "vectorized",
 "chunks.$.vec_id": vecID,
 "updated_at": time.Now(),
 },
}
_, err := coll.UpdateOne(ctx, filter, update)

先说事务，再说三个坑

事务是我们第一个想清楚的点。MongoDB 4.0 以后支持多文档事务，但性能开销不小。跨库一致性我们没有追强一致：GaussDB 里的"数据集版本"是权威状态，MongoDB 里的解析进度只是附属状态。Mongo 写失败就靠 Temporal Worker 重试，最终一致即可，不值得为它引入分布式事务。

第一个坑是 GaussDB 的 PG 兼容性。绝大多数语法和 PG 14 一致，但某些扩展（比如 pg_trgm）客户环境里不一定装了。我们本来想在数据集名字上做模糊搜索，用 trigram 索引，最后改成把搜索字段同步到 ES，数据库只做精确过滤。

第二个坑是 MongoDB 的文档膨胀。Chunks 数组一直 append，单文档逼近 16MB 上限。后来把 chunk 拆成独立集合 doc_chunks，用 doc_id 关联，反而查询和并发更新都更顺。嵌套文档用着顺手，但会无限增长的数组要警惕。

第三个坑在连接池。Hertz 服务同时连两个库，初期 Mongo 池子开太大，连接数被打满。把 Mongo 的 maxPoolSize 压到 100，GaussDB 侧用 GORM 的 SetMaxIdleConns/SetMaxOpenConns 控制，再配合 KubeSphere 的资源限额，才稳下来。

后来

回头看，这两个库在这个服务里各管一摊：强一致、要事务、要报表的核心元数据给 GaussDB；schema 多变、写多读少、嵌套深的解析中间态给 MongoDB。选型比的从来不是"哪个数据库更先进"，而是把数据按访问模式切开，让每一类数据落在它最舒服的存储里。

封面图：Laenulfean / Flickr · CC BY-SA 2.0