删DEFINER和SQL SECURITY声明可解决导入报错；将utf8mb4_0900_ai_ci替换为utf8mb4_unicode_ci（5.7+）或utf8_general_ci（5.6-）；函数需补READS SQL DATA等特性声明；导入前加SET NAMES utf8mb4防乱码。
导出文件里有 DEFINER 和 SQL SECURITY 报错怎么办
旧版 phpmyadmin（比如 4.6 之前）导出时默认保留存储过程、视图的 definer 和 sql security 声明，新 mysql（尤其是 8.0+ 或启用了 sql_mode=strict_trans_tables 的实例）会直接拒绝导入，报类似 access denied; you need (at least one of) the super privilege(s) for this operation 或 you do not have the super privilege and binary logging is enabled。
这不是权限配置问题，而是语句本身被 MySQL 拒绝执行。最直接的办法是删掉这些声明：
- 用文本编辑器全局搜索替换：
DEFINER=`.*?`@`.*?` SQL SECURITY DEFINER→ 空（正则模式，注意转义） - 或者更稳妥：只删
DEFINER=...部分，保留SQL SECURITY DEFINER（它本身不报错，但可一并删掉避免混淆） - 如果文件大，用
sed -i 's/DEFINER=`[^`]*`@`[^`]*`//g' dump.sql（Linux/macOS）；Windows 可用 PowerShell：(Get-Content dump.sql) -replace 'DEFINER=`[^`]*`@`[^`]*`', '' | Set-Content dump.sql
导入时报 Unknown collation: 'utf8mb4_0900_ai_ci'
这是 MySQL 8.0 默认字符序，旧版 phpMyAdmin 导出时没做降级处理，而目标库是 5.7 或更低版本——它们根本不认识这个 collation。
不能简单替换成 utf8mb4_general_ci，因为排序规则差异可能影响查询结果。稳妥做法是按实际需求选兼容项：
- 若目标 MySQL 是 5.7：统一替换成
utf8mb4_unicode_ci（推荐，比general_ci更准） - 若目标 MySQL 是 5.6 或更老：必须降级为
utf8_general_ci，同时把表和字段的CHARSET=utf8mb4改成CHARSET=utf8 - 用
sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' dump.sql快速修复（仅限 5.7+ 目标库）
触发器或函数导入失败，提示 This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA
MySQL 5.7+ 开启了 log_bin_trust_function_creators=OFF（默认），要求所有函数/存储过程必须显式声明特性。旧版 phpMyAdmin 导出时不加这些关键词，导致导入中断。
立即学习“PHP免费学习笔记（深入）”；
解决方式不是改 MySQL 配置（那会带来安全风险），而是补上声明：
- 找到
CREATE FUNCTION ... BEGIN前一行，在RETURNS后面加上READS SQL DATA（如果函数只查表）或NO SQL（如果纯计算） - 例如原句：
CREATE FUNCTION `myfunc`() RETURNS INT→ 改成：CREATE FUNCTION `myfunc`() RETURNS INT READS SQL DATA - 触发器不用加，但函数、存储过程、事件都得补；批量处理建议先用正则定位
CREATE (FUNCTION|PROCEDURE)再人工核对逻辑
导入后中文乱码，但文件明明是 UTF-8 编码
常见陷阱：phpMyAdmin 导出页面里选了「UTF-8」，但导出的 SQL 文件头部没有 SET NAMES utf8mb4，或者目标库连接未指定字符集，导致 MySQL 用默认 latin1 解析。
不要依赖编辑器编码显示，重点看连接层：
- 导入前手动在 SQL 文件最开头插入：
SET NAMES utf8mb4;（不是utf8，后者是 MySQL 的别名，实际只支持 3 字节） - 用命令行导入时加参数：
mysql --default-character-set=utf8mb4 -u user -p db_name - 检查目标库是否真的支持：
SHOW VARIABLES LIKE 'character_set%';和SHOW CREATE DATABASE db_name;，确保character_set_database是utf8mb4
真正麻烦的是混合了 utf8 和 utf8mb4 的老 dump：字段定义里写的是 CHARSET=utf8，但内容存了 emoji，这种必须逐表 ALTER，没法靠导入前替换解决。
