线上有个数据库，在slow log中，存在大量类似下面的记录：

# Time: 130823 13:56:08
# User@Host: repl[repl] @ slave [10.x.x.x]
# Query_time: 9.000833 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 1
SET timestamp=1377237368;
# administrator command: Binlog Dump;

每完成一次binlog dump都会被记录下来，看着非常不爽（我有强迫症，O(∩_∩)O哈哈~），得想着法子搞掉。
经过排查，最后确认是特定版本存在这个现象，目前发现官方 5.1.49 存在，估计整个官方 5.1.x 都会有这个现象。

解决方法：
修改 my.cnf 配置文件，增加或修改下面这个选项：

log-slow-admin-statements = 0

比较坑人的是，这个选项在5.1无法在线修改，需要重启mysqld。
手册上关于这个选项的解释如下：

Include slow administrative statements in the statements written to the slow query log. …

作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gm […]

作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.

今天给一个客户巡检的情况下发从库没有业务的情况mysqld的cpu的一个core占用100%.查主库慢查询也没有关于写的SQL.
可以说是典的单进程复制把一个cpu占满造成的．知道原因了，就好分析了．
分析一下binlog中写的什么，看看有什么地方可以优化或是加速的．利用工具：pasrebinlog
利用show slave status\G; 查当前同步的到节点，然后对日值进行解析．

      git clone https://github.com/wubx/mysql-binlog-statistic.git
cd mysql-binlog-statistic/bin/
parsebinlog /u1/mysql/logs/mysql-bin.000806
 
...
====================================
Table xx_db.xxtable:
Type DELETE opt： 101246
Type INSERT opt： 103265 …

作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.

可以用说用到MySQL的地方,只要数据量一大, 马上就会遇到一个问题,要分库分表.
这里引用一个问题为什么要分库分表呢?MySQL处理不了大的表吗?
其实是可以处理的大表的.我所经历的项目中单表物理上文件大小在80G多,单表记录数在5亿以上,而且这个表
属于一个非常核用的表:朋友关系表.

但这种方式可以说不是一个最佳方式. 因为面临文件系统如Ext3文件系统对大于大文件处理上也有许多问题.
这个层面可以用xfs文件系统进行替换.但MySQL单表太大后有一个问题是不好解决: 表结构调整相关的操作基
本不在可能.所以大项在使用中都会面监着分库分表的应用.

作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.

CASE:
mysql的IO处理上有抖动，　从日值上观查binlog最大的有(512M)大于max_binlog_size(128M)

原因：
当mysql在处理大事务时，不会进行binlog切换，所有的日值还是会写到一个数据文件里．
如：　bulk insert之类的操作
解决办法：
拆分大事务．　或是把大事务处理放到业务低峰期，避免大事务对业务的冲击.

特别提示：　

看到这种现象可以通过分析binlog查到是什么操作，　可以通过业务的方面考虑一下怎么规避．