(Vii) optimization table
1. Select the appropriate data engine
MyISAM: suitable for a large number of read operations tables
InnoDB: suitable for a large number of write read as Table
2. Select the appropriate column type
using SELECT * FROM TB_TEST PROCEDURE ANALYSE () this can be for each field in the table of analysis, recommendations are given to optimize the column type
3. for NULL values in a column without saving use nOT NULL, which is particularly important for the column you want to index
4. establish appropriate indexes
5. use the fixed-length field, faster than longer
(eight) indexing principles
1. rational use of the index
a Table in a query can only use an index, use the EXPLAIN statement to verify the operation of the optimizer
use the optimizer to help analyze the use of the index effect to make more accurate predictions
2. the index should be created on columns of data searching, sorting, grouping and other operations involved
3. try to indexing in less duplication of data columns, so the only best
example: birthday column can be indexed, but not to index sex column
4. try to compare the shorter index values
reduce disk IO operations, the index buffer can hold more keys, A high hit rate
if the index of a long string, a prefix length can specify
5. rational use of multi-column index
if the plurality of query conditions often need to be combined, will have to use multi-column index (since one can use a query table an index, create multiple separate index also only use one)
of the most left-prefix 6. take full advantage of
That is, to arrange the order of the columns of multi-column index, the most common top surface
6. compulsory force index using the specified index. the select * from song_lib force High index (song_name) order by song_name than not to force index efficiency
7. Do not create too many indexes
only often applied where, order by, group by the field needs to be indexed.
8. Use the slow query log to find out the slow query (log-SLOW-Queries, long_query_time)
(ix) take full advantage of index
the same data type column 1. try comparative data
2 so as to separate in the comparative index column expressions, WHERE mycol <4/2 using the index, and the WHERE mycol * 2 <4 not used
3 not queries as field plus function,
such as WHERE YEAR (date_col) <1990 transformed into the date_col the WHERE < '1990-01-01'
the WHERE TO_DAYS (the date_col) - TO_DAYS (CURDATE ()) <transformed into the cutoff WHERE date_col <DATE_ADD (CURDATE () , INTERVAL DAY the cutoff)
4. Do not use wildcards in the beginning LIKE mode
5. straight join to force the optimizer fROM clause in the order to join, may select straight join, mandatory for all links, may select * from a straight join b forced order of the two tables.
1. Create appropriate statistical Between the results of Table, to reduce the chance of a large table query from the data
2 to avoid the use of subqueries, the mode switch is connected, for example:
7. avoid using MySQL automatic type conversions, otherwise it will not use the index as the type int num_col used where num_col = '5'
optimization (x) the SQL statement
SELECT a.id, (SELECT MAX (created ) FROM posts WHERE = a.id the author_id) the AS latest_post
the FROM A the authors
can be changed:
the SELECT a.id, MAX (p.created) the AS latest_post
the FROM A the authors the AS
the INNER the ON the JOIN Posts P (= a.id p.author_id)
the GROUP BY A. ID
SELECT song_id from song_lib WHERE singer_id in
(SELECT singer_id from singer_lib
WHERE first_char = 'A'
) into a limit 2000:
SELECT A song_id from song_lib
Inner a.singer_id the Join singer_lib B = ON and first_char b.singer_id = 'A' limit 2000
3. when inserting duplicate key determination, using ON dUPLICATE kEY UPDATE:
INSERT INTO db_action.action_today (user_id, song_id, action_count) values (1,1,1) the ON KEY the UPDATE action_count the DUPLICATE = action_count +. 1;
4. avoid using a cursor
cursors Very low operating efficiency, it can increase the temporary table, the use of multi-table queries, multi-table updates, etc. to complete the task, do not use the cursor.
(Xi) the use of analysis of the situation Explain the SQL statement using the index
when you put in front of a keyword EXPLAIN SELECT statement, MySQL explain how it will deal with SELECT, provide information about how the table and join in what order coupled by means EXPLAIN , you can know when to be added to the index for the table to get a record using the index to find a faster SELECT, you can also see if the optimizer joins the tables with an optimal order. To force the optimizer to use a specific join order for a SELECT statement, add a STRAIGHT_JOIN clause. .
EXPLAIN general syntax of the command is: EXPLAIN <SQL commands> such as: explain select * from a inner join b on a.id = b.id
analysis parameters of EXPLAIN Detailed:
1.table: This is the name of the table.
2.type: type of connecting operation.
system: only one record (only a few practical application data table) Table
const: table up a matching line, with values for all part PRIMARY KEY or UNIQUE more often when the index,
such as: select * from song_lib where song_id = 2 (song_id table of primary key)
eq_ref: for each combination of rows from the front of the table, from the table with UNIQUE or PRIMARY KEY index read one line,
, such as: select * from song_lib a inner join singer_lib b on a.singer_id = b.singer_id (b type with a value of eq_ref)
REF: for each table from the foregoing line combination, from the table by the non-UNIQUE or PRIMARY KEY read row index
Such as: select * from song_lib a inner join singer_lib b on a.singer_name = b.singer_name and
select * from singer_lib b where singer_name = 'ccc' (b type with a value of the ref, because b.singer_name ordinary index)
ref_or_null: The coupling type as REF, but adds a row MySQL can search specifically contain nULL values,
such as: SELECT * from singer_lib WHERE singer_name = 'CCC' or singer_name iS null
index_merge: the coupling type indication index combined optimization method
Key: it shows the name of the index MySQL actually used. If it is empty (or NULL), then MySQL does not use the index.
key_len: the length of the index portion is used, in bytes.
3.ref: ref column shows which columns or constants use together with the key to select rows from the table
4.rows: MySQL perceived it to scan the number of records before finding the correct result. Clearly, here the ideal number is 1.
5.Extra: many different options here may appear, most will have a negative impact on the query. Generally:
a using where: indication of where conditions
using filesort: indicate the use of file sorting, which is using the order by clause, and did not use the index in order by field, requiring
additional sequencing overhead, so if it means using filesort appear sort of low efficiency, need optimization, such as forced index
method (force index) of