第6次作业

1.完成将server和client端的mysql配置默认字符集为utf8mb4

2. 掌握如何获取SQL命令的帮助，基于帮助完成添加testdb库，字符集utf8, 排序集合utf8_bin

3.总结mysql常见的数据类型

MySQL支持许多不同的数据类型，每种数据类型都具有不同的特性和用途。以下是MySQL常见的数据类型：

整型（INT、TINYINT、SMALLINT、MEDIUMINT、BIGINT）：用于存储整数值，不同的整型数据类型支持的范围不同。
浮点型（FLOAT、DOUBLE、DECIMAL）：用于存储带小数点的数字，不同的浮点型数据类型支持的精度不同。
字符串型（CHAR、VARCHAR、TEXT、BLOB）：用于存储字符型数据，不同的字符串型数据类型支持的长度和存储方式不同。
日期/时间型（DATE、TIME、DATETIME、TIMESTAMP、YEAR）：用于存储日期和时间信息，不同的日期/时间型数据类型支持的精度和存储方式不同。
枚举和集合型（ENUM、SET）：用于存储具有限定值的数据，ENUM类型只能存储单个值，而SET类型可以存储多个值。
总之，选择正确的数据类型可以使MySQL数据库更高效地处理数据，提高数据库性能，因此在设计MySQL数据库时需要根据需求选择合适的数据类型。

4. 创建一个主机表host,放在testdb中，要求字段 1) 主键自增id 无符号, tinyint. 2) hostname可变字符长度256，可为空。。3）ip 可变字符长度256，可为空。4）账号，可变字符长度256，可为空。5）密码，可变字符长度256，可为空。6）创建时间，时间类型，非空。7）更新时间，时间类型，默认当前时间。8）区域，只能在华南，华北，华东，三个区域之一。9）端口，无符号整数，可为空。10）外网地址，可变字符长度256，可为空。11）内网地址，可变字符长度256，可为空。

5. 给testdb.host表中添加多条数据。

6. 根据表扩展出几个语句，完成总结DDL, DML的用法，并配上示例

7. 导入hellodb库，总结DQL, alias, where子句，gruop by, order by, limit, having使用示例

别名使用

跳过2项，取接下来的3项记录

多字段分组

分组过滤排序

8.基于hellodb 库, 总结子查询，关联查询 ，交叉连接，内连接，左连接，右连接，完全连接，自连接

子查询
子查询，subquery即SQL语句调用另一个SELECT子句，可以对同一张表，也可以对不同表，子查询可以一次性完成很多逻辑上需要多个步骤才能完成的SQL操作，子查询虽然可以使查询语句很灵活，但执行效率不高。执行子查询时需要为内查询的查询结果建立一个临时表，然后外层查询语句从临时表中查询记录，查询完成后再撤销临时表，因此子查询速度会受到影响。可以使用连接（JOIN）查询来代子查询，连接查询不需要建立临时表，速度比子查询快，如果查询中使用到索引性能会更好。

主要有以下四种常用用法：

用于比较表达式中的子查询，子查询仅能返回单个值

用于IN中的子查询，子查询应该单独查询并返回一个或多个值重新构建列表

用于EXISTS和NOT EXISTS
EXISTS（包括NOT EXISTS）子句的返回值是一个BOOL值，EXISTS内部有一个子查询语句（SELECT…FROM…）,将其称为EXIST的内查询语句，其内查询语句返回一个结果集。EXISTS子句根据其内查询语句的结果集控或者非空，返回一个布尔值。将外查询表的每一行代入内查询作为检验，如果内查询返回的结果为非空值，则EXISTS子句返回TRUE，外查询的这一行数据编可作为外查询的结果行返回，否则不能作为结果。

联合查询

联合查询UNION实现条件：多个表字段数量相同，字段名可以不同，但数据类型相同。

交叉连接

CROSS JOIN ，多表的记录（行）之间做笛卡尔乘积，并且多个表的列横向合并，
比如tb1为3行4列，tb2为5行6列，则tb1 CROSS JOIN tb2后为3*5=15行，4+6=10列
交叉连接生成的记录可能会非常多，慎用。

内连接

inner join 内连接取多个表的交集

左连接

左外连接：以左表为主，根据条件查询右表数据，如果根据条件查询右表数据不存在，则使用null填充

右连接

右外连接：以右表为主，根据条件查询左表数据，如果根据条件查询左表数据不存在，则使用null填充

完全连接

MySQL不支持完全外连接full outer join语法

9. 总结select语句处理顺序。

10. 总结mysql事件管理,用户管理，权限管理。

事件管理
事件由两个部分组成，第一部分是事件调度(event schedule)，表示事件何时启动以及按什么频率启动，第二部分是事件动作(event action)，即事件启动时执行的代码，事件动作可以是一条简单的SQL语句，也可以是一个存储过程，也可以是begin…end语句块。
一个事件可以是活动（打开）的或停止（关闭）的，活动意味着事件调度器检查事件动作是否必须调用；停止意味着事件的声明存储在目录中，但调度器不会检查是否应该调用。在一个事件创建后它立即变为活动的，一个活动的事件可以执行一次或多次。

用户管理

涉及的数据库和表:
● 元数据数据库：mysql
● 系统授权表：db,host,user,columns_priv,tables_priv,procs_priv,proxies_priv

#创建用户
CREATE USER [IF NOT EXISTS] 'USERNAME'@'HOST' [IDENTIFIED BY password]

create user shichao@'10.0.0.%' identified by 'shichao123';

#用户重命名
RENAME USER old_user TO new_name;

#修改密码
#方法1
SET PASSWORD FOR 'USERNAME'@'HOST' = PASSWORD('password'); #mysql8.0不支持此方法，用下面的方法替代
SET PASSWORD FOR 'USERNAME'@'HOST' = 'password';

#方法2
ALTER USER 'USERNAME'@'HOST' IDENTIFIED BY 'password';

#方法3  mysql8.0不支持此方法
UPDATE mysql.user SET password=PASSWORD('password') WHERE clause;
FLUSH PRIVILEGESL;

权限管理

● 管理类
○ CREATE USER
○ FILE
○ SUPER
○ SHOW DATABASES
○ RELOAD
○ SHUTDOWN
○ REPLICATION SLAVE
○ REPLICATION CLIENT
○ LOCK TABLES
○ PROCESS
○ CREATE TEMPORARY TABLES
● 程序类，针对FUNCTION,PROCEDURE,TRIGGER进行CREATE,ALTER,DROP,EXCUTE
● 数据库级别:ALTER,CREATE
● 表级别
● 字段级别:
○ SELECT (col1,col2…)
○ UPDATE (col1,col2…)
○ INSERT (col1,col2…)

12. 总结mysql架构原理

MySQL 是一个典型的客户端/服务端模式的数据库管理系统，它的架构主要分为以下三个部分：

连接层（Connection Layer）：处理客户端连接请求，并进行身份验证、权限验证等操作。一旦连接建立成功，它将负责管理客户端和服务端之间的通信，并通过缓存、预读等技术提高数据查询的效率。
服务层（Server Layer）：该层是 MySQL 的核心组成部分，由多个线程池、缓存和存储引擎组成。所有的 SQL 查询请求都发送到该层处理，其中相关的 SQL 解析和优化工作由 Query Cache 和 Optimizer 处理，然后将查询请求发送到相应的存储引擎中执行。
存储引擎层（Storage Engine Layer）：MySQL 支持多种存储引擎，例如 InnoDB、MyISAM 等。每个存储引擎都可以独立处理数据的读写，因此在存储引擎层中，数据会被不同的存储引擎以不同的方式进行存储和管理。
其中，还有以下几个重要的组件：

连接器（Connector）：负责连接客户端和服务端、进行身份认证和权限验证。
查询缓存（Query Cache）：缓存查询结果，提高重复查询的效率。
SQL 解析器和优化器（SQL Parser & Optimizer）：将 SQL 语句转换为执行计划，进行查询优化。
存储引擎（Storage Engine）：负责数据的存储和管理，提供不同的数据访问方式、锁机制以及事务支持等功能。
总体来说，MySQL 的架构设计非常清晰，各个组件之间分工明确、相互独立，使得 MySQL 具备高效、灵活和可扩展的特性。同时，MySQL 还提供了多种配置参数以及插件接口，能够满足各种不同的需求和场景。

13. 总结myisam和Innodb存储引擎的区别。

MyISAM存储引擎
特点：
● 不支持事务
● 表级锁定
● 读写互相阻塞，写入时不能读，读时不能写
● 只缓存索引
● 不支持外键约束
● 不支持聚簇索引
● 读取数据块较快，占用资源少
● 不支持MVCC(多版本并发控制机制)高并发
● 崩溃后恢复性较差
● MYSQL5.5前默认的存储引擎
适用场景：
● 只读，写较少
● 表较小
引擎文件：
● tbl_name.frm 表格式定义
● tbl_name.MYD 数据文件
● tbl_name.MYI 索引文件

InnoDB引擎
特点：
● 行级锁
● 支持事务，适合处理大量短期事务
● 读写阻塞与事务隔离级别相关
● 可缓存数据和索引
● 支持聚簇索引
● 奔溃恢复性好
● 支持MVCC高并发
● 从Mysql5.5支持全文索引
● MYSQL5.5后默认的存储引擎
InnoDB数据库文件：
● 所有InnoDB表的数据和索引放在同一个表空间中
○ 数据文件：ibdata1,ibdata2，存放在datadir定义的目录下
○ 表格式定义：tb_name.frm，存放在datadir定义的每个数据库对应的目录下
● 每个表单独使用一个表空间存储表的数据和索引
○ 启用：innodb_file_per_tabke=ON
○ 数据文件：存储数据和索引，tb_name.ibd
○ 表格式定义：tb_name.frm

14. 总结mysql索引作用，同时总结哪些查询不会使用到索引

索引是排序的快速查找的特殊数据结构，定义作为查找条件的字段上，又称为键key，索引通过存储引擎实现。想一想书的目录。
优点：
● 可以降低服务需要扫描的数据量，减少IO次数
● 可以帮助服务器避免排序和使用临时表
● 可以帮助将随机IO转为顺序IO，有次序查找起来效率就高了

只要列中含有NULL值，就最好不要在此列设置索引，复合索引如果有NULL值，此列在使用时也不会使用索引
对于like语句，以%或者_开头的不会使用索引
尽量不要使用not in和<>虽然可能使用索引，但性能不高
不要使用RLIKE正则表达式，会导致索引失效

15. 总结事务ACID事务特性

● Atomicity 原子性：整个事务中的所有操作要么全部成功执行，要么全部失败后回滚
● Consistency一致性：数据库总是从一个一致性状态转换为另一个一致性状态
● Isolation隔离性：一个事务所做出的操作在提交之前，是不能为其他事务所见；隔离有多种隔离级别，实现并发
● Durability持久性：一旦事务提交，其所做的修改会永久保存于数据库中

16. 总结事务日志工作原理。

事务日志（Transaction Log）是数据库管理系统中的一种重要机制，用于记录每个事务所做出的修改操作。其工作原理可以简单概括如下：

事务启动：当用户发起一个事务时，数据库开始记录该事务的相关信息，并在事务日志中创建一个新的日志文件，以记录此次事务的所有操作。
日志记录：在事务执行过程中，数据库系统将所有对数据进行的修改操作，都以日志的形式记录下来，包括对数据的插入、更新、删除等操作。每个日志条目都包含了该操作的详细信息，如何修改数据，修改之前和之后的值等。
日志缓存：由于频繁写磁盘会影响性能，为了提高性能，数据库通常会使用缓存技术，将日志信息先暂存在内存中，等到缓存满或到达一定时间后再一次性写入硬盘。
将事务提交：当事务执行完成后，如果用户提交了该事务，那么就会触发事务的提交操作，同时也会将该事务所产生的所有日志记录写入磁盘上的日志文件中。
恢复操作：当数据库系统重新启动时，会检查每个已提交的事务是否正确执行，并根据事务日志对未提交的事务进行恢复。如果有未完成的事务，则进行回滚操作，将数据库恢复到事务开始前的状态。
综上所述，事务日志是确保数据库数据正确性和可靠性的重要手段，在数据库管理中扮演着至关重要的角色。

● redo log：记录某数据块被修改后的值，数据更新前先记录redo log（WALWrtite Ahead Log），可以用来恢复未写入data file的已成功事务更新的数据。（事务提交后数据还没来得及写到磁盘中发生系统崩溃，设备启动后会根据redo log恢复事务修改后的内容）
● undo log：保存与执行的操作相反的操作，即记录某数据被修改前的值，可用来在事务失败时进行rollback
事务型存储引擎自行管理和使用，建议和数据文件分开存放
redo log整体流程
先将原始数据从磁盘中读入内存中来，修改数据的内存拷贝
生成一条重做日志并写入redo log buffer，记录的是数据被修改后的值 。
当事务commit时，将redo log buffer中的内容刷新到 redo log file，对 redo log file采用追加写的方式 。
定期将内存中修改的数据刷新到磁盘中。
 

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

日志类型：
● 事务日志：transaction log，事务日志的写入类型为“追加”，因此其操作为“顺序IO”；通常也被称为预写式日志write ahead logging。事务日志文件：ib_logfile0,ib_logfile1
● 错误日志，error log
● 通用日志：general log
● 慢查询日志：slow query log
● 二进制日志：binary log
● 中继日志：relay log，在主从复制架构中，从服务器用于保存从主服务器的二进制日志中读取的事件

启动日志

打开通用日志

慢查询日志

18. 总结二进制日志的不同格式的使用场景。

二进制日志记录三种格式
● 基于“语句”记录：statement，记录语句，Mariadb10.2.3以下版本默认模式，日志量少。磁盘空间较小，或者IO性能差的服务器
● 基于“行”记录：row，记录数据，日志量大，MySQL8.0默认格式。磁盘空间大，IO性能好的服务器建议使用该格式
● 混合模式：mixed，让系统自行判定该基于哪种方式进行,Mariadb10.2.3以上版本默认模式

注意：基于“语句”的方式，会导致还原时出现问题，比如update t1 set time=now(); 命令执行时和恢复时该命令的含义是不一样的。
 

MySQL的二进制日志（Binary Log）可以分为两种不同格式：语句格式（statement-based）和行格式（row-based）。

语句格式记录的是事务中执行的SQL语句，可以用于复制、恢复、回滚等操作。但是也存在一些缺点，如对于某些复杂的语句或函数可能无法正确记录，因此可能导致数据不一致的问题。

行格式记录的是每行数据的具体修改操作，更加精确地记录了事务执行过程中的数据变化。由于记录的信息比较详细，因此行格式在进行数据复制和故障恢复时更加可靠，但是也会给硬盘写入带来更大的压力，并且日志文件会相对比较大。

使用场景：

语句格式适合轻量级的系统，查询和写入都不多，而且性能要求没有那么高的场景。

对于高性能和高可靠性要求的场景，推荐使用行格式。比如需要进行主从复制、故障恢复、数据同步等操作时，行格式可以更好地保证数据一致性，减少故障发生的概率。当然，如果存储空间受限，或者IO写入压力过大，可以选择关闭二进制日志或者调整成语句格式进行记录。

19. 总结mysql备份类型，并基于mysqldump, xtrabackup完成数据库备份与恢复验证。

● 完全备份，部分备份
○ 完全备份：整个数据集
○ 部分备份：只备份数据子集，如部分库或表
● 完全备份、增量备份、差异备份
○ 增量备份：仅备份最近一次完全备份或增量备份（如果存在增量）以来变化的数据，备份较快，还原复杂
○ 差异备份：仅备份最近一次完全备份以来变化的数据，备份较慢，还原简单
● 冷、温、热备份
○ 冷备：读写操作均不可进行，数据库停止服务
○ 温备：读操作可执行，写操作不能执行
○ 热备：读写操作均可执行。MyISAM支持温备，不支持热备；InnoDB都支持
● 物理和逻辑备份
○ 物理备份：直接复制数据文件进行备份，与存储引擎有关，占用较多空间，速度快
○ 逻辑备份：从数据库导出数据另存，与存储引擎无关，占用空间少，速度慢

20. 编写crontab，每天按表备份所有mysql数据。将备份数据放在以天为时间的目录下。

21. 编写crontab, 基于xtrabackup，每周1，周5进行完全备份，周2到周4进行增量备份。

0 2 * * 1,5 xtrabackup --user=root --password=PASSWORD /backup/full_backup_$(date +\%Y-\%m-\%d)

0 2 * * 2-4 xtrabackup --user=root --password=PASSWORD --incremental /backup/inc_backup_$(date +\%Y-\%m-\%d) --incremental-basedir=/backup/full_backup_$(date -d 'last Monday' +\%Y-\%m-\%d)
 

22. 总结mysql主从复制原理。

主从复制相关线程
● 主节点：
○ dump Thread：为每个slave的I/O Thread启动一个dump线程，用于向其发送binary log events
● 从节点：
○ I/O Thread：向master请求二进制日志事件，并保存与relay log中
○ SQL Thread：从relay log读取日志事件，本地完成重放
跟复制相关的文件：
● master.info：用于保存slave连接至master时的相关信息，例如账号、密码、服务器地址等
● relay-log.info：保存在当前slave节点上已经复制的当前二进制日志和本地relay log日志的对应关系
● mysql-relay-bin.00000x：中继日志，保存从主节点复制过来的二进制日志，本质就是二进制日志
● MySQL8.0已取消master.info和relay-log.info
 

23. 实现mysql主从复制，主主复制，半同步复制，过滤复制

主从复制

主节点配置

从节点配置

主主复制

两个节点都可以更新数据，并且互为主从。容易造成数据不一致，需慎用。
为避免主键ID冲突，需要在两个节点上分别指定奇数id和偶数id

半同步复制
默认情况下MySQL的复制功能是异步的，异步复制可以提供最佳性能，主库把binlog日志发送给从库即结束，不会等待从库响应。因此当服务器或从服务器发生故障时有可能从服务器没有接收到主服务器发送过来的binlog日志，最终导致主从数据不一致。
MySQL5.5为了保证主从数据一致，加入了半同步复制组件，可以控制从库IO线程是否将relaylog落盘，一旦落盘通过插件返回ACK给主库的ACK_REC。接受ACK后，主库事务才能提交成功。如果超时未接收到ACK，此次复制行为会切换到异步复制。

半同步复制默认设置：
rel_semi_sync_master_wait_point=after_commit
收到客户端发来的commit后master将事务写入binlog，再提交事务，然后将数据传给slave，slave将event存入relay log后返回ACK，master收到ack后返回commit ok给客户端。

缺点：
产生幻读，当用户提交一个事务，该事务已经写入redo日志和binlog并在storage commit，但该事务还没有写入从库，此时处于waiting slave dump处，此时在master读取到这条数据，但在slave读不到；
数据丢失，一个提交的事务在waiting slave dump时主备之间断开，主库将比从库多一条数据

增强半同步复制(MySQL5.7新增功能)：
rel_semi_sync_master_wait_point=after_sync
收到客户端发来的commit后master将事务写入binlog，然后将数据传给slave，slave将event存入relay log后返回ACK，master收到ack后提交事务，并返回commit ok给客户端。

改善：
解决幻读，由于在slave返回的ack之前，master是不会提交事务，因此此时主备都不会看到数据
解决数据丢失，在等待slave返回ack时，master发生crash，可以通过观察从库删是否存在主库的last gtid值，如果存在，这条数据正常恢复，如果不存在，则删除主库上last gtid对应的数据，然后再恢复。

主节点配置文件

从节点

过滤复制

24. 总结GTID复制原理，并完成GTID复制集群。
 

Global Transaction ID:全局事务标识符。
开启GTID功能可以支持多DUMP线程的并发复制，而且在MySQL5.6实现了基于库级别多SQL线程并发。在MySQL5.7利用GTID的Logic clock逻辑时钟，保证了同库级别下的事务顺序问题，即可以实现基于事务级别的并发回放，从而大大减少同步时延。
GTID具有幂等性，即多次执行结果一样。
利用GTID复制不像传统的复制方式（异步复制，半同步复制）需要找到binlog文件名和position点，只需知道master的IP、端口、账号、密码即可。开启GTID后，执行change master to master_auto_position=1即可，它会自动寻找相应的位置开始同步。
优点：
● 保证事务全局统一
● 截取日志更加方便，跨多文件，判断起点终点更方便
● 判断主从工作状态更方便
● 传输日志，可以并发传输。SQL回放可以更高并发
● 主从复制架构更方便
GTID架构

主服务器

从服务器

25. 总结主从复制不一致的原因，如何解决不一致，如何避免不一致

造成主从不一致的原因:
● 主库binlog格式为Statement，同步到从库执行后可能造成主从不一致
● 主库执行更改前执行set_sql_log_bin=0，会使主库不记录binlog，也就不会同步到从库
● 从节点未设置只读，误操作写入数据
● 主库或从库意外宕机，宕机可能会造成binlog或者relay log文件出现损坏，导致主从不一致
● 主从实例版本不一致，特别是主用高版本，从用低版本，导致主上的功能从不支持
● 主从sql_mode不一致

主从不一致修复方法：
● 将从库重新实现
● 使用percona-toolkit工具辅助
● 手动重建不一致的表
 

1.停止从库slave复制
stop slave;

2.在主库上对不一致的表进行备份，并记录binlog pos点
mysqldump --single-transaction --master-data=2 db_name tb_name1 tb_name2 > /backup.sql

3.查看backup.sql，找出binlog pos点
假设
MASTERLOGFILE='mysql-bin.xxxxx',MASTERLOGPOS=YYYYY

4.为保证其他表的数据不丢失，将停止复制后做备份期间的更改同步到备用
start slave until MASTERLOGFILE='mysql-bin.xxxxx',MASTERLOGPOS=YYYYY;

The UNTIL clause makes the replica start replication, then process transactions up to the point that you specify in the UNTIL clause, then stop again.

5.将backup.sql拷贝到slave并还原
set sql_log_bin=0;
source /backup.sql
set sql_log_bin=1;

6.开启同步
start slave
 

26. 总结数据库水平拆分和垂直拆分

简单来说，就是指通过某种特定条件，将存放在同一个数据库中的数据分散存放到多个数据库（主机）上，以达到分散单台设备负载的效果。
数据的切分（Sharding）根据其切分规则的类型分为两种切分模式：
● 一种是按照不同的表（或者schema）来切分到不同的数据库（主机）上，这种切可以称之为数据的垂直（纵向）切分
● 一种是根据表中数据的逻辑关系，将同一个表重的数据按照某种条件拆分到多台数据库主机上，这种切分称之为数据的水平（横向）切分
垂直切分的最大特点是规则简单，实施方便，尤其适合各业务之间的耦合度非常低，相互影响很小，业务逻辑非常清晰的系统。在这种系统中，可以很容易做到不同业务模块所使用的表分拆到不同的数据库中，根据不同的表来拆分，对应用程序影响也更小，拆分规则会比较简单清晰。
水平切分与垂直切分相比，相对来说稍微复杂一些。因为要将同一个表中的不同数据拆分到不同的数据库中，对于应用程序来说，拆分规则本身就比根据表拆分更复杂，后期的数据维护也更复杂。

垂直切分的优缺点：
优点：
● 拆分后业务清晰，拆分规则明确
● 系统之间整合或扩展容易
● 数据维护简单
缺点：
● 部分业务表无法join，只能通过接口方式解决，提高了系统复杂度
● 受每种业务不同的限制存在单库性能瓶颈，不易数据扩展
● 事务处理复杂
由于垂直切分是按照业务的分类将表分散到不同库，所以有些业务表会过于庞大，存在单库读写与存储的瓶颈，所以需要水平拆分来解决。
水平拆分优缺点：
优点：
● 拆分规则抽象良好，join操作基本都可以数据库完成
● 不存在单库大数据，高并发的性能瓶颈
● 应用端改造较少
● 提高了系统的稳定性跟负载能力
缺点：
● 拆分规则难以抽象
● 分片事务一致性难以解决
● 数据多次扩展难度跟维护量极大
● 跨库join性能较差
垂直和水平切分共同缺点有：
● 引入分布式事务的问题
● 跨节点join的问题
● 跨节点合并排序分页问题
● 多数据源管理问题

27. 基于mycat实现读写分离

关闭从节点后，mycat自动调度请求主节点

28. 总结mysql配置最佳实践。

MySQL 是一个广泛使用的关系型数据库管理系统，在进行 MySQL 配置时，需要考虑多个方面来实现最佳实践。以下是几方面建议：

确定正确的 MySQL 版本：选择适合业务需求的 MySQL 版本，同时将 MySQL 与其他软件版本相匹配。
配置正确的存储引擎：选择正确的存储引擎可以大大提高 MySQL 数据库的性能和可靠性。常用的存储引擎包括 InnoDB 和 MyISAM。
适当地配置缓存：通过适当地配置缓存，可以显著提高 MySQL 数据库的性能。在 MySQL 中，可以使用查询缓存、内存缓存和磁盘缓存等不同类型的缓存。
合理地配置日志：日志记录对 MySQL 数据库的性能和可靠性非常重要。MySQL 提供了多种类型的日志记录功能，如二进制日志、慢查询日志和错误日志等。你应该根据自己的业务需求合理地配置这些日志。
定期备份数据库：定期备份数据库可以确保在出现故障或者数据丢失时可以快速恢复数据。你应该选择一个可靠的备份策略，并确保备份数据的完整性和一致性。
优化查询语句：查询是数据库中最常见的操作之一，优化查询语句可以显著提高 MySQL 数据库的性能。你应该针对查询语句进行性能调优，并使用索引来优化查询速度。
安全性配置：在 MySQL 中，安全性是非常重要的。你应该定期更新 MySQL 的安全补丁，并正确地配置访问控制。
以上是一些 MySQL 配置的最佳实践建议。在进行 MySQL 配置时，需要考虑业务需求、数据量、硬件设备等多个因素。
 

29. 总结openvpn原理，并完成1键安装不同版本vpn脚本，可以适配rocky, ubuntu, centos主机。同时支持添加账号，注销账号。

OpenVPN是一种开源的虚拟私人网络（VPN）解决方案，它使用SSL/TLS协议来加密和保护数据的传输。它的工作原理如下：

建立连接：客户端与服务器之间建立一个安全的通信信道。
验证身份：客户端和服务器会进行互相验证身份，以确保双方都是可信的。
加密通信：使用SSL/TLS协议对通信数据进行加密，确保数据的机密性。
数据封装：将要传输的数据进行封装，添加OpenVPN的头部和尾部信息。
传输数据：加密后的数据通过TCP或UDP协议在客户端和服务器之间进行传输。
解封装和解密：接收方收到数据后，进行解封装和解密，还原成原始数据。
路由和转发：根据目标IP地址，将数据传递给目标主机。
OpenVPN采用了基于SSL/TLS的加密和认证技术，通过使用公钥和私钥对通信进行加密和身份验证。它可以在TCP和UDP协议上运行，并且支持多种操作系统和设备。

通过建立加密的隧道，OpenVPN能够在不安全的公共网络上创建一个安全、私密的连接，使用户能够安全地传输敏感数据或访问私有网络资源。它在保护用户隐私和数据安全方面提供了可靠的解决方案。