目录
在日常开发中，数据库的查询操作是非常常见的。但是，如果MySQL数据库出现慢查询，是比较危险的，一旦有其他的DDL操作，可能会造成整个数据库的等待。
可以分以下几种情况：
1、当表是Myisam表，对表有慢查询，不阻塞Select，对该表的其他DML、DDL操作都会被阻塞。比如出现Wating for table level lock，数据库中一定不能还存在MyiSAM表。
2、当表是Innodb表，当表上有慢查询，不阻塞Select 和DML，其他的DDL操作都会被阻塞，比如出现waiting for table metadata lock。
综上，当数据库中存在慢查询时，是比较危险的，当执行备份、create index、alter table 、flush table 等操作时就会造成数据库的等待。
1、对查询SQL，进行压测，该加索引就加索引；
2、如果有索引，进行explain执行计划分析；
数据库声明：
MySQL数据库、innodb存储引擎、20万左右的数据量；
a、b、c三个字段可以确认表中一条记录(a、b、c字段没有加索引)；
业务描述：
现有两条线程，线程1执行业务操作：其中，有个操作是根据a、b、c三个字段进行查询，为下一个操作做准备；
线程2是定时job：该job定时轮询该表状态是init的记录，然后把这些记录发送到MQ(业务逻辑)，最后把init-->sent。
问题现象：
表中同一条记录被重复发送到MQ中。
问题分析：
由于a、b、c字段没有加索引且数据库数量比较大(20多万)，导致进行全表扫描。那么，在线程1锁表的过程中-->线程2将一批init记录发送到MQ，然后来更改init到sent时更新超时失败-->线程1还在锁着表-->线程2又将这批init记录发送到MQ，然后来更改init到sent时更新超时失败....一直重试着。
总结归纳：
首先，对于a、b、c三个字段未加索引查询表导致的慢查询，是造成此次事故的直接原因。这提醒我们在设计表的时候或者在做业务的时候，必须对查询性能做压测。
其次，架构设计是存在很大的问题的。现在的逻辑是：查询init-->业务-->sent。正向流程没什么问题，但是我们开发的时候不能只想到正常情况，对于逆向流程的异常情况，也必须做考虑，就比如上面的流程，如果更新为sent失败了呢？这时候你的业务发给mq也已经发了，这如何保证一致性呢？ 正确的做法应该是添加一个中间态processing：查询init-->processing-->业务-->sent，这样如果更新为procesing失败没有关系，因为我业务还没有做；如果更新sent失败也不会影响我的业务（往mq发消息），因为状态已经是processing，job只会扫描init的数据，保证了不会往mq重新发消息。