目录
一、问题说明
我们首先在A库中通过mysqldump生成了sql文件，在导入B库时报错：
ERROR 1227 (42000) at line 18: Access denied; you need (at least one of) the SUPER, SYSTEM_VARIABLES_ADMIN or SESSION_VARIABLES_ADMIN privilege(s) for this operation
一言以蔽之，我们的sql文件的第18行存在需要更高权限才能执行的语句。
使用记事本打开sql文件查看第18行：
可以发现这是一个有关GTID的语句。
什么是GTID？
GTID是MySQL自带的一套事务标识机制，当开启GTID模式，每个事务成功提交后都会分配一个全局唯一的ID。
不难发现，GTID是为了简化MySQL主从复制而生的。
传统主从复制依赖binlog文件名和position来标识复制位置，在主从切换或故障恢复时容易出现重复执行或漏执行事务的问题。而基于GTID的复制只需判断某个GTID是否已执行，从而显著降低复制管理的复杂度。
综上可知，GTID只在自动主从复制时能起到效果，对于我们当前使用mysqldump进行手动数据迁移的时候则可有可无，因为使用逻辑导入的数据不会直接参与现有的GTID复制链路。
二、解决方案
在生成sql文件时在额外参数中添加--set-gtid-purged=OFF即可。
关于如何使用mysqldump进行数据迁移可以参考以下文章：
记录使用datagrip备份数据库信息-CSDN博客
不过需要注意的一点是，DataGrip在mysqldump界面是默认勾选lock tables选项的：
该选项等同于--lock-all-tables参数，会在生成sql文件的期间会对整个库添加全局读锁，从而阻塞所有的写线程。由于该锁粒度较大且在读写并发的业务场景下，大量写请求被阻塞可能导致连接长期占用，进而使连接池耗尽，新请求无法获取连接，最终表现为MySQL伪宕机。
所以在实际迁移中，请切实考虑是否要勾选该选项，若否则可能会导致迁移空窗期的数据丢失，甚至造成业务逻辑错误的情况。
不过如果可以容忍短期数据丢失且使用的是InnoDB引擎的话更推荐使用--single-transaction方式，这个方式会通过InnoDB的MVCC机制获取当前数据库的一致性快照，不会添加全局读锁，对整体业务影响较小。
~码文不易，留个赞再走吧~