应为第三方工具创建专用低权限账号，限制IP并精确授权，禁用root及通配符权限，定期更新密码和限制连接数。
给第三方工具配独立账号，别用 root
直接用 root 或其他高权限账号连 MySQL 给外部工具（比如 Navicat、DataGrip、Python 的 pymysql 脚本、BI 工具）用，等于把锁孔和钥匙一起扔在门口。不是不能连，是连上之后它能干的事远超需求——删库、改用户、看所有表结构，出事就是全线崩。
正确做法是为每个工具或每类用途建专用账号，只开它真需要的库+操作。比如 BI 工具只读报表库，同步脚本只写日志表，管理后台只查改用户表。
-
CREATE USER 'navicat_app'@'192.168.10.%' IDENTIFIED BY 'strong_pass_2024';（限制 IP 段比%安全得多） GRANT SELECT ON `report_db`.* TO 'navicat_app'@'192.168.10.%';-
FLUSH PRIVILEGES;（别漏这句，否则权限不生效）
GRANT 时别乱用 ON *.*
看到文档里写 GRANT SELECT ON *.* 就照抄？这是最常踩的坑。它代表“所有数据库的所有表”，哪怕你只想查一个 analytics 库，也等于把 mysql 系统库、information_schema 全暴露了——有些工具会自动查这些库来渲染界面，结果权限一开，它们真就去读了。
更危险的是 GRANT ALL PRIVILEGES ON *.*，等同于临时 root，且容易被误传为“标准配置”。
- 只读工具：用
GRANT SELECT ON `db_name`.*，精确到库名 - 需要写入的 ETL 脚本：按表给
INSERT, UPDATE, DELETE，别给DROP或ALTER - 绝对不要对
mysql、performance_schema、sys授予任何非必要权限
连接失败常见报错和对应检查点
第三方工具连不上，报错五花八门，但核心就三类：认证失败、主机拒绝、权限不足。别急着重装驱动或换端口，先盯住错误信息里的关键词。
-
Access denied for user 'app_user'@'10.0.5.23'→ 检查该用户是否真存在、密码是否输错、host是否匹配（注意：localhost ≠ 127.0.0.1，在 MySQL 权限体系里是两个不同 host） -
Host '10.0.5.23' is not allowed to connect to this MySQL server→user表里没这条记录，或者创建时用了'app_user'@'localhost'却从远程连 -
Table 'mysql.proc' doesn't exist或SELECT command denied to user→ 权限太窄，工具尝试查系统表失败，加SELECT权限到information_schema（仅限必要工具，如某些旧版 Navicat）
长期运行的工具账号要设密码过期和连接限制
很多团队配完账号就放着不管，一年后发现某个 BI 工具还在用三年前的弱密码连生产库，而那个账号有 UPDATE 权限。MySQL 5.7+ 支持细粒度控制，不用靠人盯。
- 强制定期换密：
ALTER USER 'etl_job'@'10.0.20.%' PASSWORD EXPIRE INTERVAL 90 DAY; - 防爆破/误配置：
ALTER USER 'api_db'@'%' WITH MAX_CONNECTIONS_PER_HOUR 100; - 避免长连接占满资源：
SET GLOBAL wait_timeout = 300;（配合应用层 keep-alive 使用）
密码策略和连接数限制不是“以防万一”，是确认某工具异常高频请求或持续连不上时，能快速判断是不是账号本身出了问题，而不是先怀疑网络或中间件。
