Groupby慢主要因object类型分组键需逐字符比对和哈希；转为Categorical后用整数编码分桶，可大幅提升性能，尤其在类别少、重复多时。
为什么Groupby慢？先看数据类型的影响
Pandas groupby 的性能瓶颈常不在计算逻辑，而在分组键（by 参数）的哈希与比较开销。当分组列是 object 类型（比如字符串），Pandas 每次都要逐字符比对、构造哈希值，尤其在重复值多、类别少的场景下，纯属浪费。
把列转成 Categorical 后，Pandas 内部只存储整数编码（codes）和唯一类别（categories），groupby 直接按整数分桶，跳过字符串解析 —— 这不是“优化技巧”，而是绕过底层低效路径的必要操作。
常见错误现象：
- 分组列含数千个唯一字符串，但实际只有几十个业务类别（如“华东”“华北”“华南”）
- groupby().agg(...) 耗时远高于预期，top_n = 10 的 value_counts() 却很快
- df.groupby('region').size() 比 df['region'].value_counts() 慢 3–5 倍
怎么安全地转成Categorical？注意三个条件
不是所有字符串列都适合转 Categorical。必须同时满足：
- 类别数远小于行数（例如 100 个类别 vs 100 万行）
- 类别集合稳定（不频繁新增未知值，否则
add_categories或unknown处理会拖慢） - 该列后续主要用于分组、过滤、排序，而非正则匹配或子串提取
实操建议：
- 用 df['col'].nunique() / len(df) 快速估算类别密度，比值
- 显式指定 categories（而非依赖自动推断），避免首次分组时重建索引：
df['region'] = pd.Categorical(df['region'], categories=['华北', '华东', '华南', '西南'])
- 如果原始列有缺失值，
Categorical 默认保留 NaN，无需额外处理
Groupby前必须set_index吗？不，但要注意order参数
很多人误以为 Categorical 必须配合 sort=False 才快，其实关键在 observed 和 dropna。
立即学习“Python免费学习笔记（深入）”；
默认情况下，groupby 会返回所有类别（包括零频次的），这会触发完整笛卡尔展开 —— 即使你只想要非空组。
正确做法是：
df.groupby('region', observed=True, dropna=False).sum()其中：
-
observed=True：只对实际出现的类别分组，跳过未观测到的 categories，速度提升最明显-
dropna=False：显式控制是否包含 NaN 组（Categorical 中的 NaN 是合法类别）-
sort=False 仅在你不需要结果按类别顺序排列时启用，否则可能打乱 categories 定义的业务顺序
和category dtype一起用的隐藏加速点
Categorical 单独用只是基础，搭配以下操作才能榨干性能：
- 用
cat.codes替代原始列做简单聚合（如计数）：df.groupby(df['region'].cat.codes).size()
比df.groupby('region').size()再快 20%–30% - 如果分组后要 merge 回原表，优先用
transform而非apply：df['mean_sales'] = df.groupby('region')['sales'].transform('mean')，避免触发 object 类型回退 - 避免链式操作中意外转回
object：df['region'].str.upper()会摧毁Categorical结构，需先astype(str)再操作
最易被忽略的一点：Categorical 的内存优势在 groupby 中不会自动传导到 agg 函数内部。如果你在 .agg() 里调用了自定义函数，且该函数内部又做了字符串操作，前面所有优化都会失效 —— 加速只发生在分组阶段，不保你整个 pipeline。
