简介：这份MySQL学习资料面向数据库初学者与Web开发入门者，系统梳理从SQL基础到MySQL特有功能的知识脉络，帮助读者解决语法不熟、查询写不出、性能优化无思路等常见问题。压缩包共41个文件，约21.88MB，以20个PDF教程笔记和19个SQL示例脚本为主，另附2个Markdown说明文档；PDF按章节讲解数据库概述、环境搭建、SELECT语句、运算符、多表查询、子查询、聚合与单行函数、视图、存储过程与函数、触发器、约束及MySQL8新特性，SQL脚本则与各章知识点一一对应，便于边学边练。已有224人学习。资料还覆盖事务处理、索引与EXPLAIN分析、用户权限管理、备份恢复及Web开发集成等实战内容，配合示例脚本与练习题，可帮助读者逐步建立完整的数据库设计与优化能力，适合作为课程配套或自学参考。
1. MySQL 学习地图：从 SQL 语句到索引优化的整体脉络
很多人学 MySQL 的路径是反的：先背了一堆SELECT语法，遇到慢查询却完全不知道从哪下手。真正系统的学习顺序应该是「先看清整张地图，再逐个模块啃」。MySQL 的知识体系大致可以分成四层：最底层是存储引擎与数据组织方式，往上是 SQL 语法与查询执行，再往上是索引与执行计划，最上层才是事务、锁、日志与性能调优。这四层不是并列关系，而是层层依赖——不理解 B+ 树，索引优化就是玄学；不理解事务隔离级别，锁等待就只能靠猜。这份 mysql 学习资料适合两类人：一是正在系统学 SQL 与数据库原理、需要一份完整课程资源打底的人；二是已经能写业务 SQL、但一遇到慢查询和死锁就翻车、想回头补体系的人。下面按模块把重点、难点和易错点梳理清楚，最后落到一份可执行的复习清单。
2. SQL 基础与查询执行：语法只是入口，执行顺序才是重点
2.1 从建表到多表查询的语法骨架
SQL 基础部分看起来简单，但真正拉开差距的是「写得对」和「写得准」。建表阶段要关注三类约束：主键约束决定行的唯一标识，外键约束维护表间引用完整性，唯一约束防止业务字段重复。字段类型的选择直接影响后续索引效率——能用INT就不用BIGINT，能用定长CHAR的场景不要滥用VARCHAR，时间字段优先DATETIME而非字符串。多表查询是基础模块里最容易出错的地方，核心是分清INNER JOIN、LEFT JOIN、RIGHT JOIN的语义差异，以及ON条件和WHERE条件的执行时机不同。
-- 统计每个部门下在职员工数，包含没有员工的部门 SELECT d.dept_name, COUNT(e.emp_id) AS emp_count FROM department d LEFT JOIN employee e ON e.dept_id = d.dept_id AND e.status = 'active' -- 过滤条件放在 ON 里，保留左表全部部门 GROUP BY d.dept_name;上面这段 SQL 的关键点在于：e.status = 'active'如果写到WHERE里，就会把没有员工的部门过滤掉，LEFT JOIN退化成INNER JOIN。这是基础模块里最高频的踩坑点之一。参数说明：LEFT JOIN保证左表department全量保留，ON后的附加条件只影响右表匹配，不影响左表行数。理解这一点，多表查询的很多「结果不对」问题就迎刃而解。
2.2 查询逻辑执行顺序：你写的顺序不等于执行顺序
SQL 的书写顺序和执行顺序是两回事。书写顺序是SELECT ... FROM ... WHERE ... GROUP BY ... HAVING ... ORDER BY ... LIMIT，而逻辑执行顺序大致是FROM → ON → JOIN → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY → LIMIT。这个顺序解释了三个常见困惑：为什么WHERE里不能用SELECT中定义的别名（因为WHERE先于SELECT执行），为什么HAVING可以过滤聚合结果而WHERE不行，为什么ORDER BY能用到SELECT的别名。把这条执行链记牢，很多「语法没错但结果诡异」的问题就能自己定位。
提示：面试和实际排查中，「
WHERE和HAVING的区别」几乎必问，答案的本质就是执行顺序不同，而不是「一个用于分组前一个用于分组后」这种模糊说法。
2.3 聚合、子查询与窗口函数的取舍
聚合函数COUNT、SUM、AVG、MAX、MIN配合GROUP BY是统计类需求的主力。这里有个经典易错点：COUNT(*)、COUNT(1)、COUNT(字段)三者结果可能不同，因为COUNT(字段)会跳过NULL值。子查询分标量子查询、列子查询、行子查询和相关子查询，性能上相关子查询往往比JOIN改写慢，能改写成JOIN的尽量改写。窗口函数（ROW_NUMBER、RANK、SUM OVER）适合做分组排名和累计统计，它不减少行数，和GROUP BY的语义完全不同。学习资料里这部分通常配有对比练习，建议亲手把同一个需求用「子查询版」和「窗口函数版」各写一遍，差异会非常直观。
3. 索引与执行计划：B+ 树、最左前缀与 EXPLAIN 三件套
3.1 索引底层结构与聚簇索引
InnoDB 的索引底层是 B+ 树，理解它的三个特征就够了：所有数据都在叶子节点、叶子节点之间用链表相连、非叶子节点只存键值不存数据。这决定了范围查询高效、排序友好、磁盘 IO 次数稳定。聚簇索引（主键索引）的叶子节点直接存放整行数据，二级索引的叶子节点存放的是主键值，所以通过二级索引查非索引列时需要「回表」——先查二级索引拿到主键，再回聚簇索引取整行。回表次数多了，性能就下来了，这也是「覆盖索引」存在的意义：如果查询需要的列全在索引里，就不用回表。
-- 建立联合索引 CREATE INDEX idx_user_status_time ON orders (user_id, status, created_at); -- 覆盖索引示例：查询列全部命中索引，无需回表 SELECT user_id, status, created_at FROM orders WHERE user_id = 1001 AND status = 'paid';参数说明：联合索引(user_id, status, created_at)的列顺序不是随便排的，要按「等值条件在前、范围条件在后」的原则设计。上面这条查询三个列都在索引中，属于覆盖索引，EXPLAIN的Extra列会显示Using index。
3.2 最左前缀原则与索引失效场景
联合索引遵循最左前缀原则：查询条件必须从索引的最左列开始连续匹配，才能用上索引。WHERE user_id = 1能用，WHERE status = 'paid'用不上，WHERE user_id = 1 AND created_at > '2024-01-01'只能用到user_id这一列，因为中间跳过了status。索引失效的典型场景需要单独记：在索引列上做函数运算或表达式计算、隐式类型转换（字符串列传数字）、LIKE以通配符开头、OR连接的条件中有列没建索引、使用!=或NOT IN导致优化器放弃索引。这些不是背下来就完事，而是要在EXPLAIN里亲眼看到type从ref掉到ALL，印象才深。
3.3 EXPLAIN 关键字段解读
EXPLAIN是排查慢查询的黑匣子，重点看五列：type表示访问类型，性能从好到差大致是system > const > eq_ref > ref > range > index > ALL；key是实际使用的索引；rows是预估扫描行数；filtered是过滤后剩余行数百分比；Extra里出现Using filesort或Using temporary就要警惕。把EXPLAIN和EXPLAIN ANALYZE结合用，前者看计划，后者看真实执行耗时，定位问题更准。
| 字段 | 含义 | 重点关注值 |
|---|---|---|
| type | 访问类型 | ALL 表示全表扫描，需优化 |
| key | 实际使用的索引 | 为 NULL 说明没走索引 |
| rows | 预估扫描行数 | 越大越要警惕 |
| Extra | 附加信息 | Using filesort / Using temporary 需处理 |
4. 事务、锁与日志：隔离级别背后的并发控制
4.1 事务 ACID 与四种隔离级别
事务的四个特性里，最容易混淆的是隔离性与一致性的关系。隔离性靠锁和 MVCC 实现，一致性是最终目标。四种隔离级别从低到高是读未提交、读已提交、可重复读、串行化，InnoDB 默认是可重复读。不同级别对应不同的并发问题：读未提交会出现脏读，读已提交会出现不可重复读，可重复读在标准定义下会出现幻读，但 InnoDB 通过间隙锁在很大程度上解决了幻读。这里有个高频误区：很多人以为「可重复读就完全不会幻读」，实际上只有在当前读（加锁读）场景下间隙锁才生效，快照读靠的是 MVCC。
4.2 MVCC 与 undo log 版本链
MVCC 是理解 InnoDB 并发控制的核心。每行数据有两个隐藏字段：事务 ID 和回滚指针，回滚指针指向 undo log 中的历史版本，形成版本链。读操作根据 Read View 判断哪个版本可见，从而实现「不加锁也能读到一致快照」。Read View 里有四个关键信息：当前活跃事务列表、最小活跃事务 ID、下一个待分配事务 ID、创建者事务 ID。读已提交每次查询都生成新 Read View，可重复读只在第一次查询时生成，这就是两者行为差异的根源。把这条链理顺，很多「为什么同一个事务里两次查询结果不一样」的问题就有了答案。
4.3 行锁、间隙锁与死锁排查
InnoDB 的锁按粒度分行锁和表锁，行锁又分记录锁、间隙锁、临键锁。临键锁是记录锁加间隙锁的组合，用在可重复读级别下防止幻读。死锁的产生通常是两个事务以相反顺序获取锁，排查手段是看SHOW ENGINE INNODB STATUS输出里的LATEST DETECTED DEADLOCK段落，它会打印出两个事务持有的锁和等待的锁。血泪经验是：死锁不可怕，可怕的是不知道去哪看日志。养成「先看死锁日志再改代码」的习惯，比盲目加索引有效得多。
5. 易错点与易漏点：那些复习时最容易被跳过的角落
5.1 字符集与排序规则被忽略
易漏点：建库建表时不指定字符集，依赖默认值。为什么漏：本地环境默认值往往和线上不一致，开发阶段看不出问题。怎么补：建库时显式写CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci，并检查连接层的字符集配置，避免中文乱码和索引比较异常。
5.2 NULL 值的语义陷阱
易漏点：用= NULL判断空值，或用COUNT(字段)统计时没意识到 NULL 被跳过。为什么漏：NULL表示未知，任何与它的等值比较结果都是未知而非真。怎么补：统一用IS NULL/IS NOT NULL，统计非空数量时明确用COUNT(字段)并理解其语义，建表时尽量给字段设默认值减少 NULL。
5.3 隐式类型转换导致索引失效
易漏点：字符串类型的列用数字去查，比如WHERE phone = 13800000000。为什么漏：语法不报错，结果也对，但索引悄悄失效了。怎么补：查询条件的数据类型与列定义严格一致，用EXPLAIN验证type是否掉级，养成「改完 SQL 必看执行计划」的习惯。
5.4 大事务与长事务的隐性代价
易漏点：一个事务里塞大量写操作，或事务开启后长时间不提交。为什么漏：功能上没问题，但会撑大 undo log、阻塞其他事务、拖慢主从同步。怎么补：控制事务粒度，把非数据库操作移出事务边界，监控information_schema.innodb_trx里的长事务并设置告警。
5.5 分页深翻页的性能断崖
易漏点：LIMIT 1000000, 20这种深分页写法。为什么漏：小数据量测试时很快，数据量上来后扫描行数暴增。怎么补：改用「延迟关联」或基于游标的分页，先用索引定位主键再回表取数据，避免大偏移量扫描。
6. 复习清单：按模块自查与查漏补缺的落地方法
复习最怕的是「感觉都会，一考就废」。我的做法是把上面几个模块拆成一张自查表，每项按「能讲清原理 / 能写出示例 / 能排查问题」三档打分，低于第二档的就回去补。具体清单如下：
| 模块 | 自查项 | 达标标准 |
|---|---|---|
| SQL 基础 | 多表 JOIN 与 ON/WHERE 差异 | 能举反例说明结果差异 |
| 查询执行 | 逻辑执行顺序 | 能解释别名为何不能在 WHERE 用 |
| 索引 | 最左前缀与失效场景 | 能写出 5 种失效案例 |
| 执行计划 | EXPLAIN 五字段 | 能根据输出判断优化方向 |
| 事务 | 四种隔离级别与幻读 | 能说清 MVCC 与间隙锁分工 |
| 锁 | 死锁日志定位 | 能读懂 LATEST DETECTED DEADLOCK |
| 易错点 | NULL、字符集、隐式转换 | 每项能说出触发条件与修复方式 |
查漏补缺的具体技巧是「反向出题」：拿一份自己写过的业务 SQL，故意改坏一个条件——把ON条件挪到WHERE、给索引列套个函数、把字符串换成数字——然后看结果和执行计划怎么变。每改一次，就在清单上对应项打个勾。这个方法比刷题有效，因为错误是你自己制造的，记忆锚点更深。
从那以后我每次复习数据库，都强制走一遍「先画知识地图、再按模块自查、最后反向出题验证」的流程，不再从第一页语法开始翻。希望这份梳理能帮到你，也建议把这份 mysql 学习资料当作地图底稿，边学边在上面标注自己的踩坑记录，复习时翻自己的批注比翻任何教程都快。
本文还有配套的精品资源，点击获取
