查不到慢查询日志需先开启gorm带执行时间的日志，设log.level为info或更低；db.find()易全表扫描，存在性判断应优先用first()或exists；定位缺失索引看rowsexamined远大于返回行数；函数、or、前导like等写法会导致索引失效，须改用范围查询等方案。
查不到慢查询日志？先确认 GORM 日志开关和级别
默认情况下，GORM 不输出 SQL 执行耗时，你看到的只是语句本身，没有时间戳。光看 SELECT * FROM users WHERE name = ? 没用，得知道它跑了 1200ms 还是 2ms。
实操建议：
- 启用带执行时间的日志：在初始化
GORM时传入logger.New()，并确保log.Level设为logger.Info或更低（Debug更全） - 别依赖
db.Debug()临时开启——它只影响单次调用，线上排查时基本没用 - 生产环境慎用完整 SQL 日志（含参数），避免敏感信息泄露；可用
logger.Default.LogMode(logger.Info)+ 自定义日志器过滤参数
DB.Find() 和 DB.Where().First() 性能差异在哪？
表面看都是查一条记录，但底层行为不同：Find() 默认走全表扫描+内存过滤（尤其配合 Preload 时），而 First() 强制加 LIMIT 1 且更早触发索引下推。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 用
db.Where("status = ?", "active").Find(&users)查“是否存在活跃用户”，结果查出全部活跃记录再取第一个，数据库压力大、延迟高 - 用
db.First(&user, "email = ?", email)却没给email字段建索引，导致全表扫描
实操建议：
- 判断存在性用
db.Where(...).Select("id").Limit(1).Scan(&id)或原生EXISTS子查询，不加载整行 - 主键或唯一字段查找优先用
First()/Take()，非唯一字段必须确认对应列有索引
怎么从 GORM 日志里快速定位缺失索引？
关键不是看 SQL 写得漂不漂亮，而是看执行计划有没有走索引。日志里出现 RowsExamined: 124832 而只返回 1 行，基本可以断定缺索引。
使用场景：
- 慢查询日志中反复出现某类
WHERE条件（如WHERE tenant_id = ? AND status = ?） -
ORDER BY created_at DESC LIMIT 20在数据量大时变慢，但created_at没单独索引
实操建议：
- 用
EXPLAIN ANALYZE（PostgreSQL）或EXPLAIN FORMAT=JSON（MySQL）直接跑日志里的 SQL，重点看type是否为range/ref，而非ALL - 复合索引顺序很重要：
tenant_id必须放最左，status才能被用上；created_at单独建索引对ORDER BY ... LIMIT更有效 -
GORM的Scopes或动态Where容易拼出无法复用索引的条件（比如OR、函数包裹字段），这类要单独拎出来优化
加了索引还是慢？检查 GORM 自动生成的 SQL 是否破坏索引使用
索引建了，EXPLAIN 也显示用了，但查询还是慢——大概率是 GORM 在 SQL 里悄悄加了东西，让索引失效。
典型问题：
-
db.Where("DATE(created_at) = ?", today).Find(&posts)：函数作用于字段，索引失效 -
db.Where("name LIKE ?", "%"+keyword+"%")：前导通配符，无法用 B-Tree 索引 -
db.Joins("JOIN profiles ON users.id = profiles.user_id").Where("profiles.age > ?", 18)：如果profiles.user_id没索引，JOIN 就成瓶颈
实操建议：
- 把
DATE(created_at)改成范围查询：created_at BETWEEN ? AND ? - 前缀模糊搜用
name LIKE ?（keyword + "%"），全文搜考虑tsvector或外部搜索引擎 - 所有 JOIN 字段、
GROUP BY字段、ORDER BY字段，只要参与过滤/排序，都得进索引评估范围
索引不是加了就完事，GORM 的链式调用和自动补全容易掩盖真实执行路径。最可靠的验证方式，永远是把日志里的 SQL 拿到数据库里跑一遍 EXPLAIN，而不是凭感觉调参。
