你可能听说过 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 query
SQLite: ~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 load
SELECT 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 倍。
四、90% 使用场景的现实考量
让我们坦诚地看看大多数应用程序实际需要什么：
典型 Web 应用程序：
- 1–10 个并发用户（不是 10,000个）
- 读密集型工作负载（展示数据 > 修改数据）
- 单『服务器』部署
- 数据库大小在 100GB 以下
- 简单到中等的查询复杂度
SQLite 作为数据库引擎非常适合大多数中低流量的网站（也就是说，大多数网站）。
在生产中使用 SQLite 的公司包括：
- Apple 在运行于 Mac OS-X 桌面和『服务器』以及 iOS 设备上的许多（可能是大多数？）原生应用程序中使用 SQLite
- 据报道，Dropbox 文件归档和同步服务在客户端使用 SQLite 作为主要数据存储
- Airbus 证实，SQLite 正被用于 A350 XWB 系列飞机的飞行软件中
如果 SQLite 对于空客的飞行软件来说都足够好，那么对于你初创公司的用户管理系统来说，它很可能也足够好。
五、MySQL 真正胜出的地方（以及你为什么应该关心）
我不是来抨击 MySQL 的——它是一个出色的数据库。但要明确你真正需要它的时机：
在以下情况时选择 MySQL：
- 高并发写入：如果许多线程和/或进程需要在同一瞬间写入数据库（并且它们不能排队轮流执行），那么最好选择支持该功能的数据库引擎
- 多『服务器』部署：SQLite 仅限单机
- 复杂的用户管理：你需要细粒度的权限和角色
- 数据库大小 > 100GB：虽然 SQLite 数据库大小限制为 281 TB，但实际的文件系统限制会更早出现
- MySQL 胜出的真实场景： 一个有 1000+ 并发用户同时发帖、评论和点赞的『社交媒体』平台。MySQL 的多用户架构在这里大放异彩。
- SQLite 胜出的真实场景：一个 SaaS 仪表盘，全天向 50 个用户展示分析数据。读操作远多于写操作，SQLite 的速度优势在每次页面加载时都得到放大。
六、部署简便性因素
这里有些东西不会出现在基准测试中，但却极其重要：部署复杂度。
MySQL 部署：
# Install MySQL server
sudo apt-get install mysql-server
# Configure users and permissions
mysql -u root -p
CREATE 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
SQLite 已经不是 2010 年的“玩具数据库”了。近期的改进包括：
- 预写式日志 (WAL)：一种可选的日志模式，可在写入发生时提高并发读取性能
- JSON 支持：SQLite 通过其 json1 扩展支持处理 JSON，该扩展自 2025 年起默认启用
- JSONB 支持：2024 年，SQLite 增加了对 JSONB 的支持，这是 SQLite 内部 JSON 表示的二进制序列化格式
借助像 [LiteFS]和 [Turso]这样的工具，你现在可以通过复制在多区域运行 SQLite。
八、进行切换：一个实用的迁移方案
如果你当前在典型的 Web 应用中使用 MySQL，迁移可能看起来像这样：
// Before: MySQL with connection pooling
const 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 performance
const Database = require('better-sqlite3');
const db = new Database('myapp.db');
// Your queries get faster, your deployment gets simpler
const users = db.prepare('SELECT * FROM users WHERE active = ?').all(1);
最棒的部分是：你 95% 的 SQL 查询语句完全保持不变。
九、关键结论
对于大多数 Web 应用的使用场景，使用 SQLite 可以极大地简化你的生活。你将获得：
- 对于典型的读密集型工作负载更好的性能
- 零配置的更简单的部署
- 更低的托管成本（无需单独的数据库『服务器』）
- 更轻松的备份（复制一个文件）
- 更快的开发速度（没有连接管理的烦恼）
问题不在于“SQLite 是否足够快？”——而在于“你真的需要 MySQL 的复杂性吗？”
对于 90% 的应用程序，答案是否定的。SQLite 不仅仅是足够快——它是真的更快。
你对 SQLite 与 MySQL 的体验如何？你在自己的应用程序中运行过性能对比吗？欢迎评论区分享~
作者丨Sohail Saifi
来源丨网址：https://medium.com/@sohail_saifi/why-sqlite-is-faster-than-mysql-for-90-of-applications-8f44c5460379
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
