无root权限仍可导出导入MySQL数据，关键需SELECT和LOCK TABLES权限；若无法授权LOCK TABLES，可用--skip-lock-tables但有不一致风险；导入需CREATE DATABASE、INSERT等权限，字符集与存储过程导出易被忽略。
导出时不用root，但必须有SELECT和LOCK TABLES权限
没root权限不等于不能导出数据——只要你的账号对目标数据库有SELECT和LOCK TABLES权限，mysqldump就能跑起来。很多团队会给开发/运维分配专用账号，比如app_dev，它可能没有全局权限，但能读写指定库。
常见错误现象：执行mysqldump -u app_dev -p my_db > dump.sql报错Access denied; you need (at least one of) the LOCK TABLES privilege(s) for this operation。这不是密码错，是权限不足。
- 联系DBA或管理员，确认账号已授权：
GRANT SELECT, LOCK TABLES ON my_db.* TO 'app_dev'@'%'; - 如果连
LOCK TABLES都批不了（比如共享主机环境），加--skip-lock-tables参数强制跳过，但要接受“导出瞬间可能存在不一致”的风险（适合读多写少、或业务可容忍几秒误差的场景） - 避免用
--all-databases——这需要SELECTon*.*，普通账号基本拿不到
导入目标库前，得先有CREATE DATABASE和INSERT权限
目标MySQL实例上，你账号必须能建库、建表、插数据。如果目标库已存在，至少要有CREATE、INSERT、ALTER on target_db.*；如果库不存在，还得额外有CREATE on *.*（即建库权限）。
容易踩的坑：在目标服务器执行mysql -u app_dev -p target_db 报错<code>ERROR 1044 (42000): Access denied for user 'app_dev'@'%' to database 'target_db'。这不是文件路径问题，是账号根本没被授权操作这个库。
- 让管理员提前执行：
CREATE DATABASE IF NOT EXISTS target_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;，再授予权限：GRANT ALL PRIVILEGES ON target_db.* TO 'app_dev'@'%'; - 如果无法建新库，就复用已有库名（比如
my_db_v2），但导出时就得用--databases显式指定，否则dump.sql里不含CREATE DATABASE语句，导入会失败 - 别依赖
source命令进MySQL客户端再执行——它对权限要求一样高，且容易因超时中断大文件
字符集不一致会导致中文变问号，必须手动对齐
没root权限意味着你没法改my.cnf里的character_set_server，但mysqldump和mysql客户端默认用utf8mb4还是latin1，取决于服务端配置和客户端连接参数。一旦错位，导出的SQL里中文就是乱码，再怎么导入也救不回来。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
典型症状：dump.sql里中文字段显示为????，或者导入后查出来是方块、问号、空格。
- 导出前先查源库实际字符集：
SHOW CREATE DATABASE my_db;和SHOW CREATE TABLE my_table;，确认CHARACTER SET值（大概率是utf8mb4） - 导出时强制指定客户端编码：
mysqldump -u app_dev -p --default-character-set=utf8mb4 my_db > dump.sql - 导入时同样指定：
mysql -u app_dev -p --default-character-set=utf8mb4 target_db - 如果目标库默认字符集不是
utf8mb4（比如老系统仍是utf8），导入前先执行ALTER DATABASE target_db CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;（需有ALTER权限）
存储过程、函数、事件这些对象导出要额外加参数
普通mysqldump my_db默认不导出存储过程、函数、事件、触发器——它们属于“定义”而非“数据”，且需要额外权限（如SELECT on mysql.proc）。没root时，这些对象极大概率被静默跳过，导致迁移后功能缺失。
错误信号：导入完一切正常，但调用CALL my_proc()时报PROCEDURE my_db.my_proc does not exist。
- 导出时必须加
--routines（含存储过程和函数）、--events、--triggers，例如：mysqldump -u app_dev -p --routines --events --triggers --default-character-set=utf8mb4 my_db > dump.sql - 注意：
--routines需要SELECTonmysql.proc，很多受限环境会禁掉——此时只能让DBA帮忙导出这部分，或改用SHOW CREATE PROCEDURE逐个手写 - 导入时如果报错
Access denied; you need the SUPER privilege for this operation，说明目标库开启了log_bin_trust_function_creators=OFF（防恶意函数），需DBA临时设为ON，或让你账号有SUPER（通常不给）
没root权限迁移的核心，是把“权限边界”当成设计约束来用——不是所有操作都能自动化，有些步骤必须提前协调DBA，有些对象必须人工补全。最常被忽略的是字符集与routine导出这两项，一不留神，上线后中文炸、定时任务失灵，比停机还难排查。
