# Index Considerations

+ Is it necessary to have **`IndexReader`** and **`IndexRangeScan`** for every query?
  + For small tables, the cardinality is always considered to be low even for **`FullTableScan`** and **`Selection`**, which in turn, the cost is low
  + For scenarios with low selectivity, it is not uncommon that **`FullTableScan`** and **`Selection`** is faster than **`IndexRangeScan`** and **`TableRowIDScan`**
+ What are the impacts of adding indexes on SQL execution performance?
  + Query performance **might be** improved by replacing **`FullTableScan`** to **`IndexRangeScan`**
  + Each secondary index added to the table results additional write overhead penalties, implementing a `DML` time for query time strategy
  + Indexes also consume disk space, implementing a space for time strategy

------------------------------------------------------------------------------
Some may suggest that when tuning SQL statements, creating an index that includes all columns in the `WHERE` and `SELECT` clauses could prompt the database optimizer to use the `IndexReader` and `IndexRangeScan` execution plan, thereby avoiding `TableReader` and `TableFullScan` or even `IndexLookUp`. However, in practice, this approach can lead to an excessive number of indexes on a table, which may negatively impact performance for other operations. 

Although indexes can significantly enhance query performance, they also slow down data modification statements, as they need to be updated whenever the referenced rows are changed. Additionally, they consume substantial disk space.