注意:以下文档只适用于TOP接口,请谨慎使用!

文档中心 > 聚石塔

RDS磁盘空间优化方案

更新时间:2015/09/18 访问次数:34564

RDS空间使用率过高

RDS的磁盘空间包括:数据文件空间、日志文件空间、临时文件空间、系统文件空间。下面将介绍这四块空间的优化。

1.数据文件空间

指的是存放数据的文件,对应到数据库中就是一张张的表,表的组成主要包括:数据和索引两类,数据文件占用实例的空间非常多的时候,需要看一下到底是哪一张表占用了空间。在设计应用的时候,就要考虑未来数据的增长趋势,合理的设计数据的存放位置(存放文件or数据库)、存储格式(数据类型,字段大小)、存放方式(存储引擎选择,分区还是分表)。

1)表结构设计

  1. 字符集遵循了最小化原则(能用latin的就不用gbk。能用gbk的就不用utf8)
  2. 索引上有滥用(根本不使用的字段建索引、不适合建索引的字段建索引、重复建索引、不能很好的利用前缀索引
  3. 冗余字段太多(各表中不用的或者字段冗余太多)
  4. 不正确的字段类型(能用1个字节非要用几个字节,像枚举类、状态类比较常见)
  5. 较长的字段或者几个字段组合做为主键(主键最好用mysql自增)

2)大字段占用空间

数据库采用了大字段varchar(8000)\nvarchar\varbinary\ntext\image\text\blob\clob(sqlserver/mysql),可能导致数据库日志飚升,达到或超过数据文件大小,导致实例被锁定。实际案例中,有的客户1小时增长超过100G。经过改进,将大部分字段调小,该问题消除。大字段的最大存储大小是 2^31-1 个字节 (2 GB),所以SQL Server需要用一种特别的方式来存储和操作它,其成本也就比普通字段高。而如果数据库使用了full模式,响应的日志量也就高很多了。

  1. 历史归档或文献资料类型的应用外,一般不需要用大字段来做存储。
  2. .将大字段存放到OSS
  3. 存储内容将图片、视频、音乐等大数据存储在表中?(表里最好只保留路径而不是实际的文件内容)
  4. 数据保留将有已过期而未删除的数据(对于无效数据及时清理或者进行历史归档)
  5. 尽量减少大字段的使用,在表结构设计上,一定要发扬“斤斤计较”的精神,能用1个字节表示的坚决不用2个字节。
  6. 修改大字段为小的字段,alter table XXX modify column ***

3)数据文件占用空间过大处理方法

  1. 使用delete删除历史数据,然后对表进行重建,回收表中的数据空间。delete的过程中会产生较多的binlog日志,磁盘总空间会上升比较快,待RDS自动清理binlog后,空间会自动下降;
  2. 清空整张表时,可以使用Truncate tableTruncate table 执行效率比delete高,可以更快释放表空间,注意数据安全,避免误操作;
  3. 删除不必要的索引
  4. 必要时进行数据库拆分或者弹性升级磁盘规格
  5. 收缩数据库 alter table
  6. optimize table 回收表空间, 使表中碎片减少,提高查询、写入的性能。一般压缩率在30%-70%之间,收益非常可观。optimize  table +表名,手动输入命令操作收缩数据库,在业务低峰期操作,停止表的读写,会加快收缩的速度,也可不停止表的读写,速度就会稍微慢点。收缩时会让binlog空间上涨,有时会导致锁住整张表。需要确认空间余量是否够,或者联系售后在后台关闭实例的空间检查

2.日志文件空间

日志文件增加的因素

  1. 数据库的更新写入压力过大:updateinsertdelete,导致日志急增
  2. 表结构设计中,过多使用大字段;

优化常见的方法

  1. 控制台一键清理binlog,清理之前会自动上传到OSS上,RDS也会定期将用户的日志进行清理并上传到OSS上,因此不用担心binlog的丢失。
  2. 对表结构中的大字段进行改造。

3.临时文件空间

临时文件产生的因素
一些查询语句(order by, group by)会创建临时表。用explain查看select语句的执行计划,如果extra列显示“using temporary”,即使用了内部临时表。使用临时表一般都意味着性能比较低,在实际应用中应该尽量避免临时表的使用。

tmpdir (临时空间)空间不够,导致程序报错,异常如下
The table /home/*** is full

 

优化临时空间的常见方法
a.
创建索引:在ORDER BY或者GROUP BY的列上创建索引;
b. 分拆很长的列:一般情况下,TEXTBLOB,大于512字节的字符串,基本上都是为了显示信息,而不会用于查询条件, 因此表设计的时候,应该将这些列独立到另外一张表。
如果表的设计已经确定,修改比较困难,那么也可以通过优化SQL语句来减少临时表的大小,以提升SQL执行效率。

出现临时空间快速增长时,可以通过show processlist找出正在排序的SQLkill掉查询;并进行SQL优化,添加必要的索引。

4. 系统文件空间

1.生产影响性能的系统文件因素

每个数据库在安装的时候会初始化一些系统文件,这些系统文件是数据库正常运行的前提,mysqlibdata1ib_logfile0sqlserverMSDBLogmaster.mdf

MySQL中有时会出现ibdata1占用空间过大,原因是:长时间没有提交事务,同时数据库中有大量的更新,插入,删除,导致innodb创建大量的undo来维护一致性;mysql 5.1undopurge是和master thread 共用一个线程,则可能的purge的速度到达了瓶颈,ibdata1文件中大量的都是undo_log

2. 系统文件优化方法

建议用户将版本从5.1升级到5.55.5中有独立的purge线程可以很快的回收掉undo log

5.6中可以单独设置undo tablespace文件,避免与ibdata1混用在一起;

 

案例

1.表格优化案例

CREATE TABLE `class_meta` (

`class_name` varchar(128) NOT NULL COMMENT ‘类名’,

`class_desc` varchar(2048) default COMMENT ‘类的描述’,

`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信息’;

通过上面的表结构能看到如下地方不合适

1、主键与唯一索引明显重复,索引cm_cd_ind与索引cm_cdcn_ind索引重复(这种情况经常出现,大家留意下)

2cm_cs_ind如果两个状态分布均匀也明显不合适建索引

3class_desc由于是描述性质的,也不合适建索引

4、最好以自增做为主键,可以减少整表的空间

5class_status列明显可以用tinyint来存,可以省下19个字节

FAQ

关于此文档暂时还没有FAQ
返回
顶部