pandas.to_sql默认逐行插入导致性能差，关键解法是启用批量提交：添加method='multi'合并多条insert、设置chunksize分块（如5000）、关闭索引；复用sqlalchemy engine并启用pool_pre_ping；大批量写入应truncate而非replace；mysql需统一utf8mb4编码防字符串错误。
用 to_sql 时为什么慢得像在等咖啡？
默认的 to_sql 是逐行插入，每条记录都走一次 SQL INSERT，网络往返+事务开销叠加，10 万行可能要几分钟。这不是你代码写错了，是 pandas 默认没为你批量优化。
关键解法：关掉默认的单行模式，强制走批量提交 + 合理分块。
- 加参数
method='multi'：让 pandas 把多条 INSERT 合成一条（如INSERT INTO ... VALUES (...), (...), (...)） - 设
chunksize：比如chunksize=5000，避免单次构造过长 SQL 导致内存或数据库报错（如 MySQL 的max_allowed_packet） - 关掉
index=False：除非你真需要索引列进库，否则默认带 index 会多一列、多一次转换
to_sql 配合 SQLAlchemy 的 engine 要注意什么？
很多人直接传 sqlite:///xxx.db 字符串，看似能跑，但每次调用都新建连接，没法复用连接池，还容易触发连接泄漏。尤其在循环写多个表时，问题更明显。
正确做法是显式创建 Engine 并复用：
from sqlalchemy import create_engine
engine = create_engine('postgresql://user:pass@localhost/db', pool_pre_ping=True)
pool_pre_ping=True 很关键——它会在每次取连接前发个轻量 ping，自动踢掉断连，避免写到一半报 Lost connection to MySQL server 这类错误。
- 别在循环里反复调用
create_engine - PostgreSQL/MySQL 建议加
echo=False关闭 SQL 日志，否则日志刷屏影响性能判断 - 如果用的是 SQLite，
connect_args={'timeout': 20}可缓解 busy 错误
大批量写入时要不要先删表再重建？
取决于你的场景。如果目标表结构固定、只需清空重写，if_exists='replace' 看似方便，但它会先 DROP TABLE 再 CREATE TABLE，丢失所有索引、约束、权限，甚至触发外键级联删除——这不叫“重写”，叫“破坏性覆盖”。
更稳的做法是分两步：
- 用原生 SQL 清空：
engine.execute("TRUNCATE TABLE my_table")（PostgreSQL/MySQL 支持）或"DELETE FROM my_table"（SQLite） - 再用
to_sql(..., if_exists='append')写入 - 如果表有自增主键，
TRUNCATE后记得重置序列（如 PostgreSQL 的ALTER SEQUENCE xxx RESTART）
遇到 OperationalError: (1366, "Incorrect string value") 怎么办？
这是 MySQL 最经典的编码坑：DataFrame 里含 emoji 或生僻汉字，但数据库表字段是 utf8（实际只支持 BMP 字符），不是 utf8mb4。
光改 Python 端没用，必须两端对齐：
- 建表时指定字符集：
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci - SQLAlchemy 连接字符串末尾加
?charset=utf8mb4（MySQL） - pandas 写入前确保字符串列没混入控制字符：
df[col] = df[col].astype(str).str.replace(r'[\x00-\x08\x0b\x0c\x0e-\x1f]', '', regex=True)
真正麻烦的不是发现这个错，而是它只在某几行数据上爆发，且不报具体哪一行——建议上线前用 df.applymap(lambda x: isinstance(x, str) and any(ord(c) > 0xffff for c in x)) 快速扫一遍高危字段。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
