mysql账号执行datax mysqlreader需显式授予各源库及information_schema的select权限，密码须url编码，host须匹配datax服务器ip。
MySQL账号必须有跨库SELECT权限
DataX的mysqlreader插件执行时，不是在目标数据库上下文中运行SQL，而是直接在连接会话里执行SELECT——这意味着账号必须对源库中所有要读取的表显式拥有SELECT权限，不能只靠GRANT SELECT ON *.*（某些MySQL版本下该授权不生效）。
- 错误现象：
[ERROR] Failed to read table [user_info]: Access denied for user 'datax_user'@'%' to database 'source_db' - 正确授权方式（逐库授予）：
GRANT SELECT ON `source_db`.* TO 'datax_user'@'%'; FLUSH PRIVILEGES;
- 若需整库迁移多个库，必须分别授权：
GRANT SELECT ON `db1`.* TO 'datax_user'@'%'; GRANT SELECT ON `db2`.* TO 'datax_user'@'%'; FLUSH PRIVILEGES;
- 避免使用
GRANT ALL PRIVILEGES ON *.*：DataX仅需读权限，过度授权违反最小权限原则，且部分生产环境策略会拦截此类语句
账号需能访问information_schema以支持自动列推导
当配置中使用"column": ["*"]或未显式指定字段时，mysqlreader会查询information_schema.COLUMNS获取表结构。若账号无此库的SELECT权限，任务会卡在元数据获取阶段，日志中出现类似Unknown column 'COLUMN_NAME' in 'field list'或空结果但无报错。
- 必须添加授权：
GRANT SELECT ON `information_schema`.* TO 'datax_user'@'%'; FLUSH PRIVILEGES;
- 注意：
information_schema是系统库，MySQL 8.0+默认不允许GRANT ... ON information_schema.*，此时需用GRANT SELECT ON *.*并配合--skip-grant-tables绕过（不推荐），更稳妥做法是显式列出所有需要迁移的列，避开元数据查询 - 生产环境若禁用
information_schema访问，务必在JSON配置中写死column数组，不要用["*"]
账号密码不能含特殊字符或空格
DataX通过JDBC URL传参解析密码，若密码含@、/、:、?等URL保留字符，会导致jdbcUrl解析失败，报错如java.sql.SQLException: No suitable driver或Malformed \u0027jdbcUrl\u0027。
- 典型错误密码：
pass@word/123→ 解析时被截断为pass - 解决方案：对密码做URL编码，例如
pass%40word%2F123（@→%40，/→%2F） - 验证方式：用
java.net.URLEncoder.encode("your_pass", "UTF-8")生成编码后字符串，再填入password字段 - 更省事的做法：重置账号密码为仅含字母、数字、下划线的组合，避开编码问题
host限制影响DataX所在节点连通性
MySQL账号的host部分决定允许从哪些IP连接。DataX不是在数据库服务器本地运行，而是在独立的调度机或容器中执行，因此'datax_user'@'localhost'无法使用。
- 必须用
'datax_user'@'%'或精确指定DataX服务器IP：'datax_user'@'192.168.10.55' - 若MySQL启用了
skip-name-resolve，禁止使用主机名（如'datax_user'@'datax-server'），否则连接超时 - 防火墙和安全组也要放行DataX服务器IP到MySQL端口（默认3306）的TCP流量，仅授予权限不够
实际配置中最容易被忽略的是information_schema权限和密码URL编码——前者导致静默失败，后者报错晦涩。跨库迁移不是“建个账号+给个密码”就完事，每个环节都得对上DataX的底层行为逻辑。
