1. 为什么要系统拿下MySQL基础
MySQL在各类数据存储方案里，算是出镜率最高的一个。不管是做后端服务、数据分析、运维自动化，还是给个人项目做持久化存储，MySQL几乎都是默认选择。我的经验是，很多人在初学阶段会陷入两个极端：要么只背SQL语句，做几道增删改查题就觉得“会了”；要么一头扎进索引优化、主从复制、分库分表这些高大上话题，结果基础不牢，越学越虚。
MySQL基础的核心解决的是三件事：第一，能熟练地用SQL完成日常数据操作；第二，能理解数据在磁盘和内存里是怎么组织的；第三，能读懂一条查询语句为什么慢，并具备基本的排查方向。这三件事掌握之后，你再去看性能调优、高可用架构、分布式方案，才会真正有“地基”的感觉。
这篇内容不是教科书式的语法罗列，而是按我自己的学习和带新人经验总结出来的主线路径。适用对象包括刚接触数据库的学生、转行做后端开发的候选人，以及写好几年业务代码但对数据库内部机制不太清楚的工程师。建议你边读边动手操作，别光看。
2. MySQL基础到底包含哪些知识板块
2.1 从整体上给MySQL画一张认知地图
我习惯把MySQL基础拆成五个互相依赖的部分，你可以把它想象成一辆车的结构：
- SQL语言层：相当于方向盘和仪表盘，是你和数据库直接交互的所有手段。包括查询、写入、修改、删除，以及库表管理语句。
- 存储引擎层：相当于发动机类型。MySQL不止一种发动机，InnoDB是默认主力，不同引擎决定了数据怎么存、崩溃了怎么恢复、并发写入时怎么加锁。
- 索引机制层：相当于车的导航系统。没有索引，全表扫描就像在陌生城市没有导航绕路；有索引，就是导航直接带你走快速路。
- 事务与锁机制：相当于交通规则。保证多个操作并发时不乱套，数据不会读到一半或者写入一半就崩溃。
- 日常管理与维护：相当于4S店保养。包括备份、恢复、慢查询分析、用户权限分配等。
这五个板块不是孤立的。举个最简单的例子：你写了一条UPDATE语句（SQL层），它跑到InnoDB里执行（引擎层），为了快速定位要改的行会走索引（索引层），同时要加行锁并记录事务状态（锁与事务层），最后你还要定期备份防止误操作（管理维护层）。所以基础阶段就要建立这种环环相扣的思维。
2.2 学习顺序的合理安排
不少初学者喜欢按教材目录顺序学，先学历史、再学安装、再学语法。我的建议是更务实一些，按“能干活”的逻辑推进：
- 第一步，花半小时装好环境，其他先不管。Windows装MySQL和Linux上装MySQL都可以，装完能连上就行。
- 第二步，直接用SQL去操作一张用户表做完增删改查，先获得“我能操作数据库”的手感。
- 第三步，再来理解表的字段类型、主键外键、字符集这些建表细节。因为一上来就讲这些太抽象，有了实际操作再回来看设计规范，理解成本低很多。
- 第四步，接触索引，尝试给一张几万行的表加索引，感受性能变化。
- 第五步，学习事务的四种隔离级别和锁的机制。
- 最后，再看备份、导入导出、慢查询日志等运维向内容。
有人会问：为什么把索引放在事务之前？因为索引直接影响你对查询性能的感知，这种“性能变化”是即时反馈，容易建立兴趣。而事务和锁相对抽象，放到后面，配合并发场景去理解更合适。
3. SQL语言层：不只是会写增删改查
3.1 把SQL分类弄清楚，后面学习会顺很多
SQL（结构化查询语言）按功能分为几类，很多新手混着学，导致什么时候该用GRANT、什么时候该用ALTER都分不清。其实就五类：
- DDL（数据定义语言）：负责库和表的结构。CREATE DATABASE、CREATE TABLE、ALTER TABLE、DROP TABLE都属于这一类。核心是改变“框架”。
- DML（数据操作语言）：负责具体数据内容。INSERT、UPDATE、DELETE。核心是改变“内容”。
- DQL（数据查询语言）：核心就是SELECT，这是所有业务系统里最常用的部分。
- DCL（数据控制语言）：负责权限、用户。GRANT、REVOKE属于这一类。
- TCL（事务控制语言）：COMMIT、ROLLBACK，负责事务提交与回滚。
你随便打开一个业务系统的日志，十有八九都是SELECT、INSERT、UPDATE的组合。但真正决定你的系统能不能扛住流量的，往往是你会不会设计表结构（DDL层面的功力）以及会不会写查询（DQL层面的功力）。
3.2 一定要形成肌肉记忆的查询子句顺序
SELECT的执行逻辑顺序和书写顺序不一致，这是新手最容易懵的地方。书写顺序是：
SELECT column_name FROM table_name WHERE condition GROUP BY column_name HAVING filter_condition ORDER BY column_name LIMIT offset, count;但实际执行顺序是：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT。
我见过很多新人在这上面栽跟头，比如想在WHERE里使用SELECT里定义的别名，结果报“字段不存在”。原因就是执行顺序里WHERE比SELECT早。再比如想用聚合函数过滤分组数据，在WHERE里写COUNT(*) > 2直接报错，因为聚合函数只能在HAVING里用。
当你能下意识地说出每一步的执行顺序，写复杂查询的时候就不再是瞎试，而是知道哪个阶段该对齐哪个子句。这是一个非常重要的基础能力。
3.3 JOIN连接：理解驱动表与被驱动表
多表查询用JOIN，这个知识点在基础阶段是分水岭。我常用一个生活化类比来解释：假设你要查“每个订单的买家名字”，订单表里有buyer_id，买家表里有user_name。JOIN就是拿订单表里的buyer_id去买家表里“对号”。
INNER JOIN只返回两边都匹配得上的行；LEFT JOIN以左表为基准，右表没有匹配就补NULL。按照我后面的经验，绝大多数业务场景用LEFT JOIN和INNER JOIN就够，RIGHT JOIN和FULL OUTER JOIN使用频率很低，但面试常被问，可以理解但不必纠结。
还要注意一点：连接条件建议用ON来指定，WHERE只负责过滤。很多老代码会把过滤条件写在WHERE里，功能上没错，但可读性和维护性会降低。养成好习惯，连接归连接，过滤归过滤。
4. 字段类型与表设计：基础里的硬功夫
4.1 整数类型和字符串类型别乱用
建表的时候，字段类型拍脑袋选，后面会非常难受。主要记住几个原则：
- 整数类型：TINYINT占1字节（范围-128到127），INT占4字节，BIGINT占8字节。存储用户年龄用TINYINT够用，存储订单金额的整数部分用BIGINT都不过分。无符号可以用UNSIGNED修饰，但新版MySQL其实更推荐直接用更大的类型。
- 字符串类型：VARCHAR是可变长度，适合用户名、邮箱；CHAR是定长，适合身份证号、手机号这类长度固定的数据。TEXT类型适合长文本，但注意TEXT不能直接设置默认值，而且索引上有更多限制。
我最常跟新人强调的一句话是：字段类型选错，索引再优化也救不回来。数据量小可能看不出差别，一旦单表数据量上千万，类型占用的字节数直接影响索引页能存多少键值，进而影响磁盘IO次数。
4.2 为什么主键最好是自增整数
InnoDB的索引结构是B+树，数据本身按主键顺序组织。如果你用一个业务字段（比如身份证号）做主键，每次插入新数据都有可能触发页分裂，就像往一本已经排好序的书中间插一页，后续所有页码都要调整，代价很大。用自增整数做主键，新行永远追加在末尾附近，顺序写入性能最好。
另外，主键不要用UUID字符串。UUID是随机的、长度大，作为主键既浪费空间，又严重破坏插入的顺序性，性能会很快恶化。我见过一个真实案例：某团队用UUID做主键，单表两百万行数据时插入耗时已经明显上升，换成BIGINT自增主键后立竿见影。
4.3 字符集和排序规则要在一开始就定好
在MySQL 8.0之前，默认字符集是latin1，不支持中文，很多人踩过“中文变乱码”的坑。8.0之后默认是utf8mb4，这个字符集才是真正完整的UTF-8实现，emoji表情也能存。
排序规则也要注意，utf8mb4_general_ci是不区分大小写的，utf8mb4_bin是按二进制比较、区分大小写。如果你做用户名唯一校验，用_bin更严谨，否则“Abc”和“abc”会被当成同一名字。这些细节在项目初期定了之后，后期改起来非常痛苦，因为要涉及数据转换。
5. 索引机制：性能优化的起点
5.1 索引是拿空间换时间的典型设计
索引的本质就是一份“目录”。MySQL用B+树结构来组织这份目录，叶子节点有序排列并且用双向链表串起来，所以范围查询特别高效。
为什么是B+树而不是二叉树或者哈希表？部分原因是B+树的每个节点可以容纳大量子节点，树的高度很矮。InnoDB默认一页16KB，如果主键是BIGINT（8字节），加上指针等开销，一个节点能装大概上千个键值。三到四层就能支撑千万级甚至上亿级数据量，也就是查询过程最多几次磁盘IO，这个设计非常契合磁盘存储的物理特性。
5.2 最左前缀原则：联合索引的命门
很多新人建索引喜欢把所有查询字段都放进一个联合索引里，然后发现执行计划压根没走索引。原因往往是不理解最左前缀原则。
联合索引(a, b, c)相当于先按a排序，a相同再按b排序，b相同再按c排序。所以查询条件里带a，能用到索引；带a和b，也能用到；直接只查b或c，就用不上这个联合索引。这就好比查字典，先查拼音首字母，再查声母，再查韵母，你跳过前两个直接查声调，字典帮不了你。
我建联合索引的建议是：把等值条件字段放前面，把范围条件字段放后面。比如WHERE user_id = ? AND status = ? AND create_time BETWEEN ? AND ?，索引设计(user_id, status, create_time)就比较合理。
5.3 回表、覆盖索引与最常用的EXPLAIN
InnoDB的索引分两种：聚簇索引（主键索引）和二级索引（普通索引）。聚簇索引的叶子节点直接存整行数据，二级索引的叶子节点只存索引字段+主键值。
假设你建了idx_name(name)这个二级索引，执行SELECT * FROM user WHERE name = '张三'，MySQL会先在二级索引里找到对应的主键id，再根据id回表去聚簇索引取完整行，这个过程就是回表。如果你只SELECT name，那在二级索引里就取到结果了，不需要回表，这叫覆盖索引。设计索引时尽量让常用查询命中覆盖索引，能省一次IO。
至于EXPLAIN，这是查看SQL执行计划的核心工具。直接在你的SELECT前面加EXPLAIN，会输出一张表，关键看type字段，从好到差大致是：const > eq_ref > ref > range > index > ALL。看到ALL就说明全表扫描，该考虑加索引了。rows字段能估计扫描行数，越少越好。
6. 事务与隔离级别：保证数据不出错
6.1 ACID分别是捆绑在数据之上的四道保险
事务是数据库管理系统执行过程中的一个逻辑单元，它有四个特性，用ACID缩写：
- 原子性（Atomicity）：事务里的操作要么全部成功，要么全部失败，不能只执行一半。
- 一致性（Consistency）：事务执行前后，数据始终符合约束规则，不会出现账面不平的情况。
- 隔离性（Isolation）：多个事务并发执行时，相互之间要有隔离，不能互相干扰。
- 持久性（Durability）：事务提交后，修改就永久保存，即使系统崩溃也不丢失。
举个例子，转账操作：A扣100、B加100。原子性保证这俩操作不能一个成功一个失败；一致性保证两人余额之和维持不变；隔离性保证转账过程中的“中间状态”不能被其他事务看到；持久性保证转账完成后，哪怕数据库重启数据依然正确。
6.2 隔离级别怎么选：安全与性能的平衡
MySQL的InnoDB提供四种隔离级别：
- READ UNCOMMITTED（读未提交）：可以读到其他事务未提交的数据，几乎不用。
- READ COMMITTED（读已提交）：只能读到已提交数据，解决了脏读，但不可重复读。
- REPEATABLE READ（可重复读）：同一事务多次读同一数据结果一致，解决了不可重复读和脏读。
- SERIALIZABLE（串行化）：完全串行执行，性能极差。
MySQL默认是REPEATABLE READ。很多人会有疑问：为什么互联网公司会改成READ COMMITTED？因为可重复读级别下，间隙锁更容易生效，并发插入时锁范围更大，容易出现死锁和锁等待。READ COMMITTED下锁粒度更小，并发度更高。不过如果你是个人项目，直接用默认隔离级别就好，不用刻意去改。
6.3 乐观锁与悲观锁的适用场景
锁是数据库控制并发访问的手段。从锁的粒度分，有表锁、行锁；从策略分，有悲观锁和乐观锁。
悲观锁就是默认觉得会发生冲突，操作前直接加锁。典型语句SELECT ... FOR UPDATE，把相关行锁住，直到事务提交才释放。适合并发冲突严重、写多的场景，比如库存扣减。
乐观锁则默认不太会冲突，不加锁，通过版本号字段或者CAS机制在更新时校验。比如UPDATE stock SET count = count - 1, version = version + 1 WHERE id = ? AND version = 旧版本号。如果影响行数为0，说明版本已变，重试即可。
基础阶段你要能做到：能说出当前事务的隔离级别、你写的UPDATE会加什么锁、如何排查死锁。这些在面试和实际故障排查中都是很实用的能力。
7. 实操记录：从环境准备到慢查询排查
7.1 环境准备：Docker是我最推荐的本地方式
熟悉环境的方式很多，但Docker方式最省心，不会把宿主机搞乱。假设你本机已经装了Docker，直接跑：
docker run -d \ --name mysql-basic \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=your_password \ -v mysql_data:/var/lib/mysql \ mysql:8.0这里做了三件事：把容器命名为mysql-basic，映射宿主机3306端口到容器3306端口，设置root密码，并使用命名卷保存数据。关键点是-v参数，没有它，容器删掉数据就全没了。
如果你不想用Docker，直接在Linux上安装也很简单，Ubuntu系可以用apt install mysql-server，安装完之后用systemctl start mysql启动即可。Windows下则是用安装包安装，装完在服务里启动MySQL服务。基本的操作诉求是一致的：能连上、能执行SQL。
7.2 建库建表的一整套标准动作
连接上MySQL后，我习惯先看一眼版本和字符集：
SELECT VERSION(); SHOW VARIABLES LIKE 'character_set_server';然后创建数据库。注意用IF NOT EXISTS，防止重复执行报错：
CREATE DATABASE IF NOT EXISTS shop_demo DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;接下来建用户表，带主键、唯一索引和常用查询索引：
USE shop_demo; CREATE TABLE IF NOT EXISTS user ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键', username VARCHAR(64) NOT NULL COMMENT '用户名', email VARCHAR(128) NOT NULL COMMENT '邮箱', age TINYINT UNSIGNED DEFAULT 0 COMMENT '年龄', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (id), UNIQUE KEY uk_email (email), KEY idx_username (username) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';这段建表SQL值得逐行解释：
- id用BIGINT UNSIGNED AUTO_INCREMENT，是标准自增主键设计。
- username用VARCHAR(64)加一个普通索引，因为用户名常见于WHERE条件。
- email用UNIQUE KEY约束，因为业务上邮箱不允许重复。
- created_at用DATETIME而不是TIMESTAMP，因为8.0里两者差别已越来越小，DATETIME没有2038问题。
- ENGINE=InnoDB是默认引擎，不能主动选MyISAM。
7.3 数据插入与查询：怎么造数据又怎么查数据
为了演示慢查询排查，我们往表里批量插入一百万行测试数据。用存储过程是最实用的方式，比如：
DELIMITER $$ CREATE PROCEDURE insert_mock_users(IN total INT) BEGIN DECLARE i INT DEFAULT 1; WHILE i <= total DO INSERT INTO user (username, email, age) VALUES ( CONCAT('user_', i), CONCAT('user_', i, '@example.com'), FLOOR(1 + RAND() * 80) ); SET i = i + 1; END WHILE; END$$ DELIMITER ; CALL insert_mock_users(1000000);这个存储过程每次插入都单独提交一次，百万行可能要跑比较久。如果只是想测试查询，插入十万行就够了。注意生产环境没人这么干，这是纯测试技巧。
然后我们来对比一下带不带索引的查询差别。比如查username = 'user_99999'这条数据：
SELECT * FROM user WHERE username = 'user_99999';由于我们已经建了idx_username索引，执行应该很快。如果不放心，用EXPLAIN确认是否走了索引：
EXPLAIN SELECT * FROM user WHERE username = 'user_99999';执行计划里可以看到type为ref，key为idx_username，rows大概只有一行，说明命中了索引。
7.4 慢查询日志：找到拖慢业务的那条SQL
如果线上系统很卡，第一个要排查的就是慢查询。MySQL可以开启慢查询日志，把执行时间超过阈值的SQL记录下来。在会话里临时开启：
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';long_query_time单位是秒，设为1表示超过1秒就记录。这个只是临时开启，重启失效。要永久生效，需要写进my.cnf的[mysqld]段落。
慢查询日志里每一条记录都包含执行时间、锁等待时间、返回行数、扫描行数以及SQL语句本身。我最看重的字段是Rows_examined和Rows_sent，如果前者远大于后者，说明查询扫描了大量行却只返回少量结果，SQL或者索引需要优化。
比如你在慢日志里看到一条语句扫描了90万行只返回1行，明显就是没走索引。这时候回看表的索引设计，补齐缺失索引，问题通常能解决大半。
8. 备份与恢复：保命技能不能缺席
8.1 逻辑备份用mysqldump，日常够用
mysqldump是MySQL自带的最经典备份工具，它是逻辑备份，生成的文件是一堆SQL语句，可读性强，适合中小型数据库。
备份单库的命令：
mysqldump -u root -p shop_demo > shop_demo_backup.sql恢复的命令：
mysql -u root -p shop_demo < shop_demo_backup.sql如果要备份多个库或者所有库，可以用--databases或--all-databases参数。但注意，mysqldump在数据量特别大（比如几百GB）时，备份和恢复速度都不理想，那已经到了物理备份或者说专业备份工具的范畴，基础阶段不用深究。
我自己的习惯是给备份文件加日期后缀，然后用crontab定时执行，比如每天凌晨3点做一次全量备份。
mysqldump -u root -p --single-transaction shop_demo > /backup/shop_demo_$(date +%F).sql--single-transaction这个参数很重要，它通过InnoDB的事务机制保证备份期间数据一致性，同时不影响线上读写。
8.2 误操作后的恢复思路
假设你不小心执行了不带WHERE的DELETE，把整张表删光了。这时候怎么办？在没有开启binlog的情况下，你只能从最近一次全量备份恢复，丢失备份时间点之后的数据。如果有binlog，就可以用binlog做时间点恢复，把备份之后、误操作之前的变更重新回放一遍。
所以这里我强烈建议生产环境的MySQL都开启binlog：
[mysqld] server-id=1 log-bin=mysql-bin binlog_format=ROWbinlog_format用ROW模式，信息更完整。这也是后续做主从复制的基础。binlog是MySQL的“账本”，记录所有数据变更。它既是恢复利器，也是主从复制的数据源。
9. 角色权限管理：最小权限原则怎么落地
MySQL的权限体系其实不复杂。核心是用户（User）和权限（Privilege）两个概念。常用操作如下：
-- 创建用户，限定只能从指定主机连接 CREATE USER 'app_user'@'localhost' IDENTIFIED BY 'strong_password'; -- 只授予查询权限 GRANT SELECT ON shop_demo.* TO 'app_user'@'localhost'; -- 授予增删改查权限 GRANT SELECT, INSERT, UPDATE, DELETE ON shop_demo.* TO 'app_user'@'localhost'; -- 回收权限 REVOKE DELETE ON shop_demo.* FROM 'app_user'@'localhost'; -- 查看用户权限 SHOW GRANTS FOR 'app_user'@'localhost';最小权限原则就是说：一个账号只给能完成工作的最少权限。应用连接数据库的账号不应该有DROP、TRUNCATE权限；数据分析账号可以给SELECT权限，但别给DELETE。这些约束是为了降低误操作和攻击带来的风险。
还有一个细节：MySQL 8.0的认证插件是caching_sha2_password，一些老客户端连接时会报认证失败。遇到这类问题，可以在创建用户时指定：
CREATE USER 'app_user'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password';不过这只是兼容老客户端的临时方案，新项目尽量用8.0默认插件。
10. 常见问题与排查技巧实录
10.1 100% CPU占用或查询特别慢的排查路径
这是一类经常发生的问题：某天线上数据库CPU跳到100%，应用接口大面积超时。排查路径我总结成四步：
- 第一步，先看连接数。SHOW STATUS LIKE 'Threads_connected'; 同时看是否远高于正常水平。如果连接数爆了，大概率是慢查询堆积导致的连接池打满。
- 第二步，开慢查询日志，或者用SHOW PROCESSLIST直接看正在执行的SQL，找到长时间Running的会话。
- 第三步，拿到SQL后用EXPLAIN分析执行计划，重点看type和rows。
- 第四步，根据执行计划加索引、改写SQL或调整业务逻辑。
有个真实的案例：某公司的订单列表接口数据量到几十万行后响应变慢，查慢日志发现是排序导致的。SQL类似SELECT ... FROM order WHERE user_id = ? ORDER BY create_time DESC LIMIT 20，其实已经建了user_id索引，但排序还是用了临时文件。后来把索引改成(user_id, create_time)，让索引天然有序，排序就直接走索引，不用额外排序，接口耗时从300毫秒降到20毫秒。
10.2 死锁报错怎么处理
你可能会在并发写入场景中遇到死锁报错，类似Deadlock found when trying to get lock; try restarting transaction。死锁的本质是两个事务各自持有锁，又都在等对方释放的锁，形成循环等待。
InnoDB会自动检测死锁，并选择一个事务回滚，让它释放锁，另一个事务继续执行。所以应用层要做好一件事：捕获死锁异常并重试整个事务。
避免死锁的方法，最常见的是让事务按固定的顺序访问资源。比如多个操作都会更新用户A和用户B的数据，那就规定总是先更新ID小的那条记录，再更新ID大的。这样可以避免两个事务交叉持有锁而死锁。
还有，事务尽量短小。一个事务里不要做远程调用、不要等待用户输入，因为事务时间越长，锁持有的时间就越长，死锁和锁等待的概率越大。
10.3 索引失效的几种典型情况
在基础阶段，知道索引什么时候失效比知道更多高级特性更有用。我总结最常踩的几个坑：
- 在索引列上做函数运算，比如WHERE DATE(create_time) = '2024-01-01'。一旦对列做函数计算，索引就失效了。应该写成WHERE create_time >= '2024-01-01' AND create_time < '2024-01-02'。
- 隐式类型转换。如果字段是字符串类型，查询时却用了数字：WHERE username = 123，MySQL会把字段转成数字再比较，索引失效。
- 前导模糊查询，LIKE '%abc'，以通配符开头，B+树的顺序扫描能力用不上，就无法走索引。LIKE 'abc%'则可以。
- 联合索引没有满足最左前缀原则，这个在前面已经说过。
排查索引失效最快的办法还是EXPLAIN，看到key字段为NULL或者type从ref变成ALL，就要往这几个方向检查。
11. 我踩过的一些坑和给你的建议
MySQL基础这条路，我自己走了不少弯路，总结几个经验供你参考。
第一，基础阶段不要过度追求“高级感”。有段时间我觉得会写复杂嵌套子查询和窗口函数才算厉害，后来在真实业务中发现，90%的复杂查询其实可以拆成简单的多条SQL去执行，代码可读性更好，性能也不差。把单表查询、索引设计、事务边界这些基本功打扎实，比会炫技重要得多。
第二，要主动给自己制造问题场景。比如故意写一条慢查询，然后用EXPLAIN去分析；故意开两个事务制造死锁，看看怎么解决。数据库这类东西，光靠看文档学不会，必须亲手踩一遍坑才能内化。我之前带过的新人，凡是动手做过索引对比实验的，面试时谈执行计划都能讲得比较清楚；只说不练的，遇到问题就卡壳。
第三，MySQL的官方文档其实是最好的学习资料，尤其是“InnoDB存储引擎”和“SQL优化”章节。市面上很多二手资料内容过时，甚至还有错误。遇到模棱两可的问题，直接翻官方文档查证，这是最可靠的路径。
第四，养成看日志的习惯。不管是错误日志、慢查询日志还是binlog，日志会告诉你很多真相。遇到问题先看日志再猜原因，能少走很多弯路。
最后，保持版本敏感度。MySQL 5.7和8.0在很多细节上有差异，比如默认字符集、窗口函数支持、CTE（公用表表达式）等。如果你学的是8.0，网上很多针对5.7的老方案会踩坑。一切以你自己安装的版本为准，动手验证一遍才靠谱。
