GitHub 原本用來顯示專案星標（star）歷史的 API，會傳回每一位使用者的按星紀錄與時間，結果被有心人士拿去大量爬取，用在垃圾訊息與釣魚攻擊上。同時，熱門專案像 React（擁有 251000 顆星）要抓完整歷史，得分頁呼叫將近 2500 次請求，對資料庫造成很大負擔，常常逾時失敗。
GitHub 工程團隊改建了一個全新的端點，不再回傳個別使用者的紀錄，而是直接給出最近 30 週、每天的星標數量加總，完全不含身分資訊。關鍵改動在查詢順序：舊版先把所有星標整理、排序後再分頁，新版則先用索引依日期範圍篩選，再把符合範圍的紀錄分組成每日區塊，等於每一顆星幾乎只被計算一次。
這個改動把熱門專案的請求數從約 2500 次降到大約 24 次，資料庫效能明顯改善。工程團隊提到，修正前光是計算星數的查詢就跑了將近 3 萬 7000 次，平均要花 3 秒才能跑完；他們也順手在網站介面找出類似的沒效率寫法並修好，每週少跑了「數百個」緩慢查詢，連帶也保護了按星使用者的隱私。
這則新聞偏向後端工程的真實案例，說明一個看似單純的「查詢歷史資料」功能，背後其實牽涉資料庫設計與查詢順序的細節，順序改變就能讓效能差上百倍。對正在學程式的孩子來說，這是很好的例子：寫得出功能只是開始，想清楚資料怎麼存、怎麼查，才是讓程式跑得快、也更安全的關鍵能力。
開發工具效能優化資料庫