資料庫表表面上存在索引和防錯機制，然而乙個簡單的查詢就會耗費很長時間。
web應用程式或許在開發環境中執行良好，但在產品環境中表現同樣糟糕。如果你是個資料庫管理員，你很有可能已經在某個階段遇到上述情況。因此，本文將介紹對
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
進行深入**。
首先，建立乙個簡單的資料表：
**如下
:createtable'awesome_pcq'(
'emp_id'int(10)notnull
default'0',
'full_name'varchar(100)notnull,
'email_id'varchar(100)notnull,
'password'varchar(50)notnull,
'deleted'tinyint(4)notnull,
primarykey('emp_id')
) collate='utf8_general_ci'
engine=innodb
row_format=default
這個資料表一目了然，共有五列，最後一列「
deleted
」是乙個
boolean
類變數flag
來檢查帳號是活動的還是已被刪除。接下來，您需要用樣本記錄填充這個表
(比如，
100個雇員記錄
)。正如你看到的，主鍵是「
emp_id
」。因此，使用電子郵件位址和密碼字段，我們可以很容易地建立乙個查詢，以驗證或拒絕登入請求，如下
(例項一)：
**如下
:selectcount(*)fromawesome_pcqwhere
email_id='blahblah'andpassword='blahblah'anddeleted=0
之前我們提到，要避免使用
count(*)
。**糾正如下
(例項二)：
**如下
:selectemp_idfromawesome_pcqwhere
email_id='blahblah'andpassword='blahblah'anddeleted=0
現在回想一下，在例項一中，**查詢定位並返回「
email_id
」和「password
」等於給定值的行數。在例項二中，進行了同樣的查詢，不同的是明確要求列出「
emp_id
」所有滿足給定的標準的值。哪個查詢更費時
?很顯然，這兩個例項都是同樣費時的資料庫查詢，因為無意間，兩個例項查詢都進行了全表掃瞄。為了更好地讀懂指令，執行如下**：
**如下
:explainselectemp_idfromawesome_pcqwhere
email_id='blahblah'andpassword='blahblah'anddeleted=0
在輸出時，集中在倒數第二列：「
rows
」。假設我們已經將表填充了
100個記錄，它會在第一行顯示
100，這是
mysql
需要進行掃瞄用來計算查詢的結果的行數。這說明了什麼
?這需要全表掃瞄。為了克服這個弊端，則需要新增索引。
6.新增索引
先從重要的說起：給每乙個可能遇到的次要問題建立索引並不明智。過多的索引會導致效能減慢和資源占用。在進一步討論之前，在例項中建立乙個樣本索引：
**如下
:altertable'awesome_pcq'addindex'loginvalidate'('email_id')
接下來，再次執行該查詢：
**如下
:explainselectemp_idfromawesome_pcqwhere
email_id='blahblah'andpassword='blahblah'anddeleted=0
請注意執行後的值。不是
100，而是
1。因此，為了給出查詢結果，
mysql
只掃瞄了
1行，多虧先前建立的索引。你可能會注意到，索引只在電子郵件位址字段建立，而查詢對其他字段同樣進行了搜尋。這表明
mysql
先執行了乙個
cros-check
，檢查是否有在
where
子句中的定義的值有索引指定，如果有這樣的值就執行相應的操作。
但是，它不是每次重複將減少到乙個。例如，如果不是唯一的索引字段(如
employee names
列可以有兩行相同的值
)，即使建立索引，也將有多個記錄留下。但它仍然比全表掃瞄好。並且，在
where
子句中指定列的順序沒有在這個過程中發揮作用。例如，如果在上面的查詢中，改變欄位的順序，使電子郵件位址出現在最後，
mysql
仍將遍歷索引列的基礎上。那麼，就要在索引上動腦筋，注意如何避免大量的全表掃瞄，並獲得更好的結果。不過，這需要經歷乙個很長的過程。
效能優化 MySQL資料庫優化
可以從哪幾個方面進行資料庫的優化？如下圖所示 a sql及索引優化 根據需求寫出良好的sql，並建立有效的索引，實現某一種需求可以多種寫法，這時候我們就要選擇一種效率最高的寫法。這個時候就要了解sql優化 b 資料庫表結構優化 根據資料庫的正規化，設計表結構，表結構設計的好直接關係到寫sql語句。c...
資料庫效能優化 MySQL
序 即使有較長的快取有效期和較理想的快取命中率，但是快取的建立和快取過期後的重建都是需要訪問資料庫的。對資料庫寫操作不是很容易引入快取策略。11.1 檢視資料庫狀態 可以通過show status show innodb status 來檢視mysql資料庫的狀態，使用mysqlreport這個第三...
效能優化 mysql資料庫
一 mysql常用命令 1.開啟日誌 1 show global variables like genera 2 set global general log on 3 set global general log off 2.mysql如果開了set autocommit 0，那麼所有的語句一定是...