不看后悔的腾讯面试题：SQL语句为什么执行的很慢？

假如是扫描全表的话，那么扫描的次数就是这个表的总行数了，假设为 n;而假如走索引 c 的话，我们通过索引 c 找到主键之后，还得再通过主键索引来找我们整行的数据，也就是说，必要走两次索引。并且，我们也不知道切合 100 c < and c < 10000 这个前提的数据有几多行，万一这个表是所稀有据都切合呢?这个时辰意味着，走 c 索引不只扫描的行数是 n，同时还得每行数据走两次索引。

以是呢，体系是有也许走全表扫描而不走索引的。

那体系是怎么判定呢?

判定来历于体系的猜测，也就是说，假如要走 c 字段索引的话，体系会猜测走 c 字段索引或许必要扫描几多行。假如猜测到要扫描的行数许多，它也许就不走索引而直接扫描全表了。

那么题目来了，体系是怎么猜测判定的呢?这里我给你讲下体系是怎么判定的吧，固然这个时辰我已经写到脖子有点酸了。

体系是通过索引的区分度来判定的，一个索引上差异的值越多，意味着呈现沟通数值的索引越少，意味着索引的区分度越高。我们也把区分度称之为基数，即区分度越高，基数越大。以是呢，基数越大，意味着切合 100 < c and c < 10000 这个前提的行数越少。

以是呢，一个索引的基数越大，意味着走索引查询越有上风。

那么题目来了，怎么知道这个索引的基数呢?

体系虽然是不会遍历所有来得到一个索引的基数的，价钱太大了，索引体系是通过遍历部门数据，也就是通过采样的方法，来猜测索引的基数的。

扯了这么多，重点的来了：

既然是采样，那就有也许呈现失误的环境，也就是说，c 这个索引的基数现实上是很大的，可是采样的时辰，却很不幸，把这个索引的基数猜测成很小。譬喻你采样的那一部门数据恰恰基数很小，然后就误觉得索引的基数很小。然后就呵呵，体系就不走 c 索引了，直接走所有扫描了。

以是呢，说了这么多，得出结论：因为统计的失误，导致体系没有走索引，而是走了全表扫描，而这，也是导致我们 SQL 语句执行的很慢的缘故起因。

这里我声明一下，体系判定是否走索引，扫描行数的猜测着实只是缘故起因之一，这条查询语句是否必要行使行使姑且表、是否必要排序等也是会影响体系的选择的。

不外呢，我们偶然辰也可以通过逼迫走索引的方法来查询，譬喻：

select * from t force index(a) where c < 100 and c < 100000; 

我们也可以通过：

show index from t; 

来查询索引的基数和现实是否切合，假如和现实很不切合的话，我们可以从头来统计索引的基数，可以用这条呼吁：

analyze table t; 

来从头统计说明。

既然会猜测错索引的基数，这也意味着，当我们的查询语句有多个索引的时辰，体系有也许也会选错索引哦，这也也许是 SQL 执行的很慢的一个缘故起因。

好吧，就先扯这么多了，你到时辰能扯出这么多，我认为已经很棒了，下面做一个总结。

三、总结

以上是我的总结与领略，最后一个部门，我怕许多人不大懂数据库居然会选错索引，以是我具体表明白一下，下面我对以上做一个总结。

一个 SQL 执行的很慢，我们要分两种环境接头：

大大都环境下很正常，无意很慢，则有如下缘故起因：

• 数据库在革新脏页，譬喻 redo log 写满了必要同步到磁盘。
• 执行的时辰，碰着锁，如表锁、行锁。

这条 SQL 语句一向执行的很慢，则有如下缘故起因：

• 没有效上索引：譬喻该字段没有索引;因为对字段举办运算、函数操纵导致无法用索引。
• 数据库选错了索引。

作者先容

帅地，订阅号「苦逼的码农」作者，专注于计较机基本、数据布局与算法、Java等规模。

【编辑保举】

1. 我在阿里做技能口试官的一些履历
2. 我去口试Python岗亭了
3. 包装严峻的IT行业，作为口试官，我是怎样甄别应聘者的包装水平
4. 口试陷阱：数十亿级别数据下，怎样进步ES查询服从？
5. 阿内里试，我挂在了第四轮……

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!