标准SQL本身不强制支持多值INSERT语法，但MySQL、PostgreSQL、SQL Server、SQLite均支持；差异在于细节：MySQL宽松但受max_allowed_packet限制，PostgreSQL类型检查严格需显式NULL或CAST，SQL Server触发器逐行触发，SQLite版本依赖。
标准SQL本身不强制要求支持多值 INSERT INTO ... VALUES (...), (...) 语法，但主流数据库（MySQL、PostgreSQL、SQL Server、SQLite）都已实现。真正影响“兼容性+高性能”的，是写法细节和边界控制，不是语法有无。
VALUES 多值插入的跨数据库写法差异
不同数据库对 VALUES 批量的容忍度和行为不一致，硬套一种写法容易在迁移或切换时失败。
- MySQL 允许
INSERT INTO t(a,b) VALUES (1,2), (3,4), (5,6)，但单条语句最大行数受max_allowed_packet和性能衰减点制约，实测超过 1000 组值后解析开销明显上升 - PostgreSQL 同样支持该语法，但对 NULL 类型推导更严格：如果某列类型为
TEXT，而第一组值是字符串、第二组是NULL，它可能报错column "x" is of type text but expression is of type unknown，需显式写成CAST(NULL AS TEXT)或统一用NULL占位 - SQL Server 支持良好，但若目标表有触发器，默认会为每行触发一次；加
OPTION (RECOMPILE)或用TABLOCK提示可缓解 - SQLite 支持多值
VALUES，但版本 sqlite3 --version
避免隐式类型转换导致批量失败
多值插入时，数据库会对整批数据做一次类型推导，不是逐行判断。一旦某组值触发隐式转换失败，整条语句回滚——这点比单条插入更危险。
- 不要混用字符串和数字：比如
VALUES ('1', 2), ('3', '4')在 PostgreSQL 中可能因第二列类型无法统一而报错 -
NULL必须显式写出，不能留空：错误写法VALUES (1, ), (2, )直接语法错误；正确写法是VALUES (1, NULL), (2, NULL) - 时间字段避免字符串直传：
'2026-06-24'在 MySQL 可能被接受，在 PostgreSQL 可能要求带时区或显式CAST(... AS TIMESTAMP)
分批大小与事务控制的实际取舍
“一次插 1000 行”不是银弹。真实瓶颈常出现在日志刷盘、锁粒度或网络缓冲区，而非 SQL 解析本身。
- 网络延迟高（如云数据库跨可用区）时，50–100 行/批比 1000 行更稳；可用
tcpdump或数据库慢日志验证往返耗时 - 目标表有唯一索引且数据存在重复风险时，分批越小，冲突定位越精确；
ON CONFLICT DO NOTHING（PostgreSQL）或ON DUPLICATE KEY UPDATE（MySQL）只对当前批生效 - SQL Server 下若用
INSERT ... VALUES批量，建议每批加WITH (TABLOCK)提示减少锁竞争，但会阻塞其他写操作，需权衡
最易被忽略的是：多值 INSERT 的错误信息通常只提示“第 X 行出错”，但实际失败原因可能是第 1 行的类型问题导致整批推导失败——调试时得从第一组值开始逐项核对，而不是只看报错位置。
