原文URL：http://www.mysqlperformanceblog.com/2010/07/16/analyzing-the-distribution-of-innodb-log-file-writes/

    最近我分析了一下Innodb是如何写多个日志的。我这里有个流量比较高的MySQL系统，使用的是Percona XtraDB存储引擎，

我使用strace命令分别跟踪了innodb如何去日志文件的。通常来说，innodb是以512bytes的大小来写入日志的。

关于这个可以参考：Mark Callaghan explained this and some of its performance implications 。那么innodb什么时候情况下会以大于512bytes者小于512bytes的请求写到日志里呢？

首先，我通过lsof命令找出日志的文件描述符(handle).

# lsof -p $(pidof mysqld) | grep ib_log
mysqld  29772 mysql    8uW  REG                8,2   268435456   7143989 /var/lib/mysql/ib_logfile0
mysqld  29772 mysql    9uW  REG                8,2   268435456   7143993 /var/lib/mysql/ib_logfile1

我们可以看到2个日志的handle为8和9，现在我们需要捕获innodb是如何写这2个日志的相关信息。Innodb轮循写日志就是通过这个文件描述符.

The following grabs the write sizes out of 100k calls to pwrite() and aggregates them：

# strace -f -p $(pidof mysqld) -e pwrite -s1 -xx 2>&1 \

   | grep ‘pwrite([89],’ |head -n 100000 \

   | awk ‘{writes[$5]++}END{for(w in writes){print w, ” “, writes[w]}}’

本来我可以写一个更好的脚本来捕获信息，但是下面的信息对我来说已经足够了。

<strong>bytes        count</strong>
512           44067
1024         30740
1536         15221
2048         7094
2560         1810
3072         570
3584         219
4096         112
4608         39
5120         23
5632         16
6144         15
6656         5
7168         3
7680         8
8192         2
8704         2
9216         1
9728         2
10240       1
10752       2
11264       1
11776       1
14848       1
15360       1
15872       2
16384       4
16896       4
17408       2
17920       2
18432       2
18944       8
19456       7
19968       4
20480       4
21504       1
22016       2
24064       1
40960       1

总的来说，大致有3/4是以512和1024字节写入的。那么这到底什么意思呢？这里有很多有趣的而且复杂的东西需要我们去研究。

 1. 我们可以看到，大部分的写入都小于4K。但是我们知道操作系统的page大小是4K的。如果要写入的page不在cache中，那么这个page最开始需要读出，然后再修改，最后再写回到磁盘。vadim曾经过做做一些测试，如果要性能最好，那么日志要在OS的cache中。

 2.这台MySQL的innodb_flush_log_at_trx_commit设置是2.这就说明每个事务都会有一个日志写入请求，这个和设置为1是一样的。但是如果设置成0，那么写入的方法就大不相同—这个时候写入请求会累计到一定程度，然后一起写入。

 3.那么如果说log buffer小于一个事务要写的日志大小怎么办？这是另外一个需要研究的主题了。目前我还不清楚。

4.从上面的信息来看，是否可以很容易知道log buffer大小应该给多少呢？最大的写入小于40K，这好像可以说明分配64K给log buffer就已经足够了。这是真的吗？我们需要去测试才可以知道。peter以前和我谈过这个问题，log buffer背后的机制其实是很复杂的，到底log buffer需要保留多少空间给写操作。这些都需要更深入的研究。但是有一点可以确认，即使最大的写入操作不是很大的情况下，如果log buffer设置太小，性能肯定是不好的，而且会造成而外的锁。这个问题或许我们同样需要去研究。

最后，研究innodb是如何写日志的很容易，但是事实上innodb redo log机制是很复杂的，有时候我们很难说去猜想应该是什么样的，而应该去更深入的研究才可以知道的更多。也许我们可以按照上面这种步骤去研究不同LOG buufer大小，不同的日志参数设置，以及不同的服务器负载的情况下innodb到底是如何来写入日志的。

参考地址：http://mysqlha.blogspot.com/2009/06/buffered-versus-direct-io-for-innodb.html

只导出表结构：
 mysqldump   -d –trigger=false
只导出存储过程：
mysqldump -f  -Rtdn –triggers=false
只导出触发器：
 mysqldump -f  -tdn –triggers
只导出事件：
 mysqldump -f  -Etdn –triggers=false
只导出数据：
mysqldump -f  –single-transaction –triggers=false  -t

         今天看一个水友说他的MySQL现在变的很慢。问什么情况时。说单表超过2个G的一个MyISAM。真垃圾的回答方式。

    简单答复：换一个强劲的服务器。换服务器很管用的：）

………
       最终让取到慢查询：

    SELECT * FROM pw_gbook WHERE uid='N' ORDER BY postdate DESC LIMIT N,N;

如：

   SELECT * FROM pw_gbook WHERE uid='48' ORDER BY postdate DESC LIMIT 1275480,20;

        看到这个语句我都吐血了（BT的PHPWIND分页啊，这个语句是PHP初学者写出来的还正常，但PHPWIND那么成熟的社区了还有这样的问题）。
        我这里简单说一下LIMIT的原理。这里以LIMIT N,M为基础：LIMIT首先要找查N+M行，然后从N行处，取M行。那么这样的SQL对一次查询1275500一个操作应该是一个昂贵的开销。对于LIMIT这类的优化，第一个目标就是让N变的尽可能的小或是不用。
     怎么才能使这个N尽可能小呢。我们能做的其实就是用相对的值，给分页一个提示。如现在我们看的是第5页，看完看想看第6页，第6页同样显示是20条记录。我们就可以想到，以这个例子为准：我们可以肯定的是第6页的日值应小于第5页的，如果第5页的最小日值为：2009-11-4，那我们就可以用：

     SELECT * FROM pw_gbook WHERE uid='48' and postdate<’2009-11-1’ ORDER BY postdate DESC LIMIT  20;

这样来查询第6页的内容。同样对于查看第4页的内容（假设第5页的最大日期为：2009-11-3）则第4页的内容为：

     SELECT * FROM pw_gbook WHERE uid='48' and postdate>’2009-11-3’ ORDER BY postdate DESC LIMIT  20;

         这是一个基本的思想。接下来讨论一下怎么展现的问题。

         再说一下这种业务的SQL怎么实现：对于分页的展示可以用多用类型。这里说三种常用的类型：

第一种：显示“上一页” “下一页”这种类型

         这种方式相对简单也就出现了我们看到那种SQL不思考的写法。合理的做法：

         第一页：

     SELECT * FROM pw_gbook WHERE uid='48' ORDER BY postdate DESC LIMIT  20;

         第二页：根据第一页的postdate进行查询如：

      SELECT * FROM pw_gbook WHERE uid='48'  and postdate<’2009-11-3’  ORDER BY postdate DESC LIMIT  20;

         为什么说这个简单呢，这个不存在跳页的问题。接下来这种就存在一个跳页的问题了。

第二种：显示 “ 1,2,3,4,5…”

         第一页： 还是以第一页的方式实现：

         SELECT * FROM pw_gbook WHERE uid='48' ORDER BY postdate DESC LIMIT  20;

         第二页：和原来一样。如果跳页，如从第二页跳到第5页，这里有一个第二页的最小日期为：2009-11-3（假设值，可以由第二页的程序查询得到），第二到第5，差2页，每页20条记录，那么就可以用：

SELECT * FROM pw_gbook WHERE uid='48'  and postdate<’2009-11-3’  ORDER BY postdate DESC LIMIT  40，20;

        看到这里明白为什么大型网站的分页不是一下标识出来完了，让都能点了吧。也不会给你一个框让你输入一个页跳过去了。如果跳的页面过多，也就存在N值过大的问题了。所以要想办法必免。

第三种：显示 “1，2，3，4，5，…. 末页” 或是 “首页，<<100,101,102,103 >>末页”

这里有一个特殊的一地方：

别的页面的跳转的上面一样。这里就加一个末页，这里又分两种情况，如果知道最后一页是多少页，也就知道了前一页的最小日期（分页提示值），这样就可以用上面的方法查看最后一页的内容（会出现不足20条的现象），另一种，我就不知道最后是第几页，我就是想看看最后什么样子，那么就可以用（一定是显示20条）：

SELECT * FROM pw_gbook WHERE uid='48' ORDER BY postdate ASC limit 20;

         首页这里就不在说了。

         具体怎么实现搞明白了，就可以做PHP代码的修改了。稍稍修改一下，就会带来意想不到的效果。

这里只是一个通用的分页处理方法。不同的业务有可能还有不同的方法处理。如果在条件可能和情况可以考用:between … and .. 带代替limit分页操作。

第三种方法：        
简单的逻辑转换。

   SELECT * FROM pw_gbook WHERE uid='48' ORDER BY postdate DESC LIMIT 1275480,20;

转换成：

   SELECT * FROM pw_gbook WHERE id>1275480 and  uid='48' ORDER BY postdate DESC LIMIT 20;

本站提供专业：PHPWIND优化，DISCUZ优化，DRUPAL优化 及相关咨询

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.10.118
                  Master_User: repl_wu
                  Master_Port: 3306
                Connect_Retry: 30
              Master_Log_File: mysql-bin.005121
          Read_Master_Log_Pos: 64337286
               Relay_Log_File: relay-bin.003995
                Relay_Log_Pos: 18446697137031827760
        Relay_Master_Log_File: mysql-bin.005121
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 1594
                   Last_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 4
              Relay_Log_Space: 64337901
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1594
               Last_SQL_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
1 row in set (0.00 sec)
 

        从上面可以看到是中继日值或是Master上的日值出问题了。
        首先如果是中继日值坏掉，那只需要找到同步的时间点，然后重新同步，这样就可以有新的中继日值了。如果Master上的日值坏了就麻烦了。
从经验来看，这是中继日值出问题了。处理方法：

    需要找到同步的点。

日值为：Master_Log_File: mysql-bin.005121，Relay_Master_Log_File: mysql-bin.005121以Relay_Master_Log_File为准，Master_Log_File为参考。

日值执行时间点：

Exec_Master_Log_Pos: 4

那么现在就可以：

  
      mysql>stop slave;
 
    mysql>change master to Master_Log_File=’mysql-bin.005121’, Master_Log_Pos=4;
   
    mysql>start slave;
 
    mysql>show slave status\G;

    进行确认。

   建议：

    在使用MySQL-5.1.36以下的版本的同学，请尽快升级到MySQL-5.1.40 & MySQL-5.1.37sp1

    从服务器show slave status\G;状态正常，show processlist;这个时候我观察到一个复制线程的Time值为4294967295，这个数字为2^32-1,数据比较特殊，然后我再show processlist;Time成为0，再查看，Time值变为1，等会再查看的时候Time值又变为4294967295，反正TIME值就是在 4294967295,0,1之间变化，show slave status\G,从服务器正常在运作。
mysql> show processlist;
+——-+————-+———–+——+———+————+———————————————————————–+——————+
| Id    | User        | Host      | db   | Command | Time       | State                                                                 | Info             |
+——-+————-+———–+——+———+————+———————————————————————–+——————+
|     4 | system user |           | NULL | Connect |    2950273 | Waiting for master to send event                                      | NULL             |
|     5 | system user |           | NULL | Connect | 4294967295 | Has read all relay log; waiting for the slave I/O thread to update it | NULL             |
| 14814 | root        | localhost | NULL | Query   |          0 | NULL                                                                  | show processlist |
+——-+————-+———–+——+———+————+——————————————————————

mysql> show processlist;
+——-+————-+———–+——+———+———+———————————————————————–+——————+
| Id    | User        | Host      | db   | Command | Time    | State                                                                 | Info             |
+——-+————-+———–+——+———+———+———————————————————————–+——————+
|     4 | system user |           | NULL | Connect | 2950543 | Waiting for master to send event                                      | NULL             |
|     5 | system user |           | NULL | Connect |       0 | Has read all relay log; waiting for the slave I/O thread to update it | NULL             |
| 14814 | root        | localhost | NULL | Query   |       0 | NULL                                                                  | show processlist |
+——-+————-+———–+——+———+———+———————————————————————-

mysql> show processlist;
+——-+————-+———–+——+———+———+———————————————————————–+——————+
| Id    | User        | Host      | db   | Command | Time    | State                                                                 | Info             |
+——-+————-+———–+——+———+———+———————————————————————–+——————+
|     4 | system user |           | NULL | Connect | 2950574 | Waiting for master to send event                                      | NULL             |
|     5 | system user |           | NULL | Connect |       1 | Has read all relay log; waiting for the slave I/O thread to update it | NULL             |
| 14814 | root        | localhost | NULL | Query   |       0 | NULL                                                                  | show processlist |
+——-+————-+———–+——+———+———+———————————————————————-

这个时间表示：
Slave的SQL线程连接上Master的时间点和实际进行的SQL点的时间差别。例，当Slave和Master断开时间为30分钟，再时连上，这个时间为1800。
另一方面网络不稳也会出现问题。

对于一个2000W的大表，一次走一个全表扫描确是很困难的。不过对于100W的表走一个全描扫也困难。

如果做这件事情又不想影响太大，就要分步来完成。

我给你一个思路你来参考一下。
首先衡量删除操作有多大。
selet count(*) from table1 a ,table2 b where a.pid=b.pid;
如果都有索引的话，这个操作还是挺快的。
如果操作的操作大于原表的40%，那么很有必要重建这个表了。

重建表的方法：就是按条件提取数据到一个新表，最后改名完成。这是一种方案。

另一种 删除方向。

上面通过比较觉的需要删除的量不是太大时，把需要删除的PID生到到另一个临时表中。
mysql DBname -e “select a.pid from table1 a ,table2 b where a.pid=b.pid”>del_pid.txt;

sed -i ‘1d’ del_pid.txt
awk ‘{print “delete from table1 where pid=”,$1,”;”}’ del_pid.txt >del_pid.sql
mysql DBname<del_pid.sql

这样把SQL拆成多个SQL执行速度应该不会太慢了。

如果还是感觉不行，那就只能分段操作了。

备注：http://bbs3.chinaunix.net/thread-1453362-1-1.html

用户名：一般用字母组成。
机器名：可以是机器ＩＰ也可以机器名。机器名可以用dns也可以在/etc/hosts中声明。

所以可以称为不是两个root用户。

反应到user表中,用户名对应user，机器名对应于host,密码对应于password
一个用户名完整的标识为：user@host

更改密码：
set  password for ‘用户名’@'主机名‘=password(‘yourpassword’);

所以你见到的两个Ｒｏｏｔ不能算是一个用户名的。