到底为什么不建议使用SELECT ？

• 因为总有一些毒瘤公司以为自己公司的程序员比Oracle的程序员更牛逼；
• 因为总有一些毒瘤程序员以为自己查询慢的原因在于索引覆盖这种特性，而不是自己的SQL太垃圾，表结构业务设计的太恶心；
• 因为总有一些公司，以为自己的体量自己的数据量已经达到了Select全部字段就会崩的地步；

不信你回忆一下不让你用SELECT*的都是什么人？
某某大厂的技术指南；
某某互联网老兵的经验之谈；
公司某某前辈吹水的资本；
我就从来没有见过有MySQL或者Oracle或者SqlServer说是这个东西不推荐你使用的说法。甚至MyBatis，SpringDataJpa相关标准我也没有见过说是不建议使用Select *的。

综合性价比考虑，在性能劣化到来之前，引入select明确的列名的成本可能更不划算。
随着业务的增加，列不断增多，一般都会在某个阶段将整个数据整体pb/thrift/avro打包存入。或者整体数据都会挪到类似于Tair之类的地方。原本的用db索引查询的部分保留（只会保留少数几列），或者直接引入ES。这种优化可不仅仅是select的写法那么简单的问题了。

此外还有一个场景是数据迁移，从一个IDC把数据一批批读取出来传给另外一个IDC。如果不能用binlog，一定要select，不写select *怕是要死人。当然你说SRE牛逼，自动根据数据打标写了codegen产生出select a,b,c,……能做到一列不差。我只能说大写的牛。

但其它一些场景不太适合这样做，比方说一个数仓的大宽表（当然啦，数仓一般也不会是MySQL这/PG这种东西，而是Hive，ClickHouse等等），几十上百列。倒不是说select * 会让查询变的慢，而是因为数仓都是按照列来给权限的，select * 很容易被拦截。

所以犯不着教条，实事求是，追求ROI就好。