Should I COUNT(*) or not?

前端 未结 14 1342
爱一瞬间的悲伤
爱一瞬间的悲伤 2021-01-30 15:49

I know it\'s generally a bad idea to do queries like this:

SELECT * FROM `group_relations`

But when I just want the count, should I go for this

相关标签:
14条回答
  • 2021-01-30 16:12

    If I remember it right, in MYSQL COUNT(*) counts all rows, whereas COUNT(column_name) counts only the rows that have a non-NULL value in the given column.

    0 讨论(0)
  • 2021-01-30 16:15

    I know it's generally a bad idea to do queries like this:

    SELECT * FROM `group_relations`
    

    But when I just want the count, should I go for this query since that allows the table to change but still yields the same results.

    SELECT COUNT(*) FROM `group_relations`
    

    As your question implies, the reason SELECT * is ill-advised is that changes to the table could require changes in your code. That doesn't apply to COUNT(*). It's pretty rare to want the specialized behavior that SELECT COUNT('group_id') gives you - typically you want to know the number of records. That's what COUNT(*) is for, so use it.

    0 讨论(0)
  • 2021-01-30 16:20

    Seek Alternatives

    As you've seen, when tables grow large, COUNT queries get slow. I think the most important thing is to consider the nature of the problem you're trying to solve. For example, many developers use COUNT queries when generating pagination for large sets of records in order to determine the total number of pages in the result set.

    Knowing that COUNT queries will grow slow, you could consider an alternative way to display pagination controls that simply allows you to side-step the slow query. Google's pagination is an excellent example.

    Denormalize

    If you absolutely must know the number of records matching a specific count, consider the classic technique of data denormalization. Instead of counting the number of rows at lookup time, consider incrementing a counter on record insertion, and decrementing that counter on record deletion.

    If you decide to do this, consider using idempotent, transactional operations to keep those denormalized values in synch.

    BEGIN TRANSACTION;
    INSERT INTO  `group_relations` (`group_id`) VALUES (1);
    UPDATE `group_relations_count` SET `count` = `count` + 1;
    COMMIT;
    

    Alternatively, you could use database triggers if your RDBMS supports them.

    Depending on your architecture, it might make sense to use a caching layer like memcached to store, increment and decrement the denormalized value, and simply fall through to the slow COUNT query when the cache key is missing. This can reduce overall write-contention if you have very volatile data, though in cases like this, you'll want to consider solutions to the dog-pile effect.

    0 讨论(0)
  • 2021-01-30 16:21

    It should depend on what you are actually trying to achieve as Sebastian has already said, i.e. make your intentions clear! If you are just counting the rows then go for the COUNT(*), or counting a single column go for the COUNT(column).

    It might be worth checking out your DB vendor too. Back when I used to use Informix it had an optimisation for COUNT(*) which had a query plan execution cost of 1 compared to counting single or mutliple columns which would result in a higher figure

    0 讨论(0)
  • 2021-01-30 16:21

    The advice I got from MySQL about things like this is that, in general, trying to optimize a query based on tricks like this can be a curse in the long run. There are examples over MySQL's history where somebody's high-performance technique that relies on how the optimizer works ends up being the bottleneck in the next release.

    Write the query that answers the question you're asking -- if you want a count of all rows, use COUNT(*). If you want a count of non-null columns, use COUNT(col) WHERE col IS NOT NULL. Index appropriately, and leave the optimization to the optimizer. Trying to make your own query-level optimizations can sometimes make the built-in optimizer less effective.

    That said, there are things you can do in a query to make it easier for the optimizer to speed it up, but I don't believe COUNT is one of them.

    Edit: The statistics in the answer above are interesting, though. I'm not sure whether there is actually something at work in the optimizer in this case. I'm just talking about query-level optimizations in general.

    0 讨论(0)
  • 2021-01-30 16:22

    COUNT(*) count all rows while COUNT(column_name) will count only rows without NULL values in the specified column.

    Important to note in MySQL:

    COUNT() is very fast on MyISAM tables for * or not-null columns, since the row count is cached. InnoDB has no row count caching, so there is no difference in performance for COUNT(*) or COUNT(column_name), regardless if the column can be null or not. You can read more on the differences on this post at the MySQL performance blog.

    0 讨论(0)
提交回复
热议问题