MySQL数据文件导致实例空间满的解决办法_空间/内存_常见问题_云数据库 RDS 版-阿里云 https://help.aliyun.com/knowledge_detail/101642.html
查看数据库的文件大小，分析其中可以删除的历史数据文件或无用数据文件。
SELECT file_name, concat(TOTAL_EXTENTS,'M') as 'FIle_size' FROM INFORMATION_SCHEMA.FILES  order by TOTAL_EXTENTS
MySQL Binlog日志的生成和清理规则_数据备份/恢复_常见问题_云数据库 RDS 版-阿里云 https://help.aliyun.com/knowledge_detail/41815.html
Binlog日志的生成规则
MySQL实例空间内生成binlog日志的规则如下：
通常情况下，当前binlog大小超过500MB或超过6小时会切换到下一序号文件继续写入，即写满500MB或超过6小时就会生成新的binlog日志文件。新的binlog文件继续写入，老的binlog文件并不会立刻上传，会异步上传。
有些情况下，binlog日志不满500MB就不再写入，比如由于命令的执行、系统重启等原因。
有些情况下，会出现binlog文件尺寸超过500MB的情况，比如当时在执行大事务，不断写入binlog导致当前binlog文件尺寸超过500MB。
Binlog日志的保存及清理规则
MySQL实例的空间内默认清理binlog日志的规则如下：
实例空间内默认会保存最近18个小时内的binlog文件。
当实例使用空间小于购买空间的80%时，系统会保存购买空间的30%的binlog(即使该binlog文件已经上传到OSS内)。
当实例使用空间超过购买空间的80%时，binlog会在上传到OSS后，发起删除本地数据的请求，但本地删除会有任务调度，有一定延迟。
Binlog文件上传到OSS后，才可以在RDS控制台上显示。查看步骤如下：
选择要管理的实例所在的地域。
单击目标实例右的ID，进入基本信息页面。
在左侧导航栏中，选择备份恢复，进入备份恢复页面。
选择日志备份标签页，即可查看已上传的binlog日志。
Binlog日志在后台生成，可在RDS控制台中下载，大概需要30~60分钟，如果binlog文件较大，所需时间更长。

小结：
1、避免并行大大事务对磁盘、内存的消耗；
MySQL数据文件导致实例空间满的解决办法_空间/内存_常见问题_云数据库 RDS 版-阿里云 https://help.aliyun.com/knowledge_detail/101642.html
MySQL实例可能会由于查询语句的排序、分组、关联表产生的临时表文件，或者大事务未提交前产生的binlog cache文件，导致实例空间满，为避免数据丢失，RDS会对实例进行自动锁定，磁盘锁定之后，将无法进行写入操作。
查看数据库的文件大小，分析其中可以删除的历史数据文件或无用数据文件。
SELECT file_name, concat(TOTAL_EXTENTS,'M') as 'FIle_size' FROM INFORMATION_SCHEMA.FILES  order by TOTAL_EXTENTS
MySQL Binlog日志的生成和清理规则_数据备份/恢复_常见问题_云数据库 RDS 版-阿里云 https://help.aliyun.com/knowledge_detail/41815.html
Binlog日志的生成规则
MySQL实例空间内生成binlog日志的规则如下：
通常情况下，当前binlog大小超过500MB或超过6小时会切换到下一序号文件继续写入，即写满500MB或超过6小时就会生成新的binlog日志文件。新的binlog文件继续写入，老的binlog文件并不会立刻上传，会异步上传。
有些情况下，binlog日志不满500MB就不再写入，比如由于命令的执行、系统重启等原因。
有些情况下，会出现binlog文件尺寸超过500MB的情况，比如当时在执行大事务，不断写入binlog导致当前binlog文件尺寸超过500MB。
Binlog日志的保存及清理规则
MySQL实例的空间内默认清理binlog日志的规则如下：
实例空间内默认会保存最近18个小时内的binlog文件。
当实例使用空间小于购买空间的80%时，系统会保存购买空间的30%的binlog(即使该binlog文件已经上传到OSS内)。
当实例使用空间超过购买空间的80%时，binlog会在上传到OSS后，发起删除本地数据的请求，但本地删除会有任务调度，有一定延迟。
Binlog文件上传到OSS后，才可以在RDS控制台上显示。查看步骤如下：
选择要管理的实例所在的地域。
单击目标实例右的ID，进入基本信息页面。
在左侧导航栏中，选择备份恢复，进入备份恢复页面。
选择日志备份标签页，即可查看已上传的binlog日志。
Binlog日志在后台生成，可在RDS控制台中下载，大概需要30~60分钟，如果binlog文件较大，所需时间更长。
后续维护
对于经常有delete操作的表，容易产生数据空洞，可以在业务低峰期使用optimize table .回收空间。
后续维护
针对查询产生的临时文件，应该优化SQL语句，避免频繁使用 order by、group by 操作，可以适当调大tmp_table_size和max_heap_table_size，但是为了减少磁盘使用而调高 tmp_table_size 和 max_heap_table_size 并不明智，因为内存资源远比磁盘资源宝贵；可以通过explain+SQL语句查看是否使用内部临时表，在 Extra 字段中有 Using temporary 字样的代表会使用内部临时表。示例如下：
explain select * from alarmgroup by created_on order by default;
针对binlog cache，应该少执行大事务，尤其应该减少在多个连接同时执行大事务，如果大事务比较多，可以适当调大binlog_cache_size，但是同样不应该为了节省磁盘调整这个参数，使用短连接执行大事务可以有效降低临时空间开销。
现场：
中午对同张表的补数据时，并行大事务提交导致临时文件激增消耗500G的有限空间。;<1>刚才又删除了多余数据后，现在是500G用了约70%；<2>空间回收优化的sql还在执行中，会进一步降低利用率；<3>程序这边今后也避免对单张大表的并行大事务提交；

                    
压缩数据库日志及数据库文件大小
    我无论看什么样的书籍总想和自己的工作挂上钩，在繁密的文字中来查找自己所要的信息，在自己工作中所遇到的一些难题总想在其他资料中找到相关的文字，所以我们懂得的越少就要看越多的书籍，谁也不知道什么时候能用得上，单位的数据库越来越庞大，查询速度越来越慢，我结合单位数据库的真实情况来操作如何压缩数据库日志及其数据库文件，这些内容虽然大家都熟悉，如果静下心来再看一遍我自己的这篇文章，就能感觉到他的实践性和针对性是多么的强，直接按这些步骤去执行就可以了，不要问关于这方面的知识点是什么。
    因为单位用的数据库名为svw,如果其他单位或个人想快捷方便无误的压缩数据库日志，就把数据库名更改为你们自己的数据库名，压缩数据库日志的操作步骤：
 
1、打开企业管理器

2、打开要处理的数据库

3、点击菜单>工具>SQL查询分析器

4、在输入窗口里面输入:

DUMP TRANSACTION [数据库名] WITH NO_LOG

BACKUP LOG [数据库名] WITH NO_LOG

DBCC SHRINKDATABASE([数据库名])

点击执行！这样子数据库就操作成功了。
 
上面操作我一直在用，不会出现任何问题，而我这些天想找能够直接压缩数据库文件的方法都不大理想，下面我刚采用了如下方式进行数据库日志及其数据库文件压缩操作，日志压缩的比较理想，数据库文件也有效果，可是不能直接填写你想压缩数据库文件的数字，无论怎么样，还是写出来与大家分享。
 


  下面的所有库名都指你要处理的数据库的库名。
　　1.清空日志
　　DUMP TRANSACTION 库名 WITH NO_LOG
　　2.截断事务日志：
　　BACKUP LOG 库名 WITH NO_LOG
　　3.收缩数据库文件（RU 不压缩,数据库的文件不会减小 ）
 
　　企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件-数据库文件 ：
　　--选择日志文件--收缩操作-收缩文件至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了
　　--选择数据文件--收缩操作-收缩文件至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了
 
    看起来好像操作复杂，其实实际应用中很简单，这样数据库文件就能压缩了，我的数据库文件压缩前是3.92G，压缩后为3.66G，而在收缩操作里不能随意填写你想压缩的数字，后面告诉你最小压缩数字，不能填写比压缩数字在小的数字了。


 

本文转自 jiangxuezhi2009 51CTO博客，原文链接：http://blog.51cto.com/jiangxuezhi/744732，如需转载请自行联系原作者

        
        
                
    

由于网站数据量的增加，ldf文件也在不断变大，如果改变其大小呢，
看如下代码
 --aaaaaaa是数据库名

Backup Log aaaaaaa WITH no_log
GO
DUMP TRANSACTION aaaaaaa WITH no_log
GO
USE aaaaaaa 
DBCC SHRINKFILE (2)
GO
代码只在本地电脑上的sql2005上运行执行成功，在服务器上语句报错，暂未有解决办法
执行成功后ldf大小为1~3M左右