导读
从一个现场说起，全程解析如何定位性能瓶颈。
排查过程
收到线上某业务后端的MySQL实例负载比较高的告警信息，于是登入服务器检查确认。
1. 首先我们进行OS层面的检查确认
登入服务器后，我们的目的是首先要确认当前到底是哪些进程引起的负载高，以及这些进程卡在什么地方，瓶颈是什么。
通常来说，服务器上最容易成为瓶颈的是磁盘I/O子系统，因为它的读写速度通常是最慢的。即便是现在的PCIe SSD，其随机I/O读写速度也是不如内存来得快。当然了，引起磁盘I/O慢得原因也有多种，需要确认哪种引起的。
第一步，我们一般先看整体负载如何，负载高的话，肯定所有的进程跑起来都慢。
可以执行指令 w 或者 sar -q 1 来查看负载数据，例如：
…[获取更多]导读
遇到SLAVE延迟很大，binlog apply position一直不动的情况如何排查？
问题描述
收到SLAVE延迟时间一直很大的报警，于是检查一下SLAVE状态(无关状态我给隐去了)：
Slave_IO_State: Waiting for master to send event
Master_Log_File: mysql-bin.000605
Read_Master_Log_Pos: 1194
Relay_Log_File: mysql-relay-bin.003224
Relay_Log_Pos: 295105
Relay_Master_Log_File: mysql-bin.000604
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_Errno: 0
Last_Error:
Exec_Master_Log_Pos: 294959
Relay_Log_Space: 4139172581
Seconds_Behind_Master: 10905
可以看到，延迟确实很大，而且从多次show slave status的结果来看，发现binlog的position一直不动。
Read_Master_Log_Pos: 1194
Relay_Log_File: …[获取更多]
导读
关于 lower_case_table_names 选项的设置的建议是怎样的呢？
问题由来
我个人认为，纠结于这个选项设置源于有些项目是从ORACLE或SQL Server迁移过来，在这两个数据库系统中，都无需关心数据表的大小写。而在MySQL中，默认是要区分大小写的(因为Unix/Linux文件系统是区分文件名大小写的)，除非在windows系统下(windows系统是不区分大小写的)。
老叶的建议
我在公司制定的规范是要求默认设置 lower_case_table_names=0 的，也就是区分大小写。那么问题来了，如果是从ORACLE或SQL Server迁移到MYSQL的应用应该怎么处理呢？
我的建议是：
…
导读
当磁盘空间爆满后，MySQL会发生什么事呢？又应该怎么应对？
会发生什么事
当磁盘空间写满了之后，MySQL是无法再写入任何数据的，包括对表数据的写入，以及binlog、binlog-index等文件。
当然了，因为InnoDB是可以把脏数据先放在内存里，所以不会立刻表现出来无法写入，除非开启了binlog，写入请求才会被阻塞。
当MySQL检测到磁盘空间满了，它会：
每分钟：检查空间是否得到释放，以便写入新数据。当发现有剩余空间了，就会继续写入数据，一切照旧。
每十分钟：如果还是发现没剩余空间，则会在日志中写入一条记录，报告磁盘空间满(这时候只写入几个字节还是够的)。
应该怎么办…
[获取更多]在mysql的innodb引擎的数据库异常恢复中,一般都要求有主键或者唯一index,其实这个不是必须的,当没有index信息之时,可以在整个表级别的index_id进行恢复
创建模拟表—无主键
mysql> CREATE TABLE `t1` (
-> `messageId` varchar(30) character set utf8 NOT NULL,
-> `tokenId` varchar(20) character set utf8 NOT NULL,
-> `mobile` varchar(14) character set utf8 default NULL,
-> `msgFormat` int(1) NOT NULL,
-> `msgContent` varchar(1000) character set utf8 default NULL,
-> `scheduleDate` timestamp NOT NULL default '0000-00-00 00:00:00',
-> `deliverState` int(1) default NULL,
-> `deliverdTime` timestamp NOT NULL default '0000-00-00 00:00:00'
-> ) ENGINE=INnodb DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into t1 select * from sms_service.sms_send_record;
Query OK, …[获取更多]
一、通过软连接的方式迁移部分表空间到其他硬盘
优点：对数据没有任何影响,反而可以适当增加IO能力,使用多个磁盘的IOPS
缺点：需要停机
处理步骤：
1、关掉mysql实例
2、cp big.ibd /new/big.ibd
3、rename big.ibd big.ibd.remove
4、ln -s big.ibd /new/big.ibd
5、chow -R mysql:mysql /new/big.ibd
6、启动数据库,检查是否异常
7、删掉 remove的文件.
二、通过blackhole引擎,清理掉一些不重要,但是占用空间较大的表
优点：不需要停机
缺点：只能适用于slave,会缺少数据
处理步骤:
…
[获取更多]实际上本次故障的素材来自于朋友的朋友，虽然我并不是故障的亲身经历者，但即便只是作为旁观者，依然感觉有所收获，于是乎记录下来以馈读者。
故障的来龙去脉大致是这样的：在一个月黑风高的晚上，苦逼的程序员被一阵急促的报警短信声惊醒，原来是数据库的某个表出问题了，虽然查询操作都正常，但创建操作却都失败了，经过调试，发现原因是表被插入了一行问题数据，其自增字段的值被显式的设置为整型的最大值，导致后续缺省插入的数据不能获取到一个合法的主键值。
我们不妨创建一个测试表说明问题：
CREATE TABLE IF NOT EXISTS `test` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(100) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB;
然后插入一行问题数据：
INSERT …[获取更多]
以下是两种slave复制异常的情况。导致的原因都是由于跨机房同步,slave的机房突然掉电导致的。
案例一、
这个错误大原因是Read_Master_Log_Pos: 1028687822的pos号在主库上是没有的.
处理方法:获取这个pos号的前一个pos号,从新开启同步,这里注意如果是row模式的话就没有问题.如果是mix的或者statement的话,就需要去分析binlog,确认具体执行到哪个pos号了,不然可能会导致数据不一致。
(andy:db:)[(none)] 11:18:39> show slave status\G
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 192.168.11.24
…
[获取更多]现象
上线后习惯性的观察数据库的变化。发现数据库的tps有很大的飙升。不过幸好在双十一的时候在数据库方面做了一些完善，虽然主库的tps有飙升，但是总体load还不是很高。但是问题既然出现了，还是要解决的。
排查过程 确定是insert update 还是 delete操作导致tps高？
既然是tps高，那就说明数据库修改的操作多了。到底是insert update操作多了， 还是 delete 操作多了？在天机平台可以很明显的可以看出来。如下图：
从上图，我们可以很清楚的看出来是update操作多了导致的。
到底是那些update语句导致tps高？
…
[获取更多]最近一个项目进行2.0版本升级。2.0版本部署到所有的线上机器后，发现网站访问速度变的很慢。为了不影响用户体验，紧急进行版本回滚，然后进行问题查找。
分析
首先查看php的日志，没有发现有用的线索。
然后看了下mysql db的监控情况。如下图：
…
[获取更多]
