数据库优化方案

materoalized view  物化视图 作为非规范化设计的一种手段,

首先，应学会充分利用简单、传统的技术。

只有完全掌握了这些技术，才能正确评价它们的局限性，最终发现它相当于新技术的潜在优势

1 总结：先打基础，再赶时髦：摆弄新工具之前，先把手艺学好

临时表的索引（如果有的话）可能不是最优的，因此，查询临时表的

语句效率比永久表的差

：暂时工作表意味着以不太合理的方式存储更多信息。

将一次“大批量数据的处理”分割成多次“小块处理”是个坏主意，除非对数据库的修改太昂贵，

否则不要使用，因为这种方法极其低效

几千个语句，借助游标（cursor）不断循环，很慢。换成几个语句，处理同样的数据，

还是较慢。换成一个语句，解决上述问题，最好。

避免:

过程逻辑（procedural logic）”

优化器（cost-based optimizer，CBO）

然而，过程逻辑及其之后的处理相同数据的语句，可以编写到一

个单独的SQL 语句中，CBO 就是这么做的，从而获得最高效的执行方式。

总结：在合理范围内，利用每次数据库访问完成尽量多的工作。

如要使用函数，始终应首选DBMS自带的函数。这不仅仅是为了避免无谓的重复劳动，还因为

自带函数在执行时比任何第三方开发的代码更接近数据库核心，相应地其效率也会高出许多。

总之，统计记录数极可能意味着重复全部搜索，因为它对相同数据处理了两次

总结：没必要编程实现那些数据库隐含实现的功

SQL不需要循环能力，因为它

本质上是在操作集合，SQL只需要执行条件逻辑的能力

总结：有可能的话，用一个语句处理多个更新；尽量减少对同一个表的重复访问。

可以仅对代码中非共用的表（本例中即E1和

E2）使用union，然后配合筛选条件，把union 语句降级为内嵌视图。

你可以过滤分了组的字段，也可以过滤聚合（aggregate）结果（例如检查count() 的结果

是否小于某阈值），或者同时过滤两者；SQL 允许在having 子句中使用这类条件，但应该在

group by 完成后才进行过滤（比如排序之后再进行聚合操作）

总结：尽早过滤掉不需要的数据

总结：当查询的结果集很大时，索引未必必要。