likes
comments
collection
share

Mysql 学习总结

作者站长头像
站长
· 阅读数 18

  1. 两个“原则”、两个“优化”和一个“bug”。

    1. 原则 1：加锁的基本单位是 next-key lock。希望你还记得，next-key lock 是前开后闭区间。
    2. 原则 2：查找过程中访问到的对象才会加锁。
    3. 优化 1：索引上的等值查询，给唯一索引加锁的时候，next-key lock 退化为行锁。
    4. 优化 2：索引上的等值查询，向右遍历时且最后一个值不满足等值条件的时候，next-key lock 退化为间隙锁。
    5. 一个 bug：唯一索引上的范围查询会访问到不满足条件的第一个值为止。
  2. 在 MySQL 中，字符串和数字做比较的话，是将字符串转换成数字。

  3. 字符集 utf8mb4 是 utf8 的超集，所以当这两个类型的字符串在做比较的时候，MySQL 内部的操作是，先把 utf8 字符串转成 utf8mb4 字符集，再做比较。

    select * from trade_detail where CONVERT(traideid USING utf8mb4)=$L2.tradeid.value;
  4. 行锁: 读锁之间不冲突, 写锁与读锁冲突, 写锁与写锁冲突。跟行锁有冲突关系的是“另外一个行锁”。Mysql 学习总结
  5. 但是间隙锁不一样，跟间隙锁存在冲突关系的，是“往这个间隙中插入、更新、删除一个记录”这个操作。间隙锁之间都不存在冲突关系。
  6. 4.意向锁对于 SELECT ... LOCK IN SHARE MODE; 会自动设置 IS 锁，对于 SELECT ... FOR UPDATE 会自动设置 IX 锁，并且 IS 锁和 IX 锁不需要手动设置，这个是由系统自动设置。 IS 和 IX 之间其实是兼容的，IX 之间也是兼容的，如下表：Mysql 学习总结但是意向锁和表级锁则有可能冲突，如下：Mysql 学习总结
  7. 行锁和GAP锁是分段执行的，GAP是可重入锁

  8. 除了后台线程每秒一次的轮询操作外，还有两种场景会让一个没有提交的事务的 redo log 写入到磁盘中。

    • 一种是，redo log buffer 占用的空间即将达到 innodb_log_buffer_size 一半的时候，后台线程会主动写盘。注意，由于这个事务并没有提交，所以这个写盘动作只是 write，而没有调用 fsync，也就是只留在了文件系统的 page cache。
    • 另一种是，并行的事务提交的时候，顺带将这个事务的 redo log buffer 持久化到磁盘。假设一个事务 A 执行到一半，已经写了一些 redo log 到 buffer 中，这时候有另外一个线程的事务 B 提交，如果 innodb_flush_log_at_trx_commit 设置的是 1，那么按照这个参数的逻辑，事务 B 要把 redo log buffer 里的日志全部持久化到磁盘。这时候，就会带上事务 A 在 redo log buffer 里的日志一起持久化到磁盘。多个事务共用一个 redo log buffer，所以会有相互影响的问题
  9. WAL 机制主要得益于两个方面：redo log 和 binlog 都是顺序写，磁盘的顺序写比随机写速度要快；组提交机制，可以大幅度降低磁盘的 IOPS 消耗。
转载自:https://segmentfault.com/a/1190000042291554
评论
请登录