今天久违的翻开了书本，读了《那不勒斯》，心中也有了，对于丽娜的选择而引发的一些思考。

1. 人要为自己的选择付出代价： 虽然我不知道后续丽娜的人生会有哪些变化，但就此刻的书中的情节来看，丽娜他自己做出的选择选择了一个所谓的有钱人家，但同时让自己失去了自由，失去了学习的机会。因为她要去经营熟食店、要服侍他的老公。
2. 要清楚的知道自己要什么：这一点我觉得也是莉娜没有看清楚的一部分，她的选择或许是有苦衷：不幸的童年、遭遇等。无论如何，最终也是莉拉自己选择要结婚、而不是读书。悲惨的在于，她的选择并不幸福。如果莉娜自己感到快乐还好，因为客观来说，她的确也得到了别人想要的东西：不用为金钱发愁、住在很好的房子。但这一切却并不是她想要的，她明明最擅长的是读书、学习。他有着领先别人很多的聪明头脑、从小也显得比别人更成熟，懂得更多。
   但造化弄人。命运让她做出了她的选择。

最近这两天疯狂的在追《一人之下》这部动漫，在三天的时间里面追完了5季。
作为国产动漫来说，的确很不错，但仍然达不到完美。尤其是第三季开始，剧情就不够紧凑和引入入胜。
特别是第四季、第五季陈朵这条故事线，实在是太水了点。主要还是我不喜欢主角太顺利、陈朵死的太直接了。
如果我是编剧的话，我觉得应该把陈朵的能力再爆发的多一些、以及老马要再强大一些。主角和宝儿姐太顺利了。练器师这是一个很好的设定、我觉得应该把它们写的更强大一些。最好法宝要再强大一些、好歹得让主角团吃吃瘪不是吗？太顺利就会太平淡、太平淡就意味着没有波澜、没有波澜也就无法让人动容。虽然最后陈朵的死亡也人让人动容，但花了两季，就这么匆忙的结束了，实在让人难以理解。不知道第6季能否在剧情上再回归一个较高的水平。

什么是主键索引？

1. 主键索引是每张表都有的一个索引，建表的时候就已经存在

2. 主键索引上存储了整行的数据

3. 叶子节点中的数据还是需要顺序查找，
   如┌─────────────────────────────────────────────────────────────────────────┐
   │ B+ 树聚集索引结构 │
   │ (假设每个节点存 2 个键) │
   └─────────────────────────────────────────────────────────────────────────┘

                                [1005]
                               /      \
                              /        \
                ┌────────────┘          └────────────┐
                │                                    │
             [1002]                              [1008]
            /       \                            /      \
           /         \                          /        \
   

   ┌─────────┘ └─────────┐ ┌─────────┘ └─────────┐
   │ │ │ │
   叶子节点 叶子节点 叶子节点
   ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
   │ Key | Data │ │ Key | Data │ │ Key | Data │
   ├─────────────────┤ ├─────────────────┤ ├─────────────────┤
   │ 1001 │ 完整行1 │◄──┐ │ 1005 │ 完整行3 │ │ 1008 │ 完整行4 │
   │ 1002 │ 完整行2 │ │ ├─────────────────┤ └─────────────────┘
   └─────────────────┘ │ │ ... │ ... │ ▲
   ▲ │ └─────────────────┘ │
   │ │ ▲ │
   │ └──────────────┘ │
   │ (双向链表连接，支持范围扫描) │
   │ │
   └───────────────────────────────────────────────────────────────┘

   叶子节点之间用双向链表连接，保证范围查询效率（如 WHERE product_id > 1002）

https://ddia.vonng.com/

微服务主要是人员问题的技术解决方案：允许不同的团队独立取得进展，而无需相互协调。这在大公司中很有价值，但在没有很多团队的小公司中，使用微服务可能是不必要的开销，最好以最简单的方式实现应用程序

如果你正在构建一个目前只有少数用户的新产品，也许是在初创公司，首要的工程目标通常是保持系统尽可能简单和灵活，以便你可以在了解更多关于客户需求时轻松修改和调整产品的功能 78。在这种环境中，担心未来可能需要的假设规模是适得其反的：在最好的情况下，对可伸缩性的投资是浪费的努力和过早的优化；在最坏的情况下，它们会将你锁定在不灵活的设计中，并使你的应用程序更难发展。

一、基础 & SQL 能力（必考）

1. MySQL 中 CHAR 和 VARCHAR 的区别是什么？各自的适用场景？

   1. Char 的话长度是没有限制的，是动态变化的，而 Var caht 是定长的

2. WHERE、HAVING、ON 的执行时机和区别是什么？
   1.

3. INNER JOIN、LEFT JOIN、RIGHT JOIN 的区别是什么？什么时候会产生 NULL？

   1. inner join 是内连接，是既符合左表同时又满足右表的数据才会被查询出来
   2. LEFT JOIN 是左链接，左表中的数据都会存在，再根据链接的id到右表查询，如果查询不到，则使用null 来代替
   3. RIGHT JOIN 同理

4. MySQL 中 NULL 和空字符串 '' 有什么区别？索引对它们的处理一样吗？

   1. NULL 是代表这个字段的值是空的，而空字符串是占用空间的。索引处理也不一样

5. COUNT(*)、COUNT(1)、COUNT(列名) 的区别是什么？性能上有差别吗？

   1. 在现代的数据库当中，count（*） 和count（1）基本上没有区别，都是统计查询出来的数据的行数，不管是否为null
   2. 而COUNT(列名) 是统计该列值不为null 的数量、性能上几乎没有区别

金子塔原理的核心原则：

1. 自上而下总结
2. 序言使用SCQA 法则

SCQA 法则

文档的最前面先介绍背景、冲突、问题，提出问题，最后给出结论

SCQA 法则 与阿里巴巴的思想也类似

比如你说："我主导研发的风控系统把公司的坏账率从 5% 降低到 2%"。这样的
表述是不够的，你还需要把价值背后的过程和思考说清楚。对于这个结果，评委可能
会问：
10 >　阿里工程师的自我修养

1. 之前为什么那么高？
2. 为什么你的方法可以降低？是如何归因的？
3. 具体解决了什么问题？
4. 是否可以总结出一套办法，以后别人也能用这个办法解决这些问题？

一、序言

在实际开发和调试过程中，无论是 微信小程序 还是 移动端 APP，前端与后端之间都通过接口进行数据交互。然而在很多场景下，我们并不能直观地看到后端接口的真实返回内容，例如：

• 接口返回数据异常，但前端日志有限
• 某些问题只在真机或特定网络环境下出现
• 小程序或 App 内部请求无法通过浏览器 DevTools 直接查看

当出现这类问题时，仅依靠前端代码和控制台日志，往往很难快速、准确地定位问题根因。

因此，引入 网络抓包工具 就显得尤为重要。通过抓包，我们可以直接查看客户端与后端之间的真实 HTTP / HTTPS 请求与响应，包括请求地址、参数、返回数据、状态码等关键信息。