什么也无法舍弃的人,什么也改变不了。 --《进击的巨人》by 阿尔敏
这是一个非常简单的题目
给你一个数组 candies 和一个整数 extraCandies ,其中 candies[i] 代表第 i 个孩子拥有的糖果数目。
对每一个孩子,检查是否存在一种方案,将额外的 extraCandies 个糖果分配给孩子们之后,此孩子有 最多 的糖果。注意,允许有多个孩子同时拥有 最多 的糖果数目。
示例 1:
输入:candies = [2,3,5,1,3], extraCandies = 3
输出:[true,true,true,false,true]
解释:
孩子 1 有 2 个糖果,如果他得到所有额外的糖果(3个),那么他总共有 5 个糖果,他将成为拥有最多糖果的孩子。
孩子 2 有 3 个糖果,如果他得到至少 2 个额外糖果,那么他将成为拥有最多糖果的孩子。
孩子 3 有 5 个糖果,他已经是拥有最多糖果的孩子。
孩子 4 有 1 个糖果,即使他得到所有额外的糖果,他也只有 4 个糖果,无法成为拥有糖果最多的孩子。
孩子 5 有 3 个糖果,如果他得到至少 2 个额外糖果,那么他将成为拥有最多糖果的孩子。
示例 2:
输入:candies = [4,2,1,1,2], extraCandies = 1
输出:[true,false,false,false,false]
解释:只有 1 个额外糖果,所以不管额外糖果给谁,只有孩子 1 可以成为拥有糖果最多的孩子。
示例 3:
输入:candies = [12,1,12], extraCandies = 10
输出:[true,false,true]
提示:
2 <= candies.length <= 100
1 <= candies[i] <= 100
1 <= extraCandies <= 50
- 计算最大数值
- 遍历 增加 糖果数量 依次对比
- 返回最后结果 list
class Solution:
def kidsWithCandies(self, candies: list[int], extraCandies: int) -> list[bool]:
res= []
candies_max = max(candies)
for i in candies:
res.append(True if i+extraCandies >= candies_max else False)
return res
If You Want to Be a Senior Developer, Stop Focusing on Syntax
这片文章,主要借用,通过地图,也可以在陌生城市找到目的地,同时熟悉以后,可以摆脱地图达到目的地。 类比现在的工程师行业,每天都在不断的变化和更新,一个人是不可能学会所有的语法,会使用 python golang java net lua js 等。 这些对于你以后的发展会有哪些好处?所以如果可以更加需要的是深入理解底层核心部分,不论哪一种,底层核心的变化其实都不是很大。
文章说的确实是有一定的道理,同时也要相对的扎根当前和不久的将来,同时也要参考未来,进行一个相对平衡的点的确定,这样的才会尽量在以后不会后悔。 同时也保证了方向上的正确性。
- 初级开发师 确实需要学习 一些基础的 语法,因为需要工作和生活,这部分需要的就是快速学习,尽量对比的学习,同时能够做到类比,比较两者之间的不同,以及为什么会不同,这样的一个深度。
- 中级工程师 就要对底层有一定的了解,因为万事万物 都是 殊途同归,所以需要对于底层有一定的了解,比如:不同的语言,他的 gc/内存分配 算法调度 等等都是需要需要思考。尽可能的脱离语法/语言 去思考。
- 高级工程师 就是已经对于底层有了深入了解,能够建立一套完整的体系,包含了从 CPU运行/调度 内存 磁盘IO 等等,做到 庖丁解牛的地步。
- 架构师级别 是能够从 业务 角度 去看待技术,采用的架构,需要平衡 现在/近期/未来。
-
哈希索引:
- 通过算法,计算获得其磁盘位置,然后直接读取IO,获取数据。
- 对于 等值查询 是非常不错的方式
- 不支持范围查询,同时如果哈希结果一样,等同于遍历方式。
-
BTS 索引:
-
AVL 索引:
-
红黑树:
-
B树
-
B+树
- 区别
- B树中每个节点(包括叶节点和非叶节点)都存储真实的数据,B+树中只有叶子节点存储真实的数据,非叶节点只存储键。在MySQL中,这里所说的真实数据,可能是行的全部数据(如Innodb的聚簇索引),也可能只是行的主键(如Innodb的辅助索引),或者是行所在的地址(如MyIsam的非聚簇索引)。
- B树中一条记录只会出现一次,不会重复出现,而B+树的键则可能重复重现——一定会在叶节点出现,也可能在非叶节点重复出现。
- B+树的叶节点之间通过双向链表链接。
- B树中的非叶节点,记录数比子节点个数少1;而B+树中记录数与子节点个数相同。
- 区别
为什么选择B+树?而MongoDB 使用B树,其实还是因为存储的数据结构不同的问题,对于关系型数据库,需要存储的数据是有一定的格式规范的,但是如果是 非关系型数据,那么更多的是依赖数据的可变性,所以如果使用B+树,那么如果修改数据,就需要进行全量的数据更新,因为需要维持一个统一的数据规范格式, 但是 非关系型 数据 却不一样,他需要的是保证的是 数据存储的 便捷性,能够更加方便的提高数据的可视化性能,所以使用了B树。
那么再次深入一下,一切的使用都是依据不同的业务场景,进行匹配。所以需要深入了解业务后,确定最后的具体方案,然后才确定最后需要的技术。
- 主要讲述了 mysql 幻读/脏读 出现的一些基本情况。
- 读未提交/读已提交/可重复读/串行读取
- 间隙锁 这种方式可以 规避 幻读,但是会降低系统的并发性能。
- 是否可以通过第三方的 redis 等进行热点数据的同步。
- 在业务方面 是否 需要 规避幻读?