5.确定使用临时表的时机。
这是一个比较难以处理的问题，但是你可以从这里得到很多好处。很多情况下，都是可以使用临时表的，比如：在避免两次从一个大型表格里查询时。在连接两个表格的时候，你也可以使用临时表来大大降低处理程序所占用的内存。如果你必须把一个表合并到一个大型表格中，你可以通过先从大型表中检索出你所需要的数据合并到临时表中，然后用把这些数据合并的方法来优化命令。如果在进程中，你必须对同一个表进行同样的合并的时候，临时表是一个非常有用的方式。
6.必须预存数据。
这是我比较喜欢的一个话题，因为这是一个比较容易被忽略的老方法。如果你有一个报告或者一个进程，它们需要向一个大型表里做类型的合并，这时，如果你能通过提前合并表格或者是插入表格的方法来预存数据，这将对你的操作大大有益。
一般情况下，你是不能使用这个技巧的。但是，如果你可以，你会发现这将是一个非常完美的节约服务器资源的方法。
注意到这样的问题，一般开发者通过关注查询本身而避开这样的合并问题，创建一个只可见的合并，以致于不能一而再，再而三地定义它们的合并环境。通过预存数据，你只需执行一次合并，同时别人也避免了大型的合并。我非常喜欢用这种方法，大多数情况下，有很多流行表总是执行合并，所以没有任何理由说不能预存数据。
7，分批地删除和更新。
还有一个常被忽略的简单技巧。如果你的操作错误，从一个大型表里删除和更新大量的数据将是一个噩梦。问题是这两个命令执行起来就像是一个命令，如果你需要放弃他们，或者如果你在工作的时候系统发生了什么事情，系统就必须从头开始所有命令的执行。这会花费很多时间。这些操作也会妨碍别的命令的执行，甚至会成为整个系统的瓶颈。
解决这个问题的办法是，小批量地删除和更新数据。可以通过两种方式来解决这个问题：一，如果命令的执行因为任何原因被终止，那就必须有一小部分行从头开始执行，所以数据库恢复得将会快得多。二，当更少的数据被存在了硬盘上时，别的命令也可以做一些工作，所以并发性就被大大地优化了。
按照这个指示，很多开发者企图在一天之内把这些删除和更新操作完成。但是，这并不是总是正确的，特别是当你在存档的时候。只要你需要，你可以尽可能地扩展这些炒作，而且这些小批量的数据也可以帮助你完成这些。如果你可以花费更多的时间来做更多的操作，那么就花费一些多余的时间吧，同时不要让你的系统停下来。
享受更快的SQL。
当你写代码来优化你的SQL性能的时候，在任何你可以遵守这些事项的时候，就去遵守它们。但是，请分别评价这些解决方法来看看哪种方法是最有效的，可以说没有一个万能的或者是固定的方法来解决这些问题。你将会发现很多窍门都是和ikyi提高并发性，并可以让整体运行通畅的。同时，你也会注意到这些物理实现会从这个供应商传递到下一个供应商，这些概念和问题将会存在每一个SQL平台上。
