摘要：
这篇文章分析备库延迟的原因：执行日志的速度持续低于主库生成日志的速度
分析了很多版本备库并行复制的策略，就是为了5.7版本做铺垫，只要知道5.7.22并行复制的三个策略COMMIT_ORDER（只有在多线程模式下，prepare后即可并发。无单线程优势），WRITESET（计算事务每行hash 值，组成集合 没操作相同的行，就并行。单线程优势）,WRITESET_SESSION(在前面writest多了一个约束，使主备执行顺序相同，单线程压力模式下退化成单线程复制，感觉只有特定情况才用它) 阅读全文
摘要：
为了让各位更好的了解文章，我归纳了下面几点最重要的：
1、MySQL 高可用系统的可用性，是依赖于主备延迟的。延迟的时间越小，主库故障的时候，服务恢复需要的时间就越短，可用性就越高。
2、主备延迟原因：备库用的机子不行（IOPS是和主库相同的，不要轻视备库）、备库压力太大，查询消耗了大量cpu（因为主库直接影响业务，大家用的克制，懂的都懂）、大事务（要是一个事务在主库执行10分钟，在备库那也得执行个10来分钟，这延迟不就来了）
3、主库备库切换策略有两个：可靠性（在切换中，主库备库将处于readonly状态，事务写不进去），可用性（直接主库备库秒切，但十分容易数据错乱，建议binglog用row格式）
哦，还有一个最重要的参数
命令：show slave status
你要看seconds_behind_master 的值，他是主备库的延迟时间，地位在高可用里面相当的重要 阅读全文
摘要：
第二十三讲：MySQL是怎么保证主备一致的？ 简概 开篇 在前面的文章中，我不止一次地和你提到了 binlog，大家知道 binlog 可以用来归档，也可以用来做主备同步，但它的内容是什么样的呢？为什么备库执行了 binlog 就可以跟主库保持一致了呢？今天我就正式地和你介绍一下它。 毫不夸张地 阅读全文
摘要：
第二十二讲：MySQL是怎么保证数据不丢的？ 简概 开篇 今天这篇文章，我会继续和你介绍在业务高峰期临时提升性能的方法。从文章标题“MySQL 是怎么保证数据不丢的？”，你就可以看出来，今天我和你介绍的方法，跟数据的可靠性有关。 在专栏前面文章和答疑篇中，我都着重介绍了 WAL 机制（你可以再回 阅读全文
摘要：
文章提出了数据库在高并发高请求的情况下出现的一些性能问题，这里警示DB人员饮鸩止渴提高性能操作：应对短连接风暴，切掉空闲进程（部分事务回滚），max connect参数（过高有损性能），还有SQL语句本身原因，正如之前讨论过的索引：没设计、选错了、有，但没用上，以及应对QPS（单位时间查询）过高必须下掉功能时：白名单，用户删除，语句重写（要分环境，看公司运维规范程度） 阅读全文
摘要：
该文章深刻揭示了一点：加索引=行锁+间隙锁=（next-key lock），分析了加锁的规则：对主键（唯一索引），普通非唯一索引进行等值与范围查询的加锁。这篇文章我认为收获最大的是让我们知道“明明对一行加了锁，为什么在他相邻部分，或是相相邻部分无法插入数据（这根主键类型，是单个还是范围查询有关，就算他的逻辑是一样的）”,值的一提的是事务的for update更新与delete加锁规则是一样的，这意味着在你在大量插入的业务下删除数据可能会导致“数据insert失败”，解决方式是加limit，减少间隙锁的范围。 阅读全文
摘要：
文章以幻读起手，以假设的方式钻“加锁”的空子，引出“间隙锁”（也就是现在的mysql锁机制），但就算这样，在可重复读的隔离级别下也会发生死锁，即使对行锁有准确的认识，也可能会因为间隙锁翻车，像两个session同时占用一个主键（注意：与行锁不同，他没有锁之间的冲突）插入操作时都会被对方的间隙锁挡住（虽然很行锁很相似，但他们的加锁位置不同） 阅读全文
摘要：
和上篇文章不同，文章探讨了我们正常执行sql语句慢的原因：第一：其他进程正在DML写锁，需要kill或等待，第二flush刷盘flush在关闭session途中被别的命令堵住了，进一步堵住select查询，如sleep，第三，在引擎层面update存在且不提交写锁也会被堵住（这边还介绍了kill query与kill的去别，十分实用），第四：查询慢还可以是索引：走主键顺序扫描(可以在慢查询日志里找)，第五：就算只扫描一行，但还是慢，还可以是事务一直没提交，造成undolog回滚日志特别长，如果没有加“lock in share mode”，那读取数据得先回滚到上一个版本再读取。 阅读全文
摘要：
该文章中，提出了”有很多看上去逻辑相同，但性能却差异巨大的 SQL 语句”提出索引树罢工的现象分析了三个原因：where后面函数操作，多表查询字段类型冲突，utf-8字符编码冲突（俗称隐式类型转换），正因如此索引就会罢工（explain中key显示NULL），这边还顺便介绍了驱动表（多表查询from后面的是被驱动表），最后要强调的是select * from table where id + 1 = 10000 这个 SQL 语句与select * from table where id = 10000-1（这道题体现文章核心思想） 两者间查询效率相差极大 阅读全文
摘要： 
该文章承接上一篇order by排序，进一步提出随机挑选数据的问题，站在大量数据查询的情况下：提出select word from words order by rand() limit 3;这种我们经常使用的查询语句的弊端：既要建立临时表排序（这里优化器使用的rowid排序）而且如果表中有一万条数据，那么扫描行数高达2万零三条（虽然sort_buffer排序不涉及表操作，不扫描表，这里需要注意临时表，上一张没细讲，就是因为使用另一个引擎，先后从memory到innodb引擎读了1万条数据），此外，拓宽了上一张rowid主键的范围（也可以是系统建的默认递增主键），还有优先队列排序法也挺有意思（与归并排序算法区分下），为了解决上面随机查询的弊端，我们提出了随机排序算法（这里要注意数据空洞，不能用大小比较）利用变量，字符串拼接，预处理语句十分有意思 阅读全文
该文章承接上一篇order by排序，进一步提出随机挑选数据的问题，站在大量数据查询的情况下：提出select word from words order by rand() limit 3;这种我们经常使用的查询语句的弊端：既要建立临时表排序（这里优化器使用的rowid排序）而且如果表中有一万条数据，那么扫描行数高达2万零三条（虽然sort_buffer排序不涉及表操作，不扫描表，这里需要注意临时表，上一张没细讲，就是因为使用另一个引擎，先后从memory到innodb引擎读了1万条数据），此外，拓宽了上一张rowid主键的范围（也可以是系统建的默认递增主键），还有优先队列排序法也挺有意思（与归并排序算法区分下），为了解决上面随机查询的弊端，我们提出了随机排序算法（这里要注意数据空洞，不能用大小比较）利用变量，字符串拼接，预处理语句十分有意思 阅读全文