Several Suggestions for reducing MySQL to save disk space

When we work, we often come across 1 client with TPS\QPS that is not very high, but very large disk footprint,1 single instance space is too large, such as memory, network, CPU, and backup will increase the corresponding overhead. May be just because of the space is not satisfied so that we have to carry out the expansion, the following method to provide you with reference. If there is any change, there will be no improvement.
1. Table structure design
1) Whether the character set follows the minimization principle ? If you can use latin, don't use gbk. If you can use gbk, don't use utf8)
2) Is there any abuse on the index? (Build indexes for fields that are not used at all, fields that are not suitable for building indexes, duplicate indexes, or poor use of prefix indexes, etc.)
3) Are there too many redundant fields? (Unused in each table or too many redundant fields)
4) Incorrect field type? (Use only a few bytes if you can use 1 byte, such as enumeration class, state class is common)
5) Use long fields or combinations of fields as the primary key? (mysql autoincrement is best for primary keys)
Specific examples are as follows:

CREATE TABLE `class_meta` (
`class_name` varchar(128) NOT NULL COMMENT ' The name of the class ',
`class_desc` varchar(2048) default '' COMMENT ' The description of the class ',
`class_status` char(20) default 'test1' COMMENT 'test1,test2',
PRIMARY KEY (`class_name`),
UNIQUE KEY `cm_cn_uk` (`class_name`),
KEY `cm_cd_ind` (`class_desc`(767)),
KEY `cm_cs_ind` (`class_status`),
KEY `cm_cdcn_ind` (`class_desc`(767),`class_name`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='meta information ';

You can see from the table structure above that the following does not fit
1. The primary key and only one index are clearly duplicated, the index cm_cd_ind and the index cm_cdcn_ind are duplicated (this happens frequently, please note)
2. cm_cs_ind Is obviously not suitable for indexing if the two states are evenly distributed
3. class_desc is not suitable for indexing because it is descriptive in nature
4, it is better to do the primary key, can reduce the space of the whole table
5. The class_status column can obviously be stored in tinyint, saving 19 bytes

2. Store content
1) Whether to store big data such as pictures, videos and music in tables? (It is better to keep only the path in the table rather than the actual file contents)
3. Data retention
1) Whether there is expired data that has not been deleted ? (Timely clean up the invalid data or file the history)
4. Late maintenance
1) Whether to maintain frequently deleted tables (optimize table)

Advice:
1. In case, where performance requirements are low (concurrency is not high), consider using compressed tables. 1. The general compression rate is between 30% and 70%, and the yield is very considerable.
2. For tables that are deleted very frequently, optimization should be carried out regularly to reduce the fragmentation in the table. Improve query, write performance.
3, in the table structure design, 1 must carry forward the spirit of "haggling over every detail", can be expressed with a byte resolutely not two bytes.
4. Minimize the use of large fields.

ps: When I talk to the development review form structure, I am often joked that DBA is too stingy and not very generous at all. When small amount of data may not feel, but when your data to T or P, even save a few bytes are very considerable, a simple bill to you, if we are going to 1 piece of 500 million records in the table, field from 100 bytes to 60 bytes (should be very easy to do it), so not on index about 18 G will save space.