从Excel到Pandas：百万级数据分析的实战入门与性能优化

上周帮一个零售团队处理他们的销售流水，一份两百多兆的Excel文件，打开就卡，等了三分钟才看到那一百多万行数据。列一多、表一宽，Excel直接进入半瘫痪状态。我当时的处理方案很简单：把数据丢给Pandas，用Python脚本批量清洗、聚合、输出汇总表，十分钟不到跑完，还顺手给他们做了两张趋势图。今天这篇就是想把这条从Excel到百万级数据分析的路，尽量完整地拆开讲清楚——Pandas处理入门到底要学什么，哪些操作是高频刚需，数据量上来之后又有哪些坑等着你。

这不是一篇只讲API的入门文，而是我实际处理过大几十个数据文件之后沉淀下来的经验。它适合两类人：一种是每天泡在Excel里做报表、但明显感觉Excel已经扛不住数据体量的同学；另一种是刚学完Python基础、想知道怎么用它来正经做数据分析的初学者。看完之后你至少能明白一件事：为什么Pandas能撑起"百万级数据分析"这个场景，以及你该从哪里下手。

1. 为什么不建议继续用Excel硬扛大数据

先声明一点，我不是让你把Excel丢掉。Excel的交互体验、可视化、日常表格操作，至今仍然是办公场景里效率最高的工具之一。但当你手里的数据开始往几十万行、上百万行走的时候，Excel的两大问题就会暴露得淋漓尽致。

1.1 Excel的卡顿源头在哪里

Excel的卡顿核心在于它的内存管理方式。一个单元格只要有内容，哪怕只是一个空字符串，它都要为公式计算、格式渲染、条件格式预留资源。你想想Excel里一个100万行的表格有多少个单元格，光指针和元信息就要吃掉好几个GB内存。更致命的是，Excel对大数据执行筛选、排序、透视表这类操作时是整表重算的。你对一份百万行的表做个数据透视，后台要重新索引全部数据，CPU和硬盘都在被反复压榨，表现出来就是转圈、无响应。

我印象特别深的一次是处理一份将近120万行的订单明细，列数不算多，大概15列，但其中夹杂着日期、时间、文本备注、金额字段。Excel打开花了40多秒，之后随便点击一下都需要两三秒才有反应，想按客户维度做个汇总，直接卡死弹窗"Excel无法完成此操作"。最后我导出CSV，用Pandas读进来，整个数据集的读取、清洗、透视、导出，一条管道下来7秒跑完。这不是Pandas特别神奇，而是它的设计本来就是为了处理这种体量。

1.2 Pandas处理大数据的三点优势

Pandas相比之下有几个天然优势：

其中最核心的一份优势，是"按列存储"。

Pandas的DataFrame本质上是个列优先的数据容器，你做计算的时候是整列整列地批量运算，底层用的又是C语言实现的numpy数组，所以同样是对100万行数据求平均，Pandas只需要一次性扫过这一列，Excel却要逐单元格去解释公式。这也是为什么能跑百万级的关键所在。

1.3 什么样的数据量适合用Pandas

说句实在话，数据量在5万行以内，我自己也经常用Excel处理，没必要非上代码。但一旦你的数据规模往50万行靠拢，或者你需要每天、每周重复做同一套汇总逻辑，那Pandas的脚本化优势就体现出来了。代码写一遍，以后的数据丢进去跑就行，不用再拿鼠标点半天。

另外还有一种情况也建议用Pandas——数据需要跨表关联。Excel里做多表匹配主要靠VLOOKUP，两张表都很大时VLOOKUP慢得令人绝望，而且跨文件引用极易出错。Pandas里一个merge函数就解决了，一会儿我细说。

2. 入门阶段必须掌握的五个DataFrame操作

很多初学者学Pandas最大误区是把API当单词表背。看着文档里几百个方法，今天学drop_duplicates明天学fillna，学完就忘。我的建议很直接：你的真实场景只需要从几个高频操作开始。

2.1 读入数据是第一步，也是第一个坑

一切从读数据开始。日常最常见的是这两个函数：

import pandas as pd # 读Excel df = pd.read_excel("sales_2024.xlsx", sheet_name="订单明细") # 读CSV df = pd.read_csv("sales_2024.csv", encoding="utf-8")

如果你是从Excel转过来的，注意两个细节。第一，CSV和Excel文件读进来之后的DataFrame完全一样，但对百万级数据来说，CSV的读取速度通常比xlsx快很多，因为xlsx本质是个压缩的XML文件，读取时要层层解包解析，CSV就是纯文本逐行扫。第二，编码问题非常容易踩到，read_csv的时候如果遇到中文乱码，先试试encoding="gbk"或者encoding="utf-8-sig"，Windows出品的CSV多半要转一下编码。

还有一个入门阶段容易忽略的参数是usecols。假如原始文件有30列，你只需要其中的5列，那就别把30列全读进来占内存：

df = pd.read_csv("big_sales.csv", usecols=["订单号", "日期", "金额", "客户ID", "渠道"])

这个习惯在数据量小的时候看不出来，到百万级以后，能少读一半内存。

2.2 先摸家底：info、head、describe这一套体检动作

拿到数据之后不要急着清洗，先做体检。我的固定操作是三连：

print(df.head()) print(df.info()) print(df.describe())

head让你看前五行长什么样，用来判断列名是否规范、数据长得是否像你预期。info输出的东西更有价值，每一列的字段类型、非空数量、内存占用都在里面了。你知道吗，info最后会显示一行"memory usage: 156.8 MB"，这一行是判断你后续需不需要做内存优化的关键指标。如果你的数据读进来只有十几万行却占了几百MB，那大概率是列的类型没优化，后面我专门讲。

describe适用于数值列，会告诉你每列的均值、标准差、最小值、四分位数、最大值。这一段跑完，哪些列有离群值，哪些列明显异常，心里基本就有数了。

2.3 筛选、分组、聚合：从自然语言到一行代码

数据分析里最高频的三个动作就是筛选、分组、聚合。举个例子，你脑子里想的是："华东区、渠道为线上的订单里，每个月的总销售额是多少"。这句话翻译成Pandas就是三行：

filtered = df[(df["区域"] == "华东") & (df["渠道"] == "线上")] monthly_sales = filtered.groupby(filtered["日期"].dt.to_period("M"))["金额"].sum()

第一行筛选，用布尔条件组合。注意Pandas里多个条件必须用"&"连接，每个条件都要加括号，否则报错。第二行按月份分组，这里用到了dt.to_period("M")，意思是把日期列转成月份周期，相当于把日期"按月份归类"。

很多人第一步就栽在分组上，是因为忘了groupby之后对象的类型会变成DataFrameGroupBy，不再是普通的DataFrame。你必须对它再做聚合操作（sum、mean、count、agg），才能得到结果。

如果你要同时算多个指标，比如既要总销售额又要订单数，就配合agg使用：

result = filtered.groupby(filtered["日期"].dt.to_period("M")).agg( 销售额=("金额", "sum"), 订单数=("订单号", "nunique") )

这里订单数用nunique，意思是去重计数，如果你直接count，它会数一下这个组里有几条记录，而不是多少个不同订单。这个区别在电商数据里特别容易造成报表失真，我在实际交付中反复跟业务团队确认过这个口径的差异。

2.4 排序和去重：永远记住你处理的是一张"表"

排序用sort_values，去重用drop_duplicates：

top_customers = df.sort_values("销售额", ascending=False).head(10) unique_orders = df.drop_duplicates(subset=["订单号"])

这两个操作很简单，但实际场景里有个细节容易出错：drop_duplicates默认保留第一条重复记录，如果你想保留最后一条，要加keep="last"参数。另外如果原始数据里订单号本身存在空值，去重之前得先确认一下空值占比，避免把大量真实订单误删。空了的数据不算重复，但Pandas默认也会把它当作重复项之一保留一条，处理的时候要留意。

2.5 缺失值处理：先搞清楚为什么缺，再决定怎么填

缺失值处理看起来简单，其实最考验你对业务的理解。处理手段无非就几种：删除、填0、填均值、前向填充。但选哪一种，取决于这个字段为什么为空。

举个例子，订单金额为空，那大概率是异常单，需要谨慎。用户年龄为空，你可以考虑用该渠道的平均年龄填充。库存表里某个商品的补货日期为空，可能只是因为它还没有排期，跟异常没有关系。我在实战中的固定做法是，先跑一下缺失值统计：

missing_ratio = df.isnull().sum() / len(df) print(missing_ratio[missing_ratio > 0])

然后根据缺失比例和字段含义，分列处理，绝不无脑fillna一把梭。对数值型字段，最常见的方案是fillna(0)，但你要想清楚0是否是一个有业务意义的填充值。

3. 百万级数据真正要命的三个性能瓶颈

到了百万行这个量级，你会发现普通的Pandas代码还能跑，但就是慢。明明一个很简单的操作要等好几分钟，这就是性能瓶颈。我踩过的三个最大的坑，今天一次性说清楚。

3.1 dtype是内存大户，object类型会吞掉你的内存

很多人读入数据之后从来不关心列类型。默认情况下，Pandas会把文本列都识别为object类型，而object类型在内存里存的其实是字符串指针，比数值类型昂贵得多。我做过一次实测：一个90万行的数据，里面有三列是分类文本（比如"华东/华北/华南"这种），如果保持object类型，光这三列就占了大约120MB内存，把它们转成category后直接降到5MB左右，内存减少九成以上。

所以大数据的第一个优化动作永远是类型压缩。常用的招数：

df["区域"] = df["区域"].astype("category") df["金额"] = df["金额"].astype("float32") df["订单数"] = df["订单数"].astype("int32")

category类型适合那种重复值很多的列，比如区域、渠道、产品大类，这几个列在百万行数据里往往只有几十种取值，用category再合适不过。数值列则用更小的子类型替代默认的float64和int64，哪怕float32在精度上损失一点点，做汇总分析完全够用。

每次做完类型转换，看一眼df.info()的memory usage，你会直观感受到内存从几百MB掉到几十MB，这会给后续所有操作腾出大量空间。

3.2 循环是万恶之源，向量化才是Pandas的舒适区

新手最容易写的慢代码就是遍历每一行：

# 千万别这么写，100万行会让你等到怀疑人生 for i in range(len(df)): if df.loc[i, "金额"] > 1000: df.loc[i, "等级"] = "高" else: df.loc[i, "等级"] = "低"

这行代码的逻辑没错，但对100万行数据来说，循环加loc逐行定位，双重减速，跑完起码要十分钟起步。Pandas的设计思想是向量化——对整列一次性操作，底层用C语言的循环替你跑，速度是一百倍以上的差距。

同样的逻辑用向量化一行搞定：

df["等级"] = np.where(df["金额"] > 1000, "高", "低")

如果条件复杂，多个列参与判断，可以用np.select：

conditions = [ df["金额"] > 5000, df["金额"] > 1000, df["金额"] > 0 ] choices = ["高", "中", "低"] df["等级"] = np.select(conditions, choices, default="未知")

有很多人问我，什么时候真的要用循环？我的答案是：当你需要逐行依赖前一行计算结果的时候，比如计算累加收益、持仓状态机这类有顺序依赖的业务，循环才不可避免。此时你可以考虑用numba加速，或者尽量将这类操作拆解成累计函数。大多数"想用循环"的场景其实是没找到对应的向量化函数，先找，找不到再循环。

3.3 groupby和merge在数据量上来之后的正确姿势

groupby在百万级数据上如果直接跑，通常问题不大，但如果你在这个基础上又挂了多个agg，还要排序，再合并回原表，那计算量会指数级上升。我常用的原则是：能少合并就少合并，groupby的结果如果只是最终报表，就不concat回原表，保持"分组之后只输出结果"。

merge同理。两张百万级表做关联，默认用how="inner"就行，不要没事就搞how="outer"，外连接会在匹配不到时产生大量空行，内存和行数都会暴涨。另外merge之前建议先对被关联列做类型统一，比如一边是int64一边是object，即使内容一样，merge也会判定无法匹配。我吃过这个亏，客户ID一侧是从Excel读的数字，被读成了float64，一侧是字符串，看起来都是"10086"，merge出来全是NaN，排查了很久才发现是类型不一致。所以merge前的类型检查要养成习惯，用df.dtypes排查一遍再操作。

4. 一次完整的百万行数据实操复盘

理论说了不少，我们干脆从头到尾跑一个完整案例。我构造一个模拟场景：一份某电商平台的交易流水，大约120万行，包含订单号、用户ID、区域、渠道、商品ID、销售日期、销售额、成本、数量、优惠金额这10列。目标是算出每个区域每个渠道的月度销售额、订单量和利润。

4.1 先做环境准备与数据体检

我会先准备环境：

import pandas as pd import numpy as np df = pd.read_csv("sales_120w.csv", encoding="utf-8", parse_dates=["销售日期"]) df.info()

这里parse_dates参数直接把日期列解析成datetime类型，不要等后续再转换。info出来之后看内存占用，我模拟的结果是大概980MB，这个体量在普通配置的电脑上已经有点吃紧了。于是做类型压缩：

df["区域"] = df["区域"].astype("category") df["渠道"] = df["渠道"].astype("category") df["销售额"] = df["销售额"].astype("float32") df["成本"] = df["成本"].astype("float32") df["优惠金额"] = df["优惠金额"].astype("float32") df["数量"] = df["数量"].astype("int8") df["利润"] = (df["销售额"] - df["成本"] - df["优惠金额"]).astype("float32")

此时再跑一遍df.info()，内存占用已经掉到差不多150MB，这个数字对后续计算就很舒服了。

4.2 深度清洗：去重、缺失值、异常值三件套

清洗环节是重头戏，先统计缺失，再处理重复和异常：

print(df.isnull().sum())

假设发现"优惠金额"有2.3万行缺失，这通常是订单没有优惠，填充0是合理的：

df["优惠金额"] = df["优惠金额"].fillna(0)

再看订单号去重，跑一个数量对比：

before = len(df) after = len(df.drop_duplicates(subset=["订单号", "用户ID"])) print(f"去重前后差异: {before - after}")

如果差异显著，说明有大量重复记录，这些通常来自同一个用户重复下单产生的多条流水，在订单明细分析里属于正常情况，不需要删除。但如果同一订单号出现多次，且你统计的是"订单量"这种口径，就必须去重后再统计，否则订单量会虚高。

异常值这一块，我习惯跑一个describe看分布：

print(df[["销售额", "数量", "利润"]].describe())

如果发现销售额最小值是负数，或者利润出现了极度异常的极大值，要单独抽查这些记录，判断是促销冲正还是数据录入错误。模拟数据里我设定了少量销售负值（退款单），这类记录在汇总日常销售额时应该剔除，但它们对退款分析有价值，所以我会单独建一张退款表，而不是简单删掉。

4.3 管道化处理：把清洗逻辑封装进函数

清洗步骤一多，临时写在脚本里就很乱。实际操作中我会把整套清洗封装成一个函数，用pipe一次性串起来：

def clean_sales_data(df): df = df.copy() df["优惠金额"] = df["优惠金额"].fillna(0) df = df[df["销售额"] > 0] df["利润"] = df["销售额"] - df["成本"] - df["优惠金额"] df["销售日期"] = pd.to_datetime(df["销售日期"]) return df df_clean = ( pd.read_csv("sales_120w.csv", encoding="utf-8") .pipe(clean_sales_data) )

这么做的最大好处是：以后每周收到新数据，只需要重复跑一遍管道，不会因为少执行某一步清洗而造成结果前后不一致。数据交付里最忌讳的就是"这次我手动多过滤了一个条件"这类操作，结果下周对不上账。

4.4 按区域渠道汇聚月度核心指标

清洗完之后做汇总，这是百万级数据里最典型的导出需求：

result = ( df_clean .groupby([ df_clean["销售日期"].dt.to_period("M"), "区域", "渠道" ]) .agg( 销售额=("销售额", "sum"), 订单量=("订单号", "nunique"), 利润=("利润", "sum") ) .reset_index() ) result.to_csv("月度区域渠道汇总.csv", index=False, encoding="utf-8-sig")

这段代码在120万行数据上跑，实测大概用了不到5秒。跑完之后result大约几百行，这已经是可以直接交给业务方看的报表级输出了。这里有一个细节很重要，就是groupby里分组键用了df["销售日期"].dt.to_period("M")，这是一个Series而不是列名字符串，这样写是允许的，而且能把日期直接按月归类。如果按月分组的场景很常见，更推荐提前把月份字段单独生成一列，这样后续写代码更清晰：

df_clean["月份"] = df_clean["销售日期"].dt.to_period("M")

4.5 结果校验：别相信一次跑通的结果

跑完汇总之后千万不要直接交差，一定要做结果校验。最稳妥的校验方法是抽一个你熟悉的维度跟原始数据对齐。比如，拿"华东"区域"线上"渠道某一个月的数据，手工用Excel筛选原始文件算一下总销售额，跟你代码输出的结果对一下。对不上的情况绝大多数是过滤条件不一致，比如你有没有把退款单算进去，有没有漏掉空区域的分组。

我另外的习惯是在脚本里做两层自动校验：

# 校验1：汇总后的总销售额等于过滤后的总销售额 assert abs(result["销售额"].sum() - df_clean["销售额"].sum()) < 0.01 # 校验2：每个分组的行数占比要合理 group_counts = df_clean.groupby([ "区域", "渠道", "月份" ]).size() assert len(group_counts) == len(result)

这两层校验成本极低，但你有没有做这步，决定了交付的质量是"看起来对"还是"真对"。数据量越大的时候，越要信不过自己的手，要信校验逻辑。

5. 两年里踩过最深的四个Pandas坑

坑这个东西，不真正踩一遍，光看文档是记不住的。作为一个被坑过无数次的人，我挑四个最伤的例子，按惨痛程度排个序。

5.1 inplace=True的虚假安全感

刚学Pandas时特喜欢写df.dropna(inplace=True)，总觉得加个inplace参数就万事大吉，不用重新赋值。但实际上inplace在很多方法里是有隐患的。第一，Pandas 2.x开始已经在官方文档里不推荐这种用法，未来有可能被移除。第二，inplace依赖函数内部修改原对象，某些方法实际做的是"复制一份再修改再回填"，根本没有省内存。第三，链式调用的场景里inplace经常失效——你对一个切片执行inplace操作，改的只是副本，原DataFrame纹丝不动。

我现在一律写成显式赋值：

df = df.drop_duplicates(subset=["订单号"])

这样代码意图明确，debug时也方便打断点看中间状态。

5.2 链式赋值引发的SettingWithCopyWarning

链式赋值是我见过最隐蔽的Bug来源。和inplace类似，问题出在你对"切片"的理解。下面这段代码：

df[df["金额"] > 100]["折扣"] = 0

很多新手以为这是"把金额大于100的那几行折扣改成0"，实际上Pandas会警告你：这可能是在试图修改一个副本。因为df[df["金额"] > 100]产生的是一个视图或副本，到底改没改到原DataFrame，取决于内部优化，你不该依赖它。正确的写法永远是用.loc：

df.loc[df["金额"] > 100, "折扣"] = 0

记住这条规则就好了：在DataFrame里做条件修改，一律df.loc[条件, 列名] = 新值，不要用链式括号。养成这个习惯之后，我再没遇到过SettingWithCopyWarning。

5.3 索引没有reset，groupby之后悄悄变了样

groupby之后忘了reset_index，是我看别人代码时最常见的问题。groupby的结果行数取决于分组键的取值组合数，但索引是这些分组键的值，你要是还想再继续跟其他DataFrame合并或者做进一步筛选，就会发现索引乱七八糟对不上。如果你在groupby后直接执行to_excel，你会发现左边多了一列看不到名字的索引。

正确的姿势是想清楚：这个中间结果是要继续参与计算，还是作为最终报表。如果是中间结果，分组之后加个reset_index()，把分组键变成普通列，后面怎么操作都不慌。这也是为什么我对agg结果的固定习惯是马上reset_index()。

5.4 read_excel在大型Excel文件上的隐藏慢速

很多人遇到大文件第一步还是pd.read_excel，殊不知这可能是最慢的读法。Excel文件的底层是XML压缩格式，读取时要实时解压和解析，速度远比CSV慢。我测过一个约80MB的xlsx，read_excel用了30多秒，同样数据导出成CSV后read_csv只要5秒。如果是100MB以上的Excel，差距还会更离谱。

所以我的工作流是：如果数据源是大型Excel文件，第一步先用Excel另存为CSV（或者用脚本把xlsx批量转成csv），再做Pandas处理。如果实在只能读Excel，可以考虑用openpyxl引擎配合usecols和nrows参数，先只读一部分看看结构，全量读取留到最后。

还有一个相关的坑：read_excel默认会读取整个sheet的所有行和列，如果sheet里有大量空行，Pandas也会傻乎乎地读进来再丢掉，白白浪费内存和读取时间。加sheet_name参数指定要读的sheet，能省则省。

写在最后的一点个人经验

我刚开始用Pandas处理百万级数据时，心态是"代码能跑就行"，后来才意识到干净、可读、可复现的脚本比跑得快重要得多。因为数据分析工作真正的交付物不是那几张报表，而是"如果有人想复现你的数据结论，能不能照着你的脚本一步步跑出同样的结果"。哪怕你只是给自己用，一周之后回看你也会感谢当初写了清晰注释的自己。

还有一个容易被低估的习惯：每一步处理完都打印一下行数和shape，数据从120万行变成90万行这一步，到底是因为去重还是因为过滤退款，心里要有数。做数据分析最怕的不是报错，而是结果看着"挺合理"但实际上有偏差，那种错误藏得最深，也最难查。

Pandas这条路，入门不难，难的是数据量上来之后那种"感觉自己会用、但一跑就慢、一慢就不知道该优化哪里"的迷茫。我的建议是：先跑通，再想性能，最后再优化内存。别一上手就背一堆优化技巧，等你真遇到那个让你干等10分钟的百万行文件时，你自然会回来翻这篇。