python中应让数据库执行group by和sum等聚合操作，因pandas或纯python加载全量数据再聚合会导致内存和时间开销剧增；需用sqlalchemy core原生查询、禁用read_sql()干扰参数，并确保聚合函数来自sqlalchemy.func。
为什么不能在Python里做GROUP BY和SUM？
因为Pandas或纯Python加载全量数据再聚合，内存和时间开销会指数级增长。比如千万行订单表，df.groupby('user_id')['amount'].sum() 得先把所有数据拉到本地，而数据库早就在索引和执行计划层面做了优化。
关键判断：只要聚合逻辑能用SQL表达，就该让数据库算——不是“能不能”，而是“必须让”。
用SQLAlchemy Core写原生聚合查询最直接
绕过ORM模型层，用select() + func.sum() + group_by() 构建可下推的语句，数据库引擎能完整识别并执行。
- 别用
session.query(Model).group_by(...).all()——ORM会先查出所有行再Python侧分组 - 改用
select(func.sum(table.c.amount)).group_by(table.c.user_id)，配合connection.execute() - 确保
table.c.amount是数据库字段，不是Python计算列；否则SQLAlchemy会fallback到客户端计算 - 聚合函数必须来自
sqlalchemy.func（如func.count()、func.avg()），不能用Python内置sum()
from sqlalchemy import select, func
stmt = select(
users_table.c.region,
func.sum(orders_table.c.total).label('total_sales')
).join(orders_table).group_by(users_table.c.region)
用Pandas的read_sql()但必须禁用index_col和parse_dates干扰
pd.read_sql()本身不阻止下推，但某些参数会让Pandas偷偷做额外处理，导致SQL被改写或无法下推。
- 避免
index_col：它会触发SELECT *再本地设索引，破坏聚合下推 - 避免
parse_dates：日期解析在Python端做，数据库无法提前过滤或聚合时间维度 - 显式写完整SQL字符串（带
GROUP BY、WHERE等），不要依赖pd.read_sql_table() - 确认数据库返回的是聚合后结果集（行数明显少于原始表），而不是把WHERE条件都去掉再拉全量
PostgreSQL/MySQL里COUNT(*)慢？检查是否用了count(1)或count(id)
很多用户以为count(1)比count(*)快，其实现代数据库对count(*)有专门优化（走索引元数据或只扫索引页）。用count(id)反而可能触发NULL检查，拖慢聚合。
- PostgreSQL中
count(*)在主键索引存在时近乎O(1) - MySQL InnoDB里
count(*)走最小索引树，count(id)需读取实际字段值 - 如果聚合还带
HAVING或复杂WHERE，务必在SQL里写清楚，别指望Pandas后续过滤
真正卡住的往往不是聚合本身，而是没加WHERE条件就把千万行扔给GROUP BY——数据库也得扫全表。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
