PDO::execute()多次调用比拼接SQL快，因预处理仅编译一次，后续仅传参，省去解析、权限检查等开销，性能提升3–10倍；须将prepare()置于循环外、启用原生预处理并包裹事务。
为什么 PDO::execute() 多次调用比拼 SQL 字符串快
因为预处理语句（PDO::prepare()）只编译一次，后续 execute() 只传参数，省去 SQL 解析、权限检查、执行计划生成等开销。尤其在插入几百条以上数据时，性能差距明显——不是“稍微快点”，是 3–10 倍差异。
常见错误现象：PDO::prepare() 写在循环里，每次插入都重新 prepare，反而比拼接 SQL 还慢；或者没设 PDO::ATTR_EMULATE_PREPARES = false，导致 MySQL 实际没走预处理。
- 必须把
prepare()放在循环外，只调用一次 - 确保数据库支持原生预处理：MySQL 5.1.17+ 且
PDO::ATTR_EMULATE_PREPARES设为false（默认可能为true） - 如果用 SQLite 或旧版 MySQL，模拟预处理也 OK，但别误以为“已经原生了”
怎么写安全又高效的批量插入循环
核心就一条：用单条带占位符的 INSERT + 多次 execute()，不拼字符串、不手写 (?, ?, ?) 模板。
使用场景：导入 CSV、API 批量写入、后台任务中逐条校验后入库。
立即学习“PHP免费学习笔记（深入）”；
示例（插入用户数据）：
$stmt = $pdo->prepare("INSERT INTO users (name, email, status) VALUES (?, ?, ?)");
foreach ($data as $row) {
$stmt->execute([$row['name'], $row['email'], $row['status']]);
}
- 占位符统一用
?，别混用:name命名参数——除非你真需要按字段名绑定，否则增加心智负担 - 每轮
execute()传数组，顺序必须和 SQL 中?位置严格一致 - 如果某次
execute()报错（如唯一键冲突），默认会中断循环；加try/catch可跳过单条失败
大批量时为什么不能无脑 execute 循环
当插入上万条，单纯循环 execute() 会暴露两个隐形瓶颈：事务开销和网络往返延迟。
性能影响：默认每条 execute() 都是一次独立事务（如果没显式开启事务），MySQL 要刷日志、锁表、同步 binlog，吞吐直接掉 70% 以上。
- 务必手动包裹事务：
$pdo->beginTransaction()开头，$pdo->commit()结尾 - 每 500–2000 条做一次
commit（别等全部跑完），防内存溢出或超时；具体数值看单条数据大小和服务器配置 - 避免在循环里调用
$stmt->rowCount()—— 它可能触发额外查询，拖慢整体速度
遇到 SQLSTATE[HY000]: General error: 2006 MySQL server has gone away 怎么办
这是典型连接超时或包过大触发的错误，批量插入时高频出现，不是代码写错了，而是 PDO 连接被服务端主动断开了。
根本原因：MySQL 的 wait_timeout 或 max_allowed_packet 不足，而长事务 + 大量 execute() 让连接空闲太久或单次参数超限。
- 插入前检查并临时调大：执行
$pdo->exec("SET SESSION wait_timeout = 28800") - 拆分批次：不要单次循环 10 万条，改用每 1000 条一个子循环 +
commit - 确认
max_allowed_packet≥ 单条最大参数序列化后长度（比如含长文本字段时）
真正麻烦的是跨进程/长时间运行脚本里的连接复用——PDO 连接不会自动重连，得自己捕获异常后重建 $stmt 和重试逻辑。这点容易被忽略，一跑几小时的任务中途挂掉，就卡在这儿。
