《MySQL技术内幕：InnoDB存储引擎》读书笔记.

1、MySQL 体系架构和存储引擎

一、MySQL 被设计成一个单进程多线程架构的数据库，MySQL 数据库实例在系统上的表现就是一个进程。

二、MySQL 的体系架构，须要特别注意的是，存储引擎是基于表的，而不是数据库。

三、InnoDB 存储引擎是面向在线事务处理（OLTP）应用的首选，其特色是：支持事务、支持外键、聚簇索引、行锁设计、基于 MVCC 来得到高并发性，使用一种被称为 next-keylocking 的策略来避免幻读，还提供了插入缓冲（insert buffer）、二次写（double write）、自适应哈希索引（adaptive hash index）、预读（read ahead）等高性能和高可用的功能。InnoDB 存储引擎在 1.2 版本中新增了全文索引等内容。

MyISAM 存储引擎不支持事务、表锁设计、支持全文索引，主要是面向一些在线分析处理（OLAP）数据库应用。MyISAM 存储引擎表由 MYD 和 MYI 组成，MYD 用来存放数据文件，MYI 用来存放索引文件。MyISAM 存储引擎的另外一个不同凡响的地方是它的缓冲池只缓存索引文件，而不缓存数据文件，这点和大多数的数据库都很是不一样。

Memory 存储引擎不支持事务、表锁设计、支持哈希索引、并发性能较差，而且不支持 TEXT 和 BLOB 列类型。Memory 存储引擎将表中的数据存放在内存中，若是数据库重启或者崩溃，表中的数据都将消失，它很是适合用于存储临时数据的临时表，以及数据仓库中的纬度表。Memory 存储引擎默认使用哈希索引，而不是咱们熟悉的 B+ 树索引。

2、文件

一、查看 MySQL 的参数配置

SHOW VARIABLES

二、错误日志（error log）文件对 MySQL 的启动、运行、关闭过程当中进行了记录。

SHOW VARIABLES LIKE 'log_error'

慢查询日志（slow log）文件记录了可能存在问题的 SQL 语句，可根据慢查询日志进行 SQL 语句层面的优化。

# 记录没有使用索引的 SQL 语句
SHOW VARIABLES LIKE 'log_queries_not_using_indexes';
# 容许记录到 slow log 且未使用索引的 SQL 语句次数
SHOW VARIABLES LIKE 'log_throttle_queries_not_using_indexes'
# 大于该时间的 SQL 语句都会被记录下来
SHOW VARIABLES LIKE 'long_query_time';
# 指定慢查询输出的格式（FILE/TABLE）
SHOW VARIABLES LIKE 'log_output';

二进制日志（binary log）记录了对 MySQL 数据库执行更改的全部操做，可是不包括 SELECT 和 SHOW 这类操做，由于这类操做对数据自己并无修改。二进制日志在数据库恢复、主从复制、审计等场景中获得了普遍的应用。

要查看二进制日志文件的内容，必须经过 MySQL 提供的工具 mysqlbinlog。

# 单个二进制文件的最大值
SHOW VARIABLES LIKE 'max_binlog_size';
# 二进制日志缓冲，基于会话，全部未提交的二进制日志都会被缓冲
SHOW VARIABLES LIKE 'binlog_cache_size';
# 二进制日志文件记录缓冲与记录临时文件的次数
SHOW GLOBAL STATUS LIKE 'binlog_cache%';
# 表示每写缓冲多少次就同步到磁盘，该参数的有效值为0 、一、N；
# 0：默认值，事务提交后，将 binlog 日志写入操做系统缓存，不当即刷新到磁盘；
# 1：事务提交后，将 binlog 日志写入操做系统缓存并当即刷新到磁盘，即同步写磁盘；
# N：每写 N 次操做系统缓存就执行一次刷新操做；
SHOW VARIABLES LIKE 'sync_binlog'
# slave 角色配置，从 master 取得 bin_log 日志写入到本身的二进制日志文件中
SHOW VARIABLES LIKE 'log_slave_updates%'
# 动态参数，记录二进制日志文件的格式，STATEMENT/ROW/MIXED，一般设置为 ROW
SHOW VARIABLES LIKE 'binlog_format'

３、由于 MySQL 插件式存储引擎体系结构的关系，MySQL 数据的存储是根据表进行的，每一个表都会有与之对应的文件，但不论表采用何种存储引擎，MySQL 都有一个以 frm 为后缀名的文件，这个文件记录了该表的表结构定义。

四、InnoDB 采用了将存储的数据按表空间（tablespace）进行存放的设计，innodb_data_file_path 参数用来设置默认的表空间，全部基于 InnoDB 存储引擎的表数据都会记录到默认的表空间中，若设置了参数 innoDB_file_per_table，每一个基于 InnoDB 存储的表都将产生一个独立的表空间，命名规则为：表名.ibd，独立的表空间仅存储该表的数据、索引和插入缓冲 BITMAP 等信息，其他信息（如回滚（undo）信息、插入缓冲索引页、系统事务信息、二次写缓冲（doublewrite buffer）等）仍是存放在默认的表空间中。

SHOW VARIABLES LIKE 'innodb_data_file_path';
SHOW VARIABLES LIKE 'innodb_file_per_table';

五、InnoDB 重作（REDO）日志文件对于 InnoDB 存储引擎相当重要，它们记录了 InnoDB 存储引擎的事务日志，记录了关于每一个页（Page）的更改的物理状况。重作日志文件跟 binlog 日志文件不一样，binlog 日志记录了全部与 MySQL 数据库有关的日志记录，包括 InnoDB、MyISAM、Heap 等其余存储引擎的日志。

六、redo log 称为重作日志，恢复提交事务修改的页操做，用来保证事务的原子性和持久性；undo log 称为回滚日志，帮助回滚行记录到某个特定版本及 MVCC 的功能，用来保证事务的一致性。

3、表

一、表是关于特定实体得数据集合，这也是关系型数据库模型的核心。

二、在 InnoDB 存储引擎中，表都是根据主键顺序组织存放的，这种存储方式的表称为索引组织表（index organized table），能够参考 聚簇索引。所以，InnoDB 存储引擎表老是 B+ 树索引组织的。

三、从 InnoDB 存储引擎的逻辑存储结构看，全部数据都被逻辑地存放在一个空间中，称之为表空间（tablespace）。表空间又由段（segment）、区（extent）、页（page）组成。

常见的段有数据段、索引段、回滚段等。数据段即为 B+ 树的叶子节点，索引段即为 B+ 树的非索引节点；

区是由连续页组成的空间，在任何状况下每一个区的大小都为 1MB。

页是 InnoDB 磁盘管理的最小单位，默认每一个页的大小是 16K，能够经过参数 innodb_page_size 设置。而后每一个页两行数据，因此每行最大 8K 数据。

四、InnoDB 存储引擎和大多数数据库同样，记录是以行的形式存储的，InnoDB 存储引擎提供了 Antelope（Compact、Redundant）、Barracuda（Dynamic、Compressed、FIXED）等格式 来存放行记录数据，能够经过命令 SHOW TABLE STATUS LIKE 'table_name' 来查看当前表使用的行格式。

SHOW GLOBAL VARIABLES LIKE '%FILE_FORMAT%';
SHOW TABLE STATUS LIKE 'table_name';
ALTER TABLE `table_name` ROW_FORMAT = FIXED;

Antelope 存储格式会把每一个字段的前 864 个字节存储在 PAGE 里，因此你的字段超过必定数量的话，单行大小就会超过 8K。

Barracuda 存储格式对字段的处理方式是在 PAGE 里头存储一个 20byte 大小的指针，其它全存在溢出区，因此轻易超不了 8K。

Compressed 行记录格式的另外一个功能就是，存储在其中的行数据会以 zlib 的算法进行压缩，所以对于 BLOB、TEXT、VARCHAR 这类大长度类型的数据能进行很是有效的存储。

若一张表里面不存在varchar、text以及其变形、blob以及其变形的字段的话，那么张这个表其实也叫静态表，即该表的 row_format 是 fixed，就是说每条记录所占用的字节同样。其优势读取快，缺点浪费额外一部分空间。

若一张表里面存在varchar、text以及其变形、blob以及其变形的字段的话，那么张这个表其实也叫动态表，即该表的 row_format 是 dynamic，就是说每条记录所占用的字节是动态的。其优势节省空间，缺点增长读取的时间开销。

五、关系型数据库系统和文件系统的一个不一样点是，文件系统通常须要在程序端进行控制以保证存储数据的完整性，而关系数据库自己能保证存储数据的完整性，不须要应用程序的控制，好比主键约束、惟一键约束、外键约束等等（惟一索引是能够容许有 NULL 值的）。

六、在某些设置下，MySQL 数据库容许非法的或不正确的数据插入或更新，如向 EUNM 约束中插入一个非法值，又或者能够在数据库内部将其转化为一个合法的值，如向 NOT NULL 的字段插入一个 NULL 值，MYSQL 数据库会将其更改成 0 再进行插入，所以数据库自己没有对数据的正确性进行约束，只会获得一个 WARNINGS 提示，经过设置参数 sql_mode 的值为 STRICT_TRANS_TABLES 对于输入值的合法性进行约束。

SHOW GLOBAL VARIABLES LIKE 'sql_mode'

七、视图的主要用途之一是被用做一个抽象装置。特别是对于一些应用程序，程序自己不须要关心基表的结构，只须要按照视图定义来取数据或更新数据，所以，视图同时在必定程度上起到一个安全层的做用。

# 查看基表
SELECT * FROM information_schema.TABLES WHERE table_type ='BASE TABLE' AND table_schema = database();
# 查看视图
SELECT * FROM information_schema.VIEWS WHERE table_schema = database();

八、视图是基于基表的一个虚拟表，基于视图的更新操做，其本质都是经过视图的定义来更新基本表。

4、备份和恢复

一、能够根据备份的方法不一样将备份分为：

• Hot Backup（热备）：数据库运行中直接备份，对正在运行的数据库操做没有任何的影响；
• Cold Backup（冷备）：数据库中止的状况下复制，通常只须要复制相关的数据库物理文件（.frm、.ibd 等）便可；
• Warm Backup（温备）：数据库运行中进行，会对当前数据库的操做有所影响，如加一个全局读锁以保证备份数据的一致性；

二、能够根据备份后文件的内容不一样将备份分为：

• 逻辑备份：通常是文本文件，内容可读，内容通常由一条条 SQL 语句构成，可使用 mysqldump 工具完成；
• 裸文件备份：复制数据库的物理文件，既能够是在数据库运行中的复制（如 ibbackup、xtrabackup 这类工具），也能够是在数据库中止运行时直接的数据文件复制；

三、MySQL 数据库自己提供的工具并不支持真正的增量备份，借助 xtrabackup 工具能够完成 InnoDB 存储引擎的增量备份；

四、复制（replication）是 MySQL 数据库提供的一种高可用性能的解决方案，通常用来创建大型的应用。整体来讲，replication 的工做原理分为如下三个步骤：

1）主服务器（master）把数据更改记录到二进制日志（binlog）中；
2）从服务器（slave）把主服务器的二进制日志复制到本身的中继日志（relay log）中；
3）从服务器重作中继日志中的日志，把更改应用到本身的数据库上，以达到数据的最终一致性；（从服务器有 2 个线程，一个是 I/O 线程，负责读取主服务器的二进制日志，并将其保存为中继日志；另外一个是 SQL 线程，负责执行中继日志）

# 查看主服务器中二进制日志的状态
SHOW MASTER STATUS;
# 查看从服务器中二进制日志的状态（主从服务器上 binlog 日志的偏移量，就能够得知 I/O 线程的延迟）
SHOW SLAVE STATUS;

5、其它

一、OLAP 的应用适用 CPU 密集型的数据库；OLTP 的应用适用于 IO 密集型的数据库；

# 检查当前数据库的运行状态，显示有哪些线程在运行
SHOW FULL PROCESSLIST;

二、内存的大小是最能直接反映数据库的性能，所以，应该在开发应用前预估“活跃”数据库的大小是多少，并以此肯定数据库服务器内存的大小。能够经过查看当前服务器的状态，比较物理磁盘的读取和内存读取的比例来判断缓存池的命中率，一般 InnoDB 存储引擎的缓存池的命中率不该该小于 99%；

SHOW GLOBAL STATUS LIKE 'innodb%read%';

三、RAID（Redundant Array of Independent Disks，独立磁盘冗余数组）的基本思想就是把多个相对便宜的硬盘组合起来，成为一个磁盘数组，使性能达到甚至超过一个价格昂贵、容量巨大的硬盘；

四、sysbench 是一个模块化的、跨平台的多线程基准测试工具，主要用于测试各类不一样系统参数下的数据库负载状况；

五、TPC（Transaction Processing Performance Conuncil，事务处理性能协会）是一个用来评价大型数据库系统软硬件性能的非盈利组织。TPC-C 是 TPC 协会制定的，用来测试典型的复杂 OLTP（在线事务处理）系统的性能。tpcc-mysql 是开源的 TPC-C 测试工具，彻底遵照 TPC-C 的标准，专用于 MySQL 基准测试；