Python批量导出数据库数据到Excel：从入门到工程化实战-代码聚汇网

Python批量导出数据库数据到Excel：从入门到工程化实战

Amy青梅·2026-09-05·阅读 23 GEO检测（免费）

PythonPandasopenpyxl

|难度：普通|阅读约 40 分钟

先说我遇到这个需求的典型场景：数据支持岗每天都要给业务方导数据，今天导订单明细，明天导用户列表，后天导库存快照。一开始直接用数据库客户端工具导，表多了以后又慢又累，还得手动调整格式。后来我干脆用 Python 把这件事做成了一个小工具，把“数据库 → Excel”的路径彻底固定下来，批量导出、定时跑批、格式统一，整个效率提升了一个量级。这篇文章就把我实际在用的方案、踩过的坑和优化思路完整写出来，主要适合刚接手数据工作、或者经常被“帮忙导个表”这类需求打扰的同学参考。

主题很明确：用 Python 连接数据库，把查询结果批量写入 Excel 文件。听起来简单，但真正做起来，从数据库连接串配置到 Excel 行列格式，每个环节都有不少细节，稍不注意导出来的文件就是乱码、乱列、科学计数法或者直接内存爆炸。

1. 先搞清楚：批量导出到底解决了什么问题

很多时候我们写代码只是为了解决当下的一个“小请求”，但如果只是临时跑一次，不值得写那么多代码。批量导出的核心价值是把重复劳动自动化，把不确定变成确定。

1.1 我当初遇到的实际场景

我们的业务库里有几十张业务表，覆盖订单、用户、支付、商品等模块。每个月月初，运营、财务、客服三个部门都会提数据需求，要的维度还都不太一样。运营要订单表加用户标签，财务要支付流水加手续费字段，客服要售后记录加处理状态。

一开始我是这样干的：

打开数据库客户端，输 SQL 查询。
查询结果复制出来，粘贴到 Excel。
调整列宽、改字段名、对齐格式。
另存为 xlsx 发给对方。

单次操作 10 分钟，一个月十几张表，加起来至少半天。更头疼的是，每个月同样的表、同样的字段，我还要重新写一遍 SQL，重新调整一次格式，中间只要手抖漏一个字段，业务方就会拿着明显错误的数据来找你。

所以我做了一个很简单的判断：这种批量、重复、规则固定的需求，必须脚本化。

1.2 这个方案的适用边界

要用 Python 批量导出数据库数据到 Excel，首先要确认它适不适合你的场景。我的经验是下面几种情况最合适：

数据量在 Excel 可承载范围内，单表几万到几十万行。
导出规则固定，字段清单、文件路径、文件名可以事先约定好。
需要定时跑批，比如周报、月报、每日数据快照。
需要做字段映射、格式控制、数据脱敏，而不是单纯“导出原表”。

反过来，如果单表几千万行，或者大数据场景下要做复杂的分布式抽取，那应该走数据平台链路，用更专业的抽取工具生成文件，而不是让 Python 脚本在内存里攒一个巨大 DataFrame 再写 Excel。

一句话总结：这个方案解决的是“中等数据量下的重复性导出需求”，优点是灵活、可控、好改，缺点是受制于 Excel 本身的行列上限和单机内存，认清边界才不会选错工具。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 工具链选型：Python + Pandas + openpyxl 为什么够用

做技术的人肯定都知道，实现“数据库导 Excel”这个需求有很多种路径。我在动手之前也纠结过一阵，到底用哪种方案，最后落定 Python + Pandas + openpyxl，下面说说我的取舍过程。

2.1 备选方案的取舍

我把当时想到的几个方案列在一起对比过：

方案	优点	缺点	适用场景
数据库客户端手动导出	简单、零代码	无法批量、无法复用、格式靠手工	偶尔一次
数据库自带导出命令	快、适合大表	不易控制格式、跨平台差	纯数据备份
脚本拼接 CSV	极简、通用	Excel 打开中文易乱码、无格式	数据量较大
Java/PHP 后端定时任务	性能强、适合集成业务系统	开发成本高、改需求麻烦	正式业务系统
Python + Pandas + openpyxl	开发快、生态好、格式可控	大数据量受限	数据支持、自动化报表

对比之后我选了最后一种。原因很实际：Pandas 读写数据库和 Excel 都有现成接口，代码量很少，而且 openpyxl 能让我控制单元格格式，过滤、排序、列宽这些细节都能处理，适合“导完直接能用”的需求。

2.2 环境准备与依赖安装

环境方面没有太复杂的要求，我用的是 Python 3.9+，核心依赖就三个：

bash复制pip install pandas pymysql openpyxl

如果你用的不是 MySQL，也可以根据数据库类型替换驱动：

Oracle：pip install cx_Oracle
PostgreSQL：pip install psycopg2-binary
SQL Server：pip install pyodbc
达梦：安装 dmPython，连接方式和 Oracle 类似

另外一个非常重要的点：Pandas 版本到 2.x 之后，to_excel 写 xlsx 文件默认依赖 openpyxl，写 xls 依赖 xlwt（且 xlwt 已经停止维护，只支持旧格式）。所以我强烈建议直接用 xlsx 格式，不要碰 xls 老格式，省得遇到一堆兼容性问题。

3. 代码落地：从查询到写出 Excel 的核心实现

很多教程会直接甩一个完整脚本，看起来很厉害，但读者不知道每行代码在干嘛。我这边反过来，先给你一个最小可用的版本，然后逐步叠加批量导出、分页、格式控制这些能力，每一步解释为什么这么写。

3.1 最小可用的单表导出

这个版本解决最基础的场景：从数据库查一张表，把结果写入一个 Excel 文件。

python复制import pandas as pd
from sqlalchemy import create_engine

# 拼接数据库连接串
# 格式：数据库类型+驱动://用户名:密码@主机地址:端口/数据库名?参数
engine = create_engine(
    "mysql+pymysql://root:password@127.0.0.1:3306/business_db?charset=utf8mb4"
)

sql = "SELECT * FROM orders WHERE order_date >= '2024-01-01'"

with engine.connect() as conn:
    df = pd.read_sql_query(sql, conn)

df.to_excel("orders_2024.xlsx", index=False, sheet_name="orders")

这段代码里有两个细节值得注意：

第一个，charset=utf8mb4 必须加上。utf8mb4 是 MySQL 真正的完整 UTF-8 编码，能正确存储表情符号和生僻字。如果漏了它，导出来的中文在某些环境下会乱码。

第二个，index=False 必须写。如果不写，Pandas 默认会把行号当成一列数据写进 Excel，导出的文件里多出一列无意义的数字，对方拿到手还得手动删。

read_sql_query 这个方法会把查询结果一次性加载到内存里的 DataFrame，好处是后续可以随意操作，坏处是数据量过大时内存扛不住。这一点我在后面分页导出的部分会重点展开。

3.2 多表批量导出：一张 Excel 多个 Sheet

单表跑通之后，批量导出就很自然了。最常见的需求：指定一批表名，把每张表的数据放到同一个 Excel 的不同 Sheet 里，作为一份完整的数据包发给业务方。

python复制import pandas as pd
from sqlalchemy import create_engine

engine = create_engine(
    "mysql+pymysql://root:password@127.0.0.1:3306/business_db?charset=utf8mb4"
)

# 需要导出的表清单
tables = ["orders", "users", "products", "payments"]

with pd.ExcelWriter("biz_tables_2024.xlsx", engine="openpyxl") as writer:
    with engine.connect() as conn:
        for table in tables:
            sql = f"SELECT * FROM {table}"
            df = pd.read_sql_query(sql, conn)
            # sheet_name 不能超过 31 个字符，且不能包含 / \ ? * [ ] : 这些字符
            sheet_name = table[:31]
            df.to_excel(writer, sheet_name=sheet_name, index=False)
            print(f"表 {table} 导出完成，共 {len(df)} 行")

这里的亮点是 pd.ExcelWriter 上下文管理器。所有 to_excel 操作都在同一个 writer 上执行，最终生成的文件里每个 DataFrame 对应一个 Sheet，Sheet 名字就是表名。

如果表很多，你也可以改成每张表生成一个独立文件：

python复制import os

output_dir = "export_2024"
os.makedirs(output_dir, exist_ok=True)

for table in tables:
    df = pd.read_sql_query(f"SELECT * FROM {table}", engine)
    df.to_excel(os.path.join(output_dir, f"{table}.xlsx"), index=False)

单文件多 Sheet 适合汇总类需求，多文件适合各表格独立分发的场景。我实际使用中更喜欢前者，因为交接方便，一个文件发过去就行。

3.3 代码里几个容易被忽略的细节

写完整套代码，我再补充几个容易踩坑的点：

SQL 注入风险。如果你把表名、字段名直接拼进 SQL，一旦来源不可控，很容易被注入。我这边表名是写死在配置文件里的，风险可控，但如果做成了对外界面，一定要做白名单校验。

表名当 Sheet 名要特殊处理。Excel 的 Sheet 名称有长度限制和非法字符限制。表名超 31 字符会报错，含特殊字符也会报错，所以上面代码里加了 [:31] 的截断。更稳妥的做法是提前做一个清洗函数。

别在生产库跑全表查询。批量导出最容易捅的篓子就是 SELECT * FROM 大表 直接把数据库内存拖垮。我一般加两个保险：一个是通过 LIMIT 预先看一下数据量，另一个是查询必须带上时间分区或者明确的条件，避免全表扫描。

4. 大数据量怎么办：分批导出与内存控制

以前我用最原始的方式导 100 万行数据，程序跑着跑着就 MemoryError，一度怀疑是数据库的问题。后来发现根本不是数据库问题，是 Pandas 把全部结果都塞进了内存。

4.1 一次性读全量的问题

read_sql_query 默认会把所有查询结果先放到内存，再返回 DataFrame。如果你的查询结果集是 100 万行、50 列，那内存里可能要占用 1GB 甚至更多，还没开始写 Excel 程序就垮了。

解决思路有两个方向：

分页查询，每次只取一批，取完就写。
用游标逐批读取，配合 DataFrame 分段写入 Excel。

两种方向本质都是“化整为零”，区别在于实现方式。

4.2 基于 LIMIT/OFFSET 的分批导出实现

LIMIT/OFFSET 是 MySQL 里最简单直观的分页方式，我最早用这个方案，代码长这样：

python复制PAGE_SIZE = 50000  # 每一批导出的行数
offset = 0
total = 0

with pd.ExcelWriter("big_orders.xlsx", engine="openpyxl") as writer:
    while True:
        sql = f"SELECT * FROM orders LIMIT {PAGE_SIZE} OFFSET {offset}"
        df = pd.read_sql_query(sql, engine)

        if df.empty:
            break

        # 第一页写表头，后续各页不写表头，从对应行位置追加
        if offset == 0:
            df.to_excel(writer, sheet_name="orders", index=False, startrow=0)
        else:
            df.to_excel(
                writer,
                sheet_name="orders",
                index=False,
                header=False,
                startrow=offset + 1,  # +1 是因为第一行已经被表头占用
            )

        offset += PAGE_SIZE
        total += len(df)
        print(f"已导出 {total} 行")

这个方案有几个地方要特别注意：

第一，startrow 必须算对。写入 Excel 时，第一行是表头，数据从第 2 行开始。如果第一页有 50000 行，第二页的数据应该从第 50001 行开始写，代码里的 offset + 1 就是这么来的。

第二，header=False 只在后续页生效。如果每一页都写表头，文件里会出现几十个重复标题行，业务方看到绝对会骂人。

第三，LIMIT/OFFSET 在大偏移量时性能会下降。OFFSET 1000000 时数据库引擎需要扫描并丢弃前 100 万行，查询会越来越慢。对于一次性导出 100 万行以内的数据，这个方案够用；再大的数据量，建议换游标方案。

4.3 更彻底的流式读取方案

如果你处理的是几百万行的大表，我推荐用游标逐批读取，避免 OFFSET 偏移性能损耗。

MySQL 连接驱动 pymysql 里有一个 SSCursor，它不缓存全部结果集，而是从服务端边取边用，真正实现流式读取。

python复制import pandas as pd
from pymysql.cursors import SSCursor

connection = engine.raw_connection()
cursor = connection.cursor(SSCursor)  # 流式游标

cursor.execute("SELECT * FROM orders")
columns = [desc[0] for desc in cursor.description]

BATCH_SIZE = 50000
total = 0
is_first = True

with pd.ExcelWriter("big_orders_stream.xlsx", engine="openpyxl") as writer:
    while True:
        rows = cursor.fetchmany(BATCH_SIZE)
        if not rows:
            break

        df = pd.DataFrame(rows, columns=columns)
        df.to_excel(
            writer,
            sheet_name="orders",
            index=False,
            header=is_first,
            startrow=total,
        )
        total += len(df)
        is_first = False
        print(f"已导出行数: {total}")

cursor.close()
connection.close()

这个方案用 fetchmany 每次只取 50000 行，内存里始终只有这一批数据，即使总数是几百万行也不会爆内存。注意，SSCursor 有一个限制：读数据期间同一连接上不能再发其他查询，所以导出过程中不要做额外的数据库操作。

4.4 分批导出过程中的稳定性提示

分页导出还有两个工程层面的点提醒一下。

第一个，写 Excel 的时间比查询还长。Excel 的 xlsx 格式本质是一个压缩的 XML 文件，写入时要做 XML 序列化和压缩，速度远低于内存中处理 DataFrame。所以大批量导出时，进度提示最好每批都打，否则你根本不知道程序卡在查询还是卡在写入。用我上面的 print 就是一个最基础的做法，工程化之后可以换成 logging。

第二个，批与批之间如果中断了，很难续跑。我的做法是：导出前先检查目标文件是否已存在，如果存在就重命名备份；同时每批写完后记录日志，方便排查挂在哪一步。你有条件的话，也可以每批写一个独立的临时表，全部处理完再合并，但合并 xlsx 相对麻烦，倒不如直接用游标方案减少失败概率。

5. 导出的不是“能打开”就行：输出细节才是口碑分

有段时间我导出的 Excel 经常被业务方打回来，原因不是数据错了，而是格式太乱：列顺序和对方要的不一致，日期格式没法筛选，长数字显示成科学计数法。从那以后我就学乖了，导出文件之前先做一层“输出控制”，把列、格式、外观都整理好。

5.1 列顺序与字段映射

业务方往往不关心数据库里的原始字段名，他们想要的是“用户ID、手机号、下单时间”。这时候就要做字段映射和列顺序调整。

python复制column_map = {
    "user_id": "用户ID",
    "mobile": "手机号",
    "order_time": "下单时间",
    "order_amount": "订单金额",
}

# 1. 先只选需要的列，再重命名
col_list = ["user_id", "mobile", "order_time", "order_amount"]
df = df[col_list].rename(columns=column_map)

这里有一个非常实用的习惯：先选列再重命名，而不是先重命名再按中文列名选列。如果 rename 后再 df[["用户ID", "手机号", ...]]，一旦某个字段写错，报错信息不好定位。先保证原字段的列顺序，再统一重命名，逻辑更清晰。

数据库里字段很多时，整表导出再裁剪是最常见的做法。但如果表有几百个字段，我建议 SQL 里就写好需要的字段名，不要无脑 SELECT *，这样既能减少内存占用，也能避免导出时看到一堆业务方不关心的中间字段。

5.2 追加写入已有 Excel

有时候我们不是每次生成新文件，而是要把新导出的数据追加到一个已有的 Excel 里。比如月度报表，1 月导一次，2 月导一次，最终落在同一个工作簿的不同 Sheet。

Pandas 的 ExcelWriter 支持追加模式：

python复制with pd.ExcelWriter(
    "monthly_report.xlsx",
    engine="openpyxl",
    mode="a",  # a 代表追加
    if_sheet_exists="replace",  # 如果 Sheet 已存在，则替换
) as writer:
    df.to_excel(writer, sheet_name="2024-02", index=False)

mode="a" 是追加模式，if_sheet_exists="replace" 表示同名的 Sheet 会被覆盖。这个组合非常实用，尤其是跑批任务重复执行时，不会因为 Sheet 已存在而报错，也不会每次跑都累积出一个全是重复数据的 Sheet。

不过追加模式只能操作已有的 xlsx 文件，文件不存在时会报错。稳妥的做法是先判断一下文件是否存在：

python复制import os

file_path = "monthly_report.xlsx"

if not os.path.exists(file_path):
    with pd.ExcelWriter(file_path, engine="openpyxl") as writer:
        df.to_excel(writer, sheet_name="2024-02", index=False)
else:
    with pd.ExcelWriter(file_path, engine="openpyxl", mode="a", if_sheet_exists="replace") as writer:
        df.to_excel(writer, sheet_name="2024-02", index=False)

5.3 让 Excel 打开后更好看：列宽与格式

同样是导出一份数据，用默认设置导出的 Excel 列宽参差不齐，长文本全挤在一起；调整过列宽的 Excel 打开后人看着舒服很多，也省去业务方自己调整的时间。

关键是利用 openpyxl 的列宽设置：

python复制from openpyxl.utils import get_column_letter

with pd.ExcelWriter("orders_formatted.xlsx", engine="openpyxl") as writer:
    df.to_excel(writer, sheet_name="orders", index=False)

    # 获取当前工作表
    ws = writer.book["orders"]

    # 根据列内容长度动态设置列宽
    for col_idx, col_name in enumerate(df.columns, 1):
        # 计算该列最大长度：标题长度和内容长度取最大
        max_len = max(
            df[col_name].astype(str).map(len).max(), len(str(col_name))
        )
        # 留一点余量
        width = min(max_len + 2, 50)
        ws.column_dimensions[get_column_letter(col_idx)].width = width

这段代码的核心逻辑是：遍历每一列，计算该列数据中最长的字符串长度，加上 2 个字符的余量作为列宽，同时限制最大 50，防止某列内容特别长导致整个表格宽度失控。

如果你还想调整字体、背景色、冻结首行，openpyxl 都能做，但我建议先满足核心需求，格式这东西是“够用就行”，千万不要花半天调颜色，结果业务方根本没打开看。

6. 踩坑记录：这些坑我帮你提前踩过了

写这个工具的过程中，我实打实踩过不少坑，有一些是报错信息很容易看出原因的，有一些则是文件打开以后才发现数据不对，非常隐蔽。这里挑几个典型问题写出来，都是实际生产环境遇到过的。

6.1 连接串没带 charset 导致的乱码

第一次导出的 Excel 里中文全是“？？？”或者一堆乱码，第一反应是 Excel 的问题，查了半天发现是数据库连接串的问题。

MySQL 默认连接字符集不是 utf8mb4，如果没有显式指定，中文很可能在传输过程中就已经损坏了。解决办法就是在连接串里加上 charset=utf8mb4。

python复制engine = create_engine(
    "mysql+pymysql://root:password@127.0.0.1:3306/business_db?charset=utf8mb4"
)

这里有个额外的坑：SQLAlchemy 解析连接串参数时，charset 是传给底层驱动 pymysql 的参数，如果写成 ?charset=utf8，遇到表情符号和生僻字还是会出问题。统一用 utf8mb4 就对了。

6.2 时间字段在 Excel 里变成一串数字

数据库里的 2024-01-15 10:30:00，导出到 Excel 后变成了 45341.4375 这种数字。第一次遇到这个问题的同学大概率会懵，其实这是 Excel 的日期存储机制导致的。

Excel 内部把日期时间存储为浮点数，整数部分是天数，小数部分是时间比例。Pandas 写入时如果没有正确识别列类型，就会把时间对象当作数字写进去。

解决办法是把时间列先转成字符串：

python复制for col in df.select_dtypes(include=["datetime64[ns]"]).columns:
    df[col] = df[col].dt.strftime("%Y-%m-%d %H:%M:%S")

这样 Excel 里看到的就是文本格式的日期时间，既不影响阅读，也能用文本筛选功能。缺点是你要做日期计算的话，需要先转回日期格式，但大多数业务方的诉求只是看时间、排序时间，文本格式完全够用。

6.3 长数字被 Excel 显示成科学计数法

订单号、身份证号、银行卡号这类长数字，导到 Excel 里经常变成 8.21E+17 这种科学计数法，数据本身没丢，但是显示不对，用户还以为数据错了。

最简单的处理方式：提前把这些列转成字符串，并且去掉末尾可能出现的 .0。

python复制df["order_no"] = df["order_no"].astype(str).str.replace(r"\.0$", "", regex=True)

为什么要去掉 .0？因为数据库里的字段如果类型是 DECIMAL，Pandas 读出来后可能是 float，比如 821000000000000001.0，转成字符串以后尾巴会带 .0，所以要正则替换掉。

订单号、身份证这类字段在 SQL 里最好直接 CAST(字段 AS CHAR) 处理，一步到位。

6.4 空值列被推断成 float，出现了小数点

数据库里的字段明明存的整数，导出到 Excel 后变成了 100.0、95.0 这样的格式。原因是 Pandas 读取数据时，如果这一列存在空值 NaN，整数列会被自动升级为 float64，因为 NaN 本身是浮点类型。

处理办法有两种。第一种是填充空值：

python复制# 数值列空值填 0，文本列空值填空字符串
df["age"] = df["age"].fillna(0).astype(int)
df["remark"] = df["remark"].fillna("")

第二种是使用 Pandas 可空整数类型，它既能保留空值，又能保持整数类型：

python复制df["age"] = df["age"].astype("Int64")

可空整数类型在导出到 Excel 的时候会保留空值单元格，同时数值显示不会带 .0。这个特性在你不想把空值强行填 0 的时候特别好用。

7. 从“跑通”到“长期跑”：脚本工程化的小建议

脚本写完之后，短期内确实效率很高，但时间一久，你就会遇到新的问题：脚本挂在服务器上跑了半个小时没反应，不知道是正常还是卡死了；业务方改了表结构，导出脚本直接报错；某个表数据量突然变大，导出文件超过 Excel 限制，整个任务失败。这些都不是“能跑”阶段能想到的，下面是我总结的几个工程化建议。

7.1 日志、重试与告警

脚本加日志是最低成本的投资。我通常把 print 换成 logging，输出到控制台的同时写入日志文件，方便排查。

python复制import logging

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s [%(levelname)s] %(message)s",
    handlers=[
        logging.FileHandler("export.log", encoding="utf-8"),
        logging.StreamHandler(),
    ],
)

有日志之后，再配合简单的失败重试。数据库偶尔会有连接中断、锁等待超时的问题，不是 SQL 本身的错，重试一次往往就成功了。我习惯对单个表做三次重试，重试间隔递增，比如 5 秒、15 秒、30 秒。

更进一步，可以加上结果通知。任务跑完以后通过钉钉机器人、企业微信机器人或者邮件发一条消息，内容包括“本次共导出几张表、多少行、耗时多久”。这个在定时任务场景下特别重要，否则你每天早上都要去服务器上盯任务成功没有。

7.2 查询尽量放在从库/读库

这个看起来像废话，但还是得单独强调。批量导出往往是重查询，几张大表 JOIN 起来，或者不加条件全表扫描，对生产库的压力是实打实的。我见过因为一个统计导出脚本，把核心业务库的 CPU 打到 100%，差点造成线上事故。

所以我的铁律是：能连从库就连从库，没有从库就把查询时间限制在业务低峰期，并且用 EXPLAIN 看一下 SQL 的执行计划，避免走了全表扫描还不知道。

另外，SQL 里最好带上时间等条件，既能减少数据量，又能避免每次跑批把全表数据都拿出来。比如订单表，你永远没有理由一次性导出过去十年的全部订单。

7.3 从命令到定时任务

脚本稳定以后，我把它封装成了命令行工具，支持 --date、--tables 参数，这样每次跑批不需要改代码，只需要改参数。

bash复制python export_to_excel.py --tables orders,users --date 2024-03-01

然后通过系统自带的任务计划定时执行：

Linux 上用 crontab，比如每天凌晨 2 点执行：

bash复制0 2 * * * cd /opt/export && python export_to_excel.py >> export.log 2>&1

Windows 上用任务计划程序，指定运行 python.exe 和脚本路径。

定时任务跑起来后，整个批量导出才算是真正脱离了“人肉定时器”，变成了一套自动化的数据交付链路。

最后再说一个我后来才想明白的道理：这种工具类脚本，一开始觉得只要“能跑”就行了，但在真实业务里，可维护性和稳定性比技术含量重要得多。你写一个花哨的装饰器，不如在日志里多打一行“总行数”；你用上复杂的设计模式，不如把表清单放到配置文件里。导数据的工具，最后拼的往往就是这层“看着不起眼但真正扛事”的工程习惯。