引言

• 这是我面试体验感最好的一次，腾讯、拼多多、华为都没有这个好，不仅仅是单方面接受拷打，是会和我讨论我的方法有什么不对，然后还会认真听我的研究方向，然后探讨如何改良。之前所有的面试，基本上没啥人会认真听我的研究方向，以后我应该还会投字节，能去那里工作真的不错，很棒！主要是飞书部门！
• 正常面试下来我发现我的八股不行并且算法也不行
  • 八股是只会背这一道题，一旦跟我深入讨论，我就不能顺利答出来了
  • 算法是紧张了，没写出来，没有考虑好！
• 今天主要是把八股过一遍，算法已经过过了！

正文

八股

MySQL熟悉吗？讲一下MySQL索引的结构？

我的回答

• 帮助查询数据的一种数据结构，底层是用B+数保存索引，是否需要展开讲一下B+树的具体内容？

追问：MySQL为什么要使用B+树？

• 多叉树，相同节点的情况下，树的层高更低，磁盘IO次数更少，查询效率更快
• 叶子节点使用双项链表保存，适用于范围查找
• 非叶子节点保存索引，叶子节点存储数据，B数全部都存数据，搜索更快

个人问题

• MySQL会将索引加入到内存中吗？如果可以加载到内存中的话，就是会更快，如果没有的话，就没有意义了。
• MySQL会将索引加载到内存中，从而提高查询速度。具体来说，MySQL使用一种叫做“缓存”的机制来将索引数据存储在内存中。这些缓存主要包括：
  • InnoDB Buffer Pool：这是InnoDB存储引擎使用的主要缓存区，用于缓存数据页和索引页。通过将索引加载到缓冲池中，MySQL可以更快速地访问和处理索引，从而加快查询速度

在使用MySQL的时候，如何避免索引失效？

• 这个题目一下子忘记了，太久没背了，而且没有具体使用过索引，底层并不了解，所以这里没回答出来！或者说在胡扯！
  • 不能使用聚合函数的操作？扯淡，这个用不到！

**这里暂时先贴一下GPT的回答，这里每次都挂，今天准备抽时间，把这个索引这个章节从使用到原理都看一遍，再重写一篇，这里先放在这里，今天写完了，在贴链接！ **

讲一下MySQL的事物有哪几种特征？

• 原子性：一个操作要么成功要么失败，
• 隔离性：
• 持久性：保证事物不会因为执行失败的断电
• 一致性：保证一个SQL语句执行前后的结果是一致的

这里说的不够详细，或者说不够具体，很混乱，没有一开始的那种从容和淡定了！紧张了！

• 原子性：

  • 确保事务中的所有操作要么全部完成，要么完全不执行。如果事务中的任何操作失败，整个事务将回滚，数据库会回到事务开始前的状态。

• 一致性（Consistency）：

  • 一致性保证事务将数据库从一个一致状态转移到另一个一致状态。在事务开始和结束时，数据库的完整性约束没有被破坏。

• 隔离性（isolated）

  • 隔离性确保并发事务彼此之间不会互相干扰。每个事务在其执行过程中所做的更改对其他事务是不可见的，直到该事务提交。

• 持久性（Durability）：

  • 持久性保证一旦事务提交，其结果将永久保存在数据库中，即使发生系统崩溃也不会丢失

MySQL的原子性可以实现什么效果？

• 网购购买成功，减库存操作
• 原子性主要是通过undolog保证实现的，事物执行失败进行回滚，要么执行失败，要么全部执行。

MySQL几种隔离级别？常用的隔离级别是什么？

• 电商常用的是读已提交，MySQL的InoDB默认的隔离级别是可重复读
• 4种隔离级别，列举出来了

为什么电商是读已提交？

• 电商对于并发性的要求比较高，然后可重复读的会限制并发性，对于数据不一致可以容忍。
  
• 1、性能考虑
  • 减少锁争用：在高并发环境下，“读已提交”隔离级别减少了锁的持有时间和范围，避免了长时间的行级锁定，从而减少了锁争用和死锁的风险。相比于“可重复读”或“串行化”隔离级别，“读已提交”对系统性能的影响较小。
  • 提高吞吐量：降低锁的粒度和持有时间有助于提高系统的并发处理能力，从而提高整体吞吐量。这对于高流量的电商平台至关重要。
• 2. 业务需求
  • 及时性要求：电商平台需要及时反馈用户的操作结果，如订单创建、库存查询等。在“读已提交”隔离级别下，用户可以更快地看到最新的已提交数据，满足了业务的及时性需求。
  • 一致性要求相对较低：对于许多电商业务场景，如商品浏览和搜索，对数据一致性的要求相对较低，允许一定程度的脏读。
• 3. 事务冲突减少
  • 降低事务冲突：在“读已提交”隔离级别下，读操作不会阻塞写操作，写操作也不会阻塞读操作，减少了事务之间的冲突，提高了系统的并发处理能力。
• 4. 适当的并发控制
  • 乐观锁和悲观锁的结合使用：在需要严格控制并发的场景，如库存扣减和订单处理，可以结合使用乐观锁或悲观锁，以确保数据的一致性和正确性。通过这种方式，可以在保持较高性能的同时，防止关键业务场景下的数据冲突和不一致

如果主要采用读已提交的话，怎么样防止超卖？库存有限的时候？秒拍的场景下？单说隔离级别的情况！以买票为例子，比如说一张票！实际业务系统里怎么防止超卖？

• 通过redis这种分布式锁，通过锁来控制访问
• 查的时候可以查有票，但是实际购买的时候，使用分布式锁进行处理。

搜索回答
悲观锁

• 读取库存的时候，锁住相应的记录，防止其他事物同时获取或者修改记录，使用select 。。。。for update实现

start transaction

select stock from ticks where ticket_id = 1 for update;
-- 检查库存是否足够
IF stock > 0 THEN
    -- 执行购买操作
    UPDATE tickets SET stock = stock - 1 WHERE ticket_id = 1;
    -- 提交事务
    COMMIT;
ELSE
    -- 库存不足，回滚事务
    ROLLBACK;
END IF;

乐观锁

• 在更新库存时，通过检查库存的版本号或者是时间戳来保证数据的一致性，在更新账号时发现版本好发生变化，说明其他事物已经更新过了，需要重试

START TRANSACTION;

-- 读取库存和版本号
SELECT stock, version FROM tickets WHERE ticket_id = 1;

-- 检查库存是否足够
IF stock > 0 THEN
    -- 尝试更新库存和版本号
    UPDATE tickets SET stock = stock - 1, version = version + 1 
    WHERE ticket_id = 1 AND version = @version;
    
    -- 检查是否有行受影响
    IF ROW_COUNT() > 0 THEN
        -- 更新成功，提交事务
        COMMIT;
    ELSE
        -- 更新失败，回滚事务并重试
        ROLLBACK;
        -- 重试逻辑（如重新开始事务）
    END IF;
ELSE
    -- 库存不足，回滚事务
    ROLLBACK;
END IF;

原子操作

• 使用数据的原子操作，如update中的判断语句，在高并发的情况下，确保操作的原子性

START TRANSACTION;

-- 尝试更新库存
UPDATE tickets SET stock = stock - 1 WHERE ticket_id = 1 AND stock > 0;

-- 检查是否有行受影响
IF ROW_COUNT() > 0 THEN
    -- 更新成功，提交事务
    COMMIT;
ELSE
    -- 更新失败（库存不足或其他原因），回滚事务
    ROLLBACK;
END IF;

分布式锁

• 在分布式系统中，使用分布式锁，确保同一时间只能有一个实例在操作数据库。

你对飞书了解吗？

• 不了解
• 尴尬！

补充

• 企业级协同办公平台
• 特点
  • 即时消息
  • 文档协作，提供强大的文档挂你和权限控制功能，支持多人同时编辑和评论
  • 任何和项目管理
    • 提供任务管理 工具，创建、分配和跟踪任务管理
    • 支持甘特图等
  • 集成应用
    • 支持与第三方应用的集成，github和JIRA等
    • 提供API和Webhook，方便企业进行自定义开发和集成

总结

• 大概率是进不去了，不过我学到了很多东西，后续会进一步进行改良，今天就加把劲，把MySQL的东西给补上，尤其是索引这一块。
• 也许这就是不断面试的作用吧，不断面试，不断补全自己的知识网络，然后不断提高自己的能力！加油！