Navicat界面设置的“只读连接”或Team Viewer角色对数据库真实权限无约束力；真正只读必须由后端数据库账号权限决定，需精确到表、IP和操作类型，且MySQL表级只读须手动执行GRANT SELECT ON db.table TO 'user'@'ip'并显式REVOKE写权限。
navicat 本身不拦截 sql 执行，“只读连接”在界面里勾选或设为 team viewer 角色，对数据库真实读写权限毫无约束力。真正生效的只读，必须由后端数据库账号权限决定——且需精确到表、ip、操作类型。
MySQL 表级只读账号必须手写 GRANT，不能依赖 Navicat 新建用户向导
Navicat 的「新建用户」向导只支持库级（mydb.*）粗粒度授权，无法指定单表或限制 IP 段，容易误开整库 SELECT 权限。要实现真正安全的只读，必须在查询窗口手动执行 SQL：
-
GRANT SELECT ON mydb.sales_summary TO 'reporter'@'203.0.113.45'—— 精确到单表 + 固定合作方出口 IP -
REVOKE INSERT, UPDATE, DELETE, DROP, CREATE, ALTER ON mydb.* FROM 'reporter'@'203.0.113.45'—— 显式拒绝所有写类权限，避免隐式继承 -
FLUSH PRIVILEGES—— MySQL 8.0.29 之前版本必须执行，否则权限不生效
Navicat 连接配置里的“主机”填的是客户端来源 IP，不是数据库服务器地址
很多人把 host 字段误解为数据库所在服务器的 IP，结果填错导致权限失效或过度开放。这个字段实际控制“谁可以连进来”，直接影响 'user'@'host' 的匹配逻辑：
- 填
%= 允许任意公网 IP 连接 → 生产环境严禁使用 - 填
10.20.30.0/24或203.0.113.45= 限定可信网段或机器 → 推荐做法 - 云函数（如 AWS Lambda）IP 不固定时，
@'%'不是妥协方案，得配数据库白名单 + 应用层代理，或改用临时凭证（如 IAM 认证）
PostgreSQL 需额外确认 schema 和 database 级权限
MySQL 用户常忽略 PostgreSQL 的两级权限模型：即使给了 SELECT 表权限，若缺少上层权限，SHOW TABLES 或 \dt 仍会返回空：
- 必须先确保账号有
CONNECT权限到目标 database：GRANT CONNECT ON DATABASE mydb TO reporter - 必须显式授予 schema 的
USAGE权限：GRANT USAGE ON SCHEMA public TO reporter - 再授表级
SELECT：GRANT SELECT ON TABLE public.orders TO reporter
Navicat Team Viewer 角色 ≠ 数据库只读，它根本不管 SQL 执行
你在 Navicat Cloud 后台把成员设为 Viewer，他依然能双击连接、打开查询窗口、手写 DELETE FROM users 并成功执行——只要连接所用的数据库账号本身有 DELETE 权限。Viewer 只锁住三件事：
- 不能编辑项目里的 Connection 配置（比如改密码、换 host）
- 不能修改保存的 Query 文件或 Data Model
- 不能新增/删除项目内对象
但一旦连接建立，所有 SQL 请求都直通数据库，Navicat 完全不校验、不拦截、不重写。所谓“只读连接”的唯一防线，是你在数据库里写的每一行 GRANT 和 REVOKE 是否足够窄、足够严。
