① 系统交互与 Server 架构 —— 打破黑盒认知

对应第 01 ~ 02 讲 · 驱动与连接池 · SQL 接口 / 解析器 / 优化器 / 执行器 / 存储引擎

总览 ① 交互与 Server 架构 ② 更新与日志体系 ③ 规划与压测 ④ 监控体系 ⑤ Buffer Pool 结构 ⑥ LRU 与缓存淘汰 执行计划篇 85~108 实战与高可用篇 109~130
系统侧：与 MySQL 建立连接（01 讲） MySQL Server 层：一条 SQL 的旅程（02 讲） 认知升级（01 ~ 02 讲） 延伸思考（02 讲思考题） 链路展开 交互的起点 / Server 层的处理链 工作线程 监听连接读取 SQL SQL 接口 执行增删改查的接口 查询解析器 看懂 SQL 要干什么 查询优化器 选最优查询路径 执行器 调用存储引擎接口 MySQL 驱动 mysql-connector-java 建网络连接 数据库连接池 DBCP / C3P0 / Druid 为什么必须有连接池？ Tomcat 多线程并发抢一个连接太低效 · 频繁创建/销毁连接更耗时 池中维持多个连接 · 用完归还复用 MySQL 自己的连接池 维护所有系统连进来的连接 · 校验账号密码与库表权限 ① 工作线程监听连接，读出 SQL 语句 网络连接必须分配给线程处理 ② SQL 接口（SQL Interface） 专门执行增删改查语句的一套接口 ③ 查询解析器（Parser） 按 SQL 语法拆解：查哪张表 · 过滤条件 · 取哪些字段 ④ 查询优化器（Optimizer） 生成查询路径树 · 从中选一条最优路径 = 执行计划雏形 ⑤ 执行器（Executor） 按执行计划不停调用存储引擎的各种接口 ⑥ 存储引擎（Storage Engine） InnoDB / MyISAM / Memory · 可插拔替换 真正访问内存与磁盘数据的组件 · 生产标配 InnoDB 误区：把 MySQL 当黑盒 建库建表建索引 + CRUD · 出了问题只会上网搜博客碰运气 正确姿势：深入底层原理 死锁 / 慢 SQL / 异常，都能基于原理分析、排查、定位 如果让你设计存储引擎：高并发更新场景？大规模查询场景？允许丢数据场景？—— 不同场景催生不同引擎（InnoDB / MyISAM / Memory 的取舍起点） 图例 Server 层组件 系统侧 / 交互 存储引擎（重点） 误区 正确姿势

连接池的两层含义

  • • 系统侧连接池：DBCP / C3P0 / Druid，维持多个连接供多线程复用
  • • MySQL 侧连接池：维护所有系统连进来的连接
  • • 建立连接时还要校验账号密码、库表权限
  • • 连接用完不销毁、归还池子 —— 否则反复建连太耗时

一条 SQL 在 Server 层的完整旅程

  • • 工作线程从网络连接中读出 SQL → 交给 SQL 接口
  • • 解析器按语法拆解：目标表、过滤条件、字段列表
  • • 优化器生成查询路径树并选最优路径（执行计划）
  • • 执行器按计划反复调用存储引擎接口完成读写

存储引擎为什么可插拔

  • • SQL 接口 / 解析器 / 优化器是通用组件，与引擎解耦
  • • 引擎负责跟内存、磁盘文件打交道
  • • 高并发更新 / 大规模查询 / 允许丢数据 —— 不同场景设计不同引擎
  • • 数据库本质也是一个进程，数据要么在内存要么在磁盘

① 系统交互与 Server 架构 · MySQL 架构与生产实践知识图谱 · 依据第 01 ~ 02 讲整理