Navicat本身不控制数据库读写行为，“团队只读权限”需同时配置Navicat Team/Cloud的视图权限和后端数据库的真实账号权限；仅配一层必然失效。
navicat 本身不控制数据库的读写行为，所谓“团队只读权限”必须拆成两层：navicat cloud / team 的协作视图权限，和后端数据库（mysql/postgresql等）的真实账号权限。只配其中一层，必然失效。
Navicat Team 或 Cloud 的「Viewer」角色 ≠ 数据库只读
你在 Navicat Team 管理页把成员设为 Viewer，他依然能双击连接、手写 DELETE FROM users 并执行成功——只要连接用的数据库账号本身有 DELETE 权限。Viewer 只禁止编辑项目里的 Connection 配置、Query 文件或 Data Model，不拦截 SQL 执行。
- 想让成员“只能查不能删”，必须在 MySQL 里执行
GRANT SELECT ON mydb.orders TO 'team_user'@'10.20.30.%'，且明确 不授予INSERT、UPDATE、DELETE - Navicat Team 的
Editor角色允许改连接配置；如果该连接保存了root密码，Editor 成员同步修改后，所有人的连接都会指向新地址——可能误连到生产库 - Cloud 项目里看到的数据库列表为空？不是权限没开，而是连接所用账号缺少
SHOW DATABASES或对应库的SELECT权限
用 Navicat 执行 GRANT 时最常踩的三个坑
Navicat 的「新建用户」向导只支持库级粗粒度授权，细粒度必须手动写 SQL。贴错一个字符，权限就白配。
-
GRANT SELECT ON mydb.* TO 'user'@'%'→ 允许查整个库，但第三方通常只需要 2–3 张表，应缩小为GRANT SELECT ON mydb.report_log TO 'user'@'192.168.5.100' - MySQL 8.0+ 支持列级权限，但语法严格：
GRANT SELECT(id, created_at) ON mydb.orders TO 'user'@'%'—— 漏掉括号或写成SELECT id, created_at会报错ERROR 1064 - 执行完
GRANT后，MySQL 要求显式执行FLUSH PRIVILEGES（部分版本可省），而 Navicat 查询窗口默认不自动刷新权限缓存
第三方账号必须限制主机 IP，别用 %
Navicat 连接配置里的「主机」字段填的是客户端来源 IP，不是数据库服务器 IP。填 % 相当于开放全球可连，风险极高。
- 要求合作方提供固定出口 IP（如
203.0.113.45）或 CIDR 段（如203.0.113.0/24），然后授权时写成'reporter'@'203.0.113.45' - 若对方使用云服务（如 AWS Lambda、阿里云函数计算），IP 不固定，需配合数据库白名单 + 应用层代理，不能依赖
@'%'妥协 - PostgreSQL 中还需额外确认：用户有
CONNECT权限到目标 database，且 schema（如public）有USAGE，否则SHOW TABLES返回空
权限变更后，环境不同步是最大盲区
你在测试库用 Navicat 配好 SELECT 权限，UAT 和生产库不会自动同步。每个数据库实例的权限表（如 MySQL 的 mysql.user）完全独立。
- 上线前必须人工核对三套环境：执行
SHOW GRANTS FOR 'user'@'host'，逐条比对输出是否一致 - Navicat 的「导出用户」功能默认只导
CREATE USER，漏掉全部GRANT语句；要导完整权限，得手动执行SELECT CONCAT('GRANT ', privilege, ' ON ', table_schema, '.', table_name, ' TO ''', user, '''@''', host, ''';') FROM information_schema.role_table_grants WHERE user = 'xxx'; - Navicat Team 权限变更后，成员本地客户端最长 15 分钟才轮询更新，期间仍按旧权限工作——重启软件或手动登出重登才能立即生效
