SQLite 默认在当前连接中只打开一个主数据库文件，也就是通过 sqlite3_open() 或命令行参数指定的那个数据库。但在实际项目中，数据可能分散在多个 .db 文件里，例如订单数据在一个文件、客户信息在另一个文件、配置信息又在第三个文件。如果每次都导出导入再查询，既麻烦又容易出错。SQLite 提供的 ATTACH DATABASE 语句可以解决这个问题，它允许在同一个数据库连接中挂载多个数据库文件，并为每个附加库分配一个逻辑名称。附加成功后，就可以像操作单个数据库一样，在一条 SQL 语句里跨库查询、关联甚至写入数据。
本文会先说明 ATTACH DATABASE 的语法和参数限制，再通过实际示例演示跨库查询、内存数据库附加、事务与写入行为，最后总结一些容易踩到的坑。掌握这些内容后，你可以在不破坏原有数据文件的前提下，快速完成数据整合和临时报表。
ATTACH DATABASE 语法与参数解析
先看最基本的语法：
ATTACH DATABASE 'sales.db' AS sales;
这条语句会把当前目录下的 sales.db 文件附加到当前连接，并给它起一个逻辑名称 sales。ATTACH DATABASE 中的 DATABASE 关键字可以省略，写成 ATTACH 'sales.db' AS sales; 也完全等价。第一个参数是数据库文件的路径，可以是相对路径、绝对路径，也可以是 :memory: 表示内存数据库。第二个参数 AS 后面跟着的 sales 就是后续 SQL 语句中用来引用这个附加库的名称。
需要注意，附加库的名称不能和 SQLite 内置的两个逻辑库重名：main 和 temp。main 是主数据库连接的默认名称，temp 用于存放临时表、临时视图和临时触发器等对象。如果你尝试执行 ATTACH 'x.db' AS main;，SQLite 会直接报错。此外，同一个附加库名称也不能重复挂载，必须先 DETACH 才能再次使用。
从实现角度看，ATTACH DATABASE 并不会把附加库的文件内容复制进主库，它只是在当前连接的内存结构中增加了一个新的数据库对象。所有对附加库的读写最终都会落到对应的文件上。因此，如果附加的数据库文件不存在，SQLite 默认会创建一个空的数据库文件；如果你只想读取但不希望意外创建文件，需要提前检查文件是否存在，或者在打开连接时使用只读模式。
跨库查询与表名限定
附加数据库之后，最常用的操作就是跨库查询。SQLite 通过 别名.表名 的方式区分不同数据库中的表。例如主库里有一张 orders 表，附加的 sales 库里有一张 customers 表，可以这样关联：
SELECT o.order_id,
o.order_date,
c.customer_name
FROM main.orders AS o
JOIN sales.customers AS c ON o.customer_id = c.customer_id;
在这个查询里，main.orders 表示主库的订单表，sales.customers 表示附加库中的客户表。即使两个库里都有同名的表，只要加上库别名就可以明确指定。这里给表起了 o 和 c 的别名，是为了让 SELECT 列表更简洁。实际上，如果表名不冲突，不加 main. 前缀也可以直接引用主库表；但附加库的表必须加前缀，否则 SQLite 会先在 main 库中查找，找不到再报错。
除了 SELECT，INSERT、UPDATE、DELETE 同样可以操作附加库中的表。例如要把主库中某个临时表的统计结果写入附加库：
INSERT INTO sales.monthly_report (month, total_amount) SELECT '2025-01', SUM(amount) FROM main.payments WHERE payment_date >= '2025-01-01' AND payment_date < '2025-02-01';
这个例子中，sales.monthly_report 是附加库里的目标表，数据来源是主库中的 payments 表。你可以看到，跨库写入和单库写入的语法几乎没有区别，只是表名前面多了一个库别名。需要注意的是，附加库中的表和主库一样，必须遵守 SQLite 的 SQL 语法和类型规则；外键约束默认不会跨数据库生效，也就是说，附加库中的外键引用的父表如果在另一个数据库文件中，SQLite 不会自动检查引用完整性，需要自己保证数据一致性。
再来看一个常见场景：两个数据库文件中都有名称相同的表，比如主库和附加库都有一张 config 表。如果不加前缀直接写 SELECT * FROM config;，SQLite 会优先解析为 main.config。要访问附加库中的同名表，必须写 sales.config。这种限制在编写动态 SQL 时尤其要注意，建议所有涉及附加库的表都显式携带库别名，避免歧义。
附加内存数据库与生命周期
除了磁盘文件，ATTACH DATABASE 还支持把内存数据库挂载到当前连接。语法是把文件名写成 :memory:：
ATTACH DATABASE ':memory:' AS memdb;
执行成功后，memdb 就是一个全新的内存数据库，读写速度非常快，适合存放临时计算中间结果。比如你可以把主库中的部分数据抽取到内存库，做一些复杂的聚合或窗口函数计算，再把最终结果写回磁盘库。这样既减轻了主库文件的锁竞争，又能利用内存的高性能。
不过要特别注意生命周期。每个 :memory: 附加库都只属于当前数据库连接。一旦连接关闭，内存库中的表和数据全部消失，不会写入任何文件。如果同一个连接内先后执行两次 ATTACH DATABASE ':memory:' AS mem1; 和 ATTACH DATABASE ':memory:' AS mem2;，你会得到两个互相独立的内存数据库，它们之间没有任何共享数据。这与某些数据库系统的全局内存表不同，SQLite 的内存库是连接级别的私有对象。
还有一个容易混淆的点：主连接本身也可以通过 :memory: 打开，例如命令行执行 sqlite3 :memory:。此时 main 库就是内存数据库，而通过 ATTACH 附加的磁盘库可以正常和内存主库一起查询。反之，如果主库是磁盘文件，附加 :memory: 作为缓存层，也是常见用法。但不管怎么组合，内存库都不会持久化，进程退出后数据即丢失。
多库事务与写入限制
SQLite 在同一个连接中支持跨多个数据库文件的事务。也就是说，你可以 BEGIN; 后同时修改主库和附加库中的表，再 COMMIT;。例如：
BEGIN; UPDATE main.accounts SET balance = balance - 100 WHERE id = 1; UPDATE sales.ledger SET amount = amount + 100 WHERE account_id = 1; COMMIT;
这两条更新语句会作为一个原子操作提交。如果中途出错，可以执行 ROLLBACK; 同时撤销对两个数据库文件的修改。不过这个能力依赖于 SQLite 的崩溃恢复机制。默认的 rollback journal 模式下，跨库事务是可以正常工作的，但需要保证所有涉及的数据库文件都有写入权限，并且目录可创建临时日志文件。如果其中一个文件所在的文件系统只读，事务会在写入该文件时失败，之前对另一个库的写入也会被回滚。
在多线程或多进程环境下，多个连接同时附加同一个数据库文件时，会面临锁竞争。SQLite 使用文件锁来实现并发控制，写操作会尝试获取 EXCLUSIVE 锁。如果连接 A 正在写主库，连接 B 同时想写附加库中的同一个文件，就可能触发 SQLITE_BUSY 错误。可以通过设置 busy_timeout 或使用 WAL 模式来缓解。但要注意，WAL 模式对于附加数据库的支持和主库一样，每个数据库文件的 journal 模式需要单独设置。例如想让附加库也使用 WAL，可以执行 PRAGMA sales.journal_mode=WAL;。
另一个限制是 VACUUM。如果你想对附加库执行 VACUUM，不能直接写 VACUUM sales;，因为 SQLite 的 VACUUM 只适用于主数据库。要清理附加库，需要先 DETACH，再用独立的连接打开那个文件执行 VACUUM，最后重新 ATTACH。类似地，某些 PRAGMA 语句需要通过 PRAGMA 别名.参数 来指定目标库，否则默认作用于主库。
完成附加库的使用后，应该及时执行 DETACH DATABASE sales; 释放资源。DETACH 会关闭对应的数据库文件句柄，并把附加库从连接中移除。需要注意的是，如果附加库上还有活动的事务或已编译的 SQL 语句，DETACH 可能会失败。最佳实践是在事务结束、所有查询游标释放之后再进行 DETACH。
常见误区与实用建议
第一个误区是认为附加数据库能突破 SQLite 的单文件限制，实现分布式存储。事实上，ATTACH DATABASE 只是在单个连接中同时打开多个文件，所有文件最终仍然依赖本地文件系统和单机锁。它适合数据分区、历史归档、临时整合等场景，但并不能替代真正的分布式数据库。对于超大吞吐量的写入，附加多库并不会带来水平扩展能力，反而可能因为多个文件的事务协调增加锁等待。
第二个误区是忽略文件路径的可移植性。如果附加库使用相对路径，SQLite 会基于当前工作目录解析，而不是基于主数据库文件所在目录。因此在不同工作目录下启动程序，可能导致附加库路径变化，甚至创建出空的数据库文件。建议在代码中显式拼接绝对路径，或者基于主库文件路径计算附加库路径。例如在 Python 中可以通过 os.path.join(os.path.dirname(main_db), 'sales.db') 得到可靠路径。
第三个误区是误以为附加库可以自动同步 schema。实际上，ATTACH DATABASE 不会同步任何表结构。如果有两个数据库文件需要保持相同的表结构，开发者必须自行维护迁移脚本。比如在升级系统时，需要对主库和所有附加库分别执行 DDL，否则跨库查询时会因为缺少列而报错。建议把附加库的结构变更纳入统一的版本管理，启动时检查 PRAGMA user_version 或专用版本表。
最后给一个实用建议：当跨库查询非常频繁时，可以在附加库上创建视图或索引，把常用的关联逻辑固化下来。例如在附加库中创建一个视图：
CREATE VIEW sales.v_order_customer AS
SELECT o.order_id,
o.order_date,
c.customer_name
FROM main.orders AS o
JOIN sales.customers AS c ON o.customer_id = c.customer_id;
这样后续业务代码只需要 SELECT * FROM sales.v_order_customer;，不用每次都写复杂的 JOIN。索引方面，SQLite 支持在附加库表上创建索引，但要注意索引文件仍然存储在对应的数据库文件里，不会单独生成文件。对于只读附加库，则无法创建视图或索引，需要提前规划。
总的来说，ATTACH DATABASE 是 SQLite 提供的一项非常实用的多库协作能力。只要理解它的别名机制、生命周期以及事务和锁的行为，就能在合适的场景中大幅提升数据整合效率。实际使用时，建议先把附加库的路径、命名、权限管理规范化，再编写跨库查询代码，避免后续维护成本失控。
SQLite ATTACH DATABASE附加数据库跨库查询修改时间：2026-09-25 05:30:28