三索引篇什么是索引此时【索引】 就是目录。主键索引就是根据主键建立的目录。索引目录的建立在建表插入数据的时候就已经存在了。为什么 MySQL InnoDB 选择 Btree 作为索引的数据结构B Tree在哪一层查到不确定查询效率不稳定二叉树 层数会很多BTree查询效率高联合索引执行这个语句会建立一个BTree的索引目录最左匹配原则最左边的必须在ABC联合索引索引 (A, B, C) 的物理存储顺序是 A - B - C。必须是(A)(AB)。ACBC不行从数据页的角度看B树就是以前os中磁盘里的数据是如何存储的知识太麻烦了跳。MySQL 单表不要超过 2000W 行靠谱吗此时树高为3。索引失效有哪些失效了就要进行全表扫描对索引使用左或者左右模糊匹配因为BTree索引表是按照【索引值】有序排列在BTree上的只能根据前缀进行比较对索引使用函数联合索引非最左匹配WHERE 子句中的 ORcount(*) 和 count(1) 有什么区别哪个性能最好count()函数是什么函数指定的参数不为 NULL 的记录有多少个。count(主键字段)的执行过程。字段 值 如果不是NULL就统计下来有主键索引没有二级索引 遍历主键索引没有主键索引有二级索引遍历二级索引。因为二级索引的叶子结点中记录更小count1与count*没有任何区别就是统计表中有多少条数据的MySQL 分页有什么性能问题怎么优化select * from page order by id limit 0, 10;select * from page order by id limit 990, 10; 会出现【深度分页】问题就是读1000页必须扫描前面123。。。。990.搞得像【全表扫描】只查前几页 就不叫【深度分页】。[分页查询]的关键字是order by id limit offset,size;分页的sql语句是select*from[表名]orderbyidlimitoffset,size;1.主键索引时【分页查询】的优化这样就不会把0~600w都扫描一边直接借助sever层的优化2.非主键索引时【分页查询】的优化优化了回表3.除了1.2在语法上进行优化还可以在产品上进行优化。如抖音的【瀑布流】直接就没有跳转到哪一页只允许上下滑。4.分批获取的方式通过 WHERE id ? LIMIT n四事务篇并行事务会引发什么问题脏读。一个事务发生回滚另一个事务读的是回滚前的数据。不可重复读。前后两次读的数据不同。回滚也会导致幻读。前后两次读的数据不同。回滚也会导致事务隔离级别是怎么实现的以及和锁的配合【读未提交】 顾名思义读到未提交的数据。没有加任何锁。【读提交】 。select读时没加锁使用的是【MVCC】照片是现场拍的。因为读的时候可以被写照片拍了又要重复拍导致每次读的照片都不一样这就是【不可重复读】的罪魁祸首。写时【记录锁】(【行锁是一个排他锁】这样别的事务不能读写就避免了脏读。)【可重复读】 。读时没加锁使用的是【MVCC】照片是在启动事务的时候拍这样就【可重复读了】写时用【记录锁】【间隙锁】。还可以消除【幻读】【串行化】 。废掉【MVCC】读时加【读锁】写时加【写锁】MySQL 可重复读隔离级别完全解决幻读了吗解决方案有两种这个例子就是用快照读Read View无法完全避免幻读。快照查 是查看事务开始时的快照副本当前读 是读取最新的正本并上锁五锁MySQL中要理解锁首要的是有【读锁】【写锁】的概念。全局锁表锁行级锁都是围绕这个展开的全局锁全局锁【可重复读】实现全库备份表级锁表锁//直接当成读锁理解就行共享锁locktablest_studentread;//写锁独占锁locktablest_studentwrite;元数据锁意向锁不懂行级锁Record Lock记录锁。Gap Lock间隙锁防止幻读Next-Key Lock插入意向锁事务A中是Next-Key Lock事务B因要在中间插入一条记录。所以Next-Key Lock会阻塞BB怎么被阻塞了就是插入意向锁起的作用。MySQL 是怎么加锁的具有加锁行为的语句updatedeleteselect...forupdate当等值查询where查到时 对索引加上记录锁 当 等值查询where没有查到时 对索引加上 间隙锁 如果带有加锁行为的语句没有走索引进行了全表查询会把全表都锁住造成巨大消耗。MySQL 死锁了怎么办为什么会产生死锁同这个段子一样发生了死锁如何避免死锁设置这些锁的超时时间。超过一段时间自动回滚到事务未开始的时候。开启 主动死锁检测。 发现死锁直接消灭。六日志篇redologWrite-ahead loggingWAL在事务写入磁盘前先将事务所做的修改写到redolog中然后再将事务写入磁盘。undolog事务在buffer pool中事务所做的修改在udolog BUffer中两者同时写入磁盘。便于回滚。binlog在server层binlog会将所有的sql操作都记录下来。可以防止删库跑路也能复制一个新的sql来。
MySQL图解
三索引篇什么是索引此时【索引】 就是目录。主键索引就是根据主键建立的目录。索引目录的建立在建表插入数据的时候就已经存在了。为什么 MySQL InnoDB 选择 Btree 作为索引的数据结构B Tree在哪一层查到不确定查询效率不稳定二叉树 层数会很多BTree查询效率高联合索引执行这个语句会建立一个BTree的索引目录最左匹配原则最左边的必须在ABC联合索引索引 (A, B, C) 的物理存储顺序是 A - B - C。必须是(A)(AB)。ACBC不行从数据页的角度看B树就是以前os中磁盘里的数据是如何存储的知识太麻烦了跳。MySQL 单表不要超过 2000W 行靠谱吗此时树高为3。索引失效有哪些失效了就要进行全表扫描对索引使用左或者左右模糊匹配因为BTree索引表是按照【索引值】有序排列在BTree上的只能根据前缀进行比较对索引使用函数联合索引非最左匹配WHERE 子句中的 ORcount(*) 和 count(1) 有什么区别哪个性能最好count()函数是什么函数指定的参数不为 NULL 的记录有多少个。count(主键字段)的执行过程。字段 值 如果不是NULL就统计下来有主键索引没有二级索引 遍历主键索引没有主键索引有二级索引遍历二级索引。因为二级索引的叶子结点中记录更小count1与count*没有任何区别就是统计表中有多少条数据的MySQL 分页有什么性能问题怎么优化select * from page order by id limit 0, 10;select * from page order by id limit 990, 10; 会出现【深度分页】问题就是读1000页必须扫描前面123。。。。990.搞得像【全表扫描】只查前几页 就不叫【深度分页】。[分页查询]的关键字是order by id limit offset,size;分页的sql语句是select*from[表名]orderbyidlimitoffset,size;1.主键索引时【分页查询】的优化这样就不会把0~600w都扫描一边直接借助sever层的优化2.非主键索引时【分页查询】的优化优化了回表3.除了1.2在语法上进行优化还可以在产品上进行优化。如抖音的【瀑布流】直接就没有跳转到哪一页只允许上下滑。4.分批获取的方式通过 WHERE id ? LIMIT n四事务篇并行事务会引发什么问题脏读。一个事务发生回滚另一个事务读的是回滚前的数据。不可重复读。前后两次读的数据不同。回滚也会导致幻读。前后两次读的数据不同。回滚也会导致事务隔离级别是怎么实现的以及和锁的配合【读未提交】 顾名思义读到未提交的数据。没有加任何锁。【读提交】 。select读时没加锁使用的是【MVCC】照片是现场拍的。因为读的时候可以被写照片拍了又要重复拍导致每次读的照片都不一样这就是【不可重复读】的罪魁祸首。写时【记录锁】(【行锁是一个排他锁】这样别的事务不能读写就避免了脏读。)【可重复读】 。读时没加锁使用的是【MVCC】照片是在启动事务的时候拍这样就【可重复读了】写时用【记录锁】【间隙锁】。还可以消除【幻读】【串行化】 。废掉【MVCC】读时加【读锁】写时加【写锁】MySQL 可重复读隔离级别完全解决幻读了吗解决方案有两种这个例子就是用快照读Read View无法完全避免幻读。快照查 是查看事务开始时的快照副本当前读 是读取最新的正本并上锁五锁MySQL中要理解锁首要的是有【读锁】【写锁】的概念。全局锁表锁行级锁都是围绕这个展开的全局锁全局锁【可重复读】实现全库备份表级锁表锁//直接当成读锁理解就行共享锁locktablest_studentread;//写锁独占锁locktablest_studentwrite;元数据锁意向锁不懂行级锁Record Lock记录锁。Gap Lock间隙锁防止幻读Next-Key Lock插入意向锁事务A中是Next-Key Lock事务B因要在中间插入一条记录。所以Next-Key Lock会阻塞BB怎么被阻塞了就是插入意向锁起的作用。MySQL 是怎么加锁的具有加锁行为的语句updatedeleteselect...forupdate当等值查询where查到时 对索引加上记录锁 当 等值查询where没有查到时 对索引加上 间隙锁 如果带有加锁行为的语句没有走索引进行了全表查询会把全表都锁住造成巨大消耗。MySQL 死锁了怎么办为什么会产生死锁同这个段子一样发生了死锁如何避免死锁设置这些锁的超时时间。超过一段时间自动回滚到事务未开始的时候。开启 主动死锁检测。 发现死锁直接消灭。六日志篇redologWrite-ahead loggingWAL在事务写入磁盘前先将事务所做的修改写到redolog中然后再将事务写入磁盘。undolog事务在buffer pool中事务所做的修改在udolog BUffer中两者同时写入磁盘。便于回滚。binlog在server层binlog会将所有的sql操作都记录下来。可以防止删库跑路也能复制一个新的sql来。
