MySQL on Snow

数据库全景指南：从 SQLite 到 MongoDB，一文搞懂选型与差异

Tue, 07 Jul 2026 21:04:00 +0800

数据库全景指南：从 SQLite 到 MongoDB，一文搞懂选型与差异

MySQL、PostgreSQL、MongoDB、Redis、Cassandra、Neo4j、Elasticsearch…… 数据库多到让人眼花。本文从分类、原理、模型、选型、组合五个维度，带你看清它们各自的边界与适用场景。

一、为什么会有这么多数据库？

先抛一个真实的尴尬场景：

新人入职第一天，被安排设计一个博客系统。他下意识打开 Navicat，建了一张 articles 表，写到第三天发现：文章正文要存富文本，字数可能上万；评论数据要嵌套在文章里；标签数量不固定；还要做全文搜索。继续用 MySQL 越写越别扭，最后只能上 ES 做搜索、MongoDB 存正文、MySQL 存元数据。

这不是个例。没有一种数据库能赢下所有场景，根本原因是存储需求里同时存在四组矛盾：

结构化 vs 灵活：业务模型固定还是多变
一致性 vs 可用性：要数据绝对正确，还是允许短暂数据不一致换可用性
规模 vs 性能：单机极致性能还是分布式海量吞吐
读写均衡 vs 海量写入：典型 Web 应用还是 IoT 流式写入

围绕这些矛盾，业界演化出了关系型、键值、文档、列族、图、搜索、时序、列存分析等 八大分支。每解决一组矛盾，就诞生一类新数据库。

二、数据库分类全景图

上图把主流数据库按"数据模型 + 适用场景"分成了 8 类。下面我们逐类展开，但在分类之前，必须先理解三个底层概念：ACID、CAP、BASE。它们决定了数据库的"性格"。

三、ACID vs BASE：两种一致性哲学

ACID：关系型数据库的承诺

ACID 是事务的四大保证，是关系型数据库压箱底的能力：

字母	含义	通俗解释
A Atomicity 原子性	事务要么全成功，要么全回滚	转账扣款和加款必须同时发生
C Consistency 一致性	事务前后满足所有约束	主键、外键、CHECK 不能被破坏
I Isolation 隔离性	并发事务互不干扰	MVCC + 锁机制保证
D Durability 持久性	提交后即使宕机也不丢	通过 WAL / redo log 实现

为 ACID 付出的代价：锁竞争、跨节点协调延迟、水平扩展难。这也是为什么单机 MySQL 通常撑到几千 QPS 就开始考虑读写分离。

BASE：分布式系统的妥协

当系统走向分布式，强一致性的代价过高，业界提出 BASE 作为 AP 系统的设计哲学：

BA Basically Available 基本可用：允许响应变慢、允许功能降级
S Soft State 软状态：允许存在中间状态
E Eventually Consistent 最终一致：不保证任意时刻一致，但保证最终收敛

关键认知：ACID 中的 C 是事务一致性（约束不被破坏），CAP 中的 C 是副本一致性（多节点数据相同），两者不是一回事。

四、CAP 定理：分布式系统的三角抉择

CAP 定理由 Eric Brewer 在 2000 年提出，断言：一个分布式系统最多只能同时满足 Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错）三者中的两个。

三个关键认知

① P 不可避免

真实分布式系统必然存在网络分区（交换机抖动、机房断连、节点宕机）。所以工程师实际上只能在 C 和 A 之间做选择：

分区时拒绝写入 → CP，保证数据正确，但牺牲可用性
分区时仍可读写 → AP，保证可用性，但允许数据短暂不一致

② 三种组合的典型代表

组合	牺牲项	典型数据库	典型场景
CA	分区容错	MySQL 单机、PostgreSQL 单机	传统单机业务
CP	可用性	HBase、MongoDB、Redis 集群	强一致优先的金融、配置
AP	一致性	Cassandra、DynamoDB、Eureka	高可用的社交、推荐

③ 同一业务可灵活切换

注册中心是个经典例子：ZooKeeper 是 CP，选举期间不可用；Eureka 是 AP，节点之间不强制同步。Netflix 选 Eureka，因为它能容忍注册信息短暂不一致，但不能容忍服务发现挂掉。

五、关系型数据库：稳如泰山的基石

关系型数据库以 二维表 + SQL + ACID 事务 为核心，是 90% 业务系统的默认选择。

5.1 五大主流 RDBMS 对比

数据库	厂商 / 协议	强项	适用场景
MySQL	开源（GPL/商业双协议）	生态成熟、运维资料最多	Web 应用、电商、CMS
PostgreSQL	开源（BSD）	复杂查询、JSON、PostGIS、扩展性强	复杂业务、地理数据、数据分析
SQLite	开源（公有领域）	嵌入式、零配置、单文件	移动端、嵌入式、原型、测试
Oracle	商业	企业级功能、稳定性、技术支持	银行、电信、政府核心系统
SQL Server	商业（微软）	与 .NET 生态深度集成	企业内部系统、Windows 环境

5.2 选型经验

个人项目 / 小工具：SQLite，单文件零配置
Web 应用首选：MySQL（运维生态好）或 PostgreSQL（功能强、复杂查询爽）
企业核心系统有预算：Oracle 或 SQL Server，看团队技术栈
要不要选 PostgreSQL 而不是 MySQL？ 如果业务里有复杂分析、地理数据、强约束、JSON 字段，PG 更合适；如果只是 CRUD + 简单关联，MySQL 更省心

5.3 关系型的硬伤

水平扩展难：分库分表后跨库 JOIN、事务都成噩梦，需要引入 ShardingSphere、Vitess 之类的中间件
Schema 变更贵：上亿行表加索引可能锁表几小时
高并发写入瓶颈：单机通常几千 QPS，靠缓存兜底

六、NoSQL 的崛起：四大家族

NoSQL（Not Only SQL）的核心动机：通过放松某个约束（一致性 / Schema / 关系），换取扩展性、性能或灵活性。

6.1 SQL vs NoSQL 数据模型对比

左图是关系型的方式：范式化拆表 + 外键关联，查 Alice 的订单要 JOIN 两张表。右图是文档型的方式：聚合存储 + 内嵌文档，Alice 的订单直接嵌在她的文档里，一次读取拿全。

两种模型各有利弊：

维度	关系型（SQL）	文档型（NoSQL）
Schema	严格固定	灵活可变
关联查询	JOIN 强	弱（要靠应用层）
数据冗余	低（范式化）	高（反范式）
事务	强 ACID	弱（多文档 4.0+ 才支持）
扩展性	垂直为主	易水平分片
适合	关系复杂、强一致	模型多变、读多写少

6.2 键值型：Redis

Redis 是最被低估的"瑞士军刀"。它表面上是个缓存，实际上能做：

缓存：最常见，热点数据加速
会话存储：分布式 Session
排行榜：ZSet 天生支持
消息队列：List / Stream
限流器：INCR + EXPIRE
分布式锁：SETNX / Redlock

选型提醒：Redis 是 CP 系统（集群模式下）—— 主节点挂掉会触发故障转移，期间集群不可用。不是所有 Redis 都"高可用"。

6.3 文档型：MongoDB

MongoDB 用 BSON（二进制 JSON）存储，每个文档自包含。它的甜点场景：

内容管理：文章、评论、附件，结构天然嵌套
IoT 设备元数据：不同设备字段不同，灵活 Schema 太香
快速迭代业务：需求变就加字段，不用 ALTER TABLE
日志聚合：MongoDB 的聚合管道 + 副本集很合用

坑点：MongoDB 4.0 才支持多文档事务，复杂事务场景慎用。索引设计不当会让查询慢到怀疑人生。

6.4 列族型：Cassandra / HBase

列族型数据库把"行"打散成"列族"，同一列的数据连续存储，对"按列聚合 + 海量写入"特别友好。

Cassandra：AWS Dynamo 论文的开源实现，无主架构，写入性能极强。Netflix、Instagram、Apple 都在用
HBase：基于 HDFS，强一致，适合离线大数据
ScyllaDB：用 C++ 重写的 Cassandra，性能高一个数量级

典型场景：时序数据、推荐特征存储、消息历史归档。Cassandra 在写入 QPS 上能轻松甩开 MySQL 一个数量级。

6.5 图型：Neo4j

如果业务核心是关系（不是表关联，而是多跳关系遍历），用图数据库比 SQL 递归查询快几个数量级。

// Neo4j 查询：找到 Alice 三度人脉里喜欢 Go 语言的人
MATCH (a:User {name:'Alice'})-[:KNOWS*1..3]-(friend:User)
WHERE friend.language = 'Go'
RETURN friend

典型场景：社交网络（好友推荐）、反欺诈（团伙识别）、知识图谱、IT 资产拓扑。

用 MySQL 写"找三度人脉"要用 4 层自连接，性能爆炸；Neo4j 用邻接表存储，时间复杂度近似 O(1)。

七、专用场景数据库：搜索 / 时序 / 列存

通用数据库做不到极致，专用数据库在特定领域把性能压榨到极限。

7.1 搜索引擎：Elasticsearch

ES 用 倒排索引 实现秒级全文检索，是 ELK（Elasticsearch + Logstash + Kibana）的核心。

商品搜索：分词、同义词、纠错、相关性排序
日志分析：海量日志聚合，按时间维度切片
可观测性：APM、链路追踪数据存储

重要认知：ES 不是数据库替代品。它写入延迟较高（近实时，1 秒刷新），不适合做强一致主存储。通常 MySQL 是真相源，ES 是搜索副本，通过 Canal/Debezium 同步。

7.2 时序数据库：InfluxDB / TimescaleDB

时序数据有显著特征：写多读少、按时间顺序、自动降采样、旧数据可丢弃。专用 TSDB 的写入性能比 MySQL 高 1-2 个数量级。

InfluxDB：Go 写的，单机性能强，TSM 存储引擎
TimescaleDB：PostgreSQL 扩展，能用 SQL，事务保证更好
Prometheus：监控专用，pull 模型
TDengine：国产，物联网场景优化

典型场景：服务器监控、IoT 传感器、金融行情、用户行为埋点。

7.3 列存分析：ClickHouse

OLAP 场景的核心诉求：扫描 TB 级数据，做 GROUP BY 聚合，秒级返回。行存数据库（MySQL）做这种扫描会读大量无关列，列存数据库只读需要的列，性能差几十倍。

-- ClickHouse 典型查询：秒级扫描 10 亿行
SELECT
    toDate(event_time) AS day,
    city,
    count() AS pv,
    uniq(user_id) AS uv
FROM events
WHERE event_time >= today() - 30
GROUP BY day, city
ORDER BY day DESC, pv DESC

对比：同样的查询，MySQL 要几十分钟，ClickHouse 通常 1 秒内。

八、数据库选型决策树

讲了这么多，实战怎么选？下图给出一份决策路径：

三条选型铁律

① 先 SQL，后 NoSQL

绝大多数项目从 MySQL / PostgreSQL 起步就够了。遇到具体瓶颈（缓存、搜索、海量写入、复杂关系）再引入对应专用数据库。一开始就上"全家桶"是过度设计。

② 没有银弹，组合使用

工业界真实系统几乎都是多库组合：核心业务用 MySQL/PG，缓存用 Redis，搜索用 ES，日志用 MongoDB/ES，监控用 InfluxDB，分析用 ClickHouse。让每个数据库只做它最擅长的事。

③ 团队熟悉度优先

再先进的数据库，没人会运维也是灾难。Cassandra 写入性能强，但运维门槛极高，国内很多团队踩坑后还是换回了 MySQL 分库分表。选团队能掌控的，而不是最潮的。

九、真实项目中的数据库组合架构

光说不练假把式。下图是一个典型电商系统的多库协同架构：

数据流拆解

① 写路径：订单服务先写 MySQL（强一致保证），同时发 Kafka 事件，下游消费者异步更新 ES 搜索索引和推荐系统特征库。这是经典的 “先写主库，再异步同步” 模式。

② 读路径：

请求类型	走的数据库	理由
商品详情	Redis 缓存 → MongoDB	缓存挡 95% 流量，回源用文档库装多变 SKU
商品搜索	Elasticsearch	倒排索引秒级响应
好友推荐	Neo4j	多跳关系遍历
个人订单	MySQL	强一致，按用户分库
监控大盘	InfluxDB	时序聚合，秒级出图

③ 监控旁路：所有服务通过 SDK 把指标推送到 InfluxDB，不参与业务主链路，监控挂掉不影响交易。这是旁路系统的设计铁律。

为什么要拆？

如果不拆，全塞进 MySQL 会发生什么？

商品搜索做 LIKE ‘%关键词%’ → 全表扫描，慢到超时
监控指标每秒几十万条写入 → MySQL 单机扛不住
好友推荐用 4 层自连接 → 几秒出不来结果
商品 SKU 字段每类目都不同 → ALTER TABLE 改到吐血

每个专用数据库的存在，都是为了 解决某一类 MySQL 不擅长的问题。

十、核心差异对照表

最后用一张表把主流数据库的关键指标摊开对比：

数据库	类型	一致性	Schema	事务	水平扩展	典型 QPS	适合场景
MySQL	关系	ACID	严格	强	难（需中间件）	几千	Web 主流
PostgreSQL	关系	ACID	严格	强	难	几千	复杂业务
SQLite	关系	ACID	严格	强	不可	单线程	嵌入式
Redis	KV	CP	无	弱	集群分片	10万+	缓存
MongoDB	文档	CP（可调）	灵活	4.0+ 多文档	易分片	几万	内容管理
Cassandra	列族	AP（可调）	灵活	弱	极易	10万+ 写入	海量写入
Neo4j	图	ACID	半结构	强	难	几千	关系网络
Elasticsearch	搜索	近实时	动态映射	弱	易分片	几万	全文搜索
InfluxDB	时序	CP	标签+字段	弱	集群版收费	10万+ 写入	监控指标
ClickHouse	列存	CP	严格	弱	易分片	100万+ 写入	大数据分析

总结

回到最初的问题：SQLite、MySQL、MongoDB 有什么区别？ 它们不是"谁更好"的关系，而是"为不同问题而生"的不同工具。

回顾本文核心要点：

没有银弹：每种数据库都是某组矛盾的产物，关系型解决一致性、NoSQL 解决扩展性、专用库解决极端场景
理论先行：理解 ACID / BASE / CAP，是看懂所有数据库设计意图的钥匙
SQL 不死：关系型依然是 90% 业务系统的默认选择，NoSQL 是补充而非替代
组合才是常态：工业界真实系统几乎都是多库协同，让每个数据库只做它最擅长的事
选型三铁律：先 SQL 后 NoSQL、没有银弹要组合、团队熟悉度优先

下一步行动建议：

审视你当前的项目：是不是把所有数据都塞在 MySQL 里了？哪些场景其实更适合专用数据库？
挑一个不熟的数据库试一试：Redis / MongoDB / ES 任选一个，跑一遍官方 Quick Start
关注 NewSQL：TiDB、CockroachDB、YugabyteDB 这些"既有 ACID 又能水平扩展"的下一代数据库正在崛起

记住：好的架构师不在于会多少种数据库，而在于知道每种数据库的边界在哪。

本文涉及的所有数据库选型都基于公开文档与工程实践，具体落地还需结合团队技术栈、运维能力、预算综合判断。

MySQL教程

Sat, 04 Apr 2026 13:48:03 +0800

前言

欢迎来到 MySQL 的世界！无论你是刚接触编程的新手，还是想要补充数据库技能的开发者，这份教程都将为你提供最系统、最详细的学习路径。

MySQL 作为全球最流行的开源关系型数据库，凭借其轻量、高效、跨平台、免费的特性，已经成为 Web 开发、数据分析、后端服务的标配存储方案。从个人博客到大型电商平台，从学生管理系统到金融交易系统，MySQL 都能胜任。

本教程全程基于MySQL 8.0 LTS 稳定版编写，覆盖从环境搭建到生产级运维的全流程，所有代码均可直接复制执行，所有知识点都配有实战案例，确保零基础的你也能一步到位，彻底掌握 MySQL。

第一章：MySQL 基础认知

在动手操作之前，我们先搞懂几个核心概念，帮你建立对 MySQL 的整体认知。

1.1 核心概念

概念	通俗解释
数据库（DB）	存储数据的大仓库，一个 MySQL 服务可以装很多个仓库，比如电商库、学生库
数据表（Table）	仓库里的 Excel 表格，用来分类存储数据，比如用户表、订单表
字段（Column）	表格里的列，比如用户表的`id`、`name`、`age`
记录（Row）	表格里的行，一条完整的数据，比如`1,张三,20`就是一个用户的记录
SQL	操作数据库的标准语言，就像你和数据库沟通的普通话

1.2 MySQL 整体架构

MySQL 采用经典的客户端 - 服务器架构，整个系统分为三层，理解这个架构能帮你搞懂 SQL 是怎么执行的：

连接层：负责处理客户端的连接请求、权限验证
服务层：核心层，负责 SQL 解析、优化、执行，还有内置函数、权限管理等
存储引擎层：真正负责数据存储和提取的模块，不同引擎有不同的特性

1.3 存储引擎：选对工具事半功倍

MySQL 的存储引擎就像不同的文件管理器，你可以根据业务需求选择：

引擎	特点	适用场景
InnoDB	默认引擎，支持事务、外键、行级锁， crash-safe	99% 的业务场景，生产环境首选
MyISAM	轻量，不支持事务，表级锁，查询快	只读的日志表、静态数据
Memory	数据存在内存里，速度极快，重启就没	临时缓存表、中间计算

💡 提示：不用纠结，直接用默认的 InnoDB 就对了，它能满足你所有的学习和开发需求。

第二章：环境搭建：全平台安装指南

这一章我们来搞定 MySQL 的安装，覆盖 Windows、Linux、Mac 三大平台，每一步都有避坑提示，保证你一次成功。

2.1 Windows 平台安装（图形化界面，新手首选）

Windows 用户推荐用官方的 MSI 安装包，全程图形化操作，不用敲命令。

步骤 1：下载安装包

打开官网下载页：https://dev.mysql.com/downloads/installer/
下载MySQL Installer for Windows的完整安装包（约 500M，不要下小的在线包）

步骤 2：安装流程

双击安装包，选择Developer Default（开发者默认），这个会自动帮你装齐所有需要的组件
等待依赖安装完成，一路 Next 到配置页面
Type and Networking：保持默认，端口 3306 不要改
认证方式：保持默认的强密码加密
设置 root 密码：务必记牢！比如Mysql@2026，要包含大小写、数字、特殊字符
Windows 服务：保持默认，勾选开机自启
点击 Execute，等待安装完成

步骤 3：配置环境变量（解决 mysql 不是内部命令）

找到 MySQL 的 bin 目录，默认是C:\Program Files\MySQL\MySQL Server 8.0\bin
右键此电脑→属性→高级系统设置→环境变量
找到系统变量里的 Path，双击添加上面的 bin 目录
重启 CMD，输入mysql -u root -p，输入密码能进入命令行就成功了！

2.2 Linux 平台安装（生产环境主流）

Linux 是企业生产环境的首选，我们覆盖 CentOS 和 Ubuntu 两大主流发行版。

CentOS/Rocky Linux 安装

# 1. 卸载系统自带的mariadb，避免冲突
yum remove -y mariadb*
# 2. 配置MySQL官方源
wget https://dev.mysql.com/get/mysql80-community-release-el8-3.noarch.rpm
rpm -ivh mysql80-community-release-el8-3.noarch.rpm
# 3. 安装MySQL
yum install -y mysql-community-server
# 4. 启动服务，设置开机自启
systemctl start mysqld
systemctl enable mysqld
# 5. 获取临时密码
grep 'temporary password' /var/log/mysqld.log
# 6. 登录修改密码
mysql -u root -p
ALTER USER 'root'@'localhost' IDENTIFIED BY 'Mysql@Linux2026!';

Ubuntu/Debian 安装

# 1. 更新源，清理旧版本
apt update -y && apt upgrade -y
apt remove -y mysql* mariadb*
# 2. 安装MySQL
apt install -y mysql-server
# 3. 启动服务
systemctl start mysql
systemctl enable mysql
# 4. 执行安全加固，设置密码
mysql_secure_installation

2.3 Mac 平台安装（Homebrew 一键搞定）

Mac 用户强烈推荐用 Homebrew 安装，比 dmg 包简单太多，自动适配 Intel 和 M 芯片。

# 1. 如果你没装Homebrew，先装它
/bin/bash -c "$(curl -fsSL https://mirrors.ustc.edu.cn/misc/brew-install.sh)"
# 2. 安装MySQL
brew update
brew install mysql
# 3. 启动服务
brew services start mysql
# 4. 安全加固，设置密码
mysql_secure_installation

2.4 安装报错急救包

99% 的安装失败都是这些问题，对照着解决：

1045 错误：密码错误：检查密码大小写，不要复制多余空格
2003 错误：连不上服务器：MySQL 服务没启动，或者防火墙拦了 3306 端口
命令找不到：环境变量没配对，重启终端试试
服务启动失败：之前的 MySQL 没卸载干净，或者路径有中文

第三章：SQL 核心语法入门

终于到了最核心的部分，SQL 语言！SQL 分为四大类，我们一个个来学。

后续的代码演示都在Navicat里操作的，命令行也一样，跟着敲一遍，理解更深刻！

3.1 DDL：数据库和表的结构操作

DDL 是用来定义数据库、表的结构的，比如建库、建表、改表。

数据库操作

-- 1. 创建数据库，不存在才创建，指定编码为utf8mb4（支持emoji）
CREATE DATABASE IF NOT EXISTS test_db DEFAULT CHARSET utf8mb4;

-- 2. 查看所有数据库
SHOW DATABASES;

-- 3. 使用/切换到这个数据库
USE test_db;

-- 4. 删除数据库（谨慎！删了就没了）
DROP DATABASE IF EXISTS test_db;

数据类型：选对类型很重要

建表之前要先搞懂字段的数据类型，这决定了你能存什么数据：

类型	说明	常用场景
INT	整数，4 字节	ID、年龄、数量
TINYINT	小整数，1 字节	状态、性别（1/0）
VARCHAR(n)	可变长度字符串	用户名、手机号、标题
TEXT	长文本	文章内容、描述
DECIMAL(m,n)	精确小数	金额、价格（比如 DECIMAL (10,2) 就是最多 10 位，2 位小数）
DATE	日期	生日、入职日期
DATETIME	日期时间	创建时间、更新时间

创建表

-- 创建用户表，包含各种约束和注释
CREATE TABLE IF NOT EXISTS `user` (
    `id` INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '用户ID，自增主键',
    `username` VARCHAR(50) NOT NULL UNIQUE COMMENT '用户名，唯一',
    `name` VARCHAR(10) NOT NULL COMMENT '姓名',
    `age` TINYINT UNSIGNED DEFAULT 0 COMMENT '年龄',
    `gender` ENUM('男','女','未知') DEFAULT '未知' COMMENT '性别',
    `phone` CHAR(11) NOT NULL UNIQUE COMMENT '手机号',
    `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间，自动填充',
    PRIMARY KEY (`id`) -- 主键，唯一标识一条记录
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户信息表';

表的修改和删除

-- 查看表结构
DESC `user`;

-- 查看建表的SQL语句
SHOW CREATE TABLE `user`;

-- 添加字段：给user表加个email字段
ALTER TABLE `user` ADD `email` VARCHAR(50) AFTER `phone`;

-- 修改字段：把phone的长度改成20
ALTER TABLE `user` MODIFY `phone` VARCHAR(20);

-- 删除字段
ALTER TABLE `user` DROP `email`;

-- 删除表（谨慎！）
DROP TABLE IF EXISTS `user`;

3.2 DML：数据的增删改

DDL 是改结构，DML 是改表里的数据，也就是我们常说的增删改。

user表的结构如图所示：

插入数据（INSERT）

-- 1. 插入单条数据，指定字段
INSERT INTO `user` (`username`, `name`, `age`, `gender`, `phone`) 
VALUES ('zhangsan', '张三', 20, '男', '13800138001');

-- 2. 批量插入多条数据，效率更高
INSERT INTO `user` (`username`, `name`, `age`, `gender`, `phone`) 
VALUES 
('lisi', '李四', 22, '女', '13800138002'),
('wangwu', '王五', 25, '男', '13800138003'),
('zhaoliu', '赵六', 18, '未知', '13800138004');

-- 3. 插入所有字段，按表的顺序来，id自增可以传NULL
INSERT INTO `user` VALUES (NULL, 'sunqi', '孙七', 21, '男', '13800138005', NOW());

SELECT * FROM `user`

更新数据（UPDATE）

⚠️ 新手最容易踩的坑：UPDATE 一定要加 WHERE 条件！不然会把全表的数据都改了！

-- 1. 更新单条数据：把id=1的张三的年龄改成21
UPDATE `user` SET `age` = 21 WHERE `id` = 1;

-- 2. 更新多个字段：把李四的年龄和性别都改了
UPDATE `user` SET `age` = 23, `gender` = '女' WHERE `id` = 2;

-- 3. 批量更新：给所有20岁以下的用户年龄加1（谨慎使用！）
UPDATE `user` SET `age` = `age` + 1 WHERE `age` < 20;

删除数据（DELETE）

⚠️ 同样！DELETE 一定要加 WHERE！不然全表数据都没了！

-- 1. 删除单条数据：删除id=4的赵六
DELETE FROM `user` WHERE `id` = 4;

-- 2. 批量删除：删除所有年龄大于100的无效数据
DELETE FROM `user` WHERE `age` > 100;

-- 3. 清空整个表，重置自增ID（比DELETE快，但是不可回滚）
TRUNCATE TABLE `user`;

3.3 DQL：数据查询（核心中的核心）

DQL 是我们用的最多的，查询数据！90% 的数据库操作都是查询。

基础查询

-- 1. 查询所有字段（不推荐，效率低，要啥查啥）
SELECT * FROM `user`;

-- 2. 查询指定字段
SELECT `name`, `age`, `gender` FROM `user`;

-- 3. 给字段起别名，方便看
SELECT `name` AS 姓名, `age` AS 年龄, `gender` AS 性别 FROM `user`;

-- 4. 去重：查询所有不重复的性别
SELECT DISTINCT `gender` FROM `user`;

条件查询（WHERE）

按条件过滤数据，这是查询最常用的：

运算符	作用	示例
=	等于	WHERE id = 1
!= / <>	不等于	WHERE age != 20
> < >= <=	比较	WHERE age > 18
BETWEEN … AND …	区间	WHERE age BETWEEN 18 AND 25
IN(…)	匹配多个值	WHERE id IN (1,2,3)
IS NULL / IS NOT NULL	空值判断	WHERE phone IS NULL
LIKE	模糊查询	WHERE name LIKE ‘张%’
AND / OR	逻辑与 / 或	WHERE age>18 AND gender=’ 男'

实战示例：

-- 1. 查询年龄大于20的男性
SELECT * FROM `user` WHERE `age` > 20 AND `gender` = '男';

-- 2. 查询年龄在18到25之间的用户
SELECT * FROM `user` WHERE `age` BETWEEN 18 AND 25;

-- 3. 查询姓名是张三或者李四的
SELECT * FROM `user` WHERE `name` IN ('张三', '李四');

-- 4. 查询姓张的用户（%匹配任意字符）
SELECT * FROM `user` WHERE `name` LIKE '张%';

-- 5. 查询姓名是两个字的用户（_匹配单个字符）
SELECT * FROM `user` WHERE `name` LIKE '__';

排序查询（ORDER BY）

把查询结果按某个字段排序：

-- 1. 按年龄升序（从小到大，ASC是默认）
SELECT * FROM `user` ORDER BY `age` ASC;

-- 2. 按年龄降序（从大到小）
SELECT * FROM `user` ORDER BY `age` DESC;

-- 3. 多字段排序：先按年龄排，年龄相同按创建时间排
SELECT * FROM `user` ORDER BY `age` DESC, `create_time` DESC;

分页查询（LIMIT）

数据太多的时候，分页显示，比如每页 10 条：

-- 语法：LIMIT 起始索引, 每页条数
-- 起始索引 = (页码 - 1) * 每页条数

-- 第1页，每页2条
SELECT * FROM `user` LIMIT 0, 2;

-- 第2页，每页2条
SELECT * FROM `user` LIMIT 2, 2;

-- 第3页，每页2条
SELECT * FROM `user` LIMIT 4, 2;

分组查询（GROUP BY）

分组统计，比如按性别统计人数，按班级统计平均分：

-- 聚合函数：用来统计的函数
-- COUNT(*)：统计行数，SUM()：求和，AVG()：平均值，MAX()：最大值，MIN()：最小值

-- 1. 按性别分组，统计每个性别的人数和平均年龄
SELECT 
    `gender`, 
    COUNT(*) AS 人数, 
    AVG(`age`) AS 平均年龄 
FROM `user` 
GROUP BY `gender`;

-- 2. 先过滤，再分组：查询20岁以上的用户，按性别分组
SELECT `gender`, COUNT(*) FROM `user` WHERE `age` > 21 GROUP BY `gender`;

-- 3. 分组后再过滤：筛选人数大于1的分组（HAVING是分组后的过滤，WHERE是分组前的）
SELECT `gender`, COUNT(*) AS cnt FROM `user` GROUP BY `gender` HAVING cnt > 1;

第四章：高级查询技巧

学会了基础查询，我们来学更复杂的，多表查询、子查询这些。

4.1 多表连接查询

实际业务中，数据往往存在多个表里，比如用户表、订单表，我们需要把它们关联起来查询。

首先我们准备两个表：

-- 订单表
CREATE TABLE `order` (
    `id` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    `order_no` VARCHAR(30) NOT NULL UNIQUE,
    `user_id` INT UNSIGNED NOT NULL,
    `amount` DECIMAL(10,2) NOT NULL,
    `create_time` DATETIME DEFAULT NOW(),
    FOREIGN KEY (`user_id`) REFERENCES `user`(`id`)
) ENGINE=InnoDB;

-- 插入测试数据
INSERT INTO `order` (`order_no`, `user_id`, `amount`) VALUES
('ORD001', 1, 99.9),
('ORD002', 1, 199.9),
('ORD003', 2, 299.9);

内连接（INNER JOIN）

只查两个表都匹配的数据，也就是有订单的用户：

-- 查询用户的姓名和他的订单
SELECT 
    u.`name`, o.`order_no`, o.`amount`
FROM `user` u
INNER JOIN `order` o ON u.`id` = o.`user_id`;

左连接（LEFT JOIN）

查左表的所有数据，右表匹配不上的就显示 NULL，比如查所有用户，包括没有订单的：

-- 查询所有用户，以及他们的订单，没有订单的也显示
SELECT 
    u.`name`, o.`order_no`, o.`amount`
FROM `user` u
LEFT JOIN `order` o ON u.`id` = o.`user_id`;

右连接（RIGHT JOIN）

和左连接相反，查右表的所有数据，左表匹配不上的显示 NULL，用的比较少。

4.2 子查询

子查询就是嵌套在 SQL 里的查询，用来处理复杂的条件。

-- 1. 标量子查询：查询年龄大于平均年龄的用户
SELECT `name`, `age` FROM `user` 
WHERE `age` > (SELECT AVG(`age`) FROM `user`);

-- 2. 表子查询：查询有订单的用户
SELECT * FROM `user` 
WHERE `id` IN (SELECT DISTINCT `user_id` FROM `order`);

-- 3. exists子查询：查询有订单的用户，效率比IN高
SELECT * FROM `user` u
WHERE EXISTS (SELECT 1 FROM `order` o WHERE o.`user_id` = u.`id`);

第五章：数据完整性与约束：保证数据绝对正确

很多人刚学的时候，会插入乱七八糟的数据，比如手机号重复、年龄负数、订单的用户不存在，约束就是用来解决这个问题的，它是数据库的 ”守门员”，保证你存进去的数据都是合法的。

5.1 约束的核心作用

约束是定义在表上的强制规则，数据库会自动帮你检查，如果你插入 / 更新的数据违反了规则，直接拒绝执行，从根源上避免脏数据。

5.2 非空约束（NOT NULL）：这个字段必须填

非空约束是最基础的，它规定这个字段不能为空，你插入数据的时候必须给它赋值。

实战示例

-- 创建表的时候，给name加非空约束
CREATE TABLE `user` (
    `id` INT PRIMARY KEY AUTO_INCREMENT,
    `name` VARCHAR(50) NOT NULL, -- 姓名不能为空
    `age` INT
);

-- 测试：插入name为空的数据，会直接报错！
INSERT INTO `user`(`name`, `age`) VALUES(NULL, 20);
-- 报错：Column 'name' cannot be null

💡 提示：必填的字段一定要加 NOT NULL，比如用户名、手机号，不然很容易出现空数据。

5.3 唯一约束（UNIQUE）：这个字段不能重复

唯一约束规定，这个字段的所有值都不能重复，比如用户名、手机号、身份证号，这些都是不能重复的。

实战示例

-- 给username和phone加唯一约束
CREATE TABLE `user` (
    `id` INT PRIMARY KEY AUTO_INCREMENT,
    `username` VARCHAR(50) NOT NULL UNIQUE, -- 用户名唯一
    `phone` CHAR(11) NOT NULL UNIQUE, -- 手机号唯一
    `name` VARCHAR(50) NOT NULL
);

-- 测试：插入重复的用户名，会报错！
INSERT INTO `user`(`username`, `phone`, `name`) VALUES('zhangsan', '13800138001', '张三');
INSERT INTO `user`(`username`, `phone`, `name`) VALUES('zhangsan', '13800138002', '张三2');
-- 报错：Duplicate entry 'zhangsan' for key 'user.username'

💡 注意：唯一约束允许 NULL 值，而且可以有多个 NULL，因为 NULL 不等于任何值，包括它自己。

5.4 主键约束（PRIMARY KEY）：数据的唯一身份证

主键约束是非空 + 唯一的组合，它是一条记录的唯一标识，一个表只能有一个主键。

主键的作用：

唯一标识一条记录，不会有重复
其他表的外键要关联它
默认的主键索引，查询主键的时候速度极快

主键的选择

如果经常纠结主键选什么，这里给你一个最佳实践：

不要用业务字段当主键：比如手机号、身份证号，这些业务字段可能会变
用自增 ID 当主键：INT UNSIGNED NOT NULL AUTO_INCREMENT，简单、高效、不会变
UUID 主键：分布式系统用，不过会导致索引碎片，新手不用考虑

5.5 默认约束（DEFAULT）：没填的话，用默认值

默认约束就是，如果你插入数据的时候没给这个字段赋值，就用默认值，非常方便。

实战示例

CREATE TABLE `user` (
    `id` INT PRIMARY KEY AUTO_INCREMENT,
    `name` VARCHAR(50) NOT NULL,
    `age` INT DEFAULT 0, -- 年龄默认0
    `gender` ENUM('男','女','未知') DEFAULT '未知', -- 性别默认未知
    `status` TINYINT DEFAULT 1, -- 状态默认1：启用
    `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP -- 创建时间默认当前时间
);

-- 插入数据的时候，不用填这些字段，自动用默认值
INSERT INTO `user`(`name`) VALUES('张三');
-- 结果：age=0, gender=未知, status=1, create_time=现在的时间

5.6 检查约束（CHECK）：自定义数据规则

MySQL 8.0 终于支持 CHECK 约束了！你可以自定义数据的规则，比如年龄必须大于 0，余额不能小于 0。

实战示例

CREATE TABLE `account` (
    `id` INT PRIMARY KEY AUTO_INCREMENT,
    `name` VARCHAR(50) NOT NULL,
    `age` INT CHECK (age > 0), -- 年龄必须大于0
    `balance` DECIMAL(10,2) CHECK (balance >= 0) -- 余额不能小于0
);

-- 测试：插入年龄为-1的，会报错！
INSERT INTO `account`(`name`, `age`, `balance`) VALUES('张三', -1, 100);
-- 报错：Check constraint 'account_chk_1' is violated.

5.7 外键约束（FOREIGN KEY）：关联数据的完整性

外键是用来保证两个表的关联数据正确的，比如订单表的user_id，必须在用户表存在，不能出现一个订单的用户是不存在的。

实战示例

-- 先建主表：用户表
CREATE TABLE `user` (
    `id` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    `name` VARCHAR(50) NOT NULL
);

-- 再建从表：订单表，user_id关联用户表的id
CREATE TABLE `order` (
    `id` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    `order_no` VARCHAR(30) NOT NULL,
    `user_id` INT UNSIGNED NOT NULL,
    `amount` DECIMAL(10,2) NOT NULL,
    -- 定义外键：user_id关联users的id
    FOREIGN KEY (user_id) REFERENCES `user`(id)
);

-- 测试：插入一个不存在的user_id的订单，会报错！
INSERT INTO `order`(`order_no`, `user_id`, `amount`) VALUES('ORD001', 999, 100);
-- 报错：Cannot add or update a child row: a foreign key constraint fails

5.8 外键的级联操作：删主表数据的时候，从表怎么办？

默认情况下，如果你要删的用户还有订单，MySQL 是不让你删的，这就是RESTRICT模式，防止你误删。

但是有时候我们希望，删用户的时候，把他的订单也一起删了，这时候就可以用级联操作：

级联模式	作用
RESTRICT	默认，不让你删，必须先删从表数据
CASCADE	级联，删主表数据的时候，把从表关联的数据也一起删了
SET NULL	删主表数据的时候，把从表的外键设为 NULL
NO ACTION	和 RESTRICT 一样，啥也不做

级联删除实战

-- 先建主表：用户表
CREATE TABLE `user` (
    `id` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    `name` VARCHAR(50) NOT NULL
);

-- 建表的时候，指定级联删除
CREATE TABLE `order` (
    `id` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    `order_no` VARCHAR(30) NOT NULL,
    `user_id` INT UNSIGNED NOT NULL,
    `amount` DECIMAL(10,2) NOT NULL,
    -- 删用户的时候，级联删除他的订单
    FOREIGN KEY (user_id) REFERENCES `user`(id) ON DELETE CASCADE
);

INSERT INTO `user` VALUES(NULL, '张三');

INSERT INTO `order` VALUES(NULL, 'a0001', 1, 100);

-- 现在删用户，他的订单会自动被删掉
DELETE FROM `user` WHERE id = 1;

SELECT * FROM `order`
-- 关联的order里的user_id=1的订单，也一起没了

💡 避坑：外键虽然能保证数据完整性，但是会降低性能，高并发的生产环境，很多公司会选择在业务层保证数据一致性，不用外键，咱们学习的时候可以先用着。

第六章：事务管理：保证数据绝对不出错

你有没有遇到过这种情况：转账的时候，A 的钱扣了，B 的钱没加上？这就是没有事务导致的。

事务就是把一组操作打包成一个 ”原子操作”，要么全成功，要么全失败，绝对不会出现只成功一半的情况。

MySQL 中使用 START TRANSACTION 开启事务，COMMIT 提交事务，ROLLBACK 回滚事务。

6.1 事务的 ACID 特性：事务的四大金刚

1. 原子性（Atomicity）：要么全做，要么全不做

原子性是事务最基础的特性，事务里的所有操作，就像一个原子一样，不可分割，不会只做一半。

比如转账的两个操作：A 减 100，B 加 100，这两个必须同时成功，或者同时失败，不能只成功一个。

2. 一致性（Consistency）：数据的状态永远是对的

一致性是说，事务执行前后，数据的完整性约束没有被破坏。

比如转账前，A 有 1000，B 有 1000，总钱数是 2000；转账后，A 有 900，B 有 1100，总钱数还是 2000，这就是一致的。如果 A 减了 100，B 没加，总钱数变成 1900，这就是不一致的，事务会阻止这种情况。

3. 隔离性（Isolation）：多个事务互不干扰

隔离性是说，多个事务同时执行的时候，互相看不到对方的中间状态，不会互相干扰。

比如你和我同时操作同一个账户，我的事务不会影响你的事务，你的也不会影响我的。

4. 持久性（Durability）：提交了就永远不会丢

事务提交之后，数据就永久写到磁盘里了，就算系统断电、崩溃，数据也不会丢。

6.2 事务的基本操作：转账实战

我们用转账的例子，来看看事务怎么用：

-- 先建账户表
CREATE TABLE `account` (
    `id` INT PRIMARY KEY AUTO_INCREMENT,
    `name` VARCHAR(50) NOT NULL,
    `balance` DECIMAL(10,2) NOT NULL DEFAULT 0
);

-- 插入测试数据：A有1000，B有1000
INSERT INTO `account`(`name`, `balance`) VALUES('A', 1000), ('B', 1000);

现在我们要做转账：A 给 B 转 100 块。

-- 1. 开启事务，关闭自动提交
-- 开启事务之后，你做的所有操作都是临时的，没提交之前别人看不到
START TRANSACTION;

-- 2. 执行操作：A减100
UPDATE account SET balance = balance - 100 WHERE id = 1;

-- 3. 执行操作：B加100
UPDATE account SET balance = balance + 100 WHERE id = 2;

-- 4. 检查一下，没问题的话，提交事务，生效
COMMIT;

-- 5. 如果中间出错了，比如网络断了，就回滚，回到事务之前的状态
ROLLBACK;

💡 提示：MySQL 默认是自动提交的，也就是你执行一条 SQL，它就自动提交了，所以你要手动开事务，它才会把你的操作打包。

6.3 并发问题：多个事务同时操作会出什么问题？

如果只有一个事务，那没问题，但是实际生产中，几百个事务同时执行，就会出现并发问题，主要有三个：

1. 脏读：读到了别人未提交的数据

脏读就是，一个事务读到了另一个事务还没提交的数据，然后那个事务回滚了，你读到的就是脏数据。

举个例子：

事务 1：A 给 B 转 100，A 减了 100，还没提交
事务 2：查 A 的余额，读到了 900
事务 1：出错了，回滚，A 的余额变回 1000
结果：事务 2 读到的 900 就是脏数据，根本不存在

2. 不可重复读：同一个事务里，两次读同一个数据，结果不一样

不可重复读就是，在同一个事务里，你两次读同一个数据，结果不一样，因为中间被别的事务改了。

举个例子：

事务 1：查 A 的余额，读到 1000
事务 2：改 A 的余额，改成 900，提交了
事务 1：再查 A 的余额，读到 900
结果：同一个事务里，两次读同一个数据，结果不一样，这就是不可重复读

3. 幻读：同一个事务里，两次查询，行数不一样

幻读就是，在同一个事务里，你两次查同一个范围的数据，第二次多了一行，就像幻觉一样。

举个例子：

事务 1：查年龄 > 20 的用户，查到 2 行
事务 2：插入了一个年龄 25 的用户，提交了
事务 1：再查年龄 > 20 的用户，查到 3 行
结果：同一个事务里，两次查一样的条件，结果行数不一样，这就是幻读

6.4 事务隔离级别：解决并发问题

为了解决这些并发问题，SQL 定义了四个隔离级别，级别越高，并发问题越少，但是性能越差。

隔离级别	脏读	不可重复读	幻读	说明
读未提交（Read Uncommitted）	✅	✅	✅	最低，基本不用，性能最好
读已提交（Read Committed）	❌	✅	✅	Oracle 默认，解决了脏读
可重复读（Repeatable Read）	❌	❌	✅	MySQL 默认，解决了脏读、不可重复读
串行化（Serializable）	❌	❌	❌	最高，所有问题都解决，但是性能最差，完全串行

💡 提示：MySQL 默认的可重复读，通过 MVCC（多版本并发控制），其实也解决了幻读，所以你不用改隔离级别，默认的就够用了。

6.5 事务避坑

不要开长事务：事务不要开太久，不然会锁表，影响其他业务，比如你开了事务，然后去调用接口，半天不提交，这就会出问题
异常一定要回滚：代码里如果出错了，一定要调用 ROLLBACK，不然事务会一直挂着
不要在事务里做远程调用：远程调用很慢，会把事务拖长
不要用事务做批量导入：大的批量操作，拆成小事务，不然锁太久了

第七章：索引：让查询快 1000 倍的秘密

很多人刚学的时候，数据少，查询很快，等数据到了 100 万，查询就慢的要死，这就是因为没加索引！

索引就是把数据按照某个字段进行排序，建立一个快速查找的目录，就像书的目录一样，有了索引，你就不用一页一页翻书了，直接就能找到你要的内容，查询速度能提升几百上千倍！

7.1 索引的原理：B + 树到底是什么？

MySQL 默认的索引是B + 树，这是一种有序的平衡树，所有的数据都存在叶子节点，而且叶子节点是有序的，用链表连起来。

B + 树的特点：

有序：所有数据都是排好序的，所以范围查询、排序都特别快
查询快：查询的时间复杂度是 O (log n)，100 万的数据，只要查 20 次就找到了
叶子节点有序：叶子节点是用链表连起来的，所以遍历全表也很快

7.2 索引的类型：不同的索引用在不同的地方

类型	作用	适用场景
主键索引	主键自带的，聚簇索引，每个表必须有	主键 ID，查询 ID 的时候
二级索引	普通的索引，叶子节点存主键	普通的查询字段，比如 name
唯一索引	唯一字段的索引，值不能重复	手机号、用户名、订单号
复合索引	多个字段的索引，比如 (name, age)	经常一起查询的多个字段
覆盖索引	查询的字段都在索引里，不用回表	只查几个字段的查询
全文索引	文本的模糊搜索，比如文章内容	全文检索，比如搜索文章

7.3 回表：什么是回表，怎么避免？

二级索引的叶子节点存的是数据的主键，所以你用二级索引查到主键之后，还要用主键去主键索引里查完整的数据，这就叫回表，回表会多一次 IO，所以会慢一点。

如果你的查询的字段，都在索引里，那就不用回表了，这就是覆盖索引，速度会快很多。

比如：

-- 我们有复合索引(name, age)
-- 这个查询，只查name和age，都在索引里，不用回表，覆盖索引
SELECT `name`, `age` FROM `user` WHERE `name` = '张三';

-- 这个查询，要查phone，phone不在索引里，所以要回表
SELECT `name`, `age`, `phone` FROM `user` WHERE `name` = '张三';

7.4 最左前缀原则：复合索引的核心规则

复合索引是多个字段的索引，比如(a,b,c)，它的顺序很重要，查询的时候，必须从最左边的字段开始匹配，这就是最左前缀原则。

举个例子，我们有复合索引(name, age, gender)：

查询条件	能不能用到索引？
WHERE `name` = ‘张三’	✅ 能，匹配最左的 name
WHERE `name` = ‘张三’ AND `age` = 20	✅ 能，匹配 name’+age
WHERE `name` = ‘张三’ AND `age` = 20 AND `gender` = ‘男’	✅ 能，匹配全部
WHERE `age` = 20 AND `gender` = ‘男’	❌ 不能，跳过了最左的 name
WHERE `name` = ‘张三’ AND `gender` = ‘男’	✅ 能，name 能用到，gender 用不到

💡 所以建复合索引的时候，要把查询频繁的、区分度高的字段放最左边，把范围查询的字段放右边。

7.5 索引操作：怎么加索引

-- 1. 创建普通索引：给name字段加索引
CREATE INDEX idx_user_name ON `user`(`name`);

-- 2. 创建唯一索引：给phone加唯一索引
CREATE UNIQUE INDEX idx_user_phone ON `user`(`phone`);

-- 3. 创建复合索引：给name、age、gender加复合索引
CREATE INDEX idx_user_name_age_gender ON `user`(`name`, `age`, `gender`);

-- 4. 查看表的所有索引
SHOW INDEX FROM `user`;

-- 5. 删除索引
DROP INDEX idx_user_name ON `user`;

7.6 索引失效：最容易踩的坑，加了索引也没用

很多人加了索引，但是查询还是很慢，因为索引失效了，也就是你写的 SQL，导致索引用不了，变成了全表扫描。

我们一个个来看，这些都是最容易踩的坑：

1. 对索引字段做函数操作

如果你对索引字段做函数操作，MySQL 就没法用索引了，因为索引存的是原始值，不是函数处理后的值。

反例（索引失效）：

1
2

-- 对create_time做了YEAR函数，索引失效
SELECT * FROM user WHERE YEAR(create_time) = 2026;

正例（索引生效）：

1
2

-- 用范围查询，不用函数，索引生效
SELECT * FROM user WHERE create_time >= '2026-01-01' AND create_time < '2027-01-01';

2. 模糊查询，开头用通配符

LIKE '%xxx'，开头的通配符，会导致索引失效，因为索引是有序的，开头不确定的话，没法匹配。

反例（索引失效）：

1
2

-- 开头的%，索引失效
SELECT * FROM user WHERE name LIKE '%张三';

正例（索引生效）：

1
2

-- 结尾的%，索引生效
SELECT * FROM user WHERE name LIKE '张三%';

3. 用 OR 连接没有索引的字段

如果 OR 的两个字段，一个有索引，一个没有，那整个查询都不会用索引。

反例（索引失效）：

1
2

-- name有索引，age没有，OR导致整个索引失效
SELECT * FROM user WHERE name = '张三' OR age = 20;

4. 隐式类型转换

如果字段是字符串，你传了数字，MySQL 会自动做类型转换，导致索引失效。

反例（索引失效）：

1
2

-- phone是字符串，你传了数字13800138001，隐式转换，索引失效
SELECT * FROM user WHERE phone = 13800138001;

正例（索引生效）：

1
2

-- 传字符串，索引生效
SELECT * FROM user WHERE phone = '13800138001';

5. 用 NOT、’!=、<>、IS NOT NULL

这些操作，会导致索引失效，因为 MySQL 觉得全表扫描更快。

7.7 怎么看索引有没有生效：Explain 执行计划

很多人加了索引，不知道有没有生效，这时候就可以用EXPLAIN，它能告诉你 SQL 的执行计划，索引有没有用到。

用法很简单，在 SQL 前面加 EXPLAIN：

`1`	`EXPLAIN SELECT * FROM user WHERE name = '张三';`

然后看结果里的type字段，这个是查询的类型，越好的类型，速度越快：

system > const > eq_ref > ref > range > index > ALL

如果type是ALL，那就是全表扫描，索引没生效！如果是ref、range这些，就是索引生效了。

还有key字段，显示的是用到的索引，如果这个是空的，就是没用到索引。

7.8 索引使用的最佳实践

不要给小表加索引：数据就几百条，全表扫描比索引还快
不要给区分度低的字段加索引：比如性别，只有男 / 女，加了索引也没用
不要给频繁修改的字段加索引：修改数据的时候，要同步修改索引，会变慢
索引不是越多越好：每个索引都会占用空间，而且会拖慢增删改的速度，一个表的索引不要超过 5 个
慢查询优化：开启慢查询日志，找到慢 SQL，然后给它们加索引

第八章：可视化工具：不用敲命令也能操作

很多人觉得命令行难，没关系，我们有可视化工具，点点鼠标就能操作！

8.1 Navicat：最流行的图形化工具

Navicat 是最常用的 MySQL 管理工具，界面友好，功能强大，新手首选。

连接数据库

打开 Navicat，点击左上角的「连接」→「MySQL」
连接名随便填，比如「本地 MySQL」
主机填localhost，端口 3306，用户名 root，密码填你安装时的密码
点击「测试连接」，成功就可以了

可视化建表

右键你的数据库→「新建表」
直接在表格里填字段名、类型、约束，点点鼠标就搞定
填完点保存，表就建好了，不用写 DDL！

数据操作

双击打开表，直接就能编辑数据，像 Excel 一样
导入导出数据，点点鼠标就能把 Excel 的数据导进去

8.2 MySQL Workbench：官方免费工具

Workbench 是 MySQL 官方出的免费工具，不用花钱，功能也很全。

操作和 Navicat 差不多，新手也能很快上手，而且是官方的，兼容性最好。

第九章：数据备份与恢复：防止数据丢了

新手最容易忽略的就是备份！等你误删了库，才发现没备份，哭都来不及！

我们用 MySQL 自带的mysqldump工具，这是最常用的逻辑备份工具，简单好用。

⚠️ 注意：mysqldump 是终端命令，要在 CMD/Linux 终端里执行，不是在 MySQL 客户端里！

9.1 备份操作

1. 单库备份（最常用）

1
2

# 备份test_db库，生成sql文件
mysqldump -u backup_user -p --default-character-set=utf8mb4 --single-transaction test_db > D:mysql_backuptest_db_backup.sql

2. 只备份表结构，不备份数据

1
2

# 只备份结构，用来迁移表结构
mysqldump -u root -p --no-data test_db > D:mysql_backuptest_db_struct.sql

3. 全实例备份，备份所有库

1
2

# 备份整个MySQL的所有库，用来迁移服务器
mysqldump -u root -p --all-databases > D:mysql_backupfull_backup.sql

9.2 恢复操作

1. 单库恢复

# 先创建空库
mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS test_db DEFAULT CHARSET utf8mb4"
# 恢复备份
mysql -u root -p test_db < D:mysql_backuptest_db_backup.sql

2. 客户端里恢复

1
2
3

-- 也可以在MySQL客户端里用source命令
USE test_db;
source D:/mysql_backup/test_db_backup.sql; -- 注意路径用正斜杠

9.3 备份避坑

定期备份：最好每天自动备份，不要手动
备份后要验证：备份完了打开 sql 文件看看，有没有内容，别备份了个空文件
定期恢复演练：别等出事了才发现备份是坏的
备份路径不要有中文：不然会报错

第十章：完整实战：电商订单系统

学了这么多，我们来做一个完整的实战案例，电商订单系统，把所有知识点串起来！

10.1 建库建表

-- 1. 创建数据库
CREATE DATABASE IF NOT EXISTS shop CHARACTER SET utf8mb4;
USE shop;

-- 2. 用户表
CREATE TABLE users (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '用户ID',
    username VARCHAR(50) NOT NULL UNIQUE COMMENT '用户名',
    phone VARCHAR(20) NOT NULL COMMENT '手机号',
    status TINYINT DEFAULT 1 COMMENT '状态:1启用0禁用',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP COMMENT '注册时间',
    PRIMARY KEY (id),
    INDEX idx_phone (phone)
) ENGINE=InnoDB COMMENT='用户表';

-- 3. 商品表
CREATE TABLE products (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '商品ID',
    name VARCHAR(200) NOT NULL COMMENT '商品名称',
    price DECIMAL(10,2) UNSIGNED NOT NULL COMMENT '价格',
    stock INT UNSIGNED DEFAULT 0 COMMENT '库存',
    status TINYINT DEFAULT 1 COMMENT '上架状态',
    PRIMARY KEY (id),
    INDEX idx_name (name)
) ENGINE=InnoDB COMMENT='商品表';

-- 4. 订单表
CREATE TABLE orders (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '订单ID',
    user_id INT UNSIGNED NOT NULL COMMENT '用户ID',
    total_amount DECIMAL(10,2) UNSIGNED NOT NULL COMMENT '订单金额',
    status ENUM('pending','paid','shipped','completed','cancelled') DEFAULT 'pending' COMMENT '订单状态',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    paid_at TIMESTAMP NULL COMMENT '支付时间',
    PRIMARY KEY (id),
    INDEX idx_user (user_id),
    INDEX idx_status (status),
    FOREIGN KEY (user_id) REFERENCES users(id)
) ENGINE=InnoDB COMMENT='订单表';

10.2 插入测试数据

-- 插入用户
INSERT INTO users(username, phone) VALUES
('张三', '13800138001'),
('李四', '13800138002'),
('王五', '13800138003');

-- 插入商品
INSERT INTO products(name, price, stock) VALUES
('笔记本电脑', 5999.00, 10),
('无线鼠标', 89.90, 100),
('机械键盘', 299.00, 50);

-- 插入订单
INSERT INTO orders(user_id, total_amount, status) VALUES
(1, 5999.00, 'paid'),
(1, 388.90, 'completed'),
(2, 89.90, 'pending');

10.3 复杂查询实战

-- 1. 查询每个用户的订单数和消费总额
SELECT 
    u.username,
    COUNT(o.id) AS 订单数,
    IFNULL(SUM(o.total_amount), 0) AS 消费总额
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
GROUP BY u.id
ORDER BY 消费总额 DESC;

-- 2. 查询已支付的订单，关联用户和商品
-- （这里我们可以扩展订单详情表，不过新手先理解这个）

第十一章：必避的 10 个坑

最后，总结一下最容易踩的坑，帮你少走弯路：

UPDATE/DELETE 忘记加 WHERE：这是最常见的，一不小心全表数据没了，执行前先 SELECT 看看对不对
字符集乱码：建库建表一定要用 utf8mb4，不要用 latin1，备份恢复也要指定字符集
密码忘记：root 密码一定要记牢，重置密码很麻烦
外键导致删不了表：有外键关联的话，要先删从表，或者关掉外键校验
大表 SELECT：大表查所有字段，会把数据库卡死，要啥查啥，加 LIMIT
长事务：事务不要开太久，会锁表，影响业务
索引建太多：索引不是越多越好，会拖慢增删改的速度
备份不验证：备份完了一定要看看备份文件有没有内容，别备份了个空的
root 用户到处用：生产环境不要用 root，要创建专用用户，最小权限原则
路径有中文：MySQL 对中文路径兼容性差，安装、备份的路径都用英文

附录：SQL 速查表

操作	SQL 语句
创建数据库	`CREATE DATABASE db DEFAULT CHARSET utf8mb4;`
切换数据库	`USE db;`
建表	`CREATE TABLE t(id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50));`
插入	`INSERT INTO t(name) VALUES('test');`
更新	`UPDATE t SET name='test2' WHERE id=1;`
删除	`DELETE FROM t WHERE id=1;`
查询	`SELECT * FROM t WHERE id=1;`
分页	`SELECT * FROM t LIMIT 0,10;`
排序	`SELECT * FROM t ORDER BY id DESC;`
分组	`SELECT name,COUNT(*) FROM t GROUP BY name;`

写在最后

MySQL 是一个入门简单但内涵丰富的工具，这份教程带你从零基础入门，到掌握生产级的技能。学习数据库最重要的就是多练，把这些 SQL 都自己敲一遍，做几个小项目，很快就能上手了。

希望这份教程能帮你彻底搞定 MySQL，开启你的数据之旅！

MySQL面试八股文（持续更新）

Wed, 25 Mar 2026 22:12:10 +0800

数据库 - MySQL 面试八股文

本文档整理了后端开发面试中关于 MySQL 数据库最常被问到的高频面试题和深度解析，重点聚焦于 InnoDB 存储引擎。

一、 MySQL 基础架构与执行流程

1. MySQL 的逻辑架构是怎样的？

MySQL 的逻辑架构大致分为两层：

Server 层：涵盖了 MySQL 的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等）。所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。
- 连接器：负责跟客户端建立连接、获取权限、维持和管理连接。
- 查询缓存：MySQL 8.0 已废弃。之前用于缓存执行过的 SQL 语句及其结果。
- 分析器：对 SQL 进行词法分析和语法分析，检查 SQL 是否合法。
- 优化器：决定使用哪个索引，或者在一个语句有多表关联时决定各个表的连接顺序。
- 执行器：调用存储引擎的 API 接口来执行 SQL，并返回结果。
存储引擎层：负责数据的存储和提取。其架构模式是插件式的，支持 InnoDB、MyISAM、Memory 等多个存储引擎。MySQL 5.5.5 版本开始，InnoDB 成为了默认存储引擎。

2. 一条 SQL 语句在 MySQL 中是如何执行的？

客户端通过连接器与 MySQL Server 建立连接。
（MySQL 8.0 之前）查询缓存，命中则直接返回，否则继续。
分析器进行词法和语法分析，判断 SQL 是否正确。
优化器生成执行计划，选择最优的索引。
执行器检查用户权限，调用存储引擎接口进行数据的读写，最后将结果返回给客户端。

二、存储引擎

3. InnoDB 和 MyISAM 的主要区别是什么？

特性	InnoDB	MyISAM
事务 (Transaction)	支持	不支持
锁级别	行级锁（默认）、表级锁	仅支持表级锁
外键 (Foreign Key)	支持	不支持
崩溃恢复	支持（通过 Redo Log 实现安全恢复）	不支持
索引结构	聚簇索引（数据和主键索引绑在一起）	非聚簇索引（索引和数据分离）
适用场景	绝大多数场景，特别是需要事务和高并发读写	以读为主，对事务完整性要求不高的老旧系统

三、索引机制（绝对重点）

4. 什么是索引？MySQL 为什么默认使用 B+ 树作为索引结构？

索引是帮助 MySQL 高效获取数据的数据结构（就像书的目录）。

为什么使用 B+ 树？（对比其他结构）

对比 Hash 索引：Hash 虽然单条查询最快（O(1)），但不支持范围查询（>、<、between）、不支持模糊匹配和最左前缀原则。
对比二叉搜索树 / 红黑树：树的层级太深，会导致磁盘 I/O 次数过多，查询效率低下。
对比 B 树：B 树的所有节点都存储数据，而 B+ 树只有叶子节点存储数据，非叶子节点只存键值。因此 B+ 树一个节点可以容纳更多的键，树的高度更低（通常 3-4 层），磁盘 I/O 更少。同时，B+ 树的叶子节点用双向链表连接，非常适合范围查询。

5. 什么是聚簇索引和非聚簇索引（二级索引）？什么是回表？

聚簇索引：将数据存储与索引放到了一块，找到索引也就找到了数据。在 InnoDB 中，通常主键就是聚簇索引（如果没有主键，会选择第一个非空的唯一索引；如果还没有，会隐式生成一个 row_id 作为聚簇索引）。
非聚簇索引（二级索引）：叶子节点不存储完整的行数据，而是存储主键的值。
回表：如果通过二级索引查询数据，由于二级索引叶子节点只存了主键值，要想获取除主键外的其他字段数据，就需要拿着这个主键值回到聚簇索引中再查一次，这个过程叫做“回表”。

6. 什么是覆盖索引、最左前缀原则、索引下推？

覆盖索引：在一个查询中，如果一个索引包含了（或覆盖了）所有需要查询的字段的值，就不需要回表查询了，这叫覆盖索引。（例如 SELECT id, name FROM table WHERE name = ‘张三’，如果给 name 建了索引，因为二级索引本身包含主键 id，所以直接在二级索引就能拿到结果，无需回表）。
最左前缀原则：在联合索引中（如 (a, b, c)），查询条件必须从索引的最左前列开始并且不跳过中间的列。即可以匹配 (a)、(a, b)、(a, b, c)，但不能直接匹配 (b) 或 (b, c)。
索引下推 (ICP)：MySQL 5.6 引入的优化。在联合索引匹配时，如果遇到范围查询（如 >），其后的字段无法走索引。但在索引下推优化下，存储引擎会在遍历索引时，直接把判断条件“下推”给存储引擎层进行过滤，减少了回表的次数。

7. 导致索引失效的常见场景有哪些？

使用了 SELECT *（极易导致不走覆盖索引而全表扫描）。
对索引列进行了计算、函数操作或类型转换（如 WHERE DATE(create_time) = ‘2023-01-01’ 或隐式类型转换如字符串传了数字）。
使用了前导模糊查询（如 LIKE ‘%abc’，但 LIKE ‘abc%’ 是走索引的）。
违反最左前缀原则（联合索引没有使用第一列）。
使用了 OR，且 OR 前后不是都有索引。
MySQL 优化器认为全表扫描比走索引成本更低时（如表数据极少，或查询的数据占全表很大比例）。

四、事务与并发控制

8. 事务的 ACID 特性是什么？底层是如何保证的？

原子性 (Atomicity)：事务是最小执行单位，不可分割，要么全成功，要么全失败。由 Undo Log（回滚日志）保证，失败时执行回滚。
隔离性 (Isolation)：并发访问时，一个事务的执行不影响其他事务。由 MVCC（多版本并发控制）和锁保证。
持久性 (Durability)：事务一旦提交，对数据的改变是永久的。由 Redo Log（重做日志）保证（WAL 机制，先写日志后写磁盘）。
一致性 (Consistency)：事务执行前后，数据保持一致状态（如转账前后总金额不变）。一致性是目的，由原子性、隔离性、持久性共同保证。

9. 并发事务会带来哪些问题？（脏读、不可重复读、幻读）

脏读：事务 A 读到了事务 B 已修改但未提交的数据。如果 B 回滚，A 读到的就是脏数据。
不可重复读：事务 A 两次读取同一条数据，期间事务 B 修改并提交了该数据，导致 A 两次读到的数据不一致。（侧重于数据被修改或删除）。
幻读：事务 A 执行两次相同的范围查询，期间事务 B 插入了新的满足条件的数据并提交，导致 A 第二次查出了更多的“幻影”行。（侧重于数据被新增）。

10. MySQL 的事务隔离级别有哪些？默认是哪个？

读未提交 (Read Uncommitted)：最低级别，会发生脏读、不可重复读、幻读。
读已提交 (Read Committed, RC)：解决了脏读，但会发生不可重复读和幻读。（Oracle 默认）。
可重复读 (Repeatable Read, RR)：解决了脏读、不可重复读。在 InnoDB 中，通过 MVCC 和 Next-Key Lock 很大程度上解决了幻读问题。（MySQL 默认隔离级别）。
串行化 (Serializable)：最高级别，强制事务串行执行，解决所有问题，但性能极差。

五、 MVCC (多版本并发控制)

11. 什么是 MVCC？它是如何工作的？

MVCC (Multi-Version Concurrency Control) 是 InnoDB 实现隔离级别的一种核心机制，主要用于处理读写冲突，做到读写不阻塞（无锁读）。

MVCC 主要由三个组件实现：

隐藏字段：InnoDB 会在每行数据后面增加两个隐藏列：
- trx_id：最近一次修改该行数据的事务 ID。
- roll_pointer：回滚指针，指向 Undo Log 中该行的历史版本。
Undo Log（版本链）：记录数据修改前的状态。每次更新数据时，旧数据会被存入 Undo Log，并通过 roll_pointer 串联成一个单链表（版本链）。
Read View（读视图）：事务进行快照读（普通的 SELECT）时产生的一个数据结构，用来判断当前事务能看到版本链中的哪个版本。

12. Read View 的核心机制是什么？RC 和 RR 下的区别？

Read View 包含四个核心字段：

creator_trx_id：创建该 Read View 的事务 ID。
m_ids：创建 Read View 时，当前系统中**活跃的（未提交的）**事务 ID 列表。
min_trx_id：m_ids 中的最小值。
max_trx_id：系统将分配给下一个事务的 ID。

可见性判断规则（基于被访问行的 trx_id）：

如果 trx_id < min_trx_id：说明修改该行的事务在生成 Read View 前已提交，可见。
如果 trx_id >= max_trx_id：说明修改该行的事务在生成 Read View 之后才开始，不可见。
如果 min_trx_id <= trx_id < max_trx_id：
- 若 trx_id 在 m_ids 列表中：说明修改该行的事务还在活跃（未提交），不可见。
- 若 trx_id 不在 m_ids 列表中：说明修改该行的事务已经提交，可见。
如果不可见，就顺着版本链 (roll_pointer) 往下找，直到找到可见的版本。

RC 和 RR 的核心区别：

RC（读已提交）：每次执行 SELECT 时都会生成一个新的 Read View。因此能读到其他事务新提交的数据，产生不可重复读。
RR（可重复读）：只在事务第一次执行 SELECT 时生成一个 Read View，之后的整个事务期间都复用这个 Read View。因此同一事务内多次读取结果相同，实现了可重复读。

六、 MySQL 锁机制

13. InnoDB 的行级锁有哪些？

InnoDB 的行锁是通过给索引项加锁来实现的，而不是给表的行记录加锁。

Record Lock（记录锁）：仅仅锁住某一条记录。
Gap Lock（间隙锁）：锁定一个范围，但不包括记录本身。目的是为了防止其他事务在这个范围内插入数据，从而解决幻读。
Next-Key Lock（临键锁）：Record Lock + Gap Lock 的结合，锁定一个范围，并且锁定记录本身（左开右闭区间）。InnoDB RR 隔离级别默认使用 Next-Key Lock。

14. 什么是死锁？如何解决？

死锁：两个或多个事务在执行过程中，因争夺资源而造成的一种互相等待的现象。
解决/预防：
1. InnoDB 内部有死锁检测机制（innodb_deadlock_detect=on），检测到死锁会自动回滚代价较小的事务。
2. 业务层面预防：以固定的顺序访问表和行数据。
3. 大事务拆小，缩短事务持有锁的时间。
4. 为表添加合理的索引，避免全表扫描退化为表锁，减少锁冲突的概率。

七、核心日志 (Binlog / Redo Log / Undo Log)

15. 说说 Binlog、Redo Log、Undo Log 的区别？

Undo Log (回滚日志)：
- 作用：实现事务的原子性和 MVCC。
- 内容：逻辑日志，记录数据的历史版本（比如你执行了 INSERT，它就记录一条对应的 DELETE）。
Redo Log (重做日志)：
- 作用：实现事务的持久性（Crash-safe）。MySQL 宕机重启后，靠它恢复未落盘的数据。
- 内容：物理日志，记录了“在某个数据页上做了什么修改”。
- 特点：InnoDB 引擎特有，大小固定，循环写入（WAL 机制，Write-Ahead Logging）。
Binlog (归档日志)：
- 作用：用于数据备份和主从复制。
- 内容：逻辑日志，记录的是 SQL 语句（或行修改的数据）。
- 特点：Server 层实现，所有引擎共有，追加写入，不会覆盖旧日志。

16. 什么是两阶段提交 (Two-Phase Commit)？为什么需要它？

在执行更新语句时，Redo Log 和 Binlog 必须保持数据一致性。MySQL 采用两阶段提交来保证：

Prepare 阶段：将更新写入 Redo Log，将 Redo Log 标记为 prepare 状态。
Commit 阶段：将更新写入 Binlog，然后将 Redo Log 标记为 commit 状态。

为什么需要两阶段提交？

如果在写完 Redo Log 还没写 Binlog 时发生宕机（或者反过来），会导致主库（依靠 Redo Log 恢复）和从库（依靠 Binlog 同步）的数据不一致。两阶段提交配合内部的事务 XID，确保了崩溃恢复时，Binlog 和 Redo Log 的状态绝对一致。