pd.read_sql是最直接方式，需传engine而非session或connection；支持SQL字符串、text()及Select对象；参数用params字典防注入；大数据用chunksize分批；datetime问题靠parse_dates或SQL显式转换。
SQLAlchemy连接后怎么直接转成DataFrame
不用手动遍历结果集，pd.read_sql 是最直截了当的方式。它内部会调用 engine.execute() 并自动处理列名和类型映射。
常见错误是传入 Connection 对象而非 Engine，或者误用 session.execute() 返回的 ResultProxy —— 这俩都不能直接喂给 pd.read_sql。
- ✅ 正确：用
engine（不是session，也不是connection）作为con参数 - ✅ 支持 SQL 字符串或
text()对象，也支持已编译的Select对象（SQLAlchemy 2.0+） - ⚠️ 注意：如果 SQL 含参数，必须用
params=传字典，不能用 Python 字符串格式化，否则有注入风险
import pandas as pd
from sqlalchemy import create_engine, text
<p>engine = create_engine("sqlite:///example.db")
df = pd.read_sql(text("SELECT * FROM users WHERE age > :min_age"),
con=engine,
params={"min_age": 18})用Session执行查询再转DataFrame为什么总报错
session.execute() 返回的是 Result（SQLA 2.0+）或 ResultProxy（1.x），不是可迭代的普通列表，也不能直接丢给 pd.DataFrame() 构造器。
真正能用的只有两种路径：一是回到 engine + pd.read_sql；二是手动取数据再构表，但得自己处理列名和空值。
立即学习“Python免费学习笔记（深入）”；
- ❌ 错误写法：
pd.DataFrame(session.execute(...))→ 报TypeError: 'Result' object is not iterable - ✅ 替代方案1：用
session.bind拿到 engine：pd.read_sql(..., con=session.bind) - ✅ 替代方案2：手动转（仅适合小结果集）：
rows = session.execute(...).all()，再用pd.DataFrame(rows, columns=...)，但列名得从result.keys()提取
读大数据时内存爆掉怎么办
pd.read_sql 默认一次性拉全量，遇到千万级表很容易 OOM。关键不是换库，而是控制“怎么读”。
核心是用 chunksize 参数分批读，返回的是可迭代的 TextFileReader，每块独立处理，不累积内存。
- ✅ 设置
chunksize=10000后，用 for 循环逐块处理：for chunk in pd.read_sql(..., chunksize=10000): process(chunk) - ⚠️ 注意：
chunksize不影响 SQL 执行逻辑，它只是 Python 层的缓冲切分，数据库仍执行完整查询 - ? 真正减压要靠 SQL 侧：加
WHERE、用分区字段过滤、避免SELECT *，尤其别在没索引的字段上ORDER BY
datetime字段读出来变成字符串或NaT
不是 Pandas 的锅，是 SQLAlchemy 取数时类型推导失败，或数据库驱动没把 timestamp 映射对。PostgreSQL 的 timestamptz、MySQL 的 TIMESTAMP 最容易出这问题。
- ✅ 强制指定列类型：在
pd.read_sql里用parse_dates=，例如parse_dates=["created_at", "updated_at"] - ✅ 更稳妥：SQL 里用
CAST(created_at AS DATETIME)（MySQL）或created_at::timestamp（PostgreSQL）显式转换 - ⚠️ 坑点：SQLite 的 datetime 默认存为字符串，
parse_dates有效，但时区信息全丢——除非你自己用dateutil.parser补
实际用的时候，chunksize 和 parse_dates 经常要一起配着调。很多人只顾着写 SQL，忘了驱动层和 Pandas 类型桥接那几毫米的缝隙，一跑生产就卡在时间字段或内存上。
