Original link: https://www.jianshu.com/p/359ed85c3243
Applicable scene: concurrent capacity, the amount of data of Internet services
First, the basic norms
1. recommended to use the InnoDB storage engine
It supports transactions, row-level locking, better concurrent performance, CPU and memory cache page optimization allows higher utilization of resources
2. Use the UTF8 character set
Unicode, without transcoding, no garbled risk, save space
3. Data tables, data fields must join Chinese comments
4. prohibit the use of high concurrency scenarios stored procedures, views, triggers, the Event
High concurrency large Internet data services, architecture design idea is to "liberate database CPU, will be transferred to the computing service layer" at large concurrent case, these functions are likely to slow death database, business logic into the service layer with better scalability, can be easily achieved "by the machine will increase performance." It specializes in database storage and indexing, CPU computing or move it
5. Never store large files or large photo
Let the database do it not good things? Large files and photos stored in the file system, database, how good save URI
Second, the naming convention
1. The online within the environment, development environment, test environment database domain name follows the naming convention
Business Name: xxx
online environment: dj.xxx.db
development environment: dj.xxx.rdb
test environment: dj.xxx.tdb
from the library after the name add -s logo, prepared by the library after the name plus -ss identity
online from the library: dj.xxx-s.db
online library Preparation: dj.xxx-sss.db
2. The library name, table names, field names: lowercase, underline style, no more than 32 characters, you must see to know the name is intended to prohibit the English alphabet mix
3. The table name t_xxx, non-unique index name idx_xxx, unique index name uniq_xxx
Third, the design rules of Table
1. The number of instances of a single table must be less than 500
2. Single Number table column 30 must be less than
3. The table must have a primary key, e.g. increment primary key
Interpretation :
A) Increment the primary key, the data row write performance can be improved insertion, page division avoided, reducing the use of space and the lifting table fragmentation of memory
Value b) to select the primary key data type short, an ordinary engine Innodb primary key index are stored, shorter data type index can effectively reduce disk space, Cache efficiency index
c) delete the table without a primary key, the main row pattern from architecture, will lead to the standby database live ram
Fourth, field design specifications
1. The field must be defined as NOT NULL and provide default values
Interpretation :
a) null columns in the index / index statistics / value comparisons are more complex, more difficult for the optimization of MySQL
b) null MySQL this type require special handling inside, increasing the complexity of the database records processed; time under the same conditions, the table has more empty fields, database processing performance much reduced
c) null values require more storage space, whether it is null columns in the table or index each row needs additional space to identify
d) the processing time of the null, but to use is null, or is not null, and not with =、in、<、<>、!=、not inthe operation symbols. Such as: where name!=’shenjian’if there nameis a nullrecord value, the query results will not include the value of the name is null record
2. It is prohibited to use TEXT, BLOB Types
Will waste more disk space and memory, a large number of non-essential data will heat a large field of inquiry eliminated, resulting in drastically reduced memory hit rate, affect database performance
3. prohibit the use of decimal currency storage
It uses integer, decimal easily lead to money not on (to be divided into units Statistics)
4. You must use varchar (20) to store the phone number
Interpretation:
a) related to the area code or country code, may appear + - ()
b) phone number will do the math it?
c) varcharto support fuzzy queries, such as:like“138%”
5. prohibited ENUM, may be used instead of TINYINT
Interpretation:
a) adding new ENUM values do DDL operations
Internal b) ENUM actual storage is an integer, you think you are the definition of string?
Fifth, the index design specifications
1. Single proposed control table index within 5
2. single index number field does not allow more than five
When the field is more than 5, it had no effect actual data of the effective filtration
3. Prohibition index is updated frequently, discrimination is not high property
Interpretation:
a) update will change the B + tree, frequently updated field indexing can greatly reduce database performance
b) is not "sex" discrimination of this property, indexing is meaningless, can not effectively filter the data, and performance similar to a full table scan
4. Establish combination index, identifies the field must be high on the front
Can more effectively filter the data
Six, SQL Use
1. Prohibition of the Use SELECT *, to obtain only the necessary field, needs to display the Description column properties
Interpretation:
a) reading unneeded columns increases CPU, IO, NET consumption
b) can not effectively use a covering index
c) using SELECT * BUG prone procedures after adding or removing fields
2. banned INSERT INTO t_xxx VALUES(xxx), inserted into the column must display the specified properties
BUG prone procedures after adding or removing fields
3. prohibited attribute implicit conversion
Cast will be a full table scan. SELECT uid FROM t_user WHERE phone=13812345678Will lead to full table scan, index and can not hit the phone, guess what? (This line problem appears more than once)
4. prohibited function or expression on the property WHERE condition
SELECT uid FROM t_user WHERE from_unixtime(day)>='2017-02-15'It will lead to full table scan
The correct wording is:SELECT uid FROM t_user WHERE day>= unix_timestamp('2017-02-15 00:00:00')
5. prohibit negative fuzzy query to the query, as well as the beginning of%
Negative query: NOT、!=、<>、!<、!>、NOT IN、NOT LIKEetc., will lead to full table scan
Fuzzy query% at the beginning, it will lead to a full table scan, rather than leading fuzzy query you can:select * from order where desc like 'XX%'
6. prohibit large table using JOIN query, prohibit large tables using subqueries
Will produce a temporary table, consumes more memory and CPU, greatly affect database performance
7. prohibit the use of OR conditions must be changed to IN query
Older versions of OR Mysql query can not hit the index, even if we can hit the index, why let consume more CPU database query optimization to help implement it?
8. The application must capture the SQL exception, and the corresponding processing
9. Data not discrimination field should not use the index
select * from user where sex=1When the index can be used, experience, data filtering 80%. For order status, if the state value is small, the index should not be used, if the state is worth a lot, can filter large amounts of data, it should be indexed.
10. If the service is mostly a single query, using the index Hash better performance, for example, the central user
select * from user where uid=?
select * from user where login_name=?
the reason:
- The time complexity of the index B-Tree is O (log (n))
- Hash index time complexity is O (1)
The most left-prefix 11. composite index, where the order does not refer to the SQL statement to be consistent and composite index
User Center established (login_name, passwd) composite index
select * from user where login_name=? and passwd=?
select * from user where passwd=? and login_name=?
We are able to hit the index
select * from user where login_name=?Also hit the index, a composite index meet the most left-prefix
elect * from user where passwd=?Can not hit the index, a composite index does not meet the most left-prefix
12. If you know exactly only one result is returned, limit 1 can improve efficiency
You know only one result, but the database does not know, explicitly tell it, let it take the initiative to stop cursor movement
13. The computing into the business layer instead of the database layer, in addition to saving data CPU, as well as unexpected query cache optimization results
● select * from order where date < = CURDATE()SQL is not a good practice, should be optimized as follows:
$curDate = date('Y-m-d');
$res = mysql_query(
'select * from order where date < = $curDate');
The reason: the release of the CPU of the database, multiple calls to the same incoming SQL, you can use the query cache