First, select the optimal data type

(1) smaller and better

Select the type does not exceed the minimum range, because it takes up less memory, CPU cache and processing cycles, disk.

E.g. DATETIME and TIMESAMP column can store the same types of data: date and time, accurate to the second, but only TIMESAMP DATETIME half the storage space.

(2) simple enough

Simple types reduce CPU processing cycles. E.g. shaping operation is lower than the cost of characters, character set as collation complex than plastic

(3) try to avoid NULL

The best designated as NOT NULL, NULL value unless it really needs to be stored. If the query contains a NULL column more difficult to query optimization, as can be NULL columns makes the index, statistics, value comparisons are more complex and can be NULL columns using more storage space. When the column is NULL may indexes, each requires a record of the amount of bytes.

1.1, integer type

If the storage can be an integer TINYINT, SMALLINT, MEDIUMINT, INT, GIGINT, 16,24,32,64 were used as storage space, are typically 64-bit integer calculation is BIGINT integer , MySQL may specify, for example, the width of an integer INT (11) but does not make sense, it can be directly used BIGINT.

1.2, real type

Is a real number with a fractional part. Floating point FLOAT, DOUBLE and DEDCIMAL type can specify precision, because of the extra space and computing overhead, so try to use only DECIMAl only when an accurate calculation of the decimal (for example, financial data)

Case: DECIMAL (18,9): on both sides of each of the memory 9 decimal digit, a total of 9 bytes before and after the decimal point of each four bytes, one byte decimal.

1.3, string type

(1) VARCHAR type for storing variable length strings, VARCHAR less space than a fixed-length type CHAR , because it is necessary to use the space (the space of a short string using fewer)

Case: Use VArCHAR (5) and VArCHAR (200) storage 'hello' in the space overhead is the same, that the use of shorter (5) lists what advantage?

A: The great advantage of longer columns will consume more memory, because MySQL will allocate a fixed size memory block to store internal value, typically assigned only the size of the space really need the best.

(2) BLOB and TEXT type

String data type is to Heng maybe great data designed, and the characters are stored in binary. Try to avoid using in practice, poor performance

1.4 Date and Time Types

TIMESAMP DATETIME using only half the storage space, costs less, is more commonly used.

DATETIME save larger value, from 1001 to 9999, the date and time of the package to an integer YYYYMMDDHHMMSS usually displayed as "2019-01-01 22:23:08" This display criteria;

TIMESAMP save the number of seconds since January 1, 1970, it is the integer storage, Guarantee time display.

Second, the cache table and summary tables

Sometimes saving derived from the same table redundant data can also improve performance , such as "statistics."

Cache table: for those relatively easily obtain memory (but slower each acquired) from another table data table;

Summary: Save the GROUP BY statement is to use aggregate tables of data

2.1 Summary

Case: 24 hours before calculating the number of messages sent, query the most active users, a common label, which some typical examples.

To 24 hours before calculating the number of messages sent as a case:

(1) per hour can generate a summary table, such a simple query can be done, and maintain than real-time counter and efficient, is not strictly count;

(2) the summary table can also be based on strict count, the count full before 23 hours of statistical tables all together, plus the final count in the beginning and not the full hour, assuming statistical called msg_per_hr. The following from "High Performance MySQL" Case:

Either way - not strictly count or by small-scale inquiry fill the gap strict count of all rows in the table than the calculated message effectively, because real-time calculation is very expensive to operate, because most of the data to scan the table.

2.2, cache table (Table intermediate)

Cache table and summary tables opposite way, to optimize its search and retrieval query is very effective, these queries typically require special table and index structure.

Case: requires a combination of many different types of families of index query, then need to create a cache table contains only the main part of the column in the table, you can use different storage engines on the cache table , for example, if the primary table using InnoDB buffer MyISAM table is used as a storage engine index will be smaller footprint, and can do full-text search.

2.3, counter table

Save counter in the table, you may encounter concurrency issues when updating counter. The number of applications such as caching counter a user's friends, such as file downloads. You can create a separate table, query cache failure can be avoided

Third, accelerate the speed of operation of ALTER TABLE

alter table to large table is a big problem. Internal generally created when you modify the structure of the table with a new love you with an empty table, find out all the data from the old table insert a new table, and then delete the old table.

This operation will take a lot of time, if not enough memory table and large in particular.

3.1, only modify .frm file

But not all will cause the reconstruction, the default value for the column actually exist .frm file table , so you can directly modify the file without the need to modify the table itself, to change the default value for a column by ALTER COLUMN operation:

3.2, quickly create MyISAM index

(1) If the index table is MyISAM, quickly update the table there is a common technique: heart ah disabled index, load the data and then re-enable the index (the index will lead to faster queries, additions and deletions slow):

After building the index because the work is delayed until the data is fully loaded, this time can be constructed by sorting the index, this will be much faster, and makes the index less tree debris, more compact (but unique index is invalid).

InnoDB version (2) of the current version

Delete all non-unique index, and then add a new column, and finally re-create the deleted index.