非索引字段执行select *会拖垮查询，因数据库必须全表扫描逐行过滤，i/o暴涨致响应从毫秒级升至秒级；gorm反射赋值、钩子调用及空关联字段初始化进一步加剧内存与cpu压力。
为什么非索引字段 SELECT * 会拖垮查询
当 db.Find(&users) 或 db.Select("*").Find(&users) 拉取大量记录，且 WHERE 条件字段没建索引时，数据库必须全表扫描——每行都读出来，再逐行过滤。50 万行表里查 name = 'Alice'，若 name 无索引，MySQL 就得扫完全部 50 万行；PostgreSQL 同理。这不是 GORM 的锅，但 GORM 默认不提醒你缺索引。
- 全表扫描导致磁盘 I/O 爆涨，尤其在机械盘或高并发场景下，响应时间直接从毫秒级跳到秒级
- GORM 还要为每行做反射赋值、类型转换、钩子调用（如
AfterFind），内存分配压力翻倍 - 如果结构体含未使用的关联字段（如
Orders []Order），即使没Preload，GORM 仍会初始化空切片，白占内存
db.Select() 只取必要字段真能省多少
能省掉 60%～90% 的网络传输和内存开销。比如用户表有 20 个字段，但列表页只展示 id、name、email，用 db.Select("id, name, email").Find(&users) 后：
- MySQL 返回的数据包体积下降约 75%，连接带宽压力骤减
- GORM 反射目标字段数从 20 降到 3，结构体初始化耗时减少 80%+（实测 10 万条下 GC 次数下降 40%）
- 注意：字段名必须拼写准确，大小写敏感；别写
db.Select("Name")（Go 字段名）而应写"name"（数据库列名） - 如果字段是表达式（如
CONCAT(first_name, ' ', last_name)），要用db.Raw()包裹，否则 GORM 会当列名处理报错
WHERE 字段没索引时，加 LIMIT 也救不了命
db.Where("description LIKE ?", "%urgent%").Limit(20).Find(&users) 看似安全，但只要 description 没索引，数据库仍得先扫完整张表，再丢弃前 N-20 行。LIMIT 是最后一步，不是过滤前置条件。
- 执行
EXPLAIN查看执行计划：如果type是ALL，基本就是全表扫描 - LIKE 前缀匹配（
"urgent%"）可走 B+ 树索引；但通配符在开头（"%urgent"）或中间（"%urgent%"）无法利用普通索引，需考虑全文索引（MySQLFULLTEXT）或 pg_trgm（PostgreSQL） - GORM 不会自动帮你建索引，模型里加
gorm:"index"只影响AutoMigrate，上线后新增字段必须 DBA 手动补
批量拉取非索引字段的替代方案
真没法加索引（比如日志表、动态配置表），又必须按非索引字段查大批量数据，别硬扛：
- 用
db.Raw()+ 流式Rows：绕过 GORM 反射，自己 scan 到轻量 struct 或[]map[string]interface{}，内存占用直降 70% - 把查询拆成两步：先用覆盖索引查主键（如
SELECT id FROM logs WHERE level = 'error' ORDER BY id LIMIT 1000），再用IN (id1,id2,...)拉详情——前提是主键有序且稳定 - 导出类场景改用
db.Table("users").Select("id,name,email").Rows()配合rows.Next()+rows.Scan()，避免一次性加载全部结果 - 高频非索引查询，考虑加物化视图或定时同步到搜索专用表（如 Elasticsearch），别让 OLTP 数据库背锅
GORM 不会替你决定哪些字段该索引、哪些不该查，它只负责把 Go 结构体和 SQL 行对齐。性能瓶颈卡在数据库层时，最有效的“优化”往往是一条 CREATE INDEX，而不是换 ORM 方法。
