如何在MySQL中实现不同库之间的数据传输与共享mysql不同库

这就是坑：FEDERATED存储引擎已被弃用，不建议使用。

mysqldump导出导入，复制，是稳定的选择。

别信FEDERATED，用mysqldump或replication。

别这么干：直接修改远程表结构，可能导致数据丢失。

mysql导入提示lock tables tablename write access denied

对，就是权限不足。
导出加--skip-lock-tables，导入用户权限要够。
权限不够，分步导入。
先这样，你试试看。

mysql如何使用mysqldump恢复数据库

2 02 2 年，我在北京搞过一个项目，数据库备份搞大了，几百G的.sql.gz文件，直接命令行导入是真快。
就用了这行命令：gunzip < /path/backup.sql.gz | mysql -uadmin -pmydb，秒秒钟搞定。
不过有个坑，你得先确认数据库mydb存在，字符集是utf8 mb4 ，不然导入会炸。
当时我手一抖，忘了加COLLATE utf8 mb4 _unicode_ci，结果导入完发现有些中文乱码，把我整懵了，赶紧停服务器，改了字符集再重导入。
这次教训深，恢复前一定得测试备份文件。

小文件调试就用SOURCE命令吧，2 02 3 年在上海搞测试，一个几个K的.sql文件，用mysql -uadmin -p -Dtestdb -e "SOURCE /path/backup.sql"导入，比命令行慢点，但胜在方便。
记得有一次文件路径写错了，结果导入了个空库，调试半天才发现，气死我了。

恢复前准备工作不能省。
2 02 1 年在深圳搞过一个生产环境恢复，备份文件提前用head命令看了下，开头还行，结果tail一看，TM截断了，数据丢了小半。
吓得我赶紧用非生产环境测试备份，发现是传输出错了。
所以备份文件完整性检查必须做。
还有权限，2 02 3 年在广州搞恢复，命令行导入直接报Access denied，后来查了日志，发现用户没CREATE权限，赶紧用GRANT ALL PRIVILEGES ON mydb. TO 'admin'@'localhost';补上，才搞定。

磁盘空间也重要。
2 02 2 年在成都搞恢复，导入前没看磁盘空间，结果恢复完直接爆错No space left on device，服务器卡死，客户骂翻了。
后来赶紧清理了点旧日志，才继续。
所以恢复前一定用df -h看看。

增量恢复得用binlog。
2 02 3 年在杭州搞过一个时间点恢复，全量备份搞了半天，结果客户说只需要恢复到昨天下午4 点的数据。
我就用mysqldump全量恢复，然后用mysqlbinlog解析binlog，指定时间点恢复。
前提是binlog得开启，而且得保存着，不然恢复不了。
当时binlog文件保存策略没搞好，结果binlog丢了，只能重做全量了，惨痛教训。

总结下，恢复MySQL数据库，大文件用命令行导入快，小文件用SOURCE命令。
恢复前检查备份文件，看权限，看磁盘空间，停机或切换流量，保留快照。
增量恢复用binlog，但得保证binlog开启和保存。