Reference reading: Interpretation of 30 Military Regulations in 58 Daojia Database
The table structure design of the database often affects the performance in the later stage of the application, especially the performance after the number of users increases:
1. It conforms
to the paradigm of 3NF table, which is the first to conform to 1NF, to satisfy 2NF, and further to satisfy 3NF
. 1NF: that is, the column of the table. It is atomic and cannot be decomposed, that is, the column information cannot be decomposed. As long as the database is a relational database (mysql/oracle/db2/informix/sysbase/sql server), it will automatically satisfy 1NF
2NF: the records in the table are unique Yes, it satisfies 2NF. Usually we design a primary key to achieve this. The primary key generally does not contain business logic and is set to self-increasing
3NF: that is, there should be no redundant data in the table, that is, if the information of the table can be deduced, then A separate field should not be designed to store it. For example, the following design does not satisfy 3NF:
inverse 3NF: However, a database without redundancy may not be the best database. Sometimes, in order to improve operating efficiency, it is necessary to lower the paradigm standard and retain it appropriately redundant data. The specific approach is: Follow the third paradigm in conceptual data model design, and put the work of lowering the paradigm standard into consideration in physical data model design. Decreasing the paradigm is adding fields, allowing for redundancy.
In the case of a 1-to-N table, in order to improve efficiency, it may be possible to design fields in 1 to speed up 2. Generally speaking, try to choose UTF-8 for
character sets , although GBK uses more storage space than UTF-8 when storing Less, but UTF-8 is compatible with various languages. In fact, we don't have to sacrifice scalability for this storage space. In fact, if you want to convert from GBK to UTF-8 in the later stage, the cost is very high, data migration is required, and the storage space can be solved by spending money to expand the hard disk. 3. When using the innodb of mysql, the primary key needs to be added when designing the table: Add a primary key, and it is best to increase it automatically. For insert:
Because the self-incrementing primary key allows the inserted data to be inserted into the leaf nodes of the underlying B+ tree in the order of the primary key, because it is sequential, this kind of insertion hardly needs to move other existing data, so the insertion efficiency is very high.
If the primary key is not self-incrementing, then the value of the primary key is approximately random each time. At this time, it may be necessary to move a large amount of data to ensure the characteristics of the B+ tree, which increases unnecessary overhead.
For query:
The reason is that the underlying storage model of innodb is a B+ tree, which uses the primary key as the clustered index and the inserted data as the leaf node. The leaf node can be quickly found through the primary key, so as to quickly obtain records
. 4. Field
(1) only Use only numeric fields
for fields with numeric information. Try not to design character fields for fields with only numeric information. This will reduce query and connection performance and increase storage overhead. This is because the engine will compare each character in the string one by one when processing the query and connection, and for the numeric type, only one comparison is enough
(2) To store decimals, it is recommended to use decimal,
not float and double. Storage of decimals will lose precision
(3) Try to use varchar/nvarchar instead of char/nchar First, variable-length fields have small storage space, which can save storage space, and secondly, for queries, the search efficiency in a relatively small field is obviously higher some. Secondly, the length of the varchar type is not recommended to exceed 8K.
When designing the length, the numbers in the parentheses should be as few as possible, except for the need for padding
(4) It is recommended to use Datetime
instead of timestamp for the time type, although Datetime occupies 8 bytes and timestamp only occupies 4 bytes, but the latter It is guaranteed to be non-null, and the latter is timezone-sensitive.
(5) To save a large amount of data, it is recommended to save large text data in a special file storage system. Only the access address of this file is saved in mysql. For example, blog articles can be saved in a file, and only the relative address of the file is saved in mysql. It is recommended to use Text/blob to save a large amount of data, because reading and writing large text will cause a relatively large I/O overhead, and occupy the MySQL cache at the same time, which will greatly reduce the throughput of the database under high concurrency
(6) In the design When selecting a field, it is recommended that the field must add the not null constraint, and set the default value, especially the index field and query conditions must be set
. (7) It is recommended that two fields, gmt_create and gmt_modified, be added to the table to record the modification time of data creation. The reason for the establishment of these two fields is to facilitate the investigation of problems.