1. Index Use Cases

2. Retrieval Query (SELECT Statement)
To do a retrieval query, you need the following information:
The relations that will be accessed by the query
The attributes on which any selection conditions for the query are specified
Whether the selection condition is an equality, inequality, or a range condition
The attributes on which any join conditions for the query are specified
The attributes whose values will be retrieved by the query
The attributes lists in steps 2 and 4 are candidates for access structures like indexing, hash keys or sorting.

3. Modification Query (INSERT, UPDATE, DELETE statements)
To perform a modification query, you need to know:
The relations that will be modified
The type of modification to be performed (insert, update, or delete)
The attributes which are selection conditions for a delete or update are specified
The attributes whose values will be changed by the modification
The attributes listed in step 3 are good candidates for access structures.
Which attributes are BAD candidates for indexing?

4. Analyze the expected frequency of invocation of queries
You don't need to design your database to handle every query that is might receive. You should instead try to find the queries where performance matters most.
According to the informal rule, approximately 80% of the database's processing time is caused by 20% of the queries. Identifying and optimizing for this 20% is a good use for your time.

5. Analyzing Time Constraints
Some queries have different time constraints than others.
For example, a website needs to be responsive, else users may leave. The database should ensure that page requests are handled as fast as possible. However, posting to your blog, isn't as time sensitive. So posting may take a few seconds without causing a problem.
Optimize for queries whose performance matters. Often reads are more important then writes (but not always).

6. Analyzing frequency of modifying queries
You should try to reduce access paths to attributes that change often, because each access path must also be modified if its key is changed.
You can either not index those attributes, or find ways to reduce the frequency that indexed keys need to be changed.

7. Analyzing Key Constraints
If an attribute has constraints (like uniqueness, references a foreign key, or other checks), you should consider using indices to make enforcement more performant.

8. Making the DBMS use the index
Generally, the DBMS will use an index if it deems it helpful for processing a query.
In different DBMSs, there are different ways to hint or force the system to use an index.
Generally, that's a bad idea. DBMSs (like compilers) are generally smarter than you.
Also, most DBMSs will generate automatic indices when it deems them useful. However creating explicit/manual indices can often improve performance because the automatic indices are erased after they are used.