使用pandas to_sql与SQLAlchemy向SSMS写入小数据帧时触发MemoryError的原因排查

我完全理解这种困惑——明明要写入的DataFrame比之前成功的小10倍，却偏偏触发了MemoryError，这实在反直觉。结合你的场景和代码，咱们来拆解几个最可能的原因：

1. sys.getsizeof() 无法反映真实内存开销 #

你用sys.getsizeof(df)得到的大小严重低估了实际内存占用，因为这个函数只计算DataFrame对象本身的内存，不包含列中元素的实际内容（尤其是object类型的列）。比如如果你的小DataFrame里有几列存了长文本、JSON结构或者其他大对象，这些元素的真实内存开销要大得多，而sys.getsizeof()根本没统计到。

建议用df.info(memory_usage='deep')来查看DataFrame的真实内存占用，这个命令会递归计算所有元素的内存，能帮你找到内存黑洞。

2. pyodbc驱动的executemany默认行为陷阱 #

SSMS用的pyodbc驱动，在默认情况下（fast_executemany=False），executemany会为每一行生成独立的SQL插入语句，然后一次性加载所有语句到内存。哪怕你的DataFrame只有几百行，但如果有几十列，或者列类型是字符串/复杂对象，驱动在转换这些参数时会瞬间占用大量内存。

而那些成功的大DataFrame，可能刚好列数更少、类型更简单（比如多是数值型），驱动处理时的内存开销反而没触发阈值。

解决办法：在SSMS的SQLAlchemy连接字符串中添加fast_executemany=True，这个参数会让pyodbc用更高效的方式批量处理插入，大幅降低内存占用：

# 示例连接字符串（根据你的实际配置调整）
ssms_conxn = create_engine(
    "mssql+pyodbc://username:password@your_server/your_db?driver=ODBC+Driver+17+for+SQL+Server&fast_executemany=True"
)

3. 数据类型推断错误导致的内存浪费 #

你的代码中用了cur.fetchall()然后转成DataFrame：

cur.execute(query)
df = pd.DataFrame(cur.fetchall())

这种方式会让pandas把所有列都默认推断为object类型——哪怕PostgreSQL里是int、float或者date类型。object类型的内存开销远大于原生数值/日期类型，而且在写入SSMS时，驱动需要做额外的类型转换，进一步放大内存占用。

解决办法：改用pd.read_sql直接从PostgreSQL读取数据，它会自动映射PostgreSQL的类型到合适的pandas类型，避免不必要的object列：

df = pd.read_sql(f'select * from {postgres_table}', postgres_conxn)

4. 特殊数据内容的额外内存开销 #

如果你的小DataFrame中存在特殊值，也可能触发内存异常：

• 超长的非ASCII字符串（比如包含大量中文、特殊符号）
• 嵌套的JSON/XML结构
• 二进制数据（比如PostgreSQL的bytea类型）

这些内容在pyodbc驱动转换为SQL Server兼容类型时，会占用远超预期的内存。比如Unicode字符串在转换为SQL Server的NVARCHAR时，内存占用会翻倍；嵌套JSON会被驱动解析为大对象，进一步消耗内存。

5. 简化批量写入逻辑 #

你已经发现分10行写入可以解决问题，其实可以直接让pandas自动处理分块，不用手动拆分DataFrame：

df.to_sql(
    name=ssms_table, 
    con=ssms_conxn, 
    if_exists='append', 
    index=False,
    chunksize=100  # 根据情况调整，比如100-1000都可以
)

内容来源于stack exchange