必须显式开启PrepareStmt: true，GORM默认不启用；开启后对重复结构SQL预编译一次、后续仅绑定参数，省去解析与优化开销，提升高频查询与批量写入性能，并依赖合理连接池配置才能有效复用句柄。
必须显式开启，GORM 默认不启用 PrepareStmt，否则所有查询仍是普通语句，无法复用执行计划、也起不到防注入加固作用。
为什么 PrepareStmt: true 能提升性能
开启后，GORM 会把相同结构的 SQL（如 SELECT * FROM users WHERE id = ?）编译一次，后续调用只绑定参数，省去语法解析、查询优化等开销。尤其在高频单点查询（如用户详情页）、批量写入场景下，QPS 提升明显。MySQL 服务端也会缓存预编译语句句柄，减少锁竞争。
注意：它不是“开关一开就全局加速”，效果取决于查询模式是否重复。若每条 SQL 的 WHERE 条件字段、数量、顺序都不同（比如动态拼接的搜索接口），预编译收益会下降，甚至因句柄缓存占用反而略增内存。
正确配置 PrepareStmt 的方式
仅在 gorm.Config 中设置 PrepareStmt: true 不够——你还得确保底层 *sql.DB 的 SetMaxOpenConns 和 SetMaxIdleConns 合理，否则连接池争抢会导致预编译句柄复用失败。
- 使用
mysql.Open(dsn)初始化时，DSN 必须含parseTime=true和loc=Local，否则时间类型预编译可能出错 -
PrepareStmt是gorm.Config级配置，不能运行时动态开关；重启服务才生效 - 若用连接池（如
sql.DB自带池），建议SetMaxIdleConns≥ 5，避免空闲连接被回收导致预编译失效
示例配置片段：
db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{
PrepareStmt: true,
Logger: logger.Default.LogMode(logger.Info),
})
if err != nil {
panic(err)
}
sqlDB, _ := db.DB()
sqlDB.SetMaxOpenConns(100)
sqlDB.SetMaxIdleConns(20)
容易忽略的兼容性问题
PrepareStmt: true 在某些旧版 MySQL 驱动或低版本 MySQL（ERROR 1243 (HY000): Unknown prepared statement handler。这不是 GORM bug，而是服务端未正确维护句柄状态。
- 确认驱动版本：必须用
gorm.io/driver/mysql（非已弃用的github.com/go-sql-driver/mysql） - MySQL 版本建议 ≥ 5.7.7，8.0+ 更稳妥
- 若用 ProxySQL 或某些数据库中间件，需检查其是否透传预编译协议（部分中间件会降级为普通查询）
另外，Preload 多级关联 + PrepareStmt 组合时，GORM v1.23+ 才完全支持每个子查询独立预编译；v1.22 及更早版本中，只有主查询走预编译，关联查询仍为普通语句。
真正关键的不是“开了没”，而是“开了之后有没有被实际复用”——建议上线后抓包观察 MySQL 的 COM_STMT_PREPARE 和 COM_STMT_EXECUTE 比例，或者查 performance_schema.prepared_statements_instances 表确认句柄存活数。否则只是徒有其表。
