ARST打卡第177周[177/521]
Algorithm
lc788_旋转数字_找规律or数位dp
|
|
Review
What is web2.5 and why does it matter?
Notice: 访问可能需要ladder
Web2.5 will help make crypto mainstream. But it likely won’t be the crypto we call web3. Elements of web2.5 may be similar to web3, but the narrative will differ. And a different narrative means different values and different goals. Web3 is built on openness & transparency(开放透明). Web2 is closed off & centralized(关闭集中). Web2.5 will be a hybrid(混合体的中间过度态), and which elements make it into the hybrid are what really matter.
Tips
摘要:
- 保持一颗解决问题的心
- 了解你的用户
- 不要拿自己的尺子去度量别人
- 保持学习、be open-mind
- 想清楚,再下手写代码
- 敬畏用户
- 跨团队合作是利益交换
- 用别人的语言交流,会有意想不到的收获
- 理解前人写的「烂代码」
- 在技术和工作之间找到平衡点
Share
再次分享推荐《从根儿上理解mysql》
实在是讲得很详细,会仔细分析其中的运转行为,比如优化成本分析:
12.3.4 多表连接的成本分析
有n
个表进行连接,MySQL
查询优化器要每一种连接顺序的成本都计算一遍么?那可是n!
种连接顺序呀。其实真的是要都算一遍,不过设计MySQL
的大佬们想了很多办法减少计算非常多种连接顺序的成本的方法:
-
提前结束某种顺序的成本评估
MySQL
在计算各种链接顺序的成本之前,会维护一个全局的变量,这个变量表示当前最小的连接查询成本。如果在分析某个连接顺序的成本时,该成本已经超过当前最小的连接查询成本,那就压根儿不对该连接顺序继续往下分析了。比方说A、B、C三个表进行连接,已经得到连接顺序ABC
是当前的最小连接成本,比方说10.0
,在计算连接顺序BCA
时,发现B
和C
的连接成本就已经大于10.0
时,就不再继续往后分析BCA
这个连接顺序的成本了。 -
系统变量
optimizer_search_depth
为了防止无穷无尽的分析各种连接顺序的成本,设计
MySQL
的大佬们提出了optimizer_search_depth
系统变量,如果连接表的个数小于该值,那么就继续穷举分析每一种连接顺序的成本,否则只对与optimizer_search_depth
值相同数量的表进行穷举分析。很显然,该值越大,成本分析的越精确,越容易得到好的执行计划,但是消耗的时间也就越长,否则得到不是很好的执行计划,但可以省掉很多分析连接成本的时间。 -
根据某些规则压根儿就不考虑某些连接顺序
即使是有上面两条规则的限制,但是分析多个表不同连接顺序成本花费的时间还是会很长,所以设计
MySQL
的大佬干脆提出了一些所谓的启发式规则
(就是根据以往经验指定的一些规则),凡是不满足这些规则的连接顺序压根儿就不分析,这样可以极大的减少需要分析的连接顺序的数量,但是也可能造成错失最优的执行计划。他们提供了一个系统变量optimizer_prune_level
来控制到底是不是用这些启发式规则。