count(*)真的很贵吗? [英] Is count(*) really expensive?

问题描述

我有一个页面，其中有4个标签，这些标签根据不同的表格显示4个不同的报告.

I have a page where I have 4 tabs displaying 4 different reports based off different tables.

我使用< table> 查询中的 select count(*)获得每个表的行数，并在选项卡上显示每个表中可用的行数.结果，每个页面回发都会导致执行5个 count(*)查询(其中4个用于获取计数，而1个用于分页)和1个用于获取报告内容的查询.

I obtain the row count of each table using a select count(*) from <table> query and display number of rows available in each table on the tabs. As a result, each page postback causes 5 count(*) queries to be executed (4 to get counts and 1 for pagination) and 1 query for getting the report content.

现在我的问题是: count(*)查询是否真的很昂贵-我应该将行计数(至少是在选项卡上显示的计数)保持在页面的查看状态，而不是多次查询?

Now my question is: are count(*) queries really expensive -- should I keep the row counts (at least those that are displayed on the tab) in the view state of page instead of querying multiple times?

COUNT(*)个查询的价格是多少?

How expensive are COUNT(*) queries ?

推荐答案

您需要附加像L2SProf 这样的应用程序级别探查器，您之前的实际查询费用:

You need to attach SQL Profiler or an app level profiler like L2SProf and look at the real query costs in your context before:

• 猜测问题出在哪里，并试图确定潜在解决方案的潜在好处

• guessing what the problem is and trying to determine the likely benefits of a potential solution

允许其他人在da interweb上为您猜测-很多错误信息没有被引用，包括在此线程中(但在本帖子中没有:P)

allowing others to guess for you on da interwebs - there's lots of misinformation without citations about, including in this thread (but not in this post :P)

完成此操作后，将很清楚最好的方法是什么-即SELECT COUNT是否在主导事情，等等.

When you've done that, it'll be clear what the best approach is - i.e., whether the SELECT COUNT is dominating things or not, etc.

完成此操作后，您还将知道选择进行的任何更改是产生了正面还是负面的影响.

And having done that, you'll also know whether any changes you choose to do have had a positive or a negative impact.

这篇关于count(*)真的很贵吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！