WHERE 決定回傳幾列，索引才決定要看過幾列
WHERE project_id = X決定的是回傳多少列（也就是分成幾頁）。它沒有減少資料庫要看過多少列。
沒有索引時，資料庫不知道哪些列屬於這個專案，只能整張表逐筆檢查、逐筆比對 project_id——這是 full table scan。條件再精準，掃描量仍然是整張表。
索引才是那個「不用看過全部」的機制：它讓資料庫直接定位到 project_id = X 的那一段，掃描量從表的大小降成符合條件的列數。
讀 query 時要分開的兩個量
| 量 | 由什麼決定 | 影響 |
|---|---|---|
| 回傳幾列（rows returned） | WHERE / LIMIT | 網路傳輸、記憶體 |
| 看過幾列（rows examined） | 索引 | 資料庫的實際工作量 |
效能問題幾乎都出在第二個量。「我有加 WHERE 啊」不是效能論證——要看執行計畫確認它真的走了索引。
這兩個量在執行計畫裡是分開印的
不用推論，直接看得到：
Seq Scan on orders (actual time=0.031..412.775 rows=87432 loops=1)
Filter: (status = 'pending')
Rows Removed by Filter: 712568| 輸出 | 對應上表哪一列 |
|---|---|
rows=87432 | 回傳幾列 |
Rows Removed by Filter: 712568 | 讀了但丟掉的 → 加起來 80 萬列是「看過幾列」 |
讀了 80 萬、留下 8 萬。 Rows Removed by Filter 愈大，代表這個條件愈值得有索引來幫它跳過。怎麼讀整份輸出見 執行計畫是一棵樹，從下往上讀。