MySQL on 姚玉亮的网络日志

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

MySQL + StarRocks 多数据源架构：数据仓库配置管理

Fri, 01 Nov 2024 10:30:00 +0800

一个库装不下两种负载

数据治理服务同时背两类数据访问。一类是在线交易：文件上传、元数据 CRUD、质量规则配置、任务状态流转，要低延迟、强事务，这是 MySQL 的主场。另一类是分析查询：按机构统计论文数量、按年份聚合发文趋势、质量规则的大表扫描，千万到亿级行的聚合，MySQL 跑到几十秒就受不了。

我们的解法是引入 StarRocks 做分析型数仓，MySQL 继续存权威交易数据，组成多数据源架构。要回答的是三个问题：代码里怎么清晰地路由查询，数据怎么从 MySQL 同步到 StarRocks，配置怎么统一管。

两个库，各干各的

MySQL：所有在线读写，权威库。GORM 访问，库表结构走 migration 版本化。
StarRocks：只跑 OLAP 查询，表模型按分析场景设计（主键模型做明细、聚合模型做汇总）。应用端用标准 database/sql + MySQL 驱动，StarRocks 协议兼容 MySQL。
同步：SeaTunnel 做 MySQL → StarRocks 的批量同步，按 updated_at 增量拉；实时性要求高的表（比如质量结果）走 Canal 订阅 binlog 写 StarRocks。
配置管理：各环境的数据源连接信息放配置中心，启动时构建 *gorm.DB 和 *sql.DB 两个单例，DAO 按职责显式依赖其中一个。

有一点是刻意选择的：没有用动态数据源切面（根据方法名前缀自动选库）那种魔法。每个 DAO 明确声明自己用哪个库，代码读起来啰嗦一点，但可预测。

两个数据源，显式注入

数据源初始化：

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


func NewMySQL(cfg Config) (*gorm.DB, error) {
 dsn := fmt.Sprintf("%s:%s@tcp(%s)/%s?charset=utf8mb4&parseTime=true&loc=Local",
 cfg.MySQL.User, cfg.MySQL.Password, cfg.MySQL.Addr, cfg.MySQL.DB)
 db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})
 if err != nil {
 return nil, err
 }
 sqlDB, _ := db.DB()
 sqlDB.SetMaxOpenConns(100)
 sqlDB.SetMaxIdleConns(20)
 return db, nil
}

func NewStarRocks(cfg Config) (*sql.DB, error) {
 dsn := fmt.Sprintf("%s:%s@tcp(%s)/%s?charset=utf8mb4&parseTime=true",
 cfg.StarRocks.User, cfg.StarRocks.Password,
 cfg.StarRocks.Addr, cfg.StarRocks.DB)
 db, err := sql.Open("mysql", dsn)
 if err != nil {
 return nil, err
 }
 db.SetMaxOpenConns(50)
 return db, nil
}

分析 DAO 直接用 *sql.DB：

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


type PaperStatDAO struct {
 sr *sql.DB
}

func (d *PaperStatDAO) YearTrend(ctx context.Context, tenantID int64) ([]YearCount, error) {
 rows, err := d.sr.QueryContext(ctx, `
 SELECT publish_year, COUNT(*) AS cnt
 FROM dwd_paper
 WHERE tenant_id = ? AND publish_year IS NOT NULL
 GROUP BY publish_year
 ORDER BY publish_year`, tenantID)
 if err != nil {
 return nil, err
 }
 defer rows.Close()

 var out []YearCount
 for rows.Next() {
 var y int
 var c int64
 if err := rows.Scan(&y, &c); err != nil {
 return nil, err
 }
 out = append(out, YearCount{Year: y, Count: c})
 }
 return out, nil
}

SeaTunnel 同步任务片段（HOCON 配置）：

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


source {
 MySQL-CDC {
 base-url = "jdbc:mysql://mysql:3306/dataservice"
 table-names = ["dataservice.file_objects", "dataservice.paper_meta"]
 username = "seatunnel"
 password = "${mysql_password}"
 }
}
sink {
 StarRocks {
 node-urls = ["starrocks-fe:8030"]
 base-url = "jdbc:mysql://starrocks-fe:9030"
 database = "dwh"
 table = "dwd_paper"
 username = "root"
 password = "${sr_password}"
 }
}

容易出的几类事故

别在 StarRocks 上做高频点查和单行更新。它是批量向量化引擎，高并发小查询性能反而不如 MySQL，主键模型的 Update 也是异步合并的，不适合交易场景，两类负载要严格分开。
同步有延迟，秒级到分钟级不等，产品和运营必须知道「StarRocks 的数据不是实时的」。我们在分析页面上显示「数据更新于 X 分钟前」，把话说在前面。
StarRocks 兼容 MySQL 协议，但 SQL 方言有差异：不支持外键、部分函数不同、DDL 语法也不一样。GORM 的 AutoMigrate 不能直接用在 StarRocks 上，建表语句单独维护。
多数据源最容易出的事故，就是「在事务里查了 StarRocks」或者「把分析 SQL 打到 MySQL」。代码评审时我们重点看 DAO 注入的是哪个 db，另外把 StarRocks 账号设成只读，误写也写不进去。
SeaTunnel 的 MySQL-CDC 依赖 binlog 格式为 ROW，账号还要有 REPLICATION 权限，这些得提前和 DBA 沟通好。

后来

MySQL + StarRocks 的组合，说白了就是让专业的引擎干专业的事：MySQL 扛交易，StarRocks 扛分析。这套架构里管用的就几件事：职责划分清楚，依赖显式注入，同步链路可靠，数据延迟也不藏着掖着。配置收口之后，新增一个分析查询就是写一个走 StarRocks DAO 的方法，和在线业务互不干扰。

封面图：U.S. Army Corps of Engineers Savannah District / Flickr · CC BY 2.0