直接说结论：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 列，删掉它们比换引擎还快。
