在2017年裏，項目上的MySQL出了幾個問題，記錄總結一下，給自己一個教訓！
廢話不多說了，直接進入問題主題：
問題一：MySQL單表千萬級數據量"add"字段異常分析
問題描述：
項目一個新功能，需要對有1200w+的表"tb_bw_mobile"新增2個字段"batch_num"、"data_status"；執行SQL月5-6分鐘後，查詢數據，發現未增加字段；約10-13分鐘後limit 1、10、100條數據，均爲發現有新增的2個字段；此時查詢表結構，發現表結構未變化；約24分鐘後，MySQL命令行端拋出異常"ERROR 1034 (HY000): Incorrect key file for table 'tb_ec_bw_mobile'; try to repair it"；再此覈實表結構、數據，發現均未有任何改變；
當時就矇蔽了，怎麼會提示"try to repair it"，表結構怎麼會有問題？通知測試人員，將生產的表結構和10w條數據導出來在測試環境進行測試，結果並沒有什麼問題；此時查看MySQL日誌，發現集羣出現了異常
執行SQL時拋出異常，嘗試4次修改當前執行事務未306；修改失敗後，當前事務在從節點的狀態從SYNCD->OPEN->CLOSED，再看後面的信息，MySQL從節點服務器異常。
此時重啓mysql服務，查看mysql進程；基於rsync服務以及4444端口來同步恢復數據；同時查看進程的線程和io，確定是在做數據同步；約30分鐘後，查詢mysql日誌及系統日誌，mysql數據同步成功且成功加入集羣。集羣正常提供服務
**此時回過頭來查看執行sql拋出的異常＂ERROR 1034 (HY000): Incorrect key file for table 'tb_ec_bw_mobile'; try to repair it＂；在官網中看到解決辦法，需創建一張臨時表做數據遷移，而不是直接對千萬級數據直接add字段；
問題二：MySQL臨時表問題
問題描述：
MySQL應用所在雲主機系統磁盤容量不斷減小，在tmp目錄下不斷生成以MAD、MAI爲後綴的文件，導致前端web服務mgr在1min對mysql發起請求的連接高於1000+；此時查看mysql的進程，發現有”Copy data to tmp”的相關事務在執行，原因是黑白名單功能把”tb_ec_contact”和”tb_ec_bw_mobile”兩張千萬級數據表關聯起來
問題分析：
Mysql臨時表分爲”內存臨時表”和”磁盤臨時表”；一般情況下，MySQL會先創建內存臨時表，但是內存臨時表超過配置指定的值後，MySQL會將內存臨時表導出到磁盤臨時表；使用臨時表的場景：對Innodb表進行alter和create操作或者是sql語句效率低下事務執行過慢，未做優化，以下爲網關說明；
需要注意的是：此配置默認路徑是/tmp目錄，生成以MAD、MAI爲後綴的文件，在短時間內很容易將系統磁盤佔慢，導致依賴mysql的程序運行異常；文件刪除後系統磁盤空間也不會釋放，因爲mysql的線程正在運行，除非停止mysql服務；(可以使用lsof查看)；但是好處是如果線程執行完了，會將生成的文件自動刪除，釋放系統磁盤空間；此參數配置不能在線進行全局修改，只能先停止mysql服務，在配置文件中寫明相關參數重啓服務才行；但是臨時表的空間和行數可在線修改；
show global variables like “%tmp%”；
tmpdir ##指明mysql磁盤臨時表存儲路徑
slave_load_tmpdir=/data/mysql/slave_tmpdir ##指明從節磁盤臨時表路徑
max_tmp_tables=128 ##指明支持多少個內存臨時表
tmp_table_size=33554432 ##指明臨內存時表的大小
max_heap_table_size=33554432 ##指明內存臨時表表支持多少行