Navicat“只读”设置无效，真正只读必须靠数据库账号权限兜底；MySQL需精确GRANT SELECT到单表+固定IP，并REVOKE写权限，再FLUSH PRIVILEGES；Navicat Team Viewer角色不控制SQL执行，权限由数据库账号决定。
不能只在navicat里点“只读”就完事——navicat本身不拦截sql执行，所谓“只读连接”必须靠后端数据库账号权限兜底，否则双击连接、手写delete from users照常成功。
MySQL中创建表级只读账号的正确SQL写法
Navicat的「新建用户」向导只能做库级粗粒度授权，真正安全的只读必须手动写GRANT语句，且严格限定对象范围和主机来源。
- 错误示范：
GRANT SELECT ON mydb.* TO 'team_user'@'%'—— 开放整库+任意IP，等于裸奔 - 正确做法：
GRANT SELECT ON mydb.sales_report TO 'team_user'@'203.0.113.45'—— 精确到单表+固定合作方出口IP - 必须显式拒绝写权限：
REVOKE INSERT, UPDATE, DELETE, DROP, CREATE, ALTER ON mydb.* FROM 'team_user'@'203.0.113.45' - 执行完务必补一句：
FLUSH PRIVILEGES（MySQL 8.0.29之前版本不可省）
Navicat Team Viewer角色 ≠ 数据库只读
你在Navicat Team后台把成员设为Viewer，他依然能连上数据库、执行任意SQL——因为Viewer只锁住项目里的Connection配置、Query文件编辑和Data Model修改，不干预实际连接后的SQL执行流。
- 真实权限由连接所用的数据库账号决定，不是Navicat界面角色
-
Editor角色更危险：若他修改了保存着root密码的连接配置，所有同步该连接的成员都会被带偏到生产库 - Cloud项目里看不到数据库列表？不是Team权限问题，而是该账号缺少
SHOW DATABASES或目标库的SELECT权限
第三方连接时最容易漏掉的三个硬性限制
很多团队配完GRANT SELECT就以为万事大吉，结果上线后发现对方连不上，或者查不到数据——问题往往出在权限链条的上游环节。
- MySQL需确认账号有
USAGE权限到目标database，否则USE mydb直接报错 - PostgreSQL还要额外给
CONNECT权限到database +USAGE权限到schema（如public），否则SHOW TABLES返回空 - 云环境（AWS Lambda/阿里云函数）IP不固定时，
@'%'不是妥协方案，得配数据库白名单+应用层代理，或改用临时凭证（如IAM认证）
真正的防线不在Navicat的UI开关里，而在你写的每一行GRANT语句是否精确到表、IP、操作类型；不在Team角色设置里，而在连接配置背后那个数据库账号是否真的没被授予任何写权限。细节松动一毫，风险就放大十倍。
