㈠ 如何評價ku存儲引擎
沒有數據分析流式計算的經驗，根據對kv存儲系統的理解，簡單答一發，輕拍。。
數據存儲的選擇上，HBASE和HADOOP在吞吐率、延遲上各有側重，如果做數據分析，要從HBase導出到hadoop平台再用Hive查詢，這就要求系統要混布HBASE和hadoop。
KADU的目標就是要兼顧前兩個存儲系統，實現對外數據的存儲和後台計算的本地化，減少數據傳輸成本已經部署運維成本。
架構方面，還是延用BIGTABLE的基本架構，元數據和數據分開存儲的，但做了一些比較有挑戰的優化操作，提升查詢和插入的性能
另外的亮點是，多副本間使用了raft保證數據的高可靠性。
性能方面，目前beta版本要略差與HBASE,這也是意料之中的事情。
我列舉幾個我熟悉的，
1，存儲引擎，根據應用選擇合適的引擎
2，索引
----這個就有很多文章了，具體需要你自己去了解
3，sql語句優化，查詢條件的選擇之類
4，mysql自身系統配置，需要針對應用去定製
5，表的選擇，臨時表，或者分區表，也需要針對應用的情況去選擇使用
㈢ 怎麼理解 MySQL 常見的兩種存儲引擎：MyISAM與InnoDB
InnoDB 引擎：InnoDB 引擎提供了對資料庫 acid 事務的支持，並且還提供了行級鎖和外鍵的約束，它的設計的目標就是處理大數據容量的資料庫系統。MySQL 運行的時候，InnoDB 會在內存中建立緩沖池，用於緩沖數據和索引。但是該引擎是不支持全文搜索，同時啟動也比較的慢，它是不會保存表的行數的，所以當進行 select count() from table 指令的時候，需要進行掃描全表。由於鎖的粒度小，寫操作是不會鎖定全表的,所以在並發度較高的場景下使用會提升效率的。
MyIASM 引擎：MySQL 的默認引擎，但不提供事務的支持，也不支持行級鎖和外鍵。因此當執行插入和更新語句時，即執行寫操作的時候需要鎖定這個表，所以會導致效率會降低。不過和 InnoDB 不同的是，MyIASM 引擎是保存了表的行數，於是當進行 select count() from table 語句時，可以直接的讀取已經保存的值而不需要進行掃描全表。所以，如果表的讀操作遠遠多於寫操作時，並且不需要事務的支持的，可以將 MyIASM 作為資料庫引擎的首選。
MyISAM是MySQL的默認資料庫引擎（5.5版之前）。雖然性能極佳，而且提供了大量的特性，包括全文索引、壓縮、空間函數等，但MyISAM不支持事務和行級鎖，而且最大的缺陷就是崩潰後無法安全恢復。不過，5.5版本之後，MySQL引入了InnoDB（事務性資料庫引擎），MySQL 5.5版本後默認的存儲引擎為InnoDB。
大多數時候我們使用的都是 InnoDB 存儲引擎，但是在某些情況下使用 MyISAM 也是合適的比如讀密集的情況下。
㈣ 總結下MySQL存儲引擎的區別和性能優化的一些方法
。MyISAM在所有MySQL配置里被支持，是默認的存儲引擎，除非配置MySQL默認使用另外一個引擎
㈤ 存儲引擎是什麼意思啊比如mysql的。
臨時表的存儲引擎
在 MySQL 5.6 之前，所有磁碟上的臨時表都默認創建為 MyISAM 類型。臨時表是在內存中，還是在磁碟上創建，具體取決於配置，並在查詢結束時立即刪除。從 MySQL 5.7 開始，它們默認創建為 InnoDB 類型。
新默認值可提升整體性能，大多數情況下都是最佳選擇。
可以使用新的配置項來設置臨時表的存儲引擎：internal_tmp_disk_storage_engine ，可選值為 InnoDB（默認）或 MyISAM。
InnoDB 類型的臨時表存在的潛在問題
盡管使用 InnoDB 是性能最佳的，但可能會出現新的潛在問題。在某些特定情況下，您可能會出現磁碟耗盡和伺服器中斷。
與資料庫中的任何其他 InnoDB 表一樣，臨時表具有自己的表空間文件。新文件與通用表空間一起位於數據目錄中，名稱為 ibtmp1。它存儲所有 tmp 表。不運行手動運行 OPTIMIZE TABLE，表空間文件就會不斷增長。如果你不能使用 OPTIMIZE，那麼唯一能將 ibtmp1 大小縮小為零的方法，就是重新啟動伺服器。幸運的是，即使文件無法減小，在執行查詢後，臨時表也會自動刪除，表空間可回收使用。現在，我們想一想以下情境：
存在未優化的查詢，需要在磁碟上創建非常大的的臨時表
存在優化的查詢，但他們正在磁碟上創建非常大的臨時表，因為你正在對此數據集進行計算（統計，分析）
高並發連接時，運行相同的查詢，伴隨臨時表的創建
沒有很多可用空間
- 在這些情況下，文件 ibtmp1 大大增加，很容易耗盡可用空間。這種情況每天發生幾次，並且必須重啟伺服器才能完全縮小 ibtmp1 表空間。使用不可收縮的文件可以輕松耗盡磁碟空間！
㈥ Mysql中什麼是存儲引擎
什麼是存儲引擎？
關系資料庫表是用於存儲和組織信息的數據結構，可以將表理解為由行和列組成的表格，類似於Excel的電子表格的形式。有的表簡單，有的表復雜，有的表根本不用來存儲任何長期的數據，有的表讀取時非常快，但是插入數據時去很差；而我們在實際開發過程中，就可能需要各種各樣的表，不同的表，就意味著存儲不同類型的數據，數據的處理上也會存在著差異，那麼。對於MySQL來說，它提供了很多種類型的存儲引擎，我們可以根據對數據處理的需求，選擇不同的存儲引擎，從而最大限度的利用MySQL強大的功能。這篇博文將總結和分析各個引擎的特點，以及適用場合，並不會糾結於更深層次的東西。我的學習方法是先學會用，懂得怎麼用，再去知道到底是如何能用的。下面就對MySQL支持的存儲引擎進行簡單的介紹。
MyISAM
在mysql客戶端中，使用以下命令可以查看MySQL支持的引擎。
復制代碼代碼如下:
show engines;
MyISAM表是獨立於操作系統的，這說明可以輕松地將其從Windows伺服器移植到Linux伺服器；每當我們建立一個MyISAM引擎的表時，就會在本地磁碟上建立三個文件，文件名就是表明。例如，我建立了一個MyISAM引擎的tb_Demo表，那麼就會生成以下三個文件：
1.tb_demo.frm，存儲表定義；
2.tb_demo.MYD，存儲數據；
3.tb_demo.MYI，存儲索引。
MyISAM表無法處理事務，這就意味著有事務處理需求的表，不能使用MyISAM存儲引擎。MyISAM存儲引擎特別適合在以下幾種情況下使用：
1.選擇密集型的表。MyISAM存儲引擎在篩選大量數據時非常迅速，這是它最突出的優點。
2.插入密集型的表。MyISAM的並發插入特性允許同時選擇和插入數據。例如：MyISAM存儲引擎很適合管理郵件或Web伺服器日誌數據。
InnoDB
InnoDB是一個健壯的事務型存儲引擎，這種存儲引擎已經被很多互聯網公司使用，為用戶操作非常大的數據存儲提供了一個強大的解決方案。我的電腦上安裝的MySQL 5.6.13版，InnoDB就是作為默認的存儲引擎。InnoDB還引入了行級鎖定和外鍵約束，在以下場合下，使用InnoDB是最理想的選擇：
1.更新密集的表。InnoDB存儲引擎特別適合處理多重並發的更新請求。
2.事務。InnoDB存儲引擎是支持事務的標准MySQL存儲引擎。
3.自動災難恢復。與其它存儲引擎不同，InnoDB表能夠自動從災難中恢復。
4.外鍵約束。MySQL支持外鍵的存儲引擎只有InnoDB。
5.支持自動增加列AUTO_INCREMENT屬性。
一般來說，如果需要事務支持，並且有較高的並發讀取頻率，InnoDB是不錯的選擇。
MEMORY
使用MySQL Memory存儲引擎的出發點是速度。為得到最快的響應時間，採用的邏輯存儲介質是系統內存。雖然在內存中存儲表數據確實會提供很高的性能，但當mysqld守護進程崩潰時，所有的Memory數據都會丟失。獲得速度的同時也帶來了一些缺陷。它要求存儲在Memory數據表裡的數據使用的是長度不變的格式，這意味著不能使用BLOB和TEXT這樣的長度可變的數據類型，VARCHAR是一種長度可變的類型，但因為它在MySQL內部當做長度固定不變的CHAR類型，所以可以使用。
一般在以下幾種情況下使用Memory存儲引擎：
1.目標數據較小，而且被非常頻繁地訪問。在內存中存放數據，所以會造成內存的使用，可以通過參數max_heap_table_size控制Memory表的大小，設置此參數，就可以限制Memory表的最大大小。
2.如果數據是臨時的，而且要求必須立即可用，那麼就可以存放在內存表中。
3.存儲在Memory表中的數據如果突然丟失，不會對應用服務產生實質的負面影響。
Memory同時支持散列索引和B樹索引。B樹索引的優於散列索引的是，可以使用部分查詢和通配查詢，也可以使用<、>和>=等操作符方便數據挖掘。散列索引進行「相等比較」非常快，但是對「范圍比較」的速度就慢多了，因此散列索引值適合使用在=和<>的操作符中，不適合在<或>操作符中，也同樣不適合用在order by子句中。
可以在表創建時利用USING子句指定要使用的版本。例如：
復制代碼代碼如下:
create table users
(
id smallint unsigned not null auto_increment,
username varchar(15) not null,
pwd varchar(15) not null,
index using hash (username),
primary key (id)
)engine=memory;
上述代碼創建了一個表，在username欄位上使用了HASH散列索引。下面的代碼就創建一個表，使用BTREE索引。
復制代碼代碼如下:
create table users
(
id smallint unsigned not null auto_increment,
username varchar(15) not null,
pwd varchar(15) not null,
index using btree (username),
primary key (id)
)engine=memory;
MERGE
MERGE存儲引擎是一組MyISAM表的組合，這些MyISAM表結構必須完全相同，盡管其使用不如其它引擎突出，但是在某些情況下非常有用。說白了，Merge表就是幾個相同MyISAM表的聚合器；Merge表中並沒有數據，對Merge類型的表可以進行查詢、更新、刪除操作，這些操作實際上是對內部的MyISAM表進行操作。Merge存儲引擎的使用場景。
對於伺服器日誌這種信息，一般常用的存儲策略是將數據分成很多表，每個名稱與特定的時間端相關。例如：可以用12個相同的表來存儲伺服器日誌數據，每個表用對應各個月份的名字來命名。當有必要基於所有12個日誌表的數據來生成報表，這意味著需要編寫並更新多表查詢，以反映這些表中的信息。與其編寫這些可能出現錯誤的查詢，不如將這些表合並起來使用一條查詢，之後再刪除Merge表，而不影響原來的數據，刪除Merge表只是刪除Merge表的定義，對內部的表沒有任何影響。
ARCHIVE
Archive是歸檔的意思，在歸檔之後很多的高級功能就不再支持了，僅僅支持最基本的插入和查詢兩種功能。在MySQL 5.5版以前，Archive是不支持索引，但是在MySQL 5.5以後的版本中就開始支持索引了。Archive擁有很好的壓縮機制，它使用zlib壓縮庫，在記錄被請求時會實時壓縮，所以它經常被用來當做倉庫使用。
存儲引擎的一些問題
1.如何查看伺服器有哪些存儲引擎可以使用？
為確定你的MySQL伺服器可以用哪些存儲引擎，執行如下命令：
復制代碼代碼如下:
show engines;
這個命令就能搞定了。
2.如何選擇合適的存儲引擎？
（1）選擇標准可以分為：
（2）是否需要支持事務；
（3）是否需要使用熱備；
（4）崩潰恢復：能否接受崩潰；
（5）是否需要外鍵支持；
然後按照標准，選擇對應的存儲引擎即可。
㈦ 資料庫該如何優化
資料庫優化可以從以下幾個方面進行：
1.結構層: web伺服器採用負載均衡伺服器,mysql伺服器採用主從復制,讀寫分離
2.儲存層: 採用合適的存儲引擎,採用三範式
3.設計層: 採用分區分表,索引,表的欄位採用合適的欄位屬性,適當的採用逆範式,開啟mysql緩存
4.sql語句層:結果一樣的情況下,採用效率高,速度快節省資源的sql語句執行
㈧ mysql 存儲過程執行太慢怎麼優化
1.當我們請求mysql伺服器的時候,MySQL前端會有一個監聽,請求到了之後,伺服器得到相關的SQL語句,執行之前(虛線部分為執行),還會做許可權的判斷
2.通過許可權之後,SQL就到MySQL內部,他會在查詢緩存中,看該SQL有沒有執行過,如果有查詢過,則把緩存結果返回,說明在MySQL內部,也有一個查詢緩存.但是這個查詢緩存,默認是不開啟的,這個查詢緩存,和我們的Hibernate，Mybatis的查詢緩存是一樣的,因為查詢緩存要求SQL和參數都要一樣,所以這個命中率是非常低的（沒什麼卵用的意思）。
3.如果我們沒有開啟查詢緩存,或者緩存中沒有找到對應的結果,那麼就到了解析器,解析器主要對SQL語法進行解析
4.解析結束後就變成一顆解析樹,這個解析樹其實在Hibernate裡面也是有的,大家回憶一下,在以前做過Hibernate項目的時候,是不是有個一個antlr.jar。這個就是專門做語法解析的工具.因為在Hibernate裡面有HQL，它就是通過這個工具轉換成SQL的,我們編程語言之所以有很多規范、語法,其實就是為了便於這個解析器解析,這個學過編譯原理的應該知道.
5.得到解析樹之後,不能馬上執行,這還需要對這棵樹進行預處理,也就是說,這棵樹,我沒有經過任何優化的樹,預處理器會這這棵樹進行一些預處理,比如常量放在什麼地方,如果有計算的東西,把計算的結果算出來等等...
6.預處理完畢之後,此時得到一棵比較規范的樹,這棵樹就是要拿去馬上做執行的樹,比起之前的那棵樹,這棵得到了一些優化
7.查詢優化器，是MySQL裡面最關鍵的東西,我們寫任何一條SQL,比如SELECT * FROM USER WHERE USERNAME = toby AND PASSWORD = 1,它會怎麼去執行?它是先執行username = toby還是password = 1?每一條SQL的執行順序查詢優化器就是根據MySQL對數據統計表的一些信息,比如索引,比如表一共有多少數據,MySQL都是有緩存起來的,在真正執行SQL之前,他會根據自己的這些數據,進行一個綜合的判定,判斷這一次在多種執行方式裡面,到底選哪一種執行方式,可能運行的最快.這一步是MySQL性能中,最關鍵的核心點,也是我們的優化原則.我們平時所講的優化SQL,其實說白了,就是想讓查詢優化器,按照我們的想法,幫我們選擇最優的執行方案,因為我們比MySQL更懂我們的數據.MySQL看數據,僅僅只是自己收集到的信息,這些信息可能是不準確的,MySQL根據這些信息選了一個它自認為最優的方案,但是這個方案可能和我們想像的不一樣.
8.這里的查詢執行計劃,也就是MySQL查詢中的執行計劃,比如要先執行username = toby還是password = 1
9.這個執行計劃會傳給查詢執行引擎,執行引擎選擇存儲引擎來執行這一份傳過來的計劃,到磁碟中的文件中去查詢,這個時候重點來了,影響這個查詢性能最根本的原因是什麼?就是硬碟的機械運動,也就是我們平時熟悉的IO,所以一條查詢語句是快還是慢,就是根據這個時間的IO來確定的.那怎麼執行IO又是什麼來確定的?就是傳過來的這一份執行計劃.(優化就是制定一個我們認為最快的執行方案,最節省IO,和執行最快)
10.如果開了查詢緩存,則返回結果給客戶端,並且查詢緩存也放一份。
㈨ Mysql Innodb存儲引擎 select count 太慢，怎麼優化
從 MySQL 5.7 開始，開發人員改變了 InnoDB 構建二級索引的方式，採用自下而上的方法，而不是早期版本中自上而下的方法了。在這篇文章中，我們將通過一個示例來說明如何構建 InnoDB 索引。最後，我將解釋如何通過為 innodb_fill_factor 設置更合適的值。
索引構建過程
在有數據的表上構建索引，InnoDB 中有以下幾個階段：1.讀取階段（從聚簇索引讀取並構建二級索引條目）2.合並排序階段3.插入階段（將排序記錄插入二級索引）在 5.6 版本之前，MySQL 通過一次插入一條記錄來構建二級索引。這是一種「自上而下」的方法。搜索插入位置從樹的根部（頂部）開始並達到葉頁（底部）。該記錄插入游標指向的葉頁上。在查找插入位置和進行業面拆分和合並方面開銷很大。從MySQL 5.7開始，添加索引期間的插入階段使用「排序索引構建」，也稱為「批量索引載入」。在這種方法中，索引是「自下而上」構建的。即葉頁（底部）首先構建，然後非葉級別直到根（頂部）。
示例
在這些情況下使用排序的索引構建：
ALTER TABLE t1 ADD INDEX（or CREATE INDEX）
ALTER TABLE t1 ADD FULLTEXT INDEX
ALTER TABLE t1 ADD COLUMN, ALGORITHM = INPLACE
OPIMIZE t1
對於最後兩個用例，ALTER 會創建一個中間表。中間表索引（主要和次要）使用「排序索引構建」構建。
在 0 級別創建頁，還要為此頁創建一個游標
使用 0 級別處的游標插入頁面，直到填滿
頁面填滿後，創建一個兄弟頁（不要插入到兄弟頁）
為當前的整頁創建節點指針（子頁中的最小鍵，子頁碼），並將節點指針插入上一級（父頁）
在較高級別，檢查游標是否已定位。如果沒有，請為該級別創建父頁和游標
在父頁插入節點指針
如果父頁已填滿，請重復步驟 3, 4, 5, 6
現在插入兄弟頁並使游標指向兄弟頁
在所有插入的末尾，每個級別的游標指向最右邊的頁。提交所有游標（意味著提交修改頁面的迷你事務，釋放所有鎖存器）
為簡單起見，上述演算法跳過了有關壓縮頁和 BLOB（外部存儲的 BLOB）處理的細節。
CREATE TABLE t1 (a INT PRIMARY KEY, b INT, c BLOB);
INSERT INTO t1 VALUES (1, 11, 'hello111');
INSERT INTO t1 VALUES (2, 22, 'hello222');
INSERT INTO t1 VALUES (3, 33, 'hello333');
INSERT INTO t1 VALUES (4, 44, 'hello444');
INSERT INTO t1 VALUES (5, 55, 'hello555');
INSERT INTO t1 VALUES (6, 66, 'hello666');
INSERT INTO t1 VALUES (7, 77, 'hello777');
INSERT INTO t1 VALUES (8, 88, 'hello888');
INSERT INTO t1 VALUES (9, 99, 'hello999');
INSERT INTO t1 VALUES (10, 1010, 'hello101010');
ALTER TABLE t1 ADD INDEX k1(b);
(11,1), (22,2), (33,3), (44,4), (55,5), (66,6), (77,7), (88,8), (99,9), (1010, 10)
讓我們從記錄 (11,1) 開始。
在 0 級別（葉級別）創建頁
創建一個到頁的游標
所有插入都將轉到此頁面，直到它填滿了
箭頭顯示游標當前指向的位置。它目前位於第 5 頁，下一個插入將轉到此頁面。
創建一個兄弟頁，頁碼 6
不要插入兄弟頁
在游標處提交頁面，即迷你事務提交，釋放鎖存器等
作為提交的一部分，創建節點指針並將其插入到 【當前級別 + 1】 的父頁面中（即在 1 級別）
節點指針的格式 (子頁面中的最小鍵,子頁碼) 。第 5 頁的最小鍵是 (11,1) 。在父級別插入記錄 ((11,1)，5)。
1 級別的父頁尚不存在，MySQL 創建頁碼 7 和指向頁碼 7 的游標。
將 ((11,1)，5) 插入第 7 頁
現在，返回到 0 級並創建從第 5 頁到第 6 頁的鏈接，反之亦然
0 級別的游標現在指向兄弟頁，頁碼為 6
將 (44,4) 插入第 6 頁
下一個插入 - (55,5) 和 (66,6) - 很簡單，它們轉到第 6 頁。
插入記錄 (77,7) 類似於 (44,4)，除了父頁面 （頁面編號 7） 已經存在並且它有兩個以上記錄的空間。首先將節點指針 ((44,4),8) 插入第 7 頁，然後將 (77,7) 記錄到同級 8 頁中。
插入記錄 (88,8) 和 (99,9) 很簡單，因為第 8 頁有兩個空閑插槽。
我們現在有了一個完整的 B+-tree 索引，它是自下至上構建的！
值 80 意味著 MySQL 使用了 80% 的頁空間填充，預留 20% 於未來的更新。如果 innodb_fill_factor=100 則沒有剩餘空間供未來插入二級索引。如果在添加索引後，期望表上有更多的 DML，則可能導致業面拆分並再次合並。在這種情況下，建議使用 80-90 之間的值。此變數還會影響使用 OPTIMIZE TABLE 和 ALTER TABLE DROP COLUMN, ALGOITHM=INPLACE 重新創建的索引。也不應該設置太低的值，例如低於 50。因為索引會佔用浪費更多的磁碟空間，值較低時，索引中的頁數較多，索引統計信息的采樣可能不是最佳的。優化器可以選擇具有次優統計信息的錯誤查詢計劃。
沒有頁面拆分（不包括壓縮表）和合並
沒有重復搜索插入位置
插入不會被重做記錄（頁分配除外），因此重做日誌子系統的壓力較小
ALTER 正在進行時，插入性能降低 Bug＃82940，但在後續版本中計劃修復。
演算法
通過自下而上的方式構建索引
為簡單起見，假設子頁和非子頁中允許的 最大記錄數為 3
InnoDB 將主鍵欄位追加到二級索引。二級索引 k1 的記錄格式為(b, a)。在排序階段完成後，記錄為：
初始插入階段
還有兩個空閑插槽，因此插入記錄 (22,2) 和 (33,3) 非常簡單
對於下一條記錄 (44,4)，頁碼 5 已滿（前面提到的假設最大記錄數為 3）。這就是步驟。
頁填充時的索引構建
下一個插入 (1010,10) 。將節點指針 ((77,7),8) 插入 1級別的父頁（頁碼 7）。
MySQL 在 0 級創建同級頁碼 9。將記錄 (1010,10) 插入第 9 頁並將游標更改為此頁面。
以此類推。在上面的示例中，資料庫在 0 級別提交到第 9 頁，在 1 級別提交到第 7 頁。
索引填充因子
全局變數 innodb_fill_factor 用於設置插入 B-tree 頁中的空間量。默認值為 100，表示使用整個業面（不包括頁眉）。聚簇索引具有 innodb_fill_factor=100 的免除項。 在這種情況下，聚簇索引也空間的 1 /16 保持空閑。即 6.25% 的空間用於未來的 DML。
排序索引構建的優點
缺點
㈩ MySQL資料庫性能優化有哪些技巧
1.存儲引擎的選擇如果數據表需要事務處理，應該考慮使用InnoDB，因為它完全符合ACID特性。如果不需要事務處理，使用默認存儲引擎MyISAM是比較明智的。並且不要嘗試同時使用這兩個存儲引擎。思考一下：在一個事務處理中，一些數據表使用InnoDB，而其餘的使用MyISAM.結果呢？整個subject將被取消，只有那些在事務處理中的被帶回到原始狀態，其餘的被提交的數據轉存，這將導致整個資料庫的沖突。然而存在一個簡單的方法可以同時利用兩個存儲引擎的優勢。目前大多數MySQL套件中包括InnoDB、編譯器和鏈表，但如果你選擇MyISAM，你仍然可以單獨下載InnoDB，並把它作為一個插件。很簡單的方法，不是嗎？
2.計數問題如果數據表採用的存儲引擎支持事務處理（如InnoDB），你就不應使用COUNT（*）計算數據表中的行數。這是因為在產品類資料庫使用COUNT（*），最多返回一個近似值，因為在某個特定時間，總有一些事務處理正在運行。如果使用COUNT（*）顯然會產生bug，出現這種錯誤結果。
3.反復測試查詢查詢最棘手的問題並不是無論怎樣小心總會出現錯誤，並導致bug出現。恰恰相反，問題是在大多數情況下bug出現時，應用程序或資料庫已經上線。的確不存在針對該問題切實可行的解決方法，除非將測試樣本在應用程序或資料庫上運行。任何資料庫查詢只有經過上千個記錄的大量樣本測試，才能被認可。
4.避免全表掃描通常情況下，如果MySQL（或者其他關系資料庫模型）需要在數據表中搜索或掃描任意特定記錄時，就會用到全表掃描。此外，通常最簡單的方法是使用索引表，以解決全表掃描引起的低效能問題。然而，正如我們在隨後的問題中看到的，這存在錯誤部分。
5.使用「EXPLAIN」進行查詢當需要調試時，EXPLAIN是一個很好的命令，下面將對EXPLAIN進行深入探討。