mysqli_multi_query一次执行多条INSERT不一定提速，仅适用于彼此独立的预定义SQL；批量插入应优先用单条INSERT多VALUES语法，安全高效。
mysqli_multi_query 一次执行多条 INSERT 是否真能提速？
不能一概而论。它确实避免了多次网络往返，但前提是所有语句都走同一条连接、且不依赖前一条的返回值（比如自增 ID）。如果每条 INSERT 都要等上一条执行完再拼下一条，用 mysqli_multi_query 反而容易出错，不如老实用 INSERT INTO ... VALUES (...), (...), (...) 批量写入。
常见错误现象：mysqli_multi_query() 返回 true，但后续 mysqli_store_result() 或 mysqli_next_result() 没跟上，导致只取到第一条结果，其余被丢弃或阻塞；或者把带变量拼接的多条 SQL 直接塞进去，触发 SQL 注入。
- 真正适合它的场景是：预定义好的、彼此独立的 DML（如多张配置表初始化）或 DDL + DML 组合（如先
CREATE TEMPORARY TABLE再INSERT） - 不要用它来“循环拼 SQL 字符串再一次性执行”——这等于把应用层的逻辑错误转移到了 SQL 层
- 每调用一次
mysqli_multi_query()后，必须用mysqli_store_result()清空当前结果集，再用mysqli_next_result()跳到下一条，否则后续查询会失败
批量 INSERT 更稳更快的写法：VALUES 多值语法
95% 的批量插入需求，应该优先用单条 INSERT 带多组 VALUES。MySQL 服务端原生支持，解析快、锁粒度更优、事务回滚成本低。
示例：
立即学习“PHP免费学习笔记（深入）”；
INSERT INTO users (name, email) VALUES ('Alice', 'a@b.c'), ('Bob', 'b@c.d'), ('Charlie', 'c@d.e');
注意点：
- 单次插入行数别超过 1000 行，否则可能触发
max_allowed_packet限制（默认 4MB），报错MySQL server has gone away - 字段名必须显式写出，不能省略——尤其当表有
NOT NULL DEFAULT或自增主键时，隐式列序容易错位 - 字符串值必须用单引号包裹，且内容需经
mysqli_real_escape_string()或更推荐的mysqli_prepare()+bind_param()处理
用 mysqli_prepare + bind_param 插入动态数据时的坑
这是最安全的批量方式，但很多人卡在参数绑定上：bind_param() 不接受数组，也不能在循环里反复绑定同一套变量地址而不重置。
典型错误：
- 循环中重复调用
$stmt->bind_param('ss', $name, $email)，但$name和$email是引用，值变了，指针没变——看起来能跑，实则最后一组数据覆盖全部 - 用
s类型绑定整数字段（如status TINYINT），导致隐式类型转换失败或截断 - 没检查
$stmt->execute()返回值，失败时静默跳过，数据实际没进库
正确做法是：每次循环前确保变量已赋新值，并确认类型标记（i 对应整数，d 对应浮点，s 对应字符串）与字段定义一致。
为什么不要在 PHP 循环里反复调用 mysqli_query
不是语法错，是性能和稳定性双杀。每次 mysqli_query() 都触发一次客户端→服务端的完整请求/响应周期，含 TCP 包往返、SQL 解析、权限校验、锁获取、日志写入……100 条记录 = 100 次开销。
更隐蔽的问题：
- 高并发下容易触发 MySQL 的
max_connections限制，报错Too many connections - 事务控制失效：想用一个事务包住全部插入，但循环中没显式
mysqli_begin_transaction()和统一commit/rollback，出错就部分写入 - 错误定位难：第 87 条失败，你得翻日志或加调试才能知道是哪条数据、哪个字段、什么约束冲突
批量插入的本质不是“少写几行代码”，而是让数据库一次吞下结构清晰、边界明确的数据块。越早把拼 SQL 的逻辑收口到数据准备阶段，后面越不容易掉坑里。
