临时表的性能问题

我们公司的产品线上使用了一张global temporary table with commit delete rows. 最近系统某些查询速度有点慢, DBA怀疑是temporary table导致的.给出的理由是: 当高峰时间, 由于大量的客气端同时往临时表里插入记录,使得临时表记录数变得很大(可能达到10w或100w). 尽管临时表有index, 但是由于 oracle无法获得统计信息,从而不能得到有效的执行计划.  所以只能使用全表扫描.这样性能就变慢了.

今天上午我对临时表做了一些性能测试, 感觉DBA的认识有些不对. 例如如果同时100个线程往临时表里插入记录, 事实上, oracle会为这个临时表分配100个segment, 当第101个人查询临时表的时候, oracle只查询为第101个连接所分配的segment,并不查询为其他连接生成的segment. 所以无论其他连接插入了多少数据, 都不会影响第101连接的查询速度.
请问一下上面的结论对吗?

接着我们来考虑另外一个问题, 在产品线上, 因为我们使用的是连接池. 假设为当前DB建了10个长连接, 现在有100个人来访问这个DB. 每个人都往临时表里插入10条记录, 请问,这个时候临时表会有100条记录, 还是会有1000条记录呢? 我觉得是100, 因为每个长连接在某一时刻只可能有一个人获得, 当这个人释放了这个长连接之后, 下一个人才可能获得长连接. 所以同时临时表里最多只会有100条记录..

这种认识对吗?

我同意你的说法，你们的DBA认识肯定是错的。临时表只有当前会话才能看到，根本不看不到其它会话的数据。

关于第二个问题，你的数据库连接方式是什么？是专用的还是共享的？

ORACLE临时表的特点是，只对当前会话有效。

对于你说的，但所以无论其他连接插入了多少数据, 都不会影响第101连接的查询速度。这话很含糊，准确讲，应该是
都不会影响第101连接的数据。 但若使用系统的人多的，不论是否用上临时表，效率都会下降。

另外一个问题，用了连接池，再用临时表，很可能会影响应用。因为往临时表里插入数据，和下一次要从临时表里读
数据的，很可能不是同一个会话，此时，将看不到先前插入数据的临时表。