MYSQL優化優化再優化！

• 1.數據庫設計和表創建時就要考慮性能
• 2.sql的編寫需要注意優化
• 3.分區
• 4.分表
• 5.分庫

1、數據庫設計和表創建時就要考慮性能

mysql數據庫本身高度靈活，造成性能不足，嚴重依賴開發人員能力。也就是說開發人員能力高，則mysql性能高。這也是很多關系型數據庫的通病，所以公司的dba通常工資巨高。

設計表時要注意：

1. 表字段避免null值出現，null值很難查詢優化且占用額外的索引空間，推薦默認數字0代替null。
2. 盡量使用INT而非BIGINT，如果非負則加上UNSIGNED(這樣數值容量會擴大一倍)，當然能使用TINYINT、SMALLINT、MEDIUM_INT更好。
3. 使用枚舉或整數代替字符串類型
4. 盡量使用TIMESTAMP而非DATETIME
5. 單表不要有太多字段，建議在20以內
6. 用整型來存IP

索引

1. 索引並不是越多越好，要根據查詢有針對性的創建，考慮在WHERE和ORDER BY命令上涉及的列建立索引，可根據EXPLAIN來查看是否用了索引還是全表掃描
2. 應盡量避免在WHERE子句中對字段進行NULL值判斷，否則將導致引擎放棄使用索引而進行全表掃描
3. 值分布很稀少的字段不適合建索引，例如"性別"這種只有兩三個值的字段
4. 字符字段只建前綴索引
5. 字符字段最好不要做主鍵
6. 不用外鍵，由程序保證約束
7. 盡量不用UNIQUE，由程序保證約束
8. 使用多列索引時主意順序和查詢條件保持一致，同時刪除不必要的單列索引

簡言之就是使用合適的數據類型，選擇合適的索引

選擇合適的數據類型 (1)使用可存下數據的最小的數據類型，整型 < date,time < char,varchar < blob (2)使用簡單的數據類型，整型比字符處理開銷更小，因為字符串的比較更復雜。如，int類型存儲時間類型，bigint類型轉ip函數 (3)使用合理的字段屬性長度，固定長度的表會更快。使用enum、char而不是varchar (4)盡可能使用not null定義字段 (5)盡量少用text，非用不可最好分表 # 選擇合適的索引列 (1)查詢頻繁的列，在where，group by，order by，on從句中出現的列 (2)where條件中<，<=，=，>，>=，between，in，以及like 字符串+通配符(%)出現的列 (3)長度小的列，索引字段越小越好，因為數據庫的存儲單位是頁，一頁中能存下的數據越多越好 (4)離散度大(不同的值多)的列，放在聯合索引前面。查看離散度，通過統計不同的列值來實現，count越大，離散程度越高：

原開發人員已經跑路，該表早已建立，我無法修改，故：該措辭無法執行，放棄!

2、sql的編寫需要注意優化

1. 使用limit對查詢結果的記錄進行限定
2. 避免select *，將需要查找的字段列出來
3. 使用連接(join)來代替子查詢
4. 拆分大的delete或insert語句
5. 可通過開啟慢查詢日志來找出較慢的SQL
6. 不做列運算：SELECT id WHERE age + 1 = 10，任何對列的操作都將導致表掃描，它包括數據庫教程函數、計算表達式等等，查詢時要盡可能將操作移至等號右邊
7. sql語句盡可能簡單：一條sql只能在一個cpu運算;大語句拆小語句，減少鎖時間;一條大sql可以堵死整個庫
8. OR改寫成IN：OR的效率是n級別，IN的效率是log(n)級別，in的個數建議控制在200以內
9. 不用函數和觸發器，在應用程序實現
10. 避免%xxx式查詢
11. 少用JOIN
12. 使用同類型進行比較，比如用'123'和'123'比，123和123比
13. 盡量避免在WHERE子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描
14. 對於連續數值，使用BETWEEN不用IN：SELECT id FROM t WHERE num BETWEEN 1 AND 5
15. 列表數據不要拿全表，要使用LIMIT來分頁，每頁數量也不要太大

原開發人員已經跑路，程序已經完成上線，我無法修改sql，故：該措辭無法執行，放棄!

引擎

引擎

目前廣泛使用的是MyISAM和InnoDB兩種引擎：

MyISAM

MyISAM引擎是MySQL 5.1及之前版本的默認引擎，它的特點是：

1. 不支持行鎖，讀取時對需要讀到的所有表加鎖，寫入時則對表加排它鎖
2. 不支持事務
3. 不支持外鍵
4. 不支持崩潰后的安全恢復
5. 在表有讀取查詢的同時，支持往表中插入新紀錄
6. 支持BLOB和TEXT的前500個字符索引，支持全文索引
7. 支持延遲更新索引，極大提升寫入性能
8. 對於不會進行修改的表，支持壓縮表，極大減少磁盤空間占用

InnoDB

InnoDB在MySQL 5.5后成為默認索引，它的特點是：

1.支持行鎖，采用MVCC來支持高並發

2.支持事務

3.支持外鍵

4.支持崩潰后的安全恢復

5.不支持全文索引

總體來講，MyISAM適合SELECT密集型的表，而InnoDB適合INSERT和UPDATE密集型的表

MyISAM速度可能超快，占用存儲空間也小，但是程序要求事務支持，故InnoDB是必須的，故該方案無法執行，放棄!

3、分區

MySQL在5.1版引入的分區是一種簡單的水平拆分，用戶需要在建表的時候加上分區參數，對應用是透明的無需修改代碼

對用戶來說，分區表是一個獨立的邏輯表，但是底層由多個物理子表組成，實現分區的代碼實際上是通過對一組底層表的對象封裝，但對SQL層來說是一個完全封裝底層的黑盒子。MySQL實現分區的方式也意味着索引也是按照分區的子表定義，沒有全局索引

用戶的SQL語句是需要針對分區表做優化，SQL條件中要帶上分區條件的列，從而使查詢定位到少量的分區上，否則就會掃描全部分區，可以通過EXPLAIN PARTITIONS來查看某條SQL語句會落在那些分區上，從而進行SQL優化，我測試，查詢時不帶分區條件的列，也會提高速度，故該措施值得一試。

分區的好處是：

1. 可以讓單表存儲更多的數據
2. 分區表的數據更容易維護，可以通過清楚整個分區批量刪除大量數據，也可以增加新的分區來支持新插入的數據。另外，還可以對一個獨立分區進行優化、檢查、修復等操作
3. 部分查詢能夠從查詢條件確定只落在少數分區上，速度會很快
4. 分區表的數據還可以分布在不同的物理設備上，從而搞笑利用多個硬件設備
5. 可以使用分區表賴避免某些特殊瓶頸，例如InnoDB單個索引的互斥訪問、ext3文件系統的inode鎖競爭
6. 可以備份和恢復單個分區

分區的限制和缺點：

1. 一個表最多只能有1024個分區
2. 如果分區字段中有主鍵或者唯一索引的列，那么所有主鍵列和唯一索引列都必須包含進來
3. 分區表無法使用外鍵約束
4. NULL值會使分區過濾無效
5. 所有分區必須使用相同的存儲引擎

分區的類型：

1. RANGE分區：基於屬於一個給定連續區間的列值，把多行分配給分區
2. LIST分區：類似於按RANGE分區，區別在於LIST分區是基於列值匹配一個離散值集合中的某個值來進行選擇
3. HASH分區：基於用戶定義的表達式的返回值來進行選擇的分區，該表達式使用將要插入到表中的這些行的列值進行計算。這個函數可以包含MySQL中有效的、產生非負整數值的任何表達式
4. KEY分區：類似於按HASH分區，區別在於KEY分區只支持計算一列或多列，且MySQL服務器提供其自身的哈希函數。必須有一列或多列包含整數值
5. 具體關於mysql分區的概念請自行google或查詢官方文檔，我這里只是拋磚引玉了。

我首先根據月份把上網記錄表RANGE分區了12份，查詢效率提高6倍左右，效果不明顯，故：換id為HASH分區，分了64個分區，查詢速度提升顯著。問題解決!

結果如下：

1. PARTITION BY HASH (id)PARTITIONS 64 
2. select count() from readroom_website; --11901336行記錄  
3. / 受影響行數: 0 已找到記錄: 1 警告: 0 持續時間 1 查詢: 5.734 sec. /  
4. select * from readroom_website where month(accesstime) =11 limit 10;  
5. / 受影響行數: 0 已找到記錄: 10 警告: 0 持續時間 1 查詢: 0.719 sec. */ 

4、分表

分表就是把一張大表，按照如上過程都優化了，還是查詢卡死，那就把這個表分成多張表，把一次查詢分成多次查詢，然后把結果組合返回給用戶。

分表分為垂直拆分和水平拆分，通常以某個字段做拆分項。比如以id字段拆分為100張表： 表名為 tableName_id%100

但：分表需要修改源程序代碼，會給開發帶來大量工作，極大的增加了開發成本，故：只適合在開發初期就考慮到了大量數據存在，做好了分表處理，不適合應用上線了再做修改，成本太高!!!而且選擇這個方案，都不如選擇我提供的第二第三個方案的成本低!故不建議采用。

5、分庫

把一個數據庫分成多個，建議做個讀寫分離就行了，真正的做分庫也會帶來大量的開發成本，得不償失!不推薦使用。

方案二詳細說明：升級數據庫，換一個100%兼容mysql的數據庫

mysql性能不行，那就換個。為保證源程序代碼不修改，保證現有業務平穩遷移，故需要換一個100%兼容mysql的數據庫。

開源選擇

1. tiDB https://github.com/pingcap/tidb
2. Cubrid https://www.cubrid.org/
3. 開源數據庫會帶來大量的運維成本且其工業品質和MySQL尚有差距，有很多坑要踩，如果你公司要求必須自建數據庫，那么選擇該類型產品。

雲數據選擇

1. 阿里雲POLARDB
2. https://www.aliyun.com/product/polardb?spm=a2c4g.11174283.cloudEssentials.47.7a984b5cS7h4wH

官方介紹語：POLARDB 是阿里雲自研的下一代關系型分布式雲原生數據庫，100%兼容MySQL，存儲容量最高可達 100T，性能最高提升至 MySQL 的 6 倍。POLARDB 既融合了商業數據庫穩定、可靠、高性能的特征，又具有開源數據庫簡單、可擴展、持續迭代的優勢，而成本只需商用數據庫的 1/10。

我開通測試了一下，支持免費mysql的數據遷移，無操作成本，性能提升在10倍左右，價格跟rds相差不多，是個很好的備選解決方案!

1. 阿里雲OcenanBase
2. 淘寶使用的，扛得住雙十一，性能卓著，但是在公測中，我無法嘗試，但值得期待
3. 阿里雲HybridDB for MySQL (原PetaData)
4. https://www.aliyun.com/product/petadata?spm=a2c4g.11174283.cloudEssentials.54.7a984b5cS7h4wH

官方介紹：雲數據庫HybridDB for MySQL (原名PetaData)是同時支持海量數據在線事務(OLTP)和在線分析(OLAP)的HTAP(Hybrid Transaction/Analytical Processing)關系型數據庫。

我也測試了一下，是一個olap和oltp兼容的解決方案，但是價格太高，每小時高達10塊錢，用來做存儲太浪費了，適合存儲和分析一起用的業務。

1. 騰訊雲DCDB
2. https://cloud.tencent.com/product/dcdb_for_tdsql

官方介紹：DCDB又名TDSQL，一種兼容MySQL協議和語法，支持自動水平拆分的高性能分布式數據庫——即業務顯示為完整的邏輯表，數據卻均勻的拆分到多個分片中;每個分片默認采用主備架構，提供災備、恢復、監控、不停機擴容等全套解決方案，適用於TB或PB級的海量數據場景。

騰訊的我不喜歡用，不多說。原因是出了問題找不到人，線上問題無法解決頭疼!但是他價格便宜，適合超小公司，玩玩。

方案三詳細說明：去掉mysql，換大數據引擎處理數據

數據量過億了，沒得選了，只能上大數據了。

開源解決方案

hadoop家族。hbase/hive懟上就是了。但是有很高的運維成本，一般公司是玩不起的，沒十萬投入是不會有很好的產出的!

雲解決方案

這個就比較多了，也是一種未來趨勢，大數據由專業的公司提供專業的服務，小公司或個人購買服務，大數據就像水/電等公共設施一樣，存在於社會的方方面面。

國內做的最好的當屬阿里雲。

我選擇了阿里雲的MaxCompute配合DataWorks，使用超級舒服，按量付費，成本極低。

MaxCompute可以理解為開源的Hive，提供sql/mapreduce/ai算法/python腳本/shell腳本等方式操作數據，數據以表格的形式展現，以分布式方式存儲，采用定時任務和批處理的方式處理數據。DataWorks提供了一種工作流的方式管理你的數據處理任務和調度監控。

當然你也可以選擇阿里雲hbase等其他產品，我這里主要是離線處理，故選擇MaxCompute，基本都是圖形界面操作，大概寫了300行sql，費用不超過100塊錢就解決了數據處理問題

來自51cto.

 

文章來源：劉俊濤的博客

歡迎關注，有問題一起學習歡迎留言、評論