(Reprinted) Index optimization

#1. The leftmost prefix matching principle, a very important principle, create index ix_name_email on s1(name,email,)

• Leftmost prefix matching: Must match from left to right select * from s1 where name='egon'; #Can select * from s1 where name='egon' and email='asdf'; #Can select * from s1 where email='[email protected]'; #No
  mysql will always match to the right until it encounters a range query (>, <, between, like) and stop matching, such as a = 1 and b = 2 and c>
  3 and d = 4 If an index of (a, b, c, d) order
  is established , d is not an index. If an index of (a, b, d, c) is established, it can be used, a, b, The order of d can be adjusted arbitrarily.

#2.= and in can be out of order , for example, a = 1 and b = 2 and c = 3 The establishment of (a, b, c) index can be in any order, mysql's query optimizer will help you optimize it into a form that the index can recognize

#3. Try to choose a column with high discrimination as the index. The formula for discrimination is count(distinct col)/count(*), which indicates the proportion of fields that are not repeated. The larger the proportion, the fewer records we scan, the unique key The discrimination degree is 1, and some status and
gender fields may have a discrimination degree of 0 in the face of big data. Then someone may ask, is there any empirical value for this ratio? Depending on the usage scenario,
this value is also difficult to determine. Generally, the fields that need to be joined are required to be 0.1 or more, that is, an average of 10 records per scan

#4. Index columns cannot participate in calculations. Keep columns "clean". For example, from_unixtime(create_time) = '2014-05-29', indexes cannot be used. The reason is very simple. All the fields in the data table are stored in the b+ tree. Value, but when searching, you need to apply functions to all elements to compare, which is obviously too costly.
So the statement should be written as create_time = unix_timestamp('2014-05-29');

Circumstances where the index cannot be hit:

• like ‘%xx’
  select * from tb1 where email like ‘%cn’;

• Use the function
  select * from tb1 where reverse(email) ='wupeiqi';

• or
  select * from tb1 where nid = 1 or name = ‘[email protected]’;

  Special: when there are unindexed columns in the or condition, the following will take the index
  select * from tb1 where nid = 1 or name ='seven';
  select * from tb1 where nid = 1 or name ='seven@live .com' and email ='alex'

• The type is inconsistent.
  If the column is a string type, the incoming condition must be enclosed in quotation marks, otherwise...
  select * from tb1 where email = 999; the
  normal index is not equal to the index

• !=
  select * from tb1 where email != ‘alex’

  Special: if it is a primary key, it will still take the index
  select * from tb1 where nid != 123

• select * from tb1 where email > ‘alex’

  Special: If the primary key or index is an integer type, the index will still be taken
  select * from tb1 where nid> 123
  select * from tb1 where num> 123

#The sort condition is an index, the select field must also be an index field, otherwise it cannot be hit

• order by
  select name from s1 order by email desc;
  when sorting according to the index, if the field of the select query is not an index, then the index will not be taken.
  select email from s1 order by email desc;
  special: if the primary key is sorted, the index is still taken :
  Select * from tb1 order by nid desc;

• The leftmost prefix of the
  composite index If the composite index is: (name, email)
  name and email-use the index
  name-use the index
  email-not use the index

• Count(1) or count(column) instead of count(*) makes no difference in mysql

• create index xxxx on tb(title(19)) #text type, length must be specified

The basic steps of slow query optimization

0. Run first to see if it is really slow, pay attention to set SQL_NO_CACHE 1. Where
condition single table check, lock the minimum return record table. The meaning of this sentence is to apply the where of the query statement to the table with the smallest number of records returned in the table, start to look up, query each field of the single table separately to see which field has the highest degree of discrimination
2.explain to see the execution plan, whether Consistent with 1 expectation (start querying from tables with fewer locked records)
3. Order by limit form of sql statement allows sorted tables to be checked first
4. Understand the usage scenarios of the business side
5. Refer to the principles of indexing when adding indexes
6 . Observation results, do not meet expectations, continue to analyze from 0

Reprinted from https://www.cnblogs.com/bypp/p/7755307.html