MySQL数据库在长期运行过程中，会因为业务迭代产生大量冗余数据、无效记录，这些数据会占用额外的存储空间，拖慢查询和写入速度，因此针对性地进行数据减肥是提升数据库性能的重要手段。
数据减肥的核心方向
数据减肥不是盲目删除数据，而是从存储、结构、索引三个层面针对性优化，核心方向包括以下几个方面：
- 清理无用历史数据，减少数据总量
- 优化表字段类型和长度，降低单条记录存储空间
- 调整索引结构，删除冗余无效索引
- 处理碎片化的存储空间，提升空间利用率
具体数据减肥操作方法
1. 清理冗余和无效数据
首先要梳理业务中的无效数据场景，比如超过保留期限的操作日志、已删除用户的关联冗余记录、测试产生的垃圾数据等。可以通过定期执行删除语句清理这些数据，同时建议配合归档操作，将需要留存的历史数据迁移到归档表或者冷存储中，避免误删重要数据。
以下是一个清理超过1年且状态为已失效的操作日志的示例：
-- 先查询确认要删除的数据范围，避免误删 SELECT COUNT(*) FROM operation_log WHERE create_time < DATE_SUB(NOW(), INTERVAL 1 YEAR) AND status = 'invalid'; -- 确认无误后执行删除操作，建议分批删除避免锁表 DELETE FROM operation_log WHERE create_time < DATE_SUB(NOW(), INTERVAL 1 YEAR) AND status = 'invalid' LIMIT 10000;
2. 优化表字段结构
很多表的字段在设计时预留了过大的长度或者使用了不合适的类型，比如用VARCHAR(255)存储固定长度的手机号，用BIGINT存储范围很小的状态值，这些都会浪费存储空间。可以根据实际业务场景调整字段类型和长度：
- 状态类字段如果取值范围小，优先用
TINYINT代替INT或者BIGINT - 固定长度的字符串用
CHAR代替VARCHAR，避免额外的长度存储开销 - 存储时间戳优先用
INT或者BIGINT代替DATETIME，占用空间更小
以下是修改字段类型的示例：
-- 将用户状态字段从INT改为TINYINT，长度从11改为4 ALTER TABLE user_info MODIFY COLUMN user_status TINYINT(4) NOT NULL DEFAULT 0 COMMENT '用户状态 0正常 1冻结 2注销'; -- 将手机号字段长度从255调整为11 ALTER TABLE user_info MODIFY COLUMN phone_number VARCHAR(11) NOT NULL COMMENT '用户手机号';
3. 清理冗余索引
索引可以提升查询速度，但过多的冗余索引会占用额外的存储空间，还会拖慢写入和更新的速度。可以通过sys.schema_unused_indexes视图查看长期未使用的索引，结合业务查询场景删除冗余索引。
以下是查询未使用索引的示例：
-- 查询当前数据库中未被使用的索引 SELECT * FROM sys.schema_unused_indexes WHERE object_schema = 'your_database_name';
删除冗余索引的示例：
-- 删除user_info表上冗余的idx_phone索引 DROP INDEX idx_phone ON user_info;
4. 处理表碎片空间
MySQL的InnoDB引擎在删除数据后，不会立即释放磁盘空间，会产生碎片化的存储，导致表的实际占用空间远大于有效数据大小。可以通过OPTIMIZE TABLE命令重建表，释放碎片空间。
操作示例如下：
-- 重建user_info表，释放碎片空间，注意该操作会锁表，建议在低峰期执行 OPTIMIZE TABLE user_info;
数据减肥后的效果验证
完成数据减肥操作后，可以通过以下方式验证效果：
- 查看表的大小变化，对比减肥前后的存储空间占用
- 执行常用的查询语句，对比查询耗时是否有明显下降
- 查看数据库的写入和更新的响应时间，确认是否有提升
以下是查询表大小的示例：
-- 查询指定数据库中所有表的大小，单位MB
SELECT
table_name,
ROUND(((data_length + index_length) / 1024 / 1024), 2) AS table_size_mb
FROM information_schema.tables
WHERE table_schema = 'your_database_name'
ORDER BY table_size_mb DESC;
注意事项
数据减肥操作涉及数据修改和表结构变更，执行前一定要做好全量备份，避免操作失误导致数据丢失。删除数据和修改结构时，建议分批执行，避免大操作导致数据库锁表影响业务正常运行。如果是核心业务库，建议先在测试环境验证操作的可行性和效果，再应用到生产环境。