大家都在说今年是程序员都不太好找工作，根据Boss直聘提供的数据，今年平均1份工作可以收到个简历，竞争还是比较激烈的。今天给大家分享一个经典的程序员面试题，为什么我只从Mysql中筛选几行数据，执行速度却非常慢呢。
这里有非常多的可能，首先我们考虑到的，当然是没有简历索引或者没法使用上索引。有一定经验的自然不会忘记添加索引，但是我们却常常因为一些小马虎没法正确地使用索引。例如，使用了不等于符号。举个例子，如果我们的某一个状态有1,2,3,4四个值，我们想要筛选不等于4的，如果我们的sql写的是status！=4，那么无法使用索引。如果想要使用到索引，那么我们只能够statusin(1,2,3)或者status4。也有可能我们使用索引的时候没有遵循最左匹配原则，例如所以的字段是1,2,3，我们的查询条件只有3，那么这个索引无法被使用到。所以，当我们发现一个sql执行得比较慢的时候，我们可以使用Explain看一下，看看sql语句使用索引的情况。
不知道大家会不会有这样的经历。因为业务的需要，原来的数据表需要新增字段了，你在测试环境验证没有问题之后，吭哧吭哧打算上正式环境了。这个时候你的DBA就会阻止你，告诉你说要等到今天晚上夜深人静再来执行，因为使用InnoDB的Mysql在扩展的时候，是需要锁表的。锁表，顾名思义，就是在这个期间整个数据表被加锁，无法完成增删改查操作。所以，但我们只是进行简单的Select语句却等不到返回的时候，有可能就是这样的情况。
除了被锁表，在日常生活中，我们更多的是出现的是行级别的锁冲突。虽然Mysql实现了多版本并发控制MVCC,但仍然无法避免会出现行锁冲突。举个例子，假如我们的事务类型是读未提交，那么我们很有可能在查询某一行的数据时，有非常多的进程也要同时对这一行数据进行更新，这个时候我们无法取得行锁只能够进行等待，造成查询时间过长。差不多的道理，如果我们使用的事务是可重复读，那么在时候开始之后，可能某一行的数据更新多次，我们也需要读取redolog回溯结果才能保持可重复读的事务特性。
假如我们在平时遇到mysql执行速度太慢，也不用慌，冷静下来，分析当时的机器与业务情况，发现问题，解决问题。欢迎大家