1. 插入缓冲
2. 两次写
3. 自适应哈希索引
4. 异步 io
5. 刷新邻近页
mysql 文件介绍
日志文件
1.error.log 谬误日志:
mysql> show variables like "log_error";
+---------------+---------------------------------------------+
| Variable_name | Value |
+---------------+---------------------------------------------+
| log_error | /Users/itech8/data/apps/logs/mysql/error.log |
+---------------+---------------------------------------------+
1 row in set (0.01 sec)
2. 慢查问日志, 默认慢查问日志工夫设置的是 10 秒
mysql> show variables like "long_query_time";
+-----------------+-----------+
| Variable_name | Value |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
1 row in set (0.01 sec)
慢查问日志文件地位:
mysql> show variables like "slow_query_log%";
+---------------------+------------------------------------------------------------------+
| Variable_name | Value |
+---------------------+------------------------------------------------------------------+
| slow_query_log | OFF |
| slow_query_log_file | /Users/itech8/data/apps/appdata/mysql/itech8deMacBook-Air-slow.log |
+---------------------+------------------------------------------------------------------+
2 rows in set (0.00 sec)
慢查问日志剖析
mysqldumpslow Users/itech8/data/apps/appdata/mysql/itech8eMacBook-Air-slow.log
获取执行工夫最长的 10 条记录
mysqldumpslow -s -al -n 10 Users/itech8data/apps/appdata/mysql/itech8eMacBook-Air-slow.log
也能够将慢查问日志放到 table 中, 默认文件中
SET Global log_output='TABLE'
3. 全局查问日志
mysql> show variables like "general_log%";
+------------------+-------------------------------------------------------------+
| Variable_name | Value |
+------------------+-------------------------------------------------------------+
| general_log | OFF |
| general_log_file | /Users/itech8/data/apps/appdata/mysql/itech8deMacBook-Air.log |
+------------------+-------------------------------------------------------------+
2 rows in set (0.00 sec)
开启全局日志
mysql> set global general_log=on;
Query OK, 0 rows affected (0.00 sec)
4. 二进制日志
/etc/my.conf 下增加
log-bin=mysql-bin-log
binlog_format=mixed
max_bin_size: 记录单个二进制文件的最大值:mysql-bin-log.00001 内容超过 max_bin_size 设置的最大值, 产生一个新的二进制文件, 后缀 +1
binlog_cache_size: 事务未提交, 所有未提交的二进制日志会被记录到一个缓存中, 等该事务提交时间接将缓冲的二进制日志写入二进制文件中
用途: 复制 - 故障复原 -sql 审计
sync_binlog=[n]示意每写缓冲多少次就同步到磁盘,sync_binlog= 1 示意同步磁盘的形式来实时写二进制文件, 不必操作系统的缓冲, 默认值是 0
innodb_support_xa
binlog_format
streamant、raw、mixed
pid 文件
mysql 启动实例的时候会将本人的过程 id 写入文件
mysql> show variables like "pid_file";
+---------------+-------------------------------------------------------------------+
| Variable_name | Value |
+---------------+-------------------------------------------------------------------+
| pid_file | /Users/itech8/data/apps/appdata/mysql/itech8deMacBook-Air.local.pid |
+---------------+-------------------------------------------------------------------+
1 row in set (0.00 sec)
套接字 socket 文件地位
mysql> show variables like "socket";
+---------------+-----------------+
| Variable_name | Value |
+---------------+-----------------+
| socket | /tmp/mysql.sock |
+---------------+-----------------+
1 row in set (0.00 sec)
表构造和 innodb 存储引擎文件
.frm
innodb 的表空间文件
默认配置下会有一个初始大小 10mb 的 ibdata1 文件, 能够用多个文件组成一个表空间, 例如:ibdata1 和 ibdata2 组成一个表空间, 假如两个文件在不同磁盘上, 磁盘负载被均匀
因而能够进步数据库整体性能
若 innodb_data_file_path: 所有的表数据都会记录到该共享表空间中
若 innodb_file_per_table: 每个表都会产生一个独立的表空间, 表名:.ibd, 单个表默认大小是 96kb, 这些独自的表空间, 仅存储该表的数据, 索引, 和插入缓冲 Bitmap 信息, 其余信息还是放在默认共享表空间中
innodb 的重做日志文件
默认状况下,innodb 存储引擎数据目录下都会有这两个文件 ib_logfile0 和 ib_logfile1, 这是 innodb 引擎的重做日志文件(redo log file)
每次存储引擎下至多有 1 个重做日志文件组, 每个组下卖弄至多有 2 个重做日志文件, 如默认的 ib_logfile0 和 ib_logfile1, 能够将不同的文件组放在不同的磁盘上, 进步重做日志的高可用性,
redo log file 和回滚日志文件 undo log file
表
1. 索引组织表
如果创立表时候没有显示定义表主键, 那么 innodb 会依据以下形式抉择或者创立主键
a. 首先判断表中是否有非空的惟一索引（union not null）如果有, 则该列为主键, 当表中有多个非空惟一索引时候,innodb 会抉择建表时候第一个定义的非空惟一索引为主键, 留神, 主键的抉择依据的是定义索引的程序, 而不是建表时候列的程序
CREATE TABLE `z` (`a` int(11) NOT NULL,
`b` int(11) DEFAULT NULL,
`c` int(11) NOT NULL,
`d` int(11) NOT NULL,
UNIQUE KEY `b` (`b`),
UNIQUE KEY `d` (`d`),
UNIQUE KEY `c` (`c`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO `z` (`a`, `b`, `c`, `d`)
VALUES
(1, 1, 1, 1),
(2, 2, 2, 2);
能够看到主键是 d 列
mysql> select _rowid,a,b,c,d from z;
+--------+---+------+---+---+
| _rowid | a | b | c | d |
+--------+---+------+---+---+
| 2 | 2 | 3 | 2 | 2 |
| 4 | 1 | 2 | 3 | 4 |
+--------+---+------+---+---+
2 rows in set (0.00 sec)
b. 如果不合乎上述条件,innodb 会主动创立一个 6 字节大小的指针
innodb 逻辑存储构造
tablespce 表空间又段, 区, 页组成
段: 索引段 -B+tree 的非叶子节点, 数据段:B+tree 的叶子节点, 回滚段
区: 间断页组成的空间, 任何状况下, 每个区的大小都为 1MB, 为保障去的连续性,innodb 一次从磁盘申请 4 - 5 个区, 默认 innodb 存储的引擎页大小是 16kb, 即一个区一共 16 个间断的页
页: 是 innodb 磁盘治理最小的单位, 默认每个页的大小是 16kb, 也能够通过参数 innodb_page_size 设置每页的大小是 4k,8k,16k
常见的数据页类型: 数据页,undo 页, 零碎页, 事务数据页等等
行：innodb 是按行存放数据的, 每页寄存的行记录最多容许寄存 16kb/2-200 行记录, 即 7992 行
索引和算法
B+tree 索引不能找到一个给定键值的具体行,B+tree 树索引能找到的常识被查找数据行所在的页, 而后数据库通过把页读入内存中, 再在内存中查找，失去要查找的数据
1,2,3,4,5,6,7,8,9,10
1.tinyint 和 Enum
2. 索引和算法
二叉查找树 -> 均衡二叉树 ->Btree->B+tree
二叉查找树: 左子树的键值总是小于根的键值, 右子树的键值总是大于根的键值
2-3-6-7-8
6
/ \
3 7
/ \ \
2 5 8
插入新值 9, 为了保持平衡, 须要旋转一次, 有时候须要旋转屡次, 因而保护一颗均衡二叉树须要开销的
6
/ \
3 7
/ \ / \
2 5 8 9
查找 8 先找到根节点 6 ,6 小于 8, 因而查找右子树, 须要查找 3 次, 程序查找的话则须要 6 次
定义: 均衡二叉树 (AVL) 查找效率高, 满足二叉树的定义外, 而且任意节点的两个子树高度最大差为 1
B+tree
所有数据寄存在叶子节点上, 并且是程序寄存的, 如果用户从右边的叶子节点是程序遍历, 能够失去所有键值的程序排序, 叶子节点之间是个双向链表指针
B+tree 索引分为聚簇索引和辅助索引, 其外部都是 B +tree, 高度均衡的, 叶子节点存放数据,B+tree 索引, 外部其实是 B +tree 在 mysql 中的实现
B+tree 在数据库中是高扇出性, 个别在 DB 中 B + 树的高度在 2 - 3 层左右。也就意味着只须要 2 - 3 次的 IO 操作即可。而当初的磁盘每秒差不多在 100 次 IO 左右，2- 3 次意味着查问工夫只需 0.02-0.03 秒。汇集索引,
InnoDB 存储引擎表是索引组织表，即表中数据装置主键程序寄存。而汇集索引就是依照每张表的主键结构一颗 B +, 并且叶节点寄存着整张表的行记录数据，因而也将汇集索引的叶子节点称为数据页。聚簇索引的这个个性也决定了索引组织表中的数据也是索引的一部分, 同 B
理论的数据页只能依照一颗 B + 树进行排序，因而每张表只能领有一个汇集索引。在很多状况下, 查问优化器十分偏向于采纳汇集索引, 因为汇集索引可能让咱们在索引的叶节点上间接找到数据。数据库索引为啥不必 b 树:
因为 B 树不论叶子节点还是非叶子节点, 都会保留数据, 这样导致在非叶子节点中能保留的指针数量变少（有些材料也称为扇出）指针少的状况下要保留大量数据, 只能减少树的高度, 导致 IO 操作变多, 查问性能变低;
什么时候应用 B + 树索引
个别的教训是对于拜访表中很少一部分行时，应用 B + 树索引才有意义。而对于像性别，地区，类型等字段，它们可取值的范畴很小（低选择性），个别不举荐应用 B + 树索引；【此时个别用什么索引呢？】反之，如果某个字段的取值范畴很广，简直没有反复（高选择性），则此时应用 B + 树索引是最合适的，例如 email 字段，在一些利用中通常都不容许反复呈现。因而，当拜访高选择性字段并从表中取出很少一部分行时，对这个字段增加 B + 树索引是十分有必要的。然而如果呈现了拜访字段是高选择性，然而取出的行数据占表中大部分的数据时，这时 MySQL 数据库就不会应用 B + 树索引了。联结索引: 对表上的多个列进行索引
笼罩索引:
从辅助索引中就能够失去查问的记录, 而不须要查问聚簇索引中的记录, 应用笼罩索引的益处是辅助索引不蕴含整行记录的所有信息, 所以其大小要小于笼罩索引, 因而能够大量缩小 IO 操作
参考资料:
1.MySQL 索引背地的数据结构及算法原理
http://blog.codinglabs.org/articles/theory-of-mysql-index.html