必须用 execute()，query() 默认不预编译且易致注入；execute() 强制服务端预编译、参数与结构分离，需白名单校验动态表名列名，严防类型错位与事务混用。
mysql2 的 query() 和 execute() 到底该用哪个
直接结论：必须用 execute()，别碰带字符串拼接的 query()。mysql2 的 query() 默认不启用预编译，即使传入参数数组，底层仍可能做字符串插值（尤其在含动态表名/列名时）；而 execute() 强制走服务端预编译，SQL 结构和参数彻底分离。
常见错误现象：query("SELECT * FROM users WHERE id = ?", [userId]) 看似安全，但若 userId 是 "1 OR 1=1" 且驱动未开启 permitLocalFileAccess: false 或 MySQL 配置宽松，仍有风险；更危险的是 query(`SELECT * FROM ${tableName}`, ...) —— 这种动态表名根本无法参数化，execute() 也救不了。
-
execute()要求 SQL 字符串里只出现?占位符，不能有模板字符串拼接 - 连接选项必须显式设置
namedPlaceholders: false（默认是false，但显式声明可防误开） - 首次调用
execute()会触发 PREPARE，后续同结构查询复用执行计划，性能略优
动态表名或列名怎么处理才不炸
预编译机制天生不支持参数化表名、列名、排序字段（如 ORDER BY ? 会被当成字符串字面量）。硬塞进去只会查不到数据或报错 ER_PARSE_ERROR。
正确做法是白名单校验 + 字符串拼接（仅限此场景）：
- 把允许的表名存进常量数组，用
includes()严格比对：const allowedTables = ["users", "orders"]; if (!allowedTables.includes(userInputTable)) throw new Error("Invalid table"); - 列名同理，排序字段用映射对象转换：
const sortMap = { created: "created_at", name: "full_name" }; const safeSort = sortMap[userSort] || "id"; - 拼接后仍需过一遍正则：
/^[a-zA-Z0-9_]+$/，拒绝任何符号（特别是反引号、点号、空格）
参数类型错位导致查询无声失败
mysql2 对 JavaScript 类型到 SQL 类型的隐式转换很敏感。比如把布尔值 true 当作整数传给 TINYINT(1) 字段没问题，但传给 VARCHAR 就变成字符串 "true"，可能匹配不到预期记录。
容易踩的坑：
-
NULL和undefined行为不同：undefined会被转成NULL，但某些 ORM 层会过滤掉undefined字段，导致 WHERE 条件缺失 - Date 对象传入后变成 UTC 时间戳，若数据库时区是 CST，可能差 8 小时 —— 建议统一用
toISOString().slice(0, 19).replace('T', ' ')格式化后再传 - 大数字（如雪花 ID）超出 JavaScript 安全整数范围时，
execute()可能截断末位 —— 必须以字符串形式传入
事务中混用 query() 和 execute() 的陷阱
在同一个事务连接里交替使用两个方法，可能导致预编译语句句柄泄漏或执行上下文错乱。MySQL 服务端对每个连接的 PREPARE 句柄有上限（默认 max_prepared_stmt_count=16382），撑满后新 execute() 会报错 ER_TOO_MANY_CONCURRENT_STMTS。
实操建议：
- 事务内所有查询统一用
execute()，禁用query() - 连接池配置加
resetAfterUse: true，确保每次取连接都重置状态 - 监控慢查询日志里的
Prepare和Execute语句，发现非预期的 PREPARE 频次飙升要立刻排查
预编译不是银弹，它只解决参数注入，对逻辑漏洞（比如越权查他人订单）和动态结构拼接无能为力。白名单校验和类型守卫得写在业务层最外侧，别指望驱动替你兜底。
