SQLite 并不像 MySQL 或 PostgreSQL 那样把元数据集中在一个服务器进程的内存字典里，它把每个表和索引的定义都作为一行记录存放在内置的 sqlite_master 表当中。这个表本质上就是一个普通的系统表，存储着 CREATE TABLE 和 CREATE INDEX 的原始 SQL 文本。因此在回答“最多能有多少张表和索引”这个问题之前，必须先理解 SQLite 的对象计数方式：表和索引并不分别计数，而是共享同一个对象编号空间。这意味着总的对象数量存在一个统一的上限，而不是表和索引各自独立拥有上限。
默认编译选项下，SQLite 使用 32 位有符号整数作为内部对象 ID，因此理论上最多可以创建 2,147,483,647 个对象。这个数字既包括表，也包括索引、触发器、视图等所有存在于 sqlite_master 中的条目。在实际使用中，很少有人会触及这个极限，因为数据库文件的大小会先成为瓶颈：每个对象至少需要消耗一个页来存储定义，即使使用最小的页大小 512 字节，两亿多个对象也需要超过 100GB 的存储空间。另外，SQLite 的 SQL 解析器对单条语句的长度和复杂度也有约束，这进一步限制了实际能管理的对象数量。
限制的内部来源：sqlite_master 与对象编号
SQLite 在打开数据库时会读取 sqlite_master 表中的全部记录，并在内存中构建一个 schema 缓存。每次执行一条 SQL 语句，解析器都需要查找这个缓存来定位表和索引。如果缓存中的对象数量非常大，那么即使是最简单的 SELECT 查询，也会因为哈希查找变慢而产生可感知的延迟。更关键的是，sqlite_master 表本身也是一个普通表，对它的扫描、过滤和排序完全依赖 SQLite 的查询引擎，没有任何特殊优化。
对象编号的分配并不是连续的。当你删除一个表再创建新表时，新表会尝试复用被删除的对象 ID，但这种复用机制依赖于 SQLITE_MAX_SCHEMA_RETRY 这一内部常量。如果频繁创建和删除大量对象，schema 版本号会不断递增，导致所有预处理语句失效，进而触发重新编译。在极端场景下，这种重编译开销可能比查询本身还要大。因此，即使理论对象数很高，实际推荐的表数量通常控制在几千张以内，并且最好保持 schema 稳定不变。
下面这段 SQL 可以查看当前数据库中所有对象的总数，以及表和索引分别占用的数量：
SELECT type, COUNT(*) AS cnt
FROM sqlite_master
WHERE type IN ('table','index','view','trigger')
GROUP BY type
ORDER BY cnt DESC;
执行结果会告诉你目前 schema 中每一类对象的具体数量。如果你发现索引数量接近表数量的好几倍，并且表数量已经达到上万张，那么就应该考虑重新评估数据库设计了。
编译参数如何影响表和索引数量上限
SQLite 的许多限制并不是硬编码在源码里的固定数字，而是可以通过编译时宏定义来调整的。SQLITE_MAX_SCHEMA_RETRY 控制 schema 变更后的重试次数，SQLITE_MAX_COLUMN 控制单表最大列数，而对象总数的上限则取决于 SQLITE_MAX_SQL_LENGTH 和 SQLITE_MAX_PAGE_SIZE 等参数的间接影响。其中最直接相关的是 SQLITE_MAX_ATTACHED，它限制了一次可以打开的数据库文件数量，因为每个附加数据库也有自己的 sqlite_master。
值得注意的是，SQLite 从来没有单独为表数量或索引数量设计一个编译选项。它的设计哲学是“用文件系统和内存资源自然限制对象数”。例如，如果你想在一个数据库中创建 500 万张表，那么仅仅存储这些表的 CREATE 语句文本就需要至少几十兆字节。在 SQLite 解析这些文本时，每一条 CREATE TABLE 都要经过词法分析和语法分析，这个过程是 O(n) 复杂度。所以即使你重新编译 SQLite 去掉了所有长度限制，实际可管理的对象数仍然受到物理内存和 CPU 时间的约束。
如果你确实需要修改默认限制，可以在编译时加入类似下面的自定义参数。以下示例演示了如何在 Linux 环境下使用 gcc 重新编译 SQLite 合并源文件，并将最大页大小提升到 65536 字节：
gcc -DSQLITE_MAX_PAGE_SIZE=65536 \
-DSQLITE_MAX_SCHEMA_RETRY=20 \
-DSQLITE_DEFAULT_PAGE_SIZE=4096 \
sqlite3.c shell.c -o sqlite3_custom
这种定制编译的方式在嵌入式设备或特种应用场景中比较常见，但对于大多数开发者来说，使用预编译的官方二进制文件已经足够。真正的瓶颈往往不是对象数量的硬上限，而是 schema 频繁变动带来的准备语句重建开销。
大规模表设计的性能影响与替代方案
创建数千张甚至上万张表的场景通常出现在多租户 SaaS 系统中，或者是在对不同的数据集做物理隔离时。SQLite 对这类设计并不友好，因为每次打开数据库都需要完整加载所有 schema 定义。如果一个数据库文件中有 5 万张表，打开数据库的时间可能需要数秒，而设计良好的单表方案即使有几百万行数据，打开时间依然在毫秒级别。这是因为 schema 加载是线性遍历 sqlite_master 表，而数据查询可以借助 B-tree 索引快速定位。
索引数量也存在同样的问题。SQLite 在插入、更新或删除一行数据时，需要同步维护该表上的所有索引。如果一张表上建了 50 个索引，那么每次写入操作都要对 50 棵 B-tree 进行修改，性能会急剧下降。官方文档建议每张表的索引数量不要超过 10 到 15 个，并且要确保每个索引都有明确的查询场景支持。盲目增加索引不仅不能提升查询速度，反而会因为写入放大和存储膨胀让整体性能恶化。
更好的替代方案是使用分区表思想，即在应用层做数据路由，把不同的数据集放在同一个 SQLite 数据库的不同表中，或者使用附加数据库把数据分散到多个文件中。例如下面这个 Python 示例展示了如何使用 ATTACH DATABASE 把不同的租户数据分离到独立的数据库文件，每个文件内部只保留少量几张表：
import sqlite3
conn = sqlite3.connect("main.db")
conn.execute("ATTACH DATABASE 'tenant_001.db' AS tenant1")
conn.execute("ATTACH DATABASE 'tenant_002.db' AS tenant2")
conn.execute("CREATE TABLE tenant1.orders (id INTEGER PRIMARY KEY, amount REAL)")
conn.execute("CREATE TABLE tenant2.orders (id INTEGER PRIMARY KEY, amount REAL)")
conn.execute("INSERT INTO tenant1.orders VALUES (1, 99.5)")
conn.execute("INSERT INTO tenant2.orders VALUES (2, 150.0)")
conn.commit()
conn.close()
这样每个数据库文件中的表数量保持在个位数，既避免了 schema 过度膨胀，又能通过附加数据库轻松扩展。对于真正的多租户应用，还可以考虑每个租户对应一个独立的 SQLite 文件，然后通过统一的连接管理器进行路由，这种模式在移动端和桌面应用中非常成熟。
总结来说，SQLite 对表和索引的数量在理论上有着接近 21 亿的对象总数上限，但实际开发中应当把表数量控制在几千张以内，索引数量每表不超过十几个。真正的限制来自 schema 解析、内存占用和写入放大，而不是那个遥远的整数边界。合理设计数据模型，把数据分散到多个文件或使用附加数据库，才是更符合 SQLite 设计哲学的做法。