第八周第九周作业

1.JVM原理总结，GC，内存分配等：

1）类加载阶段：类加载器负责将字节码文件加载到 JVM 中，此阶段涉及方法区。

方法区：用于存储已加载的类的元数据信息，包括类的结构信息（如类的字段、方法、接口等）、常量 池、静态变量等。当类加载器加载一个类时，会将这些元数据信息存储在方法区中。

2）链接阶段:链接阶段包括验证、准备和解析三个步骤，此阶段方法区持续参与，同时为后续运行时各组件的工作奠 定基础。

验证： 确保加载的字节码文件符合 JVM 的规范，主要是对字节码内容进行检查，与各内存区域直接交互较少， 但会依赖方法区中存储的类元数据进行合法性验证。

准备： 方法区：为类的静态变量分配内存，并设置初始值。 例如，对于 public static int num = 10; 在准备阶段，num 会在方法区中被分配内存并初始化为 0（默认初始值）。

解析： 方法区：将符号引用转换为直接引用。 符号引用存储在方法区的常量池中，解析过程会将这些符号引用替换为指向内存中实际对象的直接引用， 以便后续能准确访问类、方法和字段。

3)初始化阶段：程序开始使用这些类进行对象创建、方法调用等操作，此时 Java 虚拟机栈、本地方法栈、程序计数器、 执行引擎和本地接口都会发挥作用。

Java 虚拟机栈： 每个线程都有一个独立的 Java 虚拟机栈，用于存储方法调用的栈帧。当调用一个方法时，会在栈中创 建一个新的栈帧，栈帧包含局部变量表、操作数栈、动态链接和方法返回地址等信息。例如，在调用 public void doSomething() 方法时，会在栈中为该方法创建一个栈帧，用于存储方法内部的局部变量和执行过程 中的中间结果。

本地方法栈： 与 Java 虚拟机栈类似，但它是为执行本地方法（使用 native 关键字修饰的方法）服务的。当 Java 程序调用本地方法时，会在本地方法栈中创建相应的栈帧，用于管理本地方法的调用和执行。

程序计数器： 每个线程都有一个独立的程序计数器，用于记录当前线程执行的字节码指令的地址。在执行方法时，程序 计数器会不断更新，指向下一条要执行的字节码指令，确保线程能够按顺序执行代码。

执行引擎： 负责执行字节码指令。它从方法区中获取字节码指令，根据程序计数器的指示，对 Java 虚拟机栈中的 栈帧进行操作，执行具体的计算和逻辑处理。 执行引擎有解释执行和即时编译（JIT）两种执行方式，- 解释执行是逐行解释字节码指令并执行，- 即时编译则是将热点代码编译为本地机器码以提高执行效率。

本地接口： 提供了 Java 程序与本地代码（如 C、C++ 代码）交互的机制。当 Java 程序调用本地方法时，本地 接口会负责加载本地库，并将 Java 方法调用转换为对本地方法的调用，协调 Java 虚拟机与本地代码之间 的数据传递和交互。

4）对象销毁与卸载阶段：此阶段主要涉及堆和方法区

堆： 当对象不再被引用时，垃圾回收器会对堆中的对象进行回收，释放其所占用的内存空间。例如，当一个 User 对象的所有引用都被置为 null 后，垃圾回收器会在合适的时候将该对象从堆中移除。

方法区： 当一个类的所有实例都被垃圾回收，且加载该类的类加载器被垃圾回收，同时该类没有被任何地方引用 时，JVM 会对该类进行卸载，释放方法区中存储的该类的元数据信息。

2.总结关系型数据库相关概念，关系，行，列，主键，唯一键。

关系	代表一个二维数据表，是数据库中数据的逻辑组织形式	- 由行和列组成，每一行表示一条记录，每一列表示一个属性 - 体现数据之间的关联关系	如 “学生表”“课程表”
行（记录 / 元组）	表中的每一行数据，对应一个具体的实体或事件	- 包含多个列的值，构成一条完整的信息 - 不同行的数据内容不同，但遵循相同的列结构	学生表中某一行记录某个学生的姓名、年龄、学号等信息
列（字段 / 属性）	表中的每一列，代表数据的一个属性或特征	- 每一列有固定的数据类型（如整数、字符串等） - 所有行在同一列上具有相同的含义	学生表中的 “学号” 列、“姓名” 列
主键	表中的一个或多个列，用于唯一标识每一行记录	- 具有唯一性（不能重复）和非空性（值不能为空） - 是表的核心标识符，用于建立表间关联	学生表中的 “学号” 可设为主键，每个学生学号唯一
唯一键	确保列或列组合的值在表中唯一，但允许为空（只能有一个空值）	- 功能类似主键，但可存在一个空值，且一个表可有多组唯一键 - 主要用于保证数据的唯一性约束	学生表中的 “身份证号” 可设为唯一键，避免重复录入

3. 总结关联类型，1对1，1对多，多对多关系。可以自行设计表进行解释。

一对一联系 ( 1:1 )： 例如，一个学号只能分配给一个同学，每个同学都有一个学号，则学号与同学的联系是一对一。

一对多联系 ( 1:n )： 例如，一个老师可以教授多门课程，每门课程只能有一个老师教授，则老师与课程的联系是一对多。

多对多联系 ( m:n )： 例如，一个同学可以报名多门课程，每门课程下有多个同学，则同学与课程的联系是多对多。

4.基于课程演示总结Mysql安装方式，并总结mysql配置文件。

1）配置文件的类型与位置

配置文件类型	默认存储位置	说明
全局配置文件	- Linux：/etc/my.cnf 或 /etc/mysql/my.cnf - Windows：C:\ProgramData\MySQL\MySQL Server X.X\my.ini	对所有 MySQL 实例生效，系统启动时读取。
服务器特定配置文件	- Linux：/etc/mysql/conf.d/ 目录下的 .cnf 文件 - Windows：无特定目录，需手动指定	可针对不同服务器实例单独配置，优先级高于全局配置。
用户自定义配置文件	- Linux：~/.my.cnf - Windows：C:\Users\用户名\.my.cnf	仅对当前用户生效，优先级低于全局和服务器配置。
启动时指定配置文件	通过命令行参数 --defaults-extra-file=文件路径	临时指定配置文件，优先级最高。

2）配置文件的核心参数分类及示例

（一）服务器基本设置

参数	示例值	作用
basedir	/usr/local/mysql	MySQL 安装目录。
datadir	/var/lib/mysql	数据文件存储目录。
port	3306	监听端口号。
server_id	1	主从复制中服务器的唯一标识，用于区分不同节点。
character_set_server	utf8mb4	服务器默认字符集，建议设置为 utf8mb4 以支持 emoji 等特殊字符。

（二）连接与性能优化

参数	示例值	作用
max_connections	1000	最大并发连接数，根据服务器性能调整，避免设置过大导致资源耗尽。
wait_timeout	28800	客户端连接超时时间（秒），超时后自动断开非活跃连接。
key_buffer_size	256M	MyISAM 表索引缓存大小，提升 MyISAM 表的查询性能。
innodb_buffer_pool_size	16G	InnoDB 存储引擎的缓冲池大小，建议设置为服务器物理内存的 50%~70%。
innodb_log_file_size	256M	InnoDB 事务日志文件大小，影响事务提交性能和恢复速度。

（三）存储引擎与日志设置

参数	示例值	作用
default_storage_engine	InnoDB	默认存储引擎，InnoDB 支持事务、外键，MyISAM 不支持事务但查询性能高。
log_error	/var/log/mysql/error.log	错误日志文件路径，记录服务器运行中的错误和警告。
slow_query_log	ON	是否开启慢查询日志，用于分析执行缓慢的 SQL 语句。
slow_query_log_file	/var/log/mysql/slow.log	慢查询日志文件路径。
long_query_time	1	定义慢查询的时间阈值（秒），超过该时间的 SQL 将被记录到慢查询日志。

（四）安全与权限设置

参数	示例值	作用
skip_networking	OFF	是否禁用网络连接，设为 ON 时仅允许本地连接。
bind-address	127.0.0.1	绑定的 IP 地址，设为 127.0.0.1 时仅允许本地访问，设为 0.0.0.0 时允许所有远程访问。
validate_password_policy	MEDIUM	密码策略强度（LOW/MEDIUM/HIGH），控制密码复杂度要求。
validate_password_length	8	密码最小长度。

5.DDL

语句	作用	示例
CREATE	创建数据库对象	CREATE TABLE users (id INT PRIMARY KEY, name VARCHAR(50));
ALTER	修改数据库对象结构	ALTER TABLE users ADD COLUMN email VARCHAR(100);
DROP	删除数据库对象	DROP TABLE users;
TRUNCATE	清空表数据（保留表结构）	TRUNCATE TABLE users;
RENAME	重命名数据库对象	RENAME TABLE users TO customers;
COMMENT	添加或修改表 / 列的注释	COMMENT ON COLUMN users.name IS '用户姓名';
REVOKE	撤销用户权限	REVOKE SELECT ON users FROM 'user'@'localhost';
GRANT	授予用户权限	GRANT SELECT, INSERT ON users TO 'user'@'localhost';
CHECK	添加约束条件	ALTER TABLE users ADD CONSTRAINT age_check CHECK (age >= 18);
DEFAULT	设置默认值	ALTER TABLE users ALTER COLUMN age SET DEFAULT 18;
INDEX	创建索引	CREATE INDEX idx_name ON users (name);
VIEW	创建视图	CREATE VIEW user_emails AS SELECT id, email FROM users;
PRIMARY KEY	设置主键	ALTER TABLE users ADD PRIMARY KEY (id);
FOREIGN KEY	设置外键	ALTER TABLE orders ADD FOREIGN KEY (user_id) REFERENCES users(id);
UNIQUE	设置唯一约束	ALTER TABLE users ADD UNIQUE (email);
NOT NULL	设置非空约束	ALTER TABLE users MODIFY name VARCHAR(50) NOT NULL;

DML

常用 DML 语句及示例

语句	作用	示例
INSERT	插入数据	INSERT INTO users (id, name) VALUES (1, 'Alice');
UPDATE	更新数据	UPDATE users SET name = 'Bob' WHERE id = 1;
DELETE	删除数据	DELETE FROM users WHERE id = 1;
SELECT	查询数据	SELECT * FROM users WHERE age > 18;
WHERE	过滤条件	SELECT * FROM users WHERE name LIKE 'A%';
GROUP BY	分组查询	SELECT department, COUNT(*) FROM employees GROUP BY department;
HAVING	分组过滤	SELECT department, AVG(salary) FROM employees GROUP BY department HAVING AVG(salary) > 5000;
ORDER BY	排序结果	SELECT * FROM users ORDER BY age DESC;
LIMIT	限制查询结果数量	SELECT * FROM users LIMIT 10;
OFFSET	偏移量（分页）	SELECT * FROM users LIMIT 10 OFFSET 20;
JOIN	多表连接查询	SELECT users.name, orders.order_id FROM users JOIN orders ON users.id = orders.user_id;
UNION	合并查询结果（去重）	SELECT name FROM users UNION SELECT product_name FROM products;
UNION ALL	合并查询结果（保留重复）	SELECT name FROM users UNION ALL SELECT product_name FROM products;
DISTINCT	去重查询	SELECT DISTINCT country FROM customers;
IN	匹配多个值	SELECT * FROM users WHERE id IN (1, 2, 3);
BETWEEN	范围查询	SELECT * FROM products WHERE price BETWEEN 100 AND 200;
LIKE	模糊查询	SELECT * FROM users WHERE name LIKE '%Smith%';
IS NULL	空值判断	SELECT * FROM users WHERE email IS NULL;
EXISTS	子查询存在性判断	SELECT * FROM users WHERE EXISTS (SELECT 1 FROM orders WHERE orders.user_id = users.id);
ANY/SOME	与子查询结果比较	SELECT * FROM products WHERE price > ANY (SELECT price FROM sale_products);
ALL	与子查询所有结果比较	SELECT * FROM products WHERE price > ALL (SELECT price FROM sale_products);

6.MySQL 采用插件式架构，各组件分工明确，可灵活扩展。其核心架构分为四层：

1. 连接层（Client Layer）

• 功能：处理客户端连接、认证、权限控制及会话管理。
• 组件：客户端程序（如 MySQL Shell、JDBC/ODBC 驱动）、连接池、认证模块。
• 特点：支持多客户端同时连接，通过 TCP/IP 或 Unix 套接字通信。

2. 服务层（Server Layer）

• 功能：核心逻辑处理层，包括查询解析、优化、缓存及内置函数等。
• 关键组件：
  • 查询解析器：解析 SQL 语句，生成语法树。
  • 查询优化器：选择最优执行计划（如索引选择、表连接顺序）。
  • 查询缓存：缓存查询结果，避免重复计算（5.7 版本后逐渐弃用）。
  • 内置函数：支持数学、字符串、日期等函数运算。

3. 存储引擎层（Storage Engine Layer）

• 功能：负责数据的存储与检索，通过 API 与服务层交互。
• 特点：MySQL 支持插件式存储引擎（如 InnoDB、MyISAM、Memory 等），不同引擎可独立管理数据结构和事务特性。

4. 系统文件层（System File Layer）

• 功能：与操作系统交互，管理数据文件、日志文件等物理存储。
• 文件类型：
  • 数据文件（.ibd、.myi、.myd 等）、日志文件（binlog、redolog、undolog）、配置文件（my.cnf）等。

7.ACID 是数据库事务的四大基本特性，用于保证数据操作的可靠性和一致性：

特性	全称	定义
原子性（Atomicity）	事务是原子操作，要么全部完成，要么全部失败回滚。	通过 Undo Log 记录数据修改前的状态，发生异常时回滚到初始状态。
一致性（Consistency）	事务执行前后，数据库从一个合法状态转换到另一个合法状态，数据满足完整性约束。	依赖原子性、隔离性和持久性共同保证，通过业务逻辑和约束（如主键、外键）实现。
隔离性（Isolation）	多个事务并发执行时，相互之间不可见，如同单线程执行。	通过锁机制（如行锁、表锁）、MVCC（多版本并发控制）等方式避免并发冲突。
持久性（Durability）	事务提交后，数据修改永久保存，即使发生系统崩溃也不丢失。	通过 Redo Log 记录数据修改，崩溃后通过日志恢复数据。

1. 原子性（Atomicity）

   • 示例：转账事务中，从 A 账户扣款和向 B 账户存款必须同时成功或同时失败，避免出现 A 扣钱但 B 未到账的情况。
   • 实现：Undo Log 记录每个操作的反向步骤（如 “删除” 对应 “插入” 的反向操作），事务失败时按日志回滚。

2. 一致性（Consistency）

   • 示例：银行账户余额必须满足 “支出 + 余额≥0” 的约束，事务执行后数据需符合所有预设规则。
   • 实现：
     • 数据库内置约束（如主键唯一、外键关联）；
     • 事务的原子性和隔离性确保中间状态不影响数据合法性。

3. 隔离性（Isolation）

   • 并发问题：脏读、不可重复读、幻读等。
   • 隔离级别（从低到高）：
     • 读未提交（Read Uncommitted）；
     • 读已提交（Read Committed）；
     • 可重复读（Repeatable Read，MySQL 默认）；
     • 串行化（Serializable）。

4. 持久性（Durability）

   • 示例：用户提交订单后，即使数据库崩溃，订单数据也不会丢失。
   • 实现：Redo Log 先于数据写入磁盘，事务提交时确保日志已持久化（WAL 机制）。

事务日志工作原理总结

一、事务日志核心组件：Redo Log 与 Undo Log

1. Redo Log（重做日志）

• 作用：保证事务的持久性，记录数据修改后的状态，用于崩溃恢复。
• 工作原理：
  1. WAL（预写日志）机制：数据修改前，先将 Redo Log 写入磁盘，确保事务提交后日志已持久化。
  2. 日志格式：记录 “数据页 + 偏移量 + 新值”，不记录旧值。
  3. 崩溃恢复：数据库重启时，扫描 Redo Log，将未持久化的修改重新应用到数据文件。
• 优化策略：
  • Checkpoint（检查点）：定期将内存中已提交的数据刷新到磁盘，并标记 Redo Log 中无需再恢复的部分，减少恢复时间。
  • 组提交（Group Commit）：多个事务的 Redo Log 批量写入磁盘，提升 IO 效率。

2. Undo Log（撤销日志）

• 作用：保证事务的原子性和一致性，记录数据修改前的状态，用于事务回滚和 MVCC。
• 工作原理：
  1. 回滚机制：事务执行过程中，每一步操作对应一条 Undo Log（如插入操作对应删除日志）。
  2. MVCC 支持：通过 Undo Log 生成数据的历史版本，实现读已提交、可重复读等隔离级别。
  3. 日志清理：事务提交后，Undo Log 不会立即删除，需等待所有引用该版本的事务结束后，通过 Purge 线程清理（InnoDB）。

 8.总结mysql日志类型，并说明如何启动日志

日志类型

1. 错误日志：记录 MySQL 服务进程mysqld在启动、关闭或运行过程中遇到的错误信息2。
2. 通用日志：记录所有到达 MySQL 服务器的 SQL 语句，包括查询、更新、插入等各种操作1。
3. 慢查询日志：用于记录执行时间超过特定阈值的 SQL 语句，可帮助定位性能问题1。
4. 二进制日志：记录了对数据库的更改操作，如插入、更新、删除等，主要用于数据恢复和主从复制1。
5. 中继日志：在主从复制架构中，从服务器用于存储主服务器发送过来的二进制日志事件，然后再应用这些事件来更新从服务器的数据。
6. 重做日志（Redo Log）：保证事务的持久性，记录数据修改后的状态，用于数据库崩溃后的恢复。
7. 回滚日志（Undo Log）：保证事务的原子性和一致性，记录数据修改前的状态，用于事务回滚和实现多版本并发控制（MVCC）。

启动方法1

1. 通用日志：编辑 MySQL 配置文件my.cnf（Linux）或my.ini（Windows），在[mysqld]部分添加general_log = 1开启通用日志，添加general_log_file = /path/to/your/log/file.log指定日志文件路径，修改后重启 MySQL 服务。
2. 慢查询日志：编辑配置文件，在[mysqld]部分添加slow_query_log = 1开启慢查询日志，slow_query_log_file = /path/to/your/slow/log/file.log指定日志文件路径，long_query_time = n设置慢查询的时间阈值（单位为秒），然后重启 MySQL 服务。
3. 二进制日志：编辑配置文件，在[mysqld]部分添加log_bin = /path/to/your/binlog/file指定二进制日志文件路径，还可根据需要配置binlog_format（日志格式）、binlog_checksum等其他相关参数，配置完成后重启 MySQL 服务。
4. 错误日志：在启动 MySQL 时使用--log-error=/var/lib/mysql/error.log选项来指定错误日志的路径和文件名。如果不指定，默认情况下错误信息会输出到标准错误输出（stderr）。
5. 中继日志：在从服务器的配置文件中，通过relay_log = /data/mysql/logs/relay/mysqlrelay指定中继日志文件的路径，relay_log_index = /data/mysql/logs/relay/mysqlrelay.index指定中继日志索引文件的路径，通常还会设置relay_log_recovery = 1和relay-log-purge = 1等相关参数来确保中继日志的正确使用和管理。配置完成后，从服务器在启动或与主服务器建立连接时会自动开始使用中继日志。
6. 重做日志和回滚日志：InnoDB 存储引擎默认会启用重做日志和回滚日志，一般不需要手动配置启动。它们的相关参数（如innodb_log_file_size等）可以在配置文件中进行调整，以优化数据库的性能和恢复能力。

9.

1. STATEMENT 格式（语句级日志）

记录逻辑：记录具体执行的 SQL 语句。
优点：

• 日志文件体积小，节省磁盘空间和 IO 资源。
• 记录内容简洁，便于人工阅读和分析。
  缺点：
• 可能导致主从复制不一致（如使用非确定性函数 NOW()、RAND()，或依赖数据库状态的操作）。
• 对触发器、存储过程、自定义函数的支持较差，可能引发复制错误。
  适用场景：
• 简单业务场景：如纯 SQL 语句（无复杂函数、触发器）的增删改查，且对主从一致性要求不高。
• 日志空间敏感场景：如磁盘资源有限，需控制日志文件大小。
• 历史数据审计：仅需记录执行的 SQL 语句，无需关注数据具体变更内容。

2. ROW 格式（行级日志）

记录逻辑：记录每一行数据的变更前后状态（如插入、更新、删除的具体数据）。
优点：

• 复制安全性高：精确记录数据变更，避免因 SQL 语句不确定性导致的主从不一致。
• 完整支持触发器、存储过程、函数等复杂逻辑的复制。
• 便于数据恢复：可精准定位到每一行数据的变更。
  缺点：
• 日志文件体积大，占用更多磁盘空间和 IO 资源。
• 记录内容为二进制数据，人工阅读困难。
  适用场景：
• 高一致性要求场景：如金融交易、订单系统等对数据一致性要求极高的业务。
• 复杂逻辑场景：包含触发器、存储过程、非确定性函数（如 UUID()）的业务。
• 主从复制严格一致场景：如需要搭建多从库或进行数据灾备的系统。

3. MIXED 格式（混合日志）

记录逻辑：自动选择 STATEMENT 或 ROW 格式记录日志：

• 大部分场景使用 STATEMENT 格式，以节省空间；
• 当检测到可能导致复制不一致的操作时（如非确定性函数、DDL 语句），自动切换为 ROW 格式。
  优点：
• 平衡日志大小和复制安全性，自动适配不同场景。
  缺点：
• 自动切换逻辑可能不够智能，部分场景仍需手动指定格式。
  适用场景：
• 默认场景：适用于大多数业务，无需手动配置格式。
• 不确定业务场景：当无法确定是否需要使用 STATEMENT 或 ROW 时，作为折中方案。

场景类型	推荐格式	原因
简单 SQL 操作，低一致性要求	STATEMENT	日志体积小，节省资源。
复杂逻辑（触发器、函数）	ROW	确保复制一致性，避免数据不一致。
金融、交易等高敏感业务	ROW	严格保证主从数据一致，支持精准数据恢复。
不确定业务场景或默认配置	MIXED	自动平衡日志大小和复制安全性，减少手动配置成本。