當使用MyISAM儲存引擎時，MySQL使用極快速的資料表鎖定，以便允許多次讀或一次寫。使用該儲存引擎的最大問題出現在同一個資料表中進行混合穩定數據流更新與慢速選擇。如果這只是某些資料表的問題，您可以使用另一個儲存引擎。參見第15章：儲存引擎和資料表類型。

MySQL可以使用事務資料表和非事務資料表。為了更容易地讓非事務資料表順利工作(如果出現問題不能回滾)，MySQL採用下述規則。請注意這些規則只適用於不運行在嚴格模式下或為INSERT或UPDATE使用IGNORE規定程式時。

·         所有列有預設值。請注意當運行在嚴格SQL模式(包括TRADITIONAL SQL模式)時，必須為NOT NULL列指定預設值。

·         如果向列內插入不合適的或超出範圍的值，MySQL將該列設定為「最好的可能的值」，而不是報告錯誤。對於數字值，為0、可能的最小值或最大值。對於字串，為空字串或列內可以保存的字串。請注意當運行在嚴格模式或TRADITIONAL SQL模式時該行為不 適用。

·         所有資料表達式的計算結果返回一個資料表示錯誤狀況的信號。例如，1/0返回NULL。(使用ERROR_FOR_DIVISION_BY_ZERO SQL模式可以更改該行為)。

如果正使用非事務資料表，不應該使用MySQL來檢查列的內容。一般情況，最安全的(通常是最快的)方法徑是讓應用程式確保只向資料庫傳遞合法值。

相關詳細訊息參見1.8.6節，「MySQL處理約束的方式」和13.2.4節，「INSERT語法」或5.3.2節，「SQL伺服器模式」。

因為不同SQL伺服器實現了標準SQL的不同部分，需要花功夫來編寫可移植的SQL應用程式。對很簡單的選擇/插入，很容易實現移植，但是需要的功能越多則越困難。如果想要應用程式對很多資料庫系統都快，它變得更難！

為了使一個複雜應用程式可移植，您需要選擇它應該工作的SQL伺服器，並確定這些伺服器支援什麼特性。

所有資料庫都有一些弱點。這就是它們不同的設計折衷導致的不同行為。

可以使用MySQL的crash-me程式來找出能用於資料庫伺服器選擇的函數、類型和限制。crash-me並不能找出所有的特性，但是其廣度仍然很合理，可以進行大約450個測試。

crash-me可以提供的一種類型的訊息的例子：如果想要使用Informix或DB2，不應該使用超過18個字元的列名。

crash-me程式和MySQL基準程式是獨立於資料庫的。通過觀察它們是如何編寫的，編可以知道必須為編寫獨立於資料庫的應用程式做什麼。基準本身可在MySQL原始碼分發的「sql-bench」目錄下找到。它們用DBI資料庫接口以Perl寫成。使用DBI本身即可以解決部分移植性問題，因為它提供與資料庫無關的的存取方法。

關於crash-me結果，訪問http://dev.mysql.com/tech-resources/crash-me.php。到http://dev.mysql.com/tech-resources/benchmarks/看這個基準的結果。

如果您為資料庫的獨立性而努力，需要很好地瞭解每個SQL伺服器的瓶頸。例如，MySQL在檢索和更新MyISAM資料表記錄方面很快，但是在同一個資料表上混合慢速讀者和寫者方面有一個問題。另一方面，當您試圖訪問最近更新了(直到它們被刷新到磁盤上)的行時，在Oracle中有一個很大的問題。事務資料庫總的來說在從記錄檔案資料表中生成總結資料表方面不是很好，因為在這種情況下，行鎖定幾乎沒有用。

為了使應用程式「確實」獨立於資料庫，需要定義一個容易延伸的接口，用它可操縱數據。因為C++在大多數系統上可以適用，使用資料庫的一個C++ 類接口是有意義的。

如果您使用某個資料庫特定的功能(例如MySQL專用的REPLACE語句)，應該為SQL伺服器編碼一個方法以實現同樣的功能。儘管慢些，但確允許其它伺服器執行同樣的任務。

用MySQL，可以使用/*! */語法把MySQL特定的關鍵詞加到查詢中。在/**/中的代碼將被其它大多數SQL伺服器視為註釋(並被忽略)。

如果高性能真的比準確性更重要，就像在一些web應用程式那樣，一種可行的方法是建立一個應用層，緩存所有的結果以便得到更高的性能。通過只是讓舊的結果在短時間後『過期』，能保持緩存合理地刷新。這在極高負載的情況下是相當不錯的，在此情況下，能動態地增加緩存並且設定較高的過期時限直到一切恢復正常。

在這種情況下，資料表建立訊息應該包含緩存初始大小和資料表刷新頻率等訊息。

實施應用程式緩存的一種方法是使用MySQL查詢緩存。啟用查詢緩存後，伺服器可以確定是否可以重新使用查詢結果。這樣簡化了您的應用程式。參見5.13節，「MySQL查詢高速緩衝」。

該節描述了Mysql的早期應用程式。

在MySQL最初開發期間，MySQL的功能適合大多數客戶。MySQL為瑞典的一些最大的零售商處理數據倉庫。

我們從所有商店得到所有紅利卡交易的每週總結，並且我們期望為所有店主提供有用的訊息以幫助他們得出他們的廣告戰如何影響他們的顧客。

數據是相當巨量的(大約每月7百萬宗交易總結)並且我們保存4-10年來的數據需要呈現給用戶。我們每週從顧客那裡得到請求，他們想要「立刻」訪問來自該數據的新報告。

我們通過每月將所有訊息儲存在壓縮的「交易」資料表中來解決它。我們有一套簡單的宏/指令用來生成來自交易資料表的不同條件( 產品組、顧客id，商店...)的總結資料表。報告是由一個進行語法分析網頁的小perl指令動態生成的網頁，在指令中執行SQL語句並且插入結果。我們很想使用PHP或mod_perl，但是那時它們還不可用。

對圖形數據，我們用C語言編寫了一個簡單的工具，它能基於那些結果處理SQL查詢結果並生成GIF圖形。該工具也從分析Web網頁的perl指令中動態地執行。

在大多數情況下，一個新的報告通過簡單地複製一個現有指令並且修改其中的SQL查詢來完成。在一些情況下，我們將需要把更多的列加到一個現有的總結資料表中或產生一個新的，但是這也相當簡單，因為我們在磁盤上保存所有交易資料表。（目前我們大約有50G的交易資料表和200G的其它顧客數據)。

我們也讓我們的顧客直接用ODBC訪問總結資料表以便高級用戶能自己用這些數據進行試驗。

該系統工作得很好，我們可以毫無問題地用很適度的Sun Ultra SPARC工作站硬件(2x200MHz)來處理數據。該系統被逐步移植到了Linux中。

本節應該包含MySQL基準套件(和crash-me)的技術描述，但是該描述還沒寫成。目前，您可以通過在MySQL原始碼分發中的「sql-bench」目錄下的代碼和結果瞭解基準套件是如何工作的。

通過基準用戶可以瞭解一個給定的SQL實現在哪方面執行得很好或很糟糕。

注意，這個基準是單線程的，它可以測量操作執行的最小時間。我們計劃將來在基準套件中新增多線程測試。

要使用基準套件，必須滿足下面的要求：

·         基準套件隨MySQL原始碼分發提供。可以從http://dev.mysql.com/downloads/下載分發，或者使用當前的開發原始碼樹(參見2.8.3節，「從開發原始碼樹安裝」)。

·         基準指令用Perl編寫而成，使用Perl DBI模塊訪問資料庫伺服器，因此必須安裝DBI。還需要為每個待測試的伺服器提供伺服器專用DBD驅動程式。例如，要測試MySQL、PostgreSQL和DB2，必須安裝DBD::mysql、DBD::Pg和DBD::DB2模塊。參見2.13節，「Perl安裝注意事項」。

獲得MySQL原始碼分發後，可以在sql-bench目錄找到基準套件。要運行基準測試，應構建MySQL，然後進入sql-bench目錄並執行run-all-tests指令：

shell> cd sql-bench

shell> perl run-all-tests --server=server_name

server_name是一個支援的伺服器。要獲得所有選項和支援的伺服器，使用命令：

shell> perl run-all-tests --help

crash-me指令也位於sql-bench目錄。crash-me嘗試通過實際運行查詢確定資料庫支援的特性以及其功能和限制。例如，它確定：

·         支援什麼列類型

·         支援多少索引

·         支援什麼函數

·         查詢可以多大

·         VARCHAR列可以多大

可以從http://dev.mysql.com/tech-resources/crash-me.php發現許多不同資料庫伺服器的crash-me的結果。關於基準測試結果的詳細訊息，訪問http://dev.mysql.com/tech-resources/benchmarks/。

一定要測試應用程式和資料庫，以發現瓶頸在哪兒。通過修正它(或通過用一個「啞模塊」代替瓶頸)，可以很容易地確定下一個瓶頸。即使您的應用程式的整體性能目前可以接受，至少應該對每個瓶頸做一個計劃，如果某天確實需要更好的性能，應知道如何解決它。

關於一些可移植的基準程式的例子，參見MySQL基準套件。請參見7.1.4節，「MySQL基準套件」。可以利用這個套件的任何程式並且根據您的需要修改它。通過這樣做，可以嘗試不同的問題的解決方案並測試哪一個是最好的解決方案。

另一個免費基準套件是開放原始碼資料庫基準套件，參見http://osdb.sourceforge.net/。

在系統負載繁重時出現一些問題是很普遍的，並且很多客戶已經與我們聯繫了，他們在生產系統中有一個(測試)系統並且有負載問題。大多數情況下，性能問題經證明是與基本資料庫設計有關的問題(例如，資料表掃瞄在高負載時資料表現不好)或作業系統或庫問題。如果系統已經不在生產系統中，它們大多數將很容易修正。

為了避免這樣的問題，應該把工作重點放在在可能最壞的負載下測試您的整個應用程式。您可以使用Super Smack。該工具可以從http://jeremy.zawodny.com/mysql/super-smack/獲得。正如它的名字所建議，它可以根據您的需要提供合理的系統，因此確保只用於您的開發系統。

mysql> SELECT BENCHMARK(1000000,1+1)；

+------------------------+

| BENCHMARK(1000000,1+1) |

+------------------------+

|                      0 |

+------------------------+

1 row in set (0.32 sec)

EXPLAIN tbl_name

或：

EXPLAIN [EXTENDED] SELECT select_options

EXPLAIN語句可以用作DESCRIBE的一個同義詞，或獲得關於MySQL如何執行SELECT語句的訊息：

·         EXPLAIN tbl_name是DESCRIBE tbl_name或SHOW COLUMNS FROM tbl_name的一個同義詞。

·         如果在SELECT語句前放上關鍵詞EXPLAIN，MySQL將解釋它如何處理SELECT，提供有關資料表如何聯接和聯接的次序。

該節解釋EXPLAIN的第2個用法。

借助於EXPLAIN，可以知道什麼時候必須為資料表加入索引以得到一個使用索引來尋找記錄的更快的SELECT。

如果由於使用不正確的索引出現了問題，應運行ANALYZE TABLE更新資料表的統計（例如關鍵字集的勢），這樣會影響最佳化器進行的選擇。參見13.5.2.1節，「ANALYZE TABLE語法」。

還可以知道最佳化器是否以一個最佳次序聯接資料表。為了強制最佳化器讓一個SELECT語句按照資料表命名順序的聯接次序，語句應以STRAIGHT_JOIN而不只是SELECT開頭。

EXPLAIN為用於SELECT語句中的每個資料表返回一行訊息。資料表以它們在處理查詢過程中將被MySQL讀入的順序被列出。MySQL用一遍掃瞄多次聯接（single-sweep multi-join）的方式解決所有聯接。這意味著MySQL從第一個資料表中讀一行，然後找到在第二個資料表中的一個匹配行，然後在第3個資料表中等等。當所有的資料表處理完後，它輸出選中的列並且返回資料表清單直到找到一個有更多的匹配行的資料表。從該資料表讀入下一行並繼續處理下一個資料表。

當使用EXTENDED關鍵字時，EXPLAIN產生附加訊息，可以用SHOW WARNINGS瀏覽。該訊息顯示最佳化器限定SELECT語句中的資料表和列名，重寫並且執行最佳化規則後SELECT語句是什麼樣子，並且還可能包括最佳化過程的其它註解。

EXPLAIN的每個輸出行提供一個資料表的相關訊息，並且每個行包括下面的列：

·         id

SELECT識別符。這是SELECT的查詢序列號。

·         select_type

SELECT類型，可以為以下任何一種：

o        SIMPLE

簡單SELECT(不使用UNION或子查詢)

o        PRIMARY

最外面的SELECT

o        UNION

UNION中的第二個或後面的SELECT語句

o        DEPENDENT UNION

UNION中的第二個或後面的SELECT語句，取決於外面的查詢

o        UNION RESULT

UNION的結果。

o        SUBQUERY

子查詢中的第一個SELECT

o        DEPENDENT SUBQUERY

子查詢中的第一個SELECT，取決於外面的查詢

o        DERIVED

導出資料表的SELECT(FROM子句的子查詢)

·         table

輸出的行所引用的資料表。

·         type

聯接類型。下面給出各種聯接類型，按照從最佳類型到最壞類型進行排序：

o        system

資料表僅有一行(=系統資料表)。這是const聯接類型的一個特例。

o        const

資料表最多有一個匹配行，它將在查詢開始時被讀取。因為僅有一行，在這行的列值可被最佳化器剩餘部分認為是常數。const資料表很快，因為它們只讀取一次！

const用於用常數值比較PRIMARY KEY或UNIQUE索引的所有部分時。在下面的查詢中，tbl_name可以用於const資料表：

SELECT * from tbl_name WHERE primary_key=1；

SELECT * from tbl_name

WHERE primary_key_part1=1和 primary_key_part2=2；

o        eq_ref

對於每個來自於前面的資料表的行組合，從該資料表中讀取一行。這可能是最好的聯接類型，除了const類型。它用在一個索引的所有部分被聯接使用並且索引是UNIQUE或PRIMARY KEY。

eq_ref可以用於使用= 操作符比較的帶索引的列。比較值可以為常量或一個使用在該資料表前面所讀取的資料表的列的資料表達式。

在下面的例子中，MySQL可以使用eq_ref聯接來處理ref_tables：

SELECT * FROM ref_table,other_table

  WHERE ref_table.key_column=other_table.column;

SELECT * FROM ref_table,other_table

  WHERE ref_table.key_column_part1=other_table.column

    AND ref_table.key_column_part2=1;

o        ref

對於每個來自於前面的資料表的行組合，所有有匹配索引值的行將從這張資料表中讀取。如果聯接只使用鍵的最左邊的前綴，或如果鍵不是UNIQUE或PRIMARY KEY（換句話說，如果聯接不能基於關鍵字選擇單個行的話），則使用ref。如果使用的鍵僅僅匹配少量行，該聯接類型是不錯的。

ref可以用於使用=或<=>操作符的帶索引的列。

在下面的例子中，MySQL可以使用ref聯接來處理ref_tables：

SELECT * FROM ref_table WHERE key_column=expr;

SELECT * FROM ref_table,other_table

  WHERE ref_table.key_column=other_table.column;

SELECT * FROM ref_table,other_table

  WHERE ref_table.key_column_part1=other_table.column

    AND ref_table.key_column_part2=1;

o        ref_or_null

該聯接類型如同ref，但是新增了MySQL可以專門搜索包含NULL值的行。在解決子查詢中經常使用該聯接類型的最佳化。

在下面的例子中，MySQL可以使用ref_or_null聯接來處理ref_tables：

SELECT * FROM ref_table

WHERE key_column=expr OR key_column IS NULL;

參見7.2.7節，「MySQL如何最佳化IS NULL」。

o        index_merge

該聯接類型資料表示使用了索引合併最佳化方法。在這種情況下，key列包含了使用的索引的清單，key_len包含了使用的索引的最長的關鍵元素。詳細訊息參見7.2.6節，「索引合併最佳化」。

o        unique_subquery

該類型替換了下面形式的IN子查詢的ref：

value IN (SELECT primary_key FROM single_table WHERE some_expr)

unique_subquery是一個索引搜尋函數，可以完全替換子查詢，效率更高。

o        index_subquery

該聯接類型類似於unique_subquery。可以替換IN子查詢，但只適合下列形式的子查詢中的非唯一索引：

value IN (SELECT key_column FROM single_table WHERE some_expr)

o        range

只檢索給定範圍的行，使用一個索引來選擇行。key列顯示使用了哪個索引。key_len包含所使用索引的最長關鍵元素。在該類型中ref列為NULL。

當使用=、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN或者IN操作符，用常量比較關鍵字列時，可以使用range：

SELECT * FROM tbl_name

WHERE key_column = 10;

SELECT * FROM tbl_name

WHERE key_column BETWEEN 10 and 20;

SELECT * FROM tbl_name

WHERE key_column IN (10,20,30);

SELECT * FROM tbl_name

WHERE key_part1= 10 AND key_part2 IN (10,20,30);

o        index

該聯接類型與ALL相同，除了只有索引樹被掃瞄。這通常比ALL快，因為索引檔案通常比數據檔案小。

當查詢只使用作為單索引一部分的列時，MySQL可以使用該聯接類型。

o        ALL

對於每個來自於先前的資料表的行組合，進行完整的資料表掃瞄。如果資料表是第一個沒標記const的資料表，這通常不好，並且通常在它情況下很差。通常可以增加更多的索引而不要使用ALL，使得行能基於前面的資料表中的常數值或列值被檢索出。

·         possible_keys

possible_keys列指出MySQL能使用哪個索引在該資料表中找到行。注意，該列完全獨立於EXPLAIN輸出所示的資料表的次序。這意味著在possible_keys中的某些鍵實際上不能按生成的資料表次序使用。

如果該列是NULL，則沒有相關的索引。在這種情況下，可以通過檢查WHERE子句看是否它引用某些列或適合索引的列來提高您的查詢性能。如果是這樣，創造一個適當的索引並且再次用EXPLAIN檢查查詢。參見13.1.2節，「ALTER TABLE語法」。

為了看清一張資料表有什麼索引，使用SHOW INDEX FROM tbl_name。

·         key

key列顯示MySQL實際決定使用的鍵（索引）。如果沒有選擇索引，鍵是NULL。要想強制MySQL使用或忽視possible_keys列中的索引，在查詢中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。參見13.2.7節，「SELECT語法」。

對於MyISAM和BDB資料表，運行ANALYZE TABLE可以幫助最佳化器選擇更好的索引。對於MyISAM資料表，可以使用myisamchk --analyze。參見13.5.2.1節，「ANALYZE TABLE語法」和5.9.4節，「資料表維護和崩潰恢復」。

·         key_len

key_len列顯示MySQL決定使用的鍵長度。如果鍵是NULL，則長度為NULL。注意通過key_len值我們可以確定MySQL將實際使用一個多部關鍵字的幾個部分。

·         ref

ref列顯示使用哪個列或常數與key一起從資料表中選擇行。

·         rows

rows列顯示MySQL認為它執行查詢時必須檢查的行數。

·         Extra

該列包含MySQL解決查詢的詳細訊息。下面解釋了該列可以顯示的不同的文本字串：

o        Distinct

MySQL發現第1個匹配行後，停止為當前的行組合搜索更多的行。

o        Not exists

MySQL能夠對查詢進行LEFT JOIN最佳化，發現1個匹配LEFT JOIN標準的行後，不再為前面的的行組合在該資料表內檢查更多的行。

下面是一個可以這樣最佳化的查詢類型的例子：

SELECT * 從t1 LEFT JOIN t2 ON t1.id=t2.id

  WHERE t2.id IS NULL；

假定t2.id定義為NOT NULL。在這種情況下，MySQL使用t1.id的值掃瞄t1並搜尋t2中的行。如果MySQL在t2中發現一個匹配的行，它知道t2.id絕不會為NULL，並且不再掃瞄t2內有相同的id值的行。換句話說，對於t1的每個行，MySQL只需要在t2中搜尋一次，無論t2內實際有多少匹配的行。

o        range checked for each record (index map: #)

MySQL沒有發現好的可以使用的索引，但發現如果來自前面的資料表的列值已知，可能部分索引可以使用。對前面的資料表的每個行組合，MySQL檢查是否可以使用range或index_merge訪問方法來索取行。關於適用性標準的描述參見7.2.5節，「範圍最佳化」和7.2.6節，「索引合併最佳化」，不同的是前面資料表的所有列值已知並且認為是常量。

這並不很快，但比執行沒有索引的聯接要快得多。

o        Using filesort

MySQL需要額外的一次傳遞，以找出如何按排序順序檢索行。通過根據聯接類型瀏覽所有行並為所有匹配WHERE子句的行保存排序關鍵字和行的指針來完成排序。然後關鍵字被排序，並按排序順序檢索行。參見7.2.12節，「MySQL如何最佳化ORDER BY」。

o        Using index

從只使用索引樹中的訊息而不需要進一步搜索讀取實際的行來檢索資料表中的列訊息。當查詢只使用作為單一索引一部分的列時，可以使用該策略。

o        Using temporary

為了解決查詢，MySQL需要建立一個臨時資料表來容納結果。典型情況如查詢包含可以按不同情況列出列的GROUP BY和ORDER BY子句時。

o        Using where

WHERE子句用於限制哪一個行匹配下一個資料表或發送到客戶。除非您專門從資料表中索取或檢查所有行，如果Extra值不為Using where並且資料表聯接類型為ALL或index，查詢可能會有一些錯誤。

如果想要使查詢盡可能快，應找出Using filesort 和Using temporary的Extra值。

o        Using sort_union(...), Using union(...), Using intersect(...)

這些函數說明如何為index_merge聯接類型合併索引掃瞄。詳細訊息參見7.2.6節，「索引合併最佳化」。

o        Using index for group-by

類似於訪問資料表的Using index方式，Using index for group-by資料表示MySQL發現了一個索引，可以用來查詢GROUP BY或DISTINCT查詢的所有列，而不要額外搜索硬盤訪問實際的資料表。並且，按最有效的方式使用索引，以便對於每個組，只讀取少量索引條目。詳情參見7.2.13節，「MySQL如何最佳化GROUP BY」。

通過相乘EXPLAIN輸出的rows列的所有值，您能得到一個關於一個聯接如何的提示。這應該粗略地告訴您MySQL必須檢查多少行以執行查詢。當您使用max_join_size變數限制查詢時，也用這個乘積來確定執行哪個多資料表SELECT語句。參見7.5.2節，「調節伺服器參數」。

下列例子顯示出一個多資料表JOIN如何能使用EXPLAIN提供的訊息逐步被最佳化。

假定您有下面所示的SELECT語句，計劃使用EXPLAIN來檢查它：

EXPLAIN SELECT tt.TicketNumber, tt.TimeIn,

               tt.ProjectReference, tt.EstimatedShipDate,

               tt.ActualShipDate, tt.ClientID,

               tt.ServiceCodes, tt.RepetitiveID,

               tt.CurrentProcess, tt.CurrentDPPerson,

               tt.RecordVolume, tt.DPPrinted, et.COUNTRY,

               et_1.COUNTRY, do.CUSTNAME

        FROM tt, et, et AS et_1, do

        WHERE tt.SubmitTime IS NULL

          AND tt.ActualPC = et.EMPLOYID

          AND tt.AssignedPC = et_1.EMPLOYID

          AND tt.ClientID = do.CUSTNMBR;

對於這個例子，假定：

·         被比較的列聲明如下：

·         資料表有下面的索引：

·         tt.ActualPC值不是均勻分佈的。

開始，在進行最佳化前，EXPLAIN語句產生下列訊息：

table type possible_keys key  key_len ref  rows  Extra

et    ALL  PRIMARY       NULL NULL    NULL 74

do    ALL  PRIMARY       NULL NULL    NULL 2135

et_1  ALL  PRIMARY       NULL NULL    NULL 74

tt    ALL  AssignedPC,   NULL NULL    NULL 3872

           ClientID,

           ActualPC

      range checked for each record (key map: 35)

因為type對每張資料表是ALL，這個輸出顯示MySQL正在對所有資料表產生一個笛卡爾乘積；即每一個行的組合！這將花相當長的時間，因為必須檢查每張資料表的行數的乘積！對於一個實例，這是74 * 2135 * 74 * 3872 = 45,268,558,720行。如果資料表更大，您只能想像它將花多長時間……

這裡的一個問題是MySQL能更高效地在聲明具有相同類型和尺寸的列上使用索引。在本文中，VARCHAR和CHAR是相同的，除非它們聲明為不同的長度。因為tt.ActualPC被聲明為CHAR(10)並且et.EMPLOYID被聲明為CHAR(15)，長度不匹配。

為了修正在列長度上的不同，使用ALTER TABLE將ActualPC的長度從10個字元變為15個字元：

mysql> ALTER TABLE tt MODIFY ActualPC VARCHAR(15);

現在tt.ActualPC和et.EMPLOYID都是VARCHAR(15)，再執行EXPLAIN語句產生這個結果：

table type   possible_keys key     key_len ref         rows    Extra

tt    ALL    AssignedPC,   NULL    NULL    NULL        3872    Using

             ClientID,                                         where

             ActualPC

do    ALL    PRIMARY       NULL    NULL    NULL        2135

      range checked for each record (key map: 1)

et_1  ALL    PRIMARY       NULL    NULL    NULL        74

      range checked for each record (key map: 1)

et    eq_ref PRIMARY       PRIMARY 15      tt.ActualPC 1

這不是完美的，但是好一些了：rows值的乘積少了一個因子74。這個版本在幾秒內執行完。

第2種方法能消除tt.AssignedPC = et_1.EMPLOYID和tt.ClientID = do.CUSTNMBR比較的列的長度失配問題：

mysql> ALTER TABLE tt MODIFY AssignedPC VARCHAR(15),

    ->                MODIFY ClientID   VARCHAR(15);

EXPLAIN產生的輸出顯示在下面：

table type   possible_keys key      key_len ref           rows Extra

et    ALL    PRIMARY       NULL     NULL    NULL          74

tt    ref    AssignedPC,   ActualPC 15      et.EMPLOYID   52   Using

             ClientID,                                         where

             ActualPC

et_1  eq_ref PRIMARY       PRIMARY  15      tt.AssignedPC 1

do    eq_ref PRIMARY       PRIMARY  15      tt.ClientID   1

這幾乎很好了。

剩下的問題是，預設情況，MySQL假設在tt.ActualPC列的值是均勻分佈的，並且對tt資料表不是這樣。幸好，很容易告訴MySQL來分析關鍵字分佈：

mysql> ANALYZE TABLE tt；

現在聯接是「完美」的了，而且EXPLAIN產生這個結果：

table type   possible_keys key     key_len ref           rows Extra

tt    ALL    AssignedPC    NULL    NULL    NULL          3872 Using

             ClientID,                                        where

             ActualPC

et    eq_ref PRIMARY       PRIMARY 15      tt.ActualPC   1

et_1  eq_ref PRIMARY       PRIMARY 15      tt.AssignedPC 1

do    eq_ref PRIMARY       PRIMARY 15      tt.ClientID   1

注意在從EXPLAIN輸出的rows列是一個來自MySQL聯接最佳化器的「教育猜測」。您應該檢查數字是否接近事實。如果不是，可以通過在SELECT語句裡面使用STRAIGHT_JOIN並且試著在FROM子句以不同的次序列出資料表，可能得到更好的性能。

在大多數情況下，可以通過計算磁盤搜索來估計性能。對小的資料表，通常能在1次磁盤搜索中找到行(因為索引可能被緩存)。對更大的資料表，可以使用B－樹索引進行估計，將需要log(row_count)/log(index_block_length/3 * 2/(index_length + data_pointer_length))+1次搜索才能找到行。

在MySQL中，索引塊通常是1024個字節，數據指針通常是4個字節，這對於有一個長度為3(中等整數)的索引的500,000行的資料表，通過公式可以計算出log(500,000)/log(1024/3*2/(3+4))+1= 4次搜索。

上面的索引需要大約500,000 * 7 * 3/2 = 5.2MB，(假設典型情況下索引緩存區填充率為2/3)，可以將大部分索引保存在內存中，僅需要1-2使用從OS讀數據來找出行。

然而對於寫，將需要4次搜索請求(如上)來找到在哪兒存放新索引，並且通常需要2次搜索來更新這個索引並且寫入行。

注意，上述討論並不意味著應用程式的性能將緩慢地以logN 退化！當資料表格變得更大時，所有內容緩存到OS或SQL伺服器後，將僅僅或多或少地更慢。在數據變得太大不能緩存後，將逐漸變得更慢，直到應用程式只能進行磁盤搜索(以logN增加)。為了避免這個問題，隨數據增加而增加 鍵高速緩衝區大小。對於MyISAM資料表, 由key_buffer_size系統變數控制 鍵高速緩衝區大小。參見7.5.2節，「調節伺服器參數」。

總的來說，要想使一個較慢速SELECT ... WHERE更快，應首先檢查是否能增加一個索引。不同資料表之間的引用通常通過索引來完成。您可以使用EXPLAIN語句來確定SELECT語句使用哪些索引。參見7.4.5節，「MySQL如何使用索引」和7.2.1節，「EXPLAIN語法（獲取關於SELECT的訊息）」。

下面是一些加速對MyISAM資料表的查詢的一般建議：

·         為了幫助MySQL更好地最佳化查詢，在一個裝載數據後的資料表上運行ANALYZE TABLE或myisamchk --analyze。這樣為每一個索引更新指出有相同值的行的平均行數的值（當然，如果只有一個索引，這總是1。）MySQL使用該方法來決定當您聯接兩個基於非常量資料表達式的資料表時選擇哪個索引。您可以使用SHOW INDEX FROM tbl_name並檢查Cardinality值來檢查資料表分析結果。myisamchk --description --verbose可以顯示索引分佈訊息。

·         要想根據一個索引排序一個索引和數據，使用myisamchk --sort-index --sort-records=1（如果您想要在索引1上排序）。如果只有一個索引，想要根據該索引的次序讀取所有的記錄，這是使查詢更快的一個好方法。但是請注意，第一次對一個大資料表按照這種方法排序時將花很長時間！

SELECT * FROM tbl_name WHERE key_col IS NULL;

SELECT * FROM tbl_name WHERE key_col <=> NULL;

SELECT * FROM tbl_name

    WHERE key_col=const1 OR key_col=const2 OR key_col IS NULL;

SELECT * FROM t1 WHERE t1.a=expr OR t1.a IS NULL;

SELECT * FROM t1, t2 WHERE t1.a=t2.a OR t2.a IS NULL;

SELECT * FROM t1, t2

    WHERE (t1.a=t2.a OR t2.a IS NULL) AND t2.b=t1.b;

SELECT * FROM t1, t2

    WHERE t1.a=t2.a AND (t2.b=t1.b OR t2.b IS NULL);

SELECT * FROM t1, t2

    WHERE (t1.a=t2.a AND t2.a IS NULL AND ...)

    OR (t1.a=t2.a AND t2.a IS NULL AND ...);

SELECT * FROM t1, t2

     WHERE (t1.a=t2.a AND t2.a IS NULL)

     OR (t1.b=t2.b AND t2.b IS NULL);

在許多情況下結合ORDER BY的DISTINCT需要一個臨時資料表。

請注意因為DISTINCT可能使用GROUP BY，必須清楚MySQL如何使用所選定列的一部分的ORDER BY或HAVING子句中的列。參見12.10.3節，「具有隱含字段的GROUP BY」。

在大多數情況下，DISTINCT子句可以視為GROUP BY的特殊情況。例如，下面的兩個查詢是等效的：

SELECT DISTINCT c1, c2, c3 FROM t1 WHERE c1 > const;

SELECT c1, c2, c3 FROM t1 WHERE c1 > const GROUP BY c1, c2, c3;

由於這個等效性，適用於GROUP BY查詢的最佳化也適用於有DISTINCT子句的查詢。這樣，關於DISTINCT查詢的最佳化的更詳細的情況，參見7.2.13節，「MySQL如何最佳化GROUP BY」。

結合LIMIT row_count和DISTINCT後，MySQL發現唯一的row_count行後立即停止。

如果不使用查詢中命名的所有資料表的列，MySQL發現第1個匹配後立即停止掃瞄未使用的資料表。在下面的情況中，假定t1在t2之前使用(可以用EXPLAIN檢查)，發現t2中的第1行後，MySQL不再(為t1中的任何行)讀t2：

SELECT DISTINCT t1.a FROM t1, t2 where t1.a=t2.a;

SELECT *

    FROM a,b LEFT JOIN c ON (c.key=a.key) LEFT JOIN d ON (d.key=a.key)

    WHERE b.key=d.key;

SELECT *

    FROM b,a LEFT JOIN c ON (c.key=a.key) LEFT JOIN d ON (d.key=a.key)

    WHERE b.key=d.key;

SELECT * FROM t1 LEFT JOIN t2 ON (column1) WHERE t2.column2=5;

SELECT * FROM t1, t2 WHERE t2.column2=5 AND t1.column1=t2.column1;

資料表示聯接的語法允許嵌套聯接。下面的討論引用了13.2.7.1節，「JOIN語法」中描述的聯接語法。

同SQL標準比較，table_factor語法已經延伸了。後者只接受table_reference，而不是括號內所列的。

table_reference項列資料表內的每個逗號等價於內部聯接，這是一個保留延伸名。例如：

SELECT * FROM t1 LEFT JOIN (t2, t3, t4)

                 ON (t2.a=t1.a AND t3.b=t1.b AND t4.c=t1.c)

等價於：

SELECT * FROM t1 LEFT JOIN (t2 CROSS JOIN t3 CROSS JOIN t4)

                 ON (t2.a=t1.a AND t3.b=t1.b AND t4.c=t1.c)

在MySQL中，CROSS JOIN語法上等價於INNER JOIN (它們可以彼此代替。在標準SQL中，它們不等價。INNER JOIN結合ON子句使用；CROSS JOIN 用於其它地方。

總的來說，在只包含內部聯接操作的聯接資料表達式中可以忽略括號。刪除括號並將操作組合到左側後，聯接資料表達式：

t1 LEFT JOIN (t2 LEFT JOIN t3 ON t2.b=t3.b OR t2.b IS NULL)

   ON t1.a=t2.a

轉換為資料表達式：

(t1 LEFT JOIN t2 ON t1.a=t2.a) LEFT JOIN t3

    ON t2.b=t3.b OR t2.b IS NULL

但是這兩個資料表達式不等效。要說明這點，假定資料表t1、t2和t3有下面的狀態：

·         資料表t1包含行{1}、{2}

·         資料表t2包含行{1,101}

·         資料表t3包含行{101}

在這種情況下，第1個資料表達式返回包括行{1,1,101,101}、{2,NULL,NULL,NULL}的結果，第2個資料表達式返回行{1,1,101,101}、{2,NULL,NULL,101}：

mysql> SELECT *

    -> FROM t1

    ->      LEFT JOIN

    ->      (t2 LEFT JOIN t3 ON t2.b=t3.b OR t2.b IS NULL)

    ->      ON t1.a=t2.a;

+------+------+------+------+

| a    | a    | b    | b    |

+------+------+------+------+

|    1 |    1 |  101 |  101 |

|    2 | NULL | NULL | NULL |

+------+------+------+------+

mysql> SELECT *

    -> FROM (t1 LEFT JOIN t2 ON t1.a=t2.a)

    ->      LEFT JOIN t3

    ->      ON t2.b=t3.b OR t2.b IS NULL;

+------+------+------+------+

| a    | a    | b    | b    |

+------+------+------+------+

|    1 |    1 |  101 |  101 |

|    2 | NULL | NULL |  101 |

+------+------+------+------+

在下面的例子中，外面的聯接操作結合內部聯接操作使用：

t1 LEFT JOIN (t2，t3) ON t1.a=t2.a

該資料表達式不能轉換為下面的資料表達式：

t1 LEFT JOIN t2 ON t1.a=t2.a，t3.

對於給定的資料表狀態，第1個資料表達式返回行{1,1,101,101}、{2,NULL,NULL,NULL}，第2個資料表達式返回行{1,1,101,101}、{2,NULL,NULL,101}：

mysql> SELECT *

    -> FROM t1 LEFT JOIN (t2, t3) ON t1.a=t2.a;

+------+------+------+------+

| a    | a    | b    | b    |

+------+------+------+------+

|    1 |    1 |  101 |  101 |

|    2 | NULL | NULL | NULL |

+------+------+------+------+

mysql> SELECT *

    -> FROM t1 LEFT JOIN t2 ON t1.a=t2.a, t3;

+------+------+------+------+

| a    | a    | b    | b    |

+------+------+------+------+

|    1 |    1 |  101 |  101 |

|    2 | NULL | NULL |  101 |

+------+------+------+------+

因此，如果我們忽略聯接資料表達式中的括號連同外面的聯接操作符，我們會改變原資料表達式的結果。

更確切地說，我們不能忽視左外聯接操作的右操作數和右聯接操作的左操作數中的括號。換句話說，我們不能忽視外聯接操作中的內資料表達式中的括號。可以忽視其它操作數中的括號(外部資料表的操作數)。

對於任何資料表t1、t2、t3和屬性t2.b和t3.b的任何條件P，下�