GORM框架下数据库索引失效的排查过程-Golang-PHP中文网

索引失效本质是“未被使用”，需通过explain验证：key为空、type为all、extra含using filesort即表明未走索引；类型不匹配、复合索引顺序错、游标字段无索引或类型不符，均导致静默失效。

gorm框架下数据库索引失效的排查过程

索引失效不是“有没有建”，而是“用没用上”——GORM 生成的 SQL 很可能根本没走你自以为有效的索引。必须跳出 Go 代码，直接进数据库看 EXPLAIN 输出。

GORM 的 Logger 只打印 SQL 和耗时，不告诉你执行路径。慢查询真正卡在哪，得靠数据库原生执行计划。

在 MySQL 中运行：EXPLAIN FORMAT=JSON SELECT * FROM orders WHERE status = 'paid' ORDER BY created_at DESC LIMIT 20 OFFSET 1000，重点看 key（是否为空）、type（ALL 就是全表扫描）、Extra（含 Using filesort 或 Using temporary 都危险）
PostgreSQL 用：EXPLAIN (ANALYZE, BUFFERS) SELECT ...，关注 Index Scan 是否出现、Rows Removed by Filter 是否过高
别只查一次：GORM 的 Preload、Joins、Scopes 会拼出不同 SQL，每种组合都要单独 EXPLAIN

Go 传参是 int64，数据库字段是 INT，看着一样——但如果你用 Where("user_id = ?", "123")（字符串），MySQL 就会隐式转成 CAST(user_id AS CHAR)，索引立刻作废。

GORM框架 1.30.3

GORM框架 1.30.3版本源码包下载，版本号 1.30.3，适合在 1.30 主线早期节点做源码留档、依赖回放和升级前后行为对照。

下载

先确认字段类型：DESCRIBE orders 查 user_id 实际类型，再比对 Go 里传的是 int64 还是 string
GORM 中避免字符串拼接条件：Where("user_id = ?", strconv.Itoa(id)) 是错的；应写 Where("user_id = ?", id)（id 是整型变量）
更安全的做法：用结构体绑定，让 GORM 自动推导类型，比如 db.Where(&Order{UserID: 123}).Find(&orders)

建了 (status, created_at) 索引，但查询是 WHERE created_at > '2025-01-01' ORDER BY created_at —— MySQL 无法跳过第一列 status 直接用第二列，索引完全失效。

索引字段顺序必须严格匹配查询模式：要支持 WHERE status = ? AND created_at > ? ORDER BY created_at，索引就得是 (status, created_at)
如果业务同时需要 WHERE status = ? 和 WHERE created_at > ?，别指望一个复合索引覆盖全部，老老实实多建一个 created_at 单列索引
用 EXPLAIN 的 key_len 值验证：比如 key_len = 4 表示只用了索引前 4 字节（可能是第一列），key_len = 0 就等于没用上

用 WHERE id > ? ORDER BY id LIMIT 20 替换 LIMIT/OFFSET 是对的，但如果 id 字段没索引，或 id 是字符串类型而你传了数字，照样全表扫。

游标值必须是索引字段的精确值，且类型一致：若 id 是 BIGINT，就传 int64，别传 string 或 float64
不要用非主键字段做游标（如 created_at），除非它有高选择性且已建索引；重复值会导致漏数据或重复返回
GORM 中慎用 Where("id > ?", lastID).Order("id").Limit(20) —— 检查生成的 SQL 是否真用了索引，别被“看起来像分页”骗了

最常被忽略的一点：索引建完不等于生效。GORM 的 AutoMigrate 不会重建已有索引，也不会提示你“这个索引和现有查询不匹配”。每次加新查询逻辑，都得重新跑一遍 EXPLAIN，而不是只看表结构有没有那个索引名。