今天遇到，一个有业务的从库，大查询阻塞了备份。身边有人说，kill掉备份就好了。其实不是的，kill掉备份仍然不能解决阻塞的问题，应该kill掉查询时间最久的那个查询，也不需要kill备份，问题就能解决，测试如下：
ID为96，这个是最早发起的查询，运行时间可以看到有561秒。
然后另起一个进程，模拟备份的过程中会执行的语句：FLUSH NO_WRITE_TO_BINLOG TABLES,如下图109，这个时间，会发现109被阻塞，state是waiting for table flush，原因正是因为id为96的查询未结束。
这个时间，执行kill 109，将备份杀掉，是没有用的，108是属于在备份之后发起的查询，如果没有备份进程，它是可以正常运行的，但由于备份进程执行了flush tables操作，所以它也处于等待状态。有意思的是，虽然kill掉备份，108的等待状态并不会消失。
这个就涉及到ＭySQL对MDL锁的管理方式的问题，它属于队列形式，先进先出，这个时候虽然杀掉了109备份程序，但还有96持有锁，108仍会继续等待，所以正确的做法应该是停掉最久的查询（kill 96），备份也不需要停掉，系统可以马上恢复正常。
其实，更推荐的做法是，修改备份程序，增加如下的参数，kill-long-query--type='select'，--kill-long-queries-timeout=1000，让备份程序自动杀掉大于1000秒的大查询。
这个能降低备份阻塞后面的查询的概率，但并不能完全避免，如果要完全避免，建议专门拿一个没业务的从库来给备份使用，或者备份遇到大查询时，自动停止备份。
