【发布时间】：2021-03-06 12:38:37
【问题描述】：
当我们通过 pandas 将文件加载到 SQL Server 时，我在创建 SQLAlchemy 引擎对象时开始使用此 fast_executemany 属性。我了解它在加载数据时的好处。
是否存在不建议为 SQL Server 任务启用它的情况？也许如果一直只做单例插入？我仍然看不出 fast_executemany 会慢多少。
【问题讨论】：
标签： python pandas sqlalchemy pyodbc
【发布时间】：2021-03-06 12:38:37
【问题描述】：
是否存在不建议为 SQL Server 任务启用它的情况？也许如果一直只做单例插入？
不，如果调用 pyodbc 的 .execute() 方法，fast_executemany=True 将不会影响单行插入。一个例子是this pandas issue，其中行为在具有单行 (.execute()) 和多行 (.executemany()) 的 DataFrame 之间有所不同。解决该特定问题的方法是让 pandas 始终调用 .executemany()，即使 DataFrame 只有一行。 （另请注意，fast_executemany=True 不会导致问题，它修复问题。）
但是，在特定情况下，fast_executemany=True 和 .to_sql() 还存在一些其他已知问题：
1。具有默认“补充字符”(_SC) 排序规则的数据库
如果数据库是使用默认的“…_SC”排序规则定义的，例如，
cnxn.execute(f"CREATE DATABASE {db_name} COLLATE Latin1_General_100_CI_AS_SC")
那么.to_sql() 将无法处理超过 2000 个字符的字符串。
2。具有大量类似 NULL 的值的 DataFrame
相对稀疏的数据帧（包含许多类似 NULL 的值，例如 None、NaN、NaT 等）会降低 .executemany() 的插入性能，尽管最坏的情况是fast_executemany=True 的运行速度与 fast_executemany=False 一样慢。
3。使用[n]varchar(max) 列增加内存消耗
to_sql() 默认将字符串列创建为varchar(max)，这可能会导致fast_executemany=True 的内存膨胀。
【讨论】：
-
谢谢！这完全回答了我的问题。您打算什么时候解决这些问题？ JK：P
-
#3 的 PR 看起来很有希望。 #2 并不是真正的错误，只是存在变通办法的性能问题（例如，使用
bcp）。 #1 是，IMO，msodbcsql 中尚未解决的缺陷。