1. Basic Specifications
Item 1: You must use the InnoDB storage engine
Interpretation: support for transactions, row-level locks, better concurrent performance, CPU and memory cache page optimization to make resource utilization higher
Article 2: You must use the utf8 (utf8mb4) character set
Interpretation: Universal code, no need to transcode, no risk of garbled characters, save space, utf8mb4 is a superset of utf8, due to the increase of mobile devices in recent years, emoji expressions and some uncommon Chinese characters will appear garbled under utf8, so you need to upgrade to utf8mb4
Article 3: Chinese comments must be added to data tables and data fields
Interpretation: Who will know what the a1, a2, a3 fields are for after N years
Article 4: Prohibit the use of stored procedures, views, triggers, and Events
Interpretation: For the Internet business with high concurrency and big data , the architectural design idea is to "liberate the database CPU and transfer the calculation to the service layer" . In the case of a large amount of concurrency, these functions are likely to drag the database to death, and the business logic can be placed in the service layer. Better scalability, can easily achieve "adding machines and adding performance" . The database is good at storage and indexing, so the CPU calculation should be moved up.
Article 5: Prohibit the storage of large files or large photos
Interpretation: Why let the database do what it is not good at? Large files and photos are stored in the file system, how good is it to store URIs in the database
Second, the naming convention
Item 1: Only allow the use of intranet domain names instead of ip to connect to the database
Interpretation: Although IP access is faster and domain name access requires intranet dns, domain name is better for the expansion and migration of large databases
Article 2: Online environment, development environment, and test environment The database intranet domain name follows the naming convention
Business name: xxx Online environment: dj.xxx.db Development environment: dj.xxx.rdb Test environment: dj.xxx.tdb Add -s after the name of the slave database, and add -ss after the name of the standby database. Slave library: dj.xxx-s.db Online standby library: dj.xxx-sss.db
Article 3: Library name, table name, field name: lowercase, underscore style, no more than 32 characters, it is forbidden to mix Pinyin and English
Interpretation: See the name and know the meaning, which is convenient for follow-up maintenance
Article 4: Table name t_xxx, non-unique index name idx_xxx, unique index name uniq_xxx
Interpretation: See the name and know the meaning, which is convenient for follow-up maintenance
Three, table and field design specifications
Item 1: The use of foreign keys is prohibited. If there are foreign key integrity constraints, application control is required
Interpretation: foreign keys will cause coupling between tables, update and delete operations will involve associated tables, which will greatly affect the performance of SQL and even cause deadlocks. In the case of high concurrency, it is easy to cause database performance, and the use of databases in high-concurrency business scenarios with big data is based on performance .
Item 2: The field must be defined as NOT NULL and a default value provided
Interpretation: a) Null columns make index/index statistics/value comparison more complicated, and it is more difficult for MySQL to optimize b) This type of null requires special processing inside MySQL, which increases the complexity of database processing records; under the same conditions , when there are many empty fields in the table, the processing performance of the database will be reduced a lot c) The null value requires more storage space, whether it is the null column in each row in the table or the index, additional space is required to identify d ) When dealing with null, only is null or is not null can be used, but the operation symbols such as =, in, <, <>, !=, not in cannot be used. For example: where name!='shenjian', if there is a record whose name is null, the query result will not include records whose name is null
Article 3: Prohibit the use of TEXT and BLOB types
Interpretation: It will waste more disk and memory space, and unnecessary large field queries will eliminate hot data, resulting in a sharp decrease in the memory hit rate and affecting database performance
Article 4: Prohibit the use of decimals to store national currency
Interpretation: I have stepped on such a pit once, 100 yuan is amortized in 3 days, amortized every day (100/3) yuan, and the result is 3 33.33. Later, when the reconciliation system was implemented, there was always a few cents that were inconsistent, and I was depressed for a long time (it was not about the cents, it was the questioning eyes of the business side that made R&D very uncomfortable), and finally found that it was the division to blame. Solution: use " points" as the unit, so that the database is an integer
Article 5: You must use varchar(20) to store the phone number
Interpretation: a) When the area code or country code is involved, +-() may appear b) Does the mobile phone number perform mathematical operations? c) varchar can support fuzzy query, for example: like "138%"
Article 6: The use of ENUM is prohibited, and TINYINT can be used instead
Interpretation: a) Add a new ENUM value to do DDL operation b) The actual internal storage of ENUM is an integer, do you think you define a string?
Article 7: The table must have a primary key, such as an auto-incrementing primary key
Interpretation: a) The primary key is incremented, and data row writing can improve the insertion performance, avoid page splits, reduce table fragmentation, improve space and memory usage b) Select a shorter data type for the primary key, and the ordinary index of the Innodb engine will save the value of the primary key , a shorter data type can effectively reduce the disk space of the index and improve the cache efficiency of the index. c) Delete a table without a primary key, and the master-slave architecture in row mode will cause the standby database to stagnate.
Fourth, index design specifications
Article 1: It is recommended that single-table indexes be controlled within 5
Interpretation: A good index design can increase your efficiency by dozens or even hundreds of times, but too much will be counterproductive
Article 2: The number of single index fields is not allowed to exceed 5
Interpretation: When there are more than 5 fields, it can no longer effectively filter the data.
Article 3: It is forbidden to build indexes on attributes that are updated very frequently and are not highly discriminative
Interpretation: a) Updates will change the B+ tree, and indexing of frequently updated fields will greatly reduce database performance. b) For a property with little discrimination, such as "gender", it is meaningless to build an index. It cannot effectively filter data. Full table scan is similar
Item 4: To build a composite index, you must put the fields with high discrimination in the front
Interpretation: can filter data more effectively
Five, SQL usage specification
Item 1: Prohibit the use of SELECT *, only get the necessary fields, and need to display the description column attributes
Interpretation: a) Reading unnecessary columns will increase CPU, IO, and NET consumption b) Covering indexes cannot be effectively used c) Using SELECT * is prone to program bugs after adding or deleting fields
Item 2: Prohibit the use of INSERT INTO t_xxx VALUES(xxx), the column attributes of the specified insert must be displayed
Interpretation: It is easy to have program bugs after adding or deleting fields
Item 3: Prohibit the use of implicit conversion of attributes
Interpretation: SELECT uid FROM t_user WHERE phone=13812345678 will result in a full table scan, but cannot hit the phone index, guess why? The int data type has a higher priority than archer. The query will convert phone to int, so all data in the table needs to be changed to int, so it is necessary to scan the phone completely. The phone is a varchar type, and the SQL statement brings in an integer, so it will not hit Index, just add quotes: SELECT uid FROM t_user WHERE phone='13812345678'
Item 4: Do not use functions or expressions on properties of WHERE conditions
Interpretation: SELECT uid FROM t_user WHERE from_unixtime(day)>='2017-02-15' will result in a full table scan. The correct wording is: SELECT uid FROM t_user WHERE day>= unix_timestamp('2017-02-15 00:00: 00')
Article 5: Prohibit the use of JOIN queries for large tables, and prohibit the use of subqueries for large tables
Interpretation: Temporary tables will be generated, which consume a lot of memory and CPU, and greatly affect database performance. Large tables refer to tables with more than 10 million data.
Article 6: The use of OR conditions is prohibited and must be changed to IN query
Interpretation: The OR query of the old version of Mysql cannot hit the index. Even if it can hit the index, why should the database consume more CPU to help implement query optimization?
Article 7: Negative queries and fuzzy queries starting with % are prohibited
Interpretation: a) Negative query conditions: NOT, !=, <>, !<, !>, NOT IN, NOT LIKE, etc., will result in a full table scan b) Fuzzy queries at the beginning of % will lead to a full table scan generally It is said that the WHERE filter condition will not only have such a "negative query condition", but there will be other filter conditions, for example: querying orders other than orders that Shen Jian has completed (it's a mouthful): SELECT oid FROM t_order WHERE uid =123 AND status != 1; The order table has 5000w data, but uid=123 will quickly filter the amount of data to a small level (the uid is indexed), and it doesn't matter if you connect a negative query condition at this time Now, the number of rows scanned will be very small, but if you want to query all orders other than completed orders: SELECT oid FROM t_order WHERE status != 1; Query results in a full table scan
Item 8: The application must catch SQL exceptions and handle them accordingly
Interpretation: easy maintenance, timely "checking and filling vacancies"
Summary: Internet services with large amounts of data and high concurrency are not allowed to use those that greatly affect database performance.