一、生產環境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選項，降低死鎖檢測開銷，提高併發效率

二、MongoDB有哪些優秀特性及適合的場景是什麼

（一）優秀特性

1、實用性：面向類json富文件資料模型，對開發人員天然的友好
2、可用性：基於raft協議的自動高可用，輕鬆提供99.999%的可用性
3、擴充套件性：對分片叢集的支援，為業務提供了友好的水平擴充套件
4、高效能：巢狀模型設計支援，減少了離散寫，充分的實體記憶體利用率，避免了磁碟讀
5、強壓縮：WiredTiger引擎提供多種資料壓縮策略，2~7倍的壓縮比，大大節省了磁碟資源

（二）適合的場景

1、無多文件事務及多表關聯查詢需求
2、業務快速迭代，需求頻繁變動行業
3、單叢集併發過大無法支撐業務增長
4、資料量增長預期TB及以上儲存需求
5、期望要求99.999%資料庫高可用場景

三、GO語言對比其他的程式語言有何優勢？實際生產環境如何取捨？

1、天生支援高併發，強一致語言，開發效率高兼具線上執行穩定安全
2、垃圾回收，不用關心記憶體分配與回收
3、強大的GMP模型，非同步處理，支援高併發，小白也能輕鬆寫出高併發程式碼

在實際生產環境中建議從如下幾個方面考慮：

1、看業務場景，電商，大資料處理有現成的解決方案，不適合用。另外數學運算，cpu 密集型的也不用。
2、GO 擅長快速出業務原型，迭代開發效率高，初創公司強推
3、看公司開發的技術棧，如果差異較大，那麼選用 GO的話上手更快，程式設計風格也能統一起來

四、一個大事務，有很多更新，現在被回滾了，但是又著急關機重啟，怎麼辦才好？

1、首先，儘量避免在MySQL中執行大事務，因為大事務將會帶來主從複製延遲等問題
2、大事務被kill，MySQL會自動進行回滾操作，通過show engine innodb status的TRANSACTIONS可以看到ROLLING BACK的事務，並且在回滾操作的時候仍然會持有相應的行鎖
3、此時如果強行關閉MySQL，等到MySQL再次啟動後，仍然會進行回滾動作
4、因此，為確保資料安全，建議還是耐心等待回滾完成以後再進行關機重啟。關機重啟前，可以調低innodb_max_dirty_pages_pct讓髒頁儘量重新整理完畢，並且關閉innodb_fast_shutdown
5、假如實在沒有辦法需要關機的情況下，可以kill -9先關閉MySQL，前提是需要設定雙一保證事務安全，否則可能丟更多事務資料。然後重啟例項後innodb會自行crash recovery回滾之前的事務

PS， kill -9是高危操作，可能導致MySQL無法啟動等不可預知的問題，請謹慎使用

五、如何降低UPDATE/DELETE時WHERE條件寫錯，或者壓根沒寫WHERE條件帶來的影響

1、儘量不要線上手工執行任何SQL命令，很容易出差錯。線上直接執行SQL命令最好有第二檢查人幫助確認
2、最好在測試環境執行SQL確認無誤後，再到生產環境執行，或者提前在本地文字環境編輯好確認後再執行
3、建議開啟sql_safe_updates選項，禁止沒有WHERE條件或者不加LIMIT或者沒有使用索引條件的UPDATE/DELETE命令被執行。也可以在用mysql客戶端連線到伺服器端時增加--safe-updates選項，例如：mysql --safe-updates -h xx -u xx
4、線上手動執行DML操作時，先開啟事務模式，萬一誤操作可以回滾。例如：mysql> begin; update xxx; rollback;
5、通過DB管理平臺執行DML操作，且在平臺上增加對此類危險SQL的判斷，直接拒絕危險SQL的執行
6、配置延遲從庫，發現誤刪除資料後，從延遲從庫快速恢復資料

六、MySQL如何控制使用者輸錯密碼嘗試次數？

（一）外掛輔助

從官方MySQL5.7.17開始，提供了CONNECTION_CONTROL和CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS外掛，該外掛又提供了connection_control_failed_connections_threshold、connection_control_min_connection_delay、connection_control_max_connection_delay三個引數

1、connection_control_failed_connections_threshold

該引數的含義是控制登陸失敗多少次數後開啟延遲登陸

2、connectioncontrolminconnectiondelay

該引數分別表示超過失敗次數後每次重新連線最小的延遲時間，延遲計算公式為(當前失敗總次數-失敗閾
值)connectioncontrolminconnection_delay，因此錯誤嘗試次數越多那麼延遲時間也是越大

3、connection_control_max_connection_delay

最大延遲時間，超過該值後客戶端可重新連線

4、安裝外掛後，可通過監控Connection_control_delay_generated狀態值和INFORMATION_SCHEMA下的表

CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS來監控錯誤登入嘗試次數

（二）錯誤日誌監控

通過定時掃描MySQL錯誤日誌來捕獲賬號密碼錯誤次數，達到某個閾值以後可在系統防火牆遮蔽對應的主機ip達到遮蔽賬號的目的(具體操作視情況而定)
如：錯誤日誌會顯示2019-05-10T13:04:41.232259Z 5 [Note] Access denied for user 'xucl'@'127.0.0.1' (using password: YES)

（三）其他說明

1、有些同學會誤以為max_connection_errors能夠控制錯誤密碼的嘗試次數，其實該引數只能防止如telnet類的埠探測，即記錄協議握手錯誤的次數

2、最後，在生產環境一定要關注aborted_clients和aborted_connects的狀態，發生異常必須及時關注

總結

以上所述是小編給大家介紹的MySQL控制使用者輸錯密碼嘗試次數，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回覆大家的。在此也非常感謝大家對我們網站的支援！
如果你覺得本文對你有幫助，歡迎轉載，煩請註明出處，謝謝！