SQLAlchemy不是数据分析工具，需配合pandas或原生SQL；浮点数应优先用DECIMAL避免精度丢失；数据分析推荐session.execute()流式读取；模型初始化逻辑应改用@event.listens_for或@validates；连接池需按分析负载调优。
SQLAlchemy 本身不是数据分析工具，它只负责把 Python 对象和数据库表连起来；真要做分析，得靠 pandas 或原生 SQL 查询配合。
定义模型时别直接用 Float 存浮点数
很多用户一上来就用 Float 映射数据库里的 DECIMAL 或 NUMERIC 字段，结果读出来精度丢失（比如 12.34 变成 12.339999999999998）。这是因为 Float 对应 Python 的 float，走的是 IEEE 754 浮点规则。
- 金融、统计类字段一律用
DECIMAL(precision=10, scale=2)，对应数据库的DECIMAL - 如果只是做数值计算且不敏感（比如日志中的响应耗时），可以用
Float，但记得查询后转round(x, 2)再用 - PostgreSQL 用户注意：
NUMERIC和DECIMAL等价，但 SQLite 没原生支持，DECIMAL会被降级为REAL，此时必须手动用type_coerce或自定义类型处理
session.execute() 比 query.all() 更适合数据分析场景
用 query.all() 加载全部记录到内存再转成 pandas.DataFrame，遇到百万级表容易 OOM。而 session.execute() 返回可迭代的 Result，能流式读取。
- 写原生 SQL 时用
text("SELECT * FROM sales WHERE dt >= :start")，参数用字典传入：session.execute(stmt, {"start": "2024-01-01"}) - 想复用模型定义又不想加载对象？用
session.execute(select(Model.id, Model.amount, Model.dt))，返回的是元组，比 ORM 实例轻量得多 - 别在循环里反复调
session.execute()做单条查询——批量用IN或JOIN，否则 I/O 成瓶颈
避免在 __init__ 里写业务逻辑导致 ORM 初始化失败
有人习惯在模型 __init__ 里算衍生字段（比如 self.total = self.price * self.qty），结果发现插入数据库时报错：字段没设默认值，或触发了未预期的类型转换。
立即学习“Python免费学习笔记（深入）”；
- 衍生字段统一用
@hybrid_property或column_property定义，让 SQLAlchemy 在 SQL 层或 Python 层分别处理 - 需要初始化逻辑？改用
@event.listens_for(Model, "init")，确保对象刚创建、还没进 session 时执行 - 如果真要插库前校验（比如检查金额非负），用
@validates("amount")，别塞进__init__
连接池配置不当会让并发分析任务卡死
默认 create_engine(...) 的 pool_size=5，但开 10 个 Jupyter kernel 同时跑 read_sql，就会排队等连接，看起来像“卡住”。
- 查分析类任务多用只读连接：加参数
connect_args={"options": "-c default_transaction_read_only=on"}（PostgreSQL）或execution_options={"stream_results": True} - 调大连接池：
pool_size=20+max_overflow=30，但注意数据库侧也要调max_connections - 长期运行的分析脚本记得显式调
engine.dispose()，防止连接泄漏（尤其用了threading或multiprocessing）
真正麻烦的从来不是怎么连上数据库，而是哪列该用什么类型、哪条查询该走 ORM 哪条该绕过 ORM、连接在哪儿被占着不放——这些细节不提前想清楚，跑通第一行代码之后，问题才刚开始。
