🔍 API 回傳空陣列（[]）但資料庫明明有資料？完整排查指南（含 Oracle SQL 與後端設計陷阱解析）

 很多工程師都會遇到這種情況：

👉 畫面顯示「無資料」
👉 API 呼叫成功（HTTP 200）
👉 Swagger 測試也正常
👉 但 Response 卻是：[]（空陣列）

最讓人困惑的是：

👉 資料庫明明有資料！

這篇文章會用「白話＋工程師角度」帶你一步步找出問題，並教你怎麼從根本解決。

---

🚨 問題核心：為什麼 API 會回 []？

在多數後端程式中，回傳空陣列通常只會發生在這兩種情況：

情況一：查詢條件找不到資料

也就是：

👉 你查的條件「沒有對應資料」

---

情況二：程式主動把資料擋掉（設計邏輯問題）

例如：

如果日期清單是空的 → 直接回 []

👉 這種設計會導致：

即使「主資料有」，但「輔助資料沒有」
👉 API 還是回空

---

🧩 常見資料流程（簡化理解）

很多報表 API 其實做兩件事：

① 先拿「日期清單」

從某張參數表抓日期

② 再拿「主資料」

從另一張表抓數據

---

👉 最後組成結果回給前端

---

❗ 致命設計錯誤（超常見）

很多程式會寫成：

👉 如果日期清單是空 → 直接回空資料

但問題是：

👉 日期表和主資料表「不是一定同步」

---

🧪 實際排查方法（Oracle SQL）

以下是你可以在資料庫直接驗證的步驟。

---

✅ Step 1：確認主資料是否存在

SELECT COUNT(*)
FROM 主要資料表
WHERE 版本欄位 = '你的版本';

結果判斷：

• 0 → 有資料 ✅
• = 0 → 根本沒資料 ❌

---

✅ Step 2：檢查「版本字串」是否完全一致

SELECT 版本欄位, LENGTH(版本欄位)
FROM 主要資料表
WHERE 版本欄位 LIKE '關鍵字%';

常見問題：

• 多空白
• 少一段（例如 .01）
• 全形 / 半形不同

👉 這種問題超常見！

---

✅ Step 3：檢查日期清單是否抓得到

SELECT COUNT(DISTINCT 日期欄位)
FROM 日期來源表
WHERE 版本欄位 LIKE '%關鍵字%'
AND 日期欄位 IS NOT NULL;

---

👉 如果這裡是 0：

✔ API 會直接回 []
❌ 就算主資料有也沒用

---

✅ Step 4：檢查版本對應是否抓錯資料

SELECT 版本欄位, COUNT(*)
FROM 日期來源表
WHERE 版本欄位 LIKE '%關鍵字%'
GROUP BY 版本欄位;

---

👉 這可以看出：

• 抓到的是不是錯版本
• 是否混到其他資料

---

⚠️ 常見錯誤原因排名（實務經驗）

🥇 第一名：版本存在「主表」但不存在「明細表」

例如：

👉 版本在「版本清單表」有
👉 但在「實際資料表」沒有

➡ 結果：API 永遠回空

---

🥈 第二名：LIKE '%xxx%' 用錯

很多人用「包含」查詢：

LIKE '%ABC%'

但實際需要的是：

LIKE 'ABC%'

👉 否則會抓到不相關資料或抓不到

---

🥉 第三名：字串不一致（最陰險）

看起來一樣，但其實不同：

• NB_W2603_20260116.01
• NB_W2603_20260116.01 （多空白）

👉 SQL = 不會 match

---

🏅 第四名：日期表沒有資料

這是最容易忽略的：

👉 日期表是空的
👉 API 直接 return []

---

🛠️ 改善建議（非常重要）

✅ 建議一：不要因為日期空就 return []

改成：

👉 主資料照回
👉 日期清單為空即可

---

✅ 建議二：用「前綴比對」取代 contains

LIKE 'ABC%'

👉 效能更好 + 不會誤抓

---

✅ 建議三：版本來源統一

不要：

• 下拉選單用 A 表
• API 查詢用 B 表

👉 會導致「選得到但查不到」

---

✅ 建議四：前端先確認 API 是否真的有資料

打開 DevTools：

👉 看 Response
👉 印出 console.log

---

🎯 總結（重點整理）

如果你遇到：

👉 API 回 200
👉 但資料是 []

請直接照這順序檢查：

1️⃣ 主資料表是否有資料
2️⃣ 版本字串是否完全一致
3️⃣ 日期清單是否為空
4️⃣ LIKE 條件是否錯誤
5️⃣ API 是否被「邏輯擋掉」

---

💬 給工程師的一句話

👉 這種問題 90%不是資料庫錯，而是條件或邏輯設計錯

當你看到 []：

👉 不要懷疑資料
👉 先懷疑「條件」