Common database optimization

First, the design:

  1. Field avoid null values ​​appear, and query optimization null value is difficult to take up extra space index, suggesting default number 0 instead of null.
  2. Try to use INT instead of BIGINT, if the non-negative plus UNSIGNED (the value of such capacity will be doubled), of course, can use TINYINT, SMALLINT, MEDIUM_INT better.
  3. Instead of using the integer string or an enumeration type
  4. TINYINT instead of using the ENUM: the ENUM add a new value to be DDL operation
  5. Occupy two different byte range indicated: instead make use TIMESTAMP DATETIME
  6. Do not have too many single table field, within the recommended 20
  7. With integer to store IP
  8. Use varchar (20) stores phone number, do not use the whole: VARCHAR can fuzzy query, e.g. like ' 138% '
  9. You may be able to save the data using minimum data type Integer <date, time <char, varchar <blob
  10. Minimize the use of text, non-preferably by not sub-table

Second, the index

  1. The index is not possible, to create targeted based on the query, consider the query frequently listed in the where, group by, order by, on columns that appear in indexing clause, it can be used to check whether according to EXPLAIN index or full table scan
  2. Length of the small column, index fields as small as possible, because the database is stored in units of pages, one page of data will accommodate better
  3. Dispersion degree (multiple different values) are shown, placed in front of the joint index. View dispersion, is achieved by different statistical column values, count, the higher the degree of dispersion:
  4. Should be avoided fields NULL value judgment in the WHERE clause, it will cause the engine to give up using the index and full table scan
  5. Value distribution is sparse field is not suitable for building an index, such as "gender" only two or three values ​​of this field
  6. Character field to build only the prefix index
  7. Character is best not to field a primary key
  8. Without foreign keys, bound by the procedural guarantees
  9. Try not UNIQUE, bound by the procedural guarantees
  10. Idea and query sequence is consistent when using a multi-column index, delete unnecessary single index
  11. The most left-prefix understand the principle of the composite index, avoid duplication index, if the establishment of (a, b, c), equivalent to the establishment of (a), (a, b), (a, b, c)

 

Three, SQL written note Optimization

  1. Limit the use of the recording is defined query results
  2. Avoid select *, the fields will need to find listed
  3. Using a connection (join) instead subquery
  4. Split large delete or insert statement
  5. SQL can to find out by opening a slower slow query log
  6. Do not do arithmetic column: SELECT id WHERE age + 1 = 10, any operation on the columns will cause a table scan, which includes a database tutorial function, evaluate expressions, etc., when a query to the operation moved to the right side of the equal sign as far as possible
  7. sql statement as simple as possible: a sql only a cpu operation; big statement demolition small statement, reducing the lock time; a big sql entire library can be blocked
  8. OR rewritten IN: OR efficiency level is n, IN efficiency is log (n) level, in the number of recommended control in 200
  9. Do not function and triggers in applications to achieve
  10. Avoid% xxx-style inquiry
  11. Less JOIN: If you want to query JOIN, JOIN field must be the same type, and indexed using the same type are compared, such as by '123' and '123' ratio, ratio of 123 and 123
  12. Avoid the use in the WHERE clause! = Or <> operator, otherwise the engine to give up using the index and a full table scan
  13. For continuous values, without using BETWEEN IN: SELECT id FROM t WHERE num BETWEEN 1 AND 5
  14. Do not take a full list of data tables, to use LIMIT to pagination, page number and do not much

pending upgrade......

 

Guess you like

Origin blog.csdn.net/qq_38234594/article/details/91451622