1. 复习MySQL，到底在复习什么
前两天整理电脑里的学习笔记，翻到去年年初给自己定的目标清单，第一条写着“系统复习MySQL”。当时还画了好几个大箭头，从安装部署指向索引优化，从事务隔离指向锁机制，一副要啃下整个数据库知识体系的架势。结果这一年忙起来，断断续续看了一些文章，敲了一些命令，真正沉淀下来的东西却总觉得零散。这次下定决心重新过一遍，把踩过的坑、理清的思路、值得记住的结论都写下来，索性整理成一篇完整的复习笔记，分享给同样在补MySQL功课的朋友。
MySQL这东西，说简单也简单，日常增删改查谁都会；说复杂也复杂，索引原理、事务隔离、锁的调度、主从同步、性能调优，每一块拎出来都能写好几篇长文。但复习的关键不在于把文档从头到尾读一遍，而在于建立一个清晰的知识地图，知道哪些是高频考点，哪些是工作中的真实痛点，哪些是面试官最爱追问的底层逻辑。这篇文章适合正在准备面试的开发者，也适合工作中经常跟数据库打交道、想系统补一补基础的同学。我会按照我自己复习的路线来写，把核心知识点、实操命令和踩坑经历都揉进去，尽量做到既能当笔记查，也能当教程看。
有人可能会问，为什么不直接看官方文档？我的体会是，官方文档严谨但太散，知识点之间缺少串联。而一篇好的复习笔记，应该是把“为什么这么设计”和“实际怎么用”结合起来。比如索引为什么能加速查询，底层是B+树在起作用；事务隔离级别为什么有四种，每种解决什么问题，又留下什么隐患；锁为什么分共享锁和排他锁，死锁是怎么产生的，等等。把这些逻辑链条串起来，知识才能变成自己的，而不是背完就忘。
2. 搭建复习环境：安装部署与基础配置
2.1 不同系统下的安装方式选择
复习的第一步，是有一个能随便折腾的MySQL环境。我最开始用的是Windows，后来切到Linux服务器，两种环境都装过不止一次，这里把我试过比较顺的几种方式列出来。
Windows下安装MySQL 8.0，最简单的是直接去官网下载安装包。这里提醒一下，官网下载地址偶尔会变，最好从mysql.com的Downloads页面进，选择MySQL Community Server，然后挑Microsoft Windows平台，里面会有MSI安装包和ZIP压缩包两种。MSI装起来省事，图形化界面一路Next就行，但有个坑：安装过程中会让你选Server only还是Full，如果只要数据库本身，选Server only就够了，别装一堆用不上的组件。ZIP包则适合喜欢手动控制的人，解压后需要自己初始化数据目录、配my.ini、注册Windows服务，稍微麻烦一点，但能让你对MySQL的目录结构和启动机制有更深的认识。
Linux下安装，主流是yum或apt直接装。CentOS系的话，用yum install mysql-server之前，建议先确认一下软件源里的版本。CentOS 7默认源里还是MySQL 5.7，想装8.0得先装MySQL官方提供的yum仓库。Debian系的Ubuntu则相对简单，apt install mysql-server默认就是8.0。如果你想尝鲜MySQL 8.4 LTS，官方也有对应的仓库配置方法。我的建议是，复习阶段别追最新版本，装一个稳定版LTS就行，8.0和8.4都能覆盖绝大多数知识点。
Docker方式我也试过，确实省心，一条docker run命令就能起一个实例。但实际工作中，用Docker跑MySQL做本地开发很常见，跑生产库则需要谨慎。我复习时之所以不用Docker，是因为想练练手动的安装配置流程，毕竟面试不问“docker run怎么写”，而可能问“MySQL初始化失败怎么排查”。
2.2 初始化、启动与常见报错处理
不管哪种方式装的MySQL，装完后第一件事都是初始化数据目录。用ZIP包或源码方式安装时，需要执行mysqld --initialize --console，这一步会生成一个临时root密码，一定要记下来。如果用MSI安装包，安装过程中会让你设置root密码，就不存在这个问题了。
启动服务时，Windows下可以用net start mysql，但很多人会碰到一个经典报错：“net start mysql 服务无法启动”。这个报错的原因很多，我遇到过的就有三种：一是my.ini里的basedir或datadir路径写错了；二是data目录权限不对；三是端口被占用。排查思路很简单，先去MySQL的data目录下找错误日志，通常是.err结尾的文件，打开看最下面的报错信息。如果提示Can't start server: Bind on TCP/IP port，那就是端口被占；如果提示Can't find error-message file，多半是路径配置问题。Linux下用systemctl start mysqld之前，也可以先跑一下journalctl -u mysqld看日志，比瞎猜快得多。
还有一个常见的坑，是安装MySQL 8.0时报错“e0434352”，这个错误码看起来像是Windows的.NET相关错误，实际上是某些版本的MySQL安装程序依赖VC++运行库。解决方法是装一下Microsoft Visual C++ Redistributable，装完重启再装MySQL就好了。之前给同事远程排查时，她死活装不上，换了2015-2022合集版运行库一次通过。
2.3 连接客户端与SSL连接问题
装好MySQL之后，下一步就是用客户端连上去。命令行客户端自带的mysql -u root -p是最基础的，如果连不上，优先检查用户名、密码、端口和主机地址。还有一个高频报错是“SSL connection error”，MySQL 8.0默认开了SSL，有些客户端连的时候会因为在双方协商加密方式时出了问题而报错。排查方法可以这样：连接命令后面加上--skip-ssl或--ssl-mode=DISABLED试试，如果这样能连上，说明是SSL配置或证书校验的问题，而不是账号权限问题。需要注意的是，只是在本地开发环境排查时临时用，生产环境不建议关掉SSL。
图形化客户端方面，Navicat for MySQL和DBeaver是很多人都在用的。DBeaver有个小坑，它不自带MySQL驱动，第一次连接时会提示下载驱动，如果网络环境不好，下载会失败。解决办法是手动下载mysql-connector-java的jar包，然后放到DBeaver的驱动管理里。老实说，Navicat的操作手感确实更顺滑，导入导出、结构同步都做得很直观，但它是商业软件。破解版就别碰了，一是版权风险，二是很多所谓破解包带着木马，为一个数据库客户端冒险不值得。如果预算有限，DBeaver和MySQL Workbench都够用。
3. SQL基本功：排序、聚合与常用命令
3.1 排序和分组的内在逻辑
复习SQL时，很多人容易忽略一个基础但关键的点：排序的执行顺序。你写一条SQL语句，MySQL执行的时候并不是按照你写的顺序来的。SQL语句的书写顺序是SELECT、FROM、WHERE、GROUP BY、HAVING、ORDER BY、LIMIT，但执行顺序大致是FROM、WHERE、GROUP BY、HAVING、SELECT、ORDER BY、LIMIT。这意味着ORDER BY是在SELECT之后执行的，所以ORDER BY后面的列，必须是SELECT里出现过或者是表里真实存在的列，否则会报错。
排序本身也有不少细节。ORDER BY默认是升序ASC，降序要写DESC。多字段排序时，比如ORDER BY score DESC, name ASC，意思是先按score降序，score相同再按name升序。这个在日常业务里非常常见，比如排行榜既要按积分排，积分一样按注册时间排。另外，字符串排序的规则取决于字符集和排序规则，utf8mb4_general_ci不区分大小写，而utf8mb4_bin区分，这会影响排序结果。之前有个同事做订单号排序时发现结果不对，排查了半天，最后发现是排序规则的区别。
聚合函数这块，COUNT、SUM、AVG、MAX、MIN是基本功，但很多人容易在COUNT()和COUNT(1)之间纠结。其实在MySQL 8.0里，两者性能上几乎没差别，COUNT()反而是SQL标准推荐的做法，别被网上的老段子带偏了。GROUP BY配合HAVING要注意，WHERE是在分组前过滤，HAVING是在分组后过滤，语义完全不同。我复习的时候自己写过一个例子：
SELECT dept_id, COUNT(*) AS cnt FROM employee WHERE status = 1 GROUP BY dept_id HAVING cnt > 10;
这里WHERE status=1先过滤掉非在职员工，再按部门分组，最后用HAVING筛掉人数不足11人的部门。如果把status条件放在HAVING里，结果没错但效率会差一些。
3.2 SQL命令大全式的查漏补缺
说是复习，其实是把常用的SQL命令都过一遍。我给自己列了一份速查清单，不必背下来，但要知道有哪些能力，关键时候能想起来用。DDL部分，CREATE TABLE、ALTER TABLE、DROP TABLE是基础。其中ALTER TABLE修改表结构，经常有人写错语法，加字段是ADD COLUMN，改字段类型是MODIFY COLUMN，改字段名是CHANGE COLUMN，三个操作千万别搞混。DML部分，INSERT、UPDATE、DELETE、SELECT，最需要注意的是UPDATE和DELETE不带WHERE条件会操作全表，这是生产事故的头号原因。我给自己定的习惯是，写UPDATE和DELETE先写WHERE条件，再加其他内容，从源头上防止误操作。
DCL部分，GRANT和REVOKE用于权限管理。复习时我单独练了一下创建用户和授权，比如CREATE USER 'app'@'%' IDENTIFIED BY '密码'; 然后GRANT SELECT, INSERT ON mydb.* TO 'app'@'%';。注意'%'表示任何主机，生产环境为了安全，应该限定具体IP，比如'192.168.1.%'。数据库运维里有一个约定，最小权限原则，给应用账号只授需要的那几个权限，而不是直接GRANT ALL。
索引相关命令也是常考的。CREATE INDEX idx_name ON table(column)、SHOW INDEX FROM table、DROP INDEX都算高频。有一点容易忽略：在MySQL 8.0里，CREATE INDEX不支持加INCLUDE列，但支持函数索引，比如CREATE INDEX idx_created ON user((DATE(created_at)));。这个在按日期查询的场景里非常实用，可以避免在WHERE里对字段做函数运算导致索引失效。
4. 进阶核心：索引、事务与锁机制
4.1 索引为什么能快：B+树的底层逻辑
索引这块是MySQL面试的必考点，也是工作中排查慢查询绕不开的知识。很多人知道索引能加速查询，但说不清为什么。核心在于索引的数据结构是B+树。B+树的叶子节点存储了所有的索引列值和指向行数据的指针，而且叶子节点之间通过双向链表连接，范围查询时可以顺着链表遍历，不需要回溯上层节点。层高通常只有三四层，意味着即使有几百万行数据，查询时也只需要读少数几个磁盘页，这就是快的原因。
聚簇索引和非聚簇索引的区别，是另一个高频考点。InnoDB的主键索引就是聚簇索引，叶子节点存的是整行数据，所以通过主键查询最快。二级索引（也就是普通索引）的叶子节点存的是索引列值和主键值，查询时需要先找到主键，再回到聚簇索引里查整行，这个过程叫回表。如果查询的列恰好都包含在二级索引里，就不用回表，这叫覆盖索引。我在复习的时候把这三个概念串起来理解：聚簇索引决定了数据文件的物理组织方式，二级索引是逻辑上的额外索引结构，回表和覆盖索引是查询优化时的关键考量。
联合索引的列顺序也很重要。比如建了一个(a, b, c)的联合索引，那么查询条件只有a时能用到索引，只有a和b时也能用到，但只有b或只有c时就用不到。这叫做最左前缀原则。我在实际工作中踩过一次坑：用户表上有联合索引(city, age)，线上有个查询条件是WHERE age BETWEEN 20 AND 30 AND city = '北京'，当时以为索引会失效，后来EXPLAIN一看，优化器会自动调整条件顺序，还是会走索引的。所以复习时不仅要记原则，还要会用EXPLAIN验证。
4.2 事务隔离级别：四种级别怎么选
事务的ACID特性大家都知道，原子性、一致性、隔离性、持久性。但隔离性具体怎么实现，隔离级别怎么选择，很多人模棱两可。MySQL默认的隔离级别是REPEATABLE READ，也就是可重复读。四个级别从低到高分别是READ UNCOMMITTED（读未提交）、READ COMMITTED（读已提交）、REPEATABLE READ（可重复读）、SERIALIZABLE（串行化）。
读未提交级别下，一个事务能读到另一个事务尚未提交的数据，也就是脏读。读已提交解决了脏读，但会出现不可重复读，简单说就是同一个事务里，两次执行同样的SELECT，结果不一样，因为别的事务提交了修改。可重复读解决了不可重复读，在一个事务内，多次读取同一数据结果一致。但可重复读不解决幻读，也就是某个事务内两次查询得到的结果集行数不同，期间别的事务插入了新行。MySQL在REPEATABLE READ级别下，通过MVCC（多版本并发控制）和间隙锁，其实能在很大程度上避免幻读，这也是为什么它敢把默认级别设为REPEATABLE READ。串行化则是让事务一个接一个执行，完全解决了所有并发问题，代价是并发性能极差，生产环境几乎不用。
复习事务时，我特意做了一组实验来加深理解。开两个终端模拟两个会话，一个事务里UPDATE一条记录但不COMMIT，另一个事务去查这条记录。在默认的REPEATABLE READ级别下，第二个事务查到的还是旧值，因为MVCC的快照读看不到未提交的数据。这个实验做完，MVCC和隔离级别的配合关系就直观看明白了。
4.3 锁的分类与死锁排查
锁是并发控制的关键机制，也是面试必问。按粒度分，MySQL的锁有表锁和行锁。MyISAM引擎只支持表锁，并发写性能差；InnoDB支持行锁，这也是生产环境默认选择InnoDB的重要原因。按类别分，有共享锁（读锁）和排他锁（写锁）。共享锁之间兼容，共享锁和排他锁互斥，排他锁之间互斥。SELECT默认是快照读不加锁，但如果想强制加锁，可以SELECT ... FOR UPDATE加排他锁，SELECT ... LOCK IN SHARE MODE加共享锁。FOR UPDATE在实际业务里常用于库存扣减之类的场景，防止并发超卖。
行锁在InnoDB里的实现其实有三种：记录锁、间隙锁、临键锁。记录锁锁住具体的索引记录，间隙锁锁住索引记录之间的间隙，临键锁是记录锁和间隙锁的组合，左开右闭区间。默认隔离级别REPEATABLE READ下，InnoDB会用间隙锁防止幻读。这带来一个问题：如果业务SQL的WHERE条件没能正确走索引，行锁会升级为表锁或者锁住大量间隙，导致并发性能骤降。
死锁则是另一个经典话题。死锁的产生需要四个必要条件：互斥、持有并等待、非抢占、循环等待。MySQL内部有死锁检测机制，检测到后会回滚其中一个事务，并报错“Deadlock found when trying to get lock”。我的排查习惯是，出现死锁后先执行SHOW ENGINE INNODB STATUS，看LATEST DETECTED DEADLOCK部分，里面会显示两个事务各自持有和等待的锁。按照经验，死锁最常见的场景是多个事务以不同顺序更新同一组记录。比如事务A先更新id=1再更新id=2，事务B先更新id=2再更新id=1，同时执行时大概率死锁。解决办法是约定统一的更新顺序，按id从小到大依次处理。
4.4 存储过程与异常处理
存储过程在面试中出现的频率不算低，主要是考察对流程控制语法和异常处理逻辑的掌握。我用一个简单的例子来复习：
CREATE PROCEDURE transfer(IN from_acc INT, IN to_acc INT, IN amount DECIMAL(10,2)) BEGIN DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '转账失败，事务回滚'; END; START TRANSACTION; UPDATE account SET balance = balance - amount WHERE id = from_acc; UPDATE account SET balance = balance + amount WHERE id = to_acc; COMMIT; END$$;
这里的关键点有两个。一是DECLARE EXIT HANDLER声明了异常处理程序，任何SQL异常发生时都会执行ROLLBACK并通过SIGNAL抛出自定义错误信息。二是事务操作，转账这种业务天然需要原子性，要么都成功要么都失败。存储过程的调试比较麻烦，所以我建议在过程中多用SIGNAL或者SELECT输出中间变量，方便定位问题。
存储过程和普通SQL相比，还有一个优势是减少网络开销，因为逻辑放在服务端执行。但坏处是业务逻辑侵入数据库，后续维护成本高。我的看法是，对于简单的数据校验和事务封装，用存储过程没问题；但复杂业务逻辑还是放到应用层处理更灵活。
5. 性能调优与运维实操
5.1 慢查询定位与EXPLAIN解读
工作中遇到MySQL慢查询，第一步是确认是不是真有慢查询，第二步是定位到具体的SQL，第三步是用EXPLAIN分析执行计划。开启慢查询日志是常见的做法，在my.ini里配置如下内容：
slow_query_log = ON slow_query_log_file = /var/log/mysql/slow.log long_query_time = 1
long_query_time设成1，意思是执行时间超过1秒的SQL都会被记录。配置完后重启MySQL，业务跑一段时间再看slow.log，就能找到需要优化的SQL。我不建议在生产环境一开始就开全量慢日志，可以先开着但要定期清理，否则日志增长得很快。
拿到问题SQL之后，EXPLAIN是分析执行计划的核心工具。EXPLAIN SELECT ...; 输出里几个字段要看清楚。type列是最重要的，const和eq_ref说明走的是主键或唯一索引，性能最好；ref说明走的是普通索引；ALL说明是全表扫描，需要重点优化。rows列是估算的扫描行数，越小越好。Extra列里如果出现Using filesort或Using temporary，说明排序或分组没有用到索引，通常意味着需要优化SQL或加索引。我复习时经常有这种体会：一条SQL看起来没问题，EXPLAIN跑一下就知道瓶颈在哪了。
举个例子，之前线上有个订单列表查询，每天跑一次报表要十几秒。EXPLAIN一看，type是ALL，扫描了整张订单表。原因就是WHERE里只有status条件，而status字段本身区分度不高，建了索引也可能没用。后来把查询条件改成了time_range + status联合查询，并且建了联合索引，报表时间降到了几百毫秒。这里面的教训是，索引不是建得越多越好，而是要针对实际查询模式来设计。
5.2 数据库连接池与参数调优
数据库连接池这个知识点，在JavaWeb项目里几乎是标配了，但很多人只停留在会用，不清楚为什么需要。MySQL服务端每接收一个连接，就要分配线程和内存资源。如果应用每次访问数据库都新建连接、用完再关闭，在高并发下，连接建立和销毁的开销会占到很大比重。连接池的作用就是维护一批现成的连接，应用需要时从池子里借，用完了还回去，避免反复创建销毁。
主流的连接池有HikariCP、Druid、C3P0等。Spring Boot 2.x默认使用HikariCP，它性能好、配置简单。核心参数就几个：maximumPoolSize控制池中最大连接数，通常设为CPU核数的2到4倍；minimumIdle控制最小空闲连接数；connectionTimeout是获取连接的超时时间，默认30秒，实际设成3到5秒就够，太久会让请求排队。我在复习时顺手做了一次压测，把maximumPoolSize从10调到20，发现QPS并没有翻倍，反而因为线程切换开销增大了。这说明连接数不是越大越好，过大会增加数据库的并发压力。
MySQL服务端的参数调优，核心是innodb_buffer_pool_size，这是InnoDB的缓冲池大小，决定了对数据页的缓存能力。经验值是物理内存的50%到70%。如果设置得太小，数据频繁从磁盘读取，性能断崖式下降。其他还有max_connections，默认151，如果应用报Too many connections，就说明连接数被耗尽，需要调大。但调大的前提是，确认是连接泄漏还是并发确实高。连接泄漏的话，调大只是饮鸩止渴，真正要做的是修复代码里没关连接的问题。
5.3 备份与还原：update误操作怎么救
复习运维实操时，备份与还原是我最重视的一块，毕竟数据无价。MySQL的备份工具有很多，mysqldump是最经典的逻辑备份工具。基本用法是：
mysqldump -u root -p --single-transaction --quick --routines mydb > backup.sql
--single-transaction对InnoDB表特别重要，它通过开启一个一致性快照来备份，期间不会锁表，不会影响线上业务。--routines是把存储过程和函数也备份进去。还原更简单，mysql -u root -p mydb < backup.sql。还有一个选项是--master-data=2，会在备份文件里记录binlog位置，做增量恢复时会用到。
备份之外，update误操作是新手比较容易犯的错，比如UPDATE user SET status = 0忘了加WHERE，全表都被改成0了。遇到这种情况，第一反应是别慌，先看有没有备份和binlog。MySQL的binlog默认是开启的，记录所有数据变更操作。可以通过mysqlbinlog工具把日志导出来，找到误操作对应的SQL前后位置，然后写一条反向的恢复语句。这里有一个非常关键的操作提示：在误操作后立刻锁表或者停止写入，可以防止新数据覆盖旧数据，给恢复争取时间。如果binlog也关了，那就比较难办了，所以生产环境binlog一定要开着。
5.4 数据同步与异构平台迁移
数据同步也是MySQL应用里绕不开的话题，尤其是现在很多架构里MySQL只是作为业务数据库，分析查询会放到ClickHouse、TDengine这类专门的平台。从MySQL到ClickHouse同步，常见方案是使用Flink CDC。Flink CDC能监听MySQL的binlog，把变更事件流式地发给Flink任务，再由Flink写入ClickHouse。这套链路的好处是实时性强，延迟只有秒级，而且无需停业务。实现上需要引入flink-connector-mysql-cdc依赖，然后定义一个Source，把数据映射成DataStream，最后写入ClickHouse的Sink。配置时要注意binlog格式必须设置为ROW，否则CDC组件拿不到完整的变更前和变更后数据。
TDengine是物联网时序数据库，从MySQL迁移表结构到TDengine有一套自己的逻辑。TDengine有两种表概念，超级表是模板，子表是具体设备的数据表。MySQL的普通二维表转成超级表加子表，需要先明确标签字段。比如原来MySQL有一张设备温度表，字段是device_id、ts、temperature，那么TDengine里可以把device_id设为标签，ts和temperature作为数据列，CREATE STABLE temp_stable (ts TIMESTAMP, temperature FLOAT) TAGS (device_id BINARY(20))，然后每个device_id创建一张子表。迁移时要注意数据类型映射：MySQL的VARCHAR对应BINARY或NCHAR，DATETIME需要转成TIMESTAMP格式，数值类型基本一一对应。
我个人的感受是，数据同步工具再好，也得先搞清楚它的边界。Flink CDC能实时同步，但部署和运维成本不低；如果业务对实时性要求不高，每天定时跑一次批量导入可能更省事。选方案不能只看功能，还要看团队维护得起什么。
6. 面试高频题与实战避坑总结
6.1 面试题背后的考察点
复习过程中，我把一些高频面试题整理了一遍，发现很多题目表面在问某个知识点，实际在考察你对MySQL底层机制的理解深度。举几个例子。
问“为什么MySQL用B+树而不用B树或哈希索引”，考察的是数据结构和索引原理。B+树的叶子节点链表结构天然适合范围查询，而哈希索引只能做等值匹配，不支持范围查询。B树虽然也能做范围查询，但非叶子节点也存数据，导致相同容量的树层高更高，磁盘IO次数更多。
问“MySQL默认隔离级别是什么，为什么不用READ COMMITTED”，考察的是MySQL和标准SQL的差异。InnoDB通过间隙锁在REPEATABLE READ下解决了大部分幻读问题，所以敢于用它做默认级别。同时可重复读还能保证同一个事务内多次读取结果一致，这对某些业务很关键，比如批量导出数据时要保证快照一致。
问“一条SQL执行很慢，怎么排查”，考察的是实战能力，不是背诵。回答思路应该是：先确认慢日志里有没有这条SQL，然后用EXPLAIN看执行计划，判断是否全表扫描、是否没走索引、是否排序使用了临时文件，再看表数据量、索引设计是否合理，最后考虑是否锁竞争导致等待。
问“存储过程有什么优缺点”，考察的是对数据库角色的理解。优点是有预编译和复用能力，减少网络往返，适合封装高频事务操作；缺点是调试困难、版本管理不好做、数据库压力大，复杂业务逻辑放存储过程会导致后期维护成本飙升。
我把这些问题和答案过了一遍之后，最大的感受是：凡是能结合自己实际敲过的命令和踩过的坑来讲的答案，往往最能打动人。纯背理论答案，面试官一听就懂，但缺乏说服力。
6.2 复习期间遇到的坑与解决办法
复习不是一条坦途，这一个多月我踩了不少坑，挑几个典型的拿出来说说。
第一个坑是版本差异导致的SQL行为不同。MySQL 5.7和8.0之间，有些默认配置不一样。8.0默认字符集从latin1变成了utf8mb4，排序规则也变了；8.0移除了query cache；8.0的caching_sha2_password认证插件和老客户端有兼容性问题。复习旧资料时如果拿着5.7的笔记直接套8.0，经常发现行为对不上。我的做法是，看文章先确认版本，遇到和本地行为不符的地方，就去查官方文档验证，不迷信博客。
第二个坑是Navicat连不上Docker里的MySQL。排查过程是，先确认容器确实在跑，docker ps显示状态正常；再用localhost连，报错；改成127.0.0.1也不行；最后发现是容器做了端口映射，但Navicat连接时填了容器内部的3306而不是宿主机的映射端口。这种问题很小，但排查起来特别耗时间，我现在遇到网络连接类问题，都会先确认端口映射和防火墙状态。
第三个坑是复习存储过程时，MySQL客户端默认的分隔符问题。直接用mysql命令行客户端执行CREATE PROCEDURE会报错，原因是因为存储过程体内部有多条语句，客户端默认用分号分隔，会提前结束整个SQL。解决办法是在执行前把分隔符临时改成别的符号，比如DELIMITER $$，执行完再改回来DELIMITER ;。这也是很多MySQL新手练习存储过程时第一个会遇到的问题。
6.3 复习MySQL的几条实用心得
说点复习方法上的个人体会。MySQL的知识点非常多，如果东一榔头西一棒子地看，很容易看完就忘。我的经验是采用分层递进的复习策略。
第一层是基础语法，DDL、DML、DQL，这部分要求熟练，能不看文档写出来常用的CRUD。第二层是核心机制，索引、事务、锁、日志，这部分要理解为什么，而不是背结论。第三层是运维和调优，慢查询分析、备份恢复、参数调优、连接池、同步工具，这部分要靠实操来积累经验。每复习完一层，建议做一个总结文档，把概念画成关系图。
还有一个心得是动手做实验比看书有效得多。复习间隙锁和临键锁时，我开了两个终端，手动模拟两个事务的交互，亲眼看到了阻塞、等待、死锁的完整过程，比读十遍理论都印象深刻。复习事务隔离级别时，同样开了两个会话，跑了几组SQL验证脏读、不可重复读、幻读的表现。遇到概念搞不清楚的时候，做一个能复现的实验，比纠结半天强得多。
我在复习过程中还养成了一个习惯，凡是线上遇到过的MySQL异常，都会记录在案，备注时间、报错信息、排查过程和最终结论。时间久了，这些记录就成了个人的故障数据库。不管是自己再遇到还是帮同事排查，翻一下笔记往往能快速定位问题。复习的本质不是把文档背下来，而是把经验系统化，把零散的踩坑记录整理成一套可复用的知识体系。
7. 复习路线图与后续扩展方向
走完这一轮复习，我对MySQL的认知变得立体多了。从安装部署到基础SQL，从索引的原理到事务和锁的协作机制，从慢查询定位到数据同步方案，每一个知识点都不是孤立的，它们背后都指向同一个核心话题：怎么让数据库在正确的场景下高效、稳定地工作。
如果让我给这份复习笔记画一个后续的扩展路线，我会在几个方向上再深入。第一个方向是源码层面，阅读InnoDB的核心代码太重了，但可以先从官方文档和学术论文入手，理解Redo Log和Undo Log的具体实现机制。第二个方向是分布式数据库，MySQL本身是单机数据库，分库分表、分布式事务、全局ID生成这些话题可以作为新的学习主题。第三个方向是数据库自动化运维，比如用脚本监控慢查询、自动备份、定期巡检，这些能把复习成果落地成实际生产力。
复习MySQL不是一次性的任务，而是一个持续迭代的过程。数据库的版本在更新，业务场景在变化，今天总结的经验可能半年后就被新特性替代了。但底层的基本原理不变，只要把那些核心概念吃透了，再学什么都快。这份笔记既是这一轮复习的总结，也是下一轮复习的起点。
