真正起作用的是数据库后端的GRANT语句与Navicat Team/Cloud的视图级管控，两者缺一不可；Viewer角色不限制SQL执行，仅限制项目内配置编辑。
不能只靠navicat设置权限——它不拦截sql执行，也不控制数据库真实行为。真正起作用的，是mysql/postgresql等后端实例里的grant语句，以及navicat team/cloud对连接和查询文件的视图级管控。两者缺一不可。
为什么Navicat Team的Viewer角色无法阻止DELETE操作
Navicat Team 的 Viewer 角色只限制编辑项目内保存的 Connection 配置、Query 文件或 Data Model，但不干预用户双击连接后手写并执行的任何 SQL。只要连接用的数据库账号本身有 DELETE 权限，Viewer 成员照样能删表。
- 常见错误现象：成员在Team里被设为
Viewer，却在查询窗口执行DELETE FROM users成功 - 根本原因：该连接配置中使用的账号（如
'prod_app'@'10.20.30.%'）在MySQL里已被授予ALL PRIVILEGES或显式DELETE - 正确做法：先在MySQL中执行
GRANT SELECT ON mydb.* TO 'team_user'@'10.20.30.%'，且不给INSERT/UPDATE/DELETE
如何让成员“能查不能改”，且看不到生产连接配置
关键在于分离「连接可见性」和「数据库账号权限」：既要他在Navicat Team里看不到生产连接，又要他连上去之后也干不了危险操作。
- 在Navicat Team中，不要把生产库的
Connection加入共享项目；若必须共享，只授View权限（禁用Edit） - 为该连接单独创建低权限账号，例如：
CREATE USER 'ro_reporter'@'192.168.5.100' IDENTIFIED BY 'xxx'; GRANT SELECT ON sales.orders TO 'ro_reporter'@'192.168.5.100'; - 禁止使用
%通配主机名，固定IP或CIDR段，避免账号被滥用 - 执行完
GRANT后，记得在MySQL中运行FLUSH PRIVILEGES;（MySQL 8.0.23+部分场景可省，但建议显式执行）
Navicat「新建用户」向导为什么总配错权限
Navicat自带的图形化用户向导只支持库级粗粒度授权，比如「允许访问mydb，拥有SELECT/INSERT」，无法设置表级、列级或行级策略。
- 想只开放
orders表的id和created_at字段？必须手动写：GRANT SELECT(id, created_at) ON mydb.orders TO 'user'@'192.168.5.100';（注意括号不能漏） - 想限制某用户只能查
status = 'active'的行？Navicat GUI完全不支持，需用MySQL 8.0+的CREATE POLICY或PostgreSQL的RLS - 导出用户时，Navicat「导出用户」功能默认只生成
CREATE USER，不带GRANT语句——容易漏掉权限，务必人工补全
成员执行查询后导出失败，可能卡在哪两个地方
导出按钮置灰，不是因为没开总开关，而是两个隐性权限环节都得通：
- 项目设置 →
Permissions→Advanced Settings中必须开启Allow exporting result sets（默认关闭，仅Owner可改） - 成员必须对所运行的
Query文件拥有Execute权限，且该Query中引用的Connection对其开放View - 即使权限全开，导出路径仍由成员本地Navicat设置决定，Team端无法强制重定向或审计导出位置
最常被忽略的一点：Navicat Team/Cloud权限变更后不会实时同步到客户端，成员需重启Navicat或重新登录Team账号才能生效。别以为点完保存就立刻管用。
