往数据库表中插入数据的往数代码

假设你正盯着一个空表，就像盯着一个空房间。据库你得往里放东西，表中放对了，插入后面查起来才顺。数据插入数据这事，往数说穿了就一句话：告诉数据库“哪张表、据库哪些列、表中什么值”。插入但真写起来，数据坑比想象中多。往数

最基础的据库写法长这样：
INSERT INTO users (name, age, email) VALUES ('张三', 28, 'zhangsan@example.com');
列名和值必须一一对应，顺序不能乱。表中你写反了，插入数据库不会骂你，数据但它会默默把数字塞进字符串列里，等你查出来才发现类型全乱了。

有一次我帮同事调bug，他插了上千条数据，每条都写全列名。我说你累不累？他回我一句“这样清楚”。清楚是清楚，但代码能短一半。要是表结构稳定，你可以省略列名：
INSERT INTO users VALUES ('李四', 31, 'lisi@example.com');
但这里有个致命前提——你得知道表里所有列的精确顺序。一旦有人加了字段，这条语句立刻报错。省事和省心，往往不可兼得。

真正麻烦的是批量插入。循环里一条条执行INSERT，数据量小还好，上千条就开始卡。数据库每次插入都要做日志、锁表、检查约束，开销不小。这时候得用批量语法：
INSERT INTO users (name, age, email) VALUES ('王五', 25, 'a@x.com'), ('赵六', 30, 'b@x.com'), ('孙七', 22, 'c@x.com');
一次发过去，数据库一口气处理完。我见过有人用循环插一万条，跑了三分钟；改成批量后，三秒搞定。差距就是这么夸张。

但别高兴太早。批量插入有个暗坑：如果中途某条数据违反约束（比如主键重复），整个批量操作会全部回滚。你以为是“部分成功”，结果是“全军覆没”。所以批量前，要么先查重，要么用数据库的“冲突忽略”语法。MySQL里是这么写的：
INSERT IGNORE INTO users (name, age, email) VALUES ('周八', 27, 'zhou@x.com');
或者更精细一点：
INSERT INTO users (name, age, email) VALUES ('吴九', 29, 'wu@x.com') ON DUPLICATE KEY UPDATE age = VALUES(age);
后者的意思是“如果主键撞了，就更新年龄字段”。这种写法适合做“有则更新，无则插入”的同步逻辑，省得先查一遍再决定动作。

还有个细节容易被忽略——时间字段。你直接插入字符串'2024-06-01 12:00:00'，大多数数据库能自动转换，但格式必须严格匹配。要是你传'2024/06/01'，MySQL可能认，PostgreSQL直接报错。更稳妥的做法是用参数化查询，让驱动帮你转类型。比如Python里：
cursor.execute("INSERT INTO users (name, age, created_at) VALUES (%s, %s, %s)", ("郑十", 26, datetime.now()))
这样既避免SQL注入，又不用手拼字符串。手拼字符串这事，我年轻时干过，后来被黑客教做人了——一个引号没转义，整张表数据被人删了。别学我。

最后说个偏方。有些场景下，你不想手动写INSERT，而是从另一个表搬数据：
INSERT INTO archive_users SELECT * FROM users WHERE created_at < '2023-01-01';
这是把旧数据归档的常用招数。但注意，两个表的列结构必须完全对齐，否则数据会错位。我曾经没检查就跑了，结果把用户名插到了手机号列里，被业务方追着骂了一下午。

插入数据看起来是入门级操作，但生产环境里，性能、安全、容错全都压在这几行代码上。写之前多问自己一句：表结构变不变？数据量多大？冲突了怎么办？想清楚这三件事，你写的INSERT才真正稳。