undolog是在innodb的回滚段里的（确切是rollback segment->undo segment），这个也是buffer pool的一部分。同步到buffer pool，实际是包含了插入undolog的过程。（同样，flush to disk也需要把undo log写入磁盘）。redolog不保证不丢失数据，只保证数据原子性。
一、redo log和undo log以及bin log的生成流程
1.undolog是在innodb的回滚段里的（确切是rollback segment->undo segment），这个也是buffer pool的一部分。你所说的同步到buffer pool，实际是包含了插入undolog的过程（同样，flush to disk也需要把undo log写入磁盘）。
2.redolog不保证不丢失数据，只保证数据原子性。即保障经过redolog写入的数据是原子的。这个地方你是可以通过innodb_flush_log_at_trx_commit去修改，默认这里是1，也就是说每次写redolog的时候都会直接调用fsync要求落盘，那就不存在你说的问题了（应该说是在处理用户请求的过程里如果宕机就会丢失数据）。当然你也可以设置为0或者2把日志落盘这件事交给单独的线程去处理。
至于顺序是:修改数据(这个包含了undolog)->修改redolog(prepare)->修改binlog(同时设置redo-log事务状态为commit)。因为Innodb本身实现的复杂性，这里面每个部分都涉及非常多的操作。
关于 MySQL 不将每次操作都同步到磁盘，而是同步到 buffer pool 中的疑惑，是因为 buffer pool 是内存中的缓存区域，相比磁盘来说读取速度更快，可以提高数据库性能。而 undo log 存储的是旧数据的备份，这样即使出现宕机等问题，也可以通过 undo log 来恢复事务处理之前的数据状态。
redo log 的作用是记录数据的修改，包括增加、修改、删除等，即使发生异常宕机等情况也可以通过 redo log 来进行数据恢复。而 MySQL 在执行事务的过程中，会将 redo log 缓存在内存中的 redo log buffer 中，在事务提交时才将其写入磁盘的 redo log 文件中，所以在宕机等异常情况下，有可能会丢失部分数据，但是通过 redo log 可以尽可能地减少数据丢失的风险。因此，在生产环境中，为了保证数据的安全性和完整性，需要合理地配置 redo log 大小以及定期将数据写回磁盘中。
延伸阅读：
二、信息抽取是什么
信息抽取（infromation extraction）信息抽取是一种自动化地从半结构化和无结构数据中抽取实体、关系以及实体属性等结构化信息的技术。关键技术包括：实体抽取、关系抽取和属性抽取。
1、实体抽取，也称为命名实体识别（named entity recognition，NER），是指从文本数据集中自动识别出命名实体。
当前主流技术为面向开放域（open domain）的实体抽取。
2、关系抽取，为了得到语义信息，从相关语料中提取出实体之间的关联关系，通过关系将实体联系起来，才能够形成网状的知识结构。其技术研究已经从早期的“人工构造语法和语义规则”（模式匹配），“统计机器学习”发展到“面向开放域的信息抽取方法”与“面向封闭领域的方法”相结合。
3、属性抽取，目标是从不同信息源中采集特定实体的属性信息，如针对某个公众人物，可以从网络公开信息中得到其昵称、生日、国籍、教育背景等信息。采用数据挖掘的方法直接从文本中挖掘实体属性和属性值之间的关系模式，据此实现对属性名和属性值在文本中的定位。
