MySQL--为什么不要使用 select * from

前言

每一个技术经理，都会要求项目组成员不要使用 select * from，那么使用 select * from 会有什么问题呢？

select * from 带来的问题？

• 覆盖索引直接无法使用。
• 增加查询分析器解析成本。
• 增减字段，容易与resultMap 配置不一致。
• 无用字段增加网络消耗、磁盘IO开销。

第一条是我自己加上去的，后面是三条是引用 阿里巴巴Java开发手册，如下：

【强制】在表查询中，一律不要使用 * 作为查询的字段列表，需要哪些字段必须明确写明。 说明： 1） 增加查询分析器解析成本。 2） 增减字段容易与 resultMap 配置不一致。 3）无用字段增加网络消耗，尤其是 text 类型的字段。

select * from 无法使用覆盖索引，那我直接全表字段建立索引不就完了吗？

真的是这样吗，给全表字段建立联合索引，在真实开发场景中99.99%是不允许这么做的，索引的维护成本也是很高的，修改数据的时候，索引也需要维护，如果乱七八糟的索引一堆，那索引的维护成本将会很可怕。

关于MySQL索引介绍，传送门：
MySQL–索引类型详解

增加查询分析器解析成本：
所谓分析成本，就是MySQL去分析解析SQL语法的成本，分析器会帮你进行语法判断、字段判断等，帮你填充SQL，使用 select * from 会获取更多的字段，确实会增加分析器成本。

增减字段，容易与resultMap 配置不一致：

这个属于开发习惯问题，可以在开发层面上规避。

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

SQL查询操作其实就从磁盘上把数据读取到内存中，再返回给客户端，设计到磁盘IO，网络传输，毋庸置疑多余的字段确实会增加开销，我们要主要 text 这类字段，因为这类字段可以存储长文本信息，但是又不是每个场合都需要，这种长文本本身占据的空间也大，这样就很消耗性能了。

总结：拒绝偷懒，慎用select *，在数据量级小的场景，可能你觉得没有什么区别，一旦到了到了一定的数据量级，一个小小的SQL优化会带来意向不到的效果，同时一个小小的不注意，也会带来意向不到的事故，我们写 SQL 时候，要有工匠精神。

如有不正确的地方请各位指出纠正。