Article Directory
Choose optimized data type
There are many data types supported by MySQL, and choosing the right data type is essential for high performance.
The following simple principles can help make better choices:
更小的通常更好
简单就好
避免NULL
The default storage engine in this article is InnoDB
Integer type
There are two types of numbers: integers and real numbers.
If you store integers, you can use these integer types: TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT. Use 8, 16, 24, 32, and 64-bit storage space respectively. They can be stored in the range from -2^(N-1) to 2^(N-1)-1.
The integer type has an optional UNSIGNED attribute, which means that negative values are not allowed, which can roughly double the upper limit of integers. Signed and unsigned types use the same storage space and have the same performance, so you can select the appropriate type according to the actual situation.
For real numbers, DECIMAL.
String type
VARCHAR and CHAR are the main string types.
VARCHAR:
Usually used to store variable-length strings, and is the most common string data type. It is more space-saving than the fixed-length type because it only uses the necessary space.
VARCHAR will use one or two bytes to store the size of the space, but because the row is variable length, it is more troublesome during UPDATE. If the space occupied by a row grows, but there is no more space to use on this page, InnoDB will need to split the page to make the row fit into the page.
In this case, it is suitable to use VARCHAR:
the maximum length of the string column is much larger than the average length;
column updates are few, so fragmentation is not a problem;
a complex character set like UTF-8 is used, and each character uses a different The number of bytes is stored.
CHAR: The
CHAR type is fixed-length. When storing CHAR values, MySQL will delete all trailing spaces. CHAR values will be filled with spaces as needed to facilitate comparison.
CHAR is suitable for storing very short strings, or all values are close to a length. For frequently changing values, CHAR is also better than VARCHAR, because fixed-length CHAR types are not prone to fragmentation. For very short columns, CHAR is also more efficient than VARCHAR. For example, when storing one character, VARCHAR also has one byte to record the length.
To reiterate: how data is stored depends on the storage engine, and in this article we only talk about InnoDB
BLOG and TEXT types
Both BLOG and TEXT are string data types designed for storing large amounts of data, and are stored in binary and string modes respectively.
They belong to two different data type families:
TINYTEXT, SMALLTEXT, TEXT, MEDIUMTEXT, LONGTEXT
TINYBLOG, SMALLBLOG, BLOG, MEDIUMBLOG, LONGBLOG
Use enumeration (ENUM) instead of string
Sometimes you can use enumerated columns instead of commonly used string types.
Enumeration columns can store some unique strings into a predefined collection. MySQL is very compact when storing enumerations, and will be compressed into one or two bytes according to the number of list values. MySQL will internally save the position of each value in the list as an integer and store it in the .frm file of the table. Save the lookup table of the "number-string" mapping relationship.
Here is a chestnut:
Try to avoid using numbers as ENUM enumeration constants.
Problems in MySQL schema design
Although there are some good or changed design principles, there are also some problems caused by the implementation mechanism of MySQL, which means that it is possible to make some specific errors that only occur under MySQL.
1. Too many columns
The operation cost of converting encoded columns into data structures from the row buffer is very high.
If you plan to use thousands of fields, you must be aware that the performance and operating characteristics of the server will be somewhat different.
2. Too many associations
If you want the query to be executed quickly and with good concurrency, it is best to associate a single query within 12 tables.
3. Almighty enumeration
should avoid excessive use of enumeration.
