咱们就说下这个例子，提醒广大开发在写SQL的时候一定要仔细！当时情况是这样的，一个慢SQL把数据库CPU连接数跑满，由于并发压力大，CPU空闲瞬时为0，过一会机器被HANG死，连接不上。因涉及公司隐私问题，我这里用测试表代替，咱们主要看看是怎么引起的。表结构：mysql> desc sbtest; +-------+------------------+------+-----+------
上周日，早上快到6点，天还没亮，睡得正香，突然被一声短信惊醒，Too many connections！我这纳闷呢，搞啥活动呢？平常这都是低风期啊。登陆机器一查看慢日志，发现有这么一条SQL，很奇葩：跑了快1小时了，而且查询的结果还是0行。很奇怪到底在搞毛？我又查看了这个表，并没有aid=1的记录。周一询问了开发，都不知道这条SQL。最后猜想到，这是不是监控人员，搞的一个每隔15秒就连接一下，看看
MySQL数据库CPU飙升紧急处理方法运行平稳的数据库，如果遇到CPU狂飙，到80%左右，那一定是开发写的烂SQL导致的，DBA首先要保证的是，数据库别跑挂了，所以我们要把那些运行慢的SQL杀死并记录到文件里，以便后面的排查。这里用到一个工具pt-kill，它可以帮助你。pt-kill --match-info "^(select|SELECT)" --busy-time 3 --victim
我们先看一下这个报错日志：InnoDB: Warning: a long semaphore wait: --Thread 140593224754944 has waited at btr0cur.c line 528 for 241.00 seconds the semaphore: X-lock on RW-latch at 0x7fd9142bfcc8 created in file di
刚刚接到报警短信，从库宕机，马上通知机房重启，在检查MySQL时，发现同步挂了，报主键冲突，询问开发是不是有往里面写数据，回答没有。这就奇怪了，怎么会无缘无故报错呢？在检查了my.cnf配置文件，发现有个参数没有配置：innodb_overwrite_relay_log_info = 1当从库宕机后，重新开启主从复制同步，它可以重新执行已提交事务，这样就会造成同步失败，而这个参数就会避免这个问题的
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
