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