Index Use Cases

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.

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?

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 80-20 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. http://www.nateleung.com/how-to-use-the-80-20-rule-for-mlm-success/

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).

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. http://eatonrapidsjoe.blogspot.com/2015/07/journalism-vs-exposition.html

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. https://pixabay.com/en/photos/chain%20link/

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.