Index or Unique? What is better MySql

So i have a question.

Say you have a table requests, which represent a graph. There are 3 columns in the request table, A, B, time. A -> B At time. So what each row represents is a directed connection from A (the requestor) to B (the requestee) at Time T (time is just for organizing data, not r开发者_开发技巧eally for anything else).

So what is faster if say requests were 1,000,000 rows.

Index(A, B) Index(A) and Index(B) Unique(A, B)?

Thanks guys! And A, B are VARCHAR(32) (MD5's)

Sorry, i forgot a typical query.

I need to be able to see if User A (who logged on) has any requests!

I also will need to search to verify that a user has accepted a correct request, A Accepts B.

So the statements will look like.

Any new requests?

SELECT B, time
FROM requests
WHERE A='$id';  

Does A have a request from B?

SELECT time
FROM requests
WHERE A='$A' and B='$B';

---

Index and unique are two completely different concepts.

Indexes
An index is a hidden extra column holding the same data sorted with a pointer to your real data. Using an index you can

1. Quickly find a particular item
2. Quickly find a range of items (between x and y)
3. Save time when using order by because the items are presorted
4. Save time when using group by because group by needs to match identical items

This is a normal index, it doesn't mind duplicate values, except for the primary key which is always unique.

Unique (Index)
If you want to avoid duplicate values you can put a unique index on it. This will do all of the above, but add an extra check on every update and insert to check whether that values is not already in the database. If you try to insert a duplicate row on a unique column, MySQL will give an error and refuse your insert.
(you cannot make a row unique without using an index)

Use of indexes slows inserts and updates down.
Use of unique indexes slows then even more down.

However indexes speed up select a lot, a whole lot.
Unique doesn't speed up anything it makes sure you don't accidentally insert a duplicate row.

When to use indexes and when not
Don't put an index on every field. As stated above it will slow you inserts and updates down.
Always put an index on join criteria. And seriously consider putting an index on column you use in where clauses a lot.
MySQL will refuse to use an index if 50% of your rows have the same value in a field, so forget about indexes on boolean (Y/N) fields, 99% of the time they will not work.
(Indexes in low cardinality fields are not useful)

Always assign a primary key
Always assign a primary key on your table though. Preferably of type integer autoincrement. If you don't assign a primary key, MySQL will assign a 'hidden' primary key for you (of type integer autoincrement), but you cannot use the hidden PK to speed up quotes or identify your rows and there are a host of other slowness problems with hidden PK's which make them suck very badly.

Hope this helps.

Links:
How MySQL uses indexes: http://dev.mysql.com/doc/refman/5.5/en/mysql-indexes.html
When to use indexes: http://www.howtoforge.com/when-to-use-indexes-in-mysql-databases
More of that stuff: http://www.databasejournal.com/features/mysql/article.php/1382791/Optimizing-MySQL-Queries-and-Indexes.htm
Finally lurk here if you want to know more about MySQL: http://planet.mysql.com/

---

In this specific case, use a composite index including A and B. Make sure that A is first in the index. That way when you run these two queries, the index would be used for both.

More on composite indexes:

http://dev.mysql.com/doc/refman/5.5/en/multiple-column-indexes.html

Also, uniqueness (A,B) shouldn't matter unless your requirement is that B can only request A at most once.