避免使用SELECT* 的九个理由及两个例外场景

数据库 其他数据库
本文将从两个角度解释避免使用SELECT *的9个理由,同时讨论2个合理使用SELECT *的例外场景。

我们经常会看到一些文章警告使用SELECT * 是一种错误的习惯,应该明确地指定查询的列名,譬如在最新《阿里java开发手册(泰山版)》中对此做了强制性的规定。而大家对其原因只是一知半解。本文将从两个角度解释避免使用SELECT *的9个理由,同时讨论2个合理使用SELECT *的例外场景。

性能问题

从性能的角度,在应用中使用SELECT *可能会引起查询的性能问题,主要表现在以下六个方面。

  • 增加解析成本:用SELECT *数据库需要解析更多的对象、权限、属性等相关内容,这个影响可能较小,但是它确实会对数据库的元数据查询造成一定的压力。
  • 增加I/O操作,对于无用的大字段,如 VARCHAR、LOB、TEXT类型的字段,会增加 IO操作;数据库一般会把超过一定长度的大字段,存放在单独的表空间中,因此对这些字段的访问会额外地增加一次I/O操作。
  • 增加网络消耗,带上如LOB/TEXT之类的无用的大文本字段,传输数据量会成多倍地增涨,特别是如果数据库和应用程序不在同一台机器,这种开销非常明显。
  • 增加内存消耗,不管您是否使用这些列,您的应用程序都需要把它们接收到内存,这可能会无谓的消耗大量的内存,影响程序的性能及健壮性,甚至造成内存溢出,应用崩溃。
  • 影响索引选择,对于使用SELECT * 的查询语句,优化器会放弃覆盖索引策略优化的可能性,导致需要回表或是全表扫描。
  • 影响索引推荐,PawSQL的索引推荐引擎能够分析SQL的结构,对符合条件的表上创建索引(快速定位、避免排序、避免回表)以提升查询性能,具体请参考《创建高效索引的准则》。对于使用SELECT * 的查询语句,PawSQL将不考虑进行覆盖索引的推荐。

维护代价

从代码维护的角度,在应用中使用SELECT *可能会导致维护变得困难,主要表现在以下三个方面,

代码可读性:使用SELECT * 会降低代码的可读性,这是因为使用SELECT * 会使查询语句不容易理解,开发人员需要查看表定义来确定到底查询的是什么数据,同时也难以进行调试。

列名对齐:

  • 在通过ORM框架开发应用时,增加或是删减字段,容易与 resultMap 配置不一致;
  • 当使用SELECT * 定义视图时,增加或是删减字段,都可能导致视图失效,
  • 您可能会经常使用SELECT * into INSERT . . .之类的语句,以实现将某些数据从一张表复制到另一张表。如果在两张表中,各个列的排列顺序略有不同,那么就可能会出现将不正确的数据复制到错误列中的情况。

列名冲突:如果您在连接查询中使用了SELECT * ,一旦在多个表中出现了具有相同名称的列,就会导致列名冲突;从而导致数据的消费方使用错误。

两个例外情形

SELECT * 并不是任何情况下都不适合使用,我们日常开发中经常使用的合理场景有两类:

即席查询(Ad-hoc Query)

当我们进行数据探索或是问题定位时,我们需要即时的手工写一些SQL来查看某些数据表,我们不知道表有哪些列,这个时候我们可以使用SELECT *来完成我们的查询。我们不会,也不需要预先研究底层列名是什么,我们甚至是通过SELECT *来确定列名和样例数据。特别是当表有大量的列时,SELECT *可以让我们更方便快捷完成数据探索或是问题定位的目标。

当 * 表示一行,而不是代表所有列时

当 * 表示一行,而不是代表所有列时,* 的使用是合理的。

譬如在以下用例中,* 表示符合某个条件的行。如果您使用列名而不是 *,它将计算该列值不为NULL的行数。

SELECT COUNT(*) FROM table

类似的,在下面的这个查询中,* 表示符合关联条件条件的行。

SELECT c_custname FROM customer c WHERE EXISTS ( SELECT * FROM orders o WHERE o.c_custkey = c.c_custkey);

有些人在 SELECT 列表中使用 表orders的主键o.c_custkey,或者使用数字1,但是这些约定基本上是没有意义的。你查询的是符合某个条件的所有行,这就是 * 的含义。对于数据库优化器来说,这两个查询语句实际上是相同的。

PawSQL中与SELECT*相关的优化

PawSQL中与SELECT*相关的审查或优化有三个。

SELECT*审查预警

PawSQL分析用户输入的SQL语句,并对其中出现的非上述例外情况的SELECT*进行提示预警。

  • 对下面的SQL进行预警
select * from customer as c where c.c_acctbal > 100
  • 对下面的SQL不预警,属于例外情况
select c_custname from customer c where EXISTS ( select * from orders o where o.c_custkey = c.c_custkey);

投影下推(Projection Pushdown)

PawSQL中的投影下推重写优化可以把子查询中的SELECT进行重写,删除不必要的SELECT

  • 优化前SQL,子查询中存在SELECT*
select c_nationkey, count(*)
from (select *
from customer as c
where c.c_acctbal > 100)
group by c_nationkey
  • 应用投影下推后
select c_nationkey, count(*)
from (select c_nationkey
from customer as c
where c.c_acctbal > 100)
group by c_nationkey

如果您希望在PawSQL中验证投影下推对于SELECT *的处理逻辑,您需要先禁用查询折叠(Query Folding)重写优化,因为查询折叠会将子查询重写合并。

覆盖索引推荐

如在性能问题章节里所述,对于使用SELECT * 的查询语句,PawSQL索引推荐引擎将不考虑进行覆盖索引的推荐。

关于PawSQL

PawSQL专注数据库性能优化的自动化和智能化,支持MySQL,PostgreSQL,Opengauss等,提供的SQL优化产品包括。

  • PawSQL Cloud,在线自动化SQL优化工具,支持SQL审查,智能查询重写、基于代价的索引推荐,适用于数据库管理员及数据应用开发人员。
  • PawSQL Advisor,IntelliJ 插件, 适用于数据应用开发人员,可以IDEA/DataGrip应用市场通过名称搜索“PawSQL Advisor”安装。
责任编辑:姜华 来源: PawSQL
相关推荐

2021-12-27 10:11:22

加密后门密码学数据安全

2012-04-03 14:27:19

手机

2018-09-04 12:03:31

HBase大数据存储

2022-04-19 10:29:56

外包误区IT外包IT领导者

2022-04-08 16:11:01

物联网

2014-08-01 14:35:33

Linux开源软件

2010-01-14 14:38:47

为什么使用三层交换机

2012-10-11 10:43:26

开发SQL

2023-12-18 10:45:22

SQL开发数据库

2022-08-29 09:06:43

hippo4j动态线程池

2011-03-02 09:34:58

AppFuse

2024-06-24 08:00:00

网络安全WAFWeb应用程序防火墙

2020-06-04 08:15:53

Kubernetes容器PaaS

2024-10-10 08:46:28

2016-07-11 16:03:10

慧点科技

2011-07-31 19:44:43

程序员

2015-12-21 10:05:33

2011-08-01 14:33:44

SQL

2024-11-11 14:23:11

2023-09-14 09:40:22

自动驾驶技术
点赞
收藏

51CTO技术栈公众号