MySQL database efficiency. 1 million pieces of data -- 5 million pieces of data

    In general application systems, the read-write ratio is about 10:1, and insert operations and general update operations rarely have performance problems. The most encountered, and the most prone to problems, are some complex query operations, so the query statement optimization is clearly a top priority.

1 The default rules for database table indexing:
(1) The leftmost prefix matching principle, a very important principle, 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 the index of (a,b,c,d) order is established, d will not use the index, if the index of (a,b,d,c) is established, both Can be used, the order of a, b, d can be adjusted arbitrarily.
(2). Try to expand the index, do not create a new index. For example, there is already an index of a in the table, and now you need to add the index of (a, b), then you only need to modify the original index
(3) = and in can be out of order, such as a = 1 and b = 2 and c = 3 The (a, b, c) index can be established in any order, and the mysql query optimizer will help you optimize it into a form that the index can recognize
(4) The index column cannot participate in the calculation, keep the column "clean", such as from_unixtime(create_time) = The index cannot be used for '2014-05-29'. The reason is very simple. All the field values ​​in the data table are stored in the b+ tree. However, when retrieving, it is necessary to apply functions to all elements to compare, which is obviously too expensive. . Therefore, the statement should be written as create_time = unix_timestamp('2014-05-29');

2 When the amount of data is large, full table scan should be avoided as much as possible, and indexing should be considered on the columns involved in where and order by. Indexing can greatly speed up Data retrieval speed. However, in some cases, the index will not work:
(1) Try to avoid using the != or <> operator in the where clause, otherwise the engine will give up the use of the index and perform a full table scan.
(2) Try to avoid the null value judgment of the field in the where clause, otherwise the engine will give up the use of the index and perform a full table scan, such as:
     select id from t where num is null
     You can set the default value of 0 on num , make sure that there is no null value in the num column in the table, and then query like this:
     select id from t where num=0
(3), try to avoid using or in the where clause to connect conditions, otherwise it will cause the engine to give up using the index and perform a full table Scan, such as:
     select id from t where num=10 or num=20
     can be queried like this:
     select id from t where num=10
     union all
     select id from t where num=20
(4), the following query will also result in the full table Scan:
    select id from t where name like '%abc%'
    To improve efficiency, consider full-text search.
(5), in and not in should also be used with caution, otherwise it will lead to a full table scan, such as:
     select id from t where num in(1,2,3)
     For consecutive values, if you can use between, do not use in:
     select id from t where num between 1 and 3
(6) If parameters are used in the where clause, it will also cause a full table scan. Because SQL resolves local variables only at runtime, the optimizer cannot defer the choice of an access plan to runtime; it must choose it at compile time. However, if the access plan is built at compile time, the value of the variable is unknown and cannot be used as an input for index selection. For example, the following statement will perform a full table scan:
     select id from t where num=@num
     can be changed to force the query to use the index:
     select id from t with(index(index name)) where num=@num
(7), should be avoided as much as possible An expression operation on a field in a where clause will cause the engine to give up using the index and perform a full table scan. For example:
     select id from t where num/2=100
     should be changed to:
     select id from t where num=100*2
(8), should try to avoid the function operation on the field in the where clause, which will cause the engine to give up use index and perform a full table scan. For example:
     select id from t where substring(name,1,3)='abc'--name starts with abc id
     select id from t where datediff(day,createdate,'2005-11-30')=0-'2005 The id generated by -11-30'
     should be changed to:
     select id from t where name like 'abc%'
     select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'





from the network summary---unfinished