优先用 groupby + unstack 替代 pivot_table，避免内存爆掉；改用内置聚合函数、astype('category') 压缩、fill_value=0 减内存；千万级切 dask 或 polars；宽表转长表+索引，按需分页或缓存。

用 pandas.pivot_table 处理百万行数据会卡死，别硬扛

直接调 pandas.pivot_table 在 50 万行以上、多列聚合时极易内存爆掉或耗时超长——不是写法错，是底层把全量数据载入内存再分组，没做任何分块或延迟计算。真实场景里，得换思路。

优先考虑 groupby + unstack 替代 pivot_table

pivot_table 功能全但太重；多数实际需求（比如“按日期+品类统计销售额”）用 groupby 配合 unstack 更轻快、可控性强，且能自然衔接 dask 或 polars 后续扩展。

• 避免 aggfunc 传复杂 lambda：改用内置函数如 'sum'、'mean'，否则无法被底层优化
• 提前用 astype('category') 压缩 index 和 columns 字段，减少内存占用 30%~70%
• 若结果列太多导致宽表爆炸，加 fill_value=0 防止 NaN 占用额外空间
• 示例：

  df.groupby(['date', 'category'])['sales'].sum().unstack('category', fill_value=0)

千万级数据必须切到 dask.dataframe 或 polars

pandas 单机内存瓶颈明显，dask 能自动分块调度，polars 基于 Rust 且支持流式 pivot，二者都比硬改 pandas 配置靠谱得多。

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

• dask 注意：不能直接用 pivot_table，得走 groupby().agg().unstack() 路径，且 compute() 前别触发过多中间计算
• polars 更简捷：df.pivot(values='sales', index='date', columns='category', aggregate_function='sum')，默认就流式处理，不爆内存
• 别在 dask 中混用 pandas 函数（如自定义 aggfunc），容易 silently fallback 到单机模式
• 磁盘 I/O 成瓶颈时，把 CSV 换成 parquet 格式，polars.read_parquet() 加载速度通常快 3~5 倍

透视结果太大？立刻放弃“宽表”，改用“长表 + 查询索引”

真正卡住的往往不是计算，而是把 10 万 × 500 列的结果塞进 DataFrame——这种宽表既难存、难传、也难查。生产环境应默认输出长表（date, category, sales），再靠数据库或 pyarrow.dataset 加索引加速查询。

立即学习“Python免费学习笔记（深入）”；

• 用 reset_index().melt(id_vars=['date'], value_name='sales', var_name='category') 把宽表转回长表
• 如果下游是 Web API，别一次性返回全部 pivot 结果，改成按 date 分页或按 category 过滤后聚合
• 临时需要宽表展示？用 pd.DataFrame.to_html(table_id='pivot-table') 配合前端 JS 渲染，避免 Python 层 hold 整个矩阵

实际跑通的关键不在“怎么 pivot”，而在“要不要 pivot”——先问清楚下游到底要什么格式、更新频率多少、最大容忍延迟几秒。很多所谓“大数据 pivot 需求”，最后发现只是前端想做个可折叠的交叉报表，用 SQL VIEW + 缓存更稳。