共计 899 个字符，预计需要花费 3 分钟才能阅读完成。
为什么不倡议用select *？
不要应用 SELECT * 简直曾经成为了 MySQL 应用的一条清规戒律，然而到底是为什么呢？
个人感觉间接应用 SELECT * 还是比拟多的，起因有两个：
（1）简略，前期增加或批改字段，SQL 语句也不需过多调整
（2）没必要过早对 SQL 进行优化，遇到问题再调呗
不过还是要明确为什么不倡议用select *！
不必要的磁盘 I /O
MySQL 实质上是将用户记录存储在磁盘上，查问操作就是一种进行磁盘 IO 的行为。
查问的字段越多，阐明要读取的内容也就越多，因而会增大磁盘 IO 开销，尤其是当某些字段是 TEXT、MEDIUMTEXT或者BLOB 等类型。
对于无用的大字段，如 varchar、blob、text，会减少 IO 操作，精确来说，长度超过 728 字节 的时候，会先把超出的数据序列化到另外一个中央，因而读取这条记录会减少一次 IO 操作。
减少数据传输工夫和网络开销
总结如下 三点：
- 用
SELECT *数据库须要解析更多的对象、字段、权限、属性等相干内容，在 SQL 语句简单，硬解析较多的状况下，会对数据库造成惨重的累赘。 - 增大网络开销；
*有时会误带上如 log、IconMD5 之类的无用且大文本字段，数据传输 size 会几何增涨。如果 DB 和应用程序不在同一台机器，这种开销非常明显 - 即便 MySQL 服务器和客户端是在同一台机器上，应用的协定还是 TCP，通信也是须要额定的工夫。
无奈应用笼罩索引
SELECT * 杜绝了笼罩索引的可能性，而基于 MySQL 优化器的“笼罩索引”策略又是速度极快，效率极高，业界极为举荐的查问优化形式。
例如，有一个表为 t（a，b，c，d，e，f），其中，a 为主键，b 列有索引。在磁盘上有两棵 B+ 树，即汇集索引和辅助索引（包含单列索引、联结索引），别离保留（a，b，c，d，e，f）和（a，b）。
如果查问条件中 where 条件可通过 b 列的索引过滤一部分记录，查问就会先走辅助索引；如果用户只须要 a 列和 b 列的数据，间接通过辅助索引即可。
如果用户应用 SELECT *，获取了不须要的数据，则首先通过辅助索引过滤数据，而后再通过汇集索引获取所有的列，这就多了一次 B+ 树查问，速度就会慢。
本文由 mdnice 多平台公布