1、慢SQL的具体内容；2、应用DB是如何确保事务的持久性；    写前日志机制：再事务对数据库进行修改之前，数据库系统回先将事务的操作信息记录到日志文件中。这些日志信息包括事务的开始，每个操作的细节（如修改了哪些数据、修改前后的值等）以及事务的结束等内容。日志文件通常被写入磁盘等持久化存储设备上。这样可以保证系统出现故障时，可以更具日志来恢复事务的执行状态；    在mysql中，事务的持久性主要通过1、利用InnoDB的存储引擎的日志机制，当事务对数据进行修改时，InnoDB存储引擎会先将这些修改记录记录到redolog中。redo log属于物理日志，它记录的是数据页的物理修改情况。例如，当更新一行数据时，redo log会记录该数据页中具体字节的修改内容。binlog时记录了所有数据库的修改操作，包括数据的增删改查。binlog是逻辑日志，记录的是sql语句或者行的变化。例如，执行一条“UPDATE table SET column = value WHERE condition”语句，binlog会记录这条语句的执行细节。2、通过事务提交时的磁盘写入操作：当事务提交时，mysql会将事务涉及的数据页从内存中的缓冲池刷新到磁盘。缓冲池是InnoDB用于缓存数据页和索引页的内存区域，数据的修改首先是在内存中进行的。写入操作不是完全同步的，而是结合了redo log机制，因为redo log已经保证了事务的持久性，数据页的最终写入磁盘可以在检查点过程中进行。3、事务的隔离级别4、自适应哈希索引流的机制    自适应哈希索引是一种用于优化数据库性能的机制，它可以根据数据库的负载和查询模式动态地创建和维护哈希索引，以下是具体介绍：工作原理    数据页监控 ：InnoDB 存储引擎会监控对表中数据页的访问情况。当发现某些数据页被频繁访问时，就会考虑为这些页创建哈希索引。    哈希索引创建 ：如果一个数据页被访问的次数超过了设定的阈值，并且内存中还有足够的空间来存储哈希索引结构，InnoDB 会自动在后台为该数据页上的某个索引创建一个哈希索引。    哈希索引维护 ：随着数据的插入、删除和更新操作，哈希索引会自动进行维护，以保证其有效性和准确性。当数据页的访问频率降低，或者内存空间不足时，InnoDB 也会自动删除不再需要的哈希索引。5、网络协议http、https协议的区别6、timewait的作用7、TCP如何进行拥塞控制8、操作系统的内存管理机制    虚拟内存（虚拟内存是一种内存管理技术，使得程序可以使用比实际物理内存更大的地址空间。它通过将程序的地址空间分割成多个页面或者段，然后将这些页面或者段部分的存储在内存中，而将其他部分存储在磁盘外部存储器上。当需要访问一个不在内存中的页面时，由操作系统负责将其调入内存）：分页式存储、段页式存储    地址映射：静态重定位（绝对地址映射）、动态重定位（相对地址映射）    内存保护：分区保护：在分区分配系统中，为每个分区设置保护机制来限制进程的访问范围；页表保护：在虚拟内存系统中，通过页表来实现内存保护。每个进程都有自己的页表，页表中除了包含虚页到物理块的映射关系外，还包含访问权限位。9、软链接和硬链接的区别软链接软链接是一个独立的文件，它包含了一个指向目标文件或目录的路径。从本质上来说，软链接就像是一个快捷方式，它有自己的 inode（文件系统用于存储文件元数据的结构）。例如，如果有一个文件 file1，创建一个软链接 symlink1 指向它，symlink1 有自己的 inode，其内容是指向 file1 的路径。软链接可以跨文件系统，也就是说，软链接可以位于与目标文件不同的文件系统上。例如，目标文件在 /dev/sda1 分区，软链接可以在 /dev/sda2 分区。硬链接硬链接是直接指向目标文件 inode 的链接。多个硬链接共享同一个 inode，它们是同一个文件的不同名称。例如，对于文件 file1，创建硬链接 hardlink1 后，hardlink1 和 file1 都指向同一个 inode，操作系统将它们视为同一个文件的两个入口。硬链接不能跨文件系统。因为硬链接依赖于目标文件的 inode，而 inode 号在不同的文件系统中是独立的，所以硬链接必须位于与目标文件相同的文件系统中。

以下是基于我在腾讯的面试全流程问题汇总，给大家提供参考，有什么问题可以随时交流哈～腾讯面试全流程概览一面（基础能力）编程与算法手写代码：反转链表、快速排序、二分查找、动态规划问题（如背包问题）。算法优化：如何提升算法时间复杂度？举例说明。计算机基础TCP三次握手与四次挥手、HTTP与HTTPS区别。进程与线程区别、线程池工作原理、死锁产生条件。数据库MySQL索引（B+树特性）、事务隔离级别、Redis持久化方式。二面（项目与系统设计）项目深挖项目中如何解决高并发问题？分布式系统设计思路？量化项目成果（如“用户留存率提升30%”）。系统设计设计一个高并发订单系统、分布式缓存一致性方案。如何设计...

字节搜索二面挂当天被捞1、自我介绍2、你提到了用户的关注与取关，你用户关系服务是怎么设计的？（定义了关注表与粉丝表，两个表内容一致）3、你怎么保证两个表内容一致的？（目前是通过事务保证的，后面其实还可以通过订阅 binlog 伪从来保证一致性）3、如果是大 V 的情况，你有考虑到吗，做了哪些处理应对这种高并发（Redis 缓存+二级缓存，冷热数据分离）4、分布式 ID 你都用来生成什么 ID 的？（笔记 ID，用户 ID，用户 ID 用的号段模式，笔记 ID 考虑到雪花算法自带的时间戳可以实现冷热数据分离，发布久远的笔记不缓存在 redis，后由于点赞系统采用咆哮位图高效判断，但咆哮位图基本只能存储 32 位，遂也改为号段模式生成，生成效率基本没差多少）5、那你说说点赞系统怎么设计的？为什么改为咆哮位图了？（先是采用 Set 数据结构判断，后因为满足高并发需求，Set 模式占用内存太多，又改用布隆过滤器实现，大大降低内存占用。但布隆过滤器在判断存在时存在误判，需要从数据库进行二次校验。后改用咆哮位图，既能高效判断点赞与否，内存占用也大大降低）6、那你讲一下咆哮位图的机制，为什么有你说的这些优点？7、MySQL 了解吧，你讲一下 MySQL 的索引（一顿吟唱）8、说一下聚簇索引和非聚簇索引的区别9、联合索引再说一下，如何定义联合索引最好？（设计成覆盖索引）10、联合索引的顺序重要吗？（顺便再说一下索引下推）11、算法1：二叉树展开为链表12、算法2：根据层序遍历建树反问

3月腾讯实习基地：客户端一面（挂）：主要就是问一些很常规的八股，然后做了一道hard题，当时经验不够，现在想起来应该是kpi面，因为八股基本都答得比较流畅，hard题也做出来了，但是还是挂了。一面：挂了又被另外一个部门捞起来了，还是客户端，这个主要也是一些八股，然后做了两道medium题，第二题是实现单例模式，对设计模式不是很了解，但是写得很磕磕碰碰，最后还是给我过了。二面：没怎么聊八股，题也很简单，主要是一些关于c++的发散性问题吧，聊到什么说什么，也过了。三面：两道智力题，过hr面：常规问题，过岗位不太合适，最后还是拒了offer4月原粒半导体：算子开发一面：问了一些很简单的问题，例如tr...