SQLite如何查看数据库中的所有表？三种精度探查方案详解

1. 为什么你打开 SQLite 数据库后第一件事就该学会“看表”——不是写 SQL，而是先搞清自己站在哪片数据土地上

刚接触 SQLite 的人常有个错觉：数据库就是个黑盒子，我写 INSERT 就能存，写 SELECT 就能查，只要语句没错，万事大吉。直到某天你接手一个别人导出的 .db 文件，双击打开——界面空荡荡，没有表名列表，没有字段预览，连 schema 都没提示；或者你在命令行里敲 SELECT * FROM users; ，系统冷冰冰回你一句 Error: no such table: users 。你翻遍项目文档、问遍同事，最后发现：这个数据库里压根就没有 users 表，它叫 t_user ，而且主键是 _id 而不是 id 。那一刻你才真正意识到： SQLite 不自带图形化导航栏，也不会主动告诉你“这里有什么”，它只忠实地执行你写的每一条指令——前提是，你得先知道该对谁下指令。 这就是 sqlite3 命令行工具里那条看似简单、实则性命攸关的命令： .tables 。它不是语法糖，不是教学示例，而是你每次连接数据库后的第一道安检门、第一张地图、第一次自我确认。本文讲的不是“怎么列出表名”，而是围绕 SHOW TABLES 这一核心动作，拆解 SQLite 独特的元数据组织逻辑、命令行与编程接口的差异路径、真实项目中常见的“表看不见”陷阱，以及如何用三类不同精度的查询（快速扫表、结构探查、跨版本兼容）构建一套可复用的数据库导航工作流。无论你是嵌入式设备调试工程师、移动端 App 开发者、Python 脚本写手，还是正在用 SQLite 做本地知识库的数据爱好者，只要你需要反复打开陌生 .db 文件、验证迁移结果、审计遗留系统或自动化生成 ORM 模型，这篇内容就是你该放在书签栏最前面的那一篇。

2. SQLite 没有 SHOW TABLES 语法？别急，它的“表目录”藏在系统表里，且比 MySQL 更干净利落

2.1 为什么官方不提供 SHOW TABLES？这不是缺陷，而是设计哲学的必然选择

MySQL、PostgreSQL 甚至 SQL Server 都原生支持 SHOW TABLES 或 SELECT table_name FROM information_schema.tables ，但 SQLite 官方文档明确写着：“SQLite does not have a SHOW TABLES command.” 初看是功能缺失，细想却是极简主义的胜利。SQLite 的定位从来不是“轻量级服务器”，而是“嵌入式零配置数据库引擎”。它不运行独立服务进程，不维护用户权限体系，不抽象出复杂的 catalog 层——它的元数据就赤裸裸地躺在你数据库文件的第一页和第二页里，以普通表的形式存在。具体来说，SQLite 把所有关于表、索引、视图、触发器的定义信息，统一存进一张名为 sqlite_master 的系统表中。这张表从数据库创建那一刻起就自动存在，不可删除，也不受事务隔离影响（哪怕你在事务中 DROP TABLE， sqlite_master 的记录也会同步更新）。它的结构非常朴素：

CREATE TABLE sqlite_master(
  type TEXT,     -- 'table', 'index', 'view', 'trigger'
  name TEXT,     -- 对象名称，如 'products' 或 'idx_products_category'
  tbl_name TEXT, -- 所属表名（对索引/触发器有意义，对表本身等于 name）
  rootpage INTEGER, -- B-tree 根页号（内部使用，调试用）
  sql TEXT         -- 创建该对象的原始 CREATE 语句
);

提示： sqlite_master 是只读视图，你不能 INSERT 或 UPDATE 它，但可以像查普通表一样 SELECT 。这是 SQLite 元数据可访问性的基石。

所以，当你在命令行输入 .tables ，它背后实际执行的就是：

SELECT name FROM sqlite_master WHERE type='table' AND name NOT LIKE 'sqlite_%' ORDER BY name;

而 .schema 命令，则是：

SELECT sql FROM sqlite_master WHERE type IN ('table','index','view','trigger') ORDER BY type, name;

这种“用标准 SQL 查系统表”的方式，比硬编码一个 SHOW 命令更符合 SQLite “一切皆表”的设计信条——它不增加语法复杂度，却把元数据控制权完全交还给开发者。你甚至可以用 Python 的 sqlite3 模块直接 cursor.execute("SELECT name FROM sqlite_master...") ，无需任何额外依赖。

2.2 为什么默认不显示 sqlite_* 表？它们不是“隐藏”，而是“系统保留”，且有明确分工

你执行 .tables 后看到的是一串干净的业务表名，比如 orders , customers , products 。但如果你加个 -all 参数（ sqlite3 -line your.db ".tables -all" ），会突然多出 sqlite_sequence , sqlite_stat1 , sqlite_stat4 等表。这些不是 bug，而是 SQLite 在不同场景下自动生成的辅助表：

• sqlite_sequence ：仅当某张表使用了 AUTOINCREMENT 主键时才会创建，用于记录该表当前最大 rowid，保证自增唯一性。它只有一行两列： name （表名）和 seq （最后分配的 rowid）。
• sqlite_stat1 和 sqlite_stat4 ：由 ANALYZE 命令生成，存储各表/索引的统计信息（如行数、页数、键分布），供查询优化器估算成本。它们的存在与否，直接影响 EXPLAIN QUERY PLAN 的准确性。
• sqlite_shm 和 sqlite_wal ：不是表，而是 WAL 模式下的共享内存和日志文件，不会出现在 sqlite_master 中。

注意： sqlite_master 本身也列在 sqlite_master 里（ type='table' AND name='sqlite_master' ），但它被 .tables 命令显式过滤掉了（ name NOT LIKE 'sqlite_%' ）。这不是为了“隐藏”，而是避免干扰日常开发——你几乎不需要手动操作这些系统表，强行修改可能导致数据库损坏。

2.3 除了 sqlite_master，还有 sqlite_temp_master ——临时表的“平行宇宙”

SQLite 支持 CREATE TEMP TABLE ，这类表只在当前数据库连接生命周期内存在，数据不落盘，也不参与 WAL 日志。它们的元数据不存于 sqlite_master ，而是存于 sqlite_temp_master 。这个表结构与 sqlite_master 完全一致，但只对当前连接可见。这意味着：

• 你在命令行里执行 .tables ，它默认只查 sqlite_master ，所以看不到临时表；
• 如果你用 PRAGMA temp_store = MEMORY ，临时表完全在内存中， sqlite_temp_master 也只存在于内存；
• 多线程环境下，每个连接有自己的 sqlite_temp_master ，互不