标题：“选择查询”构件的必须改进之处

我们做的一个应用系统投入使用后一直很稳定，但最近用户突然反映，进入数据查询时，竟然需要好几分钟！这也太恐怖了！

于是我们询问原因。用户反映说，他们最近把以前几年的数据都已经追加到数据库，总量已达几十万条！

难道是数据量增大导致的原因？我们重新分析了一下，也没问题：因为整个的系统查询都是用的ADO，用户初始进入时，还特别使用1=2这样的限制条件使查询结果为空，数据量再大也不会影响到速度的。

再进一步分析发现，系统使用了“选择查询”构件，而这个构件所指定的就是总量达几十万条的那个数据表。把这个构件删除，重新运行，OK，速度很快，运行正常！看来问题就出在“选择查询”这个构件上了。

我们在数据库应用中，是从来不用“数据表”的，因为它在打开时调出的是全部记录，在数据记录很大时速度非常之慢。而“选择查询”这个构件连接的源头是“数据表”，输出的结果是“ADO查询”，只要你在项目中使用了这个构件，在项目加载时肯定要先打开该构件所指定的数据表。如果该数据表记录巨大，项目加载时肯定也会非常非常的慢。

因此，“选择查询”构件必须改进，否则，在几十、上百万条的大型数据库查询中，这个构件将根本无法使用。