轉載請注明：TheViper?http://www.cnblogs.com/TheViper

<>這本書寫的真的很好，只可惜本屌不才，大部分都看不懂，暫且記下與mysql優化有關，對自己有用的東西。

測試指標

吞吐量

吞吐量指的是單位時間內的事務處理數，單位tps(transaction per second).這一直是經典的數據庫應用測試的指標。

響應時間或延遲

這個指標用于測試任務所需的整體時間

并發性

注意，web服務器并發性不等同于數據庫的并發性。服務器的高并發一般也會導致數據庫的高并發，但服務器所用的語言，框架，工具集對此都會有影響。一個設計良好的應用，同時可以打開成千上百個數據庫服務器連接，但可能同時只有少數連接在執行查詢。因此，所需要關注的是正在工作中的并發操作，或者是同時工作中的線程數或連接數。

可擴展性

可擴展性指的是，給系統增加一倍的工作，理想情況下，會獲得兩倍的吞吐量，這時，看實際增加的吞吐量是多少。

性能優化的目標--響應時間

很多人認為性能優化就是降低cpu利用率。但這是個陷阱，資源就是用來消耗并用來工作的。所以，有時候消耗更多的資源能夠加快查詢速度。很多時候，升級到mysql新版本后，cpu利用率會上升的很厲害。這不代表性能出了問題。相反，說明新版本對資源的利用率上升了。

另外，如果把性能優化僅僅看出是提升每秒查詢量，這其實只是吞吐量優化。吞吐量的提升可以減少響應時間的副產品(倒數關系)。

優化數據類型

更小的通常更好

一般情況下，應該盡量使用可以正確存儲數據的最小數據類型。但是確保沒有低估需要存儲的值得范圍。

簡單就好

簡單數據類型的操作通常需要更少的cpu周期。例如，整型比字符操作代價更低，具體的。

1.應該使用mysql內建類型而不是字符串存儲日期和時間

2.應該用整型存儲ip地址。

盡量避免null

通常情況下，最好指定列為not null,除非真的需要存儲null值。如果查詢中包含可為null的列，對mysql來說會更難優化，因為可為null的列使得索引，索引計算和值比較更復雜。另外，可為null的列會使用更多的存儲空間。

下面具體說下數據類型

整數類型

有兩種類型的數字，整數和實數。如果存儲整數，可以使用這幾種整數類型：TINYINT,SMALLINT,MEDIUMINT,INT,BIGINT，對應8,16,24,32,64位存儲空間。

整數類型有UNSINGED屬性，表示不允許負數，這大致可以是整數的最大值上限提高一倍。

mysql可以為整數類型指定寬度，如INT(7),但對大多數應用這時沒意義的。它不會限制值的范圍。對于存儲來說，INT(1)和INT(10)是一樣的。

2.實數類型

實數是帶有小數部分的數字。但是，它們不僅可以用來儲存小數部分，還可以使用DECIMAL儲存比BIGINT還大的整數。

浮點類型在儲存同樣范圍的值時，通常比DECIMAL使用更少的空間。FLOAT使用4個字節儲存，DOUBLE使用8個字節儲存。mysql使用DOUBLE作為內部浮點計算的類型。

注意，在數據量比較大時，例如儲存財務數據，可以考慮使用BIGINT替代DECIMAL，將需要存儲的貨幣單位，根據小數的位數乘以相應的倍數即可。這樣可以同時避免浮點存儲不精確和DECIMAL精確計算代價高的問題。

3.字符串類型

VARCHAR：用于存儲可變長字符串。它比定長類型更節省空間，因為它僅使用必要的空間。

VARCHAR需要使用1或2個額外字節記錄字符串的長度。如果列的最大長度<=255字節，則使用1個字節表示，否則使用2個字節。

由于行是變長的，在update時可能會使行變得比原來長。下面情況下使用VARCHAR比較合適。

1.字符串列的最大長度比平均長度大很多

2.列的更新很少，不會出現碎片問題。

3.使用了想utf-8這樣復雜的字符集。

4.每個字符都使用不同的字節數進行存儲。

CHAR：定長，mysql總是根據定義的字符串長度分配足夠的空間。

在存儲時，mysql會刪除所有的末尾空格。CHAR適合存儲很短的字符串，或所有值都接近同一長度。

例如，CHAR適合存儲密碼的md5值，因為它是定長的。對于經常變更的數據，CHAR比VARCHAR更好，因為CHAR不容易產生碎片。

4.blob和text類型

兩者都是為存儲很大的數據而設計的字符串數據類型，分別采用二進制和字符方式存儲。

5.日期，時間類型

mysql能存儲的最小時間粒度為秒。

DATETIME:這個類型能保存大范圍的值，從1001年到9999年，精度為秒，它把日期和時間封裝到格式為YYYYMMDDHHMMSS的整數中，與時區無關，使用8個字節的存儲空間。

TIMESTAMP:這個類型保存了從1970年1月1日0時以來的秒數。它和unix時間戳相同。它使用4個字節儲存，因此范圍比DATETIME小很多，只能表示1970年到2038年。TIMESTAMP顯示的值與時區有關。

創建高性能的索引

索引可以包含一個或多個列的值。如果索引包含多個列，那列的順序十分重要，因為mysql只能高效的使用索引的最左前綴列。

最常見的B-Tree索引，按照順序存儲數據，所以mysql可以做order by和group by操作。因為數據是有序的，所以B-Tree也會將相關的列值都存儲在一起。最后，因為索引中存儲了實際的值，所以某些查詢只使用索引，就能夠完成全部查詢。

策略：

1.獨立的列：索引列不能是表達式的一部分，也不能是函數的參數。比如，

select id from a where id+1=5

select .... where TO_DAYS(CURRENT_DATE)-TO_DAYS(date_col)<=10

應該養成簡化where條件的習慣，始終將索引列單獨放在比較符號的一側。

2.前綴索引：索引開始的部分字符。

對于像BLOB,TEXT這種很長的列，必須使用前綴索引。因為mysql不允許索引這些列的完整長度。

因此建立前綴索引的關鍵是，選擇足夠長的前綴，以保證較高的選擇性，同時又不能太長。

前綴應該足夠長，以使得前綴索引的選擇性接近于索引整個列。為了找出這個足夠長度，需要找到最常見的值的列表，然后和最常見的前綴列表進行比較。例如

可以看到每個值都在45到65之間，區分度不好。下面取3個前綴字符

這次區分度就要好點了，下面繼續增加前綴長度，最后發現前綴長度為7時比較合適

計算合適前綴長度的另一個方法是計算完整列的選擇性，并使前綴的選擇性接近于完整列的選擇性，具體的

3.多列索引

一個常見的錯誤是，為每個列創建一個單獨的索引，或按照錯誤的順序創建多列索引。

關于索引列的順序，正確的順序依賴于使用該索引的查詢，同時還要考慮是否滿足排序和分組的需要。

一個經驗：將選擇性最高的列放在索引的最前列。這個經驗在不需要考慮排序和分組的時候效果很好。這時候索引的作用只是在優化where條件的查找。

事實上，性能不只是依賴于所有索引列的選擇性，也和查詢條件的具體值有關，也就是和值分布有關，這和前面說的選擇最佳前綴長度需要考慮的地方一樣。換句話說，可能需要根據那些運行頻率最高的查詢來調整索引列的順序。

使用索引掃描排序

mysql有兩種方式生成有序結果，通過排序操作或按索引順序掃描。如果explain出來的type列的值為index,說明使用了索引掃描做排序。

掃描索引本身是很快的，因為只需要從一條索引記錄移動到緊接的下一條記錄。但如果索引不能覆蓋查詢所需的全部列，那就不得不每掃描一條索引記錄就回表查詢一次對應的行。這基本上都是隨機的io.因此按索引順序讀取數據的速度通常比順序的全表掃描慢，尤其是在io密集型的工作負載中。

mysql可以使用同一個索引既滿足排序，又用于查找行。因此，如果可能，設計索引時應該盡可能的滿足這兩種任務最好。

只有當索引的順序和order by子句的順序完全一致，并且所有列的排列方向都一樣時，mysql才能使用索引對結果排序。

如果查詢需要關聯多張表，則只有當order by子句引用的字段全部為第一個表時，才能使用索引做排序。

order by子句和查找性查詢的限制是一樣的，需要滿足索引的最左前綴的要求，否則，mysql都需要執行排序操作。

有一種情況可以不滿足索引的最左前綴要求，依然可以使用索引排序。那就是當前導量為常數時。例如

在一個表上，建立索引(a,b,c)。

select ... where a=“2014-12-21” order by b,c.

這時索引的第一列被指定為常數，可以使用索引。下面的也可以使用索引

select ... where a>"2014-12-21" order by b

select ... where a>"2014-12-21" order by a,b

這兩個剛好用了索引的前綴，所以也可以。

下面是一些不能使用索引進行排序的查詢

select ... where a="2014-12-21" order by b DESC,c ESC

查詢使用了兩種不同的排序方向，但是索引列都是正序排序的。

select ... where a="2014-12-21" order by b，d

引用了一個不在索引中的列

select ... where a="2014-12-21" order by c

where和order by中的列無法組成索引的最左前綴，因為跳過了b這個列

select ... where a>"2014-12-21" order by b，c

第一列是范圍查詢

select ... where a>"2014-12-21" and b in(1,2) order by c

b列上有多個等于條件

總結

以上是生活随笔為你收集整理的高性能mysql看不懂_高性能mysql笔记1的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。