1. 程式人生 > >MySql高效能優化實戰總結(Linux)

MySql高效能優化實戰總結(Linux)

MySQL對於很多Linux從業者而言,是一個非常棘手的問題,多數情況都是因為對資料庫出現問題的情
況和處理思路不清晰。在進行MySQL的優化之前必須要了解的就是MySQL的查詢過程,很多的查詢優
化工作實際上就是遵循一些原則讓MySQL的優化器能夠按照預想的合理方式執行而已。

MySql查詢過程

優化有風險,涉足需謹慎!

1. 優化可能帶來的問題

  • 優化不總是對一個單純的環境進行,還很可能是一個複雜的已投產的系統。
  • 優化手段本來就有很大的風險,只不過你沒能力意識到和預見到!
  • 任何的技術可以解決一個問題,但必然存在帶來一個問題的風險!
  • 對於優化來說解決問題而帶來的問題,控制在可接受的範圍內才是有成果。
  • 保持現狀或出現更差的情況都是失敗!

2. 優化的需求

  • 穩定性和業務可持續性,通常比效能更重要!
  • 優化不可避免涉及到變更,變更就有風險!
  • 優化使效能變好,維持和變差是等概率事件!
  • 切記優化,應該是各部門協同,共同參與的工作,任何單一部門都不能對資料庫進行優化!
  • 所以優化工作,是由業務需要驅使的!!!

3. 優化由誰參與
在進行資料庫優化時,應由資料庫管理員、業務部門代表、應用程式架構師、應用程式設計人員、應用程式開發人員、硬體及系統管理員、儲存管理員等,業務相關人員共同參與。

優化思路

1. 在資料庫優化上有兩個主要方面:即安全與效能。

  • 安全 —> 資料可持續性
  • 效能 —> 資料的高效能訪問

2. 優化的範圍有哪些

儲存、主機和作業系統方面:

  • 主機架構穩定性
  • I/O規劃及配置
  • Swap交換分割槽
  • OS核心引數和網路問題

應用程式方面:

  • 應用程式穩定性
  • SQL語句效能
  • 序列訪問資源
  • 效能欠佳會話管理
  • 這個應用適不適合用MySQL

資料庫優化方面:

  • 記憶體
  • 資料庫結構(物理&邏輯)
  • 例項配置
    說明:不管是在,設計系統,定位問題還是優化,都可以按照這個順序執行。

3. 優化維度
資料庫優化維度有四個:
硬體、系統配置、資料庫表結構、SQL及索引。
MySql資料庫優化

優化選擇:
  • 優化成本:硬體>系統配置>資料庫表結構>SQL及索引
  • 優化效果:硬體<系統配置<資料庫表結構<SQL及索引

優化工具

1. 資料庫層面
檢查問題常用工具:

mysqladmin  # mysql客戶端,可進行管理操作
mysqlshow  # 功能強大的檢視shell命令
show [SESSION | GLOBAL] variables  # 檢視資料庫引數資訊
SHOW [SESSION | GLOBAL] STATUS  # 檢視資料庫的狀態資訊
information_schema  # 獲取元資料的方法s
SHOW ENGINE INNODB STATUS Innodb  # 引擎的所有狀態
SHOW PROCESSLIST  # 檢視當前所有連線session狀態
explain  # 獲取查詢語句的執行計劃s
how index  # 查看錶的索引資訊
slow-log # 記錄慢查詢語句
mysqldumpslow  # 分析showlog檔案的

不常用但好用的工具

zabbix  #監控主機,系統,資料庫(部署zabbix監控平臺)
pt-query-digest  # 分析慢日誌
mysqlslap  # 分析慢日誌
sysbench  # 壓力測試工具
mysql profiling  # 統計資料整體狀態工具
Performance Schema mysql  # 效能狀態統計的資料
workbench  # 管理,備份,監控,分析,優化工具(比較費資源)

2. 資料庫層面問題解決思路
一般應急調優的思路:
針對突然的業務辦理卡頓,無法進行正常的業務處理!需要立馬解決的場景!

  • 1、show processlist
  • 2、explain select id ,name from stu where name=‘clsn’; # ALL id name age sex
    select id,name from stu where id=2-1 函式 結果集>30;
    show index from table;
  • 3、通過執行計劃判斷,索引問題(有沒有、合不合理)或者語句本身問題
  • 4、show status like ‘%lock%’; # 查詢鎖狀態
    kill SESSION_ID; # 殺掉有問題的session

常規調優思路:
針對業務週期性的卡頓,例如在每天10-11點業務特別慢,但是還能夠使用,過了這段時間就好了。

  • 1、檢視slowlog,分析slowlog,分析出查詢慢的語句。
  • 2、按照一定優先順序,進行一個一個的排查所有慢語句。
  • 3、分析top sql,進行explain除錯,檢視語句執行時間。
  • 4、調整索引或語句本身。

3. 系統層面
cpu方面: vmstat、sar top、htop、nmon、mpstat
記憶體: free 、ps -aux
IO裝置(磁碟、網路): iostat 、 ss 、 netstat 、 iptraf、iftop、lsof

vmstat 命令說明:

  • Procs : r 顯示有多少程序正在等待CPU 時間。b 顯示處於不可中斷的休眠的程序數量。在等待I/O。
  • Memory:swpd顯示被交換到磁碟的資料塊的數量。未被使用的資料塊,使用者緩衝資料塊,用於作業系統的資料塊的數量。
  • Swap:作業系統每秒從磁碟上交換到記憶體和從記憶體交換到磁碟的資料塊的數量。s1和s0最好是0。
  • Io:每秒從裝置中讀入b1的寫入到裝置b0的資料塊的數量。反映了磁碟I/O。
  • System:顯示了每秒發生中斷的數量(in)和上下文交換(cs)的數量。
  • Cpu:顯示用於執行使用者程式碼,系統程式碼,空閒,等待I/O的CPU時間。

iostat命令說明
例項命令: iostat -dk 1 5
iostat -d -k -x 5 (檢視裝置使用率(%util)和響應時間(await))

  • tps:該裝置每秒的傳輸次數。“一次傳輸”意思是“一次I/O請求”。多個邏輯請求可能會被合併為“一次I/O請求”。
  • iops :硬體出廠的時候,廠家定義的一個每秒最大的IO次數,"一次傳輸"請求的大小是未知的。
  • kB_read/s:每秒從裝置(drive expressed)讀取的資料量。
  • KB_wrtn/s:每秒向裝置(drive expressed)寫入的資料量。
  • kB_read:讀取的總資料量。
  • kB_wrtn:寫入的總數量資料量;這些單位都為Kilobytes。

4. 系統層面問題解決辦法
你認為到底負載高好,還是低好呢?
在實際的生產中,一般認為 cpu只要不超過90%都沒什麼問題 。

當然不排除下面這些特殊情況:
問題一:cpu負載高,IO負載低

  • 記憶體不夠
  • 磁碟效能差
  • SQL問題 ------>去資料庫層,進一步排查sql問題
  • IO出問題了(磁碟到臨界了、raid設計不好、raid降級、鎖、在單位時間內tps過高)
  • tps過高: 大量的小資料IO、大量的全表掃描

問題二:IO負載高,cpu負載低

  • 大量小的IO 寫操作:
  • autocommit ,產生大量小IO
  • IO/PS,磁碟的一個定值,硬體出廠的時候,廠家定義的一個每秒最大的IO次數。
  • 大量大的IO 寫操作
  • SQL問題的機率比較大

問題三:IO和cpu負載都很高
硬體不夠了或sql存在問題

基礎優化

1. 優化思路
定位問題點:
硬體 --> 系統 --> 應用 --> 資料庫 --> 架構(高可用、讀寫分離、分庫分表)
處理方向:
明確優化目標、效能和安全的折中、防患未然

2. 硬體優化
主機方面:

  • 根據資料庫型別,主機CPU選擇、記憶體容量選擇、磁碟選擇
  • 平衡記憶體和磁碟資源
  • 隨機的I/O和順序的I/O
  • 主機 RAID卡的BBU(Battery Backup Unit)關閉

cpu的選擇:

  • cpu的兩個關鍵因素:核數、主頻
  • 根據不同的業務型別進行選擇:
  • cpu密集型:計算比較多,OLTP 主頻很高的cpu、核數還要多
  • IO密集型:查詢比較,OLAP 核數要多,主頻不一定高的

記憶體的選擇:

  • OLAP型別資料庫,需要更多記憶體,和資料獲取量級有關。
  • OLTP型別資料一般記憶體是cpu核心數量的2倍到4倍,沒有最佳實踐

儲存方面:

  • 根據儲存資料種類的不同,選擇不同的儲存裝置
  • 配置合理的RAID級別(raid5、raid10、熱備盤)
  • 對與作業系統來講,不需要太特殊的選擇,最好做好冗餘(raid1)(ssd、sas 、sata)

raid卡:主機raid卡選擇:

  • 實現作業系統磁碟的冗餘(raid1)
  • 平衡記憶體和磁碟資源
  • 隨機的I/O和順序的I/O
  • 主機 RAID卡的BBU(Battery Backup Unit)要關閉

網路裝置方面:
使用流量支援更高的網路裝置(交換機、路由器、網線、網絡卡、HBA卡)
注意:以上這些規劃應該在初始設計系統時就應該考慮好。

3. 伺服器硬體優化

  • 1、物理狀態燈:
  • 2、自帶管理裝置:遠端控制卡(FENCE裝置:ipmi ilo idarc),開關機、硬體監控。
  • 3、第三方的監控軟體、裝置(snmp、agent)對物理設施進行監控
  • 4、儲存裝置:自帶的監控平臺。EMC2(hp收購了), 日立(hds),IBM低端OEM hds,高階儲存是自己技術,華為儲存

4. 系統優化
Cpu:
基本不需要調整,在硬體選擇方面下功夫即可。

記憶體:
基本不需要調整,在硬體選擇方面下功夫即可。

SWAP:
MySQL儘量避免使用swap,阿里雲的伺服器中預設swap為0。

IO :

  • raid、no lvm、 ext4或xfs、ssd、IO排程策略

  • Swap調整(不使用swap分割槽)

    /proc/sys/vm/swappiness的內容改成0(臨時)
    /etc/sysctl.conf上新增vm.swappiness=0(永久)
    這個引數決定了Linux是傾向於使用swap,還是傾向於釋放檔案系統cache。在記憶體緊張的情況下,數值越低越傾向於釋放檔案系統cache。當然,這個引數只能減少使用swap的概率,並不能避免Linux使用swap。

修改MySQL 的配置引數innodb_flush_method , 開啟O_DIRECT 模式。這種情況下, InnoDB 的buffer pool會直接繞過檔案系統cache來訪問磁碟,但是redo log依舊會使用檔案系統cache。值得注意的是,Redo log是覆寫模式的,即使使用了檔案系統的cache,也不會佔用太多。

IO排程策略:

#echo deadline>/sys/block/sda/queue/scheduler  # 臨時修改為dealine
永久修改如下:
vi /boot/grub/grub.conf
更改到如下內容:
kernel /boot/vmlinuz-2.6.18-8.el5 ro root=LABEL=/ elevator=deadline rhgb quiet

5. 系統引數調整
Linux系統核心引數優化:

vim /etc/sysctl.conf
net.ipv4.ip_local_port_range = 1024 65535  # 使用者埠範圍
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_fin_timeout = 30
fs.file-max=65535  # 系統最大檔案控制代碼,控制的是能開啟檔案最大數量

使用者限制引數(mysql可以不設定以下配置):
vim /etc/security/limits.conf

  • soft nproc 65535
  • hard nproc 65535
  • soft nofile 65535
  • hard nofile 65535

6. 應用優化
業務應用和資料庫應用獨立,防火牆:iptables、selinux等其他無用服務(關閉):

chkconfig --level 23456 acpid off
chkconfig --level 23456 anacron off
chkconfig --level 23456 autofs off
chkconfig --level 23456 avahi-daemon off
chkconfig --level 23456 bluetooth off
chkconfig --level 23456 cups off
chkconfig --level 23456 firstboot off
chkconfig --level 23456 haldaemon off
chkconfig --level 23456 hplip off
chkconfig --level 23456 ip6tables off
chkconfig --level 23456 isdn off
chkconfig --level 23456 sendmail off
chkconfig --level 23456 yum-updatesd off

安裝圖形介面的伺服器不要啟動圖形介面 runlevel 3, 另外, 思考將來我們的業務是否真的需要
MySQL,還是使用其他種類的資料庫。用資料庫的最高境界就是不用資料庫。

資料庫優化

SQL優化方向:
執行計劃、索引、SQL改寫

架構優化方向:
高可用架構、高效能架構、分庫分表

1. 資料庫引數優化
調整:例項整體(高階優化,擴充套件)

	thread_concurrency  # 併發執行緒數量個數
    sort_buffer_size  # 排序快取
    read_buffer_size  # 順序讀取快取
    read_rnd_buffer_size  # 隨機讀取快取
    key_buffer_size  # 索引快取
    thread_cache_size  # 執行緒快取(1G->8,2G->16,3G->32,>3G->64)

連線層(基礎優化)
設定合理的連線客戶和連線方式

max_connections  # 最大連線數,看交易筆數設定
max_connect_errors  # 最大錯誤連線數,能大則達
connect_timeout  # 連線超時
max_user_connections  # 最大使用者連線數
skip-name-resolve  # 跳過域名解析
wait_timeout  # 等待超時
back_log  # 可以在堆疊中的連線數量

SQL層(基礎優化)

  • query_cache_size: 查詢快取
  • OLAP型別資料庫,需要重點加大此記憶體快取.
  • 但是一般不會超過GB.
  • 對於經常被修改的資料,快取會立馬失效。
  • 我們可以實用記憶體資料庫(redis、memecache),替代他的功能。

2. 儲存引擎層(innodb基礎優化引數)

default-storage-engine
# 沒有固定大小,50%測試值,看看情況再微調。
# 但是儘量設定不要超過實體記憶體70% innodb_file_per_table=(1,0)
innodb_buffer_pool_size
innodb_flush_log_at_trx_commit=(0, 1, 2)  # 1是最安全的,0是效能最高的,2折中
binlog_sync
Innodb_flush_method=(ODIRECT, fdatasync)
innodb_log_buffer_size  # 100%以下
innodb_log_file_size  # 100%以下
innodb_log_files_in_groug  # 5個成員以下,一般2-3個夠用(iblogfile0-N)
innodb_max_dirty_pages_pct  #達到百分之75的時候刷寫  記憶體髒頁到磁碟。log_bin
max_binlog_cache_size  # 可以不設定
max_binlog_size  # 可以不設定
innodb_additional_mem_pool_size  # 小於2G記憶體的機器, 推薦值是20M。32G以上100M

MySQL配置檔案my.cnf中文版

#BEGIN CONFIG INFO
#DESCR: 4GB RAM, 只使用InnoDB, ACID, 少量的連線, 佇列負載大
#TYPE: SYSTEM
#END CONFIG INFO
#
# 此mysql配置檔案例子針對4G記憶體
# 主要使用INNODB
#處理複雜佇列並且連線數量較少的mysql伺服器
# 
# 將此檔案複製到/etc/my.cnf 作為全域性設定,
# mysql-data-dir/my.cnf 作為伺服器指定設定
# (@[email protected] for this installation) 或者放入
# ~/.my.cnf 作為使用者設定.
#
# 在此配置檔案中, 你可以使用所有程式支援的長選項.
# 如果想獲悉程式支援的所有選項
# 請在程式後加上"--help"引數執行程式.
#
# 關於獨立選項更多的細節資訊可以在手冊內找到
#
#
# 以下選項會被MySQL客戶端應用讀取.
# 注意只有MySQL附帶的客戶端應用程式保證可以讀取這段內容.
# 如果你想你自己的MySQL應用程式獲取這些值
# 需要在MySQL客戶端庫初始化的時候指定這些選項
#
[client]
#password = [your_password]
port = @[email protected]
socket = @[email protected]
# *** 應用定製選項 ***
#
#  MySQL 服務端
#
[mysqld]
# 一般配置選項
port = @[email protected]
socket = @[email protected]
# back_log 是作業系統在監聽佇列中所能保持的連線數,
# 佇列儲存了在MySQL連線管理器執行緒處理之前的連線.
# 如果你有非常高的連線率並且出現"connection refused" 報錯,
# 你就應該增加此處的值.
# 檢查你的作業系統文件來獲取這個變數的最大值.
# 如果將back_log設定到比你作業系統限制更高的值,將會沒有效果
back_log = 50
# 不在TCP/IP埠上進行監聽.
# 如果所有的程序都是在同一臺伺服器連線到本地的mysqld,
# 這樣設定將是增強安全的方法
# 所有mysqld的連線都是通過Unix sockets 或者命名管道進行的.
# 注意在windows下如果沒有開啟命名管道選項而只是用此項
# (通過 "enable-named-pipe" 選項) 將會導致mysql服務沒有任何作用!
#skip-networking
# MySQL 服務所允許的同時會話數的上限
# 其中一個連線將被SUPER許可權保留作為管理員登入.
# 即便已經達到了連線數的上限.
max_connections = 100
# 每個客戶端連線最大的錯誤允許數量,如果達到了此限制.
# 這個客戶端將會被MySQL服務阻止直到執行了"FLUSH HOSTS" 或者服務重啟
# 非法的密碼以及其他在連結時的錯誤會增加此值.
# 檢視 "Aborted_connects" 狀態來獲取全域性計數器.
max_connect_errors = 10
# 所有執行緒所開啟表的數量.
# 增加此值就增加了mysqld所需要的檔案描述符的數量
# 這樣你需要確認在[mysqld_safe]中 "open-files-limit" 變數設定開啟檔案數量允許至少4096
table_cache = 2048
# 允許外部檔案級別的鎖. 開啟檔案鎖會對效能造成負面影響
# 所以只有在你在同樣的檔案上執行多個數據庫例項時才使用此選項(注意仍會有其他約束!) 
# 或者你在檔案層面上使用了其他一些軟體依賴來鎖定MyISAM表
#external-locking
# 服務所能處理的請求包的最大大小以及服務所能處理的最大的請求大小(當與大的BLOB欄位一起工作時相當必要)
# 每個連線獨立的大小.大小動態增加
max_allowed_packet = 16M
# 在一個事務中binlog為了記錄SQL狀態所持有的cache大小
# 如果你經常使用大的,多宣告的事務,你可以增加此值來獲取更大的效能. 
# 所有從事務來的狀態都將被緩衝在binlog緩衝中然後在提交後一次性寫入到binlog中
# 如果事務比此值大, 會使用磁碟上的臨時檔案來替代. 
# 此緩衝在每個連線的事務第一次更新狀態時被建立
binlog_cache_size = 1M
# 獨立的記憶體表所允許的最大容量. 
# 此選項為了防止意外建立一個超大的記憶體表導致永盡所有的記憶體資源.
max_heap_table_size = 64M
# 排序緩衝被用來處理類似ORDER BY以及GROUP BY佇列所引起的排序
# 如果排序後的資料無法放入排序緩衝, 
# 一個用來替代的基於磁碟的合併分類會被使用
# 檢視 "Sort_merge_passes" 狀態變數.
# 在排序發生時由每個執行緒分配
sort_buffer_size = 8M
# 此緩衝被使用來優化全聯合(full JOINs 不帶索引的聯合). 
# 類似的聯合在極大多數情況下有非常糟糕的效能表現,
# 但是將此值設大能夠減輕效能影響.
# 通過 "Select_full_join" 狀態變數檢視全聯合的數量
# 當全聯合發生時,在每個執行緒中分配
join_buffer_size = 8M
# 我們在cache中保留多少執行緒用於重用
# 當一個客戶端斷開連線後,如果cache中的執行緒還少於thread_cache_size,
# 則客戶端執行緒被放入cache中. 
# 這可以在你需要大量新連線的時候極大的減少執行緒建立的開銷
# (一般來說如果你有好的執行緒模型的話,這不會有明顯的效能提升.)
thread_cache_size = 8
# 此允許應用程式給予執行緒系統一個提示在同一時間給予渴望被執行的執行緒的數量.
# 此值只對於支援 thread_concurrency() 函式的系統有意義( 例如Sun Solaris).
# 你可可以嘗試使用 [CPU數量]*(2..4) 來作為thread_concurrency的值
thread_concurrency = 8
# 查詢緩衝常被用來緩衝 SELECT 的結果並且在下一次同樣查詢的時候不再執行直接返回結果. 
# 開啟查詢緩衝可以極大的提高伺服器速度, 如果你有大量的相同的查詢並且很少修改表.
# 檢視 "Qcache_lowmem_prunes" 狀態變數來檢查是否當前值對於你的負載來說是否足夠高.
# 注意: 在你表經常變化的情況下或者如果你的查詢原文每次都不同,
# 查詢緩衝也許引起效能下降而不是效能提升.
query_cache_size = 64M
# 只有小於此設定值的結果才會被緩衝
# 此設定用來保護查詢緩衝,防止一個極大的結果集將其他所有的查詢結果都覆蓋.
query_cache_limit = 2M
# 被全文檢索索引的最小的字長.
# 你也許希望減少它,如果你需要搜尋更短字的時候.
# 注意在你修改此值之後,
# 你需要重建你的 FULLTEXT 索引
ft_min_word_len = 4
# 如果你的系統支援 memlock() 函式,你也許希望開啟此選項用以讓執行中的mysql在在記憶體高度緊張的時候,資料在記憶體中保持鎖定並且防止可能被swapping out
# 此選項對於效能有益
#memlock
# 當建立新表時作為預設使用的表型別,
# 如果在建立表示沒有特別執行表型別,將會使用此值
default_table_type = MYISAM
# 執行緒使用的堆大小. 此容量的記憶體在每次連線時被預留.
# MySQL 本身常不會需要超過64K的記憶體
# 如果你使用你自己的需要大量堆的UDF函式
# 或者你的作業系統對於某些操作需要更多的堆,
# 你也許需要將其設定的更高一點.
thread_stack = 192K
# 設定預設的事務隔離級別.可用的級別如下:
# READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE
transaction_isolation = REPEATABLE-READ
# 內部(記憶體中)臨時表的最大大小
# 如果一個表增長到比此值更大,將會自動轉換為基於磁碟的表.
# 此限制是針對單個表的,而不是總和. 
tmp_table_size = 64M
# 開啟二進位制日誌功能.
# 在複製(replication)配置中,作為MASTER主伺服器必須開啟此項
# 如果你需要從你最後的備份中做基於時間點的恢復,你也同樣需要二進位制日誌.
log-bin=mysql-bin
# 如果你在使用鏈式從伺服器結構的複製模式 (A->B->C), 
# 你需要在伺服器B上開啟此項. 
# 此選項開啟在從執行緒上重做過的更新的日誌,
# 並將其寫入從伺服器的二進位制日誌.
#log_slave_updates
# 開啟全查詢日誌. 所有的由伺服器接收到的查詢 (甚至對於一個錯誤語法的查詢) 
# 都會被記錄下來. 這對於除錯非常有用, 在生產環境中常常關閉此項.
#log
# 將警告列印輸出到錯誤log檔案.  如果你對於MySQL有任何問題
# 你應該開啟警告log並且仔細審查錯誤日誌,查出可能的原因. 
#log_warnings
# 記錄慢速查詢. 慢速查詢是指消耗了比 "long_query_time" 定義的更多時間的查詢.
# 如果 log_long_format 被開啟,那些沒有使用索引的查詢也會被記錄.
# 如果你經常增加新查詢到已有的系統內的話. 一般來說這是一個好主意,
log_slow_queries
# 所有的使用了比這個時間(以秒為單位)更多的查詢會被認為是慢速查詢.
# 不要在這裡使用"1", 否則會導致所有的查詢,甚至非常快的查詢頁被記錄下來(由於MySQL 目前時間的精確度只能達到秒的級別).
long_query_time = 2
# 在慢速日誌中記錄更多的資訊.
# 一般此項最好開啟.
# 開啟此項會記錄使得那些沒有使用索引的查詢也被作為到慢速查詢附加到慢速日誌裡
log_long_format
# 此目錄被MySQL用來儲存臨時檔案.例如,
# 它被用來處理基於磁碟的大型排序,和內部排序一樣.
# 以及簡單的臨時表.
# 如果你不建立非常大的臨時檔案,將其放置到 swapfs/tmpfs 檔案系統上也許比較好
# 另一種選擇是你也可以將其放置在獨立的磁碟上. 
# 你可以使用";"來放置多個路徑
# 他們會按照roud-robin方法被輪詢使用.
#tmpdir = /tmp
# ***  複製有關的設定
# 唯一的服務辨識號,數值位於 1 到 2^32-1之間. 
# 此值在master和slave上都需要設定.
# 如果 "master-host" 沒有被設定,則預設為1, 但是如果忽略此選項,MySQL不會作為master生效.
server-id = 1
# 複製的Slave (去掉master段的註釋來使其生效)
#
# 為了配置此主機作為複製的slave伺服器,你可以選擇兩種方法:
#
# 1) 使用 CHANGE MASTER TO 命令 (在我們的手冊中有完整描述) -
#    語法如下:
#
#    CHANGE MASTER TO MASTER_HOST=
, MASTER_PORT=

,
#    MASTER_USER=

, MASTER_PASSWORD=

;
#
#    你需要替換掉

,

,

等被尖括號包圍的欄位以及使用master的埠號替換

(預設3306).
#
#    例子:
#
#    CHANGE MASTER TO MASTER_HOST='125.564.12.1', MASTER_PORT=3306,
#    MASTER_USER='joe', MASTER_PASSWORD='secret';
#
# 或者
#
# 2) 設定以下的變數. 不論如何, 在你選擇這種方法的情況下, 然後第一次啟動複製(甚至不成功的情況下,
#     例如如果你輸入錯密碼在master-password欄位並且slave無法連線), 
#    slave會建立一個 master.info 檔案,並且之後任何對於包含在此檔案內的引數的變化都會被忽略
#    並且由 master.info 檔案內的內容覆蓋, 除非你關閉slave服務, 刪除 master.info 並且重啟slave 服務.
#    由於這個原因,你也許不想碰一下的配置(註釋掉的) 並且使用 CHANGE MASTER TO (檢視上面) 來代替
#
# 所需要的唯一id號位於 2 和 2^32 - 1之間
# (並且和master不同)
# 如果master-host被設定了.則預設值是2
# 但是如果省略,則不會生效
#server-id = 2
#
# 複製結構中的master - 必須
#master-host =

#
# 當連線到master上時slave所用來認證的使用者名稱 - 必須
#master-user =


#
# 當連線到master上時slave所用來認證的密碼 - 必須
#master-password =


#
# master監聽的埠.
# 可選 - 預設是3306
#master-port =


# 使得slave只讀.只有使用者擁有SUPER許可權和在上面的slave執行緒能夠修改資料.
# 你可以使用此項去保證沒有應用程式會意外的修改slave而不是master上的資料
#read_only
#*** MyISAM 相關選項
# 關鍵詞緩衝的大小, 一般用來緩衝MyISAM表的索引塊.
# 不要將其設定大於你可用記憶體的30%, 
# 因為一部分記憶體同樣被OS用來緩衝行資料 
# 甚至在你並不使用MyISAM 表的情況下, 你也需要仍舊設定起 8-64M 記憶體由於它同樣會被內部臨時磁碟表使用.
key_buffer_size = 32M
# 用來做MyISAM表全表掃描的緩衝大小.
# 當全表掃描需要時,在對應執行緒中分配.
read_buffer_size = 2M
# 當在排序之後,從一個已經排序好的序列中讀取行時,行資料將從這個緩衝中讀取來防止磁碟尋道. 
# 如果你增高此值,可以提高很多ORDER BY的效能.
# 當需要時由每個執行緒分配
read_rnd_buffer_size = 16M
# MyISAM 使用特殊的類似樹的cache來使得突發插入
# (這些插入是,INSERT ... SELECT, INSERT ... VALUES (...), (...), ..., 以及 LOAD DATA
# INFILE) 更快. 此變數限制每個程序中緩衝樹的位元組數. 
# 設定為 0 會關閉此優化.
# 為了最優化不要將此值設定大於 "key_buffer_size".
# 當突發插入被檢測到時此緩衝將被分配.
bulk_insert_buffer_size = 64M
# 此緩衝當MySQL需要在 REPAIR, OPTIMIZE, ALTER 以及 LOAD DATA INFILE 到一個空表中引起重建索引時被分配.
# 這在每個執行緒中被分配.所以在設定大值時需要小心.
myisam_sort_buffer_size = 128M
# MySQL重建索引時所允許的最大臨時檔案的大小 (當 REPAIR, ALTER TABLE 或者 LOAD DATA INFILE).
# 如果檔案大小比此值更大,索引會通過鍵值緩衝建立(更慢)
myisam_max_sort_file_size = 10G
# 如果被用來更快的索引建立索引所使用臨時檔案大於制定的值,那就使用鍵值緩衝方法.
# 這主要用來強制在大表中長字串鍵去使用慢速的鍵值緩衝方法來建立索引.
myisam_max_extra_sort_file_size = 10G
# 如果一個表擁有超過一個索引, MyISAM 可以通過並行排序使用超過一個執行緒去修復他們.
# 這對於擁有多個CPU以及大量記憶體情況的使用者,是一個很好的選擇.
myisam_repair_threads = 1
# 自動檢查和修復沒有適當關閉的 MyISAM 表.
myisam_recover
# 預設關閉 Federated 
skip-federated
# *** BDB 相關選項 ***
# 如果你執行的MySQL服務有BDB支援但是你不準備使用的時候使用此選項. 這會節省記憶體並且可能加速一些事.
skip-bdb
# *** INNODB 相關選項 ***
# 如果你的MySQL服務包含InnoDB支援但是並不打算使用的話,
# 使用此選項會節省記憶體以及磁碟空間,並且加速某些部分
#skip-innodb
# 附加的記憶體池被InnoDB用來儲存 metadata 資訊
# 如果InnoDB為此目的需要更多的記憶體,它會開始從OS這裡申請記憶體.
# 由於這個操作在大多數現代作業系統上已經足夠快, 你一般不需要修改此值.
# SHOW INNODB STATUS 命令會顯示當先使用的數量.
innodb_additional_mem_pool_size = 16M
# InnoDB使用一個緩衝池來儲存索引和原始資料, 不像 MyISAM. 
# 這裡你設定越大,你在存取表裡面數據時所需要的磁碟I/O越少.
# 在一個獨立使用的資料庫伺服器上,你可以設定這個變數到伺服器實體記憶體大小的80%
# 不要設定過大,否則,由於實體記憶體的競爭可能導致作業系統的換頁顛簸. 
# 注意在32位系統上你每個程序可能被限制在 2-3.5G 使用者層面記憶體限制,
# 所以不要設定的太高.
innodb_buffer_pool_size = 2G
# InnoDB 將資料儲存在一個或者多個數據檔案中成為表空間.
# 如果你只有單個邏輯驅動儲存你的資料,一個單個的自增檔案就足夠好了.
# 其他情況下.每個裝置一個檔案一般都是個好的選擇.
# 你也可以配置InnoDB來使用裸盤分割槽 - 請參考手冊來獲取更多相關內容
innodb_data_file_path = ibdata1:10M:autoextend
# 設定此選項如果你希望InnoDB表空間檔案被儲存在其他分割槽.
# 預設儲存在MySQL的datadir中.
#innodb_data_home_dir =
# 用來同步IO操作的IO執行緒的數量. This value is
# 此值在Unix下被硬編碼為4,但是在Windows磁碟I/O可能在一個大數值下表現的更好.
innodb_file_io_threads = 4
# 如果你發現InnoDB表空間損壞, 設定此值為一個非零值可能幫助你匯出你的表.
# 從1開始並且增加此值知道你能夠成功的匯出表.
#innodb_force_recovery=1
# 在InnoDb核心內的允許執行緒數量. 
# 最優值依賴於應用程式,硬體以及作業系統的排程方式. 
# 過高的值可能導致執行緒的互斥顛簸.
innodb_thread_concurrency = 16
# 如果設定為1 ,InnoDB會在每次提交後重新整理(fsync)事務日誌到磁碟上,
# 這提供了完整的ACID行為.
# 如果你願意對事務安全折衷, 並且你正在執行一個小的食物, 你可以設定此值到0或者2來減少由事務日誌引起的磁碟I/O
# 0代表日誌只大約每秒寫入日誌檔案並且日誌檔案重新整理到磁碟. 
# 2代表日誌寫入日誌檔案在每次提交後,但是日誌檔案只有大約每秒才會重新整理到磁碟上.
innodb_flush_log_at_trx_commit = 1
# 加速InnoDB的關閉. 這會阻止InnoDB在關閉時做全清除以及插入緩衝合併.
# 這可能極大增加關機時間, 但是取而代之的是InnoDB可能在下次啟動時做這些操作.
#innodb_fast_shutdown
# 用來緩衝日誌資料的緩衝區的大小.
# 當此值快滿時, InnoDB將必須重新整理資料到磁碟上.
# 由於基本上每秒都會重新整理一次,所以沒有必要將此值設定的太大(甚至對於長事務而言)
innodb_log_buffer_size = 8M
# 在日誌組中每個日誌檔案的大小.
# 你應該設定日誌檔案總合大小到你緩衝池大小的25%~100%
# 來避免在日誌檔案覆寫上不必要的緩衝池重新整理行為.
# 不論如何, 請注意一個大的日誌檔案大小會增加恢復程序所需要的時間.
innodb_log_file_size = 256M
# 在日誌組中的檔案總數.
# 通常來說2~3是比較好的.
innodb_log_files_in_group = 3
# InnoDB的日誌檔案所在位置. 預設是MySQL的datadir.
# 你可以將其指定到一個獨立的硬碟上或者一個RAID1捲上來提高其效能
#innodb_log_group_home_dir
# 在InnoDB緩衝池中最大允許的髒頁面的比例.
# 如果達到限額, InnoDB會開始重新整理他們防止他們妨礙到乾淨資料頁面.
# 這是一個軟限制,不被保證絕對執行.
innodb_max_dirty_pages_pct = 90
# InnoDB用來重新整理日誌的方法.
# 表空間總是使用雙重寫入重新整理方法
# 預設值是 "fdatasync", 另一個是 "O_DSYNC".
#innodb_flush_method=O_DSYNC
# 在被回滾前,一個InnoDB的事務應該等待一個鎖被批准多久.
# InnoDB在其擁有的鎖表中自動檢測事務死鎖並且回滾事務.
# 如果你使用 LOCK TABLES 指令, 或者在同樣事務中使用除了InnoDB以外的其他事務安全的儲存引擎
# 那麼一個死鎖可能發生而InnoDB無法注意到.
# 這種情況下這個timeout值對於解決這種問題就非常有幫助.
innodb_lock_wait_timeout = 120
[mysqldump]
# 不要在將記憶體中的整個結果寫入磁碟之前快取. 在匯出非常巨大的表時需要此項
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
# 僅僅允許使用鍵值的 UPDATEs 和 DELETEs .
#safe-updates
[isamchk]
key_buffer = 512M
sort_buffer_size = 512M
read_buffer = 8M
write_buffer = 8M
[myisamchk]
key_buffer = 512M
sort_buffer_size = 512M
read_buffer = 8M
write_buffer = 8M
[mysqlhotcopy]
interactive-timeout
[mysqld_safe]
# 增加每個程序的可開啟檔案數量.
# 警告: 確認你已經將全系統限制設定的足夠高! 
# 開啟大量表需要將此值設高
open-files-limit = 8192