pandas.read_sql是读取复杂查询结果最稳妥直接的方法，需用SQLAlchemy引擎传参、参数化防注入、分块处理大数据，并注意datetime解析与类型推断问题。
用 pandas.read_sql 读取复杂查询结果最稳妥
直接用 pandas.read_sql 是最常用也最可靠的方式，它能自动处理列名、数据类型推断和空值映射。关键不是“能不能”，而是“怎么传参才不翻车”。
常见错误是把 SQL 字符串硬拼接进 read_sql，导致注入风险或语法错；或者忽略 con 参数类型——它必须是 DBAPI 连接对象（如 sqlite3.Connection 或 sqlalchemy.engine.Engine），不能是字符串 URL。
- 用
sqlalchemy.create_engine构建Engine对象，再传给con=，比直接传连接更稳定，尤其在多线程或长连接场景 - 复杂查询含换行或注释？用三引号包裹 SQL 字符串，但注意数据库驱动是否支持（PostgreSQL 的
psycopg2支持，SQLite 原生驱动不支持分号分隔多语句） - 如果查询返回空结果集，
read_sql默认返回空DataFrame，列名和 dtype 会丢失——加coerce_float=False或显式指定dtype可缓解
当 SQL 太大或需分块读取时，改用 read_sql_query + chunksize
read_sql_query 和 read_sql 行为一致，但明确限定只执行查询（不建表/删表），配合 chunksize 参数可流式读取大结果集，避免内存爆掉。
典型场景：查千万级日志表、导出报表原始数据。注意 chunksize 返回的是迭代器，不是单个 DataFrame。
立即学习“Python免费学习笔记（深入）”；
-
chunksize=10000是较安全的起点，具体值取决于每行平均字节数和可用内存 - 别直接对迭代器调
pd.concat(..., ignore_index=True)——若中间某块出错，整条链失败。应逐块处理、校验、写磁盘或入库 - MySQL 的
mysqlclient驱动默认不支持 server-side cursor，设chunksize会全量拉取再切片；换成PyMySQL或加cursorclass=pymysql.cursors.SSCursor才真流式
遇到 datetime/timestamp 类型乱码或时区错，优先检查 SQLAlchemy 的 connect_args
不是 Pandas 的锅，是底层驱动没正确解析时间字段。比如 MySQL 查询返回 2023-01-01 12:00:00，Pandas 可能转成 NaT 或错误 timezone-aware 时间戳。
根本解法在连接层：让驱动明确知道时区和格式。
- MySQL：在
create_engine中加connect_args={'charset': 'utf8mb4', 'autocommit': True}，并确保服务端time_zone='+00:00' - PostgreSQL：用
connect_args={'options': '-c search_path=myschema'}同时，加server_side_cursors=True可提升大结果时间字段稳定性 - SQLite：无需额外配置，但字段定义必须是
TEXT或NUMERIC，别用DATE这种伪类型，否则read_sql推断失败
自定义列名或类型映射？绕过自动推断，用 dtype + parse_dates
自动类型推断常失手：比如金额字段含逗号或货币符号，会被判成 object；又或 ID 字段全是数字但含前导零，变成 float64 后零丢失。
这时别硬调 astype()，应在读取阶段就干预。
-
dtype={'user_id': 'string', 'amount': 'float64'}—— 直接锁定列类型，string是 Pandas 专用字符串类型，保留前导零 -
parse_dates=['created_at', 'updated_at']比依赖自动识别更准，尤其字段名不规范（如叫dt_event） - 若某列含混合类型（如部分为空字符串、部分为数字），先用
converters参数预处理：converters={'score': lambda x: float(x) if x.strip() else np.nan}
read_sql 的 columns 参数不支持重命名，真要改名只能靠 SQL 的 AS 或后续 df.rename(columns={...})。别指望 Pandas 替你做语义理解——它只管把结果集变成表格，其余得你自己兜底。 
