数据分析别再从 Python 开始了：我用 MySQL + Power Query 把女装店周报从 4 小时压到 25 分钟

📅 2026-09-16 ✍️ 老周不加班 📂 数据分析 👁️ 公开 📝 ID: 2037

🔑 关键词：数据分析,SQL周报,Power Query,指标体系,小团队BI

📖 摘要：一个业余创作者的踩坑记录：小团队做数据分析，先别上中台和 Python。用 MySQL 8.0、DuckDB、Power Query 和一张指标字典，把 87 万行订单的周报从 4 小时压到 25 分钟。附具体 SQL、索引和踩坑对比。

先说结论：周报慢，不是 Excel 的锅，是口径在打架

去年 11 月，我帮朋友的女装店看周报。店铺 SKU 1260 个，订单表 87 万行，退款表 11 万行，Excel 文件 38MB，打开一次 1 分 40 秒。老板每周一要 6 个数：GMV、退款率、新客占比、连带率、动销率、售罄率、转化率。原来运营用 VLOOKUP + 透视表，每周一上午 4 小时，还经常对不上。我一开始以为是工具太老，想直接上 Python。结果第一周就翻车：光“退款率”就有 3 个口径——申请退款、退款成功、售后完结；按支付时间还是退款时间归属，每周能差 17 万 GMV。后来我把 13 个指标砍到 7 个，先定口径再谈自动化。这一步比学 pandas 重要 10 倍。

三种方案的真实对比：别拿 87 万行去赌 Excel 的脾气

我同时试了三条路。Excel 透视表：数据小于 5 万行、字段少于 20 个还行，超过 10 万行就卡，刷新一次 2 分 30 秒。MySQL 8.0：87 万行，建好索引后聚合查询 0.6 秒到 2.1 秒。DuckDB：本地 CSV 直接查，87 万行 group by 周日，1.2 秒，内存占用 310MB。具体参数：笔记本是 M1/16G，MySQL 跑在 Docker 里，给了 2 核 4G。所以我的排序是：临时探索用 DuckDB，团队协作放 MySQL，展示用 Power Query 或 Metabase。Python 不是不用，它适合预测、聚类、复杂清洗；但如果你的需求是“按周算 7 个数”，SQL 就够了。别把学习成本花在 10% 的场景上。

我实际跑的步骤：从订单表到 8:45 自动发邮件

第 1 步，建两张底表：orders 和 refunds。orders 只留 12 个字段：order_id、user_id、paid_at、pay_amount、status、channel、province、sku_id 等。refunds 留 order_id、refund_status、refund_at、refund_amount。第 2 步，加索引。CREATE INDEX idx_orders_paid_at ON orders(paid_at); 和 CREATE INDEX idx_refunds_order_id ON refunds(order_id);。加之前 87 万行查 6.8 秒，加之后 0.9 秒。看执行计划用 EXPLAIN，至少要到 ref，别全表扫。第 3 步，用 CTE 写周报 SQL。核心逻辑如下：

WITH base AS (
  SELECT o.order_id, o.user_id, o.paid_at, o.pay_amount,
         CASE WHEN o.status IN ('paid','shipped','done') THEN 1 ELSE 0 END AS is_paid,
         CASE WHEN r.refund_status = 'success' THEN 1 ELSE 0 END AS is_refund
  FROM orders o
  LEFT JOIN refunds r ON o.order_id = r.order_id
  WHERE o.paid_at >= '2024-01-01'
    AND o.paid_at < '2025-01-01'
)
SELECT DATE_FORMAT(paid_at, '%x-%v') AS week,
       COUNT(DISTINCT user_id) AS buyers,
       SUM(pay_amount) AS gmv,
       SUM(is_refund) / SUM(is_paid) AS refund_rate
FROM base
GROUP BY week
ORDER BY week;

第 4 步，Power Query 连 MySQL，设最大连接 5，超时 120 秒，每天 8:30 刷新。刷新完写回 Excel 模板，8:45 用 Outlook 规则发群。整个过程 25 分钟，其中 15 分钟我在看异常值，5 分钟写结论，5 分钟是机器在跑。

一个不太讨喜的观点：先做指标字典，再谈数据中台

很多小团队一上来就买 BI、接 Airbyte、搭 ClickHouse，最后卡在“退款率到底怎么算”。我的做法是先建一张 metric_dict 表：metric_name、definition、formula、owner、update_freq、source_table。比如“退款率 = 成功退款订单数 / 支付订单数，按支付时间归属；owner 是运营；每周一 8:30 更新；来源 orders + refunds”。这张表只有 7 行，但比 70 页报告有用。每周复盘只问 3 个问题：哪个指标变了、变了多少、下一步动作是什么。比如第 8 周退款率从 6.4% 涨到 9.1%，拆到省份发现黑龙江某款羽绒服退货 41 单，原因是尺码偏小。改详情页后第 11 周降到 5.8%。这就是分析的价值，不是画图多漂亮。

最后说点个人感受

我不是数据分析师，主业做内容，SQL 是当年做电商运营时被逼会的。这次帮朋友，我最大的收获不是省了 3 小时 35 分钟，而是发现：小团队最贵的不是工具，是每个人对同一个词的理解不一样。现在我把 SQL 模板存成 .sql 文件，用 Git 管版本，每次改口径都留一行注释。上个月我终于敢在周一早上请假，因为 8:45 邮件自己会发。

🏷️ 标签： SQL实战