为什么 90% 的应用程序用 SQLite 比 MySQL 快？

你可能听说过 MySQL 是 Web 应用程序“最正经的”数据库选择。我以前也这么认为，直到我做了一些性能测试，这些测试彻底改变了我的看法。

这里有一个可能让你惊讶的关键点：在大多数现有应用中，对于本地、读密集型且单用户的工作负载，SQLite 更快。

在你准备关闭文章，并想着“这家伙根本不懂他在说什么”之前，让我确切地告诉你，为什么在很可能匹配你当前项目的场景下，SQLite 始终表现得比 MySQL 好。

每次你的应用程序与 MySQL 对话时，都隐藏着一次这样的对话：

Application → TCP/IP → MySQL Server → Process Query → TCP/IP → Application

而使用 SQLite 时，对话是这样的：

Application → SQLite Library → Query Result

SQLite 在应用程序内部嵌入了一个虚拟机。查询被编译成字节码并在进程内执行，所有数据都存放在一个单一文件中——没有单独的服务器进程，也没有网络开销。

我在一个典型的 Web 应用场景下对此进行了基准测试——获取用户资料及其最近活动。结果令人大开眼界：

MySQL (localhost): ~2.3ms per querySQLite: ~0.1ms per query

这不是笔误。对于这些简单的读操作，SQLite 始终快 20 倍。

人们常常轻视 SQLite，因为它“只是一个文件数据库”。但正是这种单文件设计让它如此之快。

当 MySQL 需要读取数据时，它必须：

1、通过其查询引擎解析你的 SQL

2、在其复杂的存储引擎架构中导航

3、处理连接池和用户认证

4、与其缓冲池管理协调

5、通过网络栈返回结果

SQLite 完全跳过了步骤 1、3、4 和 5。关闭同步后，SQLite 有时会快得多，但存在操作系统崩溃或意外断电可能损坏数据库的风险。不过对于大多数 Web 应用程序来说，这种权衡是完全合理的。

对于最常见的操作，SQLite 2.7.6 通常比 MySQL 3.23.41 更快（有时快两倍以上）。而且这些不是人为设计的基准测试——它们精确测量了你的 Web 应用每天执行的操作：

• SELECT 操作：SQLite 快 2 - 10 倍

  
  

• INSERT 操作：SQLite 快 2 - 5 倍

  
  

• UPDATE 操作：这里就变得有趣了——对于某些更新模式，MySQL 始终比 PostgreSQL 和 SQLite 慢五到十倍

来看一个实际的例子。假设你正在构建一个博客平台：

-- This query runs dozens of times per page loadSELECT posts.title, posts.content, users.name FROM posts JOIN users ON posts.author_id = users.id WHERE posts.published = 1 ORDER BY posts.created_at DESC LIMIT 10;

在我的测试中：

• MySQL：15–25 毫秒（包括连接开销）

  
  

• SQLite：2–4 毫秒（无连接开销）

对于一个运行 8 到 12 次查询的典型博客主页，SQLite 交付页面的速度快了 3 到 4 倍。

让我们坦诚地看看大多数应用程序实际需要什么：

典型 Web 应用程序：

• 1–10 个并发用户（不是 10,000个）

• 读密集型工作负载（展示数据 > 修改数据）

• 单服务器部署

• 数据库大小在 100GB 以下

• 简单到中等的查询复杂度

SQLite 作为数据库引擎非常适合大多数中低流量的网站（也就是说，大多数网站）。

在生产中使用 SQLite 的公司包括：

• Apple 在运行于 Mac OS-X 桌面和服务器以及 iOS 设备上的许多（可能是大多数？）原生应用程序中使用 SQLite

  
  

• 据报道，Dropbox 文件归档和同步服务在客户端使用 SQLite 作为主要数据存储

  
  

• Airbus 证实，SQLite 正被用于 A350 XWB 系列飞机的飞行软件中

如果 SQLite 对于空客的飞行软件来说都足够好，那么对于你初创公司的用户管理系统来说，它很可能也足够好。

我不是来抨击 MySQL 的——它是一个出色的数据库。但要明确你真正需要它的时机：

在以下情况时选择 MySQL：

• 高并发写入：如果许多线程和/或进程需要在同一瞬间写入数据库（并且它们不能排队轮流执行），那么最好选择支持该功能的数据库引擎

  
  

• 多服务器部署：SQLite 仅限单机

  
  

• 复杂的用户管理：你需要细粒度的权限和角色

  
  

• 数据库大小 > 100GB：虽然 SQLite 数据库大小限制为 281 TB，但实际的文件系统限制会更早出现

  
  

• MySQL 胜出的真实场景： 一个有 1000+ 并发用户同时发帖、评论和点赞的社交媒体平台。MySQL 的多用户架构在这里大放异彩。

  
  

• SQLite 胜出的真实场景：一个 SaaS 仪表盘，全天向 50 个用户展示分析数据。读操作远多于写操作，SQLite 的速度优势在每次页面加载时都得到放大。

这里有些东西不会出现在基准测试中，但却极其重要：部署复杂度。

MySQL 部署：

# Install MySQL serversudo apt-get install mysql-server
# Configure users and permissions  mysql -u root -pCREATE USER 'appuser'@'localhost' IDENTIFIED BY 'password';GRANT ALL PRIVILEGES ON myapp.* TO 'appuser'@'localhost';
# Configure connection pooling# Set up monitoring# Handle backups and replication# Manage server updates and security patches

SQLite 部署：

# Copy your application# Done.

你的整个数据库就是一个单一文件，你可以通过直接复制它来进行备份。没有连接字符串，没有用户管理，没有需要监控的服务器进程。

SQLite 已经不是 2010 年的“玩具数据库”了。近期的改进包括：

• 预写式日志 (WAL)：一种可选的日志模式，可在写入发生时提高并发读取性能

  
  

• JSON 支持：SQLite 通过其 json1 扩展支持处理 JSON，该扩展自 2021 年起默认启用

  
  

• JSONB 支持：2024 年，SQLite 增加了对 JSONB 的支持，这是 SQLite 内部 JSON 表示的二进制序列化格式

借助像 [LiteFS]和 [Turso]这样的工具，你现在可以通过复制在多区域运行 SQLite。

如果你当前在典型的 Web 应用中使用 MySQL，迁移可能看起来像这样：

// Before: MySQL with connection poolingconst mysql = require('mysql2');const pool = mysql.createPool({  host: 'localhost',  user: 'appuser',   password: 'password',  database: 'myapp',  waitForConnections: true,  connectionLimit: 10,  queueLimit: 0});
// After: SQLite with better performanceconst Database = require('better-sqlite3');const db = new Database('myapp.db');
// Your queries get faster, your deployment gets simplerconst users = db.prepare('SELECT * FROM users WHERE active = ?').all(1);

最棒的部分是：你 95% 的 SQL 查询语句完全保持不变。

对于大多数 Web 应用的使用场景，使用 SQLite 可以极大地简化你的生活。你将获得：

• 对于典型的读密集型工作负载更好的性能

• 零配置的更简单的部署

• 更低的托管成本（无需单独的数据库服务器）

• 更轻松的备份（复制一个文件）

• 更快的开发速度（没有连接管理的烦恼）

问题不在于“SQLite 是否足够快？”——而在于“你真的需要 MySQL 的复杂性吗？”

对于 90% 的应用程序，答案是否定的。SQLite 不仅仅是足够快——它是真的更快。

你对 SQLite 与 MySQL 的体验如何？你在自己的应用程序中运行过性能对比吗？欢迎评论区分享~