而且 redo log 是 Innodb 特有的。

是不是可以这样理解。每种成功的概率是 0.9，那么两份备份失败的概率等于 1-0.1*0.1=0.99 ？

我取的也是 林晓斌 的原话，已经解释非常清楚了。

先写 redo log 后写 binlog。假设在 redo log 写完，binlog 还没有写完的时候，MySQL 进程异常重启。由于我们前面说过的，redo log 写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行 c 的值是 1。
但是由于 binlog 没写完就 crash 了，这时候 binlog 里面就没有记录这个语句。因此，之后备份日志的时候，存起来的 binlog 里面就没有这条语句。
然后你会发现，如果需要用这个 binlog 来恢复临时库的话，由于这个语句的 binlog 丢失，这个临时库就会少了这一次更新，恢复出来的这一行 c 的值就是 0，与原库的值不同。

先写 binlog 后写 redo log。如果在 binlog 写完之后 crash，由于 redo log 还没写，崩溃恢复以后这个事务无效，所以这一行 c 的值是 0。但是 binlog 里面已经记录了“把 c 从 0 改成 1 ”这个日志。所以，在之后用 binlog 来恢复的时候就多了一个事务出来，恢复出来的这先写 redo log 后写 binlog。假设在 redo log 写完，binlog 还没有写完的时候，MySQL 进程异常重启。由于我们前面说过的，redo log 写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行 c 的值是 1。
但是由于 binlog 没写完就 crash 了，这时候 binlog 里面就没有记录这个语句。因此，之后备份日志的时候，存起来的 binlog 里面就没有这条语句。
然后你会发现，如果需要用这个 binlog 来恢复临时库的话，由于这个语句的 binlog 丢失，这个临时库就会少了这一次更新，恢复出来的这一行 c 的值就是 0，与原库的值不同。

先写 binlog 后写 redo log。如果在 binlog 写完之后 crash，由于 redo log 还没写，崩溃恢复以后这个事务无效，所以这一行 c 的值是 0。但是 binlog 里面已经记录了“把 c 从 0 改成 1 ”这个日志。所以，在之后用 binlog 来恢复的时候就多了一个事务出来，恢复出来的这先写 redo log 后写 binlog。假设在 redo log 写完，binlog 还没有写完的时候，MySQL 进程异常重启。由于我们前面说过的，redo log 写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行 c 的值是 1。
但是由于 binlog 没写完就 crash 了，这时候 binlog 里面就没有记录这个语句。因此，之后备份日志的时候，存起来的 binlog 里面就没有这条语句。
然后你会发现，如果需要用这个 binlog 来恢复临时库的话，由于这个语句的 binlog 丢失，这个临时库就会少了这一次更新，恢复出来的这一行 c 的值就是 0，与原库的值不同。

先写 binlog 后写 redo log。如果在 binlog 写完之后 crash，由于 redo log 还没写，崩溃恢复以后这个事务无效，所以这一行 c 的值是 0。但是 binlog 里面已经记录了“把 c 从 0 改成 1 ”这个日志。所以，在之后用 binlog 来恢复的时候就多了一个事务出来，恢复出来的这一行 c 的值就是 1，与原库的值不同。

有几个小问题，第一就是抓包返回数据没有格式解析，都是一堆，全选就把整个（包括界面全部复制了）。第二就是你点一下桌面任何一个地方最小化了，很郁闷，必须使用分离窗口才行。整体上很不错的，加油。

查并集。这种一次查询不是很好查，要写一个视图，一个函数。视图实习的功能是查找所有子。函数的功能是从自己开始一层层找上集（从下而上），找到第一个非团长。

其实应该用关联子查询。

我个人觉得最大的改变是前端已经有自己的一套体系了。以前写 mvc，又要考虑数据，又要考虑界面。现在只需要数据驱动。第二点就是快，性能真的提升了 n 倍。如果一定要考虑 seo 也可以多页面，是一样的。

上个星期遇到了一个项目，感觉跟楼主差不多，最后临时把阿里云带宽加到 100M 就好了，就是这么神奇。你可以试下是不是带宽的瓶颈。

三年来我见过最长的帖子。

搞设计的审美确实要强很多。

这个要留名。

说!得!好!