技术团队开发写SQL的时候,select * 通配符写法应该禁止吗?

和女神嗯嗯
  • 2.6k

技术团队开发写程序的时候,select * 通配符写法应该禁止吗?为什么?

回复
阅读 4.1k
6 个回答
✓ 已被采纳

应该禁止。

原因:

  1. 读取不需要的列会增加CPU、IO、NET消耗。
  2. 不能有效的利用覆盖索引。
  3. 使用SELECT *容易在增加或者删除字段后出现程序BUG。

应该禁止
1、会查询出不必要的字段,CPU cost,IO cost,Cost,宽带消耗都会增加
2、解析字段。数据库需要根据数据字典生成一个语法树,然后根据语法生成执行计划。如果使用select * 数据库需要解析更多的 对象,字段,权限,属性相关,在SQL语句复杂,硬解析较多的情况下,会对数据库造成沉重的负担。(SQL语句软解析时不会有影响)
3、影响数据库自动重写优化SQL

朝野布告
  • 97

大多数情况不提倡,应该禁止;
即使*有时候也是有作用的——表示一行记录,比如:

SELECT COUNT(*) FROM table;

以上代码就没有毛病
但是基于团队情况如果不能严格遵守还是禁止吧
客观的危害/使用可以参考:关于SQL中SELECT *(星号)的危害论

直接取所有的列,在表里有大字段的时候,固然是不好的。道理很明显,就不多说了。
包括其他答主提到的会导致无法用到覆盖索引。

但是,也不是无脑禁止,然后强迫所有人写sql的时候列出所有字段。

我们要思考它的合理性,和在哪些场景下的不适用性。

因为select *造成了性能问题的时候,也是非常容易发现和修复的。

另外还有专表专用,短列和长列垂直分表等方法可以应付。

要限制列的话,也可以在model中注册字段列表,然后使用sql的时候加个排除大字段的语法。

现代开发,都讲究快速原型,避免过早优化。更有一个笑话是说在代码中加一些sleep,当客户提出要优化性能的时候,既能快速优化,又能拿额外的钱。

说到底,就是一个利益取舍,看你是追求快速开发,还是追求避免以后可能的性能问题。

要多思考,权衡其中利弊再决定。

我觉得看情况,当然大多数情况下,肯定不提倡,但是如果所有字段的内容都要呢,话不能说绝对

万一你哪一天在表里加了一个图片字段,之前的select * 会很影响查询速度的
mybatis的话可以定义BASE_COLUMN,但是随着业务增长,真到执行起来的时候还是蛮难得,大家都想偷懒

宣传栏