SELECT * 效率低，面试官：为什么

你在学习数据库相关的知识吗？本文《SELECT * 效率低，面试官：为什么》，主要介绍的内容就涉及到MySQL、面试、MySQL优化、经验，如果你想提升自己的开发能力，就不要错过这篇文章，大家要知道编程理论基础和实战操作都是不可或缺的哦！

为什么大家都说SELECT * 效率低

面试官：“小陈，说一下你常用的SQL优化方式吧。”

陈小哈：“那很多啊，比如不要用SELECT *，查询效率低。巴拉巴拉...”

面试官：“为什么不要用SELECT * ？它在哪些情况下效率低呢？”
陈小哈：“SELECT * 它好像比写指定列名多一次全表查询吧，还多查了一些无用的字段。”

面试官：“嗯...”
陈小哈：“emmm~ 没了”

陈小哈：“....??（几个意思）”

面试官：“嗯...好，那你还有什么要问我的么？”
陈小哈：“我问你个锤子，把老子简历还我！”

废话不多说，本文带你深入了解一下"SELECT * "效率低的原因及场景。

本文很干！请自备茶水，没时间看记得先收藏 -- 来自一位被技术经理毒打多年的程序员的忠告

一、效率低的原因

先看一下最新《阿里java开发手册（泰山版）》中 MySQL 部分描述：

4 - 1.

SELECT a,b,c from table where a='xx' and b = 'xx';

那么 MySQL 可以直接通过遍历索引取得数据，而无需回表，这减少了很多的随机 io 操作。减少 io 操作，特别是随机 io 其实是 DBA 主要的优化策略。所以，在真正的实际应用中，覆盖索引是主要的提升性能的优化手段之一。

3）效率高

索引列多，通过联合索引筛选出的数据越少。比如有 1000W 条数据的表，有如下SQL:

select col1,col2,col3 from table where col1=1 and col2=2 and col3=3;
假设：假设每个条件可以筛选出 10% 的数据。
A. 如果只有单列索引，那么通过该索引能筛选出 1000W10%=100w 条数据，然后再回表从 100w 条数据中找到符合 col2=2 and col3= 3 的数据，然后再排序，再分页，以此类推（递归）；
B. 如果是（col1,col2,col3）联合索引，通过三列索引筛选出 1000w10% 10% *10%=1w，效率提升可想而知！

索引是建的越多越好吗

答案自然是否定的

数据量小的表不需要建立索引，建立会增加额外的索引开销

不经常引用的列不要建立索引，因为不常用，即使建立了索引也没有多大意义

经常频繁更新的列不要建立索引，因为肯定会影响插入或更新的效率

数据重复且分布平均的字段，因此他建立索引就没有太大的效果（例如性别字段，只有男女，不适合建立索引）

数据变更需要维护索引，意味着索引越多维护成本越高。

更多的索引也需要更多的存储空间

三、心得体会

相信能看到这里这老铁要么是对MySQL有着一腔热血的，要么就是喜欢滚鼠标的。来了就是缘分，如果从本文学到了东西，请不要吝啬手中的赞哦，拒绝白嫖~

有朋友问我，你对SQL规范那么上心，平时你写代码不会用SELECT * 吧？

咋可能啊，天天用。。代码里也在用（一脸羞愧），其实我们的项目普遍很小，数据量也上不去，性能上还没有遇到瓶颈，所以比较放纵。

写本篇文章主要是这个知识点网上总结的很少很散，也不规范，算是给自己也是给大家总结一份比较详细的，值得记一下的。以后给面试官说完让他没法找你茬

顺便吹波牛B，谢谢各位。

微信搜索：【Java小咖秀】更多精彩等着您~

回复手册获取博主15万字Java面试通关手册&1.4万字Linux命令实战书册~

文中关于mysql的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《SELECT * 效率低，面试官：为什么》文章吧，也可关注golang学习网公众号了解相关技术文章。