1. Pros and cons of indexing
profit
- Querying data through index columns can improve the efficiency of data retrieval and reduce the IO cost of the database.
- Sort data by index column, reduce the cost of data sorting, and reduce CPU consumption
cons
- Suppose table a has column ca and create an index for it indx_a_ca
- Every time the ca is updated, the index information after the key value changes caused by the update will be adjusted.
- This will increase the IO loss, the index column will also take up space, and the data in column a will increase.
- The space occupied by the indx_a_ca index also keeps growing. Therefore, the index will also consume storage space resources.
2. MySQL index classification
- B-Tree Index
- Hash index
- Hash indexes can only satisfy "=", "in" <> queries, but cannot support range queries
- Hash indexes cannot be used for sorting operations
- Hash indexes cannot be queried using partial index keys
- Hash indexes cannot avoid table scans
- full-text index
- Only myisam storage engine supports ---> only char, varchar, text support
- R-Tree Index
- Mainly solve the problem of spatial data retrieval, rarely used
3. How to determine whether to create an index
- Fields that are frequently used as query conditions should be indexed
- Fields with poor uniqueness are not suitable for separate index creation
- This field may be repeated thousands of times
- Even if you create the index optimizer module will not choose to use
- There will be great performance problems. There are many repeated values, which will bring a lot of random IO or even repeated IO.
- Fields that are updated very frequently are not suitable for indexing
- Not only update the data in the table, but also need to update the index data IO access increases
- Fields that do not appear in the where clause should not be indexed
- Single key index or composite index
4. Limitations of indexes in mysql (the following principles are basically established in oracle)
- Whether an index is used can view the execution plan
- Doing calculations, functions, or type conversions (even automatic) on any indexed column will invalidate the index and move to a full table scan operation
- Do not perform any operations on indexed columns as it may invalidate the index
- mysql cannot use indexes when using not equals (!= or <>) will cause a full table scan
- is null , is not null and the index cannot be used
- When the join condition field type in the join statement is inconsistent, mysql cannot use the index
- When fuzzy query (like operation) starts with a wildcard ('%abc...') MySQL index invalidation will become a full table scan operation
- If a hash index is used, the index cannot be used when doing non-equivalent joins, it will be a full table scan operation
- (select * from t where t>5) is less efficient than (select * from t where t>=6)
- Columns of type BLOB and Text in mysql can only create prefix indexes
- For MyISAM storage engine, the total length of index keys cannot exceed 1000 bytes
- When both unique and non-unique indexes exist, only the unique index is often selected
- Combined index, the index will be used when the first column of the combined index appears in the query
Note: You can verify the above conclusions by viewing the execution plan
5. Some suggestions for using indexes
For single-key indexes, try to choose an index with better filterability for the current query
When selecting a composite index, the field with the best filterability in the current Query is in the order of the index fields, and the higher the position, the better.
When choosing a composite index, try to choose an index that can contain more fields in the where clause in the current query
The purpose of selecting an appropriate index is achieved by analyzing statistical information and adjusting the writing of the query as much as possible. Reduce the choice of controlling the index by using Hint, if using Hint will make the later maintenance cost relatively high