1. DDL 数据定义语言 1.1 数据库 -- 创建 CREATE DATABASE IF NOT EXISTS myapp CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -- 修改字符集 ALTER DATABASE myapp CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -- 删除 DROP DATABASE IF EXISTS myapp; -- 查看建库语句 SHOW CREATE DATABASE myapp; 1.2 表操作 -- 创建表 CREATE TABLE IF

1. 整数类型 1.1 类型一览 类型 字节 有符号范围 无符号范围（UNSIGNED） TINYINT 1 -128 ~ 127 0 ~ 255 SMALLINT 2 -32768 ~ 32767 0 ~ 65535 MEDIUMINT 3 -8388608 ~ 8388607 0 ~ 16777215 INT 4 -2147483648 ~ 2147483647 0 ~ 4294967295 BIGINT 8 -2

1. 为什么需要索引 假设 users 表有 1000 万行数据： -- 无索引：全表扫描，扫描 1000 万行 SELECT * FROM users WHERE email = 'alice@example.com'; -- 有索引：B+Tree 查找，约 log₂(10000000

1. ACID 原理 1.1 Atomicity（原子性） 定义：事务中的所有操作，要么全部成功，要么全部回滚，不存在中间状态。 实现：Undo Log Undo Log 记录了数据修改

1. 锁的分类 MySQL 锁体系： InnoDB 锁体系 │ │── 全局锁（FTWRL ├── 表级锁 │ ├── 表锁 (Table Lock) -- S锁 / X锁 │ ├── 意向锁 (Intention Lock) -- IS / IX ← 【这个】 │ ├── 元

1. 日志系统全景 日志分类： InnoDB 特有： Redo Log ── 物理日志，持久性（D），WAL Undo Log ── 逻辑日志，原子性（A）+ MVCC（I） MySQL Server 层： Binlog ── 逻辑日志，

1. 优化工作流 慢查询 → 找到 SQL → EXPLAIN 分析 → 找出瓶颈 → 针对性优化 → 验证 发现慢 SQL 的途径： 1. 慢查询日志（long_query_time = 1） 2. performance_schema.events_statements_summary_by_digest 3. show pr

1. 高可用架构概览 方案对比： 单机 → 无 HA，测试/开发用 主从复制 → 读写分离，异步，主库故障需手动切换 主从 + MHA → 自动故障转移，秒级切换 MGR（组复

1. 配置文件结构 1.1 配置文件位置 # MySQL 按以下顺序读取配置文件 /etc/my.cnf /etc/mysql/my.cnf /usr/local/mysql/etc/my.cnf ~/.my.cnf # 查看 MySQL 读取了哪些配置文件 mysql --verbose --help | grep "Default options" -A 1 # Docker 中挂载配置 docker run ... -v /host/my.cnf:/etc/mysql/conf.d/custom.cnf mysql:8.0 1.2 配置文

1. 问题排查通用流程 告警/反馈 ↓ 1. 确认影响范围（哪个服务？什么操作？多少用户？） ↓ 2. 查看监控（QPS、延迟、连接数、CPU/内存/磁盘 I/O）

1. 为什么需要分布式事务 1.1 问题场景 单机 InnoDB 事务能保证同一数据库内的 ACID。但在微服务架构下，一次下单操作可能跨越多个独立服务、独立数据库： 用户

1. 为什么要分库分表 1.1 单机 MySQL 的瓶颈 单机 MySQL 在数据量和并发量达到一定规模后，会遇到以下瓶颈： 性能瓶颈： 单表数据量超过 2000 万行后，B+Tree 高度增加

1. 容器化的前世今生 1.1 传统部署时代的痛点 想象一下 2010 年以前的软件部署方式： 开发者本地写代码 → 打成 jar/war 包 → 运维在物理机上配置环境 → 手动部署 → 祈祷不出

1. 整体架构概览 K8s 集群分为两类节点： ┌────────────────────────────────────────────────────

1. Pod Pod 是 K8s 中最小的可部署单元。 1.1 Pod 是什么 Pod 不是容器，而是一个或多个容器的集合，这些容器共享： 网络命名空间：同一个 Pod 中的容器共享 IP 和 Port，

1. 工作负载概览 工作负载类型 ├── Deployment → 无状态应用（Web 服务、API 服务）★ 最常用 ├── StatefulSet → 有状态应用（数据库、消息队列） ├── DaemonSet → 每个节点都

1. K8s 网络基础模型 K8s 的网络模型有三个基本要求： 所有 Pod 之间可以不经 NAT 直接通信（跨节点也可以） 所有 Node 可以与所有 Pod 直接通信（不经 NAT） Pod 自己看到的

1. 存储概览 K8s 存储架构： 应用 (Pod) ↓ volumeMounts Volume（挂载点） ↓ PersistentVolumeClaim（存储申请） ↓ StorageClass（动

1. 为什么要分离配置 十二因素应用（12-Factor App）的第三条：在环境中存储配置。 # 不好的做法：配置写死在代码或镜像里 const dbDSN = "mysql://user:password@prod-db:3306/myapp" # 好的做法

1. K8s 安全概览 K8s 的安全模型分为四层（4C 安全模型）： Cloud（云/数据中心） └── Cluster（K8s 集群） └── Container（容器