資料庫管理
含有「資料庫管理」共 8 篇內容
全部內容
發佈日期由新至舊
前陣子在跟同事討論一段 SP（Stored Procedure）的效能問題，話題漸漸轉到了 Table 建立時的設計策略。
同事的想法是這樣的：「建 Table 的時候就把欄位結構跟 Index 都設定好，之後 Insert 資料就一步到位，感覺比較有效率。」而我的直覺則剛好相反。
80億資料500行的搜尋指令是在工作時遇過得真實場景，這個系列是我在工作實務中歸納出來的學習筆記，起初真的是頭大，找資料找到眼花撩亂，希望可以給需要的人一些頭緒，這系列目前暫定先寫到這裡囉，歡迎大家交流。
經過前面四篇文章，能夠知道 Execution Plan 的四大核心：閱讀方向（粗細箭頭）、存取方式（Seek 與 Scan）、關聯策略（三大 Join）以及警告標誌（四大陷阱）。
然而當面對一張包含幾十個、甚至上百個節點的巨大執行計畫時，很容易感到不知所措；這時候需要的是一套系統化的除錯 SOP。
在調校 SQL Server 查詢效能時，有些問題容易被忽略，卻也容易造成嚴重的效能退化：Missing Index、Implicit Conversion、Spill to TempDB、以及 Residual Predicate。整理這四種問題的成因、症狀與修正方式，並說明彼此之間容易混淆的關鍵
延續上篇，當我們確保了資料存取的效率（消滅了不必要的 Scan 與 Key Lookup）後，接下來要面對的就是關聯式資料庫最核心的動作：將多張資料表結合在一起（Join）。
在上一篇中，我們建立了閱讀執行計畫的「方向感」，學會透過箭頭粗細找出塞車路段。順著箭頭一路往右追溯到最源頭，我們就會看到 SQL Server 是如何進入資料庫「拿資料」的。
這一步至關重要。因為資料庫系統最大的效能瓶頸往往在於磁碟 I/O（資料讀寫）。你是在「精準尋找」還是在「盲目翻找」，決定了
在開發與維護資料庫的日常中，會遇到這樣的場景，一段 SQL 查詢平常跑得順順的，卻突然卡住，或者明明加了 WHERE 條件，資料庫卻慢到讓人想打電腦。
如果你使用過 Bolt 或是 Lovable 等 AI 寫程式平台，應該會發現它們都內建支援 Supabase 連接。Supabase 為什麼這麼受歡迎？這要從它背後使用的資料庫技術 PostgreSQL 說起。
當你在網路上購物、瀏覽社群媒體、或是查看銀行帳戶餘額時，這些資訊都被存放在「資料庫」
