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
发表回复