# Secondary Index Overview
+ Index tries to find more efficient access methods than **`TableFullScan`** where possible
+ **Unique** and **non-unique** secondary index are supported
+ Composite index is supported
+ Create secondary index with careful considerations
+ Consider `TiFlash` as an alternative for creating index
------------------------------------------------------------------------------
Indexes in databases are data structures that serve the purpose of speeding up data retrieval operations, and unique indexes can enforce uniqueness. When a query statement is executed, indexes allow the database to efficiently locate data that fulfills the query conditions. This saves time compared to scanning the entire table sequentially (`TableFullScan`), resulting in improved query performance.

In TiDB, secondary indexes refer to those indexes that do not support primary key constraints.

However, indexes come with cost and they require additional storage space. Creating indexes will occupy disk space and also have a certain impact on the performance of `INSERT`, `UPDATE`, and `DELETE` operations. Therefore, when designing a table schema, it is necessary to carefully consider the use of indexes and avoid excessive or unnecessary indexes.

A composite index is an index created on multiple columns within a table. The columns in a composite index can be arranged in any order and do not need to be adjacent in the table. When determining the column order, it is essential to consider the queries being performed. As a general guideline, prioritize placing the most selective columns as the prefix in the composite index. Further details on improving the selectivity of your indexes will be covered in chapter 4.

Indexing is beneficial for retrieving a limited number of rows from a large dataset. However, in scenarios where columnar aggregated analysis requires a full scan of the table, `PingCAP` has introduced the `TiFlash` columnar engine to fulfill this requirement efficiently.