开发者学堂课程【云数据库优化经典案例：延迟优化】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/67/detail/1161
延迟优化
主要内容
一、只读实例架构
二、DDL 导致延迟
三、MDL 锁导致延迟
四、延迟问题最佳实践
一、只读实例架构
第四个是常见的一个延迟，它主要是出现在只读实例这种架构中的一个延迟，比如现在使用的这种主备只读级别架构。它采用的是 MySQL 原生复制，在原生复制上进行了一个改进，比使用的多线程同步。针对这种情况下出现的延迟，和 DDL 导致的延迟相对比，这个是非常多的常见的延迟。
二、DDL 导致延迟
比如在主库做了一个常见 DDL:create index, repair, optimze table, alter table add column（加一个字段）这样一个操作，一定会导致延迟，因为在主库上做这样一个操作，比如花了十分钟，那么这个操作传到备库上同样也需要花十分钟，这时候因为在备库上或者只读节点做这个操作，是串行的，不能并行。所以同步线程就全部耗在DDL的时间上了，这个时候应该在业务低峰的时候去做它，或者把流量切换到主库读节点，因为现在阿编程读写分离。是可以很方便的把那个读节点的流量切换到主机电上面去，这样的一个是非常方便的一个功能，读写分离。看一下这个案例:
只读节点出现延迟，主库同一时间点备库也出现了延迟。然后，分析当时的sql，发现主库在执行 ADD INDEX 这个操作。所以，主库在执行这样一个操作读节点，备库也会执行这样的操作延迟相应的时间。注意在做这个操作的时，一定是业务低峰，或者是流量切换到主库上去，避免业务得到一个延迟的数据，影响业务。类似的操作，还有一些大事务，例如: create.. as select, insert...select, load.. data, delete...from, update..from。mac in, mac 删除这种大的操作其实也会导致这种延迟，一定要注意。
三、MDL 锁导致延迟
读节点上除了来自于主库的数据的同步，同时还会存在业务访问压力，比如一些bob的查询，一些读的请求，这个时候往往会出现问题，例如一个大的，复杂的统计查询在读节点上运行。那这个时候这个 sql 一般是非常复杂的，它的执行世界非常不理想。那么主库这个时候如果传过一个 DDL 语句，它必须等查询结束。如果查询不结束那么 DDL 语句将一直被 block 住，主库传过来的数据将导致一直被延迟。所以延迟的结束直到读节点的大查询结束才能完成同步。这个时候需要观察在做 DDL 的时读节点上是否有大的查询在运行。此时可以通过修 processlist 去看每个连接的状态是否发生主设。
这个案例可以看到读节点延迟80多万秒。因为这个读节点上有一个非常慢的查询导致的这样一个问题，所以这个时候把这个慢的查询跳掉，就可以解决这个问题。
资源的问题，
从它可以看到，这个读节点出现了延迟。非常尖的延迟，这个时候去看当时数据库，它的 CPU 打满了，就是读节点的 CPU 打满了。因为读节点会存在一个查询访问，那这个时候如果 io 资源打满了，CPU 资源打满了，从主库同步过来的一些数据。因为也要消耗资源，所以就会导致同步延迟同这个主库传过来的数据应用到读节点上会应用缓慢，这样导致的延迟。所以要去观察这个读节点上面一个压力，因为这个压力包括同步压力以及读业务的压力。所以要去去判断 CPU 的压力和 io 的压力，所以资源的问题也可能导致数据同步的延迟。
四、延迟问题最佳实践
1、排查思路
（1）一看资源是否达到瓶颈；看一下它的 CPU 资源，io 资源。
（2）二看线程状态是否有锁；锁是 mld 锁，这种情况也是非常常见的，
（3）三看判断是否存在大事务。看一下是否有存在大事务大的 DDL。
这样从主库传过来，也会导致延迟。
2、最佳实践
（1）使用 innodb 存储引擎；它支持online ddl和在线的一个备份。
（2）只读实例的规格不低于主实例；因为只读实例其实存在非常复杂的一个业务查询。
（3）大事务拆分为小事务；比如删除1000万行的数据，可以一个 cycle delete..from就可以解决。因为是个大事务，它可能发挥两个小时解决。如果拆成100条100条删除，那可能100条就是花一秒钟就完成了，这个时候主备的同步基本上就不会受到影响。
（4）DDL 变更期间观察是否有大查询。DDL 变更期间是否有大查询或者是慢查询，这个和锁的问题是一致的。
