select * from table的弊端

SQL执行的流程

1.客户端发送一条查询给服务器。

2.服务器先检查查询缓存，如果命中了缓存，则立刻返回存储在缓存中的结果。否则进入下一阶段。

3.服务器端进行SQL解析，预处理，再由优化器生成对应的执行计划

4.MySql根据优化器生成的执行计划，调用存储引擎的API执行查询。

5.返回结果给客户端。

问题分析

1，首先数据库需要知道*等于什么，查数据字典（进行数据库设计的时候，对数据库元素进行的解释说明），这在分析阶段就会增大开销。
2，select * from 最大的问题是可能会多出一些不用的列，这就杜绝了索引覆盖的可能性，导致查询的成本几何级增高（索引覆盖：就是select的数据列只用从索引中就能够取得，不必从数据表中读取，换句话说查询列要被所使用的索引覆盖。）
3，网络开销，不需要的字段会增加数据传输的时间，在本地客户端连的是本地mysql服务器，TCP协议传输数据会增加额外的时间；数据量越大这种这种劣势就会越明显；如果db和客户端不在同一台机器，比如链接到阿里云，那这种开销就更加明显
4，从另外一个相似的角度来看；就是查询进行的时候，多取了不必要的列，数据字段比较多，mysql并不是把所有结果全部得到后再进行一次性保存，而是每次分配一块大小的内存空间保存结果集，使用完后，接着再分配一个这样的块，如果还不不够，接着再分配一个块，依此类推，也就是说，有可能在一次查询中mysqI要进行多次内存分配的操作，频繁操作内存都是要耗费时间的。5，mysql拿到一条命令，会去解析命令、优化查询，然后去存储引擎执行查找，Select数据库会解析更多的 对象，字段，权限，属性相关，在 SQL 语句复杂，会对数据库造成沉重的负担。选择了实际不会用到的额外的列，就会导致优化和效率问题。
6，原则上讲作为有着良好编程习惯的程序员，也不应该获取自己不需要的东西，若是执行select，以后表结构修改了，如原表加减了某些列，对代码影响也很大。(源程序就会报错，因为列数不对应。)
7，当然，若是你想在SELECT子句中列出所有的COLUMN时,使用动态SQL列引用 ‘*’ 倒是是一个方便的方法，毫无疑问！对于一次性的查询来说，使用Select *没有任何问题，不过要避免将它作为应用开发代码的一部分。程序员可能在代码中编写SQL来选择数据，并放入宿主变量字段。使用Select *时，必须为表中的每一列分别写一个宿主变量。倘若表少了一列，或者表中增加了一个新列呢？如果发生这种情况，就需要调整源代码。为了避免这种可能性，首先就不要使用Select *。