老规矩，我们还是从一些看似不着边际的基础知识开始说起吧。。。。

操作系统的一些概念

我们常说的磁盘结构图如下：绿色弧道的就是扇区，灰色的就是磁道

磁盘中每个盘面结构 磁盘的整体结构
扇区是磁盘的最小组成单元，是磁盘的读写单位，大小我们就机械的认为是512字节。
柱面 就是第一张图中的磁道
磁盘存储容量 = 磁头数磁道（柱面）数每道扇区数每扇区字节数
可能有人会发现，每个扇区存储大小一样，那岂不是越靠近圆心的扇区越密集？？对于老式磁盘确实是！新式磁盘有所改进，但是我们不打算深究～～～～
磁盘块（blocks）是操作系统层面的虚拟概念，是操作系统与磁盘打交道的最小单位，一般是4KB（一般是扇区大小2^n）
页 是操作系统与内存打交道的最小单位

InnoDB中的一些概念

为了显的高大上，我们也俗套的甩几个专业名次上来吧😢
Buffer Pool数据库缓冲池
Redo Log 重做日志，先理解成草稿吧
Datafile 数据文件，先理解成正稿及最终稿吧
Checkpoint,LSN
上面说的这几个概念都是为了在提升性能的同时，又能保证数据不丢失，那么是怎么做到的呢？请看下面一个对比的例子，大家就会明白

互联网圈，为了骗取投资人的钱，在进行融资前都会编一些ppt啥的，老板让你给他编一个可以忽悠人的ppt，你突然想到一个绝美的idea，但是你白天都在划水，又不想干活，只想晚上加班搞，但你又担心 暂时记在脑子里的这个idea到晚上会忘记，你就会先围绕这个idea大概思考一个大纲，匆忙记到一个草稿上，然后立马跑到老板面前告诉他，你要编什么东东，让他确认，到晚上了，根据草稿的内容去斟词酌句，编写正文。正文就是我们最终要拿去骗钱的ppt。
这里我们的大脑就相当于Buffer Pool,我们的大脑就像内存一样记得快，忘的也快，就像内存数据易丢失一样
重做日志Redolog，就好比我们的草稿
Datafile就是我们的正稿
按照我们编ppt的方式，来进行数据库事务的写入操作，不仅能保证数据不丢失（大脑忘记了还有草稿），还能够快速响应，得到客户端的确认（我们快速给老板响应告诉他写什么，得到他的确认）

数据库为了保证这个 【草稿】一定能恢复成正稿，还不能占用太多空间，就要求这个redo log（草稿）必须具有几个特点
Redo log一定要保存了所有要写入的内容
Redolog 只会在文件末尾增加数据，而不会去改变旧的数据
一旦事务数据被写入datafile，redo log中的草稿就可以删除了
正文在形成之前，草稿是不会删除的；也就是说只要草稿在我们一定能写出正文，就算数据库Crash了，只要又redolog我们也不怕。

我们知道，数据库在使用过程中事务是源源不断的，也是很快的，而且根据草稿写出正稿是一个很费时间的时，所以往往草稿的产生速度是远远大于正稿的产生速度的，也就是说你加班一个晚上根本写不完，要连续写好多次才有可能写完。 这样就会面临一个问题，昨天我编到哪里了？当然你也可以一个个去对，但是这样效率也太低了吧。 你或许会把最后一条生成正稿的草稿 打上一个标记，这样第二天可以直接从这个标记的地方开始写，而不关心前面的内容，也可以把前面的草稿内容删除掉。

这里最近一条变成正稿的草稿记录就是Checkpoint,LSN就是每条草稿的编号。

数据库配置文件汇总

木有办法，为了讲解innodb的某些东西，我不得不先拐个弯，把mysql配置吃透～～～
首先我们通过如下命令获取到mysql服务的安装目录

安装目录 可以看到我的安装目录是/usr 或者连上sql时 执行select @@basedir命令。

使用ps aux|grep mysql|grep 'my.cnf' 查看mysql启动的配置文件，如果没有，说明使用的默认配置，使用下面的命令

mysql --help|grep 'my.cnf' 启动时会使用第一个目录的文件
order of preference, my.cnf, $MYSQL_TCP_PORT,
/etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf

启动服务 mysqld start 重启服务mysqld restart 停止服务 mysqld stop

现在我们知道了如何查找配置文件，已经如何启动服务（其它更详细的命令后续用到了再说），终于开始正儿八经研究配置文件了

• 数据库配置文件汇总

// 这个是官方的默认文件，我们按照自己的学习记录一步一步去填充吧。在后续的概念讲解中，我们会不时的翻到这个配置文件中来做说明

/*对mysql服务器的优化参数主要集中在mysqld段中国，其它段的参数对mysql性能的影响微乎其微*/
[mysqld]
# 开启innodb引擎的独立表空间MySQL5.6.7之后默认开启
innodb_file_per_table = 1

# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
# innodb_buffer_pool_size = 128M

# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin

# These are commonly set, remove the # and set as required.
# basedir = .....
# datadir = .....
# port = .....
# server_id = .....
# socket = .....

# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
# join_buffer_size = 128M
# sort_buffer_size = 2M
# read_rnd_buffer_size = 2M

sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

• 表空间：即存放数据库表数据的地方
  表空间的具体数据结构我们后续讲，先搞明白这个表空间是干什么用的，在看原理。
  Innodb有两种管理表空间的方法：
  1． 共享表空间（这个我们暂时不研究）
  2． 独立表空间每一个表有一个独立的表空间（现在都用这个，随着我们讲解的进行，好处自然而然会出来）
  如果想要使用独立表空间，my.conf中配置innodb_file_per_table【请参照配置文件】
  使用命令 show VARIABLES like 'innodb_file_per_table'; 查看独立表空间是否开启
  开启该功能后，每创建一个新表就会在数据存放目录中的相应库目录下面(我的是/var/lib/mysql，这个目录可以通过上文截图中的--datadir=/var/lib/mysql找到)增加一个ibd文件，ibd文件就是该数据表的数据文件了。
  这个目录下，每个表都会对应一个.frm 文件和一个 .ibd文件，其中.frm是表结构文件，.ibd 是数据文件。其中.frm文件是每个存储引擎都会有的一个文件。
  .ibd文件
  innodeb引擎，使用IOT（索引组织表，即表中的数据都是根据主键顺序组织存放）的形式来管理表数据，表的索引跟数据都保存在.ibd文件中
  既然说到了索引，我们又要先跑一下题，看一下InnoDB引擎的索引，innodb使用是B+树索引。先从B+树结构说起吧 B数结构 B树的一个大概查找思路如下：

每个节点中都是有序码表，假如我们要查找9，首先在第一层查找，因为1<9<35 所以定位到第二层的2-10之间，然后定位到第三层，在有序码表中>8最终找到叶子节点上（B数中叶子节点不保存数据），如果找到了叶子节点上，说明该数据不存在。同理找37就可以找到。

innodb表的索引跟数据文件是同一个.idb文件，innodb使用B+Tree，与上图的区别是，叶子节点非空，页节点的data域保存了完整的数据记录，码值域就是数据表的主键。这种索引与数据文件在一块的就是聚集索引。innodb表的辅助索引也是先找到对应的主索引，然后再根据主索引找到数据data这是因为innodb表的数据是按照主键聚集的，这也同时要求innodb表必须有主键
单独表空间优点和缺点
优点
每个表都有自已独立的表空间。
每个表的数据和索引都会存在自已的表空间中。
可以实现单表在不同的数据库中移动。
空间可以回收
缺点
1单表增加过大，响应也是较慢，可以使用分区表
2单表增加过大，当单表占用空间过大时，存储空间不足，只能从操作系统层面思考解决方法