传统的高可用架构是不能预防误删数据的，因为主库的一个 drop table 命令，会通过 binlog 传给所有从库和级联从库，进而导致整个集群的实例都会执行这个命令
a. 误删行：Flashback 工具通过闪回把数据恢复回来-修改 binlog 的内容，拿回原库重放，insert<->delete，update before<->after
delete 全表是很慢的，需要生成回滚日志、写 redo、写 binlog。所以，从性能角度考虑，你应该优先考虑使用 truncate table 或者 drop table 命令
b. 误删库 / 表: 全量备份，加增量日志，用备份恢复出一个临时库，从日志备份里面，取出全量备份时间点之后到误删之前的日志，应用到临时库
用备份恢复出临时实例之后，将这个临时实例设置成线上备库的从库
把 mysqlbinlog 工具解析出的 binlog 文件应用到临时库，还是把临时库接到备库上，这两个方案的共同点是：误删库或者表后，恢复数据的思路主要就是通过备份，再加上应用 binlog 的方式
延迟复制备库: 一般的主备复制结构存在的问题是，如果主库上有个表被误删了，这个命令很快也会被发给所有从库，进而导致所有从库的数据表也都一起被误删了，复制的备库是一种特殊的备库，通过 CHANGE MASTER TO MASTER_DELAY = N 命令，可以指定这个备库持续保持跟主库有 N 秒的延迟，缩短了整个数据恢复需要的时间
预防误删库 / 表的方法： 账号分离/操作规范
MySQL 中有两个 kill 命令：一个是 kill query + 线程 id，表示终止这个线程中正在执行的语句；一个是 kill connection + 线程 id，这里 connection 可缺省，表示断开这个线程的连接，当然如果这个线程有语句正在执行，也是要先停止正在执行的语句的
kill 并不是马上停止的意思，而是告诉执行线程说，这条语句已经不需要继续执行了，可以开始“执行停止的逻辑了，当用户执行 kill query thread_id_B 时，MySQL 里处理 kill 命令的线程做了两件事：1. 把 session B 的运行状态改成 THD::KILL_QUERY(将变量 killed 赋值为 THD::KILL_QUERY)；2. 给 session B 的执行线程发一个信号
kill 无效的第一类情况，即：线程没有执行到判断线程状态的逻辑。跟这种情况相同的，还有由于 IO 压力过大，读写 IO 的函数一直无法返回，导致不能及时判断线程的状态
另一类情况是，终止逻辑耗时较长，大事务，大查询，回滚日志或临时文件清理等长耗时操作
MySQL 是停等协议，所以这个线程执行的语句还没有返回的时候，再往这个连接里面继续发命令也是没有用的。实际上，执行 Ctrl+C 的时候，是 MySQL 客户端另外启动一个连接，然后发送一个 kill query 命令
客户端查询，对大表做全表扫描，是边读边发的，数据是保存在主键索引上的，所以直接扫描表 t 的主键索引，服务端并不保存完整的结果集，不断取，放入net_buffer，满了通过网卡发送，循环
如果你在自己负责维护的 MySQL 里看到很多个线程都处于“Sending to client”这个状态，表示服务器端的网络栈写满了，就意味着你要让业务开发同学优化查询结果，并评估这么多的返回结果是否合理
Buffer Pool 对查询的加速效果，依赖于一个重要的指标，即：内存命中率，show engine innodb status 结果中，查看一个系统当前的 BP 命中率，show engine innodb status ，可以看到“Buffer pool hit rate”字样，显示的就是当前的命中率
InnoDB 内存管理用的是最近最少使用 (Least Recently Used, LRU) 算法的改进版，按照 5:3 的比例把整个 LRU 链表分成了 young 区域和 old 区域，在扫描这个大表的过程中，虽然也用到了 Buffer Pool，但是对 young 区域完全没有影响，从而保证了 Buffer Pool 响应正常业务的查询命中率