MySQL運(yùn)維及開(kāi)發(fā)規(guī)范
一.基礎(chǔ)規(guī)范
(1) 使用INNODB存儲(chǔ)引擎
(2) 表字符集使用UTF8
(3) 所有表都需要添加注釋
(4) 單表數(shù)據(jù)量建議控制在5000W以?xún)?nèi)
(5) 不在數(shù)據(jù)庫(kù)中存儲(chǔ)圖、文件等大數(shù)據(jù)
(6) 禁止在線(xiàn)上做數(shù)據(jù)庫(kù)壓力測(cè)試
(7) 禁從測(cè)試、開(kāi)發(fā)環(huán)境直連數(shù)據(jù)庫(kù)
二.命名規(guī)范
(1) 庫(kù)名表名字段名必須有固定的命名長(zhǎng)度，12個(gè)字符以?xún)?nèi)
(2) 庫(kù)名、表名、字段名禁止超過(guò)32個(gè)字符。須見(jiàn)名之意
(3) 庫(kù)名、表名、字段名禁止使用MySQL保留字
(4) 臨時(shí)庫(kù)、表名必須以tmp為前綴，并以日期為后綴
(5) 備份庫(kù)、表必須以bak為前綴，并以日期為后綴
三.庫(kù)、表、字段開(kāi)發(fā)設(shè)計(jì)規(guī)范
(1) 禁使用分區(qū)表
(2) 拆分大字段和訪問(wèn)頻率低的字段，分離冷熱數(shù)據(jù)
(3) 用HASH進(jìn)散表，表名后綴使進(jìn)制數(shù)，下標(biāo)從0開(kāi)始
(4) 按日期時(shí)間分表需符合YYYY[MM][DD][HH]格式
(5) 采用合適的分庫(kù)分表策略。例如千庫(kù)十表、十庫(kù)百表等
(6) 盡可能不使用TEXT、BLOB類(lèi)型
(7) 用DECIMAL代替FLOAT和DOUBLE存儲(chǔ)精確浮點(diǎn)數(shù)
(8) 越簡(jiǎn)單越好：將字符轉(zhuǎn)化為數(shù)字、使用TINYINT來(lái)代替ENUM類(lèi)型
(9) 所有字段均定義為NOT NULL
(10) 使用UNSIGNED存儲(chǔ)非負(fù)整數(shù)
(11) INT類(lèi)型固定占用4字節(jié)存儲(chǔ)
(12) 使用timestamp存儲(chǔ)時(shí)間
(13) 使用INT UNSIGNED存儲(chǔ)IPV4
(14) 使用VARBINARY存儲(chǔ)大小寫(xiě)敏感的變長(zhǎng)字符串
(15) 禁止在數(shù)據(jù)庫(kù)中存儲(chǔ)明文密碼，把密碼加密后存儲(chǔ)
(16) 用好數(shù)值類(lèi)型字段
Tinyint (1Byte)
smallint (2Byte)
mediumint (3Byte)
int (4Byte)
bigint (8Byte)
如果數(shù)值字段沒(méi)有那么大，就不要用 bigint
(17) 存儲(chǔ)ip最好用int存儲(chǔ)而非char(15)
(18) 不允許使用ENUM
(19) 避免使用NULL字段
NULL字段很難查詢(xún)優(yōu)化，NULL字段的索引需要額外空間，NULL字段的復(fù)合索引無(wú)效
(20) 少用text/blob，varchar的性能會(huì)比text高很多，實(shí)在避免不了blob，請(qǐng)拆表
(21) 數(shù)據(jù)庫(kù)中不允許存儲(chǔ)大文件，或者照片，可以將大對(duì)象放到磁盤(pán)上，數(shù)據(jù)庫(kù)中存儲(chǔ)它的路徑
四.索引規(guī)范
1、索引的數(shù)量要控制：
(1) 單張表中索引數(shù)量不超過(guò)5個(gè)
(2) 單個(gè)索引中的字段數(shù)不超過(guò)5個(gè)
(3) 對(duì)字符串使用前綴索引，前綴索引長(zhǎng)度不超過(guò)8個(gè)字符
(4) 建議優(yōu)先考慮前綴索引，必要時(shí)可添加偽列并建立索引
2、主鍵準(zhǔn)則
(1) 表必須有主鍵
(2) 不使用更新頻繁的列作為主鍵
(3) 盡量不選擇字符串列作為主鍵
(4) 不使用UUID MD5 HASH這些作為主鍵(數(shù)值太離散了)
(5) 默認(rèn)使非空的唯一鍵作為主鍵
(6) 建議選擇自增或發(fā)號(hào)器
3、重要的SQL必須被索引，比如：
(1) UPDATE、DELETE語(yǔ)句的WHERE條件列
(2) ORDER BY、GROUP BY、DISTINCT的字段
4、多表JOIN的字段注意以下：
(1) 區(qū)分度最大的字段放在前面
(2) 核SQL優(yōu)先考慮覆蓋索引
(3) 避免冗余和重復(fù)索引
(4) 索引要綜合評(píng)估數(shù)據(jù)密度和分布以及考慮查詢(xún)和更新比例
5、索引禁忌
(1) 不在低基數(shù)列上建立索引，例如“性別”
(2) 不在索引列進(jìn)行數(shù)學(xué)運(yùn)算和函數(shù)運(yùn)算
6、盡量不使用外鍵
(1) 外鍵用來(lái)保護(hù)參照完整性，可在業(yè)務(wù)端實(shí)現(xiàn)
(2) 對(duì)父表和子表的操作會(huì)相互影響，降低可用性
7、索引命名：非唯一索引必須以 idx_字段1_字段2命名，唯一所以必須以u(píng)niq_字段1_字段2命名，索引名稱(chēng)必須全部小寫(xiě)
8、新建的唯一索引必須不能和主鍵重復(fù)
9、索引字段的默認(rèn)值不能為NULL，要改為其他的default或者空。NULL非常影響索引的查詢(xún)效率
10、反復(fù)查看與表相關(guān)的SQL，符合最左前綴的特點(diǎn)建立索引。多條字段重復(fù)的語(yǔ)句，要修改語(yǔ)句條件字段的順序，為其建立一條聯(lián)合索引，減少索引數(shù)量
11、能使用唯一索引就要使用唯一索引，提高查詢(xún)效率
12、研發(fā)要經(jīng)常使用explain，如果發(fā)現(xiàn)索引選擇性差，必須讓他們學(xué)會(huì)使用hint
五.SQL規(guī)范
(1) sql語(yǔ)句盡可能簡(jiǎn)單
大的sql想辦法拆成小的sql語(yǔ)句(充分利用QUERY CACHE和充分利用多核CPU)
(2) 事務(wù)要簡(jiǎn)單，整個(gè)事務(wù)的時(shí)間長(zhǎng)度不要太長(zhǎng)
(3) 避免使用觸發(fā)器、函數(shù)、存儲(chǔ)過(guò)程
(4) 降低業(yè)務(wù)耦合度，為sacle out、sharding留有余地
(5) 避免在數(shù)據(jù)庫(kù)中進(jìn)數(shù)學(xué)運(yùn)算(MySQL不擅長(zhǎng)數(shù)學(xué)運(yùn)算和邏輯判斷)
(6) 不要用select *，查詢(xún)哪幾個(gè)字段就select 這幾個(gè)字段
(7) sql中使用到OR的改寫(xiě)為用 IN() (or的效率沒(méi)有in的效率高)
(8) in里面數(shù)字的個(gè)數(shù)建議控制在1000以?xún)?nèi)
(9) limit分頁(yè)注意效率。Limit越大，效率越低?？梢愿膶?xiě)limit，比如例子改寫(xiě)：
select id from tlimit 10000, 10; => select id from t where id > 10000 limit10;
(10) 使用union all替代union
(11） 避免使大表的JOIN
(12) 使用group by 分組、自動(dòng)排序
(13) 對(duì)數(shù)據(jù)的更新要打散后批量更新，不要一次更新太多數(shù)據(jù)
(14) 減少與數(shù)據(jù)庫(kù)的交互次數(shù)
(15) 注意使用性能分析工具
Sql explain / showprofile / mysqlsla
https://blog.csdn.net/ls3648098/article/details/9303237
(16) SQL語(yǔ)句要求所有研發(fā)，SQL關(guān)鍵字全部是大寫(xiě)，每個(gè)詞只允許有一個(gè)空格
(17) SQL語(yǔ)句不可以出現(xiàn)隱式轉(zhuǎn)換，比如 select id from 表 where id='1'
(18) IN條件里面的數(shù)據(jù)數(shù)量要少，我記得應(yīng)該是500個(gè)以?xún)?nèi)，要學(xué)會(huì)使用exist代替in，exist在一些場(chǎng)景查詢(xún)會(huì)比in快
(19) 能不用NOT IN就不用NOTIN，坑太多了。。會(huì)把空和NULL給查出來(lái)
(20) 在SQL語(yǔ)句中，禁止使用前綴是%的like
(21) 不使用負(fù)向查詢(xún)，如not in/like
(22) 關(guān)于分頁(yè)查詢(xún)：程序里建議合理使用分頁(yè)來(lái)提高效率limit，offset較大要配合子查詢(xún)使用
(23) 禁止在數(shù)據(jù)庫(kù)中跑大查詢(xún)
(24) 使預(yù)編譯語(yǔ)句，只傳參數(shù)，比傳遞SQL語(yǔ)句更高效；一次解析，多次使用；降低SQL注入概率
(25) 禁止使order by rand()
(26) 禁單條SQL語(yǔ)句同時(shí)更新多個(gè)表
六.流程規(guī)范
(1) 所有的建表操作需要提前告知該表涉及的查詢(xún)sql；
(2) 所有的建表需要確定建立哪些索引后才可以建表上線(xiàn)；
(3) 所有的改表結(jié)構(gòu)、加索引操作都需要將涉及到所改表的查詢(xún)sql發(fā)出來(lái)告知DBA等相關(guān)人員；
(4) 在建新表加字段之前，要求研發(fā)至少要提前3天郵件出來(lái)，給dba們?cè)u(píng)估、優(yōu)化和審核的時(shí)間
(5) 批量導(dǎo)入、導(dǎo)出數(shù)據(jù)必須提前通知DBA協(xié)助觀察
(6) 禁在線(xiàn)上從庫(kù)執(zhí)行后臺(tái)管理和統(tǒng)計(jì)類(lèi)查詢(xún)
(7) 禁有super權(quán)限的應(yīng)用程序賬號(hào)存在
(8) 推廣活動(dòng)或上線(xiàn)新功能必須提前通知DBA進(jìn)行流量評(píng)估
(9) 不在業(yè)務(wù)高峰期批量更新、查詢(xún)數(shù)據(jù)庫(kù)
六.配置優(yōu)化規(guī)范
(1) 開(kāi)啟慢查詢(xún)，用于sql語(yǔ)句分析。
(2) 開(kāi)啟二進(jìn)制日志，用于遇到mysql崩潰，數(shù)據(jù)恢復(fù)
(3) no-auto-rehash 確保這個(gè)服務(wù)啟動(dòng)得比較快。
(4) back_log = 600
在MYSQL暫時(shí)停止響應(yīng)新請(qǐng)求之前，短時(shí)間內(nèi)的多少個(gè)請(qǐng)求可以被存在堆棧中。如果系統(tǒng)在短時(shí)間內(nèi)有很多連接，則需要增大該參數(shù)的值，該參數(shù)值指定到來(lái)的TCP/IP連接的監(jiān)聽(tīng)隊(duì)列的大小。默認(rèn)值80。
(5) max_connections = 3000
#MySQL允許最大的進(jìn)程連接數(shù)，如果經(jīng)常出現(xiàn)Too Many Connections的錯(cuò)誤提示，則需要增大此值。默認(rèn)151
(6) max_connect_errors = 6000
#設(shè)置每個(gè)主機(jī)的連接請(qǐng)求異常中斷的最大次數(shù)，當(dāng)超過(guò)該次數(shù)，MYSQL服務(wù)器將禁止host的連接請(qǐng)求，直到mysql服務(wù)器重啟或通過(guò)flush hosts命令清空此host的相關(guān)信息。默認(rèn)100
(7) external-locking = FALSE
#使用–skip-external-locking MySQL選項(xiàng)以避免外部鎖定。該選項(xiàng)默認(rèn)開(kāi)啟
(8) max_allowed_packet = 32M
#設(shè)置在網(wǎng)絡(luò)傳輸中一次消息傳輸量的最大值。系統(tǒng)默認(rèn)值 為4MB，最大值是1GB，必須設(shè)置1024的倍數(shù)。
(9) sort_buffer_size = 2M
#Sort_Buffer_Size 是一個(gè)connection級(jí)參數(shù)，在每個(gè)connection（session）第一次需要使用這個(gè)buffer的時(shí)候，一次性分配設(shè)置的內(nèi)存。
#Sort_Buffer_Size 并不是越大越好，由于是connection級(jí)的參數(shù)，過(guò)大的設(shè)置+高并發(fā)可能會(huì)耗盡系統(tǒng)內(nèi)存資源。例如：500個(gè)連接將會(huì)消耗 500*sort_buffer_size(8M)=4G內(nèi)存
#Sort_Buffer_Size 超過(guò)2KB的時(shí)候，就會(huì)使用mmap() 而不是 malloc() 來(lái)進(jìn)行內(nèi)存分配，導(dǎo)致效率降低。 系統(tǒng)默認(rèn)2M，使用默認(rèn)值即可
(10)join_buffer_size = 2M
#用于表間關(guān)聯(lián)緩存的大小，和sort_buffer_size一樣，該參數(shù)對(duì)應(yīng)的分配內(nèi)存也是每個(gè)連接獨(dú)享。系統(tǒng)默認(rèn)2M，使用默認(rèn)值即可
(11)thread_cache_size = 300
#默認(rèn)38 服務(wù)器線(xiàn)程緩存這個(gè)值表示可以重新利用保存在緩存中線(xiàn)程的數(shù)量,當(dāng)斷開(kāi)連接時(shí)如果緩存中還有空間,那么客戶(hù)端的線(xiàn)程將被放到緩存中,如果線(xiàn)程重新被請(qǐng)求，那么請(qǐng)求將從緩存中讀取,如果緩存中是空的或者是新的請(qǐng)求，那么這個(gè)線(xiàn)程將被重新創(chuàng)建,如果有很多新的線(xiàn)程，增加這個(gè)值可以改善系統(tǒng)性能.通過(guò)比較 Connections 和 Threads_created 狀態(tài)的變量，可以看到這個(gè)變量的作用。設(shè)置規(guī)則如下：1GB 內(nèi)存配置為8，2GB配置為16，3GB配置為32，4GB或更高內(nèi)存，可配置更大。
(12)thread_concurrency = 8
#系統(tǒng)默認(rèn)為10，使用10先觀察 ,設(shè)置thread_concurrency的值的正確與否, 對(duì)mysql的性能影響很大, 在多個(gè)cpu(或多核)的情況下，錯(cuò)誤設(shè)置了thread_concurrency的值, 會(huì)導(dǎo)致mysql不能充分利用多cpu(或多核), 出現(xiàn)同一時(shí)刻只能一個(gè)cpu(或核)在工作的情況。thread_concurrency應(yīng)設(shè)為CPU核數(shù)的2倍. 比如有一個(gè)雙核的CPU, 那么thread_concurrency的應(yīng)該為4; 2個(gè)雙核的cpu, thread_concurrency的值應(yīng)為8
(13)query_cache_size = 64M
#在MyISAM引擎優(yōu)化中，這個(gè)參數(shù)也是一個(gè)重要的優(yōu)化參數(shù)。但也爆露出來(lái)一些問(wèn)題。機(jī)器的內(nèi)存越來(lái)越大，習(xí)慣性把參數(shù)分配的值越來(lái)越大。這個(gè)參數(shù)加大后也引發(fā)了一系列問(wèn)題。我們首先分析一下 query_cache_size的工作原理：一個(gè)SELECT查詢(xún)?cè)贒B中工作后，DB會(huì)把該語(yǔ)句緩存下來(lái)，當(dāng)同樣的一個(gè)SQL再次來(lái)到DB里調(diào)用時(shí)，DB在該表沒(méi)發(fā)生變化的情況下把結(jié)果從緩存中返回給Client。這里有一個(gè)關(guān)建點(diǎn)，就是DB在利用Query_cache工作時(shí)，要求該語(yǔ)句涉及的表在這段時(shí)間內(nèi)沒(méi)有發(fā)生變更。那如果該表在發(fā)生變更時(shí)，Query_cache里的數(shù)據(jù)又怎么處理呢？首先要把Query_cache和該表相關(guān)的語(yǔ)句全部置為失效，然后在寫(xiě)入更新。那么如果Query_cache非常大，該表的查詢(xún)結(jié)構(gòu)又比較多，查詢(xún)語(yǔ)句失效也慢，一個(gè)更新或是Insert就會(huì)很慢，這樣看到的就是Update或是Insert怎么這么慢了。所以在數(shù)據(jù)庫(kù)寫(xiě)入量或是更新量也比較大的系統(tǒng)，該參數(shù)不適合分配過(guò)大。而且在高并發(fā)，寫(xiě)入量大的系統(tǒng)，建議把該功能禁掉。
(14)query_cache_limit = 4M
#指定單個(gè)查詢(xún)能夠使用的緩沖區(qū)大小，缺省為1M
(15)query_cache_min_res_unit = 2k
#默認(rèn)是4KB，設(shè)置值大對(duì)大數(shù)據(jù)查詢(xún)有好處，但如果你的查詢(xún)都是小數(shù)據(jù)查詢(xún)，就容易造成內(nèi)存碎片和浪費(fèi)
#查詢(xún)緩存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%
#如果查詢(xún)緩存碎片率超過(guò)20%，可以用FLUSH QUERY CACHE整理緩存碎片，或者試試減小query_cache_min_res_unit，如果你的查詢(xún)都是小數(shù)據(jù)量的話(huà)。
#查詢(xún)緩存利用率 = (query_cache_size – Qcache_free_memory) / query_cache_size * 100%
#查詢(xún)緩存利用率在25%以下的話(huà)說(shuō)明query_cache_size設(shè)置的過(guò)大，可適當(dāng)減小;查詢(xún)緩存利用率在80%以上而且Qcache_lowmem_prunes > 50的話(huà)說(shuō)明query_cache_size可能有點(diǎn)小，要不就是碎片太多。
#查詢(xún)緩存命中率 = (Qcache_hits – Qcache_inserts) / Qcache_hits * 100%
(16)thread_stack = 192K
#設(shè)置MYSQL每個(gè)線(xiàn)程的堆棧大小，默認(rèn)值足夠大，可滿(mǎn)足普通操作?？稍O(shè)置范圍為128K至4GB，默認(rèn)為256KB，使用默認(rèn)觀察
(17)transaction_isolation = READ-COMMITTED
# 設(shè)定默認(rèn)的事務(wù)隔離級(jí)別.可用的級(jí)別如下:READ UNCOMMITTED-讀未提交 READ COMMITTE-讀已提交 REPEATABLE READ -可重復(fù)讀 SERIALIZABLE -串行
(18)tmp_table_size = 256M
# tmp_table_size 的默認(rèn)大小是 32M。如果一張臨時(shí)表超出該大小，MySQL產(chǎn)生一個(gè) The table tbl_name is full 形式的錯(cuò)誤，如果你做很多高級(jí) GROUP BY 查詢(xún)，增加 tmp_table_size 值。如果超過(guò)該值，則會(huì)將臨時(shí)表寫(xiě)入磁盤(pán)。
(18)max_heap_table_size = 256M
(19)expire_logs_days = 7
(20)key_buffer_size = 2048M
#批定用于索引的緩沖區(qū)大小，增加它可以得到更好的索引處理性能，對(duì)于內(nèi)存在4GB左右的服務(wù)器來(lái)說(shuō)，該參數(shù)可設(shè)置為256MB或384MB。
(21)read_buffer_size = 1M
#默認(rèn)128K
# MySql讀入緩沖區(qū)大小。對(duì)表進(jìn)行順序掃描的請(qǐng)求將分配一個(gè)讀入緩沖區(qū)，MySql會(huì)為它分配一段內(nèi)存緩沖區(qū)。read_buffer_size變量控制這一緩沖區(qū)的大小。如果對(duì)表的順序掃描請(qǐng)求非常頻繁，并且你認(rèn)為頻繁掃描進(jìn)行得太慢，可以通過(guò)增加該變量值以及內(nèi)存緩沖區(qū)大小提高其性能。和sort_buffer_size一樣，該參數(shù)對(duì)應(yīng)的分配內(nèi)存也是每個(gè)連接獨(dú)享。
(22)read_rnd_buffer_size = 16M
# MySql的隨機(jī)讀（查詢(xún)操作）緩沖區(qū)大小。當(dāng)按任意順序讀取行時(shí)(例如，按照排序順序)，將分配一個(gè)隨機(jī)讀緩存區(qū)。進(jìn)行排序查詢(xún)時(shí)，MySql會(huì)首先掃描一遍該緩沖，以避免磁盤(pán)搜索，提高查詢(xún)速度，如果需要排序大量數(shù)據(jù)，可適當(dāng)調(diào)高該值。但MySql會(huì)為每個(gè)客戶(hù)連接發(fā)放該緩沖空間，所以應(yīng)盡量適當(dāng)設(shè)置該值，以避免內(nèi)存開(kāi)銷(xiāo)過(guò)大。
(23)bulk_insert_buffer_size = 64M
#批量插入數(shù)據(jù)緩存大小，可以有效提高插入效率，默認(rèn)為8M
(24)myisam_sort_buffer_size = 128M
# MyISAM表發(fā)生變化時(shí)重新排序所需的緩沖 默認(rèn)8M
(25)myisam_max_sort_file_size = 10G
# MySQL重建索引時(shí)所允許的最大臨時(shí)文件的大小 (當(dāng) REPAIR, ALTER TABLE 或者 LOAD DATA INFILE).
# 如果文件大小比此值更大,索引會(huì)通過(guò)鍵值緩沖創(chuàng)建(更慢)
(26)myisam_max_extra_sort_file_size = 10G 5.6無(wú)此值設(shè)置
(27)myisam_repair_threads = 1 默認(rèn)為1
# 如果一個(gè)表?yè)碛谐^(guò)一個(gè)索引, MyISAM 可以通過(guò)并行排序使用超過(guò)一個(gè)線(xiàn)程去修復(fù)他們.
# 這對(duì)于擁有多個(gè)CPU以及大量?jī)?nèi)存情況的用戶(hù),是一個(gè)很好的選擇.
(28)innodb_additional_mem_pool_size = 16M
#這個(gè)參數(shù)用來(lái)設(shè)置 InnoDB 存儲(chǔ)的數(shù)據(jù)目錄信息和其它內(nèi)部數(shù)據(jù)結(jié)構(gòu)的內(nèi)存池大小，類(lèi)似于Oracle的library cache。這不是一個(gè)強(qiáng)制參數(shù)，可以被突破。
(29)innodb_buffer_pool_size = 2048M
# 這對(duì)Innodb表來(lái)說(shuō)非常重要。Innodb相比MyISAM表對(duì)緩沖更為敏感。MyISAM可以在默認(rèn)的 key_buffer_size 設(shè)置下運(yùn)行的可以，然而Innodb在默認(rèn)的 innodb_buffer_pool_size 設(shè)置下卻跟蝸牛似的。由于Innodb把數(shù)據(jù)和索引都緩存起來(lái)，無(wú)需留給操作系統(tǒng)太多的內(nèi)存，因此如果只需要用Innodb的話(huà)則可以設(shè)置它高達(dá) 70-80% 的可用內(nèi)存。一些應(yīng)用于 key_buffer 的規(guī)則有 — 如果你的數(shù)據(jù)量不大，并且不會(huì)暴增，那么無(wú)需把 innodb_buffer_pool_size 設(shè)置的太大了
(30)#innodb_data_file_path = ibdata1:1024M:autoextend 設(shè)置過(guò)大導(dǎo)致報(bào)錯(cuò)，默認(rèn)12M觀察
#表空間文件 重要數(shù)據(jù)
(31)#innodb_file_io_threads = 4 不明確，使用默認(rèn)值
#文件IO的線(xiàn)程數(shù)，一般為 4，但是在 Windows 下，可以設(shè)置得較大。
(32)innodb_thread_concurrency = 8
#服務(wù)器有幾個(gè)CPU就設(shè)置為幾，建議用默認(rèn)設(shè)置，一般為8.
(33)innodb_flush_log_at_trx_commit = 2
# 如果將此參數(shù)設(shè)置為1，將在每次提交事務(wù)后將日志寫(xiě)入磁盤(pán)。為提供性能，可以設(shè)置為0或2，但要承擔(dān)在發(fā)生故障時(shí)丟失數(shù)據(jù)的風(fēng)險(xiǎn)。設(shè)置為0表示事務(wù)日志寫(xiě)入日志文件，而日志文件每秒刷新到磁盤(pán)一次。設(shè)置為2表示事務(wù)日志將在提交時(shí)寫(xiě)入日志，但日志文件每次刷新到磁盤(pán)一次。
(34)#innodb_log_buffer_size = 16M 使用默認(rèn)8M
#此參數(shù)確定些日志文件所用的內(nèi)存大小，以M為單位。緩沖區(qū)更大能提高性能，但意外的故障將會(huì)丟失數(shù)據(jù).MySQL開(kāi)發(fā)人員建議設(shè)置為1－8M之間
(35)#innodb_log_file_size = 128M 使用默認(rèn)48M
#此參數(shù)確定數(shù)據(jù)日志文件的大小，以M為單位，更大的設(shè)置可以提高性能，但也會(huì)增加恢復(fù)故障數(shù)據(jù)庫(kù)所需的時(shí)間
(36)#innodb_log_files_in_group = 3 使用默認(rèn)2
#為提高性能，MySQL可以以循環(huán)方式將日志文件寫(xiě)到多個(gè)文件。推薦設(shè)置為3M
(37)#innodb_max_dirty_pages_pct = 90 使用默認(rèn)75觀察
# Buffer_Pool中Dirty_Page所占的數(shù)量，直接影響InnoDB的關(guān)閉時(shí)間。參數(shù)innodb_max_dirty_pages_pct 可以直接控制了Dirty_Page在Buffer_Pool中所占的比率，而且幸運(yùn)的是innodb_max_dirty_pages_pct是可以動(dòng)態(tài)改變的。所以，在關(guān)閉InnoDB之前先將innodb_max_dirty_pages_pct調(diào)小，強(qiáng)制數(shù)據(jù)塊Flush一段時(shí)間，則能夠大大縮短 MySQL關(guān)閉的時(shí)間。
(38)innodb_lock_wait_timeout = 120
#默認(rèn)為50秒 InnoDB 有其內(nèi)置的死鎖檢測(cè)機(jī)制，能導(dǎo)致未完成的事務(wù)回滾。但是，如果結(jié)合InnoDB使用MyISAM的lock tables 語(yǔ)句或第三方事務(wù)引擎,則InnoDB無(wú)法識(shí)別死鎖。為消除這種可能性，可以將innodb_lock_wait_timeout設(shè)置為一個(gè)整數(shù)值，指示 MySQL在允許其他事務(wù)修改那些最終受事務(wù)回滾的數(shù)據(jù)之前要等待多長(zhǎng)時(shí)間(秒數(shù))
(39)innodb_file_per_table = 0
#默認(rèn)為No #獨(dú)享表空間（關(guān)閉）
