知數堂·葉問
葉問(20190108)RDS上，MySQL實例中某張表數據小於tmp_table_size，但有查詢時會報錯臨時空間滿 The table '/data/mysql/zst/tmp/#sql_13975_23' is full。原因可能是什麼？
可能有下面幾種情況：
1、在SQL中執行group by、order by、distinct、union、多表update、子查詢、多表JOIN等情況下，可能需要生成內部臨時表，當內部臨時表超過tmp-table-size時，就會產生磁盤臨時表。
2、接上，若查詢包含BLOB、TEXT類型字段時，MySQL會直接使用磁盤臨時表。
3、雲數據庫購買的磁盤空間，是包括數據庫文件、日誌文件（binlog、relay log、error log等）、臨時文件&臨時表（關注 Created_tmp_disk_tables、Created_tmp_tables、Binlog_cache_disk_use、Binlog_stmt_cache_disk_use等指標）所消耗佔用的磁盤空間。
4、發生table...is full報錯，說明可能生成磁盤臨時表太多，超過雲數據庫購買的空間限制。
解決辦法可以有：
1、關注slow query log，或者查看processlist，及時發現需要用到臨時文件、臨時表的SQL，儘快優化。
2、調高 tmp_table_size 參數值來調高內存臨時表的上限。
3、調高參數loose_rds_max_tmp_disk_space值，可設置爲當前空閒空間的80%（阿里雲RDS專屬參數）。
4、優化表DDL設計，儘量避免使用BLOB、TEXT類型字段，並且在SQL中減少對這些大字段的訪問。
5、優化查詢邏輯，避免使用UNION或者需要中間數據集的子查詢等SQL。
葉問(20190115)雲環境上自建MySQL，有哪些高可用實現方案？
1、基於VPC環境， 支持獨立分配IP相關IP段的，還是可以考慮VIP方案，雲環境把協議閹割，使用TCP方式，如：×××開源的Xenon， MHA 。 在VPC中，是可以自主綁定私有IP，還是比較方便。
2、基於MGR、PXC構建MySQL高可用。因爲MGR、PXC無法告知應用端切換後的IP地址，所以建議配合使用類似consul來使用。如果使用多主模式的MGR/PXC，可以使用LVS/haproxy或者SLB等。
3、基於中間件層MySQL高可用。使用consul配合MGR/PXC，或者consul配合MHA使用。
4、基於ProxySQL+Replication-manager+Consul進行構建，用Replication-manager提供主從切換，動態通知proxysql,利用consul感知ProxySQL可用性。
葉問(20190220)MySQL安全相關的參數有哪些？該如何配置？
1、MySQL數據安全
innodb_flush_log_at_trx_commit =1 #innodb每次提交事務redo buffer 刷新到redo log
innodb_doublewrite =on #開啓innodb特性“二次寫”
secure_file_priv #禁用導入導出目錄，避免被人利用
2、複製安裝
sync_binlog = 1 #事務每次提交binlog cache刷新到binlog file
binlog_format =row #binlog格式爲row格式
relay_log_info_repository =table #relay log信息記錄到innodb存儲引擎的table中
master_info_repository=table #master 信息記錄到innodb存儲引擎的table中
slave_skip_errors=off #禁止跳躍錯誤信息
binlog_row_image=full #全量記錄binlog日誌內容
3、使用建議
master-slave：建議開啓gtid，採用半同步複製或者mgr高可用
密碼相關：設置密碼複雜度，定期修改密碼，針對應用app授權，減少權限分配
存儲引擎：建設使用innodb，避免使用myisam
網絡環境：內外隔離，不要把數據庫直接暴漏到公網
相關連接：
"MySQL數據安全策略"：
http://t.cn/EfvKeFD
"我猜你一定達不到要求的《MySQL安全策略":
http://t.cn/Efv9yjI
葉問(20190226): MySQL DBA運維中那些動作屬於危險性操作?
1、MySQL無備份、備份無校對。
2、執行rm -rf / tmp 等類似操作，執行rm 前要三思。
3、執行kill -9等操作
4、binlog 非row格式，執行dml操作(update、delete)
5、在生產環境執行測試命令。或在生產環境直接調索引。
6、避免使用一些騷操作："slave_skip_errors" ,或故意導致主從不一致操作。
7、drop database
8、DML操作條件寫錯， 線上DDL導致業務報錯
9、恢復數據，實例不對（基於IP連接管理環境）
10、線上高併發環境運行 flush table ; flush table with read lock; lock table;
11、數據庫重啓空間不夠文件損壞，初始化數據庫把機器IO資源佔滿
12、從庫延遲並對外提供服務
13、開多窗口操作重要數據庫
14、敏感字段不加密，備份不加密存放，線上數據同步到線下
15、犯困時操作線上環境
葉問(20190326)：MySQL誤刪除frm文件該怎麼辦？
情況一：誤刪後還未重啓MySQL
1、從proc中恢復.frm文件
cp /proc/pidof mysqld/fd/誤刪除的.frm /datadir/db/對應庫的目錄/
情況二：誤刪後也重啓MySQL了
2、從備份中獲取表結構
2.1 物理備份
從物理備份中直接把.frm文件拷貝回來。
2.2 邏輯備份
找到該表的DDL，在備用實例創建該表，再把.frm文件拷貝回來。
注意事項：
1、無論是情況一還是情況二，都需要重新設置屬主和屬組。
2、若恢復期間對該表執行了新的DDL，則上述方法可能都無效。
3、本案例在MySQL 5.7.18版本（開啓表獨立空間模式）下親測通過。
葉問(20190409):在一個2c4g的服務器上如何用python操作8GB的超大文件
1、使用with open的方式，for line in f文件對象f視爲一個迭代器，會自動的採用緩衝IO和內存管理，並且能夠自動關閉文件，推薦該方式
舉例：
with open('filename') as f:
for line in f:
do_things(line)
2、open file的方式，可以通過read(size)指定每次讀取的大小，將大文件切割成小文件來讀取，每次處理完小塊即釋放內存
舉例：
f = open(filePath)
while True:
content = f.read(chunk_size)
do_things(content)
3、linecache模塊，可以指定讀取文件某一行
舉例：
content = linecache.getline('filename', linenum)
do_things(content)
葉問(20190411)：MySQL反應慢的排查思路
一、導致MySQL慢可能的因素有
1、計算資源不足
2、系統層面未進行基本的優化，或不同進程間資源搶佔
3、MySQL配置不科學(附神器：http://imysql.com/my-cnf-wizard.html)
4、垃圾SQL滿天飛
二、查看系統層面負載手段
1、top查看整體負載情況，快速確認哪個進程系負載高
2、free查看內存情況，是否有內存泄露和用了swap等風險
3、vmstat/sar查看當前系統瓶頸到底在哪，如CPU、IO、網絡等
4、終極神器perf top查看cpu消耗在哪些系統調用函數
三、查看MySQL的整體情況
1、觀察show processlist輸出中是否有臨時表、排序、大量邏輯讀、鎖等待等狀態
2、觀察show engine innodb status輸出中是否有大事務、長事務、鎖等待等狀態
四、幹掉垃圾SQL，常用手段
1、用explain、desc觀察執行計劃
2、用profiling定位sql執行的瓶頸
3、用pt-query-digest分析慢sql
五、幾個竅門
1、mysqld進程消耗CPU長時間超過90%的話，99.9%是因爲沒用好索引
2、cpu的%sys高的話，大概率是swap或中斷不均衡導致，也可能是有多個索引且超高併發寫入(更新)，或者有很嚴重的鎖等待事件
3、最⼤的瓶頸通常是在磁盤I/O上，因此盡量用高速磁盤設備
4、如果物理磁盤無法再升級，則通過增加內存提升性能容量
5、遇到無法診斷的問題時，試試⽤perf top來觀測跟蹤
6、SQL執行慢，有時未必是效率低，也可能是因爲鎖等待，甚⾄是磁盤滿了
詳情戳：https://ke.qq.com/course/392646
葉問(20190416):生產環境MySQL死鎖如何監控及如何減少死鎖發生的概率？
首先，死鎖並不是"鎖死"，死鎖是由於兩個或兩個以上會話鎖等待產生迴路造成
一、死鎖監控及處理方法
對於死鎖的監控，各個版本都提供了innodb_print_all_deadlocks選項，打開該選項即會將死鎖的日誌輸出到MySQL的錯誤日誌當中,
因此可以通過監控錯誤日誌來達到監控死鎖的目的。而對於MariaDB就更加簡單了，MariaDB提供了Innodb_deadlocks的計數器，可以
通過監控該計數器的增長來監控是否存在發生死鎖。
假如線上出現死鎖並且頻率較高的話，務必要引起重視。由於死鎖日誌僅記錄了最後引起死鎖的兩條SQL，因此並不能通過死鎖日誌立即定位
出死鎖的原因，應當及時協同開發模擬出死鎖過程，分析死鎖產生原因，修改程序邏輯。
二、如何降低死鎖發生的概率
1、儘量使用短小事務，避免大事務
2、加FOR UPDATE/LOCK IN SHARE MODE鎖時，最好降低事務隔離級別，例如用RC級別，降低死鎖發生概率，也可以降低鎖定粒度
3、事務中涉及多個表，或者涉及多行記錄時，每個事務的操作順序都要保持一致
4、通過索引優化SQL效率，降低死鎖概率，避免全表掃描導致鎖定所有數據
5、程序中應有事務失敗檢測及自動重複提交機制
6、高併發（秒殺）場景中，關閉innodb_deadlock_detect選項，降低死鎖檢測開銷，提高併發效率