一、生產環境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控制用戶輸錯密碼嘗試次數，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復大家的。在此也非常感謝大家對腳本之家網站的支持！
如果你覺得本文對你有幫助，歡迎轉載，煩請注明出處，謝謝！