字节-火山-AI应用开发工程师-一面

时长1h

1.自我介绍

2.实习经历+项目（持续了大概20min）

3.coding部分（持续20min）

3.1 三个线程按顺序打印abcabc（因为用Go，所以写得很快，然后写太快了就奖励再来一题。。。）

3.2 在最多删除一个字符的前提下，判断是不是回文字符串

——————————————————————————————————————————————————————————

八股环节

4.索引设计的原则

答：

• 最左匹配原则（联合索引/复合索引会按照字段的顺序构建B+树，查询时只有匹配‘最左前缀’才能命中索引）

5.每一行都能设置索引吗，为什么（Mysql中给每个列表都建立索引的情况）

答：

不行

索引的本质是“按字段构建”，而非“按行设置”

1. 性能代价远大于收益，写入性能暴跌：每执行一次INSERT/UPDATE/DELETE，所有索引都需要同步更新。（比如表有 10 个索引，修改一行数据需要更新 10 棵 B + 树）
2. 磁盘空间浪费
3. 低区分度字段建索引无意义

6.Mysql中索引失效的情况

答：

• 违背“最左匹配原则”
• 索引上使用函数/运算
• 使用范围插叙后，右侧索引失效（联合索引）
• 使用模糊匹配
• OR连接的条件中，有字段无索引
• 使用 NOT IN/！=/NOT EXISTS（不等于操作）
• 索引字段为NULL
• 数据分布导致优化器放弃索引
• 联合索引中，字段类型不匹配（隐式转换）

7.Mysql中什么时候会进行回表查询

答：

使用二级索引查询，但所需要的字段超出索引范围

8.Mysql索引是如何存放的

答：

Innodb 数据和缩影都存放在同一个.ibd文件中

Innodb是存放在默认的共享表空间中（innodb_file_table = OFF）

分开存储，分别存放在独立的.ibd文件中

9.redis为什么快

答：

• 单线程模型，规避性能损耗，仅用一个线程处理所有客户端的读写请求，避免了多线程的两大核心开销
• 纯内存操作：Redis所有的数据都存储在内存中
• 网络模型：IO多路复用，让单线程能够同时监听多个客户端连接，实现非阻塞IO

10.Http的加密过程

答：

• 客户端发送第一个TLS包：包含客户端所支持的TLS版本，所有的加密套件
• 服务端收到后，确定基本规则：TLS版本
• 服务端向客户端发送数字证书
• 客户端校验数字证书通过后，用证书中的公钥加密发送给服务端（非对称加密）
• 双方改加密规范，互相验证，开始对称加密传递数据

11.Go的chanel，对已经关闭的channel进行读写有什么问题吗？

12.Go的GMP模型

答：

G:Goroutine

M：内核线程，每一个m都有一个特殊的g0，负责协程调度和切换，goroutine必须绑定到M上才能正常运行

P：Processor，包含goroutine本地队列，队列长度256，当有goroutine创建的时候，会将其添加到P的队列中，如果满了，就会维护到全局队列中。

13.反问环节

#牛客AI配图神器#