Question

Assume that I have one big table with three columns: “user_name”, “user_property”, “value_of_property”. Lat’s also assume that I have a lot of user (let say 100 000) and a lot of properties (let say 10 000). Then the table is going to be huge (1 billion rows).

When I extract information from the table I always need information about a particular user. So, I use, for example where user_name='Albert Gates'. So, every time the mysql server needs to analyze 1 billion lines to find those of them which contain “Albert Gates” as user_name.

Would it not be wise to split the big table into many small ones corresponding to fixed users?

Answer 1

No, I don’t think that is a good idea. A better approach is to add an index on the user_name column – and perhaps another index on (user_name, user_property) for looking up a single property. Then the database does not need to scan all the rows – it just need to find the appropriate entry in the index which is stored in a B-Tree, making it easy to find a record in a very small amount of time.

If your application is still slow even after correctly indexing it can sometimes be a good idea to partition your largest tables.

One other thing you could consider is normalizing your database so that the user_name is stored in a separate table and use an integer foriegn key in its place. This can reduce storage requirements and can increase performance. The same may apply to user_property.