一、生產(chǎn)環(huán)境MySQL死鎖如何監(jiān)控及如何減少死鎖發(fā)生的概率

首先，死鎖并不是"鎖死"，死鎖是由于兩個或兩個以上會話鎖等待產(chǎn)生回路造成。

（一）死鎖監(jiān)控及處理方法

對于死鎖的監(jiān)控，各個版本都提供了innodb_print_all_deadlocks選項，打開該選項即會將死鎖的日志輸出到MySQL的錯誤日志當中,因此可以通過監(jiān)控錯誤日志來達到監(jiān)控死鎖的目的。而對于MariaDB就更加簡單了，MariaDB提供了Innodb_deadlocks的計數(shù)器，可以通過監(jiān)控該計數(shù)器的增長來監(jiān)控是否存在發(fā)生死鎖。
假如線上出現(xiàn)死鎖并且頻率較高的話，務必要引起重視。由于死鎖日志僅記錄了最后引起死鎖的兩條SQL，因此并不能通過死鎖日志立即定位
出死鎖的原因，應當及時協(xié)同開發(fā)模擬出死鎖過程，分析死鎖產(chǎn)生原因，修改程序邏輯。

（二）如何降低死鎖發(fā)生的概率

1、盡量使用短小事務，避免大事務
2、加FOR UPDATE/LOCK IN SHARE MODE鎖時，最好降低事務隔離級別，例如用RC級別，降低死鎖發(fā)生概率，也可以降低鎖定粒度
3、事務中涉及多個表，或者涉及多行記錄時，每個事務的操作順序都要保持一致
4、通過索引優(yōu)化SQL效率，降低死鎖概率，避免全表掃描導致鎖定所有數(shù)據(jù)
5、程序中應有事務失敗檢測及自動重復提交機制
6、高并發(fā)（秒殺）場景中，關閉innodb_deadlock_detect選項，降低死鎖檢測開銷，提高并發(fā)效率

二、MongoDB有哪些優(yōu)秀特性及適合的場景是什么

（一）優(yōu)秀特性

1、實用性：面向類json富文檔數(shù)據(jù)模型，對開發(fā)人員天然的友好
2、可用性：基于raft協(xié)議的自動高可用，輕松提供99.999%的可用性
3、擴展性：對分片集群的支持，為業(yè)務提供了友好的水平擴展
4、高性能：嵌套模型設計支持，減少了離散寫，充分的物理內(nèi)存利用率，避免了磁盤讀
5、強壓縮：WiredTiger引擎提供多種數(shù)據(jù)壓縮策略，2~7倍的壓縮比，大大節(jié)省了磁盤資源

（二）適合的場景

1、無多文檔事務及多表關聯(lián)查詢需求
2、業(yè)務快速迭代，需求頻繁變動行業(yè)
3、單集群并發(fā)過大無法支撐業(yè)務增長
4、數(shù)據(jù)量增長預期TB及以上存儲需求
5、期望要求99.999%數(shù)據(jù)庫高可用場景

三、GO語言對比其他的編程語言有何優(yōu)勢？實際生產(chǎn)環(huán)境如何取舍？

1、天生支持高并發(fā)，強一致語言，開發(fā)效率高兼具線上運行穩(wěn)定安全
2、垃圾回收，不用關心內(nèi)存分配與回收
3、強大的GMP模型，異步處理，支持高并發(fā)，小白也能輕松寫出高并發(fā)代碼

在實際生產(chǎn)環(huán)境中建議從如下幾個方面考慮：

1、看業(yè)務場景，電商，大數(shù)據(jù)處理有現(xiàn)成的解決方案，不適合用。另外數(shù)學運算，cpu 密集型的也不用。
2、GO 擅長快速出業(yè)務原型，迭代開發(fā)效率高，初創(chuàng)公司強推
3、看公司開發(fā)的技術棧，如果差異較大，那么選用 GO的話上手更快，編程風格也能統(tǒng)一起來

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

1、首先，盡量避免在MySQL中執(zhí)行大事務，因為大事務將會帶來主從復制延遲等問題
2、大事務被kill，MySQL會自動進行回滾操作，通過show engine innodb status的TRANSACTIONS可以看到ROLLING BACK的事務，并且在回滾操作的時候仍然會持有相應的行鎖
3、此時如果強行關閉MySQL，等到MySQL再次啟動后，仍然會進行回滾動作
4、因此，為確保數(shù)據(jù)安全，建議還是耐心等待回滾完成以后再進行關機重啟。關機重啟前，可以調(diào)低innodb_max_dirty_pages_pct讓臟頁盡量刷新完畢，并且關閉innodb_fast_shutdown
5、假如實在沒有辦法需要關機的情況下，可以kill -9先關閉MySQL，前提是需要設置雙一保證事務安全，否則可能丟更多事務數(shù)據(jù)。然后重啟實例后innodb會自行crash recovery回滾之前的事務

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

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

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

六、MySQL如何控制用戶輸錯密碼嘗試次數(shù)？

（一）插件輔助

從官方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三個參數(shù)

1、connection_control_failed_connections_threshold

該參數(shù)的含義是控制登陸失敗多少次數(shù)后開啟延遲登陸

2、connectioncontrolminconnectiondelay

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

3、connection_control_max_connection_delay

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

4、安裝插件后，可通過監(jiān)控Connection_control_delay_generated狀態(tài)值和INFORMATION_SCHEMA下的表

CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS來監(jiān)控錯誤登錄嘗試次數(shù)

（二）錯誤日志監(jiān)控

通過定時掃描MySQL錯誤日志來捕獲賬號密碼錯誤次數(shù)，達到某個閾值以后可在系統(tǒng)防火墻屏蔽對應的主機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能夠控制錯誤密碼的嘗試次數(shù)，其實該參數(shù)只能防止如telnet類的端口探測，即記錄協(xié)議握手錯誤的次數(shù)

2、最后，在生產(chǎn)環(huán)境一定要關注aborted_clients和aborted_connects的狀態(tài)，發(fā)生異常必須及時關注

總結

以上所述是小編給大家介紹的MySQL控制用戶輸錯密碼嘗試次數(shù)，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復大家的。在此也非常感謝大家對腳本之家網(wǎng)站的支持！
如果你覺得本文對你有幫助，歡迎轉(zhuǎn)載，煩請注明出處，謝謝！