最大程度地提升Delphi/C++Builder/InterBase 应用的性能
大会演讲稿
摘要本文提供了一些建议和技巧用来帮助读者提升Delphi/C++ Builder/InterBase 系统的性能
本文来自于MER 系统公司Robert Schieck 在第12 届Borland 开发大会上的讲话稿。Robert Schieck 是MER 系统公司的总裁MER 系统公司位于加拿大主要提供定制的C/S软件开发以培训Robert 是Borland 认证的Delphi/C++Builder/JBuilder教员,也是TeamB成员之一CNE Certified Netware Engineer 以及多伦多Delphi 用户组的创始人和前总裁。Robert 毕业于加拿大多伦多大学并获机械工程学士学位，MER 系统的站点http://www.mers.com 是InterBase 列表和新闻组的服务器包含了世界上最多的公共InterBase信息
注意：未经译者同意不得以任何方式转载使用本文的任何部分，译者已获得Borland 公司认可进行本文的翻译工作及使用本文的权利
简介
1) 在创建前端应用前数据库中要有充分多的数据
2) 使用SQL Monitor 来帮助你了解你的前端应用向IB 发出的请求
3) 在BDE 与直接存取控件如IBX 之间速度差异只有40%
4) 避免长时间地使一个事务处于开放状态
5) 不要使用大的Varchar
6) 建立前端应用时总是要使用远程连接
7) 数据库应该使用2Kb 或4Kb 的页面大小
8) 只用Gfix 来设置你数据库的缓存空间
9) 如果查询包括动词like 就不要使用参数
10) 我不使用主键和外键
11) 将查询参数化并预准备prepare 将获得最佳性能
12) 运行IB 服务器的机器应该是单处理器系统
13) 关于Left Outer Join 的我的规则
14) 避免使用返回所有记录的操作
15) 对于大系统很多用户需要缓存你的查找表lookup table 以提高速度
16) 追求速度时关闭Async Writes 但有风险
总结
简介
Delphi 和BCB 真是美妙的工具开发者，即使没有或只有很少数据库的经验也可以通过拖拉控件并将控件进行连接而开发数据库应用程序。对于没有经验的开发人员来说很容易开发小型的数据库系统，而且可以工作得很好。不幸的是随着用户的增加，数据库的尺寸越来越大，开发人员就需要更深入地了解Delphi/BCB 如何与IB 交互的原理，才能创建可以运行的系统。本文将提供一些建议和技巧帮助你的Delphi/BCB/IB 系统达到更好的性能。
1) 在创建前端应用前数据库中要有充分多的数据
大部分开发者从来不做这个，他们所做的是创建需要的元数据创建表和索引，每个表里放上六个记录，然后就开始创建应用。
我们都会犯错误，如果每个表中只有六个记录，那么在开发阶段你就无法知道是不是有了错误。因为不管用什么方法从数据库里提取六个记录总是非常快的，反过来说，如果在你的客户数据库里有了几十万个记录，而在开发过程中你发现查找一个客户需要15 秒钟，那你立刻就知道肯定有问题需要纠正了。
这种情形有点类似吃饭时先吃后付还是先付后吃，如果在开始开发之前你的数据库中已经有了足够的数据，你将可以在开发过程中发现错误和问题。或者你可以在表格中只放上六个记录，然后在实际应用中发现错误而此时你的应用可能已经非常繁忙了。
2) 使用SQL Monitor 来帮助你了解你的前端应用向IB 发出的请求。
授人以鱼未若授人以渔，SQL Monitor 就是你进行数据库开发的钓鱼杆。它可以让你监测到客户端与服务器之间的对话。SQL Monitor 可以让你比较应用程序的更改是如何影响应用与服务器之间的对话，也可以让你比较不同的控件集合访问服务器的不同之处。
使用BDE SQL Monitor 时我经常使用这些选项
l Connect/Disconnect 该选项显示与数据库的连接何时建立，你可以用它来检查你是否用了多个连接来连接到数据库，或者应用程序是否频繁地打开和关闭数据库连接。
l Prepare Query 语句该选项可以让你监测你的查询被准备的频繁程度，如果应用构造得当查询将只准备一次而多次使用，从而减少客户到服务器端的流量。
l Execute Query 语句监测送到服务器端的SQL 查询
l 语句操作监测从服务器返回的记录每个Fetch 语句表示从服务器那里取回了一行即一个记录
l 事务监测你的应用向数据库确认数据的频率
在SQL Monitor 上花点时间你会更好地了解Delphi/BCB 如何与IB 交互从而构造高度优化的应用
3) 在BDE 与直接存取控件如IBX 之间速度差异只有40%
提升应用性能的一个方法是使用直接存取控件如IBX，总体而言你将会看到性能提高了大约40%。 另外对于IB 内部的一些功能也有更好的利用，
不过得到速度与功能的同时，你牺牲了移植性。如果你计划将应用与IB 与其它SQL服务器工作，那么使用直接存取控件将显著地增加你转换的代价。请记住SQL 里的S 是指结构化structured 而不是标准standard 即使你的应用使用了BDE ，而你希望支持Oracle， 那么你也许不得不重新书写所有的SQL 语句来获得Oracle 环境下可以接受的性能。
4) 避免长时间地使一个事务处于开放状态
在新闻组中你经常听到建议说要获得高效率就不要使一个事务长时间地处于开放状态，问题是从来没有确切地说过长时间到底应该算是多长。事务本身的执行时间并不那么重要, 因为这取决于事务要完成的内容，考虑两种情况你把一个事务处于开放状态一天但什么也不做，把事务处于开放一天然后每一分半种就运行一个查询相比而言, 后者所带来的后果更严重前者将使IB 不能进行垃圾搜集，后者也将如此。而更严重的是它将使IB 分配越来越多的内存来跟踪事务的进展，而这将使性能大大降低。例如一家公司早上打开应用程序服务器端的IB， 将使用大概180-200 兆的内存, 由于事务在一天内都处于开放状态，而选择查询也在该事务下运行一天结束时IB 将使用大概950 兆内存。性能上的差异在进行备份时显得十分明显，如果IB 使用950 兆内存备份需要一个小时，而如果你关闭IB 然后重新启动IB 以释放所有的内存备份只需要6 分钟, 因此只是将事务开放几分钟不会引起什么大问题，但是如果将一个事务开放一整天,并且在该事务下还运行很多很多查询那问题就严重了。
5) 不要使用大的Varchar
InterBase 内部存储char 和varchar 的方式完全一致，在外看来char 类型的数据返回到程序时将有补白以填满字段的长度，而varchar 类型的数据则没有这种补白，但是大多数人没有意识到在网络上传递char 和varchar 时IB 的处理方法是一样的它们都会被补白。