Question

我有这个查询

var temp = from x in ActiveRecordLinq.AsQueryable<Circuits>()
                       where x.User_Created == false
                       orderby x.Description
                       select x;

来自NHibernate Profiler
查询持续时间
- 仅限数据库：7ms
- 总计：835毫秒

生成的查询：

SELECT   this_.Circuit_ID     as Circuit1_35_0_,
     this_.[Description]  as column2_35_0_,
         this_.[User_Created] as column3_35_0_
FROM     dbo.Circuit this_
WHERE    this_.[User_Created] = 0 /* @p0 */
ORDER BY this_.[Description] asc

这似乎是一个非常简单的查询。它返回6821行。我所使用的只是填充下拉列表。

提前致谢

Answer 1

好的，如果你坚持7k（我真的认为你应该停下来重新考虑你的设计......但是......），你可以尝试做一个HQL查询来选择字段你需要从对象，而不是查询对象本身。

使用您编写的查询，nHibernate正在加载数据库中的数据，正如您所指出的那样。但是那么基于你写的Linq查询它正在初始化，填充和返回7k Circuit对象。这可能需要一段时间......

由于在这种情况下你实际上并没有以任何有意义的方式使用“对象”（只是下拉列表的文本和值对），你真的不需要nHibernate来构建对象。

尝试更改代码，只需使用HQL或LinqToNHibernate返回文本/值对。

HQL看起来像这样：

select c.description, c.id from Circuit c
where c.ordercreated = false
orderby c.description

我知道你也可以用LinqToNhibernate做到这一点，我手边没有任何简单的例子。

Answer 2

等等......你在下拉列表中放了近7k项？我理解正确吗？

如果是这样，是否可以使用带有ajax或类似设计的依赖下拉列表？

如果这是在网络上，您可能正在查看需要传输到客户端计算机的相对较大的页面，因此优化NH查询可能是一个不成熟的优化...

Answer 3

下拉列表中的7k条目对用户体验不利。由于您已按说明进行排序，因此我假设您的用户已经（至少部分）知道他们想要选择的内容。因此，提供完整列表实际上会阻碍用户。

因为你问的是自动填充器是什么

想象一下用户输入多个字符的输入字段。当用户键入他想要的内容时，将触发查询。此字符串参数将用于进一步限制结果集的大小。

所以你的查询实现就像这个伪代码：

//passedParameter => "%foo%"
var temp = from x in ActiveRecordLinq.AsQueryable<Circuits>()
              where x.User_Created == false
                and x.Description like passedParameter
              orderby x.Description
              select x;

查询的实际实现以及您决定实施'％foo％'或'foo％'等等都是您的决定。

用户体验将减少为在输入字段中写入'foo'，结果将仅获取用户将选择他想要的相关Circuits。如果结果集仍然太大，则用户可以将“b”添加到已经键入的“foo”，从而形成“foob”，再次查询会再次触发返回更有限的结果集。

当您在Google上键入内容时，它会立即为您提供自动完成实施建议

如何优化这个Nhibernate查询（835ms）

3 个答案: