单条insert循环写订单日志在高并发下易致数据库瓶颈，应改用批量insert（500–1000行/批）或load data infile（超10万行），配合预处理防注入、utf8mb4支持emoji、事务补偿与失败重试机制。
为什么不能用单条 INSERT 循环写订单日志
每笔订单生成时顺带写一条日志，看似简单，但高并发下单（比如秒杀）下，单条 INSERT 会迅速成为数据库瓶颈：连接频繁开闭、事务开销大、磁盘 I/O 暴增，还容易触发 MySQL 的 max_connections 限制或锁等待超时。
更关键的是，日志表通常无业务强一致性要求，没必要为每条日志单独事务——批量写入 + 异步落盘才是合理路径。
- 单条
INSERT在 1000 笔订单下可能耗时 >3s；批量INSERT ... VALUES (...), (...), (...)可压至 200ms 内 - PHP 进程中拼接 SQL 要注意
mysql_real_escape_string已废弃，必须用预处理或mysqli::real_escape_string - 若日志含用户输入字段（如备注），不转义直接拼 SQL 会引发注入
用 INSERT INTO ... VALUES 批量拼接最稳
这是兼容性最好、执行效率最高、且无需额外扩展的方式。核心是控制单次批量大小（建议 500–1000 行），避免 SQL 过长触发 max_allowed_packet 截断。
示例：将待写日志数组 $logs 拆成批次，每批 800 条
立即学习“PHP免费学习笔记（深入）”；
$batchSize = 800;
$chunks = array_chunk($logs, $batchSize);
foreach ($chunks as $chunk) {
$values = [];
$params = [];
foreach ($chunk as $log) {
$values[] = '(?, ?, ?, ?)';
$params[] = $log['order_id'];
$params[] = $log['status'];
$params[] = $log['remark'];
$params[] = date('Y-m-d H:i:s');
}
$sql = "INSERT INTO order_log (order_id, status, remark, created_at) VALUES " . implode(', ', $values);
$stmt = $pdo->prepare($sql);
$stmt->execute($params);
}
- 务必用
?占位符 +execute()，不用字符串拼接值 -
array_chunk比手动 for 循环更安全，避免越界或漏项 - 如果表有自增主键，不要在
VALUES中显式插入id字段
用 LOAD DATA INFILE 写超大批量日志（>10 万行）
当订单日志需离线补录或后台定时归档（如从 Kafka 或文件读取），LOAD DATA INFILE 是 MySQL 原生命令，速度比批量 INSERT 快 5–10 倍。
前提：PHP 进程有文件写权限，MySQL 开启 local_infile=ON，且用户有 FILE 权限
$tempFile = '/tmp/order_log_' . uniqid() . '.csv';
file_put_contents($tempFile, '');
$fp = fopen($tempFile, 'a');
foreach ($logs as $log) {
fputcsv($fp, [
$log['order_id'],
$log['status'],
addslashes($log['remark']), // 简单转义，避免 CSV 解析错位
date('Y-m-d H:i:s')
]);
}
fclose($fp);
$sql = "LOAD DATA LOCAL INFILE '$tempFile'
INTO TABLE order_log
FIELDS TERMINATED BY ','
OPTIONALLY ENCLOSED BY '\"'
LINES TERMINATED BY '\n'
(order_id, status, remark, created_at)";
$pdo->exec($sql);
unlink($tempFile);
-
fputcsv自动处理引号和逗号，比手拼更可靠 - 注意
addslashes仅用于 CSV 字段内双引号/换行等，不是防 SQL 注入——这里 SQL 是固定结构，变量只在文件内容里 - 生产环境禁用
LOCAL INFILE时，此方案不可用，得退回批量INSERT
别忽略事务与错误恢复逻辑
批量写入不是“一气呵成就完事”。订单主流程成功但日志写失败，会导致排查断层；反之日志写成功但订单失败，又产生脏数据。必须明确补偿边界。
- 订单创建和日志写入**不同库/不同事务**：日志走异步消息（如 RabbitMQ）或延迟队列更稳妥
- 若坚持同步写，至少给批量操作加
try/catch，记录失败批次原始数据到本地文件或 Redis，供人工重试 - MySQL 报错
SQLSTATE[HY000]: General error: 1366 Incorrect string value多因remark含 emoji，需确保表字符集为utf8mb4，且连接时指定PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"
批量本身不难，难的是批量失败时你知道哪几条丢了、怎么捞回来、会不会影响对账。别让日志变成甩手掌柜。
