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

直接说结论：Pandas 本身不背锅，问题出在默认读取方式没能绕过 I/O 和内存瓶颈。500 万行数据卡上半小时？其实 90% 的情况，调整连接器、分批加载加类型控制，或者换个执行引擎就能解决。

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

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

市面上主流的 PyMySQL、psycopg2 这类驱动，默认行为是把整个结果集一次性拉到本地内存，再丢给 Pandas 处理。面对 500 万行数据，光网络传输和本地缓存就能占满带宽和内存，卡顿自然难免。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 默认会逐列做全扫描来推断数据类型，比如猜它是 int64 还是 object。500 万行乘以 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 文件，底层向量化 + 列存 + 自动索引，500 万行常见查询通常在秒级。两种推荐用法：

• 查数据库：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？还是干脆绕过它？每个选择对应不同的成本和效果边界。最容易被忽略的一点：500 万行查询慢，往往是因为你用了 SELECT * 查了根本不用的 15 列，删掉它们比换引擎还快。