Mysql07-MySQL深入学习总结
索引的本质及索引的数据结构
b树结构详细
myslam存储引擎索引
inodb存储引擎索引
mysql索引优化与底层数据结构深入
mysql主从架构原理
mvcc底层原理
一、索引的本质及索引的数据结构
1.索引是帮助MYSQL高效获取数据的排好序的数据结构
2.索引数据结构
1)为什么不是二叉树:当数据单边增长时,会退化成链表
2)为什么不是红黑树:红黑树是二叉平衡树,存大数据量时,树的高度很高
二、b树结构详细解析
1.mysql中的b+树是多叉平衡树,这样就控制了树的高度
2.b树就是b-树,b树非叶子节点存储数据,所有索引元素不重复,节点中的数据索引从左到右递增排序
3.b+树非叶子节点不存储data,只存储索引(冗余)且从左到右递增排序,叶子结点包含所有索引字段,叶子节点用指针连接,提高区间访问性能
4.b+树中查找元素,先将根节点加载到内存中做随机查找,当没有查找元素时,继续根据索引元素之间的指针定位下个节点,直到查询到叶子结点返回data
5.为什么不在第一层节点就加载完数据? => 当大数据量时,根节点被加载后会占用大量内存,现在的B+树是分批分范围的查找
6.存储计算:
mysql默认一个节点大小是16k,show global status like 'Innodb_page_size';
假设主键使用 bigint 占8byte,指针占6byte,单个非叶子节点存储索引元素和指针的个数 = 16k/(8+6)b ≈ 1170 个,叶子节点单个元素为1k时,叶子节点可以放16个元素,当树的高度为3时,即叶子节点存储了 1170×1170×16 ≈ 2000+w 个索引元素
另外,通常索引的根节点常驻内存中,索引高度为3的b+树索引,查找一个元素需要两次IO访问就可以定位到元素
7.hash索引方法,只需要一次hash运算就能定位到数据元素,与b+树相比,hash索引方法缺少了排序功能,当使用where t.age > 10进行范围查找时,hash方法明显劣势,所以一般推荐只使用b+树索引,只有在用不到范围查找的表上可以建hash索引,而对于排好序的b+树的叶子节点可以顺藤摸瓜的很好支持范围查找
三、myslam存储引擎索引
1.MyISAM表索引文件和数据文件是分离的(非聚集),叶子结点存储的data元素内容是对应行记录的磁盘文件地址
四、inodb存储引擎索引
1.Innodb索引实现(聚集)
1)表数据文件本身就是按B+树组织的一个索引结构文件
2)聚集索引-叶节点包含完整的数据记录
3)为什么Innodb表必须有主键,并且推荐使用整型的自增主键?(主键用来组织数据形成聚集索引B+树;整型便于查找中频繁的比较大小且占用空间小;自增主键,新增的元素永远插到索引树末尾,否则,b+树的叶子节点会产生分裂,且还需要重新平衡)
4)为什么非主键索引结构叶子结点存储的是主键值?(一致性和节省存储空间)
2.Innodb表的存储文件:.frm文件和.ibd文件,即 表结构文件 和 索引数据文件
五、mysql索引优化与底层数据结构深入
1.图解复合索引数据结构+最左前缀原理
六、mysql主从架构原理
1.mysql主从架构原理图
查看binlog语句 > # show binary logs;
查看当前正在写的binlog文件 > # show master status;
查看日志文件 > # show binlog events in '[上一条命令查出的Log_name]';
从机IO thread用于同步主机binlog日志到从机的中继日志relay binlog中,从机 SQL thread 用于读取中继日志并完成对从机数据的写入
主从同步的问题:一致性和延迟
一致性问题解决办法,强制在插入数据的某短时间内读主库的数据;
当主库、从库之间产生网络问题,同步异常,使用mysql的第三方插件实现半同步,即主库的数据强制写到从库的中继日志才算完成插入 => 半同步【数据同步到从库中才返回,叫全同步】,牺牲了写数据的性能
当有多个从库时,只对一个从节点进行半同步,否则从机越多,半同步效率越低
七、mvcc底层原理(可重复读实现原理)
实际是基于大量的undo日志完成,原理分析:
1.mysql数据库给每张表添加两个字段:trx_id, roll_pointer,事务ID字段和回滚指针字段
信息加载中,请等待
微信客服(速回)
微信客服(慢回)