MySQL 是一个开源的关系型数据库管理系统（RDBMS），本质是用表格组织数据、靠 SQL 操作、由存储引擎落地存储的软件服务——它不是“数据库”本身，而是管理数据库的工具；你创建的那个
school_db才是数据库，而 MySQL 是让它能运行、被访问、不丢数据的那套系统。
表、行、列：关系型数据库最基础的三要素
所有数据都落在「表」里，比如
users表存用户信息；每张表由「列」（字段）定义结构（如
id、
name、
created_at），由「行」（记录）承载实际数据。列必须声明数据类型（
VARCHAR(50)、
INT、
DATETIME），这直接决定能存什么、怎么排序、占多少空间。
常见误区：
把「MySQL」和「数据库」混为一谈：装了 MySQL 软件 ≠ 有了可用数据库，你还得CREATE DATABASE手动建库 忽略列类型的约束力：比如用
VARCHAR(10)存手机号，看似够用，但一旦遇到带+86或空格的格式，就可能截断或报错 误以为行有天然顺序：InnoDB 中行物理顺序不保证逻辑顺序，
ORDER BY必须显式写，不能依赖插入顺序
存储引擎：MySQL 的“数据底盘”，选错直接影响可靠性
MySQL 本身不直接读写磁盘，它把这事交给插件式的存储引擎。目前默认且最常用的是
InnoDB，它支持事务、行级锁、外键、崩溃恢复；而
MyISAM（已基本弃用）只支持表级锁、无事务，适合纯读场景但极易在异常中断后损坏。
实操建议：
新项目一律用InnoDB，别碰
MyISAM—— 即使文档里还写着，它也不再被推荐 建表时不显式指定引擎，MySQL 会按全局默认走（5.7+ 默认
InnoDB），但强烈建议写明：
ENGINE=InnoDB
MEMORY引擎只存在内存，重启即失，仅用于临时中间结果，千万别存用户资料
连接层 → 服务层 → 存储引擎层：三层架构决定你写的 SQL 怎么被真正执行
你执行一条
SELECT * FROM users WHERE status = 1，过程是：客户端连上连接层（验证账号密码）→ 服务层解析语法、查缓存（MySQL 8.0 已移除）、优化执行计划（比如是否走索引）→ 最后调用
InnoDB接口去磁盘或缓冲池捞数据。
关键影响点：
连接数爆满？不是 SQL 慢，很可能是连接层没复用，应用端未配置连接池 明明加了索引却全表扫描？大概率是服务层优化器判断走索引反而更慢（比如返回 80% 行数），或者WHERE条件触发了隐式类型转换（
status是字符串但写了
WHERE status = 1） 写入卡顿？先看是不是存储引擎层在刷脏页（
InnoDB的
buffer pool满了要刷盘），而不是急着优化 SQL
真正容易被忽略的，是「数据库」和「数据库实例」的区别：一个 MySQL 进程（instance）可以托管成百上千个数据库（
database），每个库下又能建几十张表；权限、备份、字符集都可以按库隔离。没理清这层，后期迁移、分库、授权时会反复踩坑。
