SQL Tutorial
SQL Clauses / Operators
SQL-Injection
SQL Functions
SQL Queries
PL/SQL
MySQL
SQL Server
Misc
Indexes are a critical feature in relational databases, enhancing the speed of retrieval operations on a database table. An index provides a way for the database to find rows in a table without scanning through the entire table��a process that could be slow for large tables.
Physical Structure: Indexes have their own storage separate from the table they index. The structure is designed to allow efficient lookup, often a B-tree.
Index Key: The value(s) used in the index to quickly locate the required row(s).
Faster Data Retrieval: Especially beneficial for large tables. The database can quickly determine the location of rows containing the required values.
Efficient Sorting and Filtering: Indexes can also help in the quick sorting and filtering of data.
Overhead: Indexes consume storage space.
Performance Hit on DML: Insert, Update, and Delete operations can be slower on indexed tables because the index also needs to be updated.
Maintenance: Indexes can get fragmented, and occasionally they may need to be rebuilt.
Here is a generalized syntax for creating an index:
CREATE INDEX index_name ON table_name (column1, column2, ...);
Single-Column Index: Created for only one column in a table.
CREATE INDEX index_name ON table_name (column_name);
Composite (or Multi-Column) Index: Created for two or more columns in a table.
CREATE INDEX index_name ON table_name (column1, column2, ...);
Unique Index: Ensures data uniqueness in the indexed column(s). Duplicate values are not allowed.
CREATE UNIQUE INDEX index_name ON table_name (column_name);
Full-text Index: Used for full-text searches.
Clustered vs. Non-clustered Indexes:
Clustered: Reorders the way records in the table are physically stored. Hence, a table can have only one clustered index.
Non-clustered: Doesn��t reorder the physical data but creates a separate object within the table that references the original table rows. A table can have multiple non-clustered indexes.
Dropping an Index:
DROP INDEX index_name;
Rebuilding an Index: Over time, with many insert/update/delete operations, indexes can become fragmented. Many RDBMSs provide a way to rebuild indexes.
Viewing Index Information: Many databases provide system views or metadata tables that allow users to see existing indexes and their details.
Don't Over-index: While indexes can speed up read operations, having too many indexes can slow down write operations. It's a balance.
Regularly Monitor and Maintain Indexes: Over time, as data is modified, indexes can become fragmented or less efficient.
Use Composite Indexes Wisely: If you often filter or join on multiple columns together, a composite index might be beneficial.
Analyze Query Performance: Use tools provided by your RDBMS to analyze which queries are running slow and could benefit from indexing.
Consider Workload: If your application is read-heavy, more indexes might be beneficial. If it's write-heavy, be cautious about the number of indexes you create.
Remember, the choice to create an index should not be taken lightly. Always weigh the advantages of faster query performance against the costs associated with additional storage and slower write performance.
CREATE INDEX idx_last_name ON employees(last_name);
SELECT * FROM employees WHERE last_name = 'Smith';
CREATE CLUSTERED INDEX idx_employee_id ON employees(employee_id);
CREATE NONCLUSTERED INDEX idx_department_id ON employees(department_id);
CREATE UNIQUE INDEX idx_email ON employees(email);
CREATE INDEX idx_name_department ON employees(last_name, department_id);
CREATE INDEX idx_covering ON employees(last_name) INCLUDE (first_name, hire_date);
ALTER INDEX idx_last_name ON employees REBUILD;
ALTER INDEX idx_last_name ON employees REORGANIZE;
DROP INDEX idx_last_name ON employees;
ALTER INDEX idx_last_name ON employees ADD (middle_name);
SELECT * FROM employees e JOIN departments d ON e.department_id = d.department_id;
SELECT /*+ INDEX(e idx_last_name) */ * FROM employees e WHERE last_name = 'Smith';