一、物理文件
- 参数文件
告诉Mysql实例启动时在哪里可以找到数据库文件，并且指定某些初始化参数，这些参数定义了某种内存结构的大小等设置。用文件存储，可编辑，若启动时加载不到则不能成功启动（与其他数据库不同）。参数有动态和静态之分，静态相当于只读，动态是可以set的。如我们通过show variable like '***'查出来的key、value值，是可以通过set key=value直接修改的。同是，修改时还有作用域之分，即这个seesion个有效和全局有效，在对应的key前加上session或global即可，如select @@seesion。read_buffer_size、set @@global。read_buffer_size。
- log file
用来记录Mysql实例对某种条件做出响应时写入的文件。如错误日志文件、二进制日志文件、慢查询日志文件、查询日志文件等。
- error log
通过show variables like 'log_error'来查看错误日志存放地址
- slow log
通过show variables like '%long%' 查看慢查询日志记录的阈值，新版本设成了0.05；通过show variables like 'log_slow_queries'查看是否开启了，默认为关闭的；通过show variabes like 'log_queries_not_using_indexes'查看是将没有使用索引的查询记录到慢日志中。mysql中可以直接通过mysqldumpslow命令来查看慢日志。
- general log
记录所有数据库操作记录，平时不建议打开
- bin log
不记录查询，只记录对数据库所有的修改操作。目的是为了恢复(point-in-time修复)和复制。通过show variables like 'datadir'查看存放路径。二进制日志支持STATEMENT、ROW、MIX三种格式，通过binlog_format参数设定，通常设置为ROW，可以为数据库的恢复和复制带来更好的可靠性，但会带来二进制文件大小的增加，复制时会增加网络开销。mysql中通过mysqlbinlog查看二进制日志文件内容。
- socket 文件
当用Unix域套接字方式进行连接时需要的文件。
- pid文件
Mysql实例的进程ID文件。
- 表结构定义文件
用来存放Mysql表结构定义文件。因为Mysql插件式存储引擎的体系结构，每个表都有一个对应的文件，以frm后缀结尾。
- 存储引擎文件
存储自己的文件来保存各种数据，真正存储了数据和索引等数据。下面主要介绍InnoDB的存储引擎下的表空间文件和重做日志文件。
- 表空间文件
InnoDB默认的表空间文件为ibdata1，可通过show variables like 'innodb_file_per_table'查看每个表是否产生单独的。idb表空间文件。但是，单独的表空间文件仅存储该表的数据、索引和插入缓冲等信息，其余信息还是存放在默认的表空间中。
- redo log file
实例和介质失败，重做日志文件就能派上用场，如数据库掉电，InnoDB存储引擎会使用重做日志恢复到掉电前的时刻，以此来保证数据的完整性。参数innodb_log_file_size指定了重做日志文件的大小；innodb_log_file_in_group指定了日志文件组中重做日志文件的数量，默认为2，innodb_mirrored_log_groups指定了日志镜像文件组的数量，默认为1，代表只有一个日志文件组，没有镜像；innodb_log_group_home_dir指定了日志文件组所在路径，默认在数据库路径下。
- archive redo log
二进制日志和重做日志的区别：首先，二进制日志会记录所有与Mysql有关的日志记录，包括InnoDB、MyISAM、Heap等其他存储引擎的日志。而InnoDB存储引擎重做日志只存储有关其本身的事务日志；其次内容不同，不管将二进制日志文件记录的格式设为STATEMENT还是ROW，又或者是MIXED，其记录的都是关于一个事务的具体操作内容。而InnoDB存储引擎的重做日志文件记录的关于每个页的更改的物理情况 。此外，写入时间不同，二进制日志文件是在事务提交前进行记录的，而在事务进行的过程中，不断有重做日志条目被 写入重做日志文件中。
二、线程
- Master Thread
负责刷新缓存数据到磁盘并协调调度其它后台进程。Master thread线程的优先级最高，内部主要是4个循环loop组成：主循环、后台循环、刷新循环、暂停循环。
- 主循环
- loop主循环每秒一次的操作
- 日志缓冲刷新到磁盘，即使这个事务还没有提交。(总是执行，所以再大的事务commit 的时间也是很快的)
- 合并插入缓冲(innodb当前一秒发生的io次数小于5次则执行)
- 至多刷新100个innodb的缓冲池中的脏页到磁盘(超过配置的脏页所占缓冲池比例则执行，在配置文件中由innodb_max_dirty_pages_pac决定，默认是90，新版本是75，google建议是80)
- 如果当前没用用户活动，切换到backgroud loop
- loop主循环每10秒一次的操作
- 刷新100个脏页到磁盘(过去10秒IO操作小于200次则执行)
- 合并至多5个插入缓冲(总是)
- 将日志缓冲到磁盘(总是)
- 删除无用的Undo页(总是)
- 刷新100个或者10个脏页到磁盘(有超过70%的脏页，刷新100个脏页;否则刷新10个脏页)
- 产生一个检查点
- 后台循环
- 删除无用的Undo页(总是)
- 合并20个插入缓冲(总是)
- 跳回到主循环(总是)
- 不断刷新100个页，直到符合条件(可能在flush loop中完成)
- 刷新循环
- 暂停循环
- Async I/O Thread
在innodb存储引擎中大量使用AIO来处理IO请求，这样可以极大提高数据库的性能，而IO thread的工作就是负责这些IO请求的回调处理（call back），InnoDB 共有10个 IO Thread， 分别是 4个 write、4个 read、1个 insert buffer和1个 log thread。
- Purge Thread
事务提交后，其所使用的undolog可能不再需要，因此需要改线程来回收。InnoDB 引擎默认设置为4个 Purge Thread
- 删除附注索引中不存在的记录；
- 删除已经被打了delete-marked标记的记录
- 删除不需要的undo log
- Page Cleaner Thread
用于将脏页的刷新操作都放入到单独的线程来完成
三、内存
- Buffer Pool
InnoDB 存储引擎是基于磁盘存储的，其中的记录按照页的方式进行管理，由于 CPU 速度和磁盘速度之间的鸿沟， InnoDB 引擎使用缓冲池技术来提高数据库的整体性能。
- undo page
- insert buffer page
不是缓冲池的一部分，Insert Buffer是物理页的一个组成部分，它带来InnoDB性能的提高。根据B+算法(下文会提到)的特点，插入数据的时候会主键索引是顺序的，不会造成数据库的随机读取，而对于非聚集索引(即辅助索引)，叶子节点的插入不再是顺序的了，这时需要离散地访问非聚集索引，插入性能在这里变低了。InnoDB引入插入缓冲，判断非聚集索引页是否在缓冲池中，如果在则直接插入;不在，则先放在 插入缓冲区中。然后根据上述master thread中介绍的，会有一定的频率将插入缓冲合并。此外，辅助索引不能是唯一的，因为插入到插入缓冲时，并不去查找索引页的情况，否则仍然会造成随机读，失去插入缓冲的意义了。插入缓冲可能会占缓冲池中内存，默认也能会占到1/2，所以可以将这个值调小点，到1/3。通过IBUF_POOL_SIZE_PER_MAX_SIZE来设置，2表示1/2，3表示1/3。
- adaptive hash index
InnoDB存储引擎提出一种自适应哈希索引，存储引擎会监控对表上索引的查找，如果观察到建立建立哈希索引会带来速度的提升，则建立哈希索引，所以称之为自适应的。自适应哈希索引只能用来搜索等值的查询，如select * from table where index_col='***'， 此外自适应哈希是由InnoDB存储引擎控制的，我们只能通过innodb_adaptive_hash_index来禁用或启用，默认开启。
- index page
- data dictionary
- lock info
- Redo Log Buffer
InnoDB 存储引擎先将重做日志信息放入这个缓冲区，然后以一定频率将其刷新到重做日志文件。重做日志文件一般不需要设置得很大，因为在下列三种情况下重做日志缓冲中的内容会刷新到磁盘的重做日志文件中。
- Master Thread 每一秒将重做日志缓冲刷新到重做日志文件
- 每个事物提交时会将重做日志缓冲刷新到重做日志文件
- 当重做日志缓冲剩余空间小于1/2时，重做日志缓冲刷新到重做日志文件
- Additional Memory Pool
在 InnoDB 存储引擎中， 对一些数据结构本身的内存进行分配时，需要从额外的内存池中进行申请。例如，分配了缓冲池，但是每个缓冲池中的帧缓冲还有对应的缓冲控制对象，这些对象记录以一些诸如 LRU， 锁，等待等信息，而这个对象的内存需要从额外的内存池中申请。
