面试官又问我Select * 为什么效率低下？

Select * 为什么效率低下

​ 无论是在平时的工作中还是面试中，都会遇到不让用Select *的情况，那么到底是什么原因导致其沦落到人人喊打的地步呢/

效率低下的原因

​ 在阿里java开发手册中关于Mysql的部分描述中提到：在表查询中一律不要使用* 作为查询的字段列表，需要用那些字段必须明确写明。原因如下：

• 增加查询分析器解析的成本

• 增减字符容易与resultMap配置不一致

• 无用字段增加网络消耗，尤其是test类型的字段

  那么接下来我们就逐条深入的分析一下

不需要的列会增加数据传输时间和网络开销

• 用“select * ”数据库需要解析更多的对象、字段、权限、属性等相关内容，在sql语句复杂，硬解析比较多的情况下，会对数据库造成沉重的负担
• 增大网络开销，* 有时会误带上诸如log、IconMD5之类无用且大文本字段，数据传输size会呈现几何增长，如果DB和应用程序不在同一台机器上。这种开销会十分明显
• 即使mysql服务器和客户端在同一机器上，使用的协议还是tcp，通信也是需要额外的时间的

对于无用的大字段，如varchar、blob、text，会增加io操作

​ 准确的来说，长度超过728字节的时候，会把超出的数据序列化到另外一个地方，因此读取这条记录会增加一次io操作。（mysql innodb）

失去mysql优化器“覆盖索引”策略优化的可能性

​ select * 杜绝了覆盖索引的可能性，而基于Mysql优化器的“覆盖索引”策略又是速度极快，效率极高、业界极为推荐的查询优化方式

联合索引

​ 联合索引（a,b,c）实际上是建立了(a)、(a,b)、(a,b,c)三个索引

联合索引的优势

• 减少开销

  ​ 建一个联合索引，相当于建立三个索引。由于每多一个索引，都会增加写操作的开销和磁盘空间的开销。对于大量数据的表，使用联合索引会大大减少开销。

• 覆盖索引

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

• 效率高

索引是建的越多越好吗

• 数据量小的表不需要建立索引，建立会增加额外的开销
• 不经常引用的列不需要建立索引，因为不经常使用，及时建立了索引也没多大意义
• 经常频繁更新的列不要建立索引，因为肯定会影响插入或更新的效率
• 数据重复且分布平均的字段，因此他建立索引就没有太大的效果（例如性别字段，只有男女，不适合建立索引）
• 数据变更需要维护索引，意味着索引越多维护成本越高。
• 更多的索引也需要更多的存储空间