由于 MySQL 采用的是边算边发的逻辑，因此对于数据量很大的查询结果来说，不会在 server 端保存完整的结果集。
所以，如果客户端读结果不及时，会堵住 MySQL 的查询过程，但是不会把内存打爆。
而对于 InnoDB 引擎内部，由于有淘汰策略，大查询也不会导致内存暴涨。
主要介绍了kill命令的执行逻辑流程，并不是简单直接结束命令（kill connection id；kill query id）
另外解释了两个误解：
- 如果库里的表特别多，客户端连接会很慢。
主要介绍了几种误删数据的操作及恢复方案，并提出预防误删的方案：
- 使用 delete 语句误删数据行
- 使用 drop table 或者 truncate table 语句误删数据表；
- 使用 drop database 语句误删数据库；
主要介绍了如何判断一个mysql数据库是否健康 原文：https://time.geekbang.org/column/article/781
之前都在介绍主备，一主一备，本篇主要介绍一主多从（一主一备多从），在主库出问题后，如何切换到备库，并将从库设置master指向到新的主库（原
主要介绍了为什么备库会延迟好几个小时，及mysql目前常用的5.6,5.7等几个版本的并行复制策略 原文：https://time.geekb
主要介绍了主备延迟及延迟的原因，为了数据库的高可用性，提出了可靠性优先策略、可用性优策略的一些DBA具体操作。对于开发人员需要知道是如何避免主备延迟问题：
- 备库查询，也要关注性能
- 备库机器硬件
- 避免大事务
主要介绍了主备数据库之间的数据如何同步，及整个数据同步事务逻辑流程；并着重介绍了binlog（同步的主要载体）的3种格式，statement
主要介绍了binlog与redo log的cache及写入机制，方便开发更清楚的了解mysql及InnoDB相关log机制 原文链接：https
不知道你在实际运维过程中有没有碰到这样的情景：业务高峰期，生产环境的MySQL压力太大，没法正常响应，需要短期内、临时性地提升一些性能。
我以前做业务护航的时候，就偶尔会碰上这种场景。用户的开发负责人说，不管你用什么方案，让业务先跑起来再说。
但，如果是无损方案的话，肯定不需要等到这个时候才上场。今天我们就来聊聊这些临时方案，并着重说一说它们可能存在的风险。
