图床炸裂....

2019-10-25
2019年末自省

2019年末自省

…….

閱讀本文

2019-07-25
近一年学习,工作总结,之后的计划

2019-06-25
MYSQL 底层原理学习的一些感悟

MYSQL 底层原理学习的一些感悟

阿里丁奇老师的神作学习

閱讀本文

2019-06-25
TCP 小记

TCP 小记

现在每学一样东西都会去思考他的设计思想是什么 , 感觉是个很好的习惯 , 希望能继续延续下去 , 也要感谢刘宇波这个绝世好老师 , 从他那里学了许多优秀的思考方式 , 也被他感染了学习计算机的热情

閱讀本文

2019-05-19
Leetcode 198 House Robber

Leetcode 198 House Robber

记录

閱讀本文

2019-05-18
Leetcode 循环队列

Leetcode 循环队列

记录

閱讀本文

2019-05-14
Leetcode 部分复盘

Leetcode 部分复盘

意识到自己算法的不足 腾出了些时间做题

閱讀本文

2019-04-13
InnoDB 常见问题

InnoDB 常见问题
  • 隔离级别有哪几种

    一定会问到的一道…

    英文单词会更好理解一些
    Read uncommitted 可以读到未提交的数据
    Read committed 可以读到已提交的数据
    Repeatable Read 可以重复读一份数据,不会读到其他事务提交的修改
    Serializable 所有事务串行执行

    不要死记,事务(一整组原子操作)之间的并发操作只有四种,读读,写写,读写,写读 (修改和删除也是写)

    1.读读的情况是不需要担心任何问题的一种情况
    2.写写是并发里最严重的情况,对同一个数据进行这种操作,基本上都是加锁的,否则会造成丢失修改(修改被覆盖),数据错乱等问题
    3.读写,a事务在读,b事务写,则可能a 事务重复读时发现数据被修改(脏读和不可重复读),或者发现新增了一条本来不存在的数据(幻读)
    4.写读,a 事务写,b 事务读同一条,则读到的是老数据(倘若是 read committed 级别),这个时候提交则会丢失修改, 需要用到乐观锁或悲观锁,最常见于库存和余额问题

  • innodb默认隔离级别是?
    Repeatable Read , 可重复读 . 底层实现为 Multi Version Concurrency Control (多版本并发控制) , 不需要加锁即可实现两个事务并发读写, 原理是a 事务再读的时候读取的是快照数据 (MySQL 技术内幕:innodb 存储引擎有深入讲解)

  • mysql 的行锁、表锁、间隙锁、意向锁分别是做什么的?

  • mysql 索引为什么用的是 b+ tree 而不是 b tree、红黑树

  • 事务 4 个特性

未完待续….

2019-04-06
最近想到的一些 MySQL 问题

最近想到的一些 MySQL 问题
  • 什么是聚集索引?

    首先innodb引擎默认在主键上建立聚集索引 , 通常说的主键索引就是聚集索引 , 聚集索引会保存行上的所有数据, 因此不需要额外的IO

  • 什么是辅助索引?

    辅助索引(Secondary Index) , 叶子节点只保存了行的键值和指向对应行的”书签” , 一般指向的是聚集索引 , 此外innodb实现了覆盖索引(Covering index) , 即叶子节点除了保存该行的键值还保存了对应索引列的值 , 如果不需要额外数据的话则不需要另外对聚集索引中的数据进行IO

    注: SQL Server的主键索引和普通索引的区别仅仅是唯一非空,而mysql innodb下不是, 另外严格来说主键是约束

  • 为什么性别列和其他低选择性的列不适合加索引?

    因为你访问索引需要付出额外的IO开销,你从索引中拿到的只是地址,要想真正访问到数据还是要对表进行一次IO。假如你要从表的100万行数据中取几个数据,那么利用索引迅速定位,访问索引的这IO开销就非常值了。但如果你是从100万行数据中取50万行数据,就比如性别字段,那你相对需要访问50万次索引,再访问50万次表,加起来的开销并不会比直接对表进行一次完整扫描小。

    当然凡事不是绝对,如果把性别字段设为表的聚集索引,那么就肯定能加快大约一半该字段的查询速度了。聚集索引指的是表本身中数据按哪个字段的值来进行排序。因此,聚集索引只能有一个,而且使用聚集索引不会付出额外IO开销。当然你得能舍得把聚集索引这么宝贵资源用到性别字段上。从性别字段不适合建索引说起

  • 优化器为什么会选择覆盖索引用于count() 等统计问题?

    因为覆盖索引远小于聚集索引 , 可以减少磁盘IO操作

  • 为什么有的时候拆分关联查询性能会更好? 还有什么其他好处?

    这样做相当于在应用中实现了哈希关联,而不是 mysql的嵌套循环关联(nested loop join , 假设两表 join , 如果被驱动表没有索引的话相当于 O(n1n2) , 有的话相当于 O(n1logn2)b+tree 索引或者 O(n1*1)innodb 自动优化为 hash 索引),某些场景哈希关联的效率要高很多.

    当然也不是绝对的,实际测试的过程中发现如果优化器选择了一个正确的关联顺序也有很好的效率(5.6和 5.7 对同一条语句的优化效果也不同..) , 如果不能确定优化器选择路径的话可以用straight join 自行优化.

    其他好处:

    ​ 后期对数据库进行拆分(读写分离, 分库分表 , )或横向扩展时减少对应用层的修改

    参考<高性能mysql> 6.3.1

  • 临时表上有索引吗?

    临时表没有索引,因此要尽量避免产生临时表

  • 什么时候会产生临时表?

    直接explain , extra列using temporary则可能产生了临时表 , 子查询和关联查询都容易产生临时表

  • mysql join底层是如何执行的
    nested loop join :根据高性能 mysql 和网上的文章,最最原始的情况下是两表嵌套 for 循环O(n1n2)~O(n^2)(笛卡尔积), 但是在第二层被循环的表有索引的情况下,只需要在索引中查找对应数据,于是复杂度就变成了 B+tree 索引 O(n1logn2)~O(nlogn) 或者 hash 索引 O(n1*1) , 并且优化器会自动将小表选为第一层 for 循环的目标

    还有另一种暂时没有深入去学习

  • 参考

    MySQL技术内幕:innodb存储引擎-第五章

    高性能MySQL第三版 3.3剖析mysql查询 第6章 查询性能的优化

2019-03-10
单点登录的理解

单点登录的理解

最近学习单点登录的时候,发现和 OAuth 很类似,于是就循着这个踪迹找寻下去

閱讀本文