根本原因是SQLAlchemy引擎配置不当、SQL语句未规范封装、数据库字段类型与Pandas默认推断冲突；需显式创建引擎、用text()包装查询、显式指定dtype和parse_dates，并在写入时规避主键冲突与字段截断。
用 pd.read_sql 读取数据时，为什么总卡在连接或类型转换上？
根本原因常是 SQLAlchemy 引擎没配对、SQL 语句没包裹成文本、或数据库字段类型和 Pandas 默认推断冲突。比如 PostgreSQL 的 JSONB 字段会被读成 str，MySQL 的 TINYINT(1) 可能被误当布尔但实际存的是 0/1 整数。
- 务必用
create_engine显式构造引擎，别直接传 URL 字符串给read_sql—— 否则无法复用连接、也无法控制pool_pre_ping=True防失效连接 - SQL 查询必须是字符串或
text()对象；若含参数，用命名占位符:name+params=...，别用 Python 字符串格式化，防注入 - 遇到日期/时间字段乱码或时区丢失，加
parse_dates参数（如['created_at']）或设dtype={'status': 'category'}提前约束类型
用 df.to_sql 写入时，主键冲突、重复插入、字段截断怎么避免？
to_sql 默认行为是“建表+追加”，但生产环境几乎从不直接建表，也极少无脑追加。常见坑是 if_exists='replace' 清空整表、'append' 忽略主键约束导致 IntegrityError、以及字符串列因数据库默认长度（如 MySQL VARCHAR(255)）被无声截断。
- 写入前确认目标表已存在，用
if_exists='append'并搭配index=False（除非你真要把 DataFrame 索引当主键列） - 主键/唯一冲突时，改用
pd.DataFrame.to_sql配合method='multi'+ 自定义chunksize，或退回到原生 SQLAlchemy 的insert(...).on_conflict_do_update()（PostgreSQL）或REPLACE INTO（MySQL） - 字符串列长度不足？在数据库侧显式设好列宽（如
String(500)），或用dtype={'desc': sqlalchemy.String(2000)}传给to_sql
SQLAlchemy 引擎参数里哪些直接影响 Pandas 读写性能？
不是所有参数都影响 Pandas，但几个关键开关会显著改变吞吐量和稳定性：连接池行为、执行模式、类型映射精度。
-
pool_pre_ping=True：每次取连接前发SELECT 1，避免用到已断开的连接 —— 尤其在长任务中必开，否则可能报Lost connection to MySQL server during query -
echo=False：关闭 SQL 日志输出，否则大量to_sql会拖慢 10 倍以上 -
connect_args={'charset': 'utf8mb4'}（MySQL）或connect_args={'options': '-c search_path=myschema'}（PostgreSQL）：确保字符集和 schema 搜索路径正确，否则中文乱码或找不到表 - 大批量写入时，加
execution_options={'stream_results': True}（仅支持某些驱动），配合chunksize=1000减少内存峰值
什么时候该放弃 pd.read_sql/to_sql，改用原生 SQLAlchemy Core？
当操作涉及复杂事务、条件更新、多表 upsert、或需精细控制每条记录的处理逻辑时，Pandas 的封装层就成了累赘。例如：按业务规则跳过某些行、动态生成不同 INSERT 语句、或在单个事务里混合 SELECT+UPDATE+INSERT。
立即学习“Python免费学习笔记（深入）”；
- 典型信号：
to_sql报OperationalError: (sqlite3.OperationalError) too many SQL variables（SQLite 单语句参数超限）、或需要ON DUPLICATE KEY UPDATE但 MySQL 不支持to_sql原生语法 - 此时直接用
engine.connect()获取连接，调connection.execute(text("INSERT ... ON CONFLICT ..."), params_list)，再手动commit() - 注意：Pandas 的
read_sql底层仍走 Core，所以读取复杂查询没问题；但写入逻辑一旦超出“单表批量插入”范畴，就该切过去
to_sql 会自动适配 ENUM 或 ARRAY，但它不会。这些细节往往只在上线后某次字段变更时才暴露。 
