“SELECT COUNT(*)” is slow, even with where clause

后端 未结 8 1587
抹茶落季
抹茶落季 2020-11-30 23:22

I\'m trying to figure out how to optimize a very slow query in MySQL (I didn\'t design this):

SELECT COUNT(*) FROM change_event me WHERE change_event_id >         


        
相关标签:
8条回答
  • 2020-12-01 00:07

    I would create a "counters" table and add "create row"/"delete row" triggers to the table you are counting. The triggers should increase/decrease count values on "counters" table on every insert/delete, so you won't need to compute them every time you need them.

    You can also accomplish this on the application side by caching the counters but this will involve clearing the "counter cache" on every insertion/deletion.

    For some reference take a look at this http://pure.rednoize.com/2007/04/03/mysql-performance-use-counter-tables/

    0 讨论(0)
  • 2020-12-01 00:17

    Here are a few things I suggest:

    • Change the column from a "bigint" to an "int unsigned". Do you really ever expect to have more than 4.2 billion records in this table? If not, then you're wasting space (and time) the the extra-wide field. MySQL indexes are more efficient on smaller data types.

    • Run the "OPTIMIZE TABLE" command, and see whether your query is any faster afterward.

    • You might also consider partitioning your table according to the ID field, especially if older records (with lower ID values) become less relevant over time. A partitioned table can often execute aggregate queries faster than one huge, unpartitioned table.


    EDIT:

    Looking more closely at this table, it looks like a logging-style table, where rows are inserted but never modified.

    If that's true, then you might not need all the transactional safety provided by the InnoDB storage engine, and you might be able to get away with switching to MyISAM, which is considerably more efficient on aggregate queries.

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