Navicat无法屏蔽表，根本原因是它无表级可见性开关，所谓“看不到”实为数据库权限缺失：当前账号缺乏目标表的SELECT权限（MySQL）或对应schema的USAGE权限（PostgreSQL），导致元数据查询不返回该表；真正屏蔽必须通过REVOKE在服务端收回权限，并手动重连生效。
不能靠 Navicat 的界面设置“屏蔽”表——它没有表级可见性开关，所谓“屏蔽”必须由数据库权限层控制，Navicat 只是执行通道。
为什么在 Navicat 对象树里看不到某张表？
常见现象：团队成员连接同一数据库，在 Navicat 左侧对象树中看不到 user_pii 或 payment_card 这类表，但用 SQL 手动 SELECT * FROM user_pii 却能查出来。
- 根本原因不是 Navicat 隐藏了表，而是当前连接所用的数据库账号**没有该表的 SELECT 权限**，导致
SHOW TABLES或information_schema.tables查询不返回它 - PostgreSQL 还需确认该账号对目标
schema有USAGE权限，否则\dt或刷新对象树也为空 - MySQL 8.0+ 中，即使有库级 SELECT，若未显式授予某张表权限，
SHOW TABLES仍可能过滤掉它（取决于 sql_mode 和权限检查严格度）
真正有效的屏蔽方式：用 GRANT/REVOKE 控制表级访问
你必须在数据库服务端显式收回敏感表的查询权，而不是依赖 Navicat 的任何前端选项。
- 对测试账号执行：
REVOKE SELECT ON mydb.user_pii FROM 'test_user'@'10.20.30.%'; - 如果该账号此前只有库级授权（如
GRANT SELECT ON mydb.*），则需先REVOKE库级权限，再GRANT明确允许的非敏感表（如GRANT SELECT ON mydb.order_summary TO ...） - MySQL 8.0+ 支持更细粒度：可只撤回特定字段，例如
REVOKE SELECT(id, email) ON mydb.users FROM 'test_user'@'%';，保留其他列可查 - 执行后记得在 MySQL 中运行
FLUSH PRIVILEGES;；PostgreSQL 不需要，但需确保账号已CONNECT到对应 database
别踩这些坑
很多团队试图绕过数据库权限，结果白忙活：
-
仅显示指定数据库（连接 → 高级）只是前端导航过滤，不影响USE other_db; SELECT * FROM sensitive_db.pii_table; - Navicat Team 的
Viewer角色只限制改连接配置或存 Query 文件，不拦 SQL 执行——只要账号本身有权限，DELETE FROM照样成功 - 建视图（如
CREATE VIEW safe_users AS SELECT id, username FROM users;）不能“屏蔽”原表，用户仍可绕过视图直查users，除非配合REVOKE - 误以为导出时勾选“排除系统表”就能挡住业务敏感表——那个选项只影响
mysql、information_schema等内置库，对业务表完全无效
最易被忽略的一点：权限变更后，Navicat 客户端不会自动重连或刷新权限缓存。成员得手动断开重连，或重启 Navicat，否则旧会话仍可能沿用之前获取的元数据缓存，造成“明明 revoke 了却还能看到表”的错觉。
