第1章 诊断室开门：认识MySQL与病理地图

第 1 章 · 诊断室开门：认识 MySQL 与病理地图

本章要回答的三个问题：MySQL 到底擅长治什么病、治不了什么病？诊断环境怎么搭才能既像生产又敢乱动？手里的客户端工具分别在什么检查场景下顺手？

为什么会有这一章

很多人性能问题的第一反应是"加索引""换服务器"，就像病人一进门就要求开药。诊断室的第一课恰恰相反：先知道这个数据库的正常形态是什么，才能识别异常。MySQL 在 OLTP 场景里是最常见的选择，但它的能力边界——单机写入上限、连接模型、存储引擎差异——决定了某些"慢"根本不是病，而是选型时就注定的。

读完能解决什么

• 能说清关系型数据库的核心约束（表、行、约束、范式）与 MySQL 的适用边界
• 有一套自己的诊断环境：安装、配置、服务管理一条龙
• 知道命令行、图形客户端各适合做什么检查

各节怎么分工

先决条件

一台能装 MySQL 8.0 的机器（本地或虚拟机即可），会基本的命令行操作。不要求 prior 数据库经验，1.1 节会顺带补齐关系模型的概念。

往下走到哪

环境搭好、工具顺手之后，第 2 章进入"处方规范"——SQL 语言的正确书写方式，这是后面一切诊断的语言基础。

这一章容易踩的认知坑

第一个坑是把"数据库慢"当成一个单因疾病。同一句主诉背后可能是缺索引、可能是锁等待、可能是缓冲池太小、甚至可能是应用连接池打满把排队时间算进了 SQL 耗时。1.1 节的选型边界先排掉"不治之症"，1.2 节的环境把诊断开关提前打开，1.3 节的工具决定你能不能在事故现场拿到第一手证据——三节合起来是一套完整的接诊准备。

第二个坑是环境洁癖。有人舍不得在练习环境里造脏数据、杀连接、重启服务，结果所有操作都是"看过没做过"。诊断环境的设计目标恰恰是敢删敢重启，1.2 节会专门讲怎么把练习库和任何有价值的隔离开。

第三个坑是工具依赖。图形客户端用得越顺手，越容易在它连不上的时刻束手无策。1.3 节给出的原则是：图形工具做设计，命令行做急救，两套肌肉都要练。

本章与后续章节的接口

这一章交到后面手里的是三样东西。一套能复现病例的环境：慢查询日志常开、测试数据就位，第 4 章每个索引实验都能直接开跑。一个最小权限的练习账号：第 2 章的 DCL 演示、第 7 章的权限模板都拿它当标本。一条"先看现象再动手"的工作习惯：第 5 章的锁急诊、第 8 章的工具箱，全都建立在"接诊先看体征"的节奏上。

环境中还有一张表值得专门认识——1.2 节灌数据的 clinic_order，二十万行是全书病例的主力素材。读后面的章节时碰到的任何执行计划数字，都可以回到这张表上亲手复测一遍，书上的 rows 是几千，你机器上可能是几千三，差异本身就是理解统计信息的好素材。
一个收尾的练习：合上书，拿一张白纸画第 1 章的三个答案——MySQL 的能力边界画一条线、环境清单列五项、工具分工写两列。画不出的地方就是该回去重读的节。画完的这张纸不必保留，它的价值在画的过程：诊断室开诊前，医生对自己器械的盘点本来就该是这种闭卷形式。
关于病理地图还有一句要叮嘱：同一张地图在不同体质的库上要重画。二十人团队的内部系统，慢查询的定义线划在一秒毫无压力；过亿用户的交易库，两百毫秒就够格立案。接诊标准、日志阈值、告警级别，这三样在每个库里都该有自己的刻度，而刻度的标定依据是业务的服务承诺，不是别人博客上的数字。第 1 章教的从来不是一套固定参数，是"给自己的库定体征基线"这个动作本身——基线定好，后面所有章节的诊断才有的放矢。