기본적인 프로세스 및 SQL 쿼리는 그 파서, 최적화, 결국 액츄에이터에 처리되어야 즉, 동일하다.
차이는 수술 후 자격을 갖춘 데이터를 얻을 수 있다는 것입니다.
1. 풀 버퍼 풀
首先，InnnoDB 的数据都是放在磁盘上的，InnoDB 操作数据有一个最小的逻辑单位，叫做页（索引页和数据页）。我们对于数据的操作，
不是每次都直接操作磁盘，因为磁盘的速度太慢了。InnoDB 使用了一种缓冲池的技术，也就是把磁盘读到的页放到一块内存区域里面。
这个内存区域就叫 Buffer Pool。
下一次读取相同的页，先判断是不是在缓冲池里面，如果是，就直接读取，不用再次访问磁盘。
修改数据的时候，先修改缓冲池里面的页。内存的数据页和磁盘数据不一致的时候，我们把它叫做脏页。InnoDB 里面有专门的后台线程把
Buffer Pool 的数据写入到磁盘，每隔一段时间就一次性地把多个修改写入磁盘，这个动作就叫做刷脏。
Buffer Pool 是 InnoDB 里面非常重要的一个结构，它的内部又分成几块区域。
这里我们趁机到官网来认识一下 InnoDB 的内存结构和磁盘结构。2.InnoDB 디스크 구조와 메모리 구조
2.1 메모리 아키텍처
Buffer Pool 主要分为 3 个部分： Buffer Pool、Change Buffer、Adaptive HashIndex，另外还有一个（redo）log buffer。1, 버퍼 풀
Buffer Pool 缓存的是页面信息，包括数据页、索引页。其中Buffer Pool 默认大小是 128M（134217728 字节），可以调整。
查看服务器状态，里面有很多跟 Buffer Pool 相关的信息：SHOW STATUS LIKE '%innodb_buffer_pool%';이러한 상태는, 의미의 공식 웹 사이트에서 자세히 볼 수있는 검색 기능을 사용 할 수 있습니다.
https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html
보기 매개 변수 (시스템 변수) :
SHOW VARIABLES like '%innodb_buffer_pool%';이러한 상태는, 의미의 공식 웹 사이트에서 자세히 볼 수있는 검색 기능을 사용 할 수 있습니다.
https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html
内存的缓冲池写满了怎么办？（Redis 设置的内存满了怎么办？）InnoDB 用 LRU算法来管理缓冲池（链表实现，不是传统的 LRU，
分成了 young 和 old），经过淘汰的数据就是热点数据。
内存缓冲区对于提升读写性能有很大的作用。思考一个问题：
当需要更新一个数据页时，如果数据页在 Buffer Pool 中存在，那么就直接更新好了。否则的话就需要从磁盘加载到内存，
再对内存的数据页进行操作。也就是说，如果没有命中缓冲池，至少要产生一次磁盘 IO。2, 변경 버퍼 버퍼 쓰기
如果这个数据页不是唯一索引，不存在数据重复的情况，也就不需要从磁盘加载索引页判断数据是不是重复（唯一性检查）。
这种情况下可以先把修改记录在内存的缓冲池中，从而提升更新语句（Insert、Delete、Update）的执行速度。
这一块区域就是 Change Buffer。5.5 之前叫 Insert Buffer 插入缓冲，现在也能支持 delete 和 update。
最后把 Change Buffer 记录到数据页的操作叫做 merge。
什么时候发生 merge？
有几种情况：在访问这个数据页的时候，或者通过后台线程、或者数据库 shut down、redo log 写满时触发。
如果数据库大部分索引都是非唯一索引，并且业务是写多读少，不会在写数据后立刻读取，就可以使用 Change Buffer（写缓冲）。
写多读少的业务，调大这个值：SHOW VARIABLES LIKE 'innodb_change_buffer_max_size';변화는 버퍼 풀 버퍼를 차지 비율, 기본 25 %를 나타냅니다.
3.Adaptive 해시 색인
4. (재실행) 로그 버퍼
思考一个问题：如果 Buffer Pool 里面的脏页还没有刷入磁盘时，数据库宕机或者重启，这些数据丢失。如果写操作写到一半，
甚至可能会破坏数据文件导致数据库不可用。为了避免这个问题，InnoDB 把所有对页面的修改操作专门写入一个日志文件，并且
在数据库启动时从这个文件进行恢复操作（实现 crash-safe）——用它来实现事务的持久性。
这个文件就是磁盘的 redo log（叫做重做日志），对应于/var/lib/mysql/目录下的ib_logfile0 和 ib_logfile1，每个 48M。
这 种 日 志 和 磁 盘 配 合 的 整 个 过 程 ， 其 实 就 是 MySQL 里 的 WAL 技 术（Write-Ahead Logging），
它的关键点就是先写日志，再写磁盘。show variables like 'innodb_log%';| 값 | 의미 |
|---|---|
| innodb_log_file_size | 각 파일의 크기를 지정, 기본 48M |
| innodb_log_files_in_group | 지정 파일의 수, 기본값은 2입니다 |
| innodb_log_group_home_dir | 상대적 또는 절대적, 파일 경로를 지정한다. 당신은 DATADIR의 경로를 지정하지 않은 경우. |
품질 보증 : 같은 디스크에 쓰기, 왜 내부 갈 직접 DB 파일을 쓸 수 없습니다? 왜 로그 쓰기 디스크를 첫번째?
先来了解一下随机 I/O 和顺序 I/O 的概念
磁盘的最小组成单元是扇区，通常是 512 个字节。
操作系统和内存打交道，最小的单位是页 Page。
操作系统和磁盘打交道，读写磁盘，最小的单位是块 Block。
如果我们所需要的数据是随机分散在不同页的不同扇区中，那么找到相应的数据需要等到磁臂旋转到指定的页，
然后盘片寻找到对应的扇区，才能找到我们所需要的一块数据，一次进行此过程直到找完所有数据，这个就是随机 IO，
读取数据速度较慢。假设我们已经找到了第一块数据，并且其他所需的数据就在这一块数据后边，那么就不需要重新寻址，
可以依次拿到我们所需的数据，这个就叫顺序 IO。刷盘是随机 I/O，而记录日志是顺序 I/O，顺序 I/O 效率更高。因此先把修改写入日志，可以延迟刷盘时机，进而提升系统吞吐。
当然 redo log 也不是每一次都直接写入磁盘，在 Buffer Pool 里面有一块内存区域（Log Buffer）专门用来保存即将要写入
日志文件的数据，默认 16M，它一样可以节省磁盘 IO。
SHOW VARIABLES LIKE 'innodb_log_buffer_size';需要注意：redo log 的内容主要是用于崩溃恢复。磁盘的数据文件，数据来自 buffer pool。redo log 写入磁盘，不是写入数据文件。QA : 글쎄, 로그 버퍼 때 쓰기 로그 파일?
在我们写入数据到磁盘的时候，操作系统本身是有缓存的。flush 就是把操作系统缓冲区写入到磁盘。
log buffer 写入磁盘的时机，由一个参数控制，默认是 1。SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';
-- 官网 https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit| 값 | 의미 |
|---|---|
| 0 | (기록 레이턴시) 로그 버퍼 로그 파일을 작성할 수 초마다, 로그 파일 및 플러쉬 동작은 동시에 수행된다. 트랜잭션이 커밋 될 때이 모드에서는, 그것은 디스크에 기록 트리거 조치에 주도권을 쥐고하지 않습니다. |
| 1 | (기본적으로 실시간 기록, 실시간 브러쉬) 모든 MySQL의 로그 버퍼 데이터가 갈 디스크에 트랜잭션 로그 제출 한 파일 및 브러시에 기록됩니다 넣어 것입니다. |
| 이 | （实时写，延迟刷）每次事务提交时 MySQL 都会把 log buffer 的数据写入 log file。但是 flush 操作并不会同时进行。该模式下，MySQL 会每秒执行一次 flush 操作。 |
QA:redo log，它又分成内存和磁盘两部分。redo log 有什么特点？
1、redo log 是 InnoDB 存储引擎实现的，并不是所有存储引擎都有。
2、不是记录数据页更新之后的状态，而是记录这个页做了什么改动，属于物理日志。
3、redo log 的大小是固定的，前面的内容会被覆盖。
check point 是当前要覆盖的位置。如果 write pos 跟 check point 重叠，说明 redo log 已经写满，这时候需要同步 redo log 到磁盘中。
这是 MySQL 的内存结构，总结一下，分为：
Buffer pool、change buffer、Adaptive Hash Index、 log buffer。
磁盘结构里面主要是各种各样的表空间，叫做 Table space。