预处理批量插入小数应避免单行循环execute，因其引发多次网络往返和sql解析；正确做法是拼接多值insert+字符串绑定，确保decimal字段、严格类型匹配及合理分批。
预处理语句批量插入小数时，为什么不能直接用 $pdo->prepare() + 单次 $stmt->execute() 循环？
因为每次 execute() 都触发一次网络往返和 SQL 解析（即使预处理已缓存），小数字段（如 DECIMAL(10,2)）本身无特殊序列化开销，瓶颈在 I/O 次数。1000 行循环执行 1000 次 execute()，比单条多值 INSERT 慢 3–5 倍，尤其跨服务器时更明显。
常见错误现象：PDOException: SQLSTATE[HY000]: General error（参数绑定失败）、小数被截断为整数（未显式指定类型）、入库后精度丢失（如 12.30 存成 12.3）。
- 确保数据库字段是
DECIMAL或NUMERIC，不是FLOAT—— 后者二进制存储会导致0.1 + 0.2 != 0.3 - PHP 中小数统一用字符串传入绑定参数，避免浮点数隐式转换：用
(string)$value而非(float)$value - 预处理语句中占位符必须与实际字段精度匹配，例如
DECIMAL(12,4)字段就别用:price绑定一个带 6 位小数的字符串
用 PDO::prepare() + INSERT ... VALUES (?, ?, ?), (?, ?, ?) 拼接批量值
这是平衡可读性、安全性和性能的常用做法：一次预处理，一次执行，支持 100–500 行/批（取决于 MySQL max_allowed_packet）。小数作为字符串绑定，不经过 PHP 浮点运算，精度零损失。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 每批控制在 200 行以内，避免单条 SQL 超过 1MB；可用
strlen($sql) 动态截断 - 拼占位符时用
str_repeat('(? , ? , ?), ', $count - 1) . '(? , ? , ?)'，不要用循环字符串拼接 - 绑定参数数组必须严格按顺序：小数字段对应位置填
(string)$val，例如$params[] = (string)$row['amount']; - 示例片段：
$sql = "INSERT INTO orders (user_id, amount, tax) VALUES " . $placeholders;<br>$stmt = $pdo->prepare($sql);<br>$stmt->execute($allParams); // $allParams 是一维字符串数组
遇到 SQLSTATE[22001]: Data too long 或小数被截断？检查这三处
这不是预处理的问题，而是数据与 schema 不匹配的典型报错，小数场景下极易发生。
- 数据库字段定义：运行
DESCRIBE table_name确认小数字段是DECIMAL(M,D)，且M-D≥ 整数位数（例如存12345.67至少要DECIMAL(7,2)） - PHP 传入值是否含不可见字符：用
trim()和is_numeric()过滤，避免"12.30\n"导致截断 - PDO 默认不校验长度，但 MySQL 严格模式下会拒绝超长输入；可在连接时加
strict=1参数提前暴露问题：mysql:dbname=test;host=localhost;charset=utf8mb4;strict=1
更高吞吐量场景：改用 LOAD DATA INFILE 或事务包裹批量预处理
当单次入库超 5000 行，或要求毫秒级延迟，预处理循环或拼接都不再合适。此时应切换策略：
-
LOAD DATA INFILE是 MySQL 原生命令，比任何 PHP 层方案快 10 倍以上；小数需确保文件中用英文点号分隔，且字段类型与表一致；注意secure_file_priv权限限制 - 若必须走 PHP，用事务 + 分批预处理：开启
$pdo->beginTransaction()，每 500 行execute()一次，最后commit()；避免单事务过大锁表 - 别忽略连接配置：设置
PDO::ATTR_EMULATE_PREPARES => false，否则 PDO 会退化为字符串插值，小数可能被误转
真正卡住性能的往往不是小数本身，而是没意识到 MySQL 对单条语句长度、事务大小、网络往返的硬约束。批量入库前，先 EXPLAIN FORMAT=TREE 看执行计划，比调优 PHP 逻辑更有效。
