@JasonLaw
我再组织下语言：
故障恢复，
一种是运行中宕机，主存数据丢失。针对这种情况，PPT ch16 的第 25 页提出一种可行的恢复方式，恢复分为 2 个阶段，redo （如你指出，replay 所有操作）、undo 。
一种是数据库磁盘文件损坏（这是你的帖子问的情况）。 恢复方式为在最近一次的数据库备份基础上，进行 redo （下面这个图片是 ppt 36 页，明确说是 commited ）。


至于为什么前者需要，redo replay 所有，再 undo，而后者不这样干，我认为可能是：

数据库模型，在 提交时是否强制落盘 force/no-force，提交前是否禁止落盘 steal/no-steal 这两个方面（ 4 种组合）的实现不一（应该是处于并发性能的考虑），导致会出现未提交的事务数据已经写到磁盘、或者是提交了的事务数据还不在磁盘上 这种短暂的状态。运行时宕机的恢复自然要考虑这样的事情，只有 redo 所有再 undo 才能保证恢复后数据“正确”。
否则 仅 redo committed 的 会导致 磁盘上提前落盘的数据（ which shouldn't be commited ）仍然待在磁盘上---所以需要 redo+undo 来复写还原这部分数据到旧值。

磁盘故障恢复，就不存在这样的情况---备份文件是前一个时间正确的数据，不存在“脏数据”，所以直接 redo 所有 committed 事务，增量更新上去就可以了

@JasonLaw 如果动作分为 redo 动作 和 undo 动作。一个事务没有 commit 行那就是计入 undo-list 参与 undo 操作，不计入 redo-list，就不是 redo 动作，除掉 undo 的 所有动作 就是 所有 redo 了吧。

在最近一次转储的基础上恢复，如日志（转储时间点之后的）中事务缺少<T,commit>行，忽略这个事务就行了，也无需 undo 。从一个一致状态，重复所有已提交事务，没啥问题啊。

团建中每一个人都难受。

这个语句没有毛病。不太清楚要优化什么。

这张表目前多少数据？
这个语句目前耗时？
有 filesort 怎么了？
变成 index 怎么了？

说着说着，总感觉我在说废话。以其昏昏使人昭昭

应该是根据 session 直接返回你对应的邮件了， 多个域名只是做个样子吧。看了下 js，域名一直保存在 localstoreage，后端根本不需要。估计向这几个域名发送邮件，都是发送到同一个服务器了

@zhangpeter 不用太过懊恼，吃一堑长一智。

@githubhaoliu 好的 谢谢 看见你说的我又去检查了一下，我的描述确实不对---我没配 autorestart--都起不来。已经改了。

@githubhaoliu 你好，kill -9 杀掉的 也会拉起来吗？ 我自己刚刚使用 supervisor，发现通过 kill -9 杀死的不会拉起（ kill 可以拉起），是不是需要配置什么参数才行？

加油。还在上班吗，最好能卧床休息

```python
from threading import Lock

```

禁了完事， 一个支付软件能给你发什么有用的信息，到账 100 万？ 我寻思着这点钱也不用通知吧

@dawnzhu 那到底因为什么呢。原因说下啊。

@qumingkunnan 另外感觉挺奇怪的 你这个语句。 col1,2,3 是主键，那还 group by col1,2,3 干啥 sum 也没什么用啊，根本不需要。是不是脱敏脱得过头了 跟原意不一致了？

查询快的那种，到底多快？ 70 多秒？
慢的那个 force index 试一下，我看着两个语句也确实一样。

第一次接触，是通过返回时间判断吗，这也太理论了吧？ 1 毫秒的区别也不会有吧，干扰因素那么多，整个返回时间根本不是正相关吧