由SELECT *引起的多个生产故障，问题太深了吧？

作者介绍了姜兵，鲍宾技术的创始人，Oracle ACE，11g OCM，他具有多年的Oracle设计，管理和实施经验，精通数据库优化。

在许多SQL审计产品中，几乎总是提到审计规则，选择*，规则描述几乎相同：禁止使用select *，并且必须清楚地选择必需的列。

该规则实际上有许多实际的生产失败案例。

以下是一些更常见的情况：情况1用户反馈说生产环境中有两个SQL语句。

可以确认，差异只是表名（实际参数是相同的），但性能为。

但是存在10倍以上的差距。

通过生成的监控报告，可以发现SQL1执行时间为8s，IO为403MB，如下图所示：SQL2执行时间为2.1m，IO为15GB，如下图所示：根据业务反馈，SQL1中的表是影子表，数据量，表结构和对应的表几乎相同，那么为什么执行时间会有如此大的差异？在此之前，DBA已经在准生产环境中通过DBMS_SHARED_POOL.PURGE重复删除了相应的执行计划，并在更改了参数之后重复了分析，但是未能获得正确的执行计划。

通过对监视报告的分析和比较，可以发现SQL1中的with语句通常已实现，并且执行计划中存在一个临时表转换操作，即TEMP TABLE TRANSFORMATION。

在SQL2中，由于没有临时表转换操作，因此IM_HISMESSAGE表被多次访问，效率低下。

通过再次观察整个SQL操作期间的等待事件，我们可以快速发现SQL慢10倍的原因不是由执行计划引起的（主要的等待事件是直接路径读取，临时表的读写比率）是非常低的，并且没有。

经典的大表用作NL驱动表）。

比较运行数据，可以发现IO增量主要来自IM_HISMESSAGE表的扫描。

影子表的区别通过比较逐行比较数以返回列的详细信息，我们终于找到了答案：原始表有一个LOB字段，影子表没有LOB字段，并且IO的数量要小得多。

同时，由于存在LOB字段，with语句无法执行临时表转换。

SQL文本中的经典选择完美地掩盖了这种差异。

由开发人员轻松编写的select *查询根本不需要的LOB字段，从而导致性能急剧下降。

情况2客户的生产环境的AWR报告中有一个夸大的TOPSQL，占当天DBTIME的84％。

未显示原始SQL。

SQL本身实际上相对简单。

模拟如下：从test_a中选择*，其中object_id = 11;执行计划也非常简单，因此可以很快发现问题。

按索引行访问表的成本相对异常高。

当我检查下表中的统计信息时，我惊讶地发现这是一个包含400多个列的宽表。

当遇到宽桌选择*时，性能将急剧下降。

尽管问题定位很快，但是处理起来却不方便。

毕竟，您需要查找开发并更改SQL，这不是很快。

当然，毫无疑问，系统的性能问题在于SQL代码的质量。

情况3准备环境如下：从dba_objects复制两个表t1和t2作为测试环境表。

准备了两个条件相同的查询，但是主要区别在于，一个查询仅查询单个列，另一个查询所有列。

通过仿真可以发现，在use_merge表连接方​​法的情况下，排序操作的内存消耗有很大的差距。

在使用索引的情况下会出现此间隙，并且在快速对索引进行完全扫描时，指定的查询列也可以命中索引。

被大大放大了。

查询整列，SORT JOIN内存消耗1810K：查询id，SORT JOIN内存消耗424K：如果是HASH JOIN，则联接操作的影响较小，可以更改提示并再次进行测试。

情况4在某些情况下，当SQL查询表具有大量数据和许多查询字段（无法建立索引）时，当数据库将数据返回到网络层时，我们不考虑添加的未使用的列。

数据返回到应用程序。

消耗。

如果您的计算机恰好是EXADATA，则智能扫描还将使select *，并且指定列的查询包含