本文目录一览：
MYSQL数据库 ROOR登陆以后右边空白如何修复
第一种方法：
安装MySQL的时候在这一步时它默认的服务名是“MySQL”
只需要把这个名字改了就可以了。可以把默认的服务器的名称改为“MySQL4”等其他名称。
PS：这种方法我试过，大二的时候成功了，但是前几天帮同学安装时候还是不行，依然不知道是什么问题导致的。
第二种方法
1、卸载MySQL
，停止MySQL服务
2、删除安装目录及数据存放目录
3、在注册表(regedit)查询mysql，全部删除
找到如下的注册表信息，删除MySQL目录
检查C:\WINDOWS目录下是否有my.ini文件,将其删除
4、在c盘查询MySQL，全部删除
5、重新安装就好了
PS：这种方法我也试过了，依旧不行。
经过无数次的失败后，我快疯了。
下面介绍我的终极解决方案
下载绿色版mysql，即解压之后修改配置文件（身为好人的我都帮你们修改好啦）便可以用啦（由于上传资源大小的限制不能给大家分享了，想要资源的留邮箱我这里只有32位的，叫我好人）送人玫瑰，手留余香。
mysql的表坏了怎么修复啊？
1. 表损坏的原因分析
以下原因是导致mysql 表毁坏的常见原因：
1、 服务器突然断电导致数据文件损坏。
2、 强制关机，没有先关闭mysql 服务。
3、 mysqld 进程在写表时被杀掉。
4、 使用myisamchk 的同时，mysqld 也在操作表。
5、 磁盘故障。
6、 服务器死机。
7、 mysql 本身的bug 。
2. 表损坏的症状
一个损坏的表的典型症状如下：
1 、当在从表中选择数据之时，你得到如下错误：
Incorrect key file for table: ’...’. Try to repair it
2 、查询不能在表中找到行或返回不完全的数据。
3 、Error: Table ’p’ is marked as crashed and should be repaired 。
4 、打开表失败： Can’t open file: ‘×××.MYI’ (errno: 145) 。
5 、
3. 预防 MySQL 表损坏
可以采用以下手段预防mysql 表损坏：
1 、定期使用myisamchk 检查MyISAM 表（注意要关闭mysqld ），推荐使用check table 来检查表（不用关闭mysqld ）。
2 、在做过大量的更新或删除操作后，推荐使用OPTIMIZE TABLE 来优化表，这样既减少了文件碎片，又减少了表损坏的概率。
3 、关闭服务器前，先关闭mysqld （正常关闭服务，不要使用kill -9 来杀进程）。
4 、使用ups 电源，避免出现突然断电的情况。
5 、使用最新的稳定发布版mysql ，减少mysql 本身的bug 导致表损坏。
6 、对于InnoDB 引擎，你可以使用innodb_tablespace_monitor 来检查表空间文件内文件空间管理的完整性。
7 、对磁盘做raid ，减少磁盘出错并提高性能。
8 、数据库服务器最好只跑mysqld 和必要的其他服务，不要跑其他业务服务，这样减少死机导致表损坏的可能。
9 、不怕万一，只怕意外，平时做好备份是预防表损坏的有效手段。
4. MySQL 表损坏的修复
MyISAM 表可以采用以下步骤进行修复 ：
1、 使用 reapair table 或myisamchk 来修复。
2、 如果上面的方法修复无效，采用备份恢复表。
具体可以参考如下做法：
阶段1 ：检查你的表
如果你有很多时间，运行myisamchk *.MYI 或myisamchk -e *.MYI 。使用-s （沉默）选项禁止不必要的信息。
如果mysqld 服务器处于宕机状态，应使用--update-state 选项来告诉myisamchk 将表标记为’ 检查过的’ 。
你必须只修复那些myisamchk 报告有错误的表。对这样的表，继续到阶段2 。
如果在检查时，你得到奇怪的错误( 例如out of memory 错误) ，或如果myisamchk 崩溃，到阶段3 。
阶段2 ：简单安全的修复
注释：如果想更快地进行修复，当运行myisamchk 时，你应将sort_buffer_size 和Key_buffer_size 变量的值设置为可用内存的大约25% 。
首先，试试myisamchk -r -q tbl_name(-r -q 意味着“ 快速恢复模式”) 。这将试图不接触数据文件来修复索引文件。如果数据文件包含它应有的一切内容和指向数据文件内正确地点的删除连接，这应该管用并且表可被修复。开始修复下一张表。否则，执行下列过程：
在继续前对数据文件进行备份。
使用myisamchk -r tbl_name(-r 意味着“ 恢复模式”) 。这将从数据文件中删除不正确的记录和已被删除的记录并重建索引文件。
如果前面的步骤失败，使用myisamchk --safe-recover tbl_name 。安全恢复模式使用一个老的恢复方法，处理常规恢复模式不行的少数情况( 但是更慢) 。
如果在修复时，你得到奇怪的错误( 例如out of memory 错误) ，或如果myisamchk 崩溃，到阶段3 。
阶段3 ：困难的修复
只有在索引文件的第一个16K 块被破坏，或包含不正确的信息，或如果索引文件丢失，你才应该到这个阶段。在这种情况下，需要创建一个新的索引文件。按如下步骤操做：
把数据文件移到安全的地方。
使用表描述文件创建新的( 空) 数据文件和索引文件：
shell mysql db_name
mysql SET AUTOCOMMIT=1;
mysql TRUNCATE TABLE tbl_name;
mysql quit
如果你的MySQL 版本没有TRUNCATE TABLE ，则使用DELETE FROM tbl_name 。
将老的数据文件拷贝到新创建的数据文件之中。（不要只是将老文件移回新文件之中；你要保留一个副本以防某些东西出错。）
回到阶段2 。现在myisamchk -r -q 应该工作了。（这不应该是一个无限循环）。
你还可以使用REPAIR TABLE tbl_name USE_FRM ，将自动执行整个程序。
阶段4 ：非常困难的修复
只有.frm 描述文件也破坏了，你才应该到达这个阶段。这应该从未发生过，因为在表被创建以后，描述文件就不再改变了。
从一个备份恢复描述文件然后回到阶段3 。你也可以恢复索引文件然后回到阶段2 。对后者，你应该用myisamchk -r 启动。
如果你没有进行备份但是确切地知道表是怎样创建的，在另一个数据库中创建表的一个拷贝。删除新的数据文件，然后从其他数据库将描述文件和索引文件移到破坏的数据库中。这样提供了新的描述和索引文件，但是让.MYD 数据文件独自留下来了。回到阶段2 并且尝试重建索引文件。
InnoDB 表可以采用下面的方法修复：
如果数据库页被破坏，你可能想要用SELECT INTO OUTFILE 从从数据库转储你的表，通常以这种方法获取的大多数数据是完好的。即使这样，损坏可能导致SELECT * FROM tbl_name 或者InnoDB 后台操作崩溃或断言，或者甚至使得InnoDB 前滚恢复崩溃。 尽管如此，你可以用它来强制InnoDB 存储引擎启动同时阻止后台操作运行，以便你能转储你的表。例如：你可以在重启服务器之前，在选项文件的[mysqld] 节添加如下的行：
[mysqld]innodb_force_recovery = 4innodb_force_recovery 被允许的非零值如下。一个更大的数字包含所有更小数字的预防措施。如果你能够用一个多数是4 的选项值来转储你的表，那么你是比较安全的，只有一些在损坏的单独页面上的数据会丢失。一个为6 的值更夸张，因为数据库页被留在一个陈旧的状态，这个状态反过来可以引发对B 树和其它数据库结构的更多破坏。
1 (SRV_FORCE_IGNORE_CORRUPT)
即使服务器检测到一个损坏的页，也让服务器运行着；试着让SELECT * FROM tbl_name 跳过损坏的索引记录和页，这样有助于转储表。
2 (SRV_FORCE_NO_BACKGROUND)
阻止主线程运行，如果崩溃可能在净化操作过程中发生，这将阻止它。
3 (SRV_FORCE_NO_TRX_UNDO)
恢复后不运行事务回滚。
4 (SRV_FORCE_NO_IBUF_MERGE)
也阻止插入缓冲合并操作。如果你可能会导致一个崩溃。最好不要做这些操作，不要计算表统计表。
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
启动数据库之时不查看未完成日志：InnoDB 把未完成的事务视为已提交的。
6 (SRV_FORCE_NO_LOG_REDO)
不要在恢复连接中做日志前滚。
数据库不能另外地带着这些选项中被允许的选项来使用。作为一个安全措施，当innodb_force_recovery 被设置为大于0 的值时，InnoDB 阻止用户执行INSERT, UPDATE 或DELETE 操作.
即使强制恢复被使用，你也可以DROP 或CREATE 表。如果你知道一个给定的表正在导致回滚崩溃，你可以移除它。你也可以用这个来停止由失败的大宗导入或失败的ALTER TABLE 导致的失控回滚。你可以杀掉mysqld 进程，然后设置innodb_force_recovery 为3 ，使得数据库被挂起而不需要回滚，然后舍弃导致失控回滚的表。
网上找的
MySQL数据库恢复(InnoDB)
你会备份，不能恢复。真的服你了。
给你二个解决办法：
第一个办法：使用这个命令格式
shellmysqladmin
create
数据库名
-uroot
-p
(数据库已经存在就不用此步)
shellmysql
-uroot
-p
数据库名
backup-file.sql
第二个办法：更详细的用法在mysql的在线手册中，已经给你找到备份恢复的页面了，打看学一下，你们问题就可以肯定搞定了。这是mysql官方中文手册。
备份恢复的页面链接：
mysql数据库被攻击怎么恢复数据
解决方法一：
一些库可以保留30天的备份。主库的Binlog保留时间为7天，可以从库备份拿出来恢复，然后通过主库的Binlog通过时间段来筛选出时间段所有更改的一些数据。或者通过其他方法慢慢将这部分数据找出来。一定得先找备份及时间点在备份的从库上检查备份，通过确定时间点可以查看备份文件进行恢复。
具体恢复操作：
1.从备份机拷贝备份
2.恢复测试机解压
3.恢复测试机导入
4.将主库的Binlog拷贝到恢复测试机
5.使用MySQLBinlog 生成SQL脚本
6.Binlog生成的SQL脚本导入
7.导入完成后检查数据正确性
解决方法二：
联系专业的资料恢复公司进行恢复。在数据局遭到攻击在没有备份或者无法恢复的情况下，由于资料恢复的复杂性专业性，如果擅自操作可能会使得数据库遭受无法恢复的灾难。这时候为了避免出现更大的损失，我们应该停止操作，以免造成数据的二次破坏。这时候应该第一时间联系专业的资料恢复公司进行处理。
