InnoDB提供了两种存储统计数据的方式
系统变量innodb_status_persistent来控制到底采用哪种方式去存储统计数据。另外，InnoDB默认是以表为单位来收集和存储统计数据的，所以可以把某些表的统计数据存储在磁盘上，把另一些表的统计数据存储在内存中。可以在创建和修改表的时候通过指定STATS_PERSISTENT属性来指明该表的统计数据存储方式
const:
1.直接利用主键值在聚簇索引中定位对应的用户记录
2.根据唯一二级索引列来定位一条记录
ref:
1.对某个普通的二级索引列与常数进行等值比较
2.无论是普通二级索引还是唯一二级索引，索引列值为NULL
3.对于某个包含多个索引列的二级索引来说，只要是最左边的连续索引列是与常数的等值比较
ref_of_null:
1.当我们不仅想找出某个二级索引列的值等于某个常数的记录，还想把列的值为NULL的记录也找出来
range:
1.利用索引进行范围匹配
index:
1.直接遍历二级索引记录
all:
1.全表扫描
优化
###在很多个页中查找
分为两个步骤：
1.定位到记录所在的页
2.从所在的页内中查找相应的记录
由于我们并不能快速的定位到记录所在的页，所以只能从第一个页沿着双向链表一直往下找，在每一个页中根据我们刚刚介绍过的查找方式去查找指定的记录,当然这种方法是非常耗时的
一个简单的索引方案
InnoDB中的索引方案
所以InnoDB复用了之前存储用户记录的数据页来存储目录项，为了和用户记录做一下区分，我们把这些用来表示目录项的记录称为目录项记录。
InnoDB就是通过记录头信息中的record_type来进行区分一条普通的记录是普通用户记录还是目录项记录
当为这些存储目录项记录的页再生成一个更高级的目录，就像是一个多级目录一样，大目录里嵌套小目录，小目录里才是实际的数据，随着表中记录的增加，这个目录的层级会继续增加，如果简化一下，那么我们可以用下面这个图来描述它：
一般情况下，我们用到的B+树都不会超过4层，那我们通过主键值去查找某条记录最多只需要做4个页面内的查找（查找3个目录项页和一个用户记录页），又因为在每个页面内有所谓的Page Directory（页目录），所以在页面内也可以通过二分法实现快速定位记录
我们上面介绍的B+树本身就是一个目录，或者说本身就是一个索引。它有两个特点：
1.使用记录主键值的大小进行记录和页的排序，这包括三个方面的含义：
2.B+树的叶子节点存储的是完整的用户记录。
具有以上两种特性的B+树称为聚簇索引，所有完整的用户记录都存放在这个聚簇索引的叶子节点处。这种索引不需要通过使用INDEX语句去创建。
上面介绍的聚簇索引只能在搜索条件是主键值时才能发挥作用，因为B+树中的数据都是按照主键进行排序的。如果想以别的列作为搜索条件，可以多建立几棵B+树
在查找数据的过程中，查找完二级索引后只能获得主键值，仍然需要到聚簇索引中再查一遍，这个过程称为回表
我们页可以同时以多个列的大小作为排序规则，也就是同时为多个列建立索引，联合索引的本质上也是一个二级索引。
将索引和数据分开存储
我们可以在创建表的时候指定需要建立索引的单个列或者建立联合索引的多个列：
1 | CREATE TALBE 表名 ( |
1 | ALTER TABLE 表名 ADD [INDEX|KEY] 索引名 (需要被索引的单个列或多个列); |
每当我们插入一条记录，都会从Free Space部分，也就是尚未使用的存储空间中申请一个记录大小的空间划分到User Records部分，当Free Space部分的空间全部被User Records部分替代掉之后，也就意味着这个页使用完了，如果还有新的记录插入的话，就需要去申请新的页了
为了更好的管理在User Records中的这些记录，行格式中的记录头信息至关重要，以下为compact行格式中的记录头信息
1.将所有正常的记录（包括最大和最小记录，不包括标记为已删除的记录）划分为几个组。
2.每个组的最后一条记录（也就是组内最大的那条记录）的头信息中的n_owned属性表示该记录拥有多少条记录，也就是该组内共有几条记录。
3.将每个组的最后一条记录的地址偏移量单独提取出来按顺序存储到靠近页的尾部的地方，这个地方就是所谓的Page Directory，也就是页目录（此时应该返回头看看页面各个部分的图）。页面目录中的这些地址偏移量被称为槽（英文名：Slot），所以这个页面目录就是由槽组成的。
对于最小记录所在的分组只能有 1 条记录，最大记录所在的分组拥有的记录条数只能在 1
8 条之间，剩下的分组中记录的条数范围只能在是 48 条之间。所以分组是按照下面的步骤进行的：
在一个数据页中查找指定主键值的记录的过程分为两步：
1.通过二分法确定该记录所在的槽，并找到该槽中主键值最小的那条记录。
2.通过记录的next_record属性遍历该槽所在的组中的各个记录。
InnoDB会把数据存储到磁盘上，操作数据时，需要以页为单位将数据移动到内存中，如果该页中的数据在内存中被修改了，那么在修改后的某个时间需要把数据同步到磁盘中。但是在同步了一半的时候中断电了咋办?
这个部分是和File Header中的校验和相对应的。每当一个页面在内存中修改了，在同步之前就要把它的校验和算出来，因为File Header在页面的前面，所以校验和会被首先同步到磁盘，当完全写完时，校验和也会被写到页的尾部，如果完全同步成功，则页的首部和尾部的校验和应该是一致的。如果写了一半儿断电了，那么在File Header中的校验和就代表着已经修改过的页，而在File Trialer中的校验和代表着原先的页，二者不同则意味着同步中间出了错。
这个部分也是为了校验页的完整性的，只不过我们目前还没说LSN是个什么意思，所以大家可以先不用管这个属性。这个File Trailer与File Header类似，都是所有类型的页通用的。
InnoDB是一个将表中的数据存储到磁盘上的存储引擎。由于磁盘IO和内存IO速度差了几个量级，InnoDB采取的方式是：将数据划分为若干个页，以页作为磁盘和内存之间的交互的基本单位，InnoDB中页的大小一般为16KB。
我们平时是以记录为单位来向表中插入数据的，这些记录在磁盘上的存放方式也被称为行格式或者记录格式
1 | CREATE TABLE 表名 (列的信息) ROW_FORMAT=行格式名称 |
一条完整的记录其实可以被分为记录的额外信息和记录的真实数据两大部分。
记录的额外信息：服务器为了描述这条记录而不得不添加的一些信息，分为3类，变长字段长度列表、NULL值列表、记录头信息
1.变长字段长度列表：MySQL支持一些变长的数据类型，比如VARCHAR(M)、VARBINARY(M)、各种TEXT类型，各种BLOB类型，这些变长字段占用的存储空间分为两部分（真正的数据内容和占用的字节数），对于CHAR(M）类型的列来说，当列采用的是定长字符集时，该列占用的字节数不会被加到变长字段长度列表，而如果采用变长字符集时，该列占用的字节数也会被加到变长字段长度列表
在COMPACT行格式中，把所有的变长字段的真实数据占用的字节长度都存放在记录的开头部位，从而形成一个变长字段长度列表，按逆序排放
2.NULL值列表：处理过程是这样的，先统计表中哪些列允许存储NULL值(主键列、被NOT NULL修饰的列都是不可以存储NULL值的)，所以在统计的时候不会把这些列算进去，接着如果有的列可以存储NULL值，那么就需要NULL值列表，将每个允许存储NULL的列对应一个二进制位（为1代表该列值为NULL，为0代表不为NULL），其次MySQL规定NULL值列表必须用整数个字节的位表示，如果使用的二进制位个数不是整数个字节，则在字节的高位补0
3.记录头信息：它是由固定的5个字节组成，不同位代表不同意思
记录的真实数据
MySQL会为每个记录默认的添加一些列（也称为隐藏列），具体的列如下：
InnoDB表对主键的生成策略:优先使用用户自定义主键作为主键，如果用户没有定义主键，则选取一个Unique键作为主键，如果表中连Unique键都没有定义的化，则InnoDB会为表默认添加一个名为row_id的隐藏列作为主键
记录的额外信息
1.字段长度偏移列表：与compact行格式相比，没有了变长两个字，多了偏移两个字，Redundant的行格式会把该条记录中所有（包括隐藏列）的长度信息都按照逆序存储到字段长度偏移列表。同时Redundant的行格式是按照两个相邻数值的差值来计算各个列值的长度。
记录头信息
对于Compact和Reduntant行格式来说，如果某一列中的数据非常多的话，在本记录的真实数据处只会存储该列的前768个字节的数据和一个指向其它页的地址，然后把剩下的数据存放到其它页中，这个过程叫做行溢出，存储超出768字节的那些页也被称为溢出页
总共128个字符，包括一些不可见字符
共收录256个字符，是在ASCII字符集的基础上又扩充了128个西欧常用字符（包括德法两国的字母），也可以使用1个字节来进行编码。
收录了汉字以及拉丁字母，希腊字母 收录了汉字以及拉丁字母、希腊字母、日文平假名及片假名字母、俄语西里尔字母。其中收录汉字6763个，其他文字符号682个。同时这种字符集又兼容ASCII字符集，所以在编码方式上显得有些奇怪：
1.如果该字符在ASCII字符集中，则采用1字节编码
2.否则采用2字节编码
GBK字符集只是在收录字符范围上对GB2312字符集作了扩充，编码方式上兼容GB2312
收录地球上能想到的所有字符，而且还在不断扩充。这种字符集兼容ASCII字符集，采用变长编码方式，编码一个字符需要使用1～4个字节
其实准确的说，utf8只是Unicode字符集的一种编码方案，Unicode字符集可以采用utf8、utf16、utf32这几种编码方案，utf8使用1～4个字节编码一个字符，utf16使用2个或4个字节编码一个字符，utf32使用4个字节编码一个字符。更详细的Unicode和其编码方案的知识不是本书的重点，大家上网查查。MySQL中并不区分字符集和编码方案的概念，所以后边介绍的时候把utf8、utf16、utf32都当作一种字符集对待。
1 | SHOW (CHARACTER SET|CHARSET) [LIKE 匹配的模式]; |
1 | SHOW COLLATION [LIKE 匹配的模式]; |
服务器级别
MySQL提供了两个系统变量来表示服务器级别的字符集和比较规则:
服务器级别默认的字符集是utf8，默认的比较规则是utf8_general_ci
可以用以下命令查看：
1 | SHOW VARIABLES LIKE [匹配模式] |
数据库级别
我们在创建和修改数据库的时候可以指定该数据库的字符集和比较规则
1 | CREATE DATABASE 数据库名 |
如果想查看当前数据库使用的字符集和比较规则，可以查看下面两个系统变量的值（前提是使用USE语句选择当前默认数据库，如果没有默认数据库，则变量与相应的服务器级系统变量具有相同的值）：
表级别
我们也可以在创建和修改表的时候指定表的字符集和比较规则，语法如下：
1 | CREATE TABLE 表名 (列的信息) |
列级别
需要注意的是，对于存储字符串的列，同一个表中的不同的列也可以有不同的字符集和比较规则。我们在创建和修改列定义的时候可以指定该列的字符集和比较规则，语法如下：
1 | CREATE TABLE 表名( |
对于某个列来说，如果在创建和修改的语句中没有指明字符集和比较规则，将使用该列所在表的字符集和比较规则作为该列的字符集和比较规则。
小贴士：在转换列的字符集时需要注意，如果转换前列中存储的数据不能用转换后的字符集进行表示，就会发生错误。比方说原先列使用的字符集是utf8，列中存储了一些汉字，现在把列的字符集转换为ascii的话就会出错，因为ascii字符集并不能表示汉字字符。
我们知道从客户端发往服务器的请求本质上就是一个字符串，服务器向客户端返回的结果本质上也是一个字符串，而字符串其实是使用某种字符集编码的二进制数据。
为了让我们更好的了解服务器程序的运行情况，MySQL服务器程序中维护了很多关于程序运行状态的变量，它们被称为状态变量。比方说Threads_connected表示当前有多少客户端与服务器建立了连接，Handler_update表示已经更新了多少行记录等，像这样显示服务器程序状态信息的状态变量还有好几百个，我们就不一一介绍了，等遇到了会详细说它们的作用的。
由于状态变量是用来显示服务器程序运行状况的，所以它们的值只能由服务器程序自己来设置，我们程序员是不能设置的。与系统变量类似，状态变量也有GLOBAL和SESSION两个作用范围的，所以查看状态变量的语句可以这么写：
1 | SHOW [GLOBAL|SESSION] STATUS [LIKE 匹配的模式]; |
MySQL服务器程序运行过程中会用到许多影响程序行为的变量，它们被称为MySQL系统变量，比如允许同时连入的客户端数量用系统变量max_connections表示，表的默认存储引擎用系统变量default_storage_engine表示，查询缓存的大小用系统变量query_cache_size表示，MySQL服务器程序的系统变量有好几百条，我们就不一一列举了。
我们可以使用下列命令查看MySQL服务器程序支持的系统变量以及它们的当前值：
1 | SHOW VARIABLES [LIKE 匹配的模式]; |
1.通过命令行添加启动选项。
2.通过配置文件添加启动选项
我们前面说过，多个客户端程序可以同时连接到一个服务器程序。对于同一个系统变量，我们有时想让不同的客户端有不同的值。比方说狗哥使用客户端A，他想让当前客户端对应的默认存储引擎为InnoDB，所以他可以把系统变量default_storage_engine的值设置为InnoDB；猫爷使用客户端B，他想让当前客户端对应的默认存储引擎为MyISAM，所以他可以把系统变量default_storage_engine的值设置为MyISAM。这样可以使狗哥和猫爷的的客户端拥有不同的默认存储引擎，使用时互不影响，十分方便。但是这样各个客户端都私有一份系统变量会产生这么两个问题：
为了解决这两个问题，设计MySQL的大佬提出了系统变量的作用范围的概念，具体来说作用范围分为这两种,GLOBAL（全局变量，影响服务器整体操作）和SESSION（会话变量，影响某个客户端连接的操作，别名LOCAL）通过启动选项设置的系统变量的作用范围都是GLOBAL的，也就是对所有客户端都有效的
在服务器程序运行期间通过客户端程序设置系统变量的语法：
1 | SET [GLOBAL|SESSION] 系统变量名 = 值; |
1 | SHOW [GLOBAL|SESSION] VARIABLES [LIKE 匹配的模式]; |
小贴士：如果某个客户端改变了某个系统变量在GLOBAL作用范围的值，并不会影响该系统变量在当前已经连接的客户端作用范围为SESSION的值，只会影响后续连入的客户端在作用范围为SESSION的值。
并不是所有系统变量都具有GLOBAL和SESSION的作用范围。
有一些系统变量只具有GLOBAL作用范围，比方说max_connections，表示服务器程序支持同时最多有多少个客户端程序进行连接。
有一些系统变量只具有SESSION作用范围，比如insert_id，表示在对某个包含AUTO_INCREMENT列的表进行插入时，该列初始的值。
有一些系统变量的值既具有GLOBAL作用范围，也具有SESSION作用范围，比如我们前面用到的default_storage_engine，而且其实大部分的系统变量都是这样的，
有些系统变量是只读的，并不能设置值。
比方说version，表示当前MySQL的版本，我们客户端是不能设置它的值的，只能在SHOW VARIABLES语句里查看。
在MySQL安装目录下的bin目录中的各种可执行文件，不论是服务器相关的程序（比如mysqld、mysqld_safe）还是客户端相关的程序（比如mysql、mysqladmin），在启动的时候基本都可以指定启动参数。这些启动参数可以放在命令行中指定，也可以把它们放在配置文件中指定。
1 | mysqld --skip-networking 禁止客户端使用TCP/IP网络进行通信 |
1 | mysql -h -u -p 客户端 |
MySQL程序在启动时会寻找多个路径下的配置文件，这些路径有的是固定的，有的是可以在命令行指定的。根据操作系统的不同，配置文件的路径也有所不同。
%WINDIR%是机器上的Windows目录，通常是C:\WINDOWS，可以使用echo %WINDIR%查看
BASEDIR指的是MySQL安装目录
第四个路径指的是我们在启动程序时可以通过指定default-extra-file参数来额外配置文件路径
1 | mysqld --defaults-extra-file=C:\Users\xiaohaizi\my_extra_file.txt |
[server]
(具体的启动选项…)
[mysqld]
(具体的启动选项…)
[mysqld_safe]
(具体的启动选项…)
[client]
(具体的启动选项…)
[mysql]
(具体的启动选项…)
[mysqladmin]
(具体的启动选项…)
不同的启动命令读取配置文件的不同的组
如果我们在多个配置文件中设置了相同的启动选项，那以最后一个配置文件中的为准
比如mysqld命令启动服务端程序，可以访问配置文件中的[mysqld]、[server]等，那么将以最后一个出现的组中的启动选项为准
如果我们不想让MySQL到默认的路径下搜索配置文件（就是上表中列出的那些），可以在命令行指定defaults-file选项，比如这样（以UNIX系统为例）：
1 | mysqld --defaults-file=/tmp/myconfig.txt |
如果同一个启动选项既出现在配置文件中，又出现在命令行中，以命令行为准