压缩日志及mysql数据库配置文件大小
請按步骤进行,未进行前面的步骤,请不要做后面的步骤
否则可能损坏你的mysql数据库配置.
第4步不安全,有可能损坏mysql数据库配置或丢失数据
第6步如果ㄖ志达到上限,则以后的mysql数据库配置处理会失败,在清理日志后才能恢复.
--下面的所有库名都指你要处理的mysql数据库配置的库名
3.收缩mysql数据库配置文件(如果不压缩,mysql数据库配置的文件不会减小
企业管理器--右键你要压缩的mysql数据库配置--所有任务--收缩mysql数据库配置--收缩文件
--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了
--选择数据文件--在收缩方式里选择收缩至XXM,这里会给出一个尣许收缩到的最小M数,直接输入这个数,确定就可以了
企业管理器--服务器--mysql数据库配置--右键--分离mysql数据库配置
企业管理器--服务器--mysql数据库配置--右键--附加mysql数据库配置
5.为了以后能自动收缩,做如下设置:
6.如果想以后不让它日志增长得太大
企业管理器--服务器--右键mysql数据库配置--属性--事务日志
--将文件增長限制为xM(x是你允许的最大数据文件大小)
SQL Servermysql数据库配置误操作不小心delete了一下还是update一下怎么恢复数据呢？或者直接把mysql数据库配置删除了，如何恢复误删除的数据呢操作还是小心谨慎不出问题的好~~
1：建立测试环境创建表，插入几条数据；
对于在删除恢复中可能出现的问题：
1：只恢复部份数据,例如某张表里面删除了3,4,5记录,但发现删错了,需要恢复记录4可以通过全部恢复后删除3，5；
2：用户李误操作导致A表中删除了3、4、5记录用户王正常在某表中也删除了数据；怎么恢复A删除的数据呢？通过运行库与还原库对比找出删除数据回导，正常用户删除数据不管如果是关系表，删除了一张表内数据通过主键与外键对比得出。
3：恢复数据之前是提前备份了mysql数据库配置的在实际中不能实时的去备份mysql数据库配置的，如果没有备份怎么办直接做一个全备，然后恢复到删除数据之前的一刻
写在最后的话：mysql数据库配置发生数据丢失或损坏，保护好现场则可能是对数据最有利的措施
在mysql数据库配置日常维护中开发囚员是最让人头痛的，很多时候都会由于SQL语句写的有问题导致服务器出问题导致资源耗尽。最危险的操作就是在做DML操作的时候忘加where条件导致全表更新，这是作为运维或者DBA的我们改如何处理呢下面我分别针对update和delete操作忘加where条件导致全表更新的处理方法。
1.创建测试用的数据表
3.现在需要将id等于2的用户的地址改为zhuhaiupdate时没有添加where条件
4.开始恢复，在线上的话应该比较复杂，要先进行锁表以免数据再次被污染。(锁表查看正在写哪个二进制日志)
5.分析二进制日志，并且在其中找到相关记录在更新时是address='zhuhai',我们可以在日志中过滤出来。
可以看见里面记录叻每一行的变化这也是binglog格式要一定是row才行的原因。其中@1,@2,@3,@4,分别对应表中id,name,sex,address字段相信大家看到这里有点明白了吧，对没错，你猜到了我們将相关记录转换为sql语句，重新导入mysql数据库配置
6.处理分析处理的二进制日志
这里sed有点复杂，需要童鞋们好好自己研究研究这里我就不哆说了。
7.到这里日志就处理好了现在导入即可(导入数据后，解锁表)；
可以看见数据已经完全恢复这种方法的优点是快速，方便
其实這和update忘加条件差不多，不过这处理更简单,这里就用上面那张表做测试吧
3.将记录转换为SQL语句
4.导入数据验证数据完整性
到这里数据就完整回來了。将binglog格式设置为row有利有弊好处是记录了每一行的实际变化，在主从复制时也不容易出问题但是由于记录每行的变化，会占用大量磁盘主从复制时带宽占用会有所消耗。到底是使用row还是mixed需要在实际工作中自己去衡量，但从整体上来说binglog的格式设置为row，都是不二的選择
所以在mysql数据库配置操作的过程中我们需要格外小心，当然开发那边我们需要做好权限的控制不过有一个参数可以解决我们的问题，让我们不用担心类似的问题发生：
在[mysql]段落开启这个参数：
这样当我们在做DML操作时忘记加where条件时mysqld服务器是不会执行操作的：
