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 控制的:
-
这个参数设置为 OFF 表示的是,表的数据放在系统共享表空间,也就是跟数据字典放在一起;
-
这个参数设置为 ON 表示的是,每个 InnoDB 表数据存储在一个以 .ibd 为后缀的文件中。
从 MySQL 5.6.6 版本开始,它的默认值就是 ON 了。
我建议你不论使用 MySQL 的哪个版本,都将这个值设置为 ON。因为,一个表单独存储为一个文件更容易管理,而且在你不需要这个表的时候,通过 drop table 命令,系统就会直接删除这个文件。而如果是放在共享表空间中,即使表删掉了,空间也是不会回收的。
删除行数据:
InnoDB靠着主键组织数据,因此当删除某一行数据的时候只是把这个数据标记为可以修改而已。但是实际的空间大小并没有减少,具体来说就是不能被用作除过InnoDB存储以外的其他用途。但是如果对于一个内存页上的数据全部删除,则这个内存页就可以释放了。
会产生空洞问题,由于数据库的数据组织方式,为了消除空洞,最好的办法就是重新把B拷贝到A,实现这样的紧凑数据。在MySQL5.5之前都是offline操作。之后改为了online操作。
我给你简单描述一下引入了 Online DDL 之后,重建表的流程:
-
建立一个临时文件,扫描表 A 主键的所有数据页;
-
用数据页中表 A 的记录生成 B+ 树,存储到临时文件中;
-
生成临时文件的过程中,将所有对 A 的操作记录在一个日志文件(row log)中,对应的是图中 state2 的状态;
-
临时文件生成后,将日志文件中的操作应用到临时文件,得到一个逻辑数据上与表 A 相同的数据文件,对应的就是图中 state3 的状态;
-
用临时文件替换表 A 的数据文件。
Online DDL 最耗时的过程就是拷贝数据到临时表的过程,这个步骤的执行期间可以接受增删改操作。
如果说这两个逻辑之间的关系是什么的话,可以概括为:
-
DDL 过程如果是 Online 的,就一定是 inplace 的;
-
反过来未必,也就是说 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(*)