悟世之路

2023-11-18 mysql-sysbench压测TPS/QPS

2023-11-14 mysql-主从复制-相关文档。

在MySQL5.7 引入基于Logical clock的并行复制方案前，MySQL使用基于Schema的并行复制，使不同db下的DML操作可以在备库并发回放。在优化后，可以做到不同表table下并发。但是如果业务在Master端高并发写入一个库（或者优化后的表），那么slave端就会出现较大的延迟。

mysql的主从复制, 当从库执行binlog出错后, 会中止主从复制.此时需要重置主从连接, 以重建主从关系.

2023-10-17 mysql-innodb-解析write_row的record的一行数据-分析.record是一行数据的序列化后的一整个字节流, 在innodb中需要解读出字段.本文分析如何解析record, 以便学习这种技巧.

2023-10-17 mysql-从库从binlog回放事件-分析。

2023-10-17 mysql-配置主从-记录。

2023-10-10 mysql-{mysql_create_db}-失败后回滚-记录。

2023-10-10 mysql-{mysql_rm_db}-失败后回滚-记录。

2023-10-10 mysql-{rea_create_base_table}-失败后回滚-记录。

2023-10-10 mysql-{mysql_rm_table_no_locks}-出错后回滚-记录。

2023-10-10 mysql-{mysql_alter_table}-出错后回滚-记录。

记录mysql的表名前可以有多少层级。

2023-09-27 mysql8-设置远端链接-记录。

2023-09-14 mysql-Item_subselect-分析

2023-07-24 mysql-load加载数据-记录。

【代码】2023-06-27 myql5.7-Switchable Optimizations。

在分析包含内连接的嵌套外连接的过程中, 发现optimizer_switch参数derived_merge控制多个表连接是否使用派生表, 本文对其做分析.

对mysql5.7的嵌套循环连接的执行做分析, 从执行计划和执行流程的不同角度分析块嵌套循环连接的执行细节.上下文: 2023-06-25 mysql-包含内连接的嵌套外连接-JOIN_condition_to_WHERE-分析_财阀悟世的博客-CSDN博客2023-06-25 mysql-嵌套循环优化-块嵌套循环算法-分析_财阀悟世的博客-CSDN博客 JSON格式执行计划（6）—mysql执行计划（五十二) - 知乎rows_examined_per_scan 可以看作该表的扫描行数rows

mysql对于连接的处理最基本的就是嵌套循环, 有几个表就对着做几层循环.这种做法导致整体的时间复杂度达到了U*R*S, 对于朴素的嵌套循环的算法, 优化的目标就是减少整体的嵌套循环的次数.一种做法是条件变换, 将条件尽可能的以降低循环次数的目标做修剪。另一种做法是使用中间结果, 加快整体的循环处理。本文分析块嵌套循环算法就是使用中间结果的做法。需要注意BNL在mysql8.0.20中被hash join算法取代。

对mysql的join的条件优化中的JOIN_condition_to_WHERE做分析, 分析该条件优化规则为什么要这么做, 要达到什么样的目的, 对查询执行的代价的改变。

mysql的查询优化器和查询执行器采用了经典的火山模型, 从mysql5.0开始一直到mysql8.0都保持了火山模型.这么做有其自身的考虑, 火山模型是一个非常经典的模型, 但是其他一些列数据库的优化方向倒是从摒弃火山模型转而使用物化模型而进行.本文做一些反思.

在mysql/sql层的查询优化和查询执行的处理中, JOIN这个数据结构或者说类处于核心地位.本文分析SELECT_LEX, SELECT_UNION, JOIN, JOIN_TAB与表之间的关系.

【代码】2023-05-29 mysql-Nested Join Optimization。

2）对于left join，左表的谓词条件放在on不会对左表数据进行过滤，依然显示左表全部数据，放在where才会对左表进行过滤，右表谓词条件无论放在on，还是where，都会对右表先过滤再连接，但是放在where，left join会转换为inner join。2）如果业务逻辑明确要求使用left join，则不能把被驱动表的字段放在where后面做等值或不等值判断，必须都写在on后面，否则优化器就会转换，使用join...where的语法进行改写；

InnoDB 有两块非常重要的日志，一个是undo log，另外一个是redo log，前者用来保证事务的原子性以及InnoDB的MVCC，后者用来保证事务的持久性。和大多数关系型数据库一样，InnoDB记录了对数据文件的物理更改，并保证总是日志先行，也就是所谓的WAL，即在持久化数据文件前，保证之前的redo日志已经写到磁盘。LSN(log sequence number) 用于记录日志序号，它是一个不断递增的 unsigned long long 类型整数。

Undo log是InnoDB MVCC事务特性的重要组成部分。当我们对记录做了变更操作时就会产生undo记录，Undo记录默认被记录到系统表空间(ibdata)中，但从5.6开始，也可以使用独立的Undo 表空间。Undo记录中存储的是老版本数据，当一个旧的事务需要读取数据时，为了能读取到老版本的数据，需要顺着undo链找到满足其可见性的记录。当版本链很长时，通常可以认为这是个比较耗时的操作（例如bug#69812。

Handling an Unexpected Halt of a Replica

innodb崩溃恢复

mysql/sql的查询优化器, 会将子查询中的嵌套join进行上拉，形成一个平坦的join列表.这样形成一个平坦的join的列表, 便于两两之间逐个的join操作.本文对其进行分析.

mysql导入ssb数据测试。

分析mysql对于谓词的处理。

子查询优化中的策略一个非常经典的便是将子查询的表进行物化, 也就是先将子查询执行出来放到一个临时表中, 然后将子查询转换成表之间特殊的join操作.本文着重分析mysql如何实现子查询的物化.上下文相关: https://adofsauron.blog.csdn.net/article/details/129379751tpch-q16

简单记录下innodb所处理的磁盘文件。

事务是数据库的一个很重要的点, 无论如何都绕不开, 尤其是对于TP系统来说没有事务是不可想象的。本文对innodb的事务的实现进行一些反思。

由于InnoDB加锁的类型和事务的隔离级别以及记录的类型（主键索引，二级索引，唯一索引等等）有着密切的联系，不同类型和事务隔离级别会导致同一条语句在同一条记录上上锁的类型也可能完全不同。

Read view是实现多版本并发控制（mvcc）中的一个重要的数据结构。Read view也可以称作是快照。其用来描述当前数据库中的存在的事务情况。因为数据的可见性与事务息息相关。

mysql-innodb-mvcc-锁-分析MySQL :: MySQL 8.0 Reference Manual :: 15.3 InnoDB Multi-VersioningUnderstanding InnoDB MVCC

mysql中对于in的子查询, 会尝试将in转换为exists, 本文分析改策略。

对于普通的相关子查询, mysql一般采用条件上拉操作进行优化, 就是将子查询中，与和外表关联的条件，从子查询中上拉出去。好处便是这样做了之后, 更便于将内表和外表转换为join操作。以利用join的优化策略进行进一步优化。本文以TPCH-Q16的变体为例, 分析条件上拉优化。