简介：一套面向MySQL初学者的系统学习资料包，聚焦SQL基础与MySQL特有功能，兼顾课程教学与自学场景；压缩包内共41个文件，包含20个PDF讲义、19个SQL示例脚本和2个Markdown说明，整体大小约21.88MB。PDF章节覆盖数据库概述、基本的SELECT语句、运算符、排序分页、多表查询、子查询、单行与聚合函数、增删改、创建与管理表、数据类型、约束、视图、存储过程、触发器、事务管理、索引及MySQL8新特性，由浅入深，适合零基础起步。配套SQL脚本对应各章示例，可直接运行验证结果，帮助读者把理论知识转化为实操能力；README文档有助于快速定位学习路径。进阶内容还涉及查询优化、表设计范式、数据库备份恢复以及Web开发集成，与真实项目场景衔接。已有221人学习使用，是一份能系统支撑MySQL入门到实践的课程资源包。
1. 关于 MySQL 学习资料：先看这一份，少走三个月的弯路
如果你已经在网上翻过 MySQL 和 SQL 相关的课程资源，大概率会遇到两种极端：一种是上来就讲 B+ 树和 redo log，劝退新手；另一种是教你背几条增删改查的语法，学完写个多表查询照样卡壳。这套 MySQL 学习资料的好处是——它按「先会用，再会查，最后会调」的顺序排好了内容，把语法、索引、事务、锁、备份这些模块拆成能跟着练的路线，而不是给你丢一堆视频链接让你自己拼图。适合正在从写单表 SQL 往真正处理业务数据过渡的人，也适合想系统补一遍 MySQL 原理但没时间啃官方文档的开发者。接下来我把这套资料的结构、关键知识点和最容易翻车的地方拆开讲。
2. 学习路径怎么排：从 SQL 语法到 InnoDB 原理的顺序问题
2.1 为什么先学查询写法，而不是先学索引原理
很多人学 MySQL 有个惯性，觉得原理越底层越厉害，于是上来就啃 InnoDB 存储引擎、锁机制、MVCC。结果往往是一周之后连 LEFT JOIN 和 INNER JOIN 的区别都说不清，原理倒是背了一堆。这套资料的第一部分没有急着讲原理，而是把 SQL 基础语法拆成了「单表查询 → 多表关联 → 子查询 → 聚合与分组 → 窗口函数」五个台阶。我拆完发现这个顺序是有讲究的：前面的语法没练熟，后面的优化技巧根本没有载体。
举个例子，资料里练习多表关联时，要求先把三张表的字段和关系画出来再写 SQL，而不是直接上手写。这个习惯看着慢，但到了排查线上慢查询时非常有用——你先知道表之间是什么关系，才能判断 LEFT JOIN 之后的行数膨胀是不是预期的。常见做法是先跑一遍 SELECT COUNT(*) 验证关联后的行数对不对，再谈要不要改 JOIN 方式。
2.2 性能优化模块放在事务之前的原因
资料的第二块内容是索引和 EXPLAIN，第三块才是事务、锁和隔离级别。这个安排一开始有点反直觉——很多课程喜欢把事务放在很靠前的位置。但考虑到这份资料面向的是实际干活的人，事务的知识点偏「理解正确性」，而索引和 EXPLAIN 偏「解决性能问题」。从职业成长的路径看，先能发现 SQL 慢在哪，再去理解为什么并发场景下会有脏读、幻读，学起来会更顺。
EXPLAIN 的练习部分，资料给了几条固定的观察路径：先看 type 字段是不是 ALL，再看 key 字段有没有命中索引，最后看 rows 字段估算的行数。这三步做完，一条慢查询基本能定位出方向。需要注意的一点是，type 是 ALL 不一定代表 SQL 一定慢，小表全表扫描比走索引可能更快，优化器不选索引未必是错的。这些细节资料里都有提示，属于能让你少交学费的部分。
3. 索引与执行计划：看懂 EXPLAIN 输出里的几个关键字段
3.1 索引选错的典型场景与判断方法
资料里有一部分专门讲「索引失效」，用的是模拟项目X的订单表。表结构很简单：订单号、用户ID、商品ID、下单时间、金额。练习里故意给出几条查询，比如在 user_id 上建了索引，但查询条件写成了 WHERE user_id + 1 = 100，让读者观察索引是否生效。这类写法在真实代码里不太常见，但它是理解索引原理的好样例——你只要在字段上做了运算或函数处理，索引就失效了。
更常见的是隐式类型转换的坑。表里 user_id 是字符串类型，查询时写成 WHERE user_id = 100，MySQL 会把字段隐式转成数字，索引照样失效。排查这类问题最快的办法是执行 SHOW WARNINGS 查看优化器改写后的 SQL，能看到它把条件转成了 CAST(user_id AS SIGNED) = 100。这套资料带了一个完整的排查流程样例，从怀疑到确认，再到改写方案，值得照着跑一遍。
3.2 复合索引的列顺序判断标准
复合索引这个模块是资料里信息密度比较高的部分，它没有直接给结论「最左前缀原则」，而是给了三个问题来推导：等值查询放前面还是范围查询放前面？区分度高的放在最左还是区分度低的？排序字段加进索引到底有没有用？
常见做法是按「等值条件优先、区分度高的靠左、范围条件放最后」来建复合索引。但资料里补充了一个容易被忽略的点：如果查询里既等值又范围又有排序，需要先用执行计划试，不要只看理论。因为索引的选择跟数据分布强相关，某张表里某个字段的区分度可能因为业务原因变得很低，理论上的最优顺序在真实数据上未必最优。我在实践中遇到过一次类似情况，查询条件里两个等值字段，一个区分度很高，一个几乎只有两个固定值，按理论应该把区分度高的放前面，但 EXPLAIN 显示全表扫描反而更快——因为数据量太小，走索引还要回表，不如直接扫。那次之后我看优化问题就不再只盯着索引顺序了。
下面是资料里练习复合索引时常用的验证脚本，建议每调整一次索引顺序就重新 EXPLAIN 一次，看 type 和 rows 的变化：
EXPLAIN SELECT order_id, amount FROM orders WHERE user_id = 1001 AND status = 'PAID' AND create_time BETWEEN '2024-01-01' AND '2024-06-30';这个查询的逻辑是先按用户等值过滤、再按状态过滤、最后按时间范围过滤。先跑一次不加索引的 EXPLAIN 观察 rows 的基数，再分别建立 (user_id, status, create_time) 和 (status, user_id, create_time) 两种复合索引对照。
上面的例子看起来简单，但它背后藏着索引优化的两个核心原则：索引是给存储引擎快速定位行用的，字段顺序决定了能过滤掉多少数据；加 ORDER BY 字段时则要判断排序能不能直接利用索引的有序性，避免 filesort，这个在资料配套的练习里专门有一个章节讲。执行计划里的 Extra 字段如果出现 Using filesort，基本可以断定排序没走索引。
4. 常见问题排查：这套资料学习过程中最容易翻车的五个场景
4.1 照着练习写 UPDATE 忘了加 WHERE 条件导致全表更新
现象：执行完 UPDATE 后发现影响行数等于表总行数，业务数据全被改掉了。
原因：写练习时手滑，或者复制前一条 SELECT 语句时把 WHERE 条件漏掉了。
解决：MySQL 客户端默认不开启安全更新模式。建议连接时加上 -U 参数，或者在配置文件里把 sql_safe_updates 设为 1，这样不带 WHERE 条件的 UPDATE 和 DELETE 会被直接拦截。我当时实习时第一次犯这个错，数据直接从测试环境丢到了预发环境，从那以后每写一条 UPDATE 都会先 SELECT 一遍同样的条件，确认行数符合预期才切换成 UPDATE。
4.2 连接数打满导致应用雪崩
现象：数据库本身 CPU 不高，但新连接报 Too many connections，应用接口大面积超时。
原因：应用层连接池配置过大，超过数据库 max_connections 上限；或者存在慢 SQL，连接被长时间占用不释放。
解决：先把 max_connections 调大是治标不治本，更优先的是查 information_schema.PROCESSLIST 看哪些会话长时间处于 Sending data 或 Waiting for table lock 状态。这套资料里配套了一个排查脚本，能按时间倒序展示连接信息，找出占用连接数最多的三个来源 IP 和 SQL。真实业务里连接数暴涨八成是某条新上线的 SQL 没走索引，全表扫描把连接拖住了。
4.3 事务隔离级别理解错位，在 RC 下测出锁等待
现象：在 REPEATABLE READ 下做锁等待实验没问题，把隔离级别改成 READ COMMITTED 后同样的实验行为变了，开始怀疑自己的理解。
原因：两种隔离级别在 MVCC 下的快照生成时机不同、间隙锁的加锁范围也不同。RC 下只加记录锁，RR 下会加间隙锁，导致同样一条 SQL 在两种隔离级别下的锁行为和阻塞表现不一样。
解决：做锁相关的实验前，先 SET SESSION TRANSACTION ISOLATION LEVEL 明确当前的隔离级别，并在笔记里记下这次实验用的级别。资料里的实验章节在开头固定写了一段排查指令，用来确认当前会话的隔离级别和事务状态，这一步别跳过。
4.4 明明有索引，EXPLAIN 里还是 ALL
现象：在 WHERE 条件涉及的字段上建了单列索引，EXPLAIN 显示还是全表扫描。
原因：最常见的是优化器估算走索引还需要回表太多次，不如直接扫全表省事；另一种是条件里对字段做了运算或函数处理，索引失效。
解决：先查看 SHOW WARNINGS 看优化器改写后的 SQL，再确认是不是存在索引失效写法。如果是回表代价高导致的，可以考虑覆盖索引把查询字段都包含进去，让 Extra 出现 Using index。这里有个经验：单列索引在低区分度字段上基本是摆设，建复合索引的收益远大于追求每个字段都有索引。
4.5 GROUP BY 出来的数据看着对，一核对明细就对不上
现象：按天汇总的订单金额，用明细去 SUM 校验，结果和 GROUP BY 统计出来的不一样。
原因：多半是数据里有 NULL 值或重复记录。COUNT(amount) 不会统计 NULL，但 GROUP BY 的结果集里会单独分一组，看起来金额就对不上；重复记录则因为 JOIN 或基础数据本身有问题导致多算。
解决：汇总之前先跑一次 SELECT * FROM 明细 WHERE 关键字段 IS NULL 确认边界数据，再决定是用 COALESCE 把 NULL 转成 0，还是直接过滤掉。校验 SQL 建议写两个版本：一个按明细逐条相加，一个按分组汇总，两边对不上就说明基础数据或关联条件有问题。
5. 验证学习成果最直接的方式：把 EXPLAIN 和慢查询日志变成日常习惯
这套资料学完一遍之后，最值得固化的并不是背下来的语法，而是两条排查肌肉记忆。第一条是任何一条要上线的 SQL 都先 EXPLAIN 一遍，重点看 type 是不是范围扫描、rows 估算值是否在预期以内、Extra 有没有出现 Using filesort 或 Using temporary。第二条是慢查询日志别关，调一个合适的阈值。常见做法是开发环境阈值设 100 毫秒，线上根据业务量先设 1 秒，逐步调到 200 毫秒，然后每周看一眼 TOP 10 慢 SQL 清单。
我一般会在新接手的项目里先执行一遍下面的诊断查询，确认慢查询日志当前的开关状态和时间阈值：
SHOW VARIABLES LIKE 'slow_query_log'; SHOW VARIABLES LIKE 'long_query_time';如果 slow_query_log 是 OFF，先打开再设阈值，两条命令的事：
SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 0.5;实操时要留意：global 级别只对新会话生效，已经打开的客户端连接不受影响。改完需要重新连接一次，再确认参数生效。这套资料里也提醒过，别在业务高峰期直接调 long_query_time 到 0.2，慢 SQL 大量进日志会撑爆磁盘，建议先用 1 秒观察一周。
从那以后我每次接手 MySQL 相关的工作，第一件事永远是确认慢查询日志开着、阈值在合理范围，再顺手把 EXPLAIN 的观察步骤过一遍。这两个习惯能过滤掉大部分线上性能问题，也能把学习资料里的知识点真正变成日常操作。希望帮到你。
本文还有配套的精品资源，点击获取
