第一章 MySQL架构与历史

1. mysql的存储引擎负责数据的存储和提取,存储引擎不会去解析SQL,不同的存储引擎之间也不会相互通信,而是简单的相应上层服务器的请求。
2. 优化器不关心表使用的是什么存储引擎,但是存储引擎对于优化查询是有影响的,优化器会请求存储引擎提供容量或某个具体操作的开销信息,以及表数据的统计信息等。
3. 共享锁(简称S锁,又叫读锁)和排它锁(简称X锁,又叫写锁):
  • InnoDB引擎默认的修改数据语句,update,delete,insert都会自动给涉及到的数据加上排他锁
  • select语句默认不会加任何锁类型
  • 共享锁就是多个事务对于同一数据可以共享一把锁,都能访问到数据,但是只能读不能修改,即被加了共享锁的数据记录,在无法进行更新操作。
  • 加排他锁可以使用select ...for update语句,加共享锁可以使用select ... lock in share mode语句。
  • 加过排他锁的数据行在其他事务中是不能修改数据的,也不能通过for update和lock in share mode锁的方式查询数据,但可以直接通过select ...from...查询数据,因为普通查询没有任何锁机制
  • 排他锁指的是一个事务在一行数据加上排他锁后,其他事务不能再在其上加其他的锁。
4. 锁粒度:
  • 表锁:锁定整张表,此时会阻塞其他用户对该表的所有读写操作,读锁之间是不会相互阻塞的。尽管存储引擎可以管理自己的锁,MySQL本身还是会使用各种有效的表锁来实现不同的目的。例如,服务器会为如ALTER TABLE之类的语句使用表锁,而忽略存储引擎的锁机制。
  • 行级锁:只在存储引擎层实现。
5. 事务:
  • 原子性(Atomicity):整个事务的操作要么全部成功,要么全部失败回滚。
  • 一致性(Consistency):数据库总是从一个一致状态转换到另一个一致状态。【一致性和原子性的区别:https://www.cnblogs.com/loren-Yang/p/7466132.html

    原子性和一致性不是一样的吗?
    提交事务,原子性保证要么成功,要么失败,这样不就是很好的保证数据库的一致性了吗。当时我看见大多数人举的一致性例子就是转账问题:假设用户A和用户B两者的钱加起来一共是5000,那么不管A和B之间如何转账,转几次账,事务结束后两个用户的钱相加起来应该还得是5000,这就是事务的一致性。当我我就想难道原子性不就保证了转账成功和失败吗?
    其实,我上述想法是错的,但是部分错,因为,原子性确实代表一致性的部分,但不是全部。下面是我在知乎上看到的答案左轻候,感觉可以很好的解释原子性和一致性区别。
    原子性其实并不能保证一致性的。再多个事务并行进行的情况下,即使保证每一个事务的原子性,任然可能导致数据不一致的结果。
    举例:事务1需要将100元转入帐号A:先读取帐号A的值,然后在这个值上加上100。但是,在这两个操作之间,另一个事务2修改了帐号A的值,为它增加了100元。那么最后的结果应该是A增加了200元。但事实上,事务1最终完成后,帐号A只增加了100元,因为事务2的修改结果被事务1覆盖掉了。
    如上,保证了原子性,但是数据库的一致性没有得到保证,上述这种情况就需要数据库隔离性的保证了。

  • 隔离性(Isolation):一个事务所做的修改在事务提交以前,对其他事务来说是不可见的。
  • 持久性(Durability):事务一旦提交,其所做的修改就会永久保存到数据库中。
6. 事务隔离级别
  • 读未提交(READ UNCOMMITTED)

  • 读已提交(READ COMMITTED)

  • 可重复度(REPEATABLE READ)

  • 序列化(SERIALIZE)


    image.png
  • 脏读:读同一条记录,每次查询结果不一致;

  • 幻读:指的是当前某个事务在读取某个范围内的记录时,另一个事务又在该范围内插入了新的记录,当之前的事务再次读取改范围内的数据记录时,会产生幻读。

7. 死锁:数据库系统实现类各种死锁检测和死锁超时机制。InnoDB目前处理死锁的方法是,将持有最少行级排他锁的事务进行回滚。
8. 事务日志:使用事务日志,存储引擎在修改表的数据时只需要修改其内存拷贝,再把该修改行为记录到持久在硬盘上的事务日志中(而不是每次将修改的数据本身持久到磁盘),事务日志持久后,内存中被修改的数据在后台可以慢慢的刷回到磁盘。
9. 多版本并发控制(MVCC),https://juejin.im/post/5c68a4056fb9a049e063e0ab
image.png
10. InnoDB概览:
  • InnoDB采用MVCC来支持高并发,并且实现了四个标准的隔离级别。其默认级别是RR,并且通过间隙锁策略防止幻读的出现,间隙锁使得InnoDB不仅仅锁定查询涉及的行,还会对索引中的间隙进行锁定,以防止幻影行的出现。
  • 其二级索引的中会包含主键列(叶子节点),所以如果主键列很大的话,其他的所有索引都会很大,因此若表上的索引较多的话,主键应当尽可能的小。
11. 转换表的引擎:
  • 可以通过ALTER TABLE语句对表引擎进行转换,但是该方法执行需要很长时间。MySQL会按行将数据从原表复制到一张新的表,在复制期间可能会消耗系统所有的IO能力,同时会在原表上加锁。
  • 书中推荐的方法是,新建一个表,然后通过过INSERT INTO ... SELECT 语句来进行原表数据迁移,此时要注意,SELECT条件中一定要使用索引字段,并逐步批量迁移,否则依然会造成原表锁表
12. 当两个事务在对同一个数据同时进行更新的时候,先开始的事务会将数据加锁,后开始的事务需要等待前一个事务提交后才能获取锁,而后才能执行更新操作。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,456评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,370评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,337评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,583评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,596评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,572评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,936评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,595评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,850评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,601评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,685评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,371评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,951评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,934评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,167评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,636评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,411评论 2 342