[sql]大型網站MySQL深度優化揭祕

大型網站MySQL深度優化揭祕

第1章優化的思路和線路html

1.1 網站優化的思路    2前端

1.2 MySQL優化,nginx這樣的東西怎麼優化? mysql

第2章硬件層面優化 nginx

2.1 數據庫物理機  web

2.1.1 CPU redis

2.1.2 Memory 算法

2.1.3 disk(磁盤IO) sql

2.1.4 RAID陣列 數據庫

2.1.5 網卡 api

2.1.6 案例  

2.2 硬件調整

2.2.1 BIOS調整提升CPU性能

2.2.2 陣列卡調整

第3章軟件層面優化

3.1 操做系統 

3.2 文件系統層優化 

3.3 內核層面優化

第4章 MySQL層面優化 

4.1 my.cnf參數的優化 

4.2 庫和表的設計優化 

4.3 SQL語句的優化 

4.3.1 抓出來慢查詢 

4.3.2 天天生成slow.log 

4.3.3 儘可能不用子查詢,用join替代 

第5章網站集羣架構上來優化數據庫 

5.1 服務器跑多實例2-4個 

5.2 業務拆分: 

5.3 數據庫前端加緩存 

5.4 備份策略 

第6章流程制度安全 

大型網站MySQL深度優化揭祕

優化的思路和線路

網站優化的思路

解答:從用戶打開瀏覽器,到返回網頁內容這個過程優化每個細節

MySQL優化,nginx這樣的東西怎麼優化?

建議:根據OSI 7層模型,從下到上。。。以這個爲線路

硬件層面優化

數據庫物理機

CPU

64位的CPU,服務器2-16,CPU 通常2-4顆 L1,L2越大越好

Memory

48G-96G-128G-256G

48G 2-3個實例

96G 3-4個實例

disk(磁盤IO)

數據庫是IO密集應用

機械盤

SAS(不選擇SATA),300G*12塊,磁盤數量越多IO越高,SAS 15k的硬盤

SSD 

測試對比:SAS單盤隨機IO,3000IOPS, SSD單盤隨機IO達到上萬

RAID陣列

選硬件 RAID (0>10>5>1)

網卡

至少千兆(bond), 萬兆交換機

數據庫服務器儘可能不用虛擬化

SLAVE服務器配置最好是大於等於Master

從庫會接替主庫,從庫配置過低,致使延遲

 

案例

百度:IBM服務器,內存96G-128G, CPU48核心

SINA:dell r510 內存48G,磁盤300*12塊, RAID10

硬件調整

BIOS調整提升CPU性能

打開(DAPC)模式,發揮CPU性能

啓動Node Interleaving避免NUMA問題

關閉C1E和State等

陣列卡調整

配置CACHE和BBU模塊(機械盤)

寫策略(always write back)

不要用(wt)策略

關閉陣列預讀策略

 

軟件層面優化

操做系統

選擇x86_64位系統

系統盤和數據盤分開

極端狀況下不分swap分區

避免使用操做系統的軟raid

避免使用LVM

專庫專用不要跑(LNMP,TOMCAT)

文件系統層優化

調整Cache mode

啓動wce=1(Write Cache Enable)

RCD=0(Read Cache Disable)

系統調度算法默認cfq(比較中庸),數據庫選擇noop,deadline.針對deadline能夠調節參數(內核參數)

Centos 6.8 默認ext4能夠做爲數據庫的文件系統,房屋呢量大的話,XFS就更好

Centos7默認也選擇了XFS,調整XFS日誌,緩衝參數.

mount參數很重要 –o async,noatime,nodirname,nobarrier等

內核層面優化

參考連接:http://oldboy.blog.51cto.com/2561410/1336488
vm.swappiness設置爲0,或者0-5,讓數據庫儘可能不使用swap

vm.dirty_background_ratio設置5-10,vm.dirty_ratio設置前面的2倍.持續將系統數據刷到磁盤.
參考連接:http://blog.sina.com.cn/s/blog_448574810101k1va.html

減小time_wait
net.ipv4.tcp_tw_recyle=1,net.ipv4.tcp_tw_reuse=1,
net.ipv4.tcp_fin_timeout=2,net.ipv4.tcp_keepalived_time=600

MySQL層面優化

參考連接:http://oldboy.blog.51cto.com/2561410/1726517

my.cnf參數的優化

若是咱們採用myisam引擎,key_buffer_size加大.採用innodb

推薦使用innodb, 5.5.5之後默認都是innodb引擎

innodb_buffer_pool_size, 調整爲內存的50%,單實例.多實例各25%

innodb_flush_log_at_trx_commit, sync_binlog, 設置爲1, 數據能夠丟失的話(不重要),能夠設置爲0, 從庫都設置爲0,事物的log,多長時間刷入到硬盤裏

使用獨立表空間. innodb_file_per_table=1. 默認共享表文件效率低

innodb_log_file_size=256M 不要給過大

log_query_time=1 ,log的日誌查詢,超過1秒的SQL語句,記錄到日誌裏,回頭看這個日誌,進行優化.

一些session參數,不要設置過大,一個鏈接就會佔用參數設置的大小.不要給過大

Sort_buffer_size, join_buffer_size,read_buffer_size,tmp_table_size,max_heap_table_size這類參數都是session,級別參數.2M6M8M就能夠了.

查詢緩存參數要設置小一些:query_cache_size = 64M,想要緩存,前端加mc,redis

庫和表的設計優化

字符集UTF-8

固定字符串的內容,能夠選擇char

數據庫都要給一個自增的主頁,沒什麼用途.

字段長度,在知足要求前提下,最短的.Varchar(16)

省份,性別,這樣內容字段能夠設置ENUM類型,mysql系統表(char,ENUM)

儘量不用text/blob比較大的字段類型(博文帖子),若是使用的話,能夠放到子表裏

通常針對字段索引,儘可能採用字段的前N個字符索引,不要整個字段索引,效率低

多用聯合索引,有前綴特性,少用獨立索引,性別列,不要創建索引了.效果差

SQL語句的優化

索引優化(運維最經常使用的)

抓出來慢查詢

百度:白名單的方法,設計程序時參與設計,程序上線鏈接數據庫,有個控制查庫的東西,請示放我庫裏,才能查詢,數據庫沒有或者減小慢查詢

常常給開發培訓,DB水平更高

如今網站慢了,show full processlist; 抓慢查詢,連續執行兩下,間隔1-2秒,若是還有,懷疑他是慢查詢.

平常:把慢查詢語句記錄到log裏面

my.cnf

long_query_time=2 超過兩秒的查詢
log_queryies_not_using_indexes沒有超過兩秒沒有走索引
log_slow_queries=/data/3306/slow.log

天天生成slow.log

按天切割slow.log,切割後分析軟件分析(mysqlsla,-pt-query-digest)

mysqldump slow,myprofi. 優化的語句,不必定是單條佔用時間長的,頻率搞,單條不長,可是總時間很長的,這些可能也是優化的重點.

對於運維來說,慢查詢SQL發給開發.

有能力和開發一塊兒搞

用explain測試語句是否走索引,set profile深度查看語句執行狀況.

檢查刪除重複的索引,工具pt-duplicate-key-checker

效率很低的索引,檢查刪除,pt-index-usage工具

儘可能不用子查詢,用join替代

數據庫是存放數據的地方,不是計算數據的地方,計算放在web

搜索功能,like "%daf%",不用數據庫搜索

在語句中儘可能去掉in or <> 字符

網站集羣架構上來優化數據庫

參考連接:http://oldboy.blog.51cto.com/2561410/775056

服務器跑多實例2-4個

主從複製最多9個,建議1主5從, 主庫採用mixed模式,不要跨機房複製(若是是,遠程寫,本地讀

業務拆分:

搜索功能,like "%daf%",不用數據庫搜索

搜索軟件:Sphinx,Xapian,Solr

粉絲關注,好關係,統計這類應用比較簡單,不用數據庫,放到redis(想要持久haunted)

數據庫前端加緩存

動態內容轉靜態化(數據庫的數據,轉成html文件,放到存儲上),好處就是可使用CDN緩存

數據庫採用讀寫分離,讀從庫,寫主庫.

相關軟件:MyCat,atlas,cobar,amoeba,MySQL-proxy

單表超過800W,拆庫拆表,自動擴容,自動收縮.

備份策略

選擇從庫備份,鎖表,備份時間長,影響數據訪問

備份時採用分表分庫,不分很是費勁.

流程 制度 安全

50%的故障都是人爲形成的.

操做流程:開放-->核心開發-->運維或DBA

測試流程:辦公室測試-->IDC測試環境測試-->生產環境

相關文章
相關標籤/搜索