回过头想想，一开始查下mysql_install_db这个命令，也不至于承受着巨大的压力折腾两天，不得不说，折腾下来的收获真的不小，好记性不如烂笔头，记录下来共勉。 
   故事的开头是用./mysqld_safe命令起不来MySQL，错误提示：ERROR 2002: Can't connect to local MySQL server through socket '/tmp/mysql.sock'，查看/tmp目录中确实没有mysql.sock，又看了log-err:[ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it. “Please run mysql_upgrade to create it”，如果一开始注意到这句话用mysql_upgrade 命令会不会就没有后头的事了，查了下这个命令，还是没太明白这个命令在此处用的作用，internet上都是说MySQL升级时使用。[采用MySQL_upgrade升级授权表方式升级] 
  当时使用了./mysql_install_db命令，我不知道师弟用的什么参数，指定的配置文件肯定还是/etc/my.cnf，(没想到mysql_install_db命令的结果是新建了个数据库实例，并且一般会新建一个xxx.cnf文件)。然后也新指定了datadir,basedir为data目录（以前的在var目录），生成了新的授权表，my.cnf。mysqld_safe可以起来了，感觉自己棒棒的，但是当我们登陆phpmyadmin后彻底傻了，以前的数据库都没有了，没有第一时间去查mysql_install_db命令的应用场景，满脑子是闯大祸了，数据被删了，要怎么去恢复数据库，要不要请示项目leader，自己先补救再说。。。 
  恢复数据库之旅开始，我们竟然找到了以前/var目录下的所有数据，但是没有想到直接更改my.cnf配置到这个目录就可以，而是坚定的认为mysql的数据库都是默认在data目录的，不能更改，var下的只是副本或者啥的，还是太年轻了T T。我们的做法是用var下的数据去data目录下恢复，使用.frm文件恢复了表结构，按internet上说用ibdata1去恢复数据，但是就是不成功，都没想到用mysql-bin.00000x文件去恢复，还是因为太年轻T T。中间还有一个重大的插曲，ssh不能连接到阿里云服务器了，没办法，只好将这件事告诉了项目leader，好的是他让我别着急，我能不着急吗，这数据要是真没了责任都是我的T T。之后leader给阿里云打电话，工作人员说云上有近三天的快照，leader说他晚上去恢复到某一天快照，让我们不要担心。确实是松了口气，刚好也到下班时间，晚上吃了顿好的，以缓解我白天的压力。 
  然而第二天一大早leader打电话说，快照里头没有还是怎么的，总之就是通过快照不行，还是得自己搞。ssh链接不了是因为Linux的var目录被谁删了，扶额，哪个缺心眼干的，没事喜欢乱删。又开始折腾着恢复数据，internet上的方法看的多了，大都是复制之类的，我就想能不能直接指定配置文件中的路径到./mysql/var呢，反正所有文件都是从var目录cp的。说干就干，mysql起来了，但是登陆进去后每个数据库是空的，然而磁盘上每个数据库中是有.frm文件的，查看日志，”Cannot find or open table xxx from the internal data dictionary of InnoDB through the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but hava forgotton to delete the corresponding .frm……, the table contains indexes that this version of the engine doesn’t support.”这段英语说个啥信息，先不管，先给mysql用户赋予权限试试，重启，又看到了熟悉的数据熟悉的表！！！结束~ 
  后记： 
  今天（2016/4/25）大早上，甲方工作人员告诉我录入数据提交不成功，我看到控制台报：#1030-Get error -1 from storage engine，原来是前几天捯饬MySQL的时候在my.cnf加了一个参数innodb_force_recovery=4，插入操作被忽略。注释掉或者设置为0就可以执行正常操作了。