1.選擇正確的存儲引擎

以 MySQL為例，包括有兩個(gè)存儲引擎 MyISAM 和 InnoDB，每個(gè)引擎都有利有弊。

MyISAM 適合于一些需要大量查詢(xún)的應用。InnoDB 的趨勢會(huì )是一個(gè)非常復雜的存儲引擎，對于一些小的應用，它會(huì )比 MyISAM 還慢。但是它支持“行鎖” 。

2.優(yōu)化字段的數據類(lèi)型

記住一個(gè)原則，越小的列會(huì )越快。對于大多數的數據庫引擎來(lái)說(shuō)，硬盤(pán)操作可能是最重大的瓶頸。所以，把你的數據變得緊湊會(huì )對這種情況非常有幫助，因為這減少了對硬盤(pán)的訪(fǎng)問(wèn)。

如果一個(gè)表只會(huì )有幾列罷了（比如說(shuō)字典表，配置表），那么，我們就沒(méi)有理由使用 INT 來(lái)做主鍵，使用MEDIUMINT, SMALLINT 或是更小的 TINYINT 會(huì )更經(jīng)濟一些。如果你不需要記錄時(shí)間，使用 DATE 要比DATETIME 好得多。當然，你也需要留夠足夠的擴展空間。

3.為搜素字段添加索引

索引并不一定就是給主鍵或是唯一的字段。如果在你的表中，有某個(gè)字段你總要會(huì )經(jīng)常用來(lái)做搜索，那么最好是為其建立索引，除非你要搜索的字段是大的文本字段，那應該建立全文索引。

4.避免使用Select*

從數據庫里讀出越多的數據，那么查詢(xún)就會(huì )變得越慢。并且，如果你的數據庫服務(wù)器和WEB服務(wù)器是兩臺獨立的服務(wù)器的話(huà)，這還會(huì )增加網(wǎng)絡(luò )傳輸的負載。即使你要查詢(xún)數據表的所有字段，也盡量不要用*通配符，善用內置提供的字段排除定義也許能給帶來(lái)更多的便利。

5.使用ENUM而不是VARCHAR

ENUM 類(lèi)型是非?？旌途o湊的。在實(shí)際上，其保存的是 TINYINT，但其外表上顯示為字符串。這樣一來(lái)，用這個(gè)字段來(lái)做一些選項列表變得相當的完美。例如，性別、民族、部門(mén)和狀態(tài)之類(lèi)的這些字段的取值是有限而且固定的，那么，你應該使用 ENUM 而不是 VARCHAR。

6.盡可能使用NOT NULL

除非你有一個(gè)很特別的原因去使用 NULL 值，你應該總是讓你的字段保持 NOT NULL。 NULL其實(shí)需要額外的空間，并且，在你進(jìn)行比較的時(shí)候，你的程序會(huì )更復雜。 當然，這里并不是說(shuō)你就不能使用NULL了，現實(shí)情況是很復雜的，依然會(huì )有些情況下，你需要使用NULL值。

7.固定長(cháng)度的表會(huì )更快

如果表中的所有字段都是“固定長(cháng)度”的，整個(gè)表會(huì )被認為是 “static” 或 “fixed-length”。 例如，表中沒(méi)有如下類(lèi)型的字段： VARCHAR，TEXT，BLOB。只要你包括了其中一個(gè)這些字段，那么這個(gè)表就不是“固定長(cháng)度靜態(tài)表”了，這樣，MySQL 引擎會(huì )用另一種方法來(lái)處理。

固定長(cháng)度的表會(huì )提高性能，因為MySQL搜尋得會(huì )更快一些，因為這些固定的長(cháng)度是很容易計算下一個(gè)數據的偏移量的，所以讀取的自然也會(huì )很快。而如果字段不是定長(cháng)的，那么，每一次要找下一條的話(huà)，需要程序找到主鍵。

并且，固定長(cháng)度的表也更容易被緩存和重建。不過(guò)，唯一的副作用是，固定長(cháng)度的字段會(huì )浪費一些空間，因為定長(cháng)的字段無(wú)論你用不用，他都是要分配那么多的空間。

使用“垂直分割”技術(shù)，你可以分割你的表成為兩個(gè)一個(gè)是定長(cháng)的，一個(gè)則是不定長(cháng)的。

8.EXPLAIN里的SELECT查詢(xún)

使用 EXPLAIN 關(guān)鍵字可以讓你知道MySQL是如何處理你的SQL語(yǔ)句的。這可以幫你分析你的查詢(xún)語(yǔ)句或是表結構的性能瓶頸。EXPLAIN 的查詢(xún)結果還會(huì )告訴你你的索引主鍵被如何利用的，你的數據表是如何被搜索和排序的……等等

通常我們可以對比較復雜的尤其是涉及到多表的SELECT語(yǔ)句，把關(guān)鍵字EXPLAIN加到前面。你可以使用phpmyadmin來(lái)做這個(gè)事。