INSERT ... VALUES和
INSERT ... SELECT是 MySQL 中两类根本不同的插入方式，不是写法风格差异，而是数据来源和语义完全不同：前者是「手动提供静态值」，后者是「从已有表动态查出数据再插入」。
什么时候该用 INSERT ... VALUES
？
当你明确知道要插入哪些具体值（比如注册一个新用户、录入一条订单），且这些值不依赖数据库中已有的行时，就用它。
支持单行插入：INSERT INTO users (name, email) VALUES ('Alice', 'alice@example.com');
也支持多行批量插入（性能更好）：INSERT INTO users (name, email) VALUES
('Bob', 'bob@example.com'),
('Charlie', 'c@example.com'),
('Diana', 'd@example.com');
不能省略 VALUES关键字 —— 写成
INSERT INTO t VALUES (1) SELECT ...会直接报错
ERROR 1064值必须与列顺序、类型严格匹配；字符串/日期要用单引号包裹，如
'2025-12-30'
什么时候必须用 INSERT ... SELECT
？
当你想把「另一个表里符合条件的数据」搬过来，或者做数据归档、迁移、去重、补全等操作时，只能靠它。
目标表必须已存在，且字段数量/类型要兼容（或显式转换）：INSERT INTO archive_orders (order_id, amount, created_at) SELECT id, total, created FROM orders WHERE status = 'shipped';可以混用常量和字段：
INSERT INTO logs (event, source, created_at) SELECT 'user_login', 'web', NOW() FROM users WHERE last_login > '2025-12-01';绝对不能加
VALUES—— 常见错误：
INSERT INTO t(col) VALUES (SELECT ...)语法非法 若目标表有主键/唯一约束，而 SELECT 出的值冲突，整条语句会失败（除非加
ON DUPLICATE KEY UPDATE或改用
REPLACE INTO）
容易踩的坑：列名、NULL 和默认值处理
两者对缺失字段的处理逻辑不同，这点极易引发静默错误。
INSERT ... VALUES：没写的列，若允许
NULL就填
NULL；若有
DEFAULT就用默认值；若既不允许
NULL又没默认值，直接报错
ERROR 1364
INSERT ... SELECT：SELECT 返回的列数必须等于 INSERT 指定的列数。少一列？报错；多一列？也报错。不会自动补
NULL或默认值，除非你在 SELECT 里显式写
NULL AS col_name别依赖表结构顺序 —— 即使你省略列名写
INSERT INTO t VALUES (...)，一旦后续加了新字段或调整顺序，语句就可能插错列甚至失败
性能与可读性建议
没有“哪个更快”的绝对答案，关键看场景。
插入几十条固定测试数据？用VALUES多行写法最简洁高效 从日志表抽取上万条成功支付记录到宽表？
SELECT方式天然批处理，还支持
WHERE/
JOIN/
GROUP BY过滤聚合 想避免手写大量
VALUES？可以用程序生成 SQL，但注意单条语句别超
max_allowed_packet（默认 64MB） 线上大批量迁移？建议加
LOW_PRIORITY或分批次执行，避免锁表太久影响查询
MySQL 不强制你选哪一种，但混淆它们的语义（比如误以为
VALUES后能跟子查询）会导致语法错误或数据错位——这种错往往在上线后才暴露，且难以回溯。
