百度知道财富值相当于您在百度知道的钱包，您的每一次高质量回答贡献都可以获得对应的财富，您可以用来  悬赏、匿名提问 、购买或者兑换百度商城的物品。
一、财富值最普遍的用处就是用它来向专家和网友提问，用财富值增加你的悬赏，你的问题会得到更多人的关注和解决方案。  
二、财富值还可以在知道商城进行礼品兑换
点击查看商品的剩余数量，再点立刻兑换，然后填写自己的收货地址，奖品就会妥妥送到你的手中了。

、提问：显示器画面不停地轻微抖动，有什么办法

答：你也不停地抖动，当你的频率和振幅与显示器画面一致时，

、提问：如何除掉烦人的狗

我家附近有人养狗，且不管它随便

跑，经常晚上在我家门口拉屎，有没有办法不让它在我家拉屎，或

神不知鬼不觉地把它弄死且没人知道。

回答一：和主人说没用，我告诉你个好主意。每次狗拉屎的时候，

你去偷看，等狗发现了你在偷看，它会害羞的，就再也不敢到你家

回答二：给它买一台计算机，然后教它上网，它就没空去你家门

回答三：大小脑都不发达。

回答一：在寝室门上贴上“戒严”或者“查封”等字样，造成寝

室已经停止营业的假象。

回答二：买个食蚁兽回来不就结了。

回答三：播放张楚的歌曲《蚂蚁》三十遍。

回答四：把这个问题贴到蚁巢门口，难死它们

因为索引是MySQL中比较重点的知识，相信很多人都有一定的了解，尤其是在面试中出现的频率特别高。楼主自认为自己对MySQL的索引相关知识有很多了解，而且因为最近在找工作面试，所以单独复习了很多关于索引的知识。

但是，我还是图样图森破，直到我被阿里的面试官虐过之后我才知道，自己在索引方面的知识，只是个小学生水平。

以下，是我总结的一次阿里面试中关于索引有关的问题以及知识点。需要领取的可以看文末领取。

索引概念、索引模型 我们是怎么聊到索引的呢，是因为我提到我们的业务量比较大，每天大概有几百万的新数据生成，于是有了以下对话：

我：是的，我们线上使用的是MySQL数据库

我：我们在数据库中创建了一些索引（我现在非常后悔我当时说了这句话）。 这里可以看到，阿里的面试官并不会像有一些公司一样拿着题库一道一道的问，而是会根据面试者做过的事情以及面试过程中的一些内容进行展开。

我：（这道题肯定难不住我啊）索引其实是一种数据结构，能够帮助我们快速的检索数据库中的数据。

我：（这道题我也背过）常见的MySQL主要有两种结构：Hash索引和B+ Tree索引，我们使用的是InnoDB引擎，默认的是B+树。

这里我耍了一个小心机，特意说了一下索引和存储引擎有关。希望面试官可以问我一些关于存储引擎的问题。

我：（突然觉得这道题有点难，但是我还是凭借着自己的知识储备简单的回答上一些）因为Hash索引底层是哈希表，哈希表是一种以key-value存储数据的结构，所以多个数据在存储关系上是完全没有任何顺序关系的。所以，对于区间查询是无法直接通过索引查询的，就需要全表扫描。所以，哈希索引只适用于等值查询的场景。 而B+ Tree是一种多路平衡查询树，所以他的节点是天然有序的（左子节点小于父节点、父节点小于右子节点），所以对于范围查询的时候不需要做全表扫描。

我：（这个题我回答的不好，事后百度了一下）

科普时间：B+ Tree索引和Hash索引区别

哈希索引适合等值查询，但是不无法进行范围查询 哈希索引没办法利用索引完成排序 哈希索引不支持多列联合索引的最左匹配规则 如果有大量重复键值得情况下，哈希索引的效率会很低，因为存在哈希碰撞问题 聚簇索引、覆盖索引

我：InnoDB的B+ Tree可能存储的是整行数据，也有可能是主键的值。

我：（当他问我叶子节点的时候，其实我就猜到他可能要问我聚簇索引和非聚簇索引了）在 InnoDB 里，索引B+Tree的叶子节点存储了整行数据的是主键索引，也被称之为聚簇索引。而索引B+ Tree的叶子节点存储了主键的值的是非主键索引，也被称之为非聚簇索引。

我：聚簇索引查询会更快？

我：因为主键索引树的叶子节点直接就是我们要查询的整行数据了。而非主键索引的叶子节点，是主键的值，查到主键的值以后，还需要再通过主键的值再进行一次查询。

（后来我才知道，原来这个过程叫做回表）是所有情况都是这样的吗？非主键索引一定会查询多次吗？

我：（额、这个问题我回答的不好，后来我自己查资料才知道，通过覆盖索引也可以只查询一次）

覆盖索引（covering index）指一个查询语句的执行只用从索引中就能够取得，不必从数据表中读取。也可以称之为实现了索引覆盖。 当一条查询语句符合覆盖索引条件时，MySQL只需要通过索引就可以返回查询所需要的数据，这样避免了查到索引后再返回表操作，减少I/O提高效率。 如，表covering_index_sample中有一个普通索引

联合索引、最左前缀匹配

我：我们一般对于查询概率比较高，经常作为where条件的字段设置索引

我：用过呀，我们有对一些表中创建过联合索引。

我：我们把识别度最高的字段放到最前面。

我：（这个问题有点把我问蒙了，稍微有些慌乱）这样的话可能命中率会高一点吧。。。

我：（我突然想起来原来面试官是想问这个，怪自己刚刚为什么就没想到这个呢。）哦哦哦。您刚刚问的是这个意思啊，在创建多列索引时，我们根据业务需求，where子句中使用最频繁的一列放在最左边，因为MySQL索引查询会遵循最左前缀匹配的原则，即最左优先，在检索数据时从联合索引的最左边开始匹配。所以当我们创建一个联合索引的时候，如(key1,key2,key3)，相当于创建了（key1）、(key1,key2)和(key1,key2,key3)三个索引，这就是最左匹配原则。

虽然我一开始有点懵，没有联想到最左前缀匹配，但是面试官还是引导了我。很友善。 索引下推、查询优化

我：不好意思，这个我没有去了解过。

如果使用了索引下推技术，则MYSQL首先会返回符合zipcode='95054’的索引，然后根据lastname LIKE '%etrunia%'和address LIKE '%Main Street%'来判断索引是否符合条件。如果符合条件，则根据该索引来定位对应的数据，如果不符合，则直接reject掉。 有了索引下推优化，可以在有like条件查询的情况下，减少回表次数。

我：这个还没有统计过，除非遇到慢SQL的时候我们才会去排查

我：可以通过explain查看sql语句的执行计划，通过执行计划来分析索引使用情况

我：（依稀记得和优化器有关，但是这个问题并没有回答好）

科普时间——查询优化器

一条SQL语句的查询，可以有不同的执行方案，至于最终选择哪种方案，需要通过优化器进行选择，选择执行成本最低的方案。 在一条单表查询语句真正执行之前，MySQL的查询优化器会找出执行该语句所有可能使用的方案，对比之后找出成本最低的方案。这个成本最低的方案就是所谓的执行计划。 优化过程大致如下： 1、根据搜索条件，找出所有可能使用的索引 2、计算全表扫描的代价 3、计算使用不同索引执行查询的代价 4、对比各种执行方案的代价，找出成本最低的那一个

我：(后面关于事务隔离级别的问题了，就不展开了) 感觉是因为我回答的不够好，如果这几个索引问题我都会的话，他还会追问更多，恐怕会被虐的更惨

总结&感悟 以上，就是一次面试中关于索引部分知识的问题以及我整理的答案。感觉这次面试过程中关于索引的知识，自己大概能够回答的内容占70%左右，但是自信完全答对的内容只占50%左右，看来自己索引有关的知识了解的还是不够多。

通过这次面试，发现像阿里这种大厂对于底层知识还是比较看重的，我以前以为关于索引最多也就问一下Hash和B+有什么区别，没想到最后都能问到查询优化器上面。

最后，不管本次面试能不能通过，都非常感谢有这样一次机会，可以让自己看到自己的不足。通过这次面试，我也收获了很多东西。加油！