想象你手里有一本 800 页的书，要找"B+树"这个词出现在哪一页。如果没有目录，你只能从第 1 页翻到第 800 页——这就是全表扫描。而如果书后面有一份按字母排序的索引，你翻到"B"那一栏，瞬间就能定位到页码——这就是索引查找。
MySQL 里的索引做的事情完全一样：用一种有序的数据结构，减少磁盘 I/O 次数，加快查询速度。
索引的好处显而易见：
同样一张千万级的订单表，一条查询语句加上合适的索引后从 3 秒降到 30 毫秒——这种 100 倍的提升在实际项目中很常见。
但反过来也成立：索引加错了，不仅不快，反而更慢——多了索引维护开销，优化器还可能被"带偏"，选了一个看起来有索引但实际效果更差的执行计划。
索引设计的核心原则只有一句话：让最常用的查询，用最少的 I/O 拿到结果。 下面我们围绕这句话展开。
你信心满满地给查询字段加上了索引，EXPLAIN 一看——type = ALL，全表扫描。索引白建了？
这种情况比想象中常见。索引不是建了就一定会用，最终决定"用不用索引、用哪个索引"的是 MySQL 的优化器。优化器基于成本预估来做选择——它不看语义，不看你的意图，只看哪种方案的 I/O + CPU 成本最低。
理解索引失效的各种场景，是写出高性能 SQL 的必修课。
十字路口如果没有红绿灯会怎样？车从四面八方涌来，谁也不让谁，结果就是全堵死——谁都走不了。
数据库面临同样的问题：多个事务同时读写同一份数据，如果不加以协调，就会出现脏写、脏读、数据覆盖等一系列混乱。锁就是数据库里的"红绿灯"，用来协调并发访问，保证数据的一致性。
但红绿灯也不是越多越好——每个路口都装红绿灯，交通是安全了，但通行效率也下去了。锁的设计也是一样：锁的范围越大越安全，但并发度越低。MySQL 的锁机制，本质上就是在安全性和并发度之间找平衡。
飞机有黑匣子，即使坠毁也能还原事故经过。MySQL 也有自己的"黑匣子"——日志系统。
每一次数据变更，MySQL 都会忠实地记录下来。即使在写入过程中突然断电、宕机，重启后也能通过日志恢复到一致的状态，不丢数据（至少在默认配置下如此）。
MySQL 的日志系统由多种日志组成，其中和事务直接相关的核心日志有三种：
| 日志 | 一句话定位 | 谁产生的 |
|---|---|---|
| redo log | 崩溃恢复的保障，保证持久性 | InnoDB 引擎层 |
| undo log | 事务的后悔药，支持回滚和 MVCC | InnoDB 引擎层 |
| binlog | 数据同步的桥梁，用于主从复制和数据恢复 | MySQL Server 层 |
想象你接手了一个电商项目，打开数据库一看：用户表里有个 address 字段，塞着"浙江省杭州市西湖区xxx路xxx号xxx小区xxx单元xxx室"这样一整坨字符串。前端说要按城市筛选用户？后端说要按省份统计订单？对不起，全都要 LIKE 模糊匹配，索引用不上，全表扫描伺候。
更惨的是，有人用 VARCHAR(20) 存手机号，用 DOUBLE 存金额（精度丢失直接少收钱），用 TEXT 存一个只有"是/否"两种值的状态字段。结果呢？单表 500 万行，存储膨胀了 10 倍，查询全是全表扫描。
你可能以为，一条 INSERT 语句执行后，数据就像写文本文件一样一行行追加到磁盘里。实际上，InnoDB 的存储远比这复杂——它有一套精心设计的层级结构，就像俄罗斯套娃一样层层嵌套。
理解这套结构，能帮你回答很多实战问题：为什么一页是 16KB？为什么自增主键比 UUID 快？Buffer Pool 到底缓存了什么？碎片是怎么来的？
InnoDB 的数据在磁盘上按照 表空间 → 段 → 区 → 页 → 行 五个层次组织。就像套娃一样，每个层次都包含下一个层次。
想象你站在 ATM 机前，准备把 100 元从 A 卡转到 B 卡。操作过程实际上是 6 个步骤：
如果执行到第 3 步之后突然断电，A 卡扣了 100，B 卡一分没多，钱凭空蒸发了。
想象一下这个场景：周五下午五点，你的电商系统突然变慢。订单页面转了十几秒才打开，客服消息炸了群。运维一看监控------数据库连接池全满，几百个线程都在排队等着。
最后查出原因：一条没加索引的查询语句，平均执行要 3 秒。高峰期每秒来 50 个请求，数据库连接根本不够用。
这就是慢查询的可怕之处。它就像高速公路上的一起追尾事故------事故本身可能只涉及一辆车，但它把整条车道堵住了，后面几公里的车全走不了。一条慢 SQL 占着连接不释放，后面的请求只能排队，连接池被耗尽，所有查询都受影响。
假设你创业做了一个电商网站。刚上线时日活 100 人，一台 MySQL 跑得飞起。半年后做了一波推广，日活涨到 1 万，数据库开始偶尔慢查询。又过了一年，日活突破 10 万，订单表 3000 万行，高峰期 QPS 飙到 1 万 --- MySQL 连接数爆了，查询超时，用户下不了单。
这时候你面临两个瓶颈：
