开发者学堂课程【云数据库优化经典案例：disk 100%场景优化】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/67/detail/1166
disk 100%场景优化
磁盘包含的三个部分
第九个为磁盘，磁盘包含的几个部分，第一个部分是数据，数据文件其实包括了数据和索引，Mysql 的表是索引和数据在一起，第二个是临时文件，第三个是日志文件。
1、数据空间
（1）采用optimize table收缩表空间；删除不必要的索引；
（2）使用tokudb压缩引擎；
数据文件索引和数据是在一起的，如果表里的索引非常多，创建了很多无效索引，就可能会把数据空间撑大，有两种极端情况，第一种是一个查询它可能有 where 条件里有五个字段的条件，它就按这五个条件单独建了个单面索引，可能这个时候针对两三个字段见一个组合索引就可以了，但是它建立了五个单面索引这是要注意的，这个时候要去删除不必要的索引；第二个是删除数据，Mysql 数据 与删除的 delete 是不会回收空间的，它只是作为一个逻辑删除 ，那这个时候要去做 optimize table 去回收空间，回收空间第一个要注意延迟，第二个要注意 IOPS 的使用。第二个就是可能日志性的也有，比如日志表，这个时候可以用压缩引擎，比如有一个用户他购买了一个 T,但是有800个 G 是存放日志表的，那这个日志表就可以用 tokudb 做一个压缩，可以压缩到100个 G 以内，所以采用适当的引擎可以节约空间。
2、日志空间问题
（1）减少大字段的使用
（2）使用truncate替代delete from;
下一个是日志空间，是binary logs 空间，第一个要减少大字段的使用，因为 Mysql 我们的 binary logs 采用的是 row 格式，比如说你做一个 delete 操作、插入操作、更新操作，主要是更新操作和删除操作它都会把大字段记入 binary logs 里，所以这个时候对表里的字段比如状态值做评分更新，那么这些大字段都会被带入 binary logs 里，进而会导致 binary logs 空间长的非常快；第二个是 delete，delete 时要产生很多binary logs 文件，如果我们用 delete from 去全面删除这个表，一定要用 truncate 去替换，因为 truncate 只有一条低调语句，如果 delete from 的话，比如全面删除一百万行数据，delete from 就是一百万行 binary logs ，那使用 truncate 的话就只有一行 truncate 句。
3、临时空间问题
（1）适当调大 sort_buffer_size;
（2）创建合适索引避免排序；
第三个是排序产生的临时文件，因为在排序时它会在 sort_buffer_size 里，如果对两个表整理后再去排序，这个结构就非常大，它就会超出 sort_buffer_size，就会产生临时文件，此时临时文件就会膨胀的非常大，进而导致适当空间涨的厉害，在这个时候就需要创建合适索引，规避排序，遇到过情况是一个T的空间，它用了七八百的临时空间也是需要注意的问题。
