基础章节-01-MySQL数据库服务中级课程 1.00 课程知识章节说明 目前在互联网的实际应用中，各个企业都会比较关注自身网站的数据信息，既要保证数据信息的安全性，同时也要保证数据存储读取效率 并且在特殊的场景下，还要对存储的数据信息进行检索和分析；因此数据库服务业务已经在各行各业应用非常的广泛 对于互联网领域的技术人员，对于数据库服务知识的掌握，也将是在求职时必备的技能，有些时候还会绝对入职的定级和薪资水平。 1.13 数据库服务克隆应用 1.13.1 数据库克隆概念介绍 在数据库MySQL 8.0（8.0.17+）版本中，引入了数据库的克隆功能，主要是借助clone-plugin实现的，是对数据页底层克隆； 克隆的数据是InnoDB存储引擎中的物理快照信息，包括schemas, tables, tablespaces, and data dictionar y metadata； 在数据库中出现克隆功能，主要是为了满足目前云原生的技术应用场景，同时也是为了海量数据备份而诞生的； 在数据库中实现克隆功能应用有两种方式： 本地克隆（Local Cloning）： 启动克隆操作的MySQL数据库服务器实例中的数据，将会克隆到同服务器或同节点上的一个目录里； 1669564772486 远程克隆（Remote Cloning）： 默认情况下，远程克隆操作会删除接受者（recipient）数据目录中的数据，并将其替换为捐赠者（donor）的克隆数据； 也可以将数据克隆到接受者的其他目录中，以避免删除现有数据；（属于可选操作）； 主要用于实现数据远程的快速热迁移操作，在迁移过程中，除了DDL操作情况，其他操作都不会出现阻塞情况； 还可以利用远程克隆技术，实现快速构建数据库的主从架构环境，实现主从数据信息快速复制同步； 1669564937916 1.13.2 数据库克隆原理说明 在进行数据库克隆操作时，会经历几个重要的过程或步骤： 01 Page copy： 在进行数据页复制操作时，会涉及到两个操作动作： 开启redo archiving功能，从当前点开始存储新增的redo_log，这样从当前位置点开始所有的增量修改都不会丢失； 同时上一步在page track的page被发送到目标端，确保当前位置点之前所有做的变更一定发送到目标端； 关于redo archiving实际上这是官方早就存在的功能，主要用于官方的企业级备份工具，clone利用了该特性来维持记录增量产生的redo 在开始克隆前会做一次checkpoint； 对于redo archiving功能应用，会开启一个后台线程log_archiver_thread()来做日志归档; 当有新的写入时(notify_about_advanced_write_lsn)，也会通知线程去进行归档，当arch_log_sys处于活跃状态时， 线程会控制日志写入以避免未归档的日志被覆盖（log_write_wait_on_archiver）,注意如果log_write等待时间过长的话， archive任务会被中断掉； 02 Redo copy： 停止redo archiving功能，所有归档的日志被发送到目标端，这些日志包含了从page copy阶段开始到现在的所有日志； 另外可能还需要记下当前的复制点，例如：最后一个事务提交时的binlog位置点或者gtid信息，在系统页中可以找到； 03 Done： 目标端重启实例，通过crash recovery将redo log应用上去； 克隆原理过程分析参考链接：https://zhuanlan.zhihu.com/p/437760913 说明：整个克隆过程都会以事件信息记录，可以很清晰的看到克隆的流程，如果克隆过程中断，也会以追加方式进行继续克隆； 在进行克隆功能应用时，也是存在一些限制性操作的：（结合官方列出的限制） 对于MySQL 8.0.27之前版本，在进行克隆操作期间，是不允许在捐赠者和接受者上进行DDL操作，包括：truncate table操作； 对于MySQL 8.0.27之后版本，在捐赠者上默认允许并发DDL操作，对于捐赠者上并发DDL的支持由clone_block_DDL变量控制； 对于不同版本的MySQL数据库实例之间，是不能进行克隆操作的。对于捐赠者和接受者必须是确切相同数据库服务版本； 例如：你不能克隆数据在between MySQL 5.7 and MySQL 8.0, or between MySQL 8.0.19 and MySQL 8.0.20； 这个克隆功能只支持在数据库8.0.17版本或之后的版本 参考官方链接说明：https://dev.mysql.com/doc/refman/8.0/en/clone-plugin-limitations.html ...

无故障率 故障时间 解决方案 99.9% 0.1%（525.6min） keepalived+双主架构，但需要人为干预 99.99% 0.01%（52.56min） MHA ORCH TMHA，具有自动监控，自动切换，自动数据补偿，但还是属于半自动化 比较适合非金融类互联网公司 eg: facebook taobao前端-TMHA–>polaradb 99.999% 0.001%（5.256min） PXC MGR MGC，数据是高一致性 比较适合金融类互联网公司 99.9999% 0.0001%（0.5256min） 自动化、云计算化、平台化，仍然属于概念阶段 基础章节-01-MySQL数据库服务中级课程 1.00 课程知识章节说明 目前在互联网的实际应用中，各个企业都会比较关注自身网站的数据信息，既要保证数据信息的安全性，同时也要保证数据存储读取效率 并且在特殊的场景下，还要对存储的数据信息进行检索和分析；因此数据库服务业务已经在各行各业应用非常的广泛 对于互联网领域的技术人员，对于数据库服务知识的掌握，也将是在求职时必备的技能，有些时候还会绝对入职的定级和薪资水平。 1.15 数据库服务冗余架构 1.15.1 数据库服务高可用前言介绍 数据库中的高可用功能，主要是用于避免数据库服务或数据信息的损坏问题，其中数据损坏的类型有： 数据物理损坏：磁盘、主机、程序实例、数据文件误删除 数据逻辑损坏：drop update … 其中，数据库高可用技术的出现主要解决的是数据逻辑损坏问题，而主从架构技术主要解决的是数据物理损坏问题； 数据库高可用解决方案选型依据：（全年无故障率） 1.15.2 数据库服务高可用软件介绍 MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton研发， 此人目前就职于Facebook公司，MHA是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。 MySQL进行故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换过程中； MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 MHA主要有两部分组成： MHA Manager（管理节点） 可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave上。 MHA Node（数据节点） 运行在每台MySQL服务器上 MHA Manager 会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master； 然后将所有其他的slave重新指向新的master，整个故障转移过程对应用程序是完全透明的； MHA软件结构介绍：（MHA中的所有组件就是perl语言编写的功能脚本） 节点信息 软件组件 作用介绍 MHA Manager（管理节点） masterha_manger 用于启动MHA masterha_check_ssh 用于检查MHA的SSH配置互信状况 ...

基础章节-01-MySQL数据库服务中级课程 1.00 课程知识章节说明 目前在互联网的实际应用中，各个企业都会比较关注自身网站的数据信息，既要保证数据信息的安全性，同时也要保证数据存储读取效率 并且在特殊的场景下，还要对存储的数据信息进行检索和分析；因此数据库服务业务已经在各行各业应用非常的广泛 对于互联网领域的技术人员，对于数据库服务知识的掌握，也将是在求职时必备的技能，有些时候还会绝对入职的定级和薪资水平。 1.15 数据库服务冗余架构 1.15.1 数据库服务高可用前言介绍 数据库中的高可用功能，主要是用于避免数据库服务或数据信息的损坏问题，其中数据损坏的类型有： 数据物理损坏：磁盘、主机、程序实例、数据文件误删除 数据逻辑损坏：drop update … 其中，数据库高可用技术的出现主要解决的是数据逻辑损坏问题，而主从架构技术主要解决的是数据物理损坏问题； 数据库高可用解决方案选型依据：（全年无故障率） 无故障率 故障时间解决方案 99.9% 0.1%（525.6min）keepalived+双主架构，但需要人为干预 MHA ORCH TMHA，具有自动监控，自动切换，自动数据补偿，但还是属于半自动化 99.99% 0.01%（52.56min） 比较适合非金融类互联网公司 eg: facebook taobao前端-TMHA–>polaradb PXC MGR MGC，数据是高一致性 99.999% 0.001%（5.256min） 比较适合金融类互联网公司 99.9999% 0.0001%（0.5256min）自动化、云计算化、平台化，仍然属于概念阶段 1.15.2 数据库服务高可用软件介绍 MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton研发， 此人目前就职于Facebook公司，MHA是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。 MySQL进行故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换过程中； MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 MHA主要有两部分组成： MHA Manager（管理节点） 可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave上。 MHA Node（数据节点） 运行在每台MySQL服务器上 MHA Manager 会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master； 然后将所有其他的slave重新指向新的master，整个故障转移过程对应用程序是完全透明的； MHA软件结构介绍：（MHA中的所有组件就是perl语言编写的功能脚本） 节点信息 软件组件 作用介绍 MHA Manager（管理节点 ）masterha_manger 用于启动MHA masterha_check_ssh 用于检查MHA的SSH配置互信状况 masterha_check_repl 用于检查MySQL复制状态，以及配置信息 masterha_master_monitor 用于检测master是否宕机 masterha_check_status 用于检测当前MHA运行状态 masterha_master_switch 用于控制故障转移（自动或者手动） masterha_conf_host 添加或删除配置的server信息 MHA Node（数据节点） save_binar y_logs 保存和复制master的二进制日志 apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他slave purge_relay_logs 清除中继日志（不会阻塞SQL线程） 1.15.3 数据库服务高可用环境构建 ① MHA高可用架构基础环境： 为了实现MHA高可用架构构建，需要准备好三节点数据库+GTID复制环境： ...

基础章节-01-MySQL数据库服务中级课程 1.00 课程知识章节说明 目前在互联网的实际应用中，各个企业都会比较关注自身网站的数据信息，既要保证数据信息的安全性，同时也要保证数据存储读取效率 并且在特殊的场景下，还要对存储的数据信息进行检索和分析；因此数据库服务业务已经在各行各业应用非常的广泛 对于互联网领域的技术人员，对于数据库服务知识的掌握，也将是在求职时必备的技能，有些时候还会绝对入职的定级和薪资水平。 1.15 数据库服务冗余架构 1.15.1 数据库服务高可用前言介绍 数据库中的高可用功能，主要是用于避免数据库服务或数据信息的损坏问题，其中数据损坏的类型有： 数据物理损坏：磁盘、主机、程序实例、数据文件误删除 数据逻辑损坏：drop update … 其中，数据库高可用技术的出现主要解决的是数据逻辑损坏问题，而主从架构技术主要解决的是数据物理损坏问题； 数据库高可用解决方案选型依据：（全年无故障率） 无故障率 故障时间解决方案 99.9% 0.1%（525.6min）keepalived+双主架构，但需要人为干预 MHA ORCH TMHA，具有自动监控，自动切换，自动数据补偿，但还是属于半自动化 99.99% 0.01%（52.56min） 比较适合非金融类互联网公司 eg: facebook taobao前端-TMHA–>polaradb PXC MGR MGC，数据是高一致性 99.999% 0.001%（5.256min） 比较适合金融类互联网公司 99.9999% 0.0001%（0.5256min）自动化、云计算化、平台化，仍然属于概念阶段 1.15.2 数据库服务高可用软件介绍 MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton研发， 此人目前就职于Facebook公司，MHA是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。 MySQL进行故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换过程中； MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 MHA主要有两部分组成： MHA Manager（管理节点） 可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave上。 MHA Node（数据节点） 运行在每台MySQL服务器上 MHA Manager 会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master； 然后将所有其他的slave重新指向新的master，整个故障转移过程对应用程序是完全透明的； MHA软件结构介绍：（MHA中的所有组件就是perl语言编写的功能脚本） 节点信息 软件组件 作用介绍 MHA Manager（管理节点 ）masterha_manger 用于启动MHA masterha_check_ssh 用于检查MHA的SSH配置互信状况 masterha_check_repl 用于检查MySQL复制状态，以及配置信息 masterha_master_monitor 用于检测master是否宕机 masterha_check_status 用于检测当前MHA运行状态 masterha_master_switch 用于控制故障转移（自动或者手动） masterha_conf_host 添加或删除配置的server信息 MHA Node（数据节点） save_binar y_logs 保存和复制master的二进制日志 apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他slave purge_relay_logs 清除中继日志（不会阻塞SQL线程） 1.15.3 数据库服务高可用环境构建 ① MHA高可用架构基础环境： 为了实现MHA高可用架构构建，需要准备好三节点数据库+GTID复制环境： ...

无故障率 故障时间 解决方案 99.9% 0.1%（525.6min） keepalived+双主架构，但需要人为干预 99.99% 0.01%（52.56min） MHA ORCH TMHA，具有自动监控，自动切换，自动数据补偿，但还是属于半自动化 比较适合非金融类互联网公司 eg: facebook taobao前端-TMHA–>polaradb 99.999% 0.001%（5.256min） PXC MGR MGC，数据是高一致性 比较适合金融类互联网公司 99.9999% 0.0001%（0.5256min） 自动化、云计算化、平台化，仍然属于概念阶段 基础章节-01-MySQL数据库服务中级课程 1.00 课程知识章节说明 目前在互联网的实际应用中，各个企业都会比较关注自身网站的数据信息，既要保证数据信息的安全性，同时也要保证数据存储读取效率 并且在特殊的场景下，还要对存储的数据信息进行检索和分析；因此数据库服务业务已经在各行各业应用非常的广泛 对于互联网领域的技术人员，对于数据库服务知识的掌握，也将是在求职时必备的技能，有些时候还会绝对入职的定级和薪资水平。 1.15 数据库服务冗余架构 1.15.1 数据库服务高可用前言介绍 数据库中的高可用功能，主要是用于避免数据库服务或数据信息的损坏问题，其中数据损坏的类型有： 数据物理损坏：磁盘、主机、程序实例、数据文件误删除 数据逻辑损坏：drop update … 其中，数据库高可用技术的出现主要解决的是数据逻辑损坏问题，而主从架构技术主要解决的是数据物理损坏问题； 数据库高可用解决方案选型依据：（全年无故障率） 1.15.2 数据库服务高可用软件介绍 MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton研发， 此人目前就职于Facebook公司，MHA是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。 MySQL进行故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换过程中； MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 MHA主要有两部分组成： MHA Manager（管理节点） 可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave上。 MHA Node（数据节点） 运行在每台MySQL服务器上 MHA Manager 会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master； 然后将所有其他的slave重新指向新的master，整个故障转移过程对应用程序是完全透明的； MHA软件结构介绍：（MHA中的所有组件就是perl语言编写的功能脚本） 节点信息 软件组件 作用介绍 MHA Manager（管理节点） masterha_manger 用于启动MHA masterha_check_ssh 用于检查MHA的SSH配置互信状况 ...

基础章节-01-MySQL数据库服务中级课程 1.00 课程知识章节说明 目前在互联网的实际应用中，各个企业都会比较关注自身网站的数据信息，既要保证数据信息的安全性，同时也要保证数据存储读取效率 并且在特殊的场景下，还要对存储的数据信息进行检索和分析；因此数据库服务业务已经在各行各业应用非常的广泛 对于互联网领域的技术人员，对于数据库服务知识的掌握，也将是在求职时必备的技能，有些时候还会绝对入职的定级和薪资水平。 1.19 数据库服务分区应用 1.19.1 数据库服务分区概述 MySQL从5.1版本开始支持分区的功能；分区是指根据一定的规则，数据库把一个大表分解成多个更小的、更容易管理的部分； 通俗说明：表分区就是将一个大表，根据条件分割成若干个小表； 日常项目开发中经常会遇到大表的情况，所谓大表是指存储了百万级乃至千万级条记录的表。 这样的表过于庞大，导致数据库在查询和插入的时候耗时太长，性能低下；如果涉及联合查询情况，性能会更加糟糕； 对表进行分区，目的就是减少数据库的负担，提高数据库的效率，通常来讲就是提高表的增删改查效率 分区是将数据分段划分在多个位置存放，可以是同一块磁盘也可以在不同的机器； 分区后，表面上还是一张表，但数据散列到多个位置了； 应用程序读写的时候操作的还是大表名字，数据库系统自动去组织分区的数据 就访问数据库的应用而言，逻辑上只有一个表或一个索引，但是实际上这个表可能由数10个物理分区对象组成； 每个分区都是一个独立的对象，可以独自处理，可以作为表的一部分进行处理 分区对应用来说是完全透明的，不影响应用的业务逻辑 例如：某个用户表的记录超过了600万条会员信息，那么就可以根据入会日期将表分区，也可以根据所在地将表分区； 当然也可以根据其他的条件分区； 为了改善大型表以及具有各种访问模式的表的可伸缩性，可管理性和提高数据库效率，因此具有了对表分区的需求； MySQL分区的优点主要包括以下4个方面： 和单个磁盘或者文件系统分区相比，可以存储更多数据；（ext2分区单个文件2T ext3 ext4分区单个文件16T） 优化查询，在where子句中包含分区条件时，可以只扫描必要的一个或多个分区来提高查询效率； 使一些查询操作可以得到极大的优化； 对于已经过期或者不需要保存的数据，可以通过删除与这些数据有关的分区来快速删除数据； 通过删除与增加那些数据有关的分区，很容易地删除或增加那些数据； 通过跨多个磁盘甚至服务器来分散数据查询，以获得更大的查询吞吐量； 在MySQL5.5之后支持所有函数的分区优化，限定只查询有效数据的分区 同时在涉及SUM()和COUNT()这类聚合函数的查询时，可以容易地在每个分区上并行处理，最终只需要汇总所有分区得到的结果 1.19.2 数据库服务分区技术 分区有利于管理非常大的表，它采用了"分而治之"的逻辑，分区引入了分区键（partition-key）的概念； 分区键用于根据某个区间值（或者范围值）、特定值列表或者HASH函数值执行数据的聚集，让数据根据规则分布在不同的分区中； 最终让一个大对象变成一些小对象。 1.19.3 数据库服务分区类型(mycat 分布式存储策略–分表策略) *** 对于MySQL基本常用的分区类型有：基本分区类型 RANGE分区： 基于属于一个给定连续区间的列值，把多行分配给分区； 1 select count(*) from employees where gender='F'; LIST分区： 类似于按RANGE分区，区别在于LIST分区是基于列值匹配一个离散值集合中的某个值来进行选择； HASH分区： 基于用户定义的表达式的返回值来进行选择的分区，该表达式使用将要插入到表中的这些行的列值进行计算； 这个函数可以包含MySQL中有效的，产生非负整数值的任何表达式 KEY分区： 类似于按HASH分区，区别在于KEY分区只支持计算一列或多列，且MySQL服务器提供其自身的哈希函数。必须有一列或多列包含整数值 实战演示分区操作：RANGE分区 基于属于一个给定连续区间的列值，把多行分配给分区； 这些区间要连续且不能相互重叠，使用values less than操作符来进行定义 创建分区操作：在创建表的过程中也可以直接创建分区 例如：将用户表按照年龄每个10岁进行分区； 注意：分区的名字基本上遵循其他MySQL标识符应当遵循的原则，但是分区的名字是不区分大小写的； 在数据表进行分区操作后，会发现表的空间文件发生了拆分变化； ...

基础章节-01-MySQL数据库服务中级课程 1.00 课程知识章节说明 目前在互联网的实际应用中，各个企业都会比较关注自身网站的数据信息，既要保证数据信息的安全性，同时也要保证数据存储读取效率 并且在特殊的场景下，还要对存储的数据信息进行检索和分析；因此数据库服务业务已经在各行各业应用非常的广泛 对于互联网领域的技术人员，对于数据库服务知识的掌握，也将是在求职时必备的技能，有些时候还会绝对入职的定级和薪资水平。 1.19 数据库服务分区应用 1.19.1 数据库服务分区概述 MySQL从5.1版本开始支持分区的功能；分区是指根据一定的规则，数据库把一个大表分解成多个更小的、更容易管理的部分； 通俗说明：表分区就是将一个大表，根据条件分割成若干个小表； 日常项目开发中经常会遇到大表的情况，所谓大表是指存储了百万级乃至千万级条记录的表。 这样的表过于庞大，导致数据库在查询和插入的时候耗时太长，性能低下；如果涉及联合查询情况，性能会更加糟糕； 对表进行分区，目的就是减少数据库的负担，提高数据库的效率，通常来讲就是提高表的增删改查效率 分区是将数据分段划分在多个位置存放，可以是同一块磁盘也可以在不同的机器； 分区后，表面上还是一张表，但数据散列到多个位置了； 应用程序读写的时候操作的还是大表名字，数据库系统自动去组织分区的数据 就访问数据库的应用而言，逻辑上只有一个表或一个索引，但是实际上这个表可能由数10个物理分区对象组成； 每个分区都是一个独立的对象，可以独自处理，可以作为表的一部分进行处理 分区对应用来说是完全透明的，不影响应用的业务逻辑 例如：某个用户表的记录超过了600万条会员信息，那么就可以根据入会日期将表分区，也可以根据所在地将表分区； 当然也可以根据其他的条件分区； 为了改善大型表以及具有各种访问模式的表的可伸缩性，可管理性和提高数据库效率，因此具有了对表分区的需求； MySQL分区的优点主要包括以下4个方面： 和单个磁盘或者文件系统分区相比，可以存储更多数据；（ext2分区单个文件2T ext3 ext4分区单个文件16T） 优化查询，在where子句中包含分区条件时，可以只扫描必要的一个或多个分区来提高查询效率； 使一些查询操作可以得到极大的优化； 对于已经过期或者不需要保存的数据，可以通过删除与这些数据有关的分区来快速删除数据； 通过删除与增加那些数据有关的分区，很容易地删除或增加那些数据； 通过跨多个磁盘甚至服务器来分散数据查询，以获得更大的查询吞吐量； 在MySQL5.5之后支持所有函数的分区优化，限定只查询有效数据的分区 同时在涉及SUM()和COUNT()这类聚合函数的查询时，可以容易地在每个分区上并行处理，最终只需要汇总所有分区得到的结果 1 select count(*) from employees where gender='F'; 1.19.2 数据库服务分区技术 分区有利于管理非常大的表，它采用了"分而治之"的逻辑，分区引入了分区键（partition-key）的概念； 分区键用于根据某个区间值（或者范围值）、特定值列表或者HASH函数值执行数据的聚集，让数据根据规则分布在不同的分区中； 最终让一个大对象变成一些小对象。 1.19.3 数据库服务分区类型(mycat 分布式存储策略–分表策略) *** 对于MySQL基本常用的分区类型有：基本分区类型 RANGE分区： 基于属于一个给定连续区间的列值，把多行分配给分区； LIST分区： 类似于按RANGE分区，区别在于LIST分区是基于列值匹配一个离散值集合中的某个值来进行选择； HASH分区： 基于用户定义的表达式的返回值来进行选择的分区，该表达式使用将要插入到表中的这些行的列值进行计算； 这个函数可以包含MySQL中有效的，产生非负整数值的任何表达式 KEY分区： 类似于按HASH分区，区别在于KEY分区只支持计算一列或多列，且MySQL服务器提供其自身的哈希函数。必须有一列或多列包含整数值 实战演示分区操作：RANGE分区 基于属于一个给定连续区间的列值，把多行分配给分区； 这些区间要连续且不能相互重叠，使用values less than操作符来进行定义 创建分区操作：在创建表的过程中也可以直接创建分区 例如：将用户表按照年龄每个10岁进行分区； ...

背景 Switch2 直连家庭宽带访问日本、香港等海外服务器时延迟很高，体验极差。本地 PC 上已经运行了 Clash Verge 代理，可以快速连接香港、日本节点。目标是让 Switch2 的流量也走 PC 的代理。 方案选择 有三种方案可以实现： 方案 原理 优点 缺点 PC 热点共享代理 PC 开热点，Switch2 连热点走代理 零成本，快速配置 PC 需要一直开着 路由器刷 OpenWrt + Clash 全屋透明代理 一劳永逸 需要额外购买或刷机 PC 软路由 PC 网线直连 Switch2 不买设备 配置复杂 本文选择方案一：PC 热点共享代理，最简单实用。 环境说明 PC 系统：Windows 11 代理软件：Clash Verge，混合端口 7897 PC 上网方式：有线以太网 PC 热点网卡 IP：192.168.137.1 配置步骤 第一步：Clash Verge 设置 打开 Clash Verge → 设置 开启系统代理 开启允许局域网（Allow LAN） 确认端口设置为 7897 注意：不要开启 TUN（虚拟网卡）模式，TUN 模式会与 Windows 热点冲突，导致所有网络断开。 ...

一、为什么需要两阶段提交 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 未写入 ❌ 后果: ...

前言 在 MySQL 备份实践中，mysqldump --single-transaction --master-data=2 是最常见的组合。但很多 DBA 只知道"这样用不锁表"，却不清楚底层原理。今天我们深入剖析这两个参数的工作机制，以及为什么它们必须配合使用。 一、MVCC 可见性规则（理论基础） 在理解 --single-transaction 之前，必须先掌握 InnoDB 的 MVCC 机制。 1.1 Read View 结构 当事务执行 START TRANSACTION WITH CONSISTENT SNAPSHOT 时，InnoDB 会创建一个 Read View： 1 2 3 4 5 6 7 struct read_view_t { trx_id_t m_low_limit_id; // 系统中尚未分配的最小事务ID（当前最大事务ID + 1） trx_id_t m_up_limit_id; // 活跃事务列表中的最小事务ID trx_id_t m_creator_trx_id; // 创建此 Read View 的事务ID trx_id_t *m_ids; // 创建 Read View 时的活跃事务ID数组（降序） ulint m_n_trx_ids; // 活跃事务数量 }; 注意：InnoDB 的命名反直觉 m_low_limit_id 虽然叫 “low limit”，但实际是最大值（下一个要分配的事务ID） m_up_limit_id 虽然叫 “up limit”，但实际是最小值（最小活跃事务ID） 1.2 可见性判断规则 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 def is_visible(row_trx_id, read_view): # 规则1：如果是当前事务自己修改的，可见 if row_trx_id == read_view.m_creator_trx_id: return True # 规则2：如果行的事务ID < m_up_limit_id（最小活跃事务ID），说明在 Read View 创建前已提交，可见 if row_trx_id < read_view.m_up_limit_id: return True # 规则3：如果行的事务ID >= m_low_limit_id（下一个要分配的ID），说明在 Read View 创建后才开始，不可见 if row_trx_id >= read_view.m_low_limit_id: return False # 规则4：如果在 [m_up_limit_id, m_low_limit_id) 区间内 # 需要检查是否在活跃事务列表 m_ids 中 if row_trx_id in read_view.m_ids: return False # 在活跃列表中，说明创建 Read View 时未提交，不可见 else: return True # 不在活跃列表中，说明已提交，可见 可见性判断示例： ...