认知&赚钱
你永远赚不到
超出你认知范围外的钱
除非你靠运气
但是靠运气赚到的钱
最好往往又会靠实力亏掉
转眼间到 2026 年了,时间过得可真快,,现在是以周为单位感知时间,就像上周末干了啥啥,像是昨天的事情,现在又是周末了。
3月11号,礼成,一切都很顺利。
诶?解决版本日的突发状况就很不错,快乐来源于成就感,同时不要得意忘形~
转眼间到 2025 年了,时间过得可真快。。
奶奶的情况在去年夏天突然恶化了,06-22 周末接到老爷子的视频,说奶奶精神不好,村里的医生给开了药一直沉睡,大部时间都是半昏迷的状态。刚刚醒过来,跟我视频连线下。我跟奶奶打招呼,她没有什么反应,只是半睁着眼,这着实让我有点吃惊。现在想想,更多的是后怕、后悔。没多久 06-25 早上 10 点多接到老父亲的消息,奶奶走了。意料之外。赶紧交接工作,订机票回家。
最终还是没有吃上我的这碗菜。
只能安慰自己,,还好,在 4 月份跟大象领证了;还好,在 2023 年国庆带大象回家见过了。
转载自Javascript面向对象编程(二):构造函数的继承 - by 阮一峰
这个系列的第一部分,主要介绍了如何“封装”数据和方法,以及如何从原型对象生成实例。
今天要介绍的是,对象之间的“继承”的五种方法。
比如,现在有一个“动物”👇对象的构造函数:
1 | |
还有一个“猫”👇对象的构造函数:
某些性能消耗非常大的 SQL 可以直接造成数据库主从长时间延迟、主从中断、甚至实例 CRASH 等。性能消耗过大的 SQL 本身执行时间长,其实也就是资源占用时间长,会造成集群并发能力低下。在业务流量突增(业务本身或网络抖动都可能导致)等情况下,容易造成 SQL 堆积、并发超过限制等,从而影响到业务正常运行。OceanBase 数据库没有关联表数的限制,复杂函数的使用目前只针对正则表达式相关函数,例如
regexp_substr这类函数的执行性能差,容易影响业务。一个业务,使用简单的 SQL 语句,使用数据库最简单的增、删、改、查功能,从而让数据库处于一种可预估,可扩展,可控的状态。我们来衡量一个业务 SQL 写的是否优秀,其关键点是这个业务的 SQL 是否在合理范围内足够的简单。这个合理的范围指的是随着业务及数据的增长,SQL 本身的性能消耗不大且不会有大的变化,不会占用过多的 CPU 或 IO 时间。比如一个根据主键查询的语句,一行数据与一千万行数据不会有太大的变化。业务可以很好的在此基础之上预估当前流量要增加比如 N 倍的情况下,数据库应就当如何扩容并能确保数据库可以支撑.但如果业务中复杂语句过多,性能消耗又大,数据库可能就只因为偶尔的或是前端的,或是网络的,可是数据库本身的波动导致 SQL 堆积、实例并发增长,业务受到影响。
复杂的 SQL 会让集群处于一种性能波动明显,并发能力低,业务可能不可控的状态。
– OceanBase 数据库 》参考指南 》SQL 参考 》SQL 实践和建议 》SQL 语句示例
[^1]: JOIN 表使用建议
Context: 数据库从 Oracle 迁移至 OceanBase(Oracle 租户模式),顺便将数据库配置从项目文件迁移至 Apollo,代码无改动。框架为定制化的 Spring。
OK,下面讲问题,,
不出意外,出意外了,,发版时,服务启动成功后,查询数据库报错:👇🏻
1 | |