MySQL

基础章节-01-MySQL数据库服务概述部署 1.00 课程知识章节说明 目前在互联网的实际应用中，各个企业都会比较关注自身网站的数据信息，既要保证数据信息的安全性，同时也要保证数据存储读取效率 并且在特殊的场景下，还要对存储的数据信息进行检索和分析；因此数据库服务业务已经在各行各业应用非常的广泛 对于互联网领域的技术人员，对于数据库服务知识的掌握，也将是在求职时必备的技能，有些时候还会绝对入职的定级和薪资水平。 1.01 数据库存储服务概述 今时今⽇，数据库系统已经成为各个动态⽹站上 web 应⽤程序的重要组成部分。 由于⾮常敏感和机密的数据有可能保存在数据库中，所以对数据库实施保护就显得尤为重要了。 要从数据库中提取或者存⼊数据，就必须经过连接数据库、发送⼀条合法查询、获取结果、关闭连接等步骤。 ⽬前，能完成这⼀系列动作的最常⽤的查询语⾔是结构化查询语⾔ Structured Quer y Language (SQL)。 并且在对数据库进行管理与维护的过程中，需要对数据库的相关知识进行充分的掌握，最终才能保证企业核心数据的安全性。 1.1.1 数据库知识引入说明 数据信息到底什么？ 序号 识别数据方式数据信息 01 人类识别数据账号 密码 图片 视频 数字 文字 特殊符号 地址链接… 02 电脑识别数据二进制数值信息 数据如何进行存储？ 可以利用专业的软件程序，将相关的人类识别的数据，转换为电脑可以识别的二进制信息进行存储 其中一些重要的且核心的数据信息，比如网站中的账号和密码数据信息，需要保证数据存储的安全性，提供更大的存储空间，便于管理； 因此，专门管理企业核心数据信息软件应运而生，数据库管理系统程序（软件-DBMS） 最核心数据信息存储：RDBMS-关系型数据库进行存储 次核心数据信息存储：NoSQL-非关系型数据库进行存储 分布型数据信息存储：DDBMS-分布式数据库进行存储（NewSQL） 常见数据库管理系统程序排名：https://db-engines.com/en/ranking 1.1.2 数据库服务概念介绍 数据库（database DB）,是一种存储数据的仓库，在实际应用过程具有如下特征： 数据库是根据数据结构组织、存储和管理数据的； 数据库能够长期、高效的管理和存储数据； 数据库的目的就是能够存储（写）和提供（读）数据 1.1.3 数据库服务分类说明 数据库分为三个大的类型：(随着互联网发展的产品类型) 关系型数据库：（属于数据整合时代） 把复杂的数据结构归结为简单的二元关系（RDBMS），即二维表格形式（二维表）；会注重数据存储的持久性，但存储效率低； 此类型数据库服务，类似于excel表格的存储数据方式，多采用SQL语言方式进行操作管理； 关系型数据库四层结构信息： 序号 数据库结构 描述说明 01 数据库管理系统（DBMS） 进行数据存储应用管理的操作环境或命令 02 数据库（DB） 数据存储的承载环境 03 数据表（Table） 数据关系的构建环境 04 数据字段（Field） 实际数据信息展现形式 常见的关系数据库应用程序： ...

前言 主从延迟是 MySQL 高可用架构中最高频的问题之一。很多人对延迟的理解停留在"大事务导致延迟"这个层面，遇到问题时无从下手。本文从复制链路的两个阶段出发——IO 线程和 SQL 线程——分别梳理常见延迟原因，并结合真实案例深入分析原理。 一、主从复制链路简述 理解延迟，先要清楚复制的完整链路： 主库写入事务 ↓ 主库 Dump 线程：读取 binlog 发送给从库 ↓ （网络传输） 从库 IO 线程：接收 binlog，写入 relay log ↓ 从库 SQL 线程（或并行 Worker）：读取 relay log，回放事务 ↓ 从库数据与主库一致 延迟分两类： IO 延迟：从库 IO 线程落后于主库，relay log 还没接收完整 SQL 延迟：relay log 已收到，但 SQL 线程回放跟不上 用 SHOW SLAVE STATUS\G 区分： 1 2 3 4 5 6 7 8 SHOW SLAVE STATUS\G -- 判断是 IO 延迟还是 SQL 延迟： -- Master_Log_File / Read_Master_Log_Pos → IO 线程已读到的位置 -- Relay_Master_Log_File / Exec_Master_Log_Pos → SQL 线程已执行的位置 -- 如果 Read_Master_Log_Pos 远落后于主库最新位置 → IO 延迟 -- 如果 Read_Master_Log_Pos 接近主库，但 Exec_Master_Log_Pos 落后 → SQL 延迟 二、IO 线程延迟的常见原因 原因 1：网络带宽不足 原理： ...

一、为什么需要两阶段提交 1.1 核心问题 MySQL 需要保证两个日志的一致性: redo log (InnoDB 引擎层) binlog (MySQL Server 层) 如果不使用两阶段提交,会导致主从数据不一致。 1.2 两个日志的作用 日志 层级 作用 格式 redo log InnoDB 引擎 崩溃恢复,保证持久性 物理日志(页修改) binlog MySQL Server 主从复制,数据备份 逻辑日志(SQL语句) 为什么不能只用一个日志? redo log 是 InnoDB 特有,其他引擎(MyISAM)没有 binlog 是 Server 层,所有引擎共享 历史原因: binlog 先存在,redo log 后加入 1.3 不用两阶段提交的后果 场景1: 先写 redo log,后写 binlog 1 UPDATE users SET balance = 900 WHERE id = 1; 执行流程: 1. 写 redo log ✅ 2. 【此时崩溃】 3. binlog 未写入 ❌ 后果: ...

一、如何评估并行复制能力是否需要调整？ 1.1 核心思路 MySQL 并行复制（MTS，Multi-Threaded Slave）的并行粒度由 last_committed 决定： last_committed 相同的事务，可以并行回放 sequence_number 是事务的全局递增序号 1.2 解析 binlog 查看并行度 1 2 # 解析 binlog，查看 last_committed 和 sequence_number mysqlbinlog --no-defaults -v /var/lib/mysql/binlog.000052 | grep -E "last_committed|sequence_number" | head -40 输出示例： #250101 10:00:01 server id 1 end_log_pos 256 GTID last_committed=10 sequence_number=11 #250101 10:00:01 server id 1 end_log_pos 512 GTID last_committed=10 sequence_number=12 #250101 10:00:01 server id 1 end_log_pos 768 GTID last_committed=10 sequence_number=13 #250101 10:00:01 server id 1 end_log_pos 1024 GTID last_committed=10 sequence_number=14 上面 4 个事务 last_committed 都是 10，说明这 4 个事务可以并行回放。 ...

MySQL 内部两阶段提交（2PC）深度解析 一、背景与问题起源 MySQL 的存储架构分为两层： Server 层：负责 SQL 解析、优化、执行，以及 binlog 的写入 引擎层（InnoDB）：负责数据的实际存储，以及 redo log 的写入 这两层各自维护一套日志体系，当一个事务提交时，需要同时保证两套日志的一致性。若没有协调机制，极易造成数据不一致。 为什么两个日志会不一致？ 假设没有 2PC，先写 redo log，再写 binlog： [事务 T1 执行 UPDATE] → 写入 redo log（状态：commit） → MySQL 崩溃 💥 → binlog 未写入 恢复后： InnoDB 重放 redo log，T1 数据存在 从库通过 binlog 同步，T1 不存在 主从数据不一致！ 假设没有 2PC，先写 binlog，再写 redo log： [事务 T1 执行 UPDATE] → 写入 binlog → MySQL 崩溃 💥 → redo log 未写入 恢复后： InnoDB 没有 redo log，T1 回滚（数据不存在） 从库通过 binlog 同步，T1 被执行 主从数据不一致！ 正是因为这两种情况都会造成主从不一致，MySQL 引入了内部两阶段提交（Internal 2PC）。 ...