纪念工作中的第一次删库跑路的经历
今天接到一个任务，是将一个测试库数据导到另一个测试库，然而我们公司的数据库是不让直连的，所以只能通过远程连接进行导库操作。
老大布置任务的时候让用dump命令进行操作，因为老大就是通过dump命令将数据库服务器上的数据定时备份到测试环境中的应用服务器上。
所以当时就有点懵逼。。。。。。啥时dump命令。然后求助度娘，才发现有mysqldump命令。这才发现了新大陆。然后一顿操作一直报连接不上本地mysql本服务器。
第一整这个，当时就懵了。所以就想着sql文件都有了，我直接用navicat导就行了。
说干就干，直接在需要导入的库新建一个库，就直接读sql导库，并且优哉游哉的等待。等到一会之后，navicat居然断开了连接，所以只能看看那些表没导入，然后手动重新
导入一下。正在我导的起劲的时候，突然开发群里面就各种数据问题，下游系统各种数据访问失败。这个时候才发现是我导数据的问题(这里有个小坑，我导入的时候选择的是我
新建的库，但是居然把我们的应用使用的库数据给覆盖了，百思不得其解呀！这个后续还需要实验)。顿时我就懵逼了。感觉自己快要被裁了（可是我才刚刚转正呀，难受！）。
然后就各种把原始数据瞎导入，然而navicat还一直没有响应，但是下游群里面一直催。我都想当场暴毙了，十分难受。
最后还是有经验的老大发现问题了。
我之前一直时用的mysqldump命令：mysqldump -uroot -proot education users>d:/user.sql
这里只是指明了用户和密码，然后一直报连接不上本地mysql本服务器。我用ps一查我本地也没有mysql服务器呀，而且我是将数据导到数据库服务器上呀，也不是本地。
然后就在度娘的时候加上了导数据至服务器上的字样。这个时候才出现了正确的导入导出姿势：
mysqldump -u[用户名] -h[ip] -p[密码] -P[端口号] 数据库名 表名 >导出的文件名.sql
mysqldump -uroot -h127.0.0.1 -proot -P3306 education users>d:/user.sql
mysqldump -u[用户名] -h[ip] -p[密码] -P[端口号] 数据库名 表名 <导出的文件名.sql
mysqldump -uroot -h127.0.0.1 -proot -P3306 education users < d:/user.sql
还在加班的程序猿---纪念