mysql table design specifications

Naming conventions

Table names and field names must use lowercase letters or numbers, and no English abbreviations are used.

It doesn’t matter if it’s a little longer, it’s best to let other developers know about it.

Primary key index name: pk_field name Unique index name: uk_field name Common index name: jdx_field name

Choose the appropriate field type

Choose field types with small storage space as much as possible, tinyint smallint int bigint start from left to right

type of data	characteristic	scenes to be used
`tinyint`	1-byte signed integer, ranging from -128 to 127 or 0 to 255 (unsigned)	Stores booleans, status, flags, and other data with low range values
`smallint`	2-byte signed integer, ranging from -32,768 to 32,767 or 0 to 65,535 (unsigned)	Store small integer values, such as year, order quantity, etc.
`int`	4-byte signed integer, ranging from -2,147,483,648 to 2,147,483,647 or 0 to 4,294,967,295 (unsigned)	Store regular integer values, such as user ID, age, amount, etc.
`bigint`	8-byte signed integer, the value range is -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 or 0 to 18,446,744,073,709,551,615 (unsigned)	Store large integer values, such as primary keys, order numbers, etc.

Decimal type, such as amount, select decimal

Be sure to use bidecimal, Shigen has filled in a huge bug written by predecessors!

The stored string lengths are almost equal, using the char fixed-length string type.
varchar variable length string, the length should not exceed 5000
If the stored value is too large, change the field type to text and create a separate table with the primary key corresponding to it.

Choose the appropriate field length

Optimize the storage space of data. If the field length is set too large, storage space will be wasted. If the field length is set too small, it may cause data truncation or insertion failure.

Prioritize logical deletion over physical deletion

Difficulty in recovering physically deleted data
Physical deletion will make the primary key no longer continuous
It is not recommended to physically delete data in core business tables.

Common fields required by every table

Different common fields have different names in English, but they are all recommended in the specification.

id	significance	must
create_time	creation time	must
update_time	Change the time	must
version	optimistic locking	not necessary
reamrk	Data annotation	not necessary
modified_by	Modifier	not necessary
creator	founder	not necessary

Don’t have too many fields in a table

Do not exceed 20 fields. If the table has too many fields, the data stored in the table may be very large, and the query efficiency will be reduced. Just split the large table into small tables and make their primary keys the same.

Use not null to define fields whenever possible

Set the field to an empty string or constant value

not null prevents null pointer problems
The storage of null values also requires additional space, resulting in more complex comparison operations and making it difficult for the optimizer to optimize SQL.
Null values may cause index failure

design index

Fields with query conditions generally need to be indexed

The index of a single table should not exceed 5
Fields that are not highly distinguishable do not add indexes (gender)
Avoid index failure (mysql built-in function)
Too many indexes, use joint index optimization

Do not use foreign key associations

There are performance issues, concurrency deadlock issues, and inconvenience in using foreign keys. Every delete and update must consider foreign key constraints
Sub-database and sub-table cannot be used

It is not recommended to use stored procedures and triggers

Stored procedure:

One or more sql statements that have been precompiled into an executable procedure

trigger:

A piece of code that automatically executes when an event is triggered

Cascading modifications can be implemented using related tables in the database
Monitor changes in a field in a table and take appropriate action
Generate certain business numbers
Abuse causes database and application maintenance difficulties
MySQL is not very mature for stored procedures, triggers, etc., and does not have complete error record processing. It is not recommended to use it.

Optimization experience in sql writing

Try not to use select * for queries
If the query result only needs one record or only the largest/smallest record, it is recommended to use limit 1.
Avoid using or in where clause to connect conditions
Optimize limit depth paging problem
where conditions limit the data to be queried to avoid returning redundant rows
Avoid expression operations on fields in where clauses
For index optimization, you should consider adding indexes to the columns involved in where and order by.
Too much data has been inserted. Select batch insertion.