数据库开发常识（10.6）——考量使用临时表及表连接写法（3）

10.6. 数据库开发常识

10.6.8.  慎用临时表

Oracle中的临时表（Temporary Table），准确的说是Global Temporary Table,很多人也简称为GTT。这年头简称满天飞，没办法，为了理解别人的话，我们必须了解这些简称。创建临时表的语法具体如下所示。

SQL> CREATE GLOBAL TEMPORARY TABLE tmp_tab1 (c1 DATE,c2 DATE,c3 CHAR(20)) ON COMMIT PRESERVE|DELETE ROWS;

--注：

      1）Oracle中的临时表一经创建，其定义就会存储于该Oracle数据库中，除非显式删除，否则该临时表的定义会一直存在于该Oracle数据库中。

      2）根据创建临时表时的选项，临时表中的数据在事务结束(Delete)或会话结束(Preserve)时会自动清除。

      3）我们可以象操作常规表一样操作临时表，也可以为其建立索引，运行SQL语句时优化器也会选择使用这些索引。但在Oracle 11g及以下的版本中，因为临时表本身的特性及数据的不稳定性，优化器很难保证会为用到该临时表的SQL语句生成精确、理想的执行计划，所以，用它来存储和操作大量数据，一般是不推荐的，也容易导致性能问题。

      4）需要记住的是：任何人都没说过Oracle中的临时表是内存表，也不可能将其全部、长久的保存在内存中。这一点，很多人存在误解，因此，经常会看到很多人用Oracle中的临时表来进行性能优化，其结果是事与愿违，越优化性能越差。

      5）Oracle中的临时表，从某种程度讲，它更是一种功能性的对象，而非用于优化性能，其功能就是实现了会话间或事务间的数据隔离和数据的自动清除。当然，在某些场景下，如果清楚其特性和机制，且能合理使用，也可以用作一种提升性能的手段和途径。

      6）Oracle中的临时表，其典型的应用场景就是：临时或中间数据不需要永久保存；数据量少（例如：10万行以下，但不绝对，只是经验值而已）；数据列少（例如：主键列），但各会话间的这些临时数据需要相互隔离。

      7）2010年，某大型企业某核心应用模块，因存在严重性能问题影响用户正常使用。本人通过分析，确定该应用模块中，因当时开发人员临时表应用不当，导致该性能问题，本人纠正和排除临时表不当因素后，该应用模块性能从原来的400s提升至2s内。

      8）大家思考下，Oracle中临时表中的数据存储在什么地方？空间分配和管理又是按照什么方式？

      9）大家思考下，当访问Oracle中临时表中的数据时，最可能以什么路径访问？理由是什么？

10.6.9. 表连接写法选择和排序

准确的说，脱离具体场景来评论表间各种连接写法孰优孰劣，是不准确或不正确的，首先，因为每种连接写法都有各自的适用场景；其次，非常重要的一点，前面我们也不止一次的讲过了，现在所有关系库最新版本的优化器几乎都是CBO（见本专栏6.1节），优化器硬解析用户发出的SQL语句时，经常会对其进行同语义的改写和转换，并最终在多个候选执行计划中选出一个它认为最优的，因此，SQL语句的具体写法并不能完全决定其最终的执行计划，这样，具体采用哪种表连接写法也就没那么重要了。

如果大家非要在这里给各种连接写法做个排序（因为，现实中经常被追问类似问题），那本人也斗胆满足下各位的愿望，但必须说明，这个排序是以大数据量业务和不出现极端性能问题为前提和目标的，并且，也并不保证这个排序的正确性。确切的说，本人只是想通过这个排序，来启发大家对SQL调优原理和机制的更多思考。这里，本人“斗胆”给出的“未必正确的”连接写法选择和排序“原则”如下所示。

能用join的，不要用in和not in子查询；能用in子查询的，不要用exists相关子查询；能用not exists相关子查询的，不要用not in子查询。

当然，这些都是一般经验性的常识，仅用于帮助大家加深理解，并不是放之四海而皆准的真理和定律。因此，现实工作中，还要具体问题具体分析，认真阅读和分析SQL语句的执行计划才是最重要的。

--注：

      1）这里各种连接写法选择和排序的根本原因或依据是什么？

      2）这里仅仅是一般经验性的常识，仅用于帮助大家加深理解，并非真理和定律。例如：有时exists比in性能更好。