如何在Python中解决Pandas连接数据库时查询速度慢的优化方案

不是Pandas慢，而是默认读取方式未绕过I/O和内存瓶颈；500万行数据卡顿90%可通过启用SSCursor/RealDictCursor流式读取、分批加载+dtype预声明、改用DuckDB或Polars解决。

直接结论：不是 Pandas 慢，而是默认的读取方式没绕过 I/O 和内存瓶颈；500 万行数据卡在 30 分钟，90% 可通过调整连接器、分批 + 类型控制、或换执行引擎解决。

用 SSCursor 或 ServerSideCursor 避免客户端全量缓存

PyMySQL、psycopg2 等驱动默认把整张结果集拉到本地内存再交由 Pandas 处理，对 500w 行来说，光网络传输+本地缓存就占满带宽和内存。MySQL 用户应显式启用 SSCursor，PostgreSQL 用户用 RealDictCursor 配合 stream=True（psycopg2 v2.8+）。

• PyMySQL 示例：from pymysql.cursors import SSCursor; conn = pymysql.connect(..., cursorclass=SSCursor)
• psycopg2 示例：conn.cursor(cursor_factory=RealDictCursor, name='large_query')，再用 cursor.fetchmany(10000) 流式取数
• 切忌在 SSCursor 下调用 cursor.fetchall() —— 会触发一次性加载，完全失效

分批读取 + dtype 预声明，跳过类型推断开销

Pandas 默认对每列做 full-scan 推断类型（比如猜 int64 还是 object），500w 行 × 20 列下这部分耗时可能超 10 分钟。必须关掉自动推断，并手动指定紧凑类型。

• 用 pd.read_sql_query(query, conn, chunksize=50000) 分批，再用 pd.concat(chunks, ignore_index=True) 合并
• 提前查表结构：SELECT column_name, data_type FROM information_schema.columns WHERE table_name='your_table'，然后构造 dtype 字典，如 {'id': 'uint32', 'amount': 'float32', 'status': 'category'}
• 注意：MySQL 的 TINYINT(1) 常被误读为 bool，要强制写成 'bool' 或 'uint8'，否则后续 astype() 会复制整列

绕过 Pandas，用 DuckDB 直接查数据库或 Parquet

如果只是做过滤、聚合等 SQL 类操作，Pandas 不是必须环节。DuckDB 支持直接查询 PostgreSQL/MySQL（通过 duckdb.read_postgres()）或本地 Parquet 文件，底层向量化 + 列存 + 自动索引，500w 行常见查询通常在秒级。

立即学习“Python免费学习笔记（深入）”；

• 查数据库：import duckdb; duckdb.sql("SELECT * FROM read_postgres('host=... dbname=...', table='t') WHERE x > 100")
• 更推荐路径：先用 pg_dump --column-inserts 或 mysqldump --tab 导出为 CSV/Parquet，再用 duckdb.read_parquet('data.parquet') 加载 —— Parquet 比 CSV 快 5 倍以上，且支持谓词下推
• 别指望 read_sql + DuckDB 连接字符串混用：DuckDB 不直连 MySQL，read_postgres 是特例，其他数据库需先导出

换底层引擎：Polars 替代 pandas.read_sql

Polars 的 read_database_uri 使用 Arrow Flight 或 SQLAlchemy 异步通道，自带线程池与零拷贝解析，对宽表（20 列）尤其友好。实测同配置下比 Pandas 快 3–6 倍，且内存峰值低 40%。

• 示例：import polars as pl; pl.read_database_uri("postgresql://...", query="SELECT * FROM t")
• 必须加 fetch_batches=True 参数才能启用流式读取（否则仍会全量加载）
• 注意：Polars 对 datetime 时区处理较严格，MySQL 的 DATETIME 可能被读成 pl.Datetime(time_unit="us")，需用 .cast(pl.Datetime(time_zone="UTC")) 显式转换

真正卡住的从来不是“要不要优化”，而是“在哪一层动手”——在数据库侧加索引？在连接层换游标？在 Pandas 层控 dtype？还是干脆绕过它？每个选择对应不同成本和效果边界。最常被忽略的一点：500w 行查询慢，往往是因为你在用 SELECT * 查了根本不用的 15 列，删掉它们比换引擎还快。