【導致sql執行慢的原因】：
mysql的慢查詢日誌是mysql提供的一種日誌記錄，它用來記錄在mysql中響應時間超過閥值的語句，具體指執行時間超過long_query_time值的sql，則會被記錄到慢查詢日誌中。long_query_time的預設值為10，意思是執行10s以上的語句。慢查詢日誌的相關引數如下所示：
通過mysql的慢查詢日誌，我們可以查詢出執行的次數多占用的時間長的sql、可以通過pt_query_disgest(一種mysql慢日誌分析工具)分析rows examine(mysql執行器需要檢查的行數)項去找出io大的sql以及發現未命中索引的sql，對於這些sql，都是我們優化的物件。
快取是解決這類問題的一把手。它既可以加快整個系統（並非資料庫系統，使用快取的時候並沒有去訪問資料庫）的訪問速度，也可以減少資料庫負載的壓力。而快取一般都是在查詢中使用，我們並不希望每一次的查詢都要去訪問資料庫。那麼我們的快取做到**呢？一般情況下版的系統都會存在服務層這一結構層次，而資料訪問層一般都只是對於資料庫的增刪改查的介面的定義，所以我們的快取就需要在服務層進行。
我們作為開發者，是能夠知道我們需要的資料的條數的，若已經知道結果只有一條的時候，一定要使用limit 1 ，這樣一來，mysql在查詢到一條資料之後，會立即停止搜尋，這會帶來效能上的提公升。
無論查詢什麼都是直接select *，然後再從結果中取想要的字段。這樣做的話，平白無故的給mysql帶來了不必要的負擔，因為從資料庫中讀出越多的資料，查詢就會變得越慢。所以，以後看到select * 的時候，想一下是否可以在這裡進行一些優化。
這個id最好是乙個int型別的，推薦使用unsigned，並將其設定為自動增加auto_increment。將varchar的字段作為主鍵的情況， 然後在資料量較大的時候，資料庫這個環節速度變得不是很友好，所以盡量不要使用varchar來當主鍵，它會使得效能出現下降。而且在某些情況下，id這個主鍵欄位是非常重要的。
實際上，enum儲存的是tinyint型別，但其顯示為字串。用這個欄位來作一些選項列表就變得很合適了。比如你有乙個字段，比如「性別」、「狀態」或「所屬部門」等，你知道這些欄位的值是固定且有限的，那麼可以考慮使用enum。對於性別這個字段，一般分為兩種，有可能還有保密這種情況，我們可以使用數字1、2、3來分別表示這三張情況，而對於這些數字含義的區分則是業務層的事情了。我們需要將一些繁瑣的需要計算的步驟全部放到業務層（或者說是服務層），因為系統的瓶頸在資料庫，我們不能將過多的計算過程壓到資料庫上面去。資料庫儲存的資料應該盡量簡單，但是，我們會在業務層結合具體的業務，對這些簡單的資料進行分析。
除非你有乙個很特別的原因要去使用null值，你應該總讓你的字段保持為not null。
myisam適合一些需要大量查詢的應用。但其對於大量寫操作並不是很好。因為它使用到的是表級鎖，所以在你更新的時候，整張表都會被鎖起來，試想一下，當你在更新某一行資料的時候，導致其他的行都無法被訪問，這會不會 很難受呢。另外，myisam對於select count(*)這類操作的計算時很快的。而至於innodb而言，對於一些小的應用，它會比myisam還慢。它支援的是行級鎖，於是寫操作較多的時候，它會更加優秀。它還支援一些更高階的應用，比如說：事務。
如果某個欄位你總要拿來做搜尋，那麼為它建立索引吧。但是，不要以為建立索引，就可以為所欲為。其中有一些常用的規則需要去遵循的。
mysql 調優 Mysql調優
表設計 1 禁止使用外來鍵 2 多表中的相同列，必須保證列定義一致 3 國內表預設使用innodb，表字符集預設使用gbk，國際預設使用utf8的表 4 表必須包含gmt create和gmt modified欄位，即表必須包含記錄建立時間和修改時間的字段 5 單錶一到兩年內資料量超過500w或資料...
mysql卡的調優思路 MySQL效能調優思路
1.mysql效能調優思路 如果一台伺服器出現長時間負載過高 週期性負載過大,或偶爾卡住如何來處理?是週期性的變化還是偶爾問題?是伺服器整體效能的問題,還是某單條語句的問題?具體到單條語句,這條語句是在等待上花的時間,還是查詢上花的時間?1.1.監測並觀察伺服器的狀態.觀察伺服器狀態,一般用如下2個...
mysql的引數調優和方法
一 tmp table size和max heap table size tmp table size 它規定了內部記憶體臨時表的最大值，每個執行緒都要分配。實際起限制作用的是tmp table size和max heap table size的最小值。如果記憶體臨時表超出了限制，mysql就會自動...