MySQL 中如何查到 information_schema 以外的隐藏系统表

说到MySQL里的“隐藏表”，这事儿其实有点误会。真正的“隐藏”基本只发生在 information_schema、performance_schema 这些库，它们本质上是只读视图或内存结构，压根就不是磁盘上的物理表。至于 mysql 系统库里的那些内部表，比如 innodb_index_stats，你用普通账号执行 show tables 看不到，这可不是因为它们被魔法隐藏了，纯粹是权限不够——门锁着，你手里没钥匙而已。

那么，想一探究竟，具体该怎么做呢？

• 最直接的办法，就是用高权限账号（比如 root）登录，执行 SHOW TABLES FROM mysql;。这下，gtid_executed、innodb_table_stats 这些表就都一览无余了。
• 这里有个细节值得注意：mysql 库里那些带 innodb_* 前缀的表，是由InnoDB引擎自己维护的。它们是否真的落在磁盘上，取决于一个关键配置：innodb_stats_persistent。只有当它设为 ON 时，统计信息才会持久化；否则，就只待在内存里。
• 最后提醒一句，看到 mysql.user 或 mysql.db 这类表，可别顺手就来个 SELECT *。密码字段是哈希值，权限字段的含义也相当复杂。真想搞清楚用户的权限，更稳妥的办法是使用 SHOW GRANTS FOR ... 命令。

PostgreSQL 怎么导出 pg_catalog 和 pg_toast 下的系统对象

转到PostgreSQL，情况又略有不同。它的系统表都规规矩矩地放在 pg_catalog 这个schema里。不过，默认情况下，无论是连接后的提示还是 \dt 命令，都会主动过滤掉它们，营造出一种“不存在”的假象。想看？你得指名道姓才行。

具体操作路径如下：

• 连接数据库后，运行 \dt pg_catalog.*。像 pg_class（存储所有表和索引的定义）、pg_attribute（存放字段的元信息）这些核心系统表就都会列出来了。
• 如果想导出结构，这里有个坑：常用的 pg_dump --schema-only 命令默认会跳过 pg_catalog。你必须加上 --include-foreign-data 参数，或者更直接地，用 --table=pg_catalog.pg_class 这样的方式指定单个表来导出。
• 至于 pg_toast，它是自动创建的辅助schema，专门用来存储大字段的压缩数据。它不能、也不需要被单独导出——在备份时，它会随着主表一起被处理，单独操作它没有意义。

SQL Server 备份系统数据库（master、msdb、model）要注意什么

SQL Server的系统数据库备份，是个需要格外小心的技术活。尤其是 master 库，它可不能像用户数据库那样随意执行 BACKUP DATABASE。原因在于，master 数据库仅在SQL Server服务启动时加载一次，运行期间的许多修改并不写入事务日志，这导致其备份窗口极短，且恢复时必须停止服务。

备份时，务必牢记这几个要点：

• master 数据库：必须在SQL Server处于“单用户模式”下才能进行可靠备份。日常操作中，建议先用 sqlservr.exe -m 命令以单用户模式启动实例，然后再执行 BACKUP DATABASE master TO DISK = '...'。
• msdb 数据库：它存储着作业、备份历史、SSIS包等重要信息，通常每天自动备份一次即可。但请注意，如果启用了数据库邮件功能，msdb 里的 sysmail_mailitems 等表可能包含敏感数据，导出前最好先清理。
• model 数据库：这是所有新用户数据库的模板。一旦你对它做了修改，务必立刻备份。否则，后续新建的数据库可能会继承错误的配置，比如误设为 RECOVERY FULL 模式却忘了配置相应的日志备份策略。

SQLite 怎么查看和导出 sqlite_master 及隐藏表（如 sqlite_stat1）

最后来看看轻量级的SQLite。它把所有元数据都打包塞进了 sqlite_master 这张表里。它并非“隐藏”，只是名字以 sqlite_ 开头，被命令行工具（CLI）默认过滤掉了，所以在执行 .tables 时看不到。

想查看和导出，可以这么做：

• 在 sqlite3 命令行中，输入 .tables sqlite_*。这样，sqlite_master、sqlite_sequence、sqlite_stat1 等系统表就无所遁形了。
• 要导出整个数据库（包括系统表），使用 .dump 命令是最简单的，它会默认包含 sqlite_master。但要注意，sqlite_stat* 这类由 ANALYZE 命令生成的统计信息表不会被包含在内，如果需要，得手动通过 INSERT INTO 语句来备份。
• 另外一个小知识：sqlite_master 表中的 sql 字段存储的是原始的建表语句文本，但它不包含外键约束的细节。要查看完整的外键信息，需要单独查询 PRAGMA foreign_key_list(...)。

说到底，系统表从来不是什么神秘的黑盒子。所谓的“看不见”，多半是权限不足、工具默认行为的过滤，或者是设计上的约定俗成。真要导出它们，核心思路就三条：换上足够权限的账号、绕过命令行工具的默认过滤逻辑、最后确认一下目标表是不是真的已经持久化在磁盘上可供读取。很多所谓的“隐藏”，其实只是文档里那句“visible only to superuser”没有被认真对待罢了。