在數(shù)據(jù)庫性能優(yōu)化領(lǐng)域索引無疑是每一位開發(fā)者必須掌握的核心技能。無論是處理海量數(shù)據(jù)的后端工程師還是需要快速響應(yīng)的前端應(yīng)用一個(gè)設(shè)計(jì)不當(dāng)?shù)乃饕伎赡軐?dǎo)致查詢從毫秒級(jí)驟降至分鐘級(jí)。本文將從零開始系統(tǒng)性地拆解數(shù)據(jù)庫索引的方方面面不僅解釋其“是什么”和“為什么”更通過大量可運(yùn)行的 SQL 示例手把手教你“如何用”以及“如何避坑”。無論你是剛接觸數(shù)據(jù)庫的新手還是希望深入理解索引原理的進(jìn)階開發(fā)者都能從中獲得一套從理論到實(shí)戰(zhàn)的完整知識(shí)體系。1. 數(shù)據(jù)庫索引概念、作用與代價(jià)1.1 什么是數(shù)據(jù)庫索引想象一下你要在一本厚厚的、沒有目錄的百科全書里查找一個(gè)特定術(shù)語的解釋。你只能從第一頁開始一頁一頁地翻閱直到找到為止。這個(gè)過程非常低效。而數(shù)據(jù)庫索引就相當(dāng)于這本百科全書的目錄或關(guān)鍵詞索引。從技術(shù)角度定義數(shù)據(jù)庫索引是一種特殊的數(shù)據(jù)結(jié)構(gòu)它存儲(chǔ)了表中一列或多列的值以及這些值對(duì)應(yīng)數(shù)據(jù)行的物理位置如磁盤地址或行ID。它的核心目的是加快數(shù)據(jù)檢索速度其工作原理是通過預(yù)先對(duì)數(shù)據(jù)進(jìn)行排序和組織使得數(shù)據(jù)庫管理系統(tǒng)DBMS能夠像使用書的目錄一樣快速定位到所需的數(shù)據(jù)而無需掃描整張表。1.2 索引解決了什么問題索引主要解決數(shù)據(jù)庫查詢中的性能瓶頸具體體現(xiàn)在加速數(shù)據(jù)檢索SELECT這是索引最核心的用途。通過索引數(shù)據(jù)庫可以避免全表掃描Full Table Scan將時(shí)間復(fù)雜度從 O(n) 降低到 O(log n) 甚至 O(1)。加速數(shù)據(jù)排序ORDER BY如果排序的字段已經(jīng)建立了索引數(shù)據(jù)庫可以直接利用索引的有序性來返回結(jié)果避免臨時(shí)排序操作。保證數(shù)據(jù)唯一性UNIQUE唯一索引強(qiáng)制一列或多列的組合值必須唯一這是實(shí)現(xiàn)業(yè)務(wù)約束如用戶名、手機(jī)號(hào)唯一的關(guān)鍵手段。加速表連接JOIN在連接操作中如果連接條件字段有索引可以極大提升連接效率。1.3 索引的“雙刃劍”特性代價(jià)與權(quán)衡索引并非“免費(fèi)的午餐”。創(chuàng)建和維護(hù)索引需要付出代價(jià)占用額外存儲(chǔ)空間索引本身是一種數(shù)據(jù)結(jié)構(gòu)需要占用磁盤空間。對(duì)于大表索引的大小可能接近甚至超過原表數(shù)據(jù)。降低數(shù)據(jù)寫入速度當(dāng)執(zhí)行INSERT、UPDATE、DELETE操作時(shí)數(shù)據(jù)庫不僅需要修改表數(shù)據(jù)還需要更新所有相關(guān)的索引以保持其一致性。這會(huì)導(dǎo)致寫操作變慢。維護(hù)成本索引需要定期維護(hù)如重建、重組以保持其性能尤其是在數(shù)據(jù)頻繁增刪改的表上索引可能會(huì)產(chǎn)生大量碎片。因此索引設(shè)計(jì)的核心哲學(xué)是權(quán)衡Trade-off用額外的存儲(chǔ)空間和寫性能的輕微損失來換取讀性能的巨大提升。在大多數(shù)OLTP在線事務(wù)處理系統(tǒng)中讀操作遠(yuǎn)多于寫操作因此合理使用索引的收益非常顯著。2. 環(huán)境準(zhǔn)備與示例數(shù)據(jù)說明為了后續(xù)的實(shí)戰(zhàn)演示我們需要一個(gè)數(shù)據(jù)庫環(huán)境。本文將以最流行的開源數(shù)據(jù)庫MySQL 8.0為例進(jìn)行講解其原理同樣適用于PostgreSQL,Oracle,SQL Server等主流關(guān)系型數(shù)據(jù)庫。環(huán)境要求數(shù)據(jù)庫MySQL 5.7 或更高版本推薦 8.0。你可以使用 Docker 快速啟動(dòng)一個(gè)實(shí)例docker run --name some-mysql -e MYSQL_ROOT_PASSWORDmy-secret-pw -d mysql:8.0客戶端任何能連接 MySQL 的工具如mysql命令行客戶端、MySQL Workbench、Navicat 或 DBeaver。創(chuàng)建示例數(shù)據(jù)庫和表我們將創(chuàng)建一個(gè)模擬電商場(chǎng)景的orders訂單表用于演示各種索引操作。-- 1. 創(chuàng)建數(shù)據(jù)庫 CREATE DATABASE IF NOT EXISTS index_demo; USE index_demo; -- 2. 創(chuàng)建訂單表 DROP TABLE IF EXISTS orders; CREATE TABLE orders ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 訂單ID主鍵, order_no VARCHAR(32) NOT NULL COMMENT 訂單號(hào), user_id INT NOT NULL COMMENT 用戶ID, amount DECIMAL(10, 2) NOT NULL COMMENT 訂單金額, status TINYINT NOT NULL DEFAULT 1 COMMENT 狀態(tài)1-待支付2-已支付3-已發(fā)貨4-已完成, product_id INT NOT NULL COMMENT 商品ID, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 創(chuàng)建時(shí)間, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新時(shí)間, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT訂單表; -- 3. 插入模擬數(shù)據(jù)約10萬行 -- 這里使用存儲(chǔ)過程快速生成數(shù)據(jù)你可以直接運(yùn)行。 DELIMITER // CREATE PROCEDURE generate_order_data() BEGIN DECLARE i INT DEFAULT 0; WHILE i 100000 DO INSERT INTO orders (order_no, user_id, amount, status, product_id, create_time) VALUES ( CONCAT(NO, LPAD(i, 8, 0)), -- 生成訂單號(hào) NO00000001 格式 FLOOR(1 RAND() * 5000), -- 用戶ID在1-5000之間隨機(jī) ROUND(RAND() * 1000, 2), -- 金額在0-1000之間隨機(jī) FLOOR(1 RAND() * 4), -- 狀態(tài)在1-4之間隨機(jī) FLOOR(1 RAND() * 100), -- 商品ID在1-100之間隨機(jī) DATE_SUB(NOW(), INTERVAL FLOOR(RAND() * 365) DAY) -- 創(chuàng)建時(shí)間在過去一年內(nèi)隨機(jī) ); SET i i 1; END WHILE; END // DELIMITER ; -- 調(diào)用存儲(chǔ)過程生成數(shù)據(jù)可能需要幾秒鐘 CALL generate_order_data(); -- 刪除存儲(chǔ)過程 DROP PROCEDURE generate_order_data; -- 4. 查看數(shù)據(jù)概覽 SELECT COUNT(*) AS total_orders FROM orders; SELECT * FROM orders LIMIT 5;運(yùn)行后你將擁有一個(gè)包含約10萬行數(shù)據(jù)的orders表這是觀察索引效果的一個(gè)合適規(guī)模。3. 索引的核心類型與工作原理拆解3.1 B-Tree 索引最廣泛的索引結(jié)構(gòu)B-Tree平衡多路查找樹是 MySQL 中InnoDB和MyISAM存儲(chǔ)引擎默認(rèn)的索引類型。我們常說的普通索引、唯一索引、主鍵索引底層基本都是 B-Tree。工作原理B-Tree 保持?jǐn)?shù)據(jù)有序并且樹的深度是平衡的。查找時(shí)從根節(jié)點(diǎn)開始通過比較鍵值決定進(jìn)入哪個(gè)子節(jié)點(diǎn)層層向下最終在葉子節(jié)點(diǎn)找到目標(biāo)數(shù)據(jù)或數(shù)據(jù)的位置指針。這個(gè)過程非常高效。適用場(chǎng)景全值匹配范圍查詢,,BETWEEN,LIKE prefix%排序查詢ORDER BY前綴匹配示例為user_id創(chuàng)建 B-Tree 索引-- 創(chuàng)建普通索引 CREATE INDEX idx_user_id ON orders(user_id); -- 查看索引創(chuàng)建后的查詢計(jì)劃EXPLAIN是關(guān)鍵工具 EXPLAIN SELECT * FROM orders WHERE user_id 1234;觀察EXPLAIN輸出中的type和key字段。type從可能的ALL全表掃描變?yōu)閞ef或rangekey顯示使用了idx_user_id這表示索引生效了。3.2 哈希索引精確匹配的利器哈希索引基于哈希表實(shí)現(xiàn)它對(duì)索引鍵計(jì)算一個(gè)哈希碼哈希碼對(duì)應(yīng)著數(shù)據(jù)行的指針。它只能用于等值比較不支持范圍查詢、排序或前綴匹配。工作原理對(duì)WHERE user_id 1234這樣的條件數(shù)據(jù)庫計(jì)算1234的哈希值直接到哈希表中找到對(duì)應(yīng)的行指針。速度極快時(shí)間復(fù)雜度接近 O(1)。MySQL 中的使用InnoDB引擎有一個(gè)特殊功能叫“自適應(yīng)哈希索引”它是自動(dòng)的、內(nèi)部的。我們無法手動(dòng)創(chuàng)建真正的哈希索引但MEMORY存儲(chǔ)引擎支持。更多時(shí)候哈希索引的概念幫助我們理解為何等值查詢?nèi)绱丝?。適用場(chǎng)景僅等值查詢且數(shù)據(jù)離散度高。3.3 全文索引應(yīng)對(duì)文本搜索當(dāng)需要在大量文本數(shù)據(jù)如文章內(nèi)容、產(chǎn)品描述中進(jìn)行關(guān)鍵詞搜索時(shí)LIKE %keyword%效率極低且無法利用普通 B-Tree 索引。全文索引FULLTEXT就是為此而生。工作原理它會(huì)對(duì)文本內(nèi)容進(jìn)行分詞建立倒排索引記錄每個(gè)關(guān)鍵詞出現(xiàn)在哪些文檔數(shù)據(jù)行中。示例-- 假設(shè)我們有一個(gè) articles 表有 content 字段 -- ALTER TABLE articles ADD FULLTEXT INDEX ft_idx_content(content); -- 使用 MATCH ... AGAINST 進(jìn)行全文搜索 SELECT * FROM articles WHERE MATCH(content) AGAINST(數(shù)據(jù)庫 索引 IN NATURAL LANGUAGE MODE);3.4 空間索引R-Tree用于地理空間數(shù)據(jù)類型如GEOMETRY,POINT。例如查詢“某個(gè)點(diǎn)附近的所有位置”。日常業(yè)務(wù)開發(fā)中接觸較少。3.5 聚集索引 vs 非聚集索引以 InnoDB 為例這是理解索引性能的關(guān)鍵概念。聚集索引Clustered Index表數(shù)據(jù)本身的存儲(chǔ)順序就是按照聚集索引鍵的順序排列的。一張表只能有一個(gè)聚集索引。在InnoDB中主鍵PRIMARY KEY就是聚集索引。如果沒有定義主鍵InnoDB會(huì)選擇一個(gè)唯一的非空索引代替如果也沒有則會(huì)隱式創(chuàng)建一個(gè)隱藏的聚集索引。優(yōu)點(diǎn)對(duì)于主鍵的范圍查詢和排序非常快因?yàn)橄噜彽臄?shù)據(jù)物理上也存儲(chǔ)在一起。缺點(diǎn)插入速度嚴(yán)重依賴于插入順序。亂序插入可能導(dǎo)致頻繁的頁分裂影響性能。非聚集索引Secondary Index也叫二級(jí)索引或輔助索引。索引結(jié)構(gòu)的葉子節(jié)點(diǎn)存儲(chǔ)的不是完整行數(shù)據(jù)而是該行的主鍵值聚集索引鍵。查找過程當(dāng)通過二級(jí)索引查找時(shí)先找到對(duì)應(yīng)的主鍵值再通過這個(gè)主鍵值回到聚集索引主鍵索引中查找完整的行數(shù)據(jù)。這個(gè)過程稱為回表Bookmark Lookup。影響如果查詢所需的所有列都包含在二級(jí)索引中則無需回表這個(gè)索引被稱為“覆蓋索引Covering Index”性能最佳。4. 索引的創(chuàng)建、查看與刪除實(shí)戰(zhàn)4.1 創(chuàng)建索引的多種語法-- 1. 創(chuàng)建表時(shí)直接定義最推薦尤其對(duì)于主鍵和唯一約束 CREATE TABLE users ( id INT PRIMARY KEY, -- 主鍵索引 email VARCHAR(100) UNIQUE, -- 唯一索引 name VARCHAR(50), INDEX idx_name (name) -- 普通索引 ); -- 2. 使用 ALTER TABLE 添加索引常用 ALTER TABLE orders ADD INDEX idx_status (status); -- 普通索引 ALTER TABLE orders ADD UNIQUE INDEX uk_order_no (order_no); -- 唯一索引 ALTER TABLE orders ADD INDEX idx_composite (user_id, status); -- 復(fù)合索引 -- 3. 使用 CREATE INDEX 語句標(biāo)準(zhǔn)SQL不能用于創(chuàng)建主鍵 CREATE INDEX idx_amount ON orders(amount); CREATE UNIQUE INDEX uk_order_no ON orders(order_no); -- 與ALTER TABLE方式等價(jià)4.2 創(chuàng)建復(fù)合索引最左前綴原則復(fù)合索引聯(lián)合索引指對(duì)多個(gè)列同時(shí)建立一個(gè)索引。-- 創(chuàng)建一個(gè)基于 (user_id, status, create_time) 的復(fù)合索引 CREATE INDEX idx_user_status_time ON orders(user_id, status, create_time);最左前綴原則復(fù)合索引(A, B, C)相當(dāng)于建立了(A),(A, B),(A, B, C)三個(gè)索引。查詢時(shí)必須從索引的最左列開始使用否則索引可能失效。WHERE user_id 1? 使用索引WHERE user_id 1 AND status 2? 使用索引WHERE status 2? 未從最左列user_id開始索引可能失效取決于優(yōu)化器選擇WHERE user_id 1 AND create_time 2023-01-01? 使用索引的user_id部分create_time作為過濾條件。4.3 查看與刪除索引-- 查看表的所有索引 SHOW INDEX FROM orders; -- 或使用更詳細(xì)的信息MySQL 8.0 SELECT * FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA index_demo AND TABLE_NAME orders; -- 刪除索引 DROP INDEX idx_user_id ON orders; -- 或使用 ALTER TABLE ALTER TABLE orders DROP INDEX idx_status;5. 索引使用策略與性能分析5.1 使用 EXPLAIN 分析查詢執(zhí)行計(jì)劃EXPLAIN是優(yōu)化 SQL 和索引的必備工具。它展示了 MySQL 如何執(zhí)行一條查詢語句。EXPLAIN SELECT user_id, amount FROM orders WHERE user_id 100 AND status 2 ORDER BY create_time DESC;關(guān)注以下幾個(gè)關(guān)鍵字段type訪問類型從好到壞systemconsteq_refrefrangeindexALL。至少要到range級(jí)別避免ALL全表掃描。key實(shí)際使用的索引。rows預(yù)估需要掃描的行數(shù)越少越好。Extra額外信息。出現(xiàn)Using filesort文件排序或Using temporary臨時(shí)表通常意味著需要優(yōu)化。出現(xiàn)Using index是好事表示使用了覆蓋索引。5.2 索引失效的常見場(chǎng)景即使創(chuàng)建了索引錯(cuò)誤的查詢寫法也可能導(dǎo)致索引失效。對(duì)索引列進(jìn)行運(yùn)算或函數(shù)操作-- 索引失效 SELECT * FROM orders WHERE YEAR(create_time) 2023; -- 優(yōu)化后利用索引范圍掃描 SELECT * FROM orders WHERE create_time 2023-01-01 AND create_time 2024-01-01;使用OR連接條件且部分條件無索引-- 假設(shè) user_id 有索引product_id 無索引 SELECT * FROM orders WHERE user_id 100 OR product_id 50; -- 可能導(dǎo)致全表掃描 -- 優(yōu)化考慮改為 UNION或?yàn)?product_id 也建立索引 SELECT * FROM orders WHERE user_id 100 UNION SELECT * FROM orders WHERE product_id 50;使用!或NOT INSELECT * FROM orders WHERE status ! 1; -- 可能不走索引 -- 對(duì)于狀態(tài)不多的枚舉可以考慮 SELECT * FROM orders WHERE status IN (2,3,4);LIKE以通配符開頭SELECT * FROM orders WHERE order_no LIKE %123; -- 索引失效 SELECT * FROM orders WHERE order_no LIKE NO%; -- 索引有效最左前綴匹配字符串索引列查詢時(shí)未加引號(hào)類型隱式轉(zhuǎn)換-- 假設(shè) order_no 是 VARCHAR 類型 SELECT * FROM orders WHERE order_no 123456; -- 數(shù)據(jù)庫會(huì)將列轉(zhuǎn)為數(shù)字索引失效 SELECT * FROM orders WHERE order_no 123456; -- 正確索引有效復(fù)合索引未遵循最左前綴原則前文已述。5.3 覆蓋索引減少回表提升性能如果一個(gè)索引包含了查詢所需的所有字段數(shù)據(jù)庫就無需回表直接從索引中取得數(shù)據(jù)性能極高。-- 創(chuàng)建覆蓋索引 CREATE INDEX idx_covering ON orders(user_id, product_id, amount); -- 查詢1需要回表SELECT * EXPLAIN SELECT * FROM orders WHERE user_id 100 AND product_id 10; -- Extra 列可能沒有 Using index -- 查詢2覆蓋索引所需字段都在索引中 EXPLAIN SELECT user_id, product_id, amount FROM orders WHERE user_id 100 AND product_id 10; -- Extra 列會(huì)出現(xiàn) Using index性能更優(yōu)6. 索引設(shè)計(jì)的最佳實(shí)踐與工程建議6.1 索引設(shè)計(jì)原則只為用于搜索、排序或分組的列創(chuàng)建索引WHERE,ORDER BY,GROUP BY,JOIN ON子句中的列是候選。考慮列的基數(shù)Cardinality基數(shù)指列中不重復(fù)值的數(shù)量。基數(shù)越高如用戶ID、手機(jī)號(hào)索引過濾效果越好。性別這種低基數(shù)列通常不適合單獨(dú)建索引。使用短索引對(duì)于字符串列如果前N個(gè)字符已有足夠區(qū)分度可以創(chuàng)建前綴索引以減少索引大小。CREATE INDEX idx_email_prefix ON users(email(10)); -- 只對(duì)email前10個(gè)字符索引利用復(fù)合索引避免多個(gè)單列索引復(fù)合索引通常比多個(gè)獨(dú)立索引更高效但要注意最左前綴原則。謹(jǐn)慎創(chuàng)建索引索引不是越多越好。每多一個(gè)索引寫操作就多一份負(fù)擔(dān)。定期審查未使用或低效的索引。6.2 生產(chǎn)環(huán)境注意事項(xiàng)在測(cè)試環(huán)境驗(yàn)證任何索引變更都應(yīng)在測(cè)試環(huán)境通過EXPLAIN和真實(shí)負(fù)載測(cè)試驗(yàn)證效果。選擇業(yè)務(wù)低峰期操作創(chuàng)建或刪除大表索引是重量級(jí)操作會(huì)鎖表Online DDL 在 MySQL 5.6 有所改善但仍需謹(jǐn)慎。監(jiān)控索引使用情況使用performance_schema或sys庫來查找未使用的索引。-- 在MySQL 5.7中可通過以下查詢輔助判斷需開啟性能模式 SELECT object_schema, object_name, index_name FROM performance_schema.table_io_waits_summary_by_index_usage WHERE index_name IS NOT NULL AND count_star 0 ORDER BY object_schema, object_name;定期維護(hù)對(duì)于數(shù)據(jù)頻繁變動(dòng)的表索引會(huì)產(chǎn)生碎片定期執(zhí)行OPTIMIZE TABLE table_name;或ALTER TABLE table_name ENGINEInnoDB;可以重建表并整理碎片需在業(yè)務(wù)低峰期進(jìn)行。6.3 索引與主鍵設(shè)計(jì)主鍵應(yīng)簡(jiǎn)短因?yàn)樗卸?jí)索引都包含主鍵值過長(zhǎng)的主鍵如很長(zhǎng)的 VARCHAR會(huì)導(dǎo)致二級(jí)索引龐大。推薦使用自增整數(shù)BIGINT UNSIGNED AUTO_INCREMENT。主鍵與業(yè)務(wù)無關(guān)盡量避免使用身份證號(hào)、手機(jī)號(hào)等業(yè)務(wù)字段作為主鍵。業(yè)務(wù)字段可能變更且長(zhǎng)度可能不理想。使用代理主鍵Surrogate Key是更佳實(shí)踐。7. 常見問題與排查思路問題現(xiàn)象可能原因排查與解決思路查詢速度突然變慢1. 索引失效如類型轉(zhuǎn)換、函數(shù)操作2. 數(shù)據(jù)量激增原有索引選擇性下降3. 索引碎片化嚴(yán)重1. 使用EXPLAIN分析慢查詢檢查type和key。2. 分析WHERE條件確保寫法能利用索引。3. 檢查表數(shù)據(jù)和索引大小考慮在低峰期優(yōu)化表。INSERT/UPDATE很慢1. 表上索引過多2. 唯一約束沖突導(dǎo)致回滾3. 單行數(shù)據(jù)過大1. 審查并刪除不必要的索引。2. 檢查業(yè)務(wù)邏輯避免重復(fù)數(shù)據(jù)提交。3. 考慮垂直分表將大字段拆分。磁盤空間占用過高1. 索引數(shù)量過多或過大2. 未清理的歷史數(shù)據(jù)3. 使用了大字段如 TEXT且未單獨(dú)存儲(chǔ)1. 使用SHOW TABLE STATUS分析索引占比。2. 建立數(shù)據(jù)歸檔機(jī)制。3. 考慮將大字段移至擴(kuò)展表。明明有索引但EXPLAIN顯示沒用到1. 查詢優(yōu)化器認(rèn)為全表掃描更快當(dāng)表中數(shù)據(jù)很少時(shí)2. 索引統(tǒng)計(jì)信息過期3. 查詢條件使用了OR、!等導(dǎo)致失效1. 使用ANALYZE TABLE table_name;更新統(tǒng)計(jì)信息。2. 使用FORCE INDEX提示強(qiáng)制使用索引謹(jǐn)慎使用。3. 重寫查詢語句。復(fù)合索引部分失效未遵循最左前綴原則調(diào)整查詢條件順序或根據(jù)最頻繁的查詢模式重新設(shè)計(jì)復(fù)合索引順序。掌握數(shù)據(jù)庫索引是后端工程師從“會(huì)用數(shù)據(jù)庫”到“精通數(shù)據(jù)庫”的關(guān)鍵一步。它要求我們?cè)诖鎯?chǔ)空間、讀寫性能和數(shù)據(jù)一致性之間做出精妙的權(quán)衡。核心要點(diǎn)可以歸納為理解B-Tree原理善用EXPLAIN工具遵循最左前綴原則追求覆蓋索引并時(shí)刻謹(jǐn)記索引的維護(hù)成本。建議的學(xué)習(xí)路徑是先從單表查詢優(yōu)化開始熟練使用EXPLAIN分析各種查詢場(chǎng)景下的索引使用情況然后深入研究復(fù)合索引的設(shè)計(jì)理解最左前綴和索引下推等高級(jí)特性最后在復(fù)雜的多表關(guān)聯(lián)和業(yè)務(wù)場(chǎng)景中全局考量索引策略。記住沒有放之四海而皆準(zhǔn)的索引方案最好的索引永遠(yuǎn)是服務(wù)于你具體業(yè)務(wù)查詢模式的那一個(gè)。動(dòng)手在你自己的項(xiàng)目數(shù)據(jù)庫中實(shí)踐、分析和調(diào)整是掌握這門藝術(shù)的不二法門。