Whether it should be indexed
Should an index be created on every query field in every table? The answer is no.
We should decide according to the situation. If the execution time of the SQL statement of a table is not long, why build an index to increase the cost of maintaining the table and index?
1. We can open the slow query log
slow_query_log=1
2. The slow query log storage path
slow_query_log_file=/var/log/mysql/log-slow-queries.log
3. SQL execution time is greater than 3 seconds, then log
long_query_time=3
So when we find that the execution time of this statement is too long, should we immediately build an index? No. First, we must first determine whether the SQL statement can be optimized:
1. Try not to return all fields select * from tablename
2. Try not to use subqueries in select,
etc.
Then, build an index to optimize sql
So which fields should the index be built on?
The following online searches have some rules:
1. Fields with a large number of conditional queries
2. Fields with a high degree of discrimination, such as: a unique identification field, if it is a similar gender and only "male" and "female", there is no need to add an index
3. Often used for connection queries Column
4. Columns that often need to be sorted (group by / order by)
5. Fields that are used as conditions in the where clause to filter
Do not create indexes on frequently updated fields and fields with very many values.
Do not create indexes when the amount of table data is small. Because the amount of table data is small, the efficiency of full table scans will not be lower than that of walking indexes (the default is not a primary key index. Need to return to the table)
For columns with a large or small amount of data such as text, image and bit, it is not suitable for indexing
Indexed statement
create index [indexname] on tablename;`
Index Design Samsung Guidelines
If a query satisfies all the index conditions of the three stars in the Samsung index, the index we designed can theoretically be considered the best index. What is the
first star of the Samsung index : The columns participating in the query after WHERE can form a single-column index or a joint index. The
second star: avoid sorting, that is, if order by colulmn appears in the SQL statement, then the result set retrieved is already in accordance with The column is sorted, no need to generate a temporary table.
Third star: The column corresponding to the SELECT should be an index column as much as possible, that is, try to avoid back to the table query.
Under what circumstances will cause the index to fail?
1. In the fuzzy query, like "%aa%" will invalidate the index, but the latter will not be like "aa%". The specific reason is that the underlying implementation of the index will not be able to reduce the search range when looking for data.
2. In Index fields use functions or operations
3. Range search: not equal to (!= or <>), not in, not exists, it may cause a full table scan (the principle is the same as like)
4. or connect multiple conditions Will make the index invalid, unless the or conditions are indexed or changed to union all connection
5. Implicit type conversion and implicit character encoding conversion will make the index invalid. If id is of character type and 1 is of numeric type, you will find that you can use the explain to scan the full table and you can't use the index at all. Why? Because the bottom layer of MySQL will convert your comparison, it is equivalent to adding a function such as CAST (id AS signed int). As mentioned above, the function will cause the index to fail. The same problem is still the same. If the character sets of the two tables are different, one is utf8mb4 and the other is utf8, because utf8mb4 is a superset of utf8, so once the two characters are compared, they will be converted to utf8mb4 and then compared. The conversion process is equivalent to adding the CONVERT (id USING utf8mb4) function, then back to the above problem, the index
6 is null, is not null if the function is used, and index
7...characters cannot be used under normal circumstances . Strings without single quotes are invalid.
8. Less use of or or in. When querying with it, MySQL does not necessarily use indexes. The internal optimizer of MySQL will evaluate whether to use indexes as a whole according to multiple factors such as retrieval ratio and table size. See the scope for details. Query optimization
9. Do not use the index when the leftmost prefix rule is not satisfied (MySQL will always match to the right until it encounters a range query (>,<,BETWEEN,LIKE) and stop matching.)