🐬Spotfire 匯出報表資料跟 SQL 查詢不一致？工程師教你一步一步找出真正原因（含日期、PIVOT、快取陷阱）

一、這篇文章在解決什麼問題？

很多公司使用 BI 系統（例如 Spotfire、Power BI、Tableau） 自動產生報表，
但工程師最常遇到一個可怕的狀況：

「系統匯出的報表數據，跟我在資料庫查詢的不一樣。」

這不是小問題。
在半導體、金融、製造業，這種情況可能直接影響決策、產線、甚至客戶信任。

這篇文章會帶你理解：

你看到的「資料不同」，通常不是資料壞掉，而是 查詢邏輯不同。

而且 —
非常常見。

---

二、真實案例（簡化後）

一位工程師建立了一個自動報表：

系統每天會：

1. 從資料庫抓測試數據

2. 分析

3. 匯出 CSV

4. 產生 PDF

他發現一件事：

系統顯示只有 3 個產品型號，但他在資料庫查詢卻看到很多列資料。

他以為：

• SQL 寫錯

• 報表錯

• 系統壞掉

其實都不是。

---

三、關鍵概念：「清單」跟「明細」是兩種資料

先看一個例子：

資料庫裡的資料（明細）可能長這樣：

產品	批號
A	001
A	002
A	003
B	004
B	005
C	006

但報表系統可能只會先抓：

有哪些產品？

那結果會是：

A
B
C

這叫做：

DISTINCT（去重複清單）

而資料庫原始資料叫：

明細資料（Detail Rows）

所以當你看到：

• 報表：3 個

• SQL：6 列

不是錯，是你在比兩種不同的東西。

---

四、第二個陷阱：日期範圍（90% 的報表錯誤來源）

很多工程師都會寫類似查詢：

（示意範例）

查詢時間 < 2026-01-26

問題是：

電腦會把它理解成：

2026-01-26 00:00:00 之前

也就是：

整個 1 月 26 日的白天資料全部被排除。

如果某產品只在 1/26 上午出現：

• 報表可能有

• SQL 可能沒有

於是你以為資料不一致。

實際上是「時間邏輯不同」。

正確寫法（概念）

不要寫「小於某一天」
而要寫：

小於「隔天」

例如：

查詢 1/19～1/26 應該是：

>= 1/19
< 1/27

這叫做：

左閉右開區間（Left-closed Right-open）

這是資料工程界標準作法。

---

五、第三個陷阱：PIVOT 造成的 NULL

報表常會把資料轉成這樣：

產品	測站1	測站2	測站3
A	98%	NULL	97%

很多人會問：

為什麼會有 NULL？資料壞了嗎？

其實不是。

NULL 的意思是：

那個測站根本沒有資料。

不是錯誤，是「沒有測」。

但人眼會誤判為錯誤。

---

六、第四個陷阱：BI 系統快取（這才是最陰險的）

BI 工具為了速度，會做一件事：

快取 (Cache)

意思是：

它不一定每次都重新查資料庫。

可能發生：

1. 你改了 SQL

2. 系統其實沒重新查資料

3. 仍使用舊資料

結果：

• 報表顯示 A、B、C

• 資料庫查只有 A、C

你會覺得系統壞掉。

其實只是：

報表還在看舊資料。

---

七、如何判斷是哪一種問題？

請照這個順序檢查：

步驟 1：先查「不重複清單」

先確認產品種類是否一致，而不是看筆數。

步驟 2：確認時間區間

兩邊查詢的日期是否完全相同？

步驟 3：確認是否包含當天

是否不 reopen day（當天被排除）？

步驟 4：確認報表是否重新載入

BI 是否仍用快取？

步驟 5：檢查是否是 PIVOT NULL

NULL 不等於錯誤。

---

八、為什麼這種問題很常發生？

因為 BI 系統涉及 4 層：

1. 資料庫

2. SQL 查詢

3. BI 快取

4. 視覺化轉換

任何一層不同步，就會「看起來錯」。

而人通常只會看第 4 層。

---

九、結論（最重要）

當你發現：

報表 ≠ SQL

請先記住：

大多數情況下
資料沒有錯，理解錯。

最常見原因排名：

1. 日期區間錯誤

2. DISTINCT vs 明細混淆

3. PIVOT NULL 誤解

4. BI 快取

不是資料庫壞掉。

也不是你寫錯 SQL。

而是你在比較兩個「本來就不同的東西」。

---

十、給工程師的建議

當你要驗證報表時：

永遠先問三件事：

1. 這是清單還是明細？

2. 這包含哪一天的時間？

3. 系統有沒有快取？

只要做到這三點，你排查報表問題的速度會提升非常多。

---

如果你常做報表或資料分析，建議把這篇文章收藏。
未來當客戶說「數據不對」時，你會非常需要它。