，但到底怎么设计和优化根据业务的事情这点也和数据库有关，不同类型的数据库的特点不同，所以表设计的方式也不同，大部分开发都不大懂，把ORACLE的表直接照搬到MYSQL（第三方或有些说支持多种数据库的软件公司） ，结果也可想而知。知识的扩展如果懂得数据库种类数量算是横向扩展，那根据业务逻辑来进行表的设计就是纵向发展的一部分，所以希望大家可以帮助，拽人或者加入扩展自己，互相帮助。也十分欢迎开发的同学，we are friend ,help each other.
正文___________________________________________________________________
说到临时表，使用MYSQL的同学可能不是很常用，尤其是互联网领域的，临时表在MYSQL 的主从复制环境中使用临时表本身是有缺陷的（这还的扯到程序当中去，解释起来比较复杂）。今天的主题是Postgresql 的临时表，Postgresql 的临时表本身是事带有隔离性的，与ORACLE 不同的是，PostgreSQL的临时表本身更彻底，在SESSION失效后，表的定义都会消失，ORACLE 则不是，表的定义不会消失。这也是两种数据库在临时表上的区别。
我们可以下载做一个测试，我们开两个窗口
在此之外，我们在开一个窗口
首先证明了每个session 中的临时表都是独立的，在别的SESSION 中是看不到的。
另外PostgreSQL 中的临时表还有一些相关方便的设置，在创建时指定临时表的在什么时候消失或者清理数据。
相关postgresql 可以在 commit 中进行设置例如
代码语言：javascript复制ON COMMIT DELETE ROWS;ON COMMIT DROP;ON COMMIT PRESERVE ROWS;这三种分别代表不同的含义，一个是在SESSION内，如果COMMIT 就直接将临时表中的行删除 ， DROP 是直接commit 后就将表删除，最后是即使commit 也保留表，直到session结束。
另外POSTGRESQL 中的并行扫描，对临时表是无效的。还有一个有意思的事情时，如果你在同一个事务中创建了同名的临时表 和 实体表，则你访问的和操作的都是临时表优先。
另外有一个地方需要讨论的是，临时表在复杂事务中到底帮了我们多少，
临时表可以降低多表进行关联造成的查询复杂性和性能的问题
例如：临时表可以在程序快速调用存储过程中，分解对大表的访问和查询，将中间的结果存储在临时表中，而不是多个大表进行关联，如果我们仅仅需要查询大表中1%的记录，同时可以通过条件来现将大表1%的数据或更少的数据存储在临时表里面，在进行相关的连接，聚合，等操作，会大大减少例如锁等待，死锁，等可能性。
另外和有些数据库不同，PG的临时表会创建在你当前操作的数据库中，并且以t 开头进行命名(这里指的是在临时表的物理存储空间的名字)
所以更好的利用历史表，能让你的例如存储过程，乃至是程序设计都能提升一个层次，当然如果滥用历史表，在不恰当的场景进行使用，则会事倍功半的结果。
