PrepareStmt 加速 GORM 查询的根本原因是复用数据库端预编译语句，跳过每次 SQL 解析与优化，实现“一次编译、多次执行”，实测性能提升 40%+；它由驱动层自动管理，无需手动 Close，但仅对参数化查询生效，且需配合 SetConnMaxLifetime 等连接池参数防句柄泄漏。
PrepareStmt 为什么能让 GORM 查询更快
根本原因在于：GORM 开启 PrepareStmt:true 后，会复用数据库服务端的预编译语句（Prepared Statement），跳过每次执行时的 SQL 解析、语法树生成、查询优化等步骤。实测重复查询性能提升 40%+，不是靠 Go 层缓存，而是靠 MySQL 等数据库原生的执行计划复用。
关键点在于「一次编译、多次执行」：首次执行 SELECT * FROM users WHERE id = ? 时，MySQL 完成完整解析并生成执行计划；后续相同模板的查询直接绑定新参数、走已编译路径，省掉约 60–80% 的单次 SQL 处理开销。
GORM 的 PrepareStmt 和原生 db.Prepare 有什么区别
GORM 的 PrepareStmt 是在驱动层自动管理的，它不暴露 *sql.Stmt 对象，也不需要你手动调用 Close()；而原生 db.Prepare() 要求你显式创建、复用、关闭，否则会快速耗尽 MySQL 的 max_prepared_stmt_count（默认 16382）——这点 GORM 自动规避了。
但要注意：GORM 的 PrepareStmt 只对参数化查询生效（如 Where("id = ?", 123)），对动态拼接的 SQL（如 Where("id = " + strconv.Itoa(id))）完全无效，且无法处理表名、列名等标识符。
- ✅ GORM
PrepareStmt:true：自动复用、无需 Close、适配所有支持预编译的驱动（MySQL/PostgreSQL） - ❌ 原生
db.Prepare在循环里反复调用：触发ERROR 1461，连接句柄泄漏 - ⚠️ GORM 不支持
PreparedStmt绑定表名：分表场景仍需白名单校验后字符串拼接
开启 PrepareStmt 后必须配哪些连接池参数
只开 PrepareStmt:true 不调连接池，反而容易出问题——预编译语句绑定在具体连接上，若连接被回收而语句未清理，MySQL 会保留无用句柄直至超时。所以必须同步配置底层 *sql.DB 的生命周期控制：
-
sqlDB.SetMaxIdleConns(20)：空闲连接数建议设为 CPU 核心数 × 2，避免频繁新建连接导致 Prepare 开销摊薄 -
sqlDB.SetMaxOpenConns(100)：峰值并发高时需调大，否则连接争抢会导致 Prepared Stmt 分配不均 -
sqlDB.SetConnMaxLifetime(time.Hour)：强制一小时后重建连接，让旧连接上的预编译句柄自然释放，防内存泄漏
漏掉 SetConnMaxLifetime 是生产环境最常被忽略的点：长时间运行后，MySQL 的 SHOW PREPAREDS 会堆积上千条 stale stmt，拖慢整个实例。
为什么 Find() 查不到数据却和 PrepareStmt 有关
无关。这是两个独立机制：Find() 忽略零值是 GORM 的默认行为（如 int 字段传 0 就不进 WHERE），而 PrepareStmt 只影响 SQL 执行路径。但二者叠加会放大问题——比如你传了 id=0，Find() 直接跳过该条件，生成的 SQL 变成 SELECT * FROM users，再经预编译执行，结果就是全表扫描。
真正要查 id=0，必须显式用 Where("id = ?", 0) 或关掉零值过滤（不推荐）。别指望 PrepareStmt 能修正语义错误。
预编译再快，也救不了写错的 WHERE 条件。
