update toc

txz1994 · Mar 20, 2022 · adff8a2 · adff8a2
1 parent 6a6ee53
commit adff8a2
Show file tree

Hide file tree

Showing 6 changed files with 257 additions and 261 deletions.
diff --git a/src/main/java/com/learning/algorithm/ALGORITHM.md b/src/main/java/com/learning/algorithm/ALGORITHM.md
@@ -1166,7 +1166,7 @@ class Solution {
 1. 定义dp：两字符串的动态规划问题，经常的就是以字符串1与字符串2的长度组成二维数组。
 2. 定义下标及含义：dp的含义经常就是求解的结果，下标为从0～i、j的两字符串的子问题
 3. 状态转移公式：主要考虑以下三个的状态转移
-  - `dp[i-1][j-1]`: 匹配条件的，结果顺推
+  - `dp[i-1][j-1]`: 匹配条件的，结果顺推。如子数组匹配问题
   - `dp[i-1][j]`
   - `dp[i][j-1]`
 4. 初始化
@@ -1226,7 +1226,7 @@ class Solution {
 }
 ```
 
-- *[回文子串](https://leetcode-cn.com/problems/palindromic-substrings/)
+- [回文子串](https://leetcode-cn.com/problems/palindromic-substrings/): review
 - [最长回文子序列](https://leetcode-cn.com/problems/longest-palindromic-subsequence/)
 
 
@@ -1249,7 +1249,7 @@ public class StockTrading {
      * 下标j：第j次交易
      * 下标k：0买入、1卖出
      * 
-     * 2. 初始化，由于dp代表的是第i天所能获取的最大利润，第0天卖出均要初始化成-price[0]
+     * 2. 初始化，由于dp代表的是第i天所能获取的最大利润，第0天卖出均要初始化成-price[0]。(可以理解为与次数不挂钩，仅进行一次交易)
      * 
      * 3. 状态转移：
      *   dp[i][j][0] = Math.max(dp[i-1][j][0], dp[i-1][j][1] + prices[i]);

diff --git a/src/main/java/com/other/MYSQL.md b/src/main/java/com/other/MYSQL.md
@@ -344,14 +344,14 @@ Innodb 为解决幻读问题引入了间隙锁+行锁充当范围锁
 隔离级别是读已提交，两次重复执行的查询结果就会不一样，原因是读已提交的隔离级别缺乏贯穿整个事务周期的读锁，无法禁止读取过的数据发生变化。
 > 读已提交对事务涉及的数据加的写锁会一直持续到事务结束，但**加的读锁在查询操作完成后就马上会释放**。读已提交比可重复读弱化的地方在于不可重复读问题
 
-### 脏读解决
+#### 脏读解决
 例子：
 1. 事务A对于事务内修改的数据T1添加写锁。
 2. 事务B想读取数据T1会先加读锁，而数据T1已经被加了写锁，想加读锁就得等待事务A处理结束。
 
 事务B处理数据T1必须等事务A结束，解决了读未提交破坏了事务隔离性问题，实现了读取的数据都是已提交的数据，不会被回滚，即读已提交。
 
-### 不可重复读问题出现
+#### 不可重复读问题出现
 例子：
 1. 事务A对于事务内修改的数据T1添加写锁，查询数据T2时候使用读锁进行查询，查询完成释放读锁。
 2. 事务A事务处理期间，事务B对数据T2进行了修改，因为数据T2现在未添加任何锁，可以被加写锁进行修改。
@@ -580,7 +580,9 @@ sync_binlog这个参数设置成1的时候，表示每次事务的binlog都持
     > binlog作为MySQL一开始就有的功能，被用在了很多地方。其中，MySQL系统高可用的基础，就是binlog复制\
     很多公司有异构系统（比如一些数据分析系统） ，这些系统就靠消费MySQL的binlog来更新自己的数据。
 
-参考文章：[MySQL 2PC & Group Commit](https://segmentfault.com/a/1190000014810628)
+参考文章：
+- [MySQL 2PC & Group Commit](https://segmentfault.com/a/1190000014810628)
+- [MySQL InnoDB Crash Safe](https://www.modb.pro/db/74297): 崩溃恢复流程
 ### 两种日志区别
 1. redo log是InnoDB引擎特有的； binlog是MySQL的Server层实现的，所有引擎都可以使用。
 2. redo log是物理日志，记录的是“在某个数据页上做了什么修改”； binlog是逻辑日志，记录的是这个语句的原始逻辑，比如“给ID=2这一行的c字段加1 ”。
@@ -589,7 +591,6 @@ sync_binlog这个参数设置成1的时候，表示每次事务的binlog都持
 
 
 ### 两阶段提交的组提交机制执行流程
-
 crash-safe的参数设置会导致频繁的刷盘，在高TPS下容易达到磁盘能力的瓶颈。\
 MySQL为了让组提交的效果更好，把redo log做fsync的时间拖到了binlog write 之后，整体的提交流程改成如下：
 ![image](https://gitee.com/rbmon/file-storage/raw/main/learning-note/other/mysql/actualWrite.jpg)