MySQL優化方法參考

1、

• 表的設計規範化（三範式）
• 添加索引（普通索引、主鍵索引、惟一索引、全文索引）
• 分表（水平分割、垂直分割）
• 讀寫分離（寫add、update、delete）
• 存儲過程
• 對mysql配置優化（配置最大併發數my.ini,調整緩存大小）
• Mysql硬件升級
• 定時刪除不須要的數據、定時碎片整理（myisam）

 

三範式：3NF:

反3NF：

 

SQL語句優化：

定位：慢查詢

1. 運行狀態查詢（運行時間、併發數、等show status ）
2. Show status like 'com_select'
3. show global status
4. show global status like 'slow_queries' 慢查詢次數

   如何定位慢查詢

    

 

索引優化：

Explain

 

數據庫的引擎：

碎片整理：optimiza table 表名

定時備份：mysqldump –uroot –proot temp D:/a.bak

定時：crontab 0 0 0 0 0 mybash.sh

 

讀寫分離：

主從複製：

 

2、

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

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

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越大，離散程度越高：

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

二、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是必須的，故該方案沒法執行，放棄!

三、分區

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. */ 

四、分表

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

分表分爲垂直拆分和水平拆分，一般以某個字段作拆分項。好比以id字段拆分爲100張表： 表名爲 tableName_id%100

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

五、分庫

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

方案二詳細說明：升級數據庫，換一個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，基本都是圖形界面操做。

 

 

 

轉載原博客連接：http://www.javashuo.com/article/p-ptlkhtur-k.html