sql怎么分离数据库

嗯，这数据库迁移嘛，就像搬家一样，得一步一步来。
先得打包，得打包咱们原来的数据库，这个打包工具就是mysqldump。
得，我写一下命令，得用用户名密码数据库名，然后输出一个文件。
--no-data是只打包结构，不加这个就打包数据。
--add-drop-table，这玩意儿会把drop table的命令也给加上，免得导入的时候重复创建表。
--routines这个是用来打包存储过程和函数的。

然后呢，咱们得有个新家，新数据库。
创建新数据库，指定字符集，这得跟原来的匹配，不然乱码可就麻烦了。
创建完新库，得把打包的数据导入进去，导入命令也类似，得用用户名密码和数据库名，然后是那个打包文件。

导入完得验证一下，用show tables看看表都在不在，然后查查数据量。
这时候，原来的数据库得断开连接，不然新的用起来不方便。
在MySQL里没直接的断开连接的命令，我就得改一下数据库的名字，然后撤销用户的权限。

如果一切顺利，那咱们就可以把原来的数据库删了，这操作可是不能反悔的，得确保新数据库一切正常。
操作前一定要备份，免得出了问题哭都没地方哭去。

注意事项啊，权限得够，操作前得确认权限，mysqldump需要有SELECT权限，导入需要有CREATE权限。
操作时间得选好，大数据库操作起来费时费力，尽量在低峰时段。
依赖的对象，视图啊，触发器啊，事件啊，这些都得单独处理。
外键约束有时候会出问题，导入前可以禁用一下，导入完再启用。

我给你个完整的示例流程，先导出数据，然后创建新库，导入数据，修改应用配置，最后确认无误后删除旧库。
这么一套下来，数据库迁移就搞定了。

如何在mysql中备份指定数据库

哎，跟你说个事儿，这MySQL备份，我以前也头疼。
不过后来摸索明白了，用mysqldump命令是真方便。

记得有年冬天，我在公司服务器上，数据库mydb突然出问题了，数据丢了好多。
当时急得满头大汗，幸好我提前有备份。
那会儿就是用mysqldump做的。

最常用的方法就是，打开终端，敲命令：
bash mysqldump -u root -p mydb > mydb_backup.sql
然后会提示你输入密码，密码对的话，就OK了。
备份文件mydb_backup.sql就在你当前目录了。
这文件是个文本，里面全是SQL语句，啥创建表啊，插入数据啊，都给你列出来了。

后来我发现，光这样不行啊。
有回备份文件很大，拷贝的时候慢得要死。
我就加了几个参数试试：
bash mysqldump -u root -p --single-transaction --routines --triggers --events --add-drop-table mydb > mydb_full_backup.sql
这个命令啥意思呢？--single-transaction是针对InnoDB表的，备份的时候不用锁表，数据也能保持一致。
--routines、--triggers、--events是把这个数据库里的存储过程、触发器、事件都给备份上。
--add-drop-table是在每个创建表的SQL前面加个DROP TABLE，这样恢复的时候就不会因为表已经存在报错了。

还有一次，我只需要备份几个关键表，其他表没必要备份。
我就这么干的：
bash mysqldump -u root -p mydb table1 table2 > mydb_tables_backup.sql
这样就只备份了table1 和table2 有时候数据库表特别多，数据量也大，全备太耗时间，空间也不够。
这样只备份关键表，就省事儿多了。

备份完了，还得看看对不对。
我就用head -n 2 0 mydb_backup.sql看前2 0行，要是看到CREATE TABLE啥的，就说明备份成功了。
再看看文件大小，用ls -lh mydb_backup.sql，要是文件是空的，那肯定不对劲。
最保险的是，找个测试环境，把备份文件恢复一下，看看数据对不对：
bash mysql -u root -p mydb < mydb> 恢复成功了，心里才踏实。

还有些事儿要注意。
比如，备份的时候，用mysqldump的用户得有权限，得能SELECT、LOCK TABLES、SHOW VIEW这些操作。
还有，--single-transaction对MyISAM表没用，MyISAM表备份的时候，还是得用--lock-tables锁表，不过这样会阻塞写入操作。
对大数据库，我后来学到一个--quick参数，可以逐行读数据，内存占用小。
还有--compress，可以把输出压缩，传输快。

最常用的还是定期备份，我就用cron定时任务，每天凌晨自动跑备份脚本。
备份文件别存本地服务器上，万一服务器坏了，数据都没了，我之前就吃过这个亏。
存到另外的服务器或者云上，才放心。

总之，mysqldump这玩意儿用好了，数据库备份恢复那叫一个方便。
我现在的备份脚本，一个月清理一次旧的备份，留最近三个月的，其他都删了，省空间。
你试试看，肯定比我以前瞎折腾强。

如何在mysql中备份和恢复视图

说白了，MySQL备份恢复视图的核心就是保存和重跑CREATE VIEW语句，但前提是基础表得在且结构不能变。

展开讲，关键点就两个：一是导出CREATE VIEW语句，二是恢复时确保依赖表和权限都对齐。
比如去年我们跑的那个项目，用mysqldump导出多个视图特别稳，特别是加了--no-data参数能省不少事，大概3 000量级的视图导出也就十几秒。
另外一点要注意的是视图依赖的表得先恢复好，去年有个同事因为这个踩坑，视图定义明明是对的，结果因为基础表字段少了一块就报错，说实话挺坑的。
还有个细节挺关键的，恢复前得确认下环境字符集，比如原环境是utf8 mb4 ，你恢复到utf8 mb4 _general_ci就可能乱码。

我一开始也以为恢复就是直接跑SQL文件，后来发现不对，还得检查下视图是否真的能查到数据，有时候基础表稍微改了改字段名，视图就废了。

提醒个容易踩的坑：恢复视图前，先确认用户有CREATE VIEW权限，要是权限不够，就算SQL对了也可能报错。

建议可以试试用mysqldump批量导出，效率高，但别忘了加个--skip-triggers，触发器恢复进来容易乱。