开发者

Does this field need an index?

开发者 https://www.devze.com 2023-04-08 06:02 出处:网络
I currently have a summary table to keep track of my users\' post counts, and I run SELECTs on that table to sort them by counts, like WHERE count > 10, for example. Now I know having an index on c

I currently have a summary table to keep track of my users' post counts, and I run SELECTs on that table to sort them by counts, like WHERE count > 10, for example. Now I know having an index on columns used in WHERE clauses speeds things up, but since these fields will also be upda开发者_如何转开发ted quite often, would indexing provide better or worse performance?


If you have a query like

SELECT count(*) as rowcount
FROM table1
GROUP BY name

Then you cannot put an index on count, you need to put an index on the group by field instead.

If you have a field named count

Then putting an index in this query may speed up the query, it may also make no difference at all:

SELECT id, `count`
FROM table1
WHERE `count` > 10

Whether an index on count will speed up the query really depends on what percentage of the rows satisfy the where clause. If it's more than 30%, MySQL (or any SQL for that matter) will refuse to use an index.
It will just stubbornly insist on doing a full table scan. (i.e. read all rows)
This is because using an index requires reading 2 files (1 index file and then the real table file with the actual data).
If you select a large percentage of rows, reading the extra index file is not worth it and just reading all the rows in order will be faster.

If only a few rows pass the sets, using an index will speed up this query a lot

Know your data

Using explain select will tell you what indexes MySQL has available and which one it picked and (kind of/sort of in a complicated kind of way) why.

See: http://dev.mysql.com/doc/refman/5.0/en/explain.html


Indexes in general provide better read performance at the cost of slightly worse insert, update and delete performance. Usually the tradeoff is worth it depending on the width of the index and the number of indexes that already exist on the table. In your case, I would bet that the overall performance (reading and writing) will still be substantially better with the index than without but you would need to run tests to know for sure.


It will improve read performance and worsen write performance. If the tables are MyISAM and you have a lot of people posting in a short amount of time you could run into issues where MySQL is waiting for locks, eventually causing a crash.


There's no way of really knowing that without trying it. A lot depends on the ratio of reads to writes, storage engine, disk throughput, various MySQL tuning parameters, etc. You'd have to setup a simulation that resembles production and run before and after.


I think its unlikely that the write performance will be a serious issue after adding the index.

But note that the index won't be used anyway if it is not selective enough - if more than for example 10% of your users have count > 10 the fastest query plan might be to not use the index and just scan the entire table.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号