- Database object naming specification
- Database objects
- Global naming conventions for database objects
- Database naming rules
- Table naming conventions
- Field naming conventions
- Index naming conventions
- View naming conventions
- Stored procedure naming conventions
- Function naming conventions
- Trigger naming conventions
- Constraint naming conventions
- User naming conventions
- Database object design specification
- Choice of storage engine
- Character set selection
- Table design specification
- Field design specification
- Index design specification
- Constraint design specifications
- SQL Use standard
- select Normative retrieval
- Standardization of operation
- Procedural constraints
Database object naming specification
Database objects
Database objects are part of the database , The common ones are the following ： surface （Table ）、 Indexes （Index）、 View （View）、 Chart （Diagram）、 The default value （Default）、 The rules （Rule）、 trigger （Trigger）、 stored procedure （Stored Procedure）、 user （User） etc. . Naming conventions refer to database objects, such as databases （SCHEMA）、 surface （TABLE）、 Indexes （INDEX）、 constraint （CONSTRAINTS） And so on .
Global naming conventions for database objects
1、 Naming uses meaningful English words , Words are separated by underscores
2、 Only English letters can be used for naming 、 Numbers 、 Underline , Start with an English letter
3、 Avoid using MySQL The reserved words are as follows ：backup、call、group etc.
4、 All database objects use lowercase letters , actually MySQL You can set case sensitivity in , To ensure uniformity , All of our specifications are in lowercase .
Database naming rules
1、 Database naming should not exceed 30 Characters .
2、 The database name is generally the project name + Abbreviation for library meaning , such as IM Workflow database for the project , It can be im\_flow.
3、 The default character set and collation clause must be added when the database is created . The default character set is UTF8（ Moved dumbo Use utf8mb4）
4、 Names should be in lowercase .
Table naming conventions
1、 The general table name starts with t\_ start ,t representative table It means , The naming rule is t + modular （ Abbreviations that contain the meaning of modules ）+ surface （ Abbreviation containing the meaning of the table ）, For example, the education information table of the user module ：t\_user\_eduinfo.
2、 A temporary table （RD、QA or DBA Table used by students for temporary data processing ）, Naming rules ：temp Prefix + modular + surface + Date suffix ：temp\_user\_eduinfo\_20210719
3、 Backup tables （ Used to save and archive historical data or data for disaster recovery ） Naming rules ,bak Prefix + modular + surface + Date suffix ：bak\_user\_eduinfo\_20210719
4、 Tables of the same module use the same prefix as much as possible , The name of the table should mean as much as possible
5、 Underline multiple words \_ Separate
6、 The name of a regular table should not exceed 30 Characters ,temp Table and bak The table depends on the situation , Also try to be brief , Names should be in lowercase
Field naming conventions
1、 Field names need to represent the actual meaning of English words or abbreviations , Underline words \_ Connect , Such as service\_ip、service\_port.
2、 Fields with the same meaning between tables must have the same name , such as a Table and b All tables have creation time , It should be unified as create\_time, Inconsistency can be chaotic .
3、 Underline multiple words \_ Separate
4、 The field name should not exceed 30 Characters , Naming should be in lowercase
Index naming conventions
1、 Unique index usage uni + Field name Named after the ：create unique index uni\_uid on t\_user\_basic(uid) .
2、 Non-unique index usage idx + Field name Named after the ：create index idx\_uname\_mobile on t\_user\_basic(uname,mobile) .
3、 Underline multiple words \_ Separate .
4、 The index name should not exceed 50 Characters , Naming should be in lowercase , The combined index should not have too many fields , Otherwise, it is not conducive to the improvement of query efficiency .
5、 Multi word column names , Take abbreviations that represent meaning as much as possible , Such as test\_contact surface member\_id and friend\_id Composite index on ：idx\_mid\_fid.
6、 Understand the leftmost prefix principle for composite indexes , Avoid duplicate index construction , If you set up (a,b,c), It's kind of set up (a), (a,b), (a,b,c).
View naming conventions
1、 The view name starts with v start , Express view, The complete structure is v+ View content meaning abbreviation .
2、 If the view only comes from a single table , Then for v+ Table name . If the view is generated by the association of several tables, use v+ Underline （\_） Connect several table names , The view name should not exceed 30 Characters . Exceed 30 Characters are abbreviated .
3、 If there is no special need , Developers are strictly prohibited from creating views .
4、 Names should be in lowercase .
Stored procedure naming conventions
1、 The stored procedure name starts with sp start , Represents a stored procedure （storage procedure）. Then underline multiple words （\_） Connect . The function of stored procedure should be reflected in its naming . Try not to exceed the stored procedure name 30 Characters .
2、 The input parameters in the stored procedure are expressed in i\_ start , Output parameters in o\_ start .
3、 Names should be in lowercase .
create procedure sp_multi_param(
in i_id bigint,
in i_name varchar(32),
out o_memo varchar(100)
)
Function naming conventions
1、 The function name is func Start , Express function. Then underline multiple words （\_） Connect , Function naming should reflect its function . The function name should not exceed 30 Characters .
2、 Names should be in lowercase .
create function func_format_date(ctime datetime)
Trigger naming conventions
1、 Trigger to trig start , Express trigger trigger .
2、 The basic part , Describe the table added by the trigger , The trigger name should not exceed 30 Characters .
3、 suffix （\_i,\_u,\_d）, Indicates the trigger mode of the trigger condition （insert,update or delete）.
4、 Names should be in lowercase .
DROP TRIGGER IF EXISTS trig_attach_log_d;
CREATE TRIGGER trig_attach_log_d AFTER DELETE ON t_dept FOR EACH ROW;
Constraint naming conventions
1、 Unique constraint ：uk\_ The name of the table \_ Field name .uk yes UNIQUE KEY Abbreviation . For example, add a unique constraint to the Department name of a department , To ensure that there are no duplicate names , as follows ：ALTER TABLE t\_dept ADD CONSTRAINT un\_name UNIQUE(name);
2、 Foreign key constraints ：fk\_ Table name , Followed by the table name of the foreign key and the corresponding main table name （ Not included t\_）. Child and parent table names are underlined (\_) Separate . as follows ：ALTER TABLE t\_user ADD CONSTRAINT fk\_user\_dept FOREIGN KEY(depno) REFERENCES t\_dept (id);
3、 Non empty constraint ： If there is no special need , It is recommended that all fields be non empty by default (not null), Different data types must give default values (default).
4、 For performance reasons , If there is no special need , Foreign keys are not recommended . Referential integrity is controlled by code . This is also our common practice , Integrity control from a procedural perspective , But if you don't pay attention to , It also produces dirty data .
5、 Names should be in lowercase .
User naming conventions
1、 The user naming format used in production is code\_ application
2、 The read-only user naming rule is read\_ application
Database object design specification
Choice of storage engine
1、 If there is no special need , You have to use innodb Storage engine .
Can pass show variables like 'default\_storage\_engine' To view the current default engine . There are mainly MyISAM and InnoDB, from 5.5 The version starts to use by default InnoDB engine .
The basic difference is ：MyISAM Types do not support advanced processing such as transaction processing , and InnoDB Type of support .MyISAM Type tables emphasize performance , Its execution speed ratio InnoDB The type is faster , Transaction support is not provided , and InnoDB Provide transaction support and external key and other advanced database functions .
Character set selection
1、 If there is no special requirement , You have to use utf8 or utf8mb4.
At home , Choose one with perfect support for Chinese and all languages utf8 Format is the best way ,MySQL stay 5.5 Increase after utf8mb4 code ,mb4 Namely most bytes 4 It means , Designed to be compatible with four bytes unicode.
therefore utf8mb4 yes utf8 Superset , In addition to changing the code to utf8mb4 There is no need to make any other conversion . Of course , To save space , In general use utf8 That's enough. .
You can use the following script to view the encoding format of the database
SHOW VARIABLES WHERE Variable_name LIKE 'character_set_%' OR Variable_name LIKE 'collation%';
SHOW VARIABLES Like '%char%';
Table design specification
1、 The association between database tables corresponding to different applications should be reduced as much as possible , Associating tables with foreign keys is not allowed , Ensure the independence between the tables corresponding to the components , Provides the possibility of refactoring a system or table structure . At present, the practice in the industry is generally Program controlled referential integrity .
2、 Table design should not be aimed at the whole system database design , It should be divided according to the components in the system architecture , Design database for the business processed by each component .
3、 The watch must have PK, The advantage of a primary key is that it uniquely identifies 、 Valid references 、 Efficient retrieval , Therefore, in general, try to have primary key fields .
4、 A field represents only one meaning .
5、 A table should not have repeating Columns .
6、 Do not use complex data types ( Array , Customization, etc ),Json The use of type depends on the situation .
7、 need join Field of ( Connection key ), Data types must be absolutely consistent , Avoid implicit conversions . For example, the associated fields are int type .
8、 The design should at least meet the third paradigm , Minimize data redundancy . Some special scenarios allow anti normal design , But in the project review, it is necessary to explain the design of redundant fields .
9、TEXT Fields are stored as large volume text , Must be placed in a separate table , use PK Associated with main table . If there is no special need , No use TEXT、BLOB Field .
10、 You need to delete... On a regular basis ( Or transfer ) A table of overdue data , Solve by dividing tables , Our approach is to follow 2/8 The rule migrates the historical data with low operation frequency to the historical table , According to time or once Id Make a cutting point .
11、 Don't count too many fields in a single table , It is recommended not to be greater than 50 individual . It also has a great impact on the performance of the watch .
12、MySQL When dealing with large watches , The performance starts to decrease obviously , Therefore, it is recommended to limit the physical size of a single table to 16GB, The number of data rows in the table shall be controlled at 2000W Inside .
The rules of the industry are more than 2000W Performance began to degrade significantly . But this value is flexible , You can test according to the actual situation to judge , For example, Ali's standard is 500W, Baidu is indeed 2000W. In fact, whether the wide table , The space occupied by single line data plays a role .
13、 If the data volume or data growth is large in the early planning , Then, in the design review, we should add the tabulation strategy , Later, there will be a special article to analyze the practice of data splitting ： Split Vertically （ Vertical database and vertical table ）、 Horizontal split （ Sub warehouse and sub table and intra warehouse sub table ）;
14、 No special needs , It is strictly forbidden to use the partition table
Field design specification
1、INT： If there is no special need , Store integer numbers for use UNSIGNED INT type , The number after the integer field represents the display length . such as id int(11) NOT NULL
2、DATETIME： All need to be accurate to time ( Minutes and seconds ) The fields of are all in DATETIME, Do not use TIMESTAMP type .
about TIMESTAMP, It converts the write time from the current time zone to UTC（ World standard time ） For storage . When inquiring , Convert it to the current time zone of the client to return . And for DATETIME, Don't make any changes , It's basically the original input and output .
in addition DATETIME The storage range is also relatively large ：
timestamp The range of time that can be stored is ：'1970-01-01 00:00:01.000000' To '2038-01-19 03:14:07.999999'.
datetime The range of time that can be stored is ：'1000-01-01 00:00:00.000000' To '9999-12-31 23:59:59.999999'.
But in special cases , For business across time zones ,TIMESTAMP More appropriate .
3、VARCHAR： All dynamic length strings All use VARCHAR type , Fields with limited categories like status , You can also use strings that clearly represent the actual meaning , Instead of using INT Instead of ;VARCHAR(N),
N Represents the number of characters rather than the number of bytes . such as VARCHAR(255), It can store up to 255 Characters （ Characters include English letters , Chinese characters , Special characters, etc ）. but N It should be as small as possible , because MySQL All... In a table VARCHAR The maximum length of the field is 65535 Bytes , And the number of stored characters is determined by the selected character set .
Such as UTF8 Store a character at most 3 Bytes , that varchar In storage 3 Characters of byte length should not exceed 21845 Characters . meanwhile , When sorting and creating temporary tables , Will use N The length of the request memory .( If there is no special need , In principle, a single varchar Type field cannot exceed 255 Characters )
4、TEXT： Only if the number of characters may exceed 20000 When it's time , Can be used TEXT Type to store character data , Because all MySQL Database will use UTF8 Character set .
All use TEXT Fields of type must be split from the original table , The primary key of the original table is stored in another table , Isolation from large text fields , The purpose is . If there is no special need , Don't use MEDIUMTEXT、TEXT、LONGTEXT type
5、 For precise floating point data storage , Need to use DECIMAL, Do not use FLOAT and DOUBLE.
6、 If there is no special need , Try not to use BLOB type
7、 If there is no special need , It is recommended to use NOT NULL attribute , Default values can be used instead of NULL
8、 Autoincrement field type must be integer and must be UNSIGNED, The recommended type is INT or BIGINT, And the auto increment field must be a primary key or a part of the primary key .
Index design specification
1、 Index differentiation
The index must be created on the index （ Degree of differentiation ） On the higher column , The alternative calculation is : selecttivity = count(distinct c\_name)/count(*) ; If the discrimination result is less than 0.2, It is not recommended to create an index on this column , Otherwise, the rate will probably slow down SQL perform
2、 Follow the leftmost prefix
For identifying multiple fields that need to form a composite index , When designing, it is recommended to put the fields with high selectivity forward . When using , First field of Composite Index , Must be in where In the condition , And it needs to match according to the leftmost prefix rule .
3、 Foreign keys are not allowed , Integrity can be constrained at the program level
4、Text Type field if you need to create an index , Must use prefix index
5、 In theory, the index number of a single table should be controlled at 5 Within a . There is often a mass insert 、 Update operation table , Index should be minimized , The principle of index establishment is theoretically a scenario of reading more and writing less .
6、ORDER BY,GROUP BY,DISTINCT The fields of need to be added after the index , Form coverage index
7、 Correctly understand and calculate the discrimination of index field , There are calculation rules , High resolution index , You can quickly locate data , The distinction is too low , Can't use index effectively , You may need to scan a large number of data pages , It's no different than not using an index .
8、 Correctly understand and calculate the field length of prefix index , There are rules of judgment , The appropriate length should ensure high discrimination and the most appropriate index storage capacity , Only when you are at your best , It is the index that ensures high efficiency .
9、 Union index pays attention to the leftmost matching principle ： Must match from left to right ,MySQL The index is matched to the right until a range query is encountered (>、<、between、like) And then stop matching .
Such as ：depno=1 and empname>'' and job=1 If set up (depno,empname,job) Index of order ,job There is no index .
10、 Strategy on demand , When looking up records , Don't use it as soon as you come up *, Just take the data you need , If possible, use only index coverage , It can reduce the operation of returning table , Improve efficiency .
11、 Judge whether to use union index correctly （ The above section about the use of union index has the rules of judgment ）, We can also further analyze the index push down （IPC）, Reduce the return operation , Improve efficiency .
12、 The principle of avoiding index invalidation ： Disable the use of functions... On index fields 、 Operator operation , Will invalidate the index . This is actually the field corresponding to the index ” Cleanliness “.
13、 Avoid unnecessary type conversions , When string fields are compared with numeric values, the index will be invalid .
14、 Fuzzy query '%value%' Will invalidate the index , Change to full scan , Because it's impossible to determine the scan range , however 'value%' The index can be used effectively .
15、 Index override sort field , This reduces the sorting steps , Improve query efficiency
16、 Expand the index as much as possible , There is no need to create a new index . Let's say it's already in the table a The index of , Now want to add (a,b) The index of , All you need to do is change the original index .
For example ： For example, a brand table , The index established is as follows , A primary key index , A unique index
PRIMARY KEY (`id`),
UNIQUE KEY `uni_brand_define` (`app_id`,`define_id`)
When the search statement in your colleague's business code is as follows , It should be warned immediately , That is, the index is not overwritten , Not according to the leftmost prefix principle ：
select brand_id,brand_name from ds_brand_system where status=? and define_id=? and app_id=?
It is suggested to read as follows ：
select brand_id,brand_name from ds_brand_system where app_id=? and define_id=? and status=?
Constraint design specifications
1、PK It should be orderly and meaningless , Customized by developers , Be as brief as possible , And it's a self increasing sequence .
2、 Divide... In the table PK outside , There are also unique constraints , Can be created in the database to “uk\_” A unique constraint index as a prefix .
3、PK Fields are not allowed to update .
4、 Prohibit creation of foreign key constraints , Foreign key constraints are controlled by the program .
5、 If there is no special need , All fields must have non empty constraints , namely not null.
6、 If there is no special need , All fields must have default values .
SQL Use standard
select Normative retrieval
1、 Avoid using select *,join Statements use select * It may lead to the query that can be completed only by accessing the index needs to fetch data back to the table .
One is that it is possible to take out a lot of unnecessary data , For wide tables , This is a disaster ; One is to avoid returning to the table as much as possible , The performance is low because some unnecessary data is retrieved and returned to the table , It's not cost-effective .
2、 Do not use select * from t\_name , Without any where Conditions , It's the same thing , This will turn into a full table full field scan .
3、MySQL Medium text The type field stores ：
3.1、 Not stored with other common fields , Because the reading efficiency is low , It will also affect the access efficiency of other lightweight fields .
3.2、 If you don't need to text The type field , And used it again. select *, This execution will consume a lot of io, It's also inefficient
4、 You can use the correlation function... On the fetch field , But avoid as much as possible now() , rand() , sysdate() Wait for the function of the uncertain result , stay Where It is strictly forbidden to use any function on the filter condition field in the condition , Including data type conversion functions . A lot of calculation and conversion will lead to inefficiency , This is also described in the index .
5、 All paging query statements need to have sorting conditions , Otherwise, it is easy to cause disorder
6、 use in()/union Replace or, The efficiency will be better , And pay attention in Is less than 300
7、 Do not use % Prefix fuzzy prefix query : Such as ：select a,b,c from t_name where a like ‘%name’; have access to % Fuzzy suffix query such as ：select a,b from t_name where a like ‘name%’;
8、 Avoid subqueries , The subquery can be optimized to join operation
Usually the subquery is in in clause , And the subquery is simple SQL( It doesn't contain union、group by、order by、limit clause ) when , To be able to turn the sub query into an associated query for optimization .
Reasons for poor subquery performance ：
「·」 The result set of a subquery cannot use an index , Usually the result set of a subquery is stored in a temporary table , Indexes do not exist for either in-memory or disk temporary tables , So query performance Will be affected to some extent ;
「·」 Especially for subqueries that return large result sets , The greater the impact on query performance ;
「·」 Since subqueries produce a large number of temporary tables, there are no indexes , So it will consume too much CPU and IO resources , Generate a lot of slow queries .
Standardization of operation
1、 Do not use a list of fields INSERT sentence
Such as ：insert into values ('a','b','c'); You should use insert into t\_name(c1,c2,c3) values ('a','b','c'); .
2、 Mass write operations （UPDATE、DELETE、INSERT）, The operation needs to be carried out many times in batches
- Large volume operations can cause significant master-slave delays , Especially in master-slave mode , Large volume operations can cause significant master-slave delays , Because of the need slave from master Of binlog Read logs in to synchronize data .
- binlog Log for row The format generates a lot of logs
Procedural constraints
In the follow-up, our team's goal is to develop a review tool to build a database of the documents submitted by the development students 、 Build table 、 Brush data 、 Query statements for analysis , See if it meets the due specifications . If it doesn't meet , Reject the amendment .
