编程与软件工程sqlite.org
在 SQLite 中，大量小查询同样高效
Many small queries are efficient in SQLite
2021 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
SQLite 官方文章，回应'单页执行 200 条 SQL 查询是糟糕设计'的批评：由于 SQLite 进程内、无网络往返的架构，执行大量小查询的开销极低，很多小查询反而是高效的做法。文章解释了为什么传统数据库的 N+1 查询问题在 SQLite 上并不成立。
为什么经久不衰：它挑战了'查询越少越好'的行业教条，多年后仍能纠正开发者对数据库性能的直觉，对架构选型有实际参考价值。
HN 评论精选
推荐 SQLite：速度快且单文件数据库非常实用
如果你还没试过 SQLite，请一定试试。多年来我一直忽视它而用 MySQL，但一旦见识到 SQLite 有多快，以及整个数据库装在单个文件里的优势……别像我一样忽视它多年，去玩玩吧，它很棒。
Laminary查看英文原文
If you haven't tried SQLite, please do. For years I ignored SQLite and used MySQL (it does the job) but once you see how fast SQLite is, and advantages of having a DB contained in a single file... just go play around with SQLite instead of ignoring it for years like me. It's neat.
SQLite 的高效小查询特性天然化解了 GraphQL 的 N+1 问题
SQLite 的这个特性带来一个有趣的结果：它非常适合 GraphQL。GraphQL 几乎天生就有 N+1 查询问题，即使用 data loader 模式费力规避，仍可能有人写出触发一连串 SELECT 的查询。而既然'SQLite 中大量小查询很高效'，直接用它就行。我写了一个 Datasette 插件为现有 SQLite 数据库暴露 GraphQL API，效果之好让我从 GraphQL 怀疑者变成了拥护者。一个嵌套 GraphQL 查询执行了 32 条 SELECT，依然非常快。
simonw查看英文原文
An interesting consequence of this characteristic of SQLite is that it makes it a really good fit for GraphQL. GraphQL has the N+1 queries problem pretty much baked into it. You can work around it to a certain extent with a lot of effort implementing data loader patterns, but someone will still likely be able to cow up with a query that triggers a cascade of SELECTs. Or, because "many small queries are efficient in SQLite", you could use that instead. I built a Datasette plugin that exposes a GraphQL API to an existing SQLite database and it works so well that I switched from being a GraphQL skeptic to a GraphQL advocate. https://simonwillison.net/2020/Aug/7/datasette-graphql/ Here's an example nested GraphQL query that executes 32 select queries. It's pretty snappy: https://datasette-graphql-demo.datasette.io/graphql?query=%7B%0A%20%20repos(first%3A%2010%2C%20search%3A%20%22datasette%22%2C%20sort_desc%3A%20stargazers_count)%20%7B%0A%20%20%20%20totalCount%0A%20%20%20%20pageInfo%20%7B%0A%20%20%20%20%20%20endCursor%0A%20%20%20%20%20%20hasNextPage%0A%20%20%20%20%7D%0A%20%20%20%20nodes%20%7B%0A%20%20%20%20%20%20full_name%0A%20%20%20%20%20%20description%0A%20%20%20%20%20%20stargazers_count%0A%20%20%20%20%20%20created_at%0A%20%20%20%20%20%20owner%20%7B%0A%20%20%20%20%20%20%20%20name%0A%20%20%20%20%20%20%20%20html_url%0A%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20issues_list(first%3A%203)%20%7B%0A%20%20%20%20%20%20%20%20totalCount%0A%20%20%20%20%20%20%20%20nodes%20%7B%0A%20%20%20%20%20%20%20%20%20%20title%0A%20%20%20%20%20%20%20%20%20%20created_at%0A%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%7D%0A%20%20%20%20%7D%0A%20%20%7D%0A%7D%0A
调侃现实中'200 条查询'在不同语境下标准截然不同
有趣的是，在我最近工作过的地方，内部标准是'如果只跑 200 条查询，那就算优化得够好了'。
ThePadawan查看英文原文
> The Appropriate Uses For SQLite page says that dynamic pages on the SQLite website typically do about 200 SQL statements each. This has provoked criticism from readers. Examples: > "200 SQL statements is a ridiculously high number for a single page" > "For most sites, 200 queries is way, way, way too much." > "[This is] bad design" Funnily enough, at a recent workplace the guideline was "if it only does 200 queries, you've optimized it enough".
SQLite 作为教学数据库有类型检查和 SQL 标准兼容性方面的短板
我只用过 PostgreSQL。妻子（会计学教授）需要一个数据库教学生 SQL，我热心推荐了 SQLite，因为简单。但这可能不是最好的决定：1. 没有类型检查！DDL 里声明 int 列，插入文本 SQLite 也照存不报错；2. 不支持 FULL OUTER JOIN，妻子只能教学生用 UNION 替代，很烦人；视图也有奇怪的问题。我现在觉得选 SQLite 比我想的要更微妙。
reacharavindh查看英文原文
I have only worked with PostgreSQL and when the wife(Accounting Professor) needed a DB to teach their students SQL, I heartily took her down the SQLite path because of its simplicity. It may not have been the best decision as I see her now fighting with its warts like 1. No type checking! Declare a column as int in DDL, and insert a text, SQLite happily stores it without an error :-( 2. No full outer join... instead my wife taught the students the standard SQL syntax and told them to use UNION with SQLite because it does not support that syntax. This is where it gets annoying. I can’t recollect, but there were issues with views as well which sounded really weird. I now think the choice of SQLite is more nuanced than I believed it to be.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选