Marico's space

这周数据库圈子有几个值得关注的动态，踩了几个坑顺便整理出来分享下。

SQLite 数据库在 bwrap 沙盒中并发访问导致数据损坏（SQLite 论坛）

来源：https://sqlite.org/forum/info/a9ee12e5f36adc13da1f59b1912753ba08d87c596eb6cb2f1d3882270b291488

SQLite 论坛上一个老哥遇到了个棘手的问题：多个用 bwrap 沙盒化的进程同时访问同一配置目录下的 SQLite 数据库，结果数据库直接损坏了。这种玩法在嵌入式系统里做安全隔离很常见，但偏偏在 SQLite 上翻车了。

这事儿说明了一个问题：SQLite 虽然皮实，但在一些极端场景下还是会出问题。bwrap 这种激进沙盒工具可能会干扰 SQLite 的 WAL（预写日志）或者传统回滚日志机制，尤其是涉及 fsync 操作的时候。系统层面的文件锁、bwrap 的命名空间隔离、以及 SQLite 内部的一致性保证这几者搅在一起，就容易出幺蛾子。

如果你在搞嵌入式应用或者服务，需要在受限环境里跑 SQLite，这个案例必看。它提醒我们：即使在看似隔离的进程边界内，文件系统层面的干扰依然会导致数据损坏。

PostgreSQL 查询结果缓存实战指南（r/PostgreSQL）

来源：https://reddit.com/r/PostgreSQL/comments/1t9s4tg/the_monday_elephant_4_caching_postgresql_query/

“Monday Elephant”系列第四期，聊聊怎么缓存 PostgreSQL 查询结果。这个话题在高性能场景下老生常谈了，毕竟数据库负载是很多应用的瓶颈。

文章会覆盖几个层面：应用层缓存、数据库自带特性（物化视图、内置查询缓存）、以及 Redis、Memcached 这类外部方案。核心目标就一个：减少对数据库的重复查询，把资源省出来给真正需要的请求。

缓存失效策略是重点，比如 TTL 过期时间、事件驱动失效、或者 cache-aside 模式。怎么让缓存数据保持新鲜又不会引入额外的复杂度，这里头学问不小。得分析查询模式、数据变化频率、还有能接受的数据延迟，才能设计出一套真正好用的缓存层。

对 DBA 和后端开发来说，缓存绝对是 PostgreSQL 性能优化的第一招。

开源 Rust 数据库代理项目求架构反馈（r/database）

来源：https://reddit.com/r/Database/comments/1ta44bq/opensource_rust_db_proxy_looking_for_architecture/

有个老哥在搞一个开源的 Rust 数据库代理项目，目前支持 MySQL 和 PostgreSQL 两种协议，正在征集架构意见。这东西定位在应用和数据库之间做中间层，打算利用 Rust 的内存安全特性和并发性能来处理连接池、负载均衡、查询路由这些事儿。

支持两大主流数据库协议意味着适用范围挺广，能塞进各种数据架构里。开源嘛，大家都能去看代码、提意见、甚至根据自己需求魔改。这种社区驱动的项目，早期反馈对方向和稳定性都很关键。

虽然不是专门给 SQLite 用的，但它的架构思路和解决问题的方式，对搞嵌入式数据库连接优化的同学也很有参考价值。

原文链接：https://dev.to/...