Question

I’m designing a MySQL Database…

1. I have a number of tables that use UserID as the primary Key. All these tables will have 1 row for each user and will therefore grow at the same rate. Seeing they will be access via the primary key (UserID) I assume there is no need to index to this key as each is unique.

2. I will also have a number of tables that will have an incremental number as a primary key and the UserID will be second column. For these tables there will be multiple instances of the UserID in the second column. (each this UserID has many Friends and each is listed on a different row). I expect these tables to grow very long, however not very wide and therefore not large with respects to GB.

Question: If I add an index on the tables in part 2 above (the UserID/second column) and if my queries are using the UserID for Joins (all joins off UserID) does this mean Joins would access the larger tables (Part 2 above) via the indexed UserID and therefore the speed of access these larger tables would be similar to the smaller tables in Part 1?

Having all tables that will be part of Joins using the UserID as either a unique Primary Key (shorter tables) or an Indexed column (larger tables) – does this appear to be resonable design with respects to ensure good response times if tables were to get quite large – ever in to the 100Millions rows? (excluding other requirements like HW).

thoughts? thx

Answer 1

A primary key field(s) is automatically part of a unique index, so there’s no need to add yet another index on top of that.

It is a good rule of thumb to put an index onto any field which is used in a where, join, and/or order by clause.

Speed-wise, no one can say for sure if adding (or removing) indexes will improve performance. For simple/small DBs, indexes are invariably a major speedup. For large/complicated schemas, they can actually hurt performance in some scenarios. You’ll have to benchmark your system to make sure. But in general, indexes = good.