<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Archive on 技術、遊戲、生活通俗易懂的解釋</title><link>https://takao.blog/zh-tw/tags/archive/</link><description>Recent content in Archive on 技術、遊戲、生活通俗易懂的解釋</description><generator>Hugo -- gohugo.io</generator><language>zh-tw</language><copyright>Commentary of Takao</copyright><lastBuildDate>Sun, 25 May 2025 00:00:00 +0900</lastBuildDate><atom:link href="https://takao.blog/zh-tw/tags/archive/index.xml" rel="self" type="application/rss+xml"/><item><title>資料庫索引簡介：解決查詢延遲</title><link>https://takao.blog/zh-tw/web/backend-database-indexing-basics/</link><pubDate>Sun, 25 May 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/zh-tw/web/backend-database-indexing-basics/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/backend-database-indexing-basics-zh-tw.png" alt="Featured image of post 資料庫索引簡介：解決查詢延遲" /&gt;&lt;h2 id="介紹"&gt;介紹
&lt;/h2&gt;&lt;p&gt;隨著 Web 應用程式的擴展和資料量的成長，後端系統經常面臨查詢延遲等資料庫瓶頸問題。&lt;/p&gt;
&lt;p&gt;在沒有適當索引優化的情況下，在具有數十萬筆記錄的表上執行聯接 (&lt;code&gt;JOIN&lt;/code&gt;) 操作或複雜的搜尋查詢可能會導致資料庫 CPU 峰值，從而導致最終用戶的回應時間變慢。&lt;/p&gt;
&lt;p&gt;設計資料庫索引是解決這些效能瓶頸的有效方法。本文解釋了資料庫索引的工作原理，詳細介紹了 B 樹結構，並分享了設計有效索引的指南。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="1-為什麼索引可以加快查詢速度"&gt;1. 為什麼索引可以加快查詢速度？
&lt;/h2&gt;&lt;p&gt;將資料庫索引視為教科書後面的索引部分。&lt;/p&gt;
&lt;p&gt;如果沒有索引，搜尋特定主題需要您掃描從開始到餘韻的每一頁。在資料庫中，這稱為&lt;strong&gt;全表掃描（All Table Scan）&lt;/strong&gt;。隨著資料量的增加，這種線性掃描過程需要更長的時間。&lt;/p&gt;
&lt;p&gt;透過在特定列上建立索引，資料庫以排序結構組織資料並記錄對實體行的參考（指標）。這使得查詢引擎可以快速找到目標記錄。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="2-b-樹索引的機制"&gt;2. B 樹索引的機制
&lt;/h2&gt;&lt;p&gt;關聯式資料庫（如 MySQL 和 PostgreSQL）通常使用&lt;strong&gt;B-Tree（平衡樹）索引&lt;/strong&gt;結構。&lt;/p&gt;
&lt;p&gt;B 樹將鍵組織成由根節點、中間節點和葉節點組成的平衡樹佈局。&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"&gt;&lt;code class="language-text" data-lang="text"&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; [Root Node]
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; / \
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; [100] [200]
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; / \ / \
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; [...] [...] [...] [Leaf Nodes] -&amp;gt; References to physical rows
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;h3 id="如何執行搜尋"&gt;如何執行搜尋
&lt;/h3&gt;&lt;ol&gt;
&lt;li&gt;搜尋查詢從頂級根節點開始。&lt;/li&gt;
&lt;li&gt;查詢引擎將目標鍵值與節點值進行比較，以確定要遵循哪個子分支指標。&lt;/li&gt;
&lt;li&gt;這個過程向下重複到葉節點，葉節點包含指向磁碟上實體行的指標（如 ROWID），允許引擎取得匹配的記錄。&lt;/li&gt;
&lt;/ol&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;好處：&lt;/strong&gt; 無論表格成長多大，搜尋複雜度都會以 &lt;code&gt;O(log N)&lt;/code&gt; 對數縮放。這使得查找時間變快，通常在幾毫秒內解析。&lt;/li&gt;
&lt;/ul&gt;
&lt;hr&gt;
&lt;h2 id="3-設計資料庫索引的三個準則"&gt;3. 設計資料庫索引的三個準則
&lt;/h2&gt;&lt;p&gt;雖然索引可以提高搜尋速度，但在每一列上建立索引會適得其反。每個寫入作業（&lt;code&gt;INSERT&lt;/code&gt;、&lt;code&gt;UPDATE&lt;/code&gt;、&lt;code&gt;DELETE&lt;/code&gt;）都需要更新對應的索引結構，這會增加開銷，從而降低寫入效能。&lt;/p&gt;
&lt;p&gt;使用這三個準則來決定何時建立索引：&lt;/p&gt;
&lt;h3 id="準則-1具有高基數的目標列選擇性"&gt;準則 1：具有高基數的目標列（選擇性）
&lt;/h3&gt;&lt;p&gt;基數是指儲存在列中的&lt;strong&gt;唯一值的數量&lt;/strong&gt;。&lt;/p&gt;</description></item><item><title>SQL Injection 預防: Modern Database Security 指南</title><link>https://takao.blog/zh-tw/web/sql-injection-prevention/</link><pubDate>Tue, 01 Oct 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/zh-tw/web/sql-injection-prevention/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/sql-injection-prevention-zh-tw.png" alt="Featured image of post SQL Injection 預防: Modern Database Security 指南" /&gt;&lt;p&gt;SQL injection remains in the OWASP Top 10 despite decades of awareness. The 2023-2024 period saw high-profile breaches in healthcare, e-commerce, and government sectors involving SQLi. While the classic &lt;code&gt;' OR 1=1 --&lt;/code&gt; attack is well-known, modern variants include second-order injection, blind SQLi (time-based and boolean-based), and out-of-band exfiltration. Prevention is well-understood but poorly executed due to legacy code, ORM misuse, and insufficient testing automation.&lt;/p&gt;
&lt;h2 id="parameterized-queries-and-prepared-statements"&gt;Parameterized Queries and Prepared Statements
&lt;/h2&gt;&lt;p&gt;Prepared statements are the gold standard for SQL injection prevention. They separate SQL logic from data at the database engine level, making it impossible for user input to alter query structure.&lt;/p&gt;</description></item></channel></rss>