7.25 leetcode+数据库

leetcode刷题总结:

二叉树上进行统计问题:

leetcode 437：路径总和Ⅲ

当需要在二叉树上统计某一个值得时候，我在这里提出了两种理解方式:

1. 树的单节点统计量
        例如在本题中需要统计的是所有路径，所有路径可以按照以每一个节点起始满足要求的路径来进行求和。所以树的全局统计量问题可以转化为树的单节点统计量。
        如何解决单节点统计量呢？首先需要明确这个统计量如何计算,例如在本题中该统计量不能单单通过一个节点的值求得，还得继续往下求。想象树所有节点之间都可以进行消息传递：总结我们的递归代码可以抽象成下列模式:
        

单点统计量计算函数(root,判断依据)
{
    if(root==nullptr)
    {
        return ;
    }

    计算该节点统计量(可有可无)
        
    left = 单点统计量计算函数(root->left, 新判断依据)
    right = 单点统计量计算函数(root->right, 新判断依据)
    
    该节点向上返回统计量 = caculate(left,right,本节点)

    return 该节点向上统计量
}

回到本题的代码来,本题的单节点统计量其实计算的是，以该节点为起点的，满足和等同于target的节点的个数:

int rootSum(TreeNode* root, long targetSum) {
        if (!root) {
            return 0;
        }
           

        int ret = 0;//统计量，统计root节点开始的满足要求的节点数目
        if (root->val == targetSum) {
            ret++;
        } //如果树节点满足则本身就要+1，这里不return是因为可能还会有

        ret += rootSum(root->left, targetSum - root->val);//去左边判断是否还有节点满足条件
        ret += rootSum(root->right, targetSum - root->val);//去右边判断是否满足条件
        
        return ret;//传递消息
    }

2. 树的全局统计量

全局其实就是在单点的基础上再加上一次遍历:

    int pathSum(TreeNode* root, long targetSum) {
        if (!root) {
            return 0;
        }
        
        int ret = rootSum(root, targetSum);

        ret += pathSum(root->left, targetSum);
        ret += pathSum(root->right, targetSum);
        return ret;
    }

leetcode236:二叉树的最近公共祖先
 先分析一下，这个题需要找出来公共节点是哪个，左边获取信息，右边获取信息。处理信息。

 bool dfs(TreeNode* root, TreeNode* p, TreeNode* q) {
        if (root == nullptr) return false;

        bool lson = dfs(root->left, p, q);
        bool rson = dfs(root->right, p, q);

        if ((lson && rson) || ((root->val == p->val || root->val == q->val) && (lson || rson))) {
            ans = root;
        } 

        return lson || rson || (root->val == p->val || root->val == q->val);
        
    }

如果需要从中取出一个ans则需要设置一个全局变量。

 leetcode124: 二叉树最大路径:

最这样的字眼实际上是一个单节点统计量,因此只需要再外面设置一个全局变量取答案就行。然后该任务可以划分为经过各个节点的路径和。

int ans = MIN_ANS;

int maxrootSum(TreeNode* root)
{
    if(root == nullptr) return 0;
    
    int sum = root->val;
    
    //是否需要加左边的值？左边的值应当是左边可能的最大值
    int sum_l = max(maxrootSum(root->left),0);
    int sum_r = max(maxrootSum(root->right),0);

    //计算符合题目要求的统计量
    maxSum = max(maxSum,sum_l+sum_r+root->val);
    
    //返回这个节点的"奉献"
    return root->val + max(sum_l,sum_r);
    
}

---

继续学一学MySQL:平时MySQL会突然抖一下是为什么呢？其实是因为数据库在把redo log的日志写入磁盘。这个过程称之为flush：

那么，什么情况会引发数据库的 flush 过程呢？

第一种场景是，粉板满了，记不下了。

第二种场景是，这一天生意太好，要记住的事情太多，掌柜发现自己快记不住了，赶紧找出账本把孔乙己这笔账先加进去。这种场景，对应的就是系统内存不足。当需要新的内存页，而内存不够用的时候，就要淘汰一些数据页，空出内存给别的数据页使用。

第三种场景是，生意不忙的时候，或者打烊之后。这时候柜台没事，掌柜闲着也是闲着，不如更新账本。

第四种场景是，年底了咸亨酒店要关门几天，需要把账结清一下。

一旦一个查询请求需要在执行过程中先 flush 掉一个脏页时，这个查询就可能要比平时慢了。而 MySQL 中的一个机制，可能让你的查询会更慢：在准备刷一个脏页的时候，如果这个数据页旁边的数据页刚好是脏页，就会把这个“邻居”也带着一起刷掉；而且这个把“邻居”拖下水的逻辑还可以继续蔓延，也就是对于每个邻居数据页，如果跟它相邻的数据页也还是脏页的话，也会被放到一起刷。

会导致慢查询!找“邻居”这个优化在机械硬盘时代是很有意义的，可以减少很多随机 IO。机械硬盘的随机 IOPS 一般只有几百，相同的逻辑操作减少随机 IO 就意味着系统性能的大幅度提升。

删除数据表为什么空间占用不变？

参数 innodb_file_per_table

表数据既可以存在共享表空间里，也可以是单独的文件。这个行为是由参数 innodb_file_per_table 控制的：

1. 这个参数设置为 OFF 表示的是，表的数据放在系统共享表空间，也就是跟数据字典放在一起；

2. 这个参数设置为 ON 表示的是，每个 InnoDB 表数据存储在一个以 .ibd 为后缀的文件中。

从 MySQL 5.6.6 版本开始，它的默认值就是 ON 了。

我建议你不论使用 MySQL 的哪个版本，都将这个值设置为 ON。因为，一个表单独存储为一个文件更容易管理，而且在你不需要这个表的时候，通过 drop table 命令，系统就会直接删除这个文件。而如果是放在共享表空间中，即使表删掉了，空间也是不会回收的。

删除行数据:

InnoDB靠着主键组织数据，因此当删除某一行数据的时候只是把这个数据标记为可以修改而已。但是实际的空间大小并没有减少，具体来说就是不能被用作除过InnoDB存储以外的其他用途。但是如果对于一个内存页上的数据全部删除，则这个内存页就可以释放了。

会产生空洞问题，由于数据库的数据组织方式，为了消除空洞，最好的办法就是重新把B拷贝到A，实现这样的紧凑数据。在MySQL5.5之前都是offline操作。之后改为了online操作。

我给你简单描述一下引入了 Online DDL 之后，重建表的流程：

1. 建立一个临时文件，扫描表 A 主键的所有数据页；

2. 用数据页中表 A 的记录生成 B+ 树，存储到临时文件中；

3. 生成临时文件的过程中，将所有对 A 的操作记录在一个日志文件（row log）中，对应的是图中 state2 的状态；

4. 临时文件生成后，将日志文件中的操作应用到临时文件，得到一个逻辑数据上与表 A 相同的数据文件，对应的就是图中 state3 的状态；

5. 用临时文件替换表 A 的数据文件。

Online DDL 最耗时的过程就是拷贝数据到临时表的过程，这个步骤的执行期间可以接受增删改操作。

如果说这两个逻辑之间的关系是什么的话，可以概括为：

1. DDL 过程如果是 Online 的，就一定是 inplace 的；

2. 反过来未必，也就是说 inplace 的 DDL，有可能不是 Online 的。截止到 MySQL 8.0，添加全文索引（FULLTEXT index）和空间索引 (SPATIAL index) 就属于这种情况。
    

如果要收缩一个表，只是 delete 掉表里面不用的数据的话，表文件的大小是不会变的，你还要通过 alter table 命令重建表，才能达到表文件变小的目的。我跟你介绍了重建表的两种实现方式，Online DDL 的方式是可以考虑在业务低峰期使用的，而 MySQL 5.5 及之前的版本，这个命令是会阻塞 DML 的，这个你需要特别小心。

收缩之后还变大：

本来就很紧凑，没能整出多少剩余空间。
重新收缩的过程中，页会按90%满的比例来重新整理页数据（10%留给UPDATE使用），
未整理之前页已经占用90%以上，收缩之后，文件就反而变大了。

Count(*)的实现方式:

缓存系统更新：必然导致缓存一致性问题，即插入数据了，但是还没能即使更新计数，就被读走了。因此不靠谱。

采用事务的方式，利用事务之间的隔离性，和一致性来解决这种并发问题。

count(字段)<count(主键 id)<count(1)≈count(*)