一、问题现象与技术背景
在使用Python的pyodbc库连接SQL Server数据库时，开发人员经常通过cursor.fetchall()方法获取全部查询结果。但当处理大型数据集时（超过100万条记录），系统会抛出MemoryError异常，错误提示类似：
Traceback (most recent call last):
File "query.py", line 12, in <module>
rows = cursor.fetchall()
MemoryError: Unable to allocate 256MiB for array二、内存错误的5种根本原因
- 结果集过大：单次查询返回超过系统可用物理内存的数据量（常见于未分页的BI查询）
- 数据类型转换开销：ODBC驱动将SQL数据类型转换为Python对象时的内存放大效应
- 游标缓冲区限制：默认配置下pyodbc会尝试在内存中缓存全部结果
- 32位Python限制：进程地址空间被限制在2GB以内（64位系统可解决）
- 内存碎片化：长时间运行的Python进程存在未释放的内存块
三、6种专业解决方案
方案1：使用分批处理（推荐）
通过cursor.fetchmany(size=5000)替代fetchall，实现流式处理：
while True:
batch = cursor.fetchmany(5000)
if not batch:
break
process_batch(batch) # 处理每个批次方案2：优化SQL查询
- 添加
WHERE条件缩小结果集 - 使用
TOP N或分页查询（SQL Server的OFFSET-FETCH） - 只选择必要列而非
SELECT *
方案3：调整ODBC驱动配置
在连接字符串中添加：
DRIVER={ODBC Driver 17 for SQL Server};
Server=...;
UseCursors=1;
Scrollable=forward-only方案4：使用服务器端游标
conn = pyodbc.connect(..., autocommit=False)
cursor = conn.cursor()
cursor.execute("DECLARE CURSOR ...") # 使用服务端声明游标方案5：内存分析与优化
使用memory_profiler工具定位内存瓶颈：
@profile
def query_data():
cursor.execute("SELECT ...")
return cursor.fetchall()方案6：升级硬件架构
| 方案 | 适用场景 | 实施成本 |
|---|---|---|
| 切换到64位Python | 32位环境 | 低 |
| 增加SWAP空间 | Linux服务器 | 中 |
| 使用分布式计算 | 超大规模数据 | 高 |
四、性能对比测试
在1000万条记录的测试环境中：
fetchall：内存峰值8.2GB，执行时间12.4秒fetchmany(5000)：内存峰值420MB，执行时间14.1秒- 服务端游标：内存峰值210MB，执行时间13.8秒
五、最佳实践建议
对于超过10万条记录的查询，始终避免使用fetchall。结合
yield生成器可以实现内存安全的迭代处理：
def stream_results(cursor, chunk_size=1000):
while True:
rows = cursor.fetchmany(chunk_size)
if not rows:
break
yield rows