首页/博客/五个进程同时写 SQLite，谁在丢数据数据库五个进程同时写 SQLite，谁在丢数据掘金2026-11-06 10:360 次浏览5 进程写 SQLite，busy_timeout=0 时 92% 事务被拒、1 万行只落 800 行；本次 100ms 7 次全落库。WAL 不让写并行，读长尾 307→4ms，最坏 268ms。原文：https://juejin.cn/post/7704689501192683561我的收藏上一篇零成本做一颗芯片：我用 OpenLane 把 SHA-256 从 Verilog 做到了 GDS下一篇Electron 发布 正文写入的三条通道与读回口径相关文章开源 yourbatis：把 MyBatis 的动态 SQL 体验带到 Go用过 MyBatis 的人，大概都能理解我们为什么喜欢它：SQL 直接写，复杂查询也能按自己的需要组织； 遇到可选条件、批量操作，用 、 、 就能表达。SQL 和0掘金内网全断，怎么核实高炉和烧结系统的数据库对接信息VPN 没连、内网全部 TCP 超时，没法实连数据库。本文记录了一次纯靠配置文件和初始化 SQL 完成数据库点位对接核实的实操过程：取证边界怎么划、yml 逐行怎么标、以及发现两个系统共享同一业务库这个最大的坑。0掘金第22章：Redis 持久化 RDB 与 AOF：数据不丢的底线1. 项目背景 1.1 业务场景 订单团队逐步把 Redis 用在了越来越多的场景——秒杀库存预热、活动资格缓存、验证码、排行榜、会话状态。刚开始大家都说"Redis 是缓存，丢了可以回源"。但随着业0掘金OpenViking连接业务系统，LLM Wiki一键编译OpenViking是火山引擎推出的Agent上下文数据库，支持文档、图片、音视频、3D等多模态数据的导入与理解。 现在，OpenViking已上线多种0掘金Redis开发实战:从入门到精通当 Redis 的 O(N) 操作遇上生产环境的大 Key 去年我们上线了一个用户行为分析系统，核心逻辑是用 Redis 的 存储用户最近 1000 次操作的事件 ID（按时间排序）。一开始跑得0掘金Redis 数据类型全解 - Bitfield：99% 开发者没用过的位域操作，把内存再砍 80%（七）BITFIELD 将连续比特视为小整数，取代多个 key 以节省内存（每合并一 key 省约 77B）。核心要点：溢出默认 WRAP 静默，需显式设 SAT/FAIL；原子但非事务，失败不回滚；布局即0掘金
