# Indexing Best Practices
+ Consider indexes on columns that participate in
  + The `WHERE` clause
  + `ORDER BY` or `GROUP BY` clauses
  + Table join conditions
+ Index columns with high cardinality ("uniqueness" of data)
  + For example, a `gender` column has low cardinality. A `CustomerID` column is likely to have high cardinality
+ Consider using prefix indexes on character columns
  + Put only required data into index when possible
  + Require less disk space
+ Do NOT create indexes that the optimizer can NOT use
------------------------------------------------------------------------------
Do not assume that a column requires an index simply because it appears in the query output.

In certain situations, even if you create an index on a column and reference it in the `WHERE` clause of a query, the optimizer might choose not to use that index. This can occur when the index's selectivity is low or when the statistics gathered by the optimizer do not accurately reflect the column's value distribution. For example, an index on a gender column exhibits low selectivity due to the limited number of possible values. Similarly, an index on an `order_status` column may have low cardinality, with statuses such as opened, picking, packing, shipping, shipped, or closed, and the majority of orders might be in the `closed` status. In such cases, the optimizer might determine that a full table scan is less costly than using a low-selectivity index, considering that each secondary index lookup could involve additional lookups. Consequently, it may opt not to use the index.