「幫我抓出今年截至目前，累積消費金額最高的 15 位會員，再列出他們的訂單數、平均客單價，以及最近一次購買日期。」

把我遇過的需求情境換成電商案例，大概就像上面這句話。對象、時間範圍、排名條件和指標都列好了，聽起來很明確，應該可以直接開始撈資料了吧？

以前的我，可能已經打開資料庫，開始寫 SQL。但後來我才發現，除了模糊的需求需要釐清，這種看起來已經很完整的需求，也值得多問幾句。因為對方清楚說出「想要哪些資料」，不代表我們已經理解「他想解決什麼問題」。

他列出的欄位，可能只是他知道的那幾個

需求方提出的資料清單，往往受限於他對資料的認識。他知道哪些指標，就會先提出哪些指標；其他可能更有幫助的資訊，他未必知道可以取得。

我曾經遇過這樣的情況：需求方要了一份高消費客戶名單，名單交出去後，我卻發現，對方不是直接用資料，居然還打開系統後台，一位會員、一位會員地查詢歷史累積消費金額、首次購買日期，以及過去下過幾筆訂單。

原來，對方不知道這些資料也可以一起撈出來。

如果一開始多問一句：「你拿到這份名單之後，接下來會做什麼？」我們可能就能提早發現這些需求，省下後續人工查找的時間。身為分析師，我們比需求方更熟悉資料存在哪裡、有哪些欄位，以及可以如何組合。這份專業，也能用來幫對方找到更適合的資訊。

名單抓對了，行銷卻做錯了：你問過用途嗎？

「這份資料，你打算拿來做什麼？」

有時候，得到的回答會是：「其實我也不確定，我再去問一下。」

聽到這裡，先別急著覺得對方沒有準備好。有時候，他只是接到主管或客戶的問題，希望盡快把資料準備齊全，還沒機會確認背後的目的，而這份資料究竟能不能回答問題，正是我們需要一起釐清的地方。

同樣以「Q1 到 Q2 累積消費金額最高的 15 位會員」為例，如果目的是喚回舊客，只按照消費金額排名，可能就找錯了對象。因為這 15 位會員如果至今仍持續下單，就未必需要被「喚回」。我們可能還需要看距離上次購買的天數、過往購買頻率，以及最近一段時間是否仍有訂單。

即使同樣是 60 天沒購買，對每月補貨的消耗品和一年才換一次的耐用品來說，意義也不一樣。要找誰回來，得先理解商品的購買週期。

另外，為什麼是 15 位？是因為活動預算只能支援 15 位客戶？行銷團隊一次只能聯繫這麼多人？還是對方只是先提出一個數字？

這些答案會影響名單該怎麼篩選，也會影響後續是否需要調整人數。多問幾句，是在幫雙方確認：眼前準備做的事情，是否真的能支援接下來的行動。

「再幫我拆一下」：為什麼交件才是修改的開始？

有些需求在提出時，對方確實已經想過了。只是看到實際結果之後，才發現資料和自己想像的不太一樣。

例如，一開始只想看某個商品類別的營收和訂單數，拿到資料後才發現，還需要拆分新客與舊客、廣告與自然流量，才能判斷成長來自哪裡。又或者，原本指定最近 30 天的轉換率，看到結果後才想起，這次要評估的是上週才開始的促銷活動，因此需要另外看活動期間的表現。時間範圍一改，比較基準也得一起確認。

這類調整未必代表對方反覆無常。有些問題，確實要等資料攤開來，才會變得具體。

但我們可以讓這個確認提早發生。在完成整份分析之前，先提供一小部分資料、簡單的圖表，或預計交付的欄位，讓對方確認：「這樣的內容，能幫你回答原本的問題嗎？」

提早看到結果的樣貌，通常比等到全部做完後再修改，更容易控制調整的範圍。

「你是專業的，你決定」：最容易漏掉的業務背景

還有一種情況是，需求方認為自己只需要提出想法，至於該用什麼指標、怎麼抓資料、如何分析，都應該交給分析師判斷。這樣的期待可以理解。畢竟，處理資料確實是我們的專業。

不過，有些資訊仍然需要需求方提供：為什麼現在需要這份分析？結果會交給誰看？看完之後，會做什麼決定？如果缺少這些背景，即使分析師有能力把資料處理得很完整，也可能選錯方向。

所以，遇到這類需求時，我會把問題問得更具體：「你現在最想確認的是什麼？」「如果結果比預期高或低，你接下來會怎麼做？」

如果需求方依舊請你出意見，那也沒關係，了解業務背景與決策情境，才有辦法發揮你的分析專業，判斷資料和方法，雙方的專業才有機會接起來。

一句「順便看一下」，讓分析範圍愈做愈大

有時候，需求一開始真的很單純，只是資料帶出了新的問題。

例如，原本只是想估算促銷活動的營收，看到結果後才發現，有少數會員下了大額訂單，拉高整體平均客單價。接著，對方又想看這些人買了什麼、用了哪些優惠券，以及後續是否回購。

這也是分析的價值之一：資料能幫助我們發現原本沒想到的事情。只是，新想法出現之後，最好先停下來確認優先順序，例如，這個發現會不會改變原本的結論？需要在這次交付前處理嗎？還是可以另外安排下一輪分析？

分析師也可以主動提出判斷。例如：「目前平均客單價受到幾筆大額訂單影響。我建議先比較包含與排除這些訂單的結果，再決定要不要深入分析這群會員。」

帶著初步觀察和建議討論，更有助於雙方決定下一步，也能避免分析範圍在不知不覺中持續擴大。

少做白工的關鍵：寫 SQL 前，先多問這一句

做了幾次這樣的需求之後，我愈來愈常把這句話放在開始工作的前面：「你想拿這份資料做什麼？」

這個問題，能幫我們判斷該找哪些資料、用什麼方式呈現，以及做到什麼程度才足夠。另一件同樣重要的事，是分析師自己必須清楚這份資料的解讀限制。

以電商資料來說，消費金額有沒有扣除退款？訂單數是否排除取消訂單？平均客單價使用哪一種金額與訂單口徑？計算回購率時，觀察的是哪一批會員、多久內的再次購買？這些定義會影響結果。若新會員加入時間不同，有些人甚至還沒有完整的回購觀察期，也不適合直接拿同一個比例比較。

理解用途，讓我們知道資料該怎麼準備；理解限制，則能幫助對方更恰當地使用結果。愈明確的需求，往往愈容易讓人想立刻動手。但在打開資料庫之前，多花一點時間確認背後的目的，常常能省下後續更多的修改與往返。

下次收到一份條件完整、指標清楚的需求時，不妨先多問一句：「了解，那這份資料的目的是什麼，打算怎麼用？」

---

Buy me a coffee 用行動支持我的內容創作

如果文章對你有幫助，歡迎用小額贊助支持 Sharon 持續分享數據分析實務。

上一篇 SQL 面試題進階：CTE、Window Function 與 10 道常見練習題（上），我們用五道題目練習 CTE、累積計算與排名。你應該已經發現，進階 SQL 不只是多寫幾層 WITH，而是每一層都要知道自己正在回答哪個問題。

這篇接著分享第 6～10 題，從 30 天內回購率一路練習到 Cohort 留存。這幾題更接近實務分析，也更容易出現「Query 可以執行，但指標定義不對」的情況。

練習使用的資料表與共同假設

SQL 延續入門篇，使用 Amazon Athena engine version 3 語法。orders 包含 order_id、customer_id、order_date、order_status、total_amount；order_date 是 YYYYMMDD 整數，例如 20250831，需要先轉成 DATE。

以下假設一列就是一張訂單，order_id 唯一，customer_id 與日期沒有缺漏，日期也都是有效值；completed 代表納入分析的完成訂單。total_amount 是已確認可加總、非 NULL 的最終金額，折扣、退款與運費處理一致，且已統一幣別。這些是假設，實務上要先和面試官確認，不能只靠欄位名稱猜測。

每題都附上 clean_orders，讓你可以各自複製整段 SQL 練習。它只處理訂單狀態與日期轉換，並不會自動解決重複資料、退款或異常日期。若原始資料是商品明細，請先整理成每張訂單一列；如果歷史不完整，首購相關結果只能稱為「可觀察資料中的首購」。

第 6 題：如何計算 30 天內回購率？

首購後 30 天內有沒有再買，看起來找第二筆訂單就能回答。但昨天才首購的人，和已經觀察三個月的人，真的能一起放進分母嗎？

下手之前，你可以先問：

1. 30 天內是否包含首購當天的另一張訂單，以及第 30 天？

2. 回購率分母是首購顧客，還是所有購買顧客？

3. 資料完整到哪一天？每位顧客是否都已經有完整 30 天可以觀察？

假設資料完整到 2025 年 6 月 30 日，只納入首購後已滿 30 天的顧客；同日另一張完成訂單也算回購，第 30 天包含在內。用 order_id 區分訂單，避免把首購本身算成回購。

WITH clean_orders AS (
    SELECT
        order_id
        , customer_id
        , CAST(DATE_PARSE(CAST(order_date AS VARCHAR), '%Y%m%d') AS DATE) AS order_dt
        , total_amount
    FROM orders
    WHERE order_status = 'completed'
),
params AS (
    SELECT
        DATE '2025-06-30' AS as_of_date
),
ranked AS (
    SELECT
        o.*
        , ROW_NUMBER() OVER (
            PARTITION BY customer_id ORDER BY order_dt, order_id
        ) AS rn
    FROM clean_orders o CROSS JOIN params p
    WHERE o.order_dt <= p.as_of_date
), eligible AS (
    SELECT
        r.customer_id
        , r.order_id AS first_order_id
        , r.order_dt AS first_dt
    FROM ranked r CROSS JOIN params p
    WHERE r.rn = 1 AND DATE_ADD('day', 30, r.order_dt) <= p.as_of_date
), flags AS (
    SELECT
        f.customer_id
        , MAX(CASE WHEN o.order_id IS NOT NULL THEN 1 ELSE 0 END) AS has_repeat
    FROM eligible f LEFT JOIN clean_orders o
      ON f.customer_id = o.customer_id
     AND o.order_id <> f.first_order_id
     AND o.order_dt BETWEEN f.first_dt AND DATE_ADD('day', 30, f.first_dt)
    GROUP BY f.customer_id
)
SELECT
    COUNT(*) AS eligible_customers
    , COALESCE(SUM(has_repeat), 0) AS repeat_customers
    , ROUND(100.0 * SUM(has_repeat) / NULLIF(COUNT(*), 0), 2) AS repeat_rate_pct
FROM flags;

先決定誰有資格進入分母，再為每位顧客建立是否回購的旗標。一個人買五次也只算一位回購顧客。沒有符合觀察期的顧客時，比例回傳 NULL，不能把「無法計算」寫成 0%。

例如 6 月 1 日首購，到 6 月 30 日還沒有滿 30 天，就不納入分母；5 月 31 日首購則可以。若公司規定同日不算回購，把日期下限改成 o.order_dt > f.first_dt。只有日期時，也不能宣稱這是精確到小時的 720 小時回購率。

第 7 題：如何找出連續兩個月購買的顧客？

同一位顧客有兩筆訂單，不代表他連續兩個月都買過。先想一下，如果兩張都在 1 月，直接對訂單使用 LAG 會得到什麼？

下手之前，你可以先問：

1. 連續兩個月是相鄰日曆月，還是兩次購買相隔 30 天？

2. 結果要列出每一組相鄰月份，還是只要顧客名單？

3. 同一個月買很多次，是否只計算一次活躍？

假設只要找出曾在相鄰日曆月完成購買的顧客，每位顧客只出現一次。先將資料整理成每位顧客每月一列。

WITH clean_orders AS (
    SELECT
        order_id
        , customer_id
        , CAST(DATE_PARSE(CAST(order_date AS VARCHAR), '%Y%m%d') AS DATE) AS order_dt
        , total_amount
    FROM orders
    WHERE order_status = 'completed'
),
customer_months AS (
    SELECT DISTINCT
        customer_id
        , DATE_TRUNC('month', order_dt) AS order_month
    FROM clean_orders
), compared AS (
    SELECT
        *
        , LAG(order_month) OVER (
            PARTITION BY customer_id ORDER BY order_month
        ) AS previous_month
    FROM customer_months
)
SELECT DISTINCT
    customer_id
FROM compared
WHERE order_month = DATE_ADD('month', 1, previous_month)
ORDER BY customer_id;

DISTINCT 先把同月多張訂單收斂成一次月活躍，LAG 才是在比較相鄰的購買月份。最後仍然要檢查相差一個月，因為上一筆有購買的月份也可能是三個月前。

1 月 31 日與 2 月 1 日各買一次，符合這題；1 月 1 日與 1 月 30 日各買一次則不符合。若想知道是哪些月份連續購買，可將最後的欄位改成 customer_id、previous_month、order_month，並保留每一組結果。

第 8 題：如何將顧客依消費金額分成 5 組？

行銷同事想把顧客分成五組，安排不同的溝通方式。你可能想到 NTILE(5)，但他要的是每組人數差不多，還是每組營收差不多？這兩件事可不一樣。

下手之前，你可以先問：

1. 分群依照歷史消費，還是最近半年？

2. 同金額顧客可以分到不同組嗎？

3. 沒有購買的會員是否也要分組？

4. 這個分群要用於發優惠券，還是只是觀察消費分布？

假設針對 2025 年上半年有完成訂單的顧客，依總消費分成五個人數盡量接近的組；接受同額顧客被分開，並以 customer_id 固定排序。

WITH clean_orders AS (
    SELECT
        order_id
        , customer_id
        , CAST(DATE_PARSE(CAST(order_date AS VARCHAR), '%Y%m%d') AS DATE) AS order_dt
        , total_amount
    FROM orders
    WHERE order_status = 'completed'
),
customer_spend AS (
    SELECT
        customer_id
        , SUM(total_amount) AS total_spend
    FROM clean_orders
    WHERE order_dt >= DATE '2025-01-01' AND order_dt < DATE '2025-07-01'
    GROUP BY customer_id
)
SELECT
    customer_id
    , total_spend
    , NTILE(5) OVER (ORDER BY total_spend DESC, customer_id) AS spend_group
FROM customer_spend
ORDER BY spend_group, total_spend DESC, customer_id;

第 1 組是消費較高的顧客，但不代表它剛好貢獻 20% 營收。NTILE 主要控制每組人數，總人數無法整除時，各組人數最多差一人；如果只有三位顧客，也不會憑空產生五個都有人的組別。

假設有 10 位顧客，每組會有 2 人，但第一組可能就貢獻一半營收。如果同額顧客收到不同優惠會造成困擾，就應先討論固定金額門檻或同分處理方式，不能只因為 NTILE 寫起來方便就直接使用。

第 9 題：如何計算新客與舊客的月營收？

如果想知道營收成長來自新客還是舊客，只把第一張訂單標成新客訂單就好了嗎？先想一下：顧客在首購當月買了三次，後面兩張要算哪一邊？

下手之前，你可以先問：

1. 新客是當月註冊，還是當月第一次完成購買？

2. 首購當月的所有訂單都算新客營收，還是只算第一張？

3. 是否有完整歷史可以辨認真正的首購月份？

假設新客定義為當月首購的顧客，首購當月所有完成訂單都歸入新客營收，之後月份才算舊客。我們展示 2025 年上半年，但先用完整歷史找首購。

WITH clean_orders AS (
    SELECT
        order_id
        , customer_id
        , CAST(DATE_PARSE(CAST(order_date AS VARCHAR), '%Y%m%d') AS DATE) AS order_dt
        , total_amount
    FROM orders
    WHERE order_status = 'completed'
),
first_purchase AS (
    SELECT
        customer_id
        , DATE_TRUNC('month', MIN(order_dt)) AS first_month
    FROM clean_orders GROUP BY customer_id
), labeled AS (
    SELECT
        DATE_TRUNC('month', o.order_dt) AS order_month
        , o.customer_id
        , o.total_amount
        , CASE WHEN DATE_TRUNC('month', o.order_dt) = f.first_month
                    THEN 'New' ELSE 'Existing' END AS customer_type
    FROM clean_orders o JOIN first_purchase f ON o.customer_id = f.customer_id
    WHERE o.order_dt >= DATE '2025-01-01' AND o.order_dt < DATE '2025-07-01'
)
SELECT
    order_month
    , customer_type
    , COUNT(DISTINCT customer_id) AS purchasing_customers
    , SUM(total_amount) AS revenue
FROM labeled
GROUP BY 1, 2
ORDER BY 1, 2;

first_purchase 每位顧客只有一列，因此接回訂單時不會因為多筆首購資料而放大營收。這題的分類單位是「顧客在某個月的身分」，和上集逐張標記首購、回購訂單的邏輯不同。

例如顧客 1 月首購 100 元、1 月再買 200 元、2 月買 300 元，1 月新客營收是 300 元，2 月舊客營收是 300 元。這份結果只列有訂單的月份與類別；報表若需要零值列，還要補上月份與 New／Existing 的組合。

第 10 題：如何建立 Cohort Retention Table？

公司想知道「1 月來的新客，到了 2 月還有多少人回來？」這時候可以使用 Cohort。不過，回來是指登入、開信，還是真的又買了一次？如果只拿到訂單表，我們能回答的範圍也要先說清楚。

下手之前，你可以先問：

1. Cohort 依註冊月還是首購月分組？

2. 留存代表有完成購買，還是任何活躍行為？

3. 中間一個月沒買，下一個月回來是否仍算該月留存？

4. 哪些月份已完整觀察？尚未發生的月份應該留白，還是填 0？

假設以首購月分群，後續某月有完成訂單就算該月購買留存，不要求每月連續購買。資料完整到 2025 年 6 月 30 日，展示 2025 年上半年首購的 Cohort，只產生已完整觀察的月份。

WITH clean_orders AS (
    SELECT
        order_id
        , customer_id
        , CAST(DATE_PARSE(CAST(order_date AS VARCHAR), '%Y%m%d') AS DATE) AS order_dt
        , total_amount
    FROM orders
    WHERE order_status = 'completed'
),
params AS (
    SELECT
        DATE '2025-06-01' AS last_complete_month
),
observed_orders AS (
    SELECT
        o.*
    FROM clean_orders o CROSS JOIN params p
    WHERE o.order_dt < DATE_ADD('month', 1, p.last_complete_month)
), first_purchase AS (
    SELECT
        customer_id
        , DATE_TRUNC('month', MIN(order_dt)) AS cohort_month
    FROM observed_orders GROUP BY customer_id
), cohort_sizes AS (
    SELECT
        cohort_month
        , COUNT(*) AS cohort_size
    FROM first_purchase
    WHERE cohort_month >= DATE '2025-01-01'
    GROUP BY cohort_month
), customer_months AS (
    SELECT DISTINCT
        customer_id
        , DATE_TRUNC('month', order_dt) AS active_month
    FROM observed_orders
), activity AS (
    SELECT
        f.cohort_month
        , m.active_month
        , COUNT(*) AS active_customers
    FROM first_purchase f JOIN customer_months m ON f.customer_id = m.customer_id
    GROUP BY 1, 2
), grid AS (
    SELECT
        s.cohort_month
        , s.cohort_size
        , t.active_month
    FROM cohort_sizes s CROSS JOIN params p
    CROSS JOIN UNNEST(SEQUENCE(s.cohort_month, p.last_complete_month, INTERVAL '1' MONTH)) AS t(active_month)
)
SELECT
    g.cohort_month
    , DATE_DIFF('month', g.cohort_month, g.active_month) AS month_number
    , g.cohort_size
    , COALESCE(a.active_customers, 0) AS active_customers
    , ROUND(100.0 * COALESCE(a.active_customers, 0) / NULLIF(g.cohort_size, 0), 2) AS retention_pct
FROM grid g LEFT JOIN activity a
  ON g.cohort_month = a.cohort_month AND g.active_month = a.active_month
ORDER BY 1, 2;

先找首購月、計算固定的 Cohort 人數，再把訂單去重成每位顧客每月一列。grid 會產生已經觀察完的月份組合，所以當月沒有人回購時可以填 0；尚未走到的月份則沒有資料列，做成樞紐表時應留白。這份 Query 輸出的是長表，可以再用報表工具把 month_number 展開成欄位。

例如 1 月 Cohort 有 100 人，2 月 20 人購買，Month 1 就是 20%。6 月 Cohort 目前只有 Month 0，不應把 Month 1 填成 0%。因為我們定義的是各月購買留存，顧客可以隔月再回來，留存率也不一定逐月下降；它同樣不是「首購後 30 天內回購率」。

寫完 Query，再問自己結果能不能回答問題

回購率要看觀察期，連續購買要先定義月份，顧客分群要考慮用途，新舊客營收要分清楚顧客身分與訂單次序，Cohort 則要區分沒有回來和還沒觀察到。這些問題確認清楚，SQL 才有明確的計算方向。

面試時，你可以試著這樣回答：「我會先確認回購的定義和資料截止日，再找出完整歷史中的首購，讓分母只包含已滿觀察期的顧客。最後檢查同日第二張訂單與第 30 天的邊界，確保結果符合剛才約定的規則。」

看完答案後，別忘了自己動手改一個條件。例如同日不算回購、排名要保留同分，或首購當月只計第一張訂單。能說清楚哪些步驟需要改，才是真的理解這段 Query。

系列閱讀：從基礎題到進階應用

SQL 面試題入門：數據分析師必會的 10 道基礎題 (上)

SQL 面試題入門：數據分析師必會的 10 道基礎題 (下)

SQL 面試題進階：CTE、Window Function 與 10 道常見練習題（上）

SQL 面試題進階：CTE、Window Function 與 10 道常見練習題（下）(本篇)

想繼續練習更多電商 SQL 面試題嗎？

如果你已經完成上面的題目，接下來可以試著挑戰更多貼近實際工作情境的 SQL 題目。

我整理了一份《電商產業 SQL 面試實戰題庫》，收錄 24 道電商商業案例，涵蓋付款失敗率、取消與退款、實際營收、新舊客、回購率、商品表現、MoM、QoQ、優惠券成效與購物轉換漏斗。

每一道題目都會提供資料表與欄位，讓你先練習釐清商業問題、拆解查詢步驟，再對照 Athena SQL 與 MySQL 8.0 的參考答案，這裏購買：https://buymeacoffee.com/aderlabsharon/e/572913

最後也提供讀者專屬折扣碼：BLOG，結帳時輸入折扣碼即可享有8折優惠～

SQL 語法參考

日期與視窗函數可參考 Athena engine version 3 官方文件、Window functions 與 日期函數說明。不同資料庫的日期語法可能不同，練習時請先確認使用的環境。

---

Buy me a coffee　用行動支持我的內容創作

如果文章對你有幫助，歡迎用小額贊助支持 Sharon 持續分享數據分析實務。

如果你看過 SQL 面試題入門：數據分析師必會的 10 道基礎題 (上) 或 SQL 面試題入門：數據分析師必會的 10 道基礎題（下），應該已經發現，看到題目先別急著寫 Query。先確認商業問題、資料格式與指標定義，往往比多背幾個函數更重要。

到了進階題，這個習慣一樣適用。只是我們開始需要把問題拆成幾個步驟，處理累積消費、排名、回購與留存，這個系列保留 10 道練習題，分成上下兩篇，這篇先練習五題，包括月營收成長率、累積消費、購買間隔、每月前三位顧客，以及首購與回購訂單。

練習使用的資料表與共同假設

SQL 延續入門篇，使用 Amazon Athena engine version 3 語法。orders 包含 order_id、customer_id、order_date、order_status、total_amount；order_date 是 YYYYMMDD 整數，例如 20250831，需要先轉成 DATE。

以下假設一列就是一張訂單，order_id 唯一，customer_id 與日期沒有缺漏，日期也都是有效值；completed 代表納入分析的完成訂單。total_amount 是已確認可加總、非 NULL 的最終金額，折扣、退款與運費處理一致，且已統一幣別。這些是假設，實務上要先和面試官確認，不能只靠欄位名稱猜測。

每題都附上 clean_orders，讓你可以各自複製整段 SQL 練習。它只處理訂單狀態與日期轉換，並不會自動解決重複資料、退款或異常日期。若原始資料是商品明細，請先整理成每張訂單一列；如果歷史不完整，首購相關結果只能稱為「可觀察資料中的首購」。

先認識 CTE 與 Window Function 在幫你做什麼

當 Query 越寫越長，你是不是也會開始忘記內層到底算了什麼？CTE 就是用 WITH 幫一段查詢結果取名字，讓後面的步驟接著使用。例如先整理訂單，再計算月營收，最後比較上月，閱讀起來就能對上自己的解題順序。CTE 的用途是整理邏輯，不代表一定會建立實體暫存表，也不保證查詢會更快。

Window Function 則適合「保留目前這一列，同時參考其他列」。例如保留訂單明細，但在旁邊加上顧客累積消費。OVER 裡的 PARTITION BY 決定分組範圍，ORDER BY 決定視窗計算順序，ROWS 可進一步指定累計範圍，最後輸出的排序，仍然要靠最外層 ORDER BY。

第 1 題：如何計算每月營收的 MoM 成長率？

看到月成長率，你是不是會想到先算每月營收，再拿這個月減掉上個月，除以上個月？方向沒有錯，但 SQL 裡的「上一列」，真的就是我們想比較的「上個月」嗎？

下手之前，你可以先問：

1. 要比較完整月份，還是本月截至今天？

2. 兩個月的觀察天數是否一致？如果不一樣，是否要改成比較 daily營收

假設資料已完整入庫，沒有訂單就代表零營收。我們比較 2025 年 1～6 月的完整月份，額外讀入 2024 年 12 月作為 1 月的比較基準。

WITH clean_orders AS (
    SELECT
        order_id
        , customer_id
        , CAST(DATE_PARSE(CAST(order_date AS VARCHAR), '%Y%m%d') AS DATE) AS order_dt
        , total_amount
    FROM orders
    WHERE order_status = 'completed'
),

months AS (
    SELECT
        order_month
    FROM UNNEST(SEQUENCE(DATE '2024-12-01', DATE '2025-06-01', INTERVAL '1' MONTH)) AS t(order_month)
), 

monthly_revenue AS (
    SELECT
        DATE_TRUNC('month', order_dt) AS order_month
        , SUM(total_amount) AS revenue
    FROM clean_orders
    WHERE order_dt >= DATE '2024-12-01' AND order_dt < DATE '2025-07-01'
    GROUP BY 1
), 

filled AS (
    SELECT
        m.order_month
        , COALESCE(r.revenue, 0) AS revenue
    FROM months m LEFT JOIN monthly_revenue r ON m.order_month = r.order_month
), 

compared AS (
    SELECT
        *
        , LAG(revenue) OVER (ORDER BY order_month) AS previous_revenue
    FROM filled
)

SELECT
    order_month
    , revenue
    , previous_revenue
    , ROUND(100.0 * (revenue - previous_revenue) / NULLIF(previous_revenue, 0), 2) AS mom_pct
FROM compared
WHERE order_month >= DATE '2025-01-01'
ORDER BY order_month;

先建立月份清單，再補上營收，LAG 才能對到上一個日曆月。最後才篩選展示期間，才能保留 1 月需要用到的 12 月資料。NULLIF 則讓上月營收為 0 時回傳 NULL，因為這時候一般百分比成長率沒有定義。

你可以用小例子檢查：1 月 100 元、2 月沒有訂單、3 月 150 元，3 月應該與 2 月的 0 元比較，結果是 NULL，不能跳過 2 月算成成長 50%。如果缺月是資料遺漏，也不能直接補 0。

第 2 題：如何計算每位顧客的累積消費？

如果公司想看顧客在哪一筆訂單達到 VIP 門檻，只用 GROUP BY 算出每個人的總消費，夠不夠呢？我們還需要保留每一張訂單，才能看到消費是怎麼累積上去的。

下手之前，你可以先問：

1. 要看歷史累積，還是今年重新起算？

2. 同一天有兩張訂單時，要逐筆累加，還是只看每天結束時的金額？

假設要看全部歷史的逐筆累積；目前只有日期，因此同日訂單用唯一的 order_id 固定排列。這能讓結果一致，但不代表同日的實際先後。

WITH clean_orders AS (
    SELECT
        order_id
        , customer_id
        , CAST(DATE_PARSE(CAST(order_date AS VARCHAR), '%Y%m%d') AS DATE) AS order_dt
        , total_amount
    FROM orders
    WHERE order_status = 'completed'
)

SELECT
    customer_id
    , order_dt
    , order_id
    , total_amount
    , SUM(total_amount) OVER (
        PARTITION BY customer_id ORDER BY order_dt, order_id
        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ) AS cumulative_spend
FROM clean_orders
ORDER BY customer_id, order_dt, order_id;

PARTITION BY 讓每位顧客各自計算，ORDER BY 決定累積順序，ROWS 則明確指定從第一列加到目前這一列。發現了嗎？Window Function 可以計算合計，同時保留訂單明細，這就是它和 GROUP BY 很實用的差別。

假設同一位顧客依序消費 500、300、200 元，累積結果就是 500、800、1,000 元。如果要判斷真實的第幾次購買達標，就要取得交易 timestamp；若只關心每日累積，應先彙總到顧客與日期。

第 3 題：如何計算前後兩次購買的間隔？

行銷同事想知道顧客大約多久會再買一次，你可能會想到用 LAG 找上一筆訂單日期。不過，兩張訂單和兩次購物行為，一定是同一件事嗎？

下手之前，你可以先問：

1. 同一天拆成兩張訂單，要算兩次購買嗎？

2. 間隔以日曆天、完整 24 小時，還是工作天計算？

3. 第一次購買沒有上一筆，應保留 NULL 還是排除？

假設一張完成訂單算一次購買，使用日曆天差；同日購買的間隔就是 0 天，第一次購買則保留 NULL。

WITH clean_orders AS (
    SELECT
        order_id
        , customer_id
        , CAST(DATE_PARSE(CAST(order_date AS VARCHAR), '%Y%m%d') AS DATE) AS order_dt
        , total_amount
    FROM orders
    WHERE order_status = 'completed'
),

previous_orders AS (
    SELECT
        customer_id
        , order_id
        , order_dt
        , LAG(order_dt) OVER (PARTITION BY customer_id ORDER BY order_dt, order_id) AS previous_order_dt
    FROM clean_orders
)
SELECT
    *
    , DATE_DIFF('day', previous_order_dt, order_dt) AS interval_days
FROM previous_orders
ORDER BY customer_id, order_dt, order_id;

我們先在每位顧客內找上一張訂單，再使用 DATE_DIFF 計算天數。YYYYMMDD 整數不能直接相減當天數，所以前面的日期轉換在這裡就派上用場了。

例如 1 月 31 日買一次，2 月 1 日再買一次，間隔是 1 天。第一次購買的 NULL 不應改成 0，否則會拉低平均間隔；而只有一次購買的人沒有可計算的間隔，也不能把這個平均值解讀成所有顧客的購買週期。

第 4 題：如何找出每月消費最高的顧客？三種排名情境

「前三名」看起來只是排名，但如果第三名有兩個人同分，你會留下誰？這時候選哪個排名函數，就不只是語法偏好了。下面把同一個商業問題拆成三個子題，練習 ROW_NUMBER、RANK 與 DENSE_RANK。

下手之前，先確認：公司一定只能發出 3 份獎品，還是同分顧客都要保留？排名依照單筆最大訂單，還是每月總消費？同分時有沒有指定第二個排序條件？這些答案會直接影響最後選出哪些顧客。

以下三題都使用 orders 資料表，只計算 order_status = ‘completed’ 的訂單，並先彙總成「每月每位顧客一列」。假設 order_date 是 YYYYMMDD 格式的整數或字串，例如 20250101；月消費總額以 total_amount 加總。實務上也要先確認退款、折扣與運費是否已反映在金額中，以及訂單是否有重複資料。

4-1：每月最多選 3 位顧客發送禮品（ROW_NUMBER）

題目：公司每月最多提供 3 份禮品，要送給當月總消費最高的顧客。請找出每月獲獎名單；消費金額相同時，優先選擇 customer_id 較小的顧客。每月最多選 3 位，不足 3 位時全部保留。輸出月份、顧客 ID、月消費總額與序號。

既然禮品數量有限，就需要讓每位顧客取得唯一的序號。ROW_NUMBER 搭配 revenue DESC、customer_id ASC，可以依消費金額排序，再用顧客 ID 決定同額顧客的先後。

WITH clean_orders AS (
    SELECT
        order_id
        , customer_id
        , CAST(DATE_PARSE(CAST(order_date AS VARCHAR), '%Y%m%d') AS DATE) AS order_dt
        , total_amount
    FROM orders
    WHERE order_status = 'completed'
), monthly_spend AS (
    SELECT
        DATE_TRUNC('month', order_dt) AS order_month
        , customer_id
        , SUM(total_amount) AS revenue
    FROM clean_orders
    GROUP BY 1, 2
), ranked AS (
    SELECT
        *
        , ROW_NUMBER() OVER (
            PARTITION BY order_month
            ORDER BY revenue DESC, customer_id ASC
        ) AS rn
    FROM monthly_spend
)
SELECT
    order_month
    , customer_id
    , revenue
    , rn
FROM ranked
WHERE rn <= 3
ORDER BY order_month, rn, customer_id;

ROW_NUMBER 不會產生並列序號。即使第三位與第四位消費金額相同，也只會留下序號 3 的顧客；這就是為什麼必須先約定同額時的選擇規則。

4-2：每月競賽排名前三名，同分者都獲獎（RANK）

題目：公司依每月總消費金額舉辦排行榜，競賽排名在前三名的顧客都能獲獎。同額顧客並列，且並列會占用後續名次，例如兩人並列第二名，下一位就是第四名。請輸出月份、顧客 ID、月消費總額與競賽排名，保留排名小於或等於 3 的所有顧客。

這次不限制獲獎人數，而是依競賽名次決定資格，因此使用 RANK。視窗內只依 revenue DESC 排序，才能讓同額顧客取得相同排名。

WITH clean_orders AS (
    SELECT
        order_id
        , customer_id
        , CAST(DATE_PARSE(CAST(order_date AS VARCHAR), '%Y%m%d') AS DATE) AS order_dt
        , total_amount
    FROM orders
    WHERE order_status = 'completed'
), monthly_spend AS (
    SELECT
        DATE_TRUNC('month', order_dt) AS order_month
        , customer_id
        , SUM(total_amount) AS revenue
    FROM clean_orders
    GROUP BY 1, 2
), ranked AS (
    SELECT
        *
        , RANK() OVER (
            PARTITION BY order_month
            ORDER BY revenue DESC
        ) AS spend_rank
    FROM monthly_spend
)
SELECT
    order_month
    , customer_id
    , revenue
    , spend_rank
FROM ranked
WHERE spend_rank <= 3
ORDER BY order_month, spend_rank, customer_id;

如果金額是 100、90、80、80，名次會是 1、2、3、3，四位顧客都獲獎。如果金額是 100、90、90、80，名次則是 1、2、2、4，金額 80 的顧客就不會入選。

4-3：找出每月前三個不同消費金額的所有顧客（DENSE_RANK）

題目：公司想研究高消費顧客，要找出每月最高的 3 個不同月消費總額，以及達到這些金額的所有顧客。同額顧客屬於同一級距，級距編號連續、不跳號；不足 3 個級距時全部保留。請輸出月份、顧客 ID、月消費總額與級距排名。

這裡的級距指不同的月消費總額，不是自行設定的金額區間。使用 DENSE_RANK，相同金額取得相同排名，下一個不同金額的排名接著往下編，不會因並列人數而跳號。

WITH clean_orders AS (
    SELECT
        order_id
        , customer_id
        , CAST(DATE_PARSE(CAST(order_date AS VARCHAR), '%Y%m%d') AS DATE) AS order_dt
        , total_amount
    FROM orders
    WHERE order_status = 'completed'
), monthly_spend AS (
    SELECT
        DATE_TRUNC('month', order_dt) AS order_month
        , customer_id
        , SUM(total_amount) AS revenue
    FROM clean_orders
    GROUP BY 1, 2
), ranked AS (
    SELECT
        *
        , DENSE_RANK() OVER (
            PARTITION BY order_month
            ORDER BY revenue DESC
        ) AS spend_rank
    FROM monthly_spend
)
SELECT
    order_month
    , customer_id
    , revenue
    , spend_rank
FROM ranked
WHERE spend_rank <= 3
ORDER BY order_month, spend_rank, customer_id;

如果金額是 100、90、90、80，級距排名會是 1、2、2、3。因此 DENSE_RANK 小於或等於 3 會保留四位顧客，代表選出前三種金額的所有顧客。

放在一起比較：前三位、競賽前三名、前三種金額

用同一月份的五位顧客來驗證。假設 customer_id 依序為 A、B、C、D、E，月消費總額分別是 100、90、90、80、70：

顧客	月消費總額	ROW_NUMBER	RANK	DENSE_RANK
A	100	1	1	1
B	90	2	2	2
C	90	3	2	2
D	80	4	4	3
E	70	5	5	4

篩選排名小於或等於 3 時，ROW_NUMBER 與 RANK 在這組資料都選出 A、B、C；DENSE_RANK 則選出 A、B、C、D。前兩者這次剛好選到相同的人，不代表規則相同；把金額換成 100、90、80、80、70，就會看到 ROW_NUMBER 選出 3 人，RANK 選出 4 人。

三題都先在 ranked CTE 算好排名，再到外層 WHERE 篩選。使用 RANK 或 DENSE_RANK 保留同分者時，不要把 customer_id 加進視窗內的 ORDER BY，否則同額顧客會被拆成不同名次。最外層的 ORDER BY 可以加入 customer_id，因為它只決定結果的顯示順序，不會改變已算好的排名。

第 5 題：如何區分首購與回購訂單？

看到首購，你可能會想：把每個人的訂單依時間排序，第一張就是首購。可是，如果手上的資料只剩最近一年，這張「第一張」真的就是顧客人生中的第一筆訂單嗎？

下手之前，你可以先問：

1. 首購指第一張完成訂單，還是第一次付款？退款後是否重新認定？

2. 資料是否涵蓋完整歷史？是否有舊系統或其他通路的訂單？

3. 同日多張訂單要只標一張首購，還是整個首購日都算？

假設有完整歷史，一張完成訂單就是一次購買；只標記一張首購，同日以 order_id 作為固定的判定規則。

WITH clean_orders AS (
    SELECT
        order_id
        , customer_id
        , CAST(DATE_PARSE(CAST(order_date AS VARCHAR), '%Y%m%d') AS DATE) AS order_dt
        , total_amount
    FROM orders
    WHERE order_status = 'completed'
),
ranked_orders AS (
    SELECT
        *
        , ROW_NUMBER() OVER (
            PARTITION BY customer_id ORDER BY order_dt, order_id
        ) AS order_sequence
    FROM clean_orders
)
SELECT
    order_id
    , customer_id
    , order_dt
    , CASE WHEN order_sequence = 1 THEN 'First Purchase'
    ELSE 'Repeat Purchase' END AS purchase_type
FROM ranked_orders
ORDER BY customer_id, order_dt, order_id;

如果只想看 2025 年的首購與回購訂單，應該先在完整歷史上排名，再在最外層加上日期條件。如果先把舊訂單切掉，老顧客今年的第一張訂單，就會被誤判成首購。

假設顧客在 2024 年已經買過，2025 年又買一次，2025 年那張仍然是回購。只有日期時，我們採用的是明確約定的同日規則；如果業務要精確找出第一筆付款，還是需要付款時間。

練習時，試著把你的判斷說出來

這五題分別用了 LAG、SUM OVER 與排名函數，但真正會改變答案的，是缺月怎麼處理、累積從哪裡開始、同分要不要保留，以及首購歷史是否完整。你可以先遮住答案，練習把需要確認的問題說出來，再一步步寫 Query。

下一篇接著練習第 6～10 題，把這些方法放進 30 天回購率、連續購買、顧客分群、新舊客營收與 Cohort 留存分析。

系列閱讀：從基礎題到進階應用

SQL 面試題入門：數據分析師必會的 10 道基礎題 (上)

SQL 面試題入門：數據分析師必會的 10 道基礎題 (下)

SQL 面試題進階：CTE、Window Function 與 10 道常見練習題（上）(本篇)

SQL 面試題進階：CTE、Window Function 與 10 道常見練習題（下）

SQL 語法參考

日期與視窗函數可參考 Athena engine version 3 官方文件、Window functions 與 日期函數說明。不同資料庫的日期語法可能不同，練習時請先確認使用的環境。

想繼續練習更多電商 SQL 面試題嗎？

如果你已經完成上面的題目，接下來可以試著挑戰更多貼近實際工作情境的 SQL 題目。

我整理了一份《電商產業 SQL 面試實戰題庫》，收錄 24 道電商商業案例，涵蓋付款失敗率、取消與退款、實際營收、新舊客、回購率、商品表現、MoM、QoQ、優惠券成效與購物轉換漏斗。

每一道題目都會提供資料表與欄位，讓你先練習釐清商業問題、拆解查詢步驟，再對照 Athena SQL 與 MySQL 8.0 的參考答案，這裏購買：https://buymeacoffee.com/aderlabsharon/e/572913

最後也提供讀者專屬折扣碼：BLOG，結帳時輸入折扣碼即可享有8折優惠～

---

Buy me a coffee　用行動支持我的內容創作

如果文章對你有幫助，歡迎用小額贊助支持 Sharon 持續分享數據分析實務。

上一篇文章，我們從五道 SQL 基礎題開始，練習如何計算每月營收、找出高消費顧客、分析各國購買人數、找出從未下單的會員，以及計算不同訂單狀態的占比。

如果你有看完上篇，應該已經發現，SQL 面試並不是看到題目就馬上開始寫 Query。真正重要的，是先確認商業問題、資料格式與指標定義，再決定查詢條件應該怎麼下。

這篇文章接著分享第 6～10 題，會練習日期處理、平均值、HAVING、跨表 JOIN 與 CASE WHEN。SQL 範例延續上篇，以 Amazon Athena 語法為主。

練習使用的資料表

我們同樣使用兩張簡化的電商資料表：

customers 是客戶資料表，包含 customer_id、signup_date、country、acquisition_channel。

orders 是訂單紀錄表，包含 order_id、customer_id、order_date、order_status、total_amount。其中 order_date 以 YYYYMMDD 的整數格式儲存，例如 20250831。

第 6 題：如何找出每位顧客的第一次購買日期？

看到「第一次購買日期」，你是不是會很直覺地想到：依照 customer_id 分組，再使用 MIN(order_date) 找出最早的日期？

SELECT
    customer_id,
    MIN(order_date) AS first_order_date
FROM orders
GROUP BY customer_id;

這個方向沒有錯，但先別急著把它當成最後答案。題目說的是「第一次購買」，而不是「第一次建立訂單」，兩者不一定是同一件事。

下手之前，你可以先問：

1. 第一次購買是第一次建立訂單、第一次付款成功，還是第一次完成訂單？取消或付款失敗的訂單要算嗎？

2. order_date 的資料格式是什麼？如果它是 YYYYMMDD 的整數，能不能直接使用日期函數？

3. 如果顧客完成訂單後又全額退款，這筆訂單還算他的第一次購買嗎？

4. 同一位顧客是否可能有多個 customer_id？如果有，第一次購買日期要以帳號還是真實顧客為單位？

假設面試官告訴你，第一次購買是指第一筆已完成的訂單，而且 order_date 是 YYYYMMDD 的整數格式，那麼在 Athena 中要先將整數轉成日期，再找出最小值：

SELECT
    customer_id,
    MIN(
        CAST(
            DATE_PARSE(CAST(order_date AS VARCHAR), '%Y%m%d')
            AS DATE
        )
    ) AS first_purchase_date
FROM orders
WHERE order_status = 'completed'
GROUP BY customer_id;

這題看似只是在考 MIN，其實也在測試你是否能分辨「下單」與「購買」的差異，以及能不能正確處理日期格式。

第 7 題：如何計算每位顧客的平均訂單金額？

平均訂單金額看起來很簡單，把 total_amount 放進 AVG() 不就好了嗎？

SELECT
    customer_id,
    AVG(total_amount) AS average_order_value
FROM orders
GROUP BY customer_id;

但平均值是 SQL 面試裡很容易出現陷阱的地方，因為你一定要先確認每一列資料代表什麼。

你可以先問：

1. orders 的一列就是一張訂單嗎？還是一張訂單中的一項商品？如果一張訂單有三項商品，會不會出現三列？

2. 平均訂單金額只計算 completed 訂單嗎？取消、付款失敗與退款訂單要不要排除？

3. total_amount 是整張訂單的最終金額，還是單項商品金額？是否已經扣除折扣與退款？

4. 題目想看的是每位顧客自己的平均訂單金額，還是全公司的平均客單價？分析粒度不同，答案也會不同。

假設一列就是一張訂單，total_amount 是最終訂單金額，而且只計算已完成的訂單，那麼可以寫成：

SELECT
    customer_id,
    COUNT(DISTINCT order_id) AS order_count,
    SUM(total_amount) AS total_spend,
    AVG(total_amount) AS average_order_value
FROM orders
WHERE order_status = 'completed'
GROUP BY customer_id;

除了平均訂單金額，我也會一起列出訂單數與累積消費金額。為什麼呢？因為平均消費 3,000 元的顧客，可能只買過一次，也可能已經買過十次。只看平均值，很容易忽略背後完全不同的顧客行為。

第 8 題：如何找出購買超過 3 次的顧客？

這一題常被拿來測試 WHERE 和 HAVING 的差別。很多人看到「超過 3 次」，第一個反應可能是把條件寫在 WHERE：

SELECT
    customer_id,
    COUNT(DISTINCT order_id) AS order_count
FROM orders
WHERE COUNT(DISTINCT order_id) > 3
GROUP BY customer_id;

但這段 SQL 無法正確執行，因為 WHERE 是在分組與彙總之前篩選原始資料，COUNT() 則是分組後才會得到的結果。如果要篩選彙總後的訂單數，就需要使用 HAVING。

不過，語法問題解決後，商業定義還是要確認：

1. 購買超過 3 次，是指至少 3 次，還是大於 3 次，也就是 4 次以上？

2. 一次購買要用資料列數量、order_id 數量，還是 completed 訂單數來判斷？

3. 是否有指定觀察期間？是歷史累積購買次數，還是最近一年、最近 90 天的購買次數？

4. 退貨或全額退款的訂單，還算一次購買嗎？

假設題目的意思是歷史上完成 4 張以上訂單的顧客，那麼 Query 可以寫成：

SELECT
    customer_id,
    COUNT(DISTINCT order_id) AS order_count
FROM orders
WHERE order_status = 'completed'
GROUP BY customer_id
HAVING COUNT(DISTINCT order_id) > 3
ORDER BY order_count DESC;

發現了嗎？WHERE 和 HAVING 都是在篩選資料，但它們發生的時間點不同。WHERE 先篩選哪些訂單可以進入計算，HAVING 再篩選哪些顧客的彙總結果符合條件。

第 9 題：如何比較不同顧客來源渠道的營收？

這題開始更接近真實的商業分析。公司想知道哪個 acquisition_channel 帶來最多營收，你可能會把 customers 和 orders 連接起來，再依照渠道加總 total_amount。

SELECT
    c.acquisition_channel,
    SUM(o.total_amount) AS revenue
FROM customers c
JOIN orders o
    ON c.customer_id = o.customer_id
GROUP BY c.acquisition_channel
ORDER BY revenue DESC;

這段 SQL 可以算出結果，但看到結果後，真的就能判斷哪個渠道表現最好嗎？先想一下，還有哪些問題需要釐清：

1. acquisition_channel 代表顧客第一次接觸、第一次註冊，還是最後一次轉換的渠道？歸因規則是什麼？

2. 營收是否只計算已完成的訂單？退款、折扣與不同幣別應該如何處理？

3. customers 中的 customer_id 是否唯一？如果同一位顧客在 customers 表中出現多列，JOIN 後會不會讓營收被重複計算？

4. 題目想比較的是營收，還是渠道效益？如果要評估效益，是否還需要廣告費、顧客取得成本與毛利資料？

假設 acquisition_channel 是顧客註冊時的來源渠道、customer_id 在 customers 中不重複，而且只計算已完成訂單，那麼可以寫成：

SELECT
    c.acquisition_channel,
    COUNT(DISTINCT c.customer_id) AS purchasing_customers,
    COUNT(DISTINCT o.order_id) AS order_count,
    SUM(o.total_amount) AS revenue
FROM customers c
JOIN orders o
    ON c.customer_id = o.customer_id
WHERE o.order_status = 'completed'
GROUP BY c.acquisition_channel
ORDER BY revenue DESC;

我會同時保留購買顧客數、訂單數與營收，因為只看營收很難解釋渠道差異。某個渠道的營收較高，可能只是帶來的顧客比較多，不代表每位顧客的價值更高。

而且別忘了，營收最高也不等於投資報酬率最高。如果真的要決定行銷預算怎麼分配，還需要搭配渠道成本、CAC、毛利與 LTV，才能做出完整判斷。

第 10 題：如何將訂單分成高、中、低金額？

最後一題要使用 CASE WHEN 進行分類。假設高金額訂單是 3,000 元以上、中金額訂單是 1,000～2,999 元，其餘則是低金額訂單，你可能會寫成：

SELECT
    order_id,
    total_amount,
    CASE
        WHEN total_amount >= 3000 THEN 'High'
        WHEN total_amount >= 1000 THEN 'Medium'
        ELSE 'Low'
    END AS order_value_segment
FROM orders;

語法看起來很直覺，但面試官很可能會繼續問你：「為什麼是 1,000 元和 3,000 元？」

所以，開始分類前，你可以先確認：

1. 高、中、低金額的門檻是公司已經定義好的，還是需要你根據資料分布自行決定？

2. total_amount 是否為最終付款金額？取消、退款與折扣後的訂單該如何分類？

3. 如果 total_amount 是 NULL、負數或異常高值，要放在哪一類？還是應該先排除並檢查？

4. 不同國家或產品的訂單金額差異很大時，是否應該使用相同門檻？

假設門檻已由公司定義，並且只分類已完成、金額不為 NULL 的訂單，那麼 Query 可以寫成：

SELECT
    order_id,
    total_amount,
    CASE
        WHEN total_amount >= 3000 THEN 'High'
        WHEN total_amount >= 1000 THEN 'Medium'
        ELSE 'Low'
    END AS order_value_segment
FROM orders
WHERE order_status = 'completed'
  AND total_amount IS NOT NULL;

CASE WHEN 會從上到下判斷條件，因此條件順序也很重要。如果先寫 total_amount >= 1000，那麼 3,000 元以上的訂單也會先被歸類為 Medium，後面的 High 條件就永遠不會執行。

實務上，如果公司沒有提供門檻，我不會直接憑感覺設定數字，而是先查看訂單金額分布，或依照百分位數、毛利與顧客經營策略來決定分類方式。

總結：真正加分的是你如何拆解問題

完成這五道題目後，你會發現，SQL 語法只是解題過程中的一部分。

第 6 題看起來在考 MIN，實際上要先定義第一次購買；第 7 題使用 AVG，卻必須先確認資料粒度；第 8 題考 WHERE 和 HAVING，也要先釐清購買次數；第 9 題使用 JOIN 分析渠道營收，但不能把營收直接當成渠道效益；第 10 題使用 CASE WHEN 分群，門檻也不能毫無依據地設定。

發現了嗎？同一段 SQL，在不同的資料結構與商業定義下，可能會得到完全不同的答案。

所以下次面試時，先別急著證明自己寫 Query 的速度。先說明你想確認哪些事情、你目前採用什麼假設，以及這些假設會如何影響結果。這些看似繞了一點的步驟，反而更能讓面試官看見你真正的分析能力。

數據分析師的價值，不只是把資料查出來，而是確保查出來的資料，真的能回答原本的商業問題。

看完答案後，別忘了真的動手寫一次

看到這裡，連同上篇：SQL 面試題入門：數據分析師必會的 10 道基礎題 (上)，你已經完成 10 道 SQL 基礎面試題了。

不過，看懂答案和面試時能夠自己拆解問題，還是兩件不太一樣的事情。真正遇到 SQL 面試題時，面試官通常不只想知道你的 Query 能不能執行，也會觀察你是否知道要先確認資料格式、指標定義與商業情境。

如果你想繼續練習，我整理了一份《電商產業 SQL 面試實戰題庫》，收錄 24 道不與本篇重複的電商案例題。

題目會從基礎到進階，帶你練習付款、退款、營收、新舊客、商品表現、成長率、優惠券與購物漏斗等常見分析情境，並提供 Athena SQL 與 MySQL 8.0 參考答案，這裏購買下載：https://buymeacoffee.com/aderlabsharon/e/572913。

讀者專屬折扣碼：BLOG，結帳時輸入折扣碼即可享有8折優惠～

---

Buy me a coffee 用行動支持我的內容創作

如果文章對你有幫助，歡迎用小額贊助支持 Sharon 持續分享數據分析實務。

準備數據分析師面試時，SQL 幾乎是無法避開的一關，即使公司使用 Tableau、Power BI 或 Python進行視覺化呈現，分析師仍需要透過 SQL 從資料庫提取視覺化前需要的底層資料。

SQL 面試的重點不只是在測試語法，面試官更想透過面試，知道你是否能理解資料內容、將商業問題轉換成查詢條件、避免重複計算，並正確處理商業問題，這篇文章就來與你分享 10 道數據分析師的 SQL 基礎面試題。

練習使用的資料表

一開始，我們先假設兩張簡化的電商資料表：

一張資料表叫做customers 包含客戶資料，包括 customer_id、signup_date、country、acquisition_channel

另外一張表則為訂單紀錄表orders， 包含所有訂單紀錄，資料欄位有： order_id、customer_id、order_date、order_status、total_amount。

第 1 題：如何每個月的訂單數與營收？

這時候你是不是會想要急著開始寫你的SQL呢？

SELECT
    DATE_TRUNC('month', order_date) AS order_month,
    COUNT(DISTINCT order_id) AS order_count,
    SUM(total_amount) AS revenue
FROM orders
GROUP BY 1
ORDER BY 1;

在還沒確認商業問題之前，貿然寫出你的Query答案，可能會讓你有點扣分，解題之前，其實最重要的就是確認商業問題以及資料格式，所以先別急著寫下你的query，如果資訊只有上面提供的資料表以及資料欄位，其實並不足以讓你判斷你的Query語法應該怎麼下。

下手之前，你可以問問，例如：

1. order_date的資料格式是什麼？是日期格式嗎？還是string(字串), int(整數) 或者是timestamp格式呢？基於資料表的大小以及儲存限制，不同公司不同資料表可能會針對日期做不同的儲存格式，所以確認資料欄位的格式，絕對是第一步。

2. 每月的訂單數與營收是指完成的訂單數嗎？資料表目前的資料只包含完成的訂單嗎？如果是先完成的訂單，但後續有退貨或是換貨，該訂單的狀態會是退貨嗎？部分退貨部分取貨，那資料欄位又會怎麼顯示呢？

3. revenue是否代表實際客戶付款的金額呢？還是折扣前金額呢？如果是折扣前金額，是否需要扣除折扣金額或是運費呢？

發現了嗎？光是詢問這些問題，就可能讓你的query的處理方式完全不一樣，所以，開始回答前，請先想一下實際的商業案例可能會有哪些情況，並試想可能的情況，才會讓你的能力不僅僅停留在sql的寫手，而是專業的商業問題解析員

問完這些問題，你可能會得到：

日期的格式為整數，需要計算已完成的訂單，已完成的訂單可以以order_status = ‘completed’來判斷，先不考慮退貨，revenue是指最終營收，所以其他折扣與運費不避考慮。

SELECT
    DATE_TRUNC('month', DATE_PARSE(CAST(order_date AS VARCHAR), '%Y%m%d')) AS order_month,
    COUNT(DISTINCT order_id) AS order_count,
    SUM(total_amount) AS revenue
FROM orders
WHERE order_status = 'completed'
GROUP BY 1
ORDER BY 1;

結果是不是就跟一開始還沒釐清商業問題完全不一樣了呢？

第 2 題：如何找出消費金額最高的 10 位顧客？

看到「消費金額最高」這幾個字，你是不是已經準備把每位顧客的 total_amount 加總，再由高到低排序了呢？

SELECT
    customer_id,
    SUM(total_amount) AS total_spend
FROM orders
GROUP BY customer_id
ORDER BY total_spend DESC
LIMIT 10;

先別急著交出這個答案。這段 SQL 在語法上可能沒有問題，但「消費金額」在商業情境中，還有很多需要確認的細節。

下手之前，你可以先問：

1. 消費金額是所有訂單的金額，還是只計算已完成的訂單？取消、付款失敗與退款訂單需要排除嗎？

2. total_amount 代表折扣前金額，還是顧客實際支付的金額？裡面是否包含運費、退款金額？

3. 資料中是否有不同幣別？如果有人使用美元消費、有人使用台幣消費，可以直接把金額放在一起比較嗎？

發現了嗎？只是要找出消費金額最高的顧客，就會牽涉訂單狀態、金額定義、幣別。技術上能夠加總，不代表這些數字在商業上真的可以直接相比。

假設面試官進一步告訴你：資料只有單一幣別、total_amount 已經是最終付款金額，而且只需要計算 order_status = ‘completed’ 的訂單，那麼 Query 就可以寫成：

SELECT
    customer_id,
    SUM(total_amount) AS total_spend
FROM orders
WHERE order_status = 'completed'
GROUP BY customer_id
ORDER BY total_spend DESC
LIMIT 10;

這題真正想測試的，不只是你會不會使用 SUM、GROUP BY、ORDER BY 和 LIMIT，而是你是否知道「消費金額最高」背後還藏著哪些商業定義。

第 3 題：如何計算每個國家的購買顧客數？

這一題需要使用 customers 與 orders 兩張資料表。看到 customer_id 同時出現在兩張表裡，你可能會很快想到用 JOIN 把它們連起來。

SELECT
    c.country,
    COUNT(DISTINCT c.customer_id) AS customer_count
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
GROUP BY c.country
ORDER BY customer_count DESC;

不過，在正式回答之前，還是要先確認題目裡的「國家」和「購買顧客」分別代表什麼。

你可以先問：

1. country 是會員註冊時填寫的國家、目前居住國家，還是訂單的配送國家？如果顧客購買送給住在不同居住地的收件者，應該歸在哪個國家？

2. 「購買顧客」是曾經建立訂單就算？還是至少要有一筆已完成訂單？如果是要有一筆完成訂單，是多久內完成訂單的客戶才要算？

3. 一位顧客可能有很多筆訂單，JOIN 之後會出現很多列。這時候應該計算訂單筆數，還是不重複的顧客人數？

第 3 個問題非常重要。如果直接使用 COUNT(*)，一位下過 10 次訂單的顧客就會被計算 10 次，但題目問的是顧客數，因此需要使用 COUNT(DISTINCT customer_id) 避免重複計算。

假設 country 代表顧客註冊的國家，而購買顧客的定義是2025(2025-01-01~2025-12-31)至少完成過一筆訂單，那麼 SQL 可以寫成：

SELECT
    c.country,
    COUNT(DISTINCT c.customer_id) AS customer_count
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id and 
WHERE o.order_status = 'completed' and DATE(DATE_PARSE(CAST(order_date AS VARCHAR), '%Y%m%d')) between DATE('2025-01-01') AND DATE('2025-12-31') 
GROUP BY c.country
ORDER BY customer_count DESC;

如果題目改成「每個國家的註冊顧客數」，那就不一定需要 JOIN orders。光是「註冊顧客」與「購買顧客」兩個字的差別，就會直接改變你需要使用的資料表與篩選條件囉～

第 4 題：如何找出從未下單的會員？

這是一道很常見的 JOIN 題目。你可能知道要使用 LEFT JOIN，但真正容易出錯的地方，反而是「從未下單」到底是什麼意思。

開始寫 Query 前，可以先確認：

1. 從未下單是指完全沒有建立過任何訂單，還是沒有完成過訂單？

2. 如果會員曾經下單，但後來取消、付款失敗或全額退款，他還算是下過單嗎？

3. orders 資料表是否包含測試訂單？測試帳號與內部員工帳號是否需要排除？

假設面試官說，這裡的「從未下單」就是在 orders 資料表中完全找不到任何訂單紀錄，那麼可以使用 LEFT JOIN：

SELECT
    c.customer_id,
    c.signup_date,
    c.country
FROM customers c
LEFT JOIN orders o
    ON c.customer_id = o.customer_id
WHERE o.order_id IS NULL;

為什麼不能使用 INNER JOIN 呢？因為 INNER JOIN 只會保留兩張表都有出現的 customer_id，沒有訂單的會員反而會直接被排除。LEFT JOIN 則會先保留 customers 中的所有會員，再讓找不到訂單的資料呈現 NULL，因此可以用 o.order_id IS NULL 把他們找出來。

但如果題目真正想找的是「從未完成訂單的會員」，就不能只是把 order_status = ‘completed’ 寫在最後的 WHERE 條件中，否則很容易改變 LEFT JOIN 的結果。這時候，可以把完成訂單的條件放進 JOIN：

SELECT
    c.customer_id,
    c.signup_date,
    c.country
FROM customers c
LEFT JOIN orders o ON c.customer_id = o.customer_id AND o.order_status = 'completed'
WHERE o.order_id IS NULL;

發現了嗎？「沒有下單」和「沒有完成訂單」看起來很接近，實際上卻是兩個不同的客群。面試時先說清楚你的定義，會比直接背出 LEFT JOIN 更加分。

第 5 題：如何計算不同訂單狀態的占比？

如果題目要你計算 completed、cancelled、refunded 等不同訂單狀態的占比，你可能會先想到依照 order_status 分組，再計算每一組的訂單數。

SELECT
    order_status,
    COUNT(*) AS order_count
FROM orders
GROUP BY order_status;

但是只有各狀態的訂單數，還不能算出占比。正式往下寫之前，你可以先確認：

1. 一筆資料列就代表一張訂單嗎？還是同一張訂單會因為包含多個商品而出現多列？如果是一張訂單多列，就不能直接使用 COUNT(*)。

2. 訂單狀態是目前的最終狀態，還是每次狀態變更都會留下紀錄？如果是狀態歷程表，同一張訂單可能會被重複計算。

3. 占比的分母是所有訂單，還是只計算某段期間、特定市場或特定渠道的訂單？

4. order_status 如果是 NULL 或出現未知狀態，要獨立列出、歸類為 other，還是排除？

假設 orders 中的一列就是一張訂單、order_status 是訂單目前的最終狀態，而且分母包含資料表中的所有訂單，那麼可以搭配 Window Function 計算占比：

WITH status_count AS (
    SELECT
        order_status,
        COUNT(*) AS order_count
    FROM orders
    GROUP BY order_status
),

total_count AS (
    SELECT
        COUNT(*) AS total_order_count
    FROM orders
)

SELECT
    s.order_status,
    s.order_count,
    ROUND(
        100.0 * s.order_count / t.total_order_count,
        2
    ) AS order_percentage
FROM status_count s
CROSS JOIN total_count t
ORDER BY s.order_count DESC;

在這段 Query 中，我們先透過 status_count 計算每個 order_status 分別有多少筆訂單，再透過 total_count 計算全部訂單的總數。

最後，將每種狀態的訂單數除以全部訂單數，再乘以 100，就可以得到各訂單狀態所占的百分比。

Query 寫完後也別急著結束。你還可以檢查各狀態的百分比加總是否接近 100%，並觀察 cancelled 或 refunded 的比例是否異常。這樣回答，就不只是算出結果，也展現了你會檢查資料品質與商業合理性。

總結：SQL 面試不是只看你會不會寫語法

看完前面五道題目，你可能會發現，這些 SQL 語法其實都不算太複雜，使用的主要是 GROUP BY、JOIN、SUM、COUNT、ORDER BY。

真正困難的地方，反而是在開始寫 Query 之前，你能不能先把問題問清楚。

日期欄位是 date、timestamp、string，還是整數？營收要不要扣除退款與折扣？購買顧客是曾經建立訂單，還是至少完成過一筆訂單？從未下單，是完全沒有訂單紀錄，還是沒有成功完成的訂單？計算訂單狀態占比時，一列資料又是否真的代表一張訂單？

這些問題看起來都不是 SQL 語法，卻會直接決定你的 SQL 應該怎麼寫。如果商業定義理解錯誤，就算 Query 能夠成功執行，最後得到的答案也不一定是公司真正想知道的結果，所以啊，下次遇到 SQL 面試題時，先別急著埋頭寫答案。你可以按照下面的順序思考：

1. 確認題目真正想解決的商業問題。
2. 確認資料表、欄位格式與每一列資料代表的意義。
3. 說明你對指標與篩選條件的假設。
4. 拆解查詢步驟，再開始撰寫 SQL。
5. 寫完後檢查重複資料、NULL、取消、退款與其他例外情況。
6. 最後確認查詢結果在商業上是否合理。

發現了嗎？面試官想找的通常不是一位只會背語法的 SQL 寫手，而是一位能理解資料、釐清問題，並且把商業需求轉換成正確查詢邏輯的數據分析師。

這篇先和你分享前五道 SQL 基礎面試題。下一篇，我會繼續整理第 6～10 題，帶你練習日期處理、HAVING、CASE WHEN，以及更多數據分析師面試中常見的應用情境。