这几天看了《SQL语言艺术》一书,对其中提到的数据库开发过程中应该关注的问题进行一下总结:
1.查询的识别:
尽管许多产品提供良好的监控工具,但要确定一小段S QL 语句与整个系统的关系,有时却非常困难。因此,要养成为程序和关键模块加注释的习惯,在S QL 中插入注释有助于辨别查询在程序中的位置。例如:
/*CU S T O ME R RE G I S T RA T I O N*/se le ct b la h...
这些注释在查错时非常有用。另外,注释也有助于判断单独应用对服务器造成的负载有多大.
2.保持数据库连接稳定:
建立一个新的数据库连接,既快又方便,但这其中往往掩藏着重复建立数据库连接带来的巨大开销。所以,管理数据库连接必须非常小心。允许多重连接——可能就藏在你的应用中——的后果可能很严重.
提升性能可以基于以下方面进行提高:
第一个原因,也是最大的原因,在于
数据库连接是很“重”的操作,消耗资源很多。在常见的客户/服务器模式中(现在仍广为使用),简单的连接操作背后潜藏着如下事实:首,先客户端与远程服务器的监听程序(l is t e n e r p ro gr a m)建立联系;接着,监听程序要么创建一个进程或线程来执行数据库核心程序,要么直接或间接地把客户请求传递给已存在的服务器进,程这取决于此服务器是否为共享服务器。
除了这些系统操作(创建进程或线程并开始执行)之外,数据库系统还必须为每次se ss io n建立新环境,以跟踪它的行为。建立新s e ss i o n前,DB MS 还要检查密码是否与保存的加密的账户密码相符。或许,DB MS 还要执行登录触发器(lo go n t ri gg e r),还要初始化存储过程和程序包(如果它们是第一次被调用)。上面这些还不包括客户端进程和服务器进程要之间完成的握手协议。正因为如此,连接池(co n n e ct io n po o li n g)等保持永久数据库连接的技术对性能才如此重要。
第二个原因,你的
程序(甚至包括存储过程)和数据库之间的交互也有开销。
即使数据库连结已经建立且仍未中断,程序和DB M S核心之间的上下文切换(c o n t e xt sw i t ch )也有代价。因此,如果DB M S支持数据通过数组传递,应毫不犹豫地使用它。
3.战略优先于战术
想要获得上述的大幅提高性能,无需特别技能,仅要求站在局外思考(t h i nk o u t s i d e t h e bo x)的能力。之前两次优化因“太关注问题本身”而收到了干扰。我们需要大胆的思维,站得远一些,试着从大局的角度看待问题。
4.先定义问题,再解决问题
所有技术方案,都只是我们达到目标的手段。没有经验的开发者误把新技术本身当成了目标。对于热衷于技术、过于看重技术的人来说,此问题就更为严重。
5.直接操作实际数据
许多开发者喜欢建立临时工作表(t e m p or a r y w o rk t ab l e),把后续处理使用的大量数据放入其,中
然后开始“正式”工作。这种方法广受质疑,反映了“跳出业务流程细节考虑问题”的能力不足。记住,永久表(p e rm an e n t t ab l e)可以设置非常复杂的存储选项,而临时表不能。