我有一个概念，调用查询中的查询比从数据库中的查询更快，因为速度减慢是在cf和数据库之间的通信中。这是真的吗。
这是否意味着循环中的QoQ是可接受的，而循环中的查询则不是。
完整的DBMS经过高度优化，可以处理[适当编写]的查询，在现代网络上，开销不会很大。
QoQ是使用嵌入式数据库执行的，根据执行的查询类型，嵌入式数据库可能优化得很好，也可能优化得不好。
因此，如果数据库在不同的机器上，通过慢速网络，那么在某些情况下，QoQ可能不那么慢。如果您正在访问数据库，理想情况下，您希望在一个请求中适当地处理所有内容，并避免往返和循环中的重新处理。
当然，QoQ的一大好处是，您可以使用它来处理非来自数据库的数据，例如cfdirectory的结果或已转换为查询的CSV文件。
ColdFusion通过手动解析SQL，然后在记录集中循环来执行QoQ。这使得它对于简单的操作(例如具有匹配键的两个表联接)效率很高，但对于复杂的组合(其中联接使用多列和/或不是直接的a=b比较)效率较低。(此处为简要信息。)
Railo使用H2。H2声称速度很快，他们的网站提供了一些速度比较，表明它比Derby和MySQL更快，但当然最好寻找独立的第三方测试，更不用说这些测试并不能保证QoQ性能(例如，我怀疑它不会有索引)。
一般来说：在没有首先进行性能测试的情况下，不要做出任何艰难的决定以确定您实际上需要提高性能，并能够客观地确定哪种方法实际上更快。
这取决于与数据库服务器相比Coldfusion机器的功能，以及您试图解决的问题。
对于小型数据集，QofQ通常会非常快，因为它都发生在服务器内存中。但是，如果您尝试在大型数据集上使用QofQ，则由于在内存中保存和处理数据所涉及的开销，您的服务器将开始出现问题。
数据库查询在大型数据集上通常会优于QofQ，因为这就是它们的设计目的。数据库擅长快速处理大量数据。为此使用它们。
如果你正在考虑从数据库中检索一个大的结果集，并使用QofQ对其进行解析，那么这可能是错误的做法。相反，让数据库为你减少结果。如果您经常向数据库服务器询问这些信息，请将其缓存在服务器上。
请记住，这都是主观的，在很大程度上取决于您的特定问题、负载、数据库和服务器功能。
我发现使用q OF q比从查询中提取DB要快得多。
例如，我虔诚地在销售报告中使用QoQ。我有一份第一季度日期范围的销售报告，可能会显示销售代理的销售数据，也可能显示销售产品的销售数据。
在我的数据库中，相同的表/字段将用于出现在同一报表上的两个部分。
我在主表中查询基于日期范围的数据，然后查询这些结果来构建报告的每个部分。
我发现这种方法在使用DB本地和远程的服务器上都更快。
使用QofQ 的次数
- 如果您有两个数据源，并且由于各种原因，您可以使用链接服务器
- 当数据通过WDDX或JSON传入时，您必须执行联接
- 当在缓存查询中存储数据并对缓存查询执行QofQ是可行的时
- 当您必须将directoryList()的结果与数据库连接时
不使用QofQ 的次数
- 何时可以将数据加载到结构中
- 进行大量迭代时
- 当其中一个源数据集非常大时
- 当您需要执行左、右或外联接时
有关更多详细信息，请参阅
http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec0e4fd-7ff0.html
这是针对CF 9的，但自CF 6 以来QofQ一直大致相同
老兄！刚刚用过cachedwithin。