葉問【轉(zhuǎn)自知數(shù)堂微信公眾號】

轉(zhuǎn)自

《葉問》是知數(shù)堂新設(shè)計(jì)的互動(dòng)欄目，不定期給大家提供技術(shù)知識小貼士，形式不限，或提問、或討論均可，并在當(dāng)天發(fā)布答案，讓大家輕輕松松利用碎片時(shí)間就可以學(xué)到最實(shí)用的知識點(diǎn)。

知數(shù)堂 - 最靠譜、最有品質(zhì)的培訓(xùn)品牌 http://www.3wedu.net/

 葉問專輯 https://mp.weixin.qq.com/mp/homepage?__biz=MzI1OTU2MDA4NQ%3D%3D&hid=15&sn=8a530aa309c1fe6e4d99b3a0d49a9695

2018年6月10日，周日

MySQL主從復(fù)制什么原因會(huì)造成不一致，如何預(yù)防及解決？

一、導(dǎo)致主從不一致的原因主要有： 

1. 人為原因?qū)е聫膸炫c主庫數(shù)據(jù)不一致（從庫寫入）

2. 主從復(fù)制過程中，主庫異常宕機(jī)

3. 設(shè)置了ignore/do/rewrite等replication等規(guī)則

4. binlog非row格式

5. 異步復(fù)制本身不保證，半同步存在提交讀的問題，增強(qiáng)半同步起來比較完美。 但對于異常重啟（Replication Crash Safe），從庫寫數(shù)據(jù)（GTID）的防范，還需要策略來保證。

6. 從庫中斷很久，binlog應(yīng)用不連續(xù)，監(jiān)控并及時(shí)修復(fù)主從

7. 從庫啟用了諸如存儲過程，從庫禁用存儲過程等

8. 數(shù)據(jù)庫大小版本/分支版本導(dǎo)致數(shù)據(jù)不一致？，主從版本統(tǒng)一

9. 備份的時(shí)候沒有指定參數(shù) 例如mysqldump --master-data=2 等

10. 主從sql_mode 不一致

11. 一主二從環(huán)境，二從的server id一致

12. MySQL自增列 主從不一致

13. 主從信息保存在文件里面，文件本身的刷新是非事務(wù)的，導(dǎo)致從庫重啟后開始執(zhí)行點(diǎn)大于實(shí)際執(zhí)行點(diǎn)

14. 采用5.6的after_commit方式半同步，主庫當(dāng)機(jī)可能會(huì)引起主從不一致，要看binlog是否傳到了從庫

15. 啟用增強(qiáng)半同步了（5.7的after_sync方式），但是從庫延遲超時(shí)自動(dòng)切換成異步復(fù)制

     

二、預(yù)防和解決的方案有：

1. master:innodb_flush_log_at_trx_commit=1&sync_binlog=1

2. slave:master_info_repository="TABLE"&relay_log_info_repository="TABLE"&relay_log_recovery=1

3. 設(shè)置從庫庫為只讀模式

4. 可以使用5.7增強(qiáng)半同步避免數(shù)據(jù)丟失等

5. binlog row格式

6. 必須引定期的數(shù)據(jù)校驗(yàn)機(jī)制

7. 當(dāng)使用延遲復(fù)制的時(shí)候，此時(shí)主從數(shù)據(jù)也是不一致的（計(jì)劃內(nèi)），但在切換中，不要把延遲從提升為主庫哦~

8. mha在主從切換的過程中，因主庫系統(tǒng)宕機(jī)，可能造成主從不一致（mha本身機(jī)制導(dǎo)致這個(gè)問題）

2018年6月11日，周一

你為什么會(huì)決定進(jìn)行分庫分表，分庫分表過程中遇到什么難題，如何解決的？

一、為什么決定進(jìn)行分庫分表？

1. 根據(jù)業(yè)務(wù)類型，和業(yè)務(wù)容量的評估，來選擇和判斷是否使用分庫分表

2. 當(dāng)前數(shù)據(jù)庫本事具有的能力，壓力的評估

3. 數(shù)據(jù)庫的物理隔離，例如減少鎖的爭用、資源的消耗和隔離等

4. 熱點(diǎn)表較多,并且數(shù)據(jù)量大，可能會(huì)導(dǎo)致鎖爭搶，性能下降

5. 數(shù)據(jù)庫的高并發(fā)，數(shù)據(jù)庫的讀寫壓力過大，可能會(huì)導(dǎo)致數(shù)據(jù)庫或系統(tǒng)宕機(jī)

6. 數(shù)據(jù)庫（MySQL5.7以下）連接數(shù)過高，會(huì)增加系統(tǒng)壓力

7. 單表數(shù)據(jù)量大，如SQL使用不當(dāng)，會(huì)導(dǎo)致io隨機(jī)讀寫比例高。查詢慢（大表上的B+樹太大，掃描太慢，甚至可能需要4層B+樹）

8. 備份和恢復(fù)時(shí)間比較長

    

二、都遇到什么問題?

1. 全局pk（主鍵和唯一索引）的沖突檢測不準(zhǔn)確，全局的自增主鍵支持不夠好

2. 分片鍵的選擇。如沒有選擇好，可能會(huì)影響SQL執(zhí)行效率

3. 分布式事務(wù)，中間價(jià)產(chǎn)品對分布式事務(wù)的支持力度

4. 對于開發(fā)來說，需要進(jìn)行業(yè)務(wù)的拆分

5. 對于開發(fā)來說，部分SQL不兼容則需要代碼重構(gòu)，工作量的評估

6. 對于開發(fā)來說，跨庫join，跨庫查詢

三、如何解決?

1. 使用全局分號器。或者使用全局唯一id，（應(yīng)用生成順序唯一int類型做為全局主鍵）

2. 應(yīng)用層來判斷唯一索引

3. 配合應(yīng)用選擇合適的分片鍵，并加上索引

4. 配合應(yīng)用，配合開發(fā)，對不兼容SQL的進(jìn)行整改

2018年6月12日，周二

MySQL高可用架構(gòu)應(yīng)該考慮什么? 你認(rèn)為應(yīng)該如何設(shè)計(jì)？

一、MySQL高可用架構(gòu)應(yīng)該考慮什么？

1. 對業(yè)務(wù)的了解，需要考慮業(yè)務(wù)對數(shù)據(jù)庫一致性要求的敏感程度，切換過程中是否有事務(wù)會(huì)丟失

2. 對于基礎(chǔ)設(shè)施的了解，需要了解基礎(chǔ)設(shè)施的高可用的架構(gòu)。例如 單網(wǎng)線，單電源等情況 

3. 對于數(shù)據(jù)庫故障時(shí)間掌握，業(yè)務(wù)方最多能容忍時(shí)間范圍，因?yàn)楦呖捎们袚Q導(dǎo)致的應(yīng)用不可用時(shí)間

4. 需要了解主流的高可用的優(yōu)缺點(diǎn)：例如 MHA/PXC/MGR 等。

5. 考慮多IDC多副本分布，支持IDC級別節(jié)點(diǎn)全部掉線后，業(yè)務(wù)可以切到另一個(gè)機(jī)房

二、你認(rèn)為應(yīng)該如何設(shè)計(jì)? 

1. 基礎(chǔ)層 和基礎(chǔ)運(yùn)維部門配合，了解和避免網(wǎng)絡(luò)/ 硬盤/ 電源等是否會(huì)出現(xiàn)單點(diǎn)故障 

2. 應(yīng)用層 和應(yīng)用開發(fā)同學(xué)配合，在關(guān)鍵業(yè)務(wù)中記錄SQL日志，可以做到即使切換，出現(xiàn)丟事務(wù)的情況，也可以通過手工補(bǔ)的方式保證數(shù)據(jù)一致性，例如：交易型的業(yè)務(wù)引入狀態(tài)機(jī)，事務(wù)狀態(tài)，應(yīng)對數(shù)據(jù)庫切換后事務(wù)重做 

3. 業(yè)務(wù)層 了解自己的應(yīng)用，根據(jù)不同的應(yīng)用制定合理的高可用策略。 

4. 單機(jī)多實(shí)例 環(huán)境及基于虛擬機(jī)或容器的設(shè)計(jì)不能分布在同一臺物理機(jī)上。 

5. 最終大招 在數(shù)據(jù)庫不可用 ，可以把已提及的事務(wù)先存儲到隊(duì)列或者其他位置，等數(shù)據(jù)庫恢復(fù)，重新應(yīng)用

2018年6月13日，周三

MySQL備份，使用xtrabackup備份全實(shí)例數(shù)據(jù)時(shí)，會(huì)造成鎖等待嗎？那么如果使用mysqldump進(jìn)行備份呢？

一、xtrabackup和mysqldump會(huì)造成鎖等待嗎？ 

1. xtrabackup會(huì)，它在備份時(shí)會(huì)產(chǎn)生短暫的全局讀鎖FTWL(flush table with read lock)，用于拷貝frm/MYD/MYI等文件，以及記錄binlog信息。如果MyISAM表的數(shù)據(jù)量非常大，則拷貝時(shí)間就越長，加鎖的時(shí)間也越長

2. mysqldump有可能會(huì)。如果只是添加 --single-transacton 選項(xiàng)用于保證備份數(shù)據(jù)一致性，這時(shí)就不會(huì)產(chǎn)生FTWL鎖了。但通常我們?yōu)榱俗寕浞菸募蚥inlog保持一致，通常也會(huì)設(shè)置 --master-data 選項(xiàng)用于獲得當(dāng)前binlog信息，這種情況也會(huì)短暫加鎖

3. 數(shù)據(jù)量特別大的話，建議優(yōu)先用 xtrabackup，提高備份/恢復(fù)速度。而如果數(shù)據(jù)量不是太大或者想備份單表，則建議用mysqldump了，方便邏輯恢復(fù)。各有利弊，注意其適用場景

二、xtrabackup冷知識

1. 基于MySQL 5.6版本開發(fā)的xtrabackup，會(huì)在備份過程中生成內(nèi)部通信文件 suspend file，用于 xtrabackup 和 innobackupex 的通信，備份結(jié)束后文件刪除，默認(rèn)文件位置 /tmp/xtrabackup_suspended 

2. 如果在備份過程中，修改了 /tmp 的訪問權(quán)限或該文件的權(quán)限，則兩個(gè)程序間直接不能通信，會(huì)造成 xtrabackup hang 住，正在備份的表不能正常釋放鎖，會(huì)造成鎖等待，此時(shí)需要強(qiáng)制 kill 掉 xtrabackup 進(jìn)程

2018年6月15日，周五

MySQL 5.7開始支持JSON，那還有必要使用MongoDB存JSON嗎？請列出你的觀點(diǎn)/理由。

一、觀點(diǎn)A：支持MySQL存儲JSON

1.MongoDB不支持事務(wù)，而MySQL支持事務(wù)

2.MySQL相對MongoDB而言，MySQL的穩(wěn)定性要優(yōu)于MongoDB

3.MySQL支持多種存儲引擎

二、觀點(diǎn)B:支持MongoDB存儲JSON 

1.從性能的角度考慮，對于JSON讀寫效率MongoDB要優(yōu)于MySQL

2.MongoDB相對MySQL而言，MongoDB的擴(kuò)展性要優(yōu)于MySQL

3.MongoDB支持更多的JSON函數(shù)

三、總結(jié)

1.如果應(yīng)用程序無事務(wù)要求，存儲數(shù)據(jù)表結(jié)構(gòu)復(fù)雜并且經(jīng)常被修改， 例如游戲中裝備等場景用MongoDB比較適合

2.如果應(yīng)用程序有事務(wù)要求，存儲數(shù)據(jù)的"表"之間相互有關(guān)聯(lián)，例如有訂單系統(tǒng)等場景用MySQL比較適合

3.整體來看相對看好MySQL的JSON功能，在未來官方的努力下MySQL的JSON功能有機(jī)會(huì)反超MongoDB

2018年6月17日，周日

當(dāng)數(shù)據(jù)被誤刪除/誤操作后造成數(shù)據(jù)丟失。你嘗試過用什么手段來挽救數(shù)據(jù)/損失？

一、前提 
1.當(dāng)數(shù)據(jù)被誤刪除/誤操作后，第一時(shí)間要關(guān)閉數(shù)據(jù)庫。業(yè)務(wù)方需要緊急掛停機(jī)公告，避免數(shù)據(jù)二次污染，用于保護(hù)數(shù)據(jù)的一致性

2.BINLOG格式為ROW格式，不討論其他格式的BINLOG

二、數(shù)據(jù)被誤操作(update/delete/drop)造成數(shù)據(jù)丟失，可以用哪些手段來恢復(fù)？ 

1.BINLOG恢復(fù)：可以使用逆向解析BINLOG工具來恢復(fù)。例如：binlog2SQL等

2.延遲從庫: 可以通過解除延遲從庫，并指定BINLOG結(jié)束位置點(diǎn)，可以實(shí)現(xiàn)數(shù)據(jù)恢復(fù)

三、數(shù)據(jù)被誤刪除(rm/物理文件損壞)造成數(shù)據(jù)丟失，可以用哪些手段來恢復(fù)？ 

1.如果有備份，可以通過備份恢復(fù) mysqldump/xtrabackup + binlog 來實(shí)現(xiàn)全量+增量恢復(fù)

2.如果無備份但是有從庫，可以通過主從切換，提升從庫為主庫，從而實(shí)現(xiàn)數(shù)據(jù)恢復(fù)

3.如果無備份并且無從庫，但MySQL沒有重啟，可以通過拷貝/proc/$pid/fd中的文件，來進(jìn)行嘗試恢復(fù)

4.如果無備份并且無從庫，但MySQL有重啟，可以通過extundelete或undrop-for-innodb來恢復(fù)

2018年6月19日，周二

MySQL 5.7的復(fù)制架構(gòu),在有異步復(fù)制、半同步、增強(qiáng)半同步、MGR等的生產(chǎn)中，該如何選擇？

一、生產(chǎn)環(huán)境中：  

幾種復(fù)制場景都有存在的價(jià)值。下面分別描述一下： 

1. 從成熟度上來選擇，推薦：異步復(fù)制(GTID+ROW)

2. 從數(shù)據(jù)安全及更高性能上選擇：增強(qiáng)半同步 （在這個(gè)結(jié)構(gòu)下也可以把innodb_flush_log_trx_commit調(diào)整到非1， 從而獲得更好的性能)

3. 對于主從切換控制覺的不好管理，又對數(shù)據(jù)一致性要求特別高的場景，可以使用MGR

二、理由：

1. 異步復(fù)制，相對來講非常成熟，對于環(huán)境運(yùn)維也比較容易上手 

2. 增強(qiáng)半同步復(fù)制，可以安全的保證數(shù)據(jù)傳輸?shù)綇膸焐?，對于單?jié)點(diǎn)的配置上不用要求太嚴(yán)格，特別從庫上也可以更寬松一點(diǎn)，而且在一致性和性能有較高的提升，但對運(yùn)維上有一定的要求

3. MGR組復(fù)制。相對增強(qiáng)半同步復(fù)制，MGR更能確保數(shù)據(jù)的一致性，事務(wù)的提交，必須經(jīng)過組內(nèi)大多數(shù)節(jié)點(diǎn)（n/2+1）決議并通過，才能得以提交。MGR架構(gòu)對運(yùn)維難度要更高，不過它也更完美

總的來講，從技術(shù)實(shí)現(xiàn)上來看：MGR> 增強(qiáng)半同步>異步復(fù)制。

未來可能見到更多的MGR在生產(chǎn)中使用，對于MySQL的運(yùn)維的要求也會(huì)更上一層樓。

2018年6月20日，周三

為什么說pt-osc可能會(huì)引起主從延遲，有什么好辦法解決或規(guī)避嗎？

• 若復(fù)制中binlog使用row格式，對大表使用pt-osc把數(shù)據(jù)從舊表拷貝到臨時(shí)表，期間會(huì)產(chǎn)生大量的binlog，從而導(dǎo)致延時(shí)

• pt-osc在搬數(shù)據(jù)過程中insert...select是有行鎖的，會(huì)降低事務(wù)并行度；且pt-osc搬數(shù)據(jù)過程中生成的binlog不是并行的，所以在slave不能并行回放

• 可以通過設(shè)定參數(shù) --chunk-size、--chunk-time控制每次拷貝數(shù)據(jù)大小，也可以設(shè)定--max-log、check-interval、check-slave-lag等參數(shù)控制主從復(fù)制延遲程度（但這樣可能會(huì)造成pt-osc工作耗時(shí)太久，需要自行權(quán)衡）

2018年6月21日，周四

你遇到過哪些原因造成MySQL異步復(fù)制延遲？

1. master上多為并發(fā)事務(wù)，salve上則多為單線程回放（MySQL 5.7起，支持真正的并行回放，有所緩解）

2. 異步復(fù)制，本來就是有一定延遲的（否則也不叫做異步了，介意的話可以改成半同步復(fù)制）

3. slave機(jī)器一般性能比master更弱（這是很常見的誤區(qū)，其實(shí)slave對機(jī) 器性能要求并不低）

4. 有時(shí)為了節(jié)省機(jī)器資源，會(huì)在slave上運(yùn)行多個(gè)實(shí)例

5. 表結(jié)構(gòu)設(shè)計(jì)不合理，尤其是在MySQL 5.6之前沒主鍵，幾乎會(huì)造成所有更新都全表掃描一遍，效率非常低

6. slave上運(yùn)行大量只讀低效率的SQL

7. 大量大事務(wù)，也會(huì)造成slave無法并行回放 

8. 業(yè)務(wù)設(shè)計(jì)缺陷，或網(wǎng)絡(luò)延遲等導(dǎo)致延遲

2018年6月22日，周五

MySQL每天產(chǎn)生了多大容量的binlog，用SQL語句能查到嗎？

首先，這是個(gè)假設(shè)性命題（又一個(gè)釣魚題）。 
這個(gè)需求完全可以通過系統(tǒng)層命令，配合MySQL中的“FLUSH BINARY LOGS”快速完成。 
運(yùn)行SHOW MASTER/BINARY LOGS命令能查看全部binlog列表，但沒辦法區(qū)別哪些是當(dāng)天內(nèi)生成的。

2018年6月23日，周六

用什么方法可以防止誤刪數(shù)據(jù)？

以下幾個(gè)措施可以防止誤刪數(shù)據(jù)，如下： 

1. 生產(chǎn)環(huán)境中，業(yè)務(wù)代碼盡量不明文保存數(shù)據(jù)庫連接賬號密碼信息

2. 重要的DML、DDL通過平臺型工具自動(dòng)實(shí)施，減少人工操作

3. 部署延遲復(fù)制從庫，萬一誤刪除時(shí)用于數(shù)據(jù)回檔，且從庫設(shè)置為read-only

4. 確認(rèn)備份制度及時(shí)有效

5. 啟用SQL審計(jì)功能，養(yǎng)成良好SQL習(xí)慣

6. 啟用 sql_safe_updates 選項(xiàng)，不允許沒 WHERE 條件的更新/刪除

7. 將系統(tǒng)層的rm改為mv

8. 線上不進(jìn)行物理刪除，改為邏輯刪除（將row data標(biāo)記為不可用）

9. 啟用堡壘機(jī)，屏蔽高危SQL

10. 降低數(shù)據(jù)庫中普通賬號的權(quán)限級別

11. 務(wù)必開啟binlog

2018年6月24日，周日

MySQL 8.0相對于5.7的復(fù)制改進(jìn)，都有哪些呢 ？

宋利兵老師：《MySQL 8.0相對于5.7的復(fù)制改進(jìn)》 的公開課也討論了這個(gè)命題，簡單概括主要有兩部分：

一、普通復(fù)制功能改進(jìn) 

1. 新增WRITESET并行復(fù)制模式，提高并行度，降低延遲 

2. 在多源復(fù)制中，可在線動(dòng)態(tài)修改每個(gè)channel的filter rule，并且能在P_S中查看/監(jiān)控 

3. Binary Log中存儲更多元數(shù)據(jù)，并支持毫秒級別的延遲監(jiān)控 

4. 對JSON Documents的復(fù)制效率更高了 

5. 支持DDL Crashsafe 

6. 增加caching_sha2_password安全策略，提高復(fù)制安全性

二、MGR功能改進(jìn):

1. 支持設(shè)置節(jié)點(diǎn)權(quán)重，且權(quán)重最大的在線節(jié)點(diǎn)將被選舉為主 

2. 每個(gè)節(jié)點(diǎn)中存儲更多的狀態(tài)信息，如版本、角色等 

3. 可根據(jù)從節(jié)點(diǎn)的事務(wù)狀態(tài)，自動(dòng)化流控 

4. 離開集群的服務(wù)器自動(dòng)被設(shè)置為read only，避免被誤操作更新數(shù)據(jù) 

5. 可監(jiān)控MGR的內(nèi)存使用情況

2018年6月25日，周一

跑truncate table，4億條數(shù)據(jù)會(huì)不會(huì)造成長時(shí)間鎖表呢?有什么更好的方法嗎?

最好是create新表，然后交叉rename對調(diào)，再drop/truncate table或其他方式清除數(shù)據(jù)。 

一、可操作步驟： 

1. 創(chuàng)建新的 tmp 表，正式表與tmp表表名交換（注意在一個(gè)SQL里完成，并鎖表） 

2. 對 tmp 表創(chuàng)建硬鏈接 ln tmp.ibd tmp.ibd.hdlk 

3. mysql中刪除表tmp（truncate / drop 都行）

4. 然后找個(gè)業(yè)務(wù)不繁忙的時(shí)間刪除數(shù)據(jù)文件或者用coreutils 的truncate慢慢搞 

二、關(guān)于truncate table，官檔解釋：

Logically, TRUNCATE TABLE is similar to a DELETE statement that deletes all rows, or a sequence of DROP TABLE and CREATE TABLE statements 
When a table is truncated, it is dropped and re-created in a new .ibd file, and the freed space is returned to the operating system

2018年6月26日，周二

明明有個(gè)索引“感覺”應(yīng)該被選中，EXPLAIN時(shí)在possible_keys也有它，但最后沒被選中，可能的原因有哪些？ 

一、執(zhí)行計(jì)劃如下：

desc select * from t1 where c2 >= 2; 
key: NULL 
key_len: NULL 
rows: 14 
filtered: 92.86 
Extra: Using where

二、可能的原因如下： 

1. 隱式轉(zhuǎn)換

2. 表碎片，因?yàn)楸淼乃槠蔬^高

3. 根據(jù)索引讀取到的數(shù)據(jù)在整個(gè)表中的數(shù)據(jù)占比超過30%

4. 統(tǒng)計(jì)信息沒有及時(shí)更新

三、上述執(zhí)行計(jì)劃的結(jié)果是 ：

預(yù)計(jì)掃描的行數(shù)為14行，filtered（是指返回結(jié)果的行占需要讀到的行的百分比）的值為92%。

當(dāng)前執(zhí)行計(jì)劃中filtered值92% 說明根據(jù)索引查詢獲取的結(jié)果占整張表的92%，在MySQL中根據(jù)索引查詢的結(jié)果占整張表的數(shù)據(jù)30%則不會(huì)走索，所以不會(huì)走索引。 
另外，也有可能是表的碎片率過高或隱式轉(zhuǎn)換導(dǎo)致的。

2018年6月27日，周三

主從復(fù)制線程均正常（為Yes，也沒報(bào)錯(cuò)），Master的binlog已到binlog.000100，但slave上看到Master_Log_File卻只到binlog.000090，可能的原因有哪些?

首先要注意，這是Master_Log_File IO線程延遲，并不是Relay_Master_Log_File SQL線程延遲。

一、可能的原因如下： 

1. 由于sync_relay_log值過低，導(dǎo)致Slave頻繁刷新relay_log文件，使 Slave的硬盤資源消耗過高，所以導(dǎo)致SlaveIO Thread很慢。 

2. Master/Slave壓力過大導(dǎo)致Slave IO Thread不能及時(shí)響應(yīng)， 無法及時(shí)獲得Master的event。 

3. 網(wǎng)絡(luò)丟包嚴(yán)重。小包可以連接并且保持連接不斷，但是大包就無法發(fā)送?？赡苁荕aster和Slave關(guān)于TCP MTU值設(shè)置不一致導(dǎo)致。 

4. Master和Slave網(wǎng)絡(luò)鏈接已經(jīng)斷開。但slave_net_timeout值等于0（表示完全禁用心跳）或者slave_net_timeout和Slave_heartbeat_period非常大（表示檢測主從心跳的時(shí)間）。 

5. Master的binlog非常大，io線程的file很長時(shí)間都在讀同一個(gè)。 

二、總結(jié) 
本次案例是在主庫進(jìn)行壓力測試，在壓力測試的過程中，因?yàn)镸aster本身的壓力就很大Master來不及把binlog發(fā)送給Slave。所以表面上看起來沒有延遲，但實(shí)際上已經(jīng)產(chǎn)生了延遲。

。
2018年7月4日，周三

如何優(yōu)化Linux操作系統(tǒng)用于MySQL環(huán)境？

一、初級玩法 

1. 在BIOS及內(nèi)核層面關(guān)閉NUMA 

2. 在BIOS層面將CPU、內(nèi)存均設(shè)置最大性能模式 

3. 在BIOS層面關(guān)閉CPU節(jié)能模式 

4. 修改IO Scheduler為deadline 或 noop 

5. 使用xfs文件系統(tǒng)，掛載選項(xiàng)noatime、nodiratime、nobarrier 

6. 在內(nèi)核層面設(shè)置vm.swappiness<=5，vm.dirty_ratio<=10， vm.dirty_background_rati<=5 

7. 在內(nèi)核層面修改用戶可最大打開文件數(shù)和線程數(shù)為65535 

8. 禁用SWAP分區(qū)

二、高端玩法

1. 使用最新穩(wěn)定Linux發(fā)行版 

2. 升級各個(gè)硬件設(shè)備到最新穩(wěn)定firmware版本 

3. 使用SSD時(shí)，開啟TRIM功能，并且可以的話文件系統(tǒng)block size和SSD對齊 

4. 當(dāng)磁盤I/O存在瓶頸時(shí)，除了常規(guī)因素外，還需要關(guān)注中斷不均衡的可能性

2018年7月5日，周四

MySQL 8.0 InnoDB哪些新特性你最期待，為什么？

1. 數(shù)據(jù)字典全部采用InnoDB引擎存儲，支持DDL原子性、crash safe，metadata管理更完善 

2. 快速在線加新列（騰訊互娛DBA團(tuán)隊(duì)貢獻(xiàn)） 
3. 并行redo log，并提升redo log的I/O性能 
4. 新增倒序索引 
5. 增強(qiáng)CBO特性 
6. 消除了buffer pool mutex（Percona的貢獻(xiàn)） 
7. 自增ID持久化 
8. 行鎖增加SKIP LOCKED和NOWAIT特性選項(xiàng) 
9. 新增事務(wù)CATS特性，大大提升事務(wù)性能（Michigan大學(xué)貢獻(xiàn)） 
10. memcached plugin增強(qiáng) 
11. 增強(qiáng)JSON性能、功能 
12. 新增智能選項(xiàng) innodb_dedicated_server

2018年7月10日，周二

 MySQL hang的原因有哪些？ 

1. MySQL使用資源過高導(dǎo)致服務(wù)器太累扛不住。例如CPU、內(nèi)存、 I/O等開銷。 

2. 磁盤無可用空間。 

3. MySQL頻繁的創(chuàng)建和銷毀連接。 

4. MySQL使用的最大文件打開數(shù)和連接數(shù)，超過了操作系統(tǒng)的限制。 

5. MySQL的鎖不能有效的釋放。例如持有行鎖或者表鎖，造成了MDL等待。 

6. MySQL的bug導(dǎo)致的。 

導(dǎo)致MySQL hang住的原因有很多，不局限于上述因素，還需要機(jī)智的你來挖掘。

2018年7月12日，周四

專訪王曉偉老師，MySQL數(shù)據(jù)導(dǎo)入數(shù)據(jù)倉庫（Hadoop）有哪幾種方式？ 

1. 傳統(tǒng)方式，采用mysqldump等工具將數(shù)據(jù)文件上傳至HDFS 

2. 使用Sqoop Kettle等ETL工具，將數(shù)據(jù)表對應(yīng)導(dǎo)入Hive的數(shù)據(jù)表 

3. 使用kafka+flume方案，將mysql binlog通過流式采集的方式導(dǎo)入Hadoop 

4. 設(shè)計(jì)實(shí)現(xiàn)Hive的快照表、增量表、全量表，實(shí)現(xiàn)MySQL到Hive數(shù)據(jù)的增量導(dǎo)入，并支持分庫分表等特性。