MySQL如何控制用户输错密码尝试次数？

目录

• 生产环境MySQL死锁如何监控及如何减小死锁发生的几率
• MongoDB有哪些优秀特性及适合的场景是什么
• GO语言对比其余的编程语言有何优点？实际生产环境如何取舍？
• 一个大事务，有不少更新，如今被回滚了，可是又着急关机重启，怎么办才好？
• 如何下降UPDATE/DELETE时WHERE条件写错，或者压根没写WHERE条件带来的影响
• MySQL如何控制用户输错密码尝试次数？

---

1、生产环境MySQL死锁如何监控及如何减小死锁发生的几率

首先，死锁并非"锁死"，死锁是因为两个或两个以上会话锁等待产生回路形成。

（一）死锁监控及处理方法

对于死锁的监控，各个版本都提供了innodb_print_all_deadlocks选项，打开该选项即会将死锁的日志输出到MySQL的错误日志当中,所以能够经过监控错误日志来达到监控死锁的目的。而对于MariaDB就更加简单了，MariaDB提供了Innodb_deadlocks的计数器，能够经过监控该计数器的增加来监控是否存在发生死锁。
假如线上出现死锁而且频率较高的话，务必要引发重视。因为死锁日志仅记录了最后引发死锁的两条SQL，所以并不能经过死锁日志当即定位
出死锁的缘由，应当及时协同开发模拟出死锁过程，分析死锁产生缘由，修改程序逻辑。

（二）如何下降死锁发生的几率

一、尽可能使用短小事务，避免大事务
二、加FOR UPDATE/LOCK IN SHARE MODE锁时，最好下降事务隔离级别，例如用RC级别，下降死锁发生几率，也能够下降锁定粒度
三、事务中涉及多个表，或者涉及多行记录时，每一个事务的操做顺序都要保持一致
四、经过索引优化SQL效率，下降死锁几率，避免全表扫描致使锁定全部数据
五、程序中应有事务失败检测及自动重复提交机制
六、高并发（秒杀）场景中，关闭innodb_deadlock_detect选项，下降死锁检测开销，提升并发效率

2、MongoDB有哪些优秀特性及适合的场景是什么

（一）优秀特性

一、实用性：面向类json富文档数据模型，对开发人员自然的友好
二、可用性：基于raft协议的自动高可用，轻松提供99.999%的可用性
三、扩展性：对分片集群的支持，为业务提供了友好的水平扩展
四、高性能：嵌套模型设计支持，减小了离散写，充分的物理内存利用率，避免了磁盘读
五、强压缩：WiredTiger引擎提供多种数据压缩策略，2~7倍的压缩比，大大节省了磁盘资源

（二）适合的场景

一、无多文档事务及多表关联查询需求
二、业务快速迭代，需求频繁变更行业
三、单集群并发过大没法支撑业务增加
四、数据量增加预期TB及以上存储需求
五、指望要求99.999%数据库高可用场景

3、GO语言对比其余的编程语言有何优点？实际生产环境如何取舍？

一、天生支持高并发，强一致语言，开发效率高兼具线上运行稳定安全
二、垃圾回收，不用关心内存分配与回收
三、强大的GMP模型，异步处理，支持高并发，小白也能轻松写出高并发代码

在实际生产环境中建议从以下几个方面考虑：

一、看业务场景，电商，大数据处理有现成的解决方案，不适合用。另外数学运算，cpu 密集型的也不用。
二、GO 擅长快速出业务原型，迭代开发效率高，初创公司强推
三、看公司开发的技术栈，若是差别较大，那么选用 GO的话上手更快，编程风格也能统一块儿来

4、一个大事务，有不少更新，如今被回滚了，可是又着急关机重启，怎么办才好？

一、首先，尽可能避免在MySQL中执行大事务，由于大事务将会带来主从复制延迟等问题
二、大事务被kill，MySQL会自动进行回滚操做，经过show engine innodb status的TRANSACTIONS能够看到ROLLING BACK的事务，而且在回滚操做的时候仍然会持有相应的行锁
三、此时若是强行关闭MySQL，等到MySQL再次启动后，仍然会进行回滚动做
四、所以，为确保数据安全，建议仍是耐心等待回滚完成之后再进行关机重启。关机重启前，能够调低innodb_max_dirty_pages_pct让脏页尽可能刷新完毕，而且关闭innodb_fast_shutdown
五、假如实在没有办法须要关机的状况下，能够kill -9先关闭MySQL，前提是须要设置双一保证事务安全，不然可能丢更多事务数据。而后重启实例后innodb会自行crash recovery回滚以前的事务

PS， kill -9是高危操做，可能致使MySQL没法启动等不可预知的问题，请谨慎使用

5、如何下降UPDATE/DELETE时WHERE条件写错，或者压根没写WHERE条件带来的影响

一、尽可能不要在线手工执行任何SQL命令，很容易出差错。线上直接执行SQL命令最好有第二检查人帮助确认
二、最好在测试环境执行SQL确认无误后，再到生产环境执行，或者提早在本地文本环境编辑好确认后再执行
三、建议打开sql_safe_updates选项，禁止没有WHERE条件或者不加LIMIT或者没有使用索引条件的UPDATE/DELETE命令被执行。也能够在用mysql客户端链接到服务器端时增长--safe-updates选项，例如：mysql --safe-updates -h xx -u xx
四、线上手动执行DML操做时，先开启事务模式，万一误操做能够回滚。例如：mysql> begin; update xxx; rollback;
五、经过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三个参数

一、connection_control_failed_connections_threshold
该参数的含义是控制登录失败多少次数后开启延迟登录

二、connectioncontrolminconnectiondelay
该参数分别表示超过失败次数后每次从新链接最小的延迟时间，延迟计算公式为(当前失败总次数-失败阈
值)connectioncontrolminconnection_delay，所以错误尝试次数越多那么延迟时间也是越大

三、connection_control_max_connection_delay
最大延迟时间，超过该值后客户端可从新链接

四、安装插件后，可经过监控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)

（三）其余说明

一、有些同窗会误觉得max_connection_errors可以控制错误密码的尝试次数，其实该参数只能防止如telnet类的端口探测，即记录协议握手错误的次数
二、最后，在生产环境必定要关注aborted_clients和aborted_connects的状态，发生异常必须及时关注

---

公众号：知数堂，更多MySQL干货知识，关注公众号获取。

原文连接：https://zhishutang.com/CID

推荐阅读：https://zhishutang.com/xdI