Select Count() Performance Options

Forum Moderators: open

Message Too Old, No Replies

Select Count() Performance Options

any other method for achieving this across multiple tables?

blaketar

6:04 pm on Sep 4, 2007 (gmt 0)

I have a small application where a user logs in with a username/password, upon successfully logging in a set of navigation links are displayed on the left of the screen.

These links interface with the different options available in the application, however each link displayed may have a COUNT() value associated with it. For instance one link may be MESSAGES, this particular user may have 3 new messages in the messages.table, the next link may be TASKS, with 4 new tasks in the tasks.table.

I know I could perform a SQL count() on each of the desired tables but I am worried somewhat about the overhead of this (say I have to perform 20 different sql counts) on each page load to display these count numbers.

Has anyone run into this situation? Can your perform counts across multiple tables? One option that crossed my mind was storing these numbers in the users.table but this seems like allot of extra sql-footwork to keep the numbers synced...

alexdunae

1:46 am on Sep 9, 2007 (gmt 0)

I've always had good luck with using a counter field (e.g. `users`.`message_count`) and incrementing/decrementing as required. It doesn't take that much more work it will be fast.

That said, COUNT() is generally very fast providing you have indexes set up properly.

aspdaddy

8:20 pm on Sep 11, 2007 (gmt 0)

Why not set the counters at the start of a session, store them in a cookie and only update them when needed.

syber

8:28 pm on Sep 11, 2007 (gmt 0)

COUNT(*) is usually very fast in that the table itself usually doesn't need to be accessed (the meta information in the database should already have stored the number of records in each table). If you say COUNT(fieldname), however, the actual table (or index) must be accessed to determine the number of rows without NULL in the fieldname column.

Lord Majestic

3:45 pm on Sep 12, 2007 (gmt 0)

Using MAX() on a column that is incremented for each row can often do the trick very quickly so long as it is indexed. If you read stats more than you update, then you could benefit from updating stats in place whenever new data is added - triggers could be good for that, but be careful as excessive use of triggers can lead to performance issues. Alternatively you can just update stats once every X minutes - they won't be exact, but if you have lots of data then running stats in real time would cost too much.

SeanW

1:27 am on Sep 21, 2007 (gmt 0)

Create an index on the field that links the user to the row, mysql should be able to count it quickly (your have tuned your server so the indexes stay in memory, right?)

The mysql query cache might help depending on the write volume to the table.

Failing that, look into memcached. Store the whole profile as a serialized array (messages=3, tasks=2), and invalidate the key if one of them changes.

Sean

blaketar

1:31 am on Sep 29, 2007 (gmt 0)

Thanks guys, I hadnt thought of the session variable idea but created a function which updates the number array when needed and it works great!

Thanks Again!