Mysql数据库查询好慢，除了索引，还能因为什么？( 三 ) _数据库查询

force index指定索引
通过explain可以看出，加了force index之后，sql就选用了idx_age这个索引了。

走了索引还是很慢有些sql，用explain命令看，明明是走索引的，但还是很慢。一般是两种情况：
第一种是索引区分度太低，比如网页全路径的url链接，这拿来做索引，一眼看过去全都是同一个域名，如果前缀索引的长度建得不够长，那这走索引跟走全表扫描似的，正确姿势是尽量让索引的区分度更高，比如域名去掉，只拿后面URI部分去做索引。

文章插图

索引前缀区分度太低
第二种是索引中匹配到的数据太大，这时候需要关注的是explain里的rows字段了。
它是用于预估这个查询语句需要查的行数的，它不一定完全准确，但可以体现个大概量级。
当它很大时，一般常见的是下面几种情况。

如果这个字段具有唯一的属性，比如电话号码等，一般是不应该有大量重复的，那可能是你代码逻辑出现了大量重复插入的操作，你需要检查下代码逻辑，或者需要加个唯一索引限制下。
如果这个字段下的数据就是会很大，是否需要全部拿？如果不需要，加个limit限制下。如果确实要拿全部，那也不能一次性全拿，今天你数据量小，可能一次取一两万都没啥压力，万一哪天涨到了十万级别，那一次性取就有点吃不消了。你可能需要分批次取，具体操作是先用order by id排序一下，拿到一批数据后取最大id作为下次取数据的起始位置。

连接数过小索引相关的原因我们聊完了，我们来聊聊，除了索引之外，还有哪些因素会限制我们的查询速度的。
我们可以看到，mysql的server层里有个连接管理，它的作用是管理客户端和mysql之间的长连接。
正常情况下，客户端与server层如果只有一条连接，那么在执行sql查询之后，只能阻塞等待结果返回，如果有大量查询同时并发请求，那么后面的请求都需要等待前面的请求执行完成后，才能开始执行。

文章插图

连接过少会导致sql阻塞
因此很多时候我们的应用程序，比如go或JAVA这些，会打印出sql执行了几分钟的日志，但实际上你把这条语句单独拎出来执行，却又是毫秒级别的。这都是因为这些sql语句在等待前面的sql执行完成。
怎么解决呢？
如果我们能多建几条连接，那么请求就可以并发执行，后面的连接就不用等那么久了。

文章插图

增加连接可以加快执行sql
而连接数过小的问题，受数据库和客户端两侧同时限制。

数据库连接数过小Mysql的最大连接数默认是100, 最大可以达到16384 。
可以通过设置mysql的max_connections参数，更改数据库的最大连接数。

mysql> set global max_connections= 500;Query OK, 0 rows affected (0.00 sec)mysql> show variables like 'max_connections';+-----------------+-------+| Variable_name   | Value |+-----------------+-------+| max_connections | 500   |+-----------------+-------+1 row in set (0.00 sec)

上面的操作，就把最大连接数改成了500 。

应用侧连接数过小数据库连接大小是调整过了，但貌似问题还是没有变化？还是有很多sql执行达到了几分钟，甚至超时？
那有可能是因为你应用侧（go，java写的应用，也就是mysql的客户端）的连接数也过小。
应用侧与mysql底层的连接，是基于TCP协议的长链接，而TCP协议，需要经过三次握手和四次挥手来实现建连和释放。如果我每次执行sql都重新建立一个新的连接的话，那就要不断握手和挥手，这很耗时。所以一般会建立一个长连接池，连接用完之后，塞到连接池里，下次要执行sql的时候，再从里面捞一条连接出来用，非常环保。