秋天的第一个offer~

秋招收到的第一个意向书，太激动了

对团队很满意，秋招随缘

我本以为有大厂实习秋招就会简单点了，我现在发现我想的有点简单了，周末两场笔试全部挂0了，笔试就直接把我卡掉了😭😭😭

7.28投递 -> 8.8一面挂一面：1、实习工作；2、用过comfyUI吗，怎么把它用于文生图时候的图像理解和识别(去除一些色情暴力刀具等元素)；3、在文生图提交任务突然激增的时候，生产者-mq中间件-消费者应该做什么处理；4、mysql的索引结构，mysql索引失效或慢sql的可能原因；5、mysql的架构分几层，每一层都是怎么工作的；6、mysql在执行sql语句的时候，怎么知道大概计划或者执行扫描行数；7、mysql性能毛刺的原因和死锁原因；8、mysql怎么看连接池状态；9、mysql三大日志的功能；算法：最长回文子串，秒了一面就挂了，说实话挺难受，我自己也觉得答的还行，算法题比较常规肌肉记忆也做出来了，看看后面能不能让其他hr帮我复活吧，把自己当时原话发在下面想跟牛友交流一下，可能是我真的说得不好但是没意识到(下面根据记忆而非录音总结，实际面试表达可能会嘴瓢/说得不全)，还请大家赐教：1、在文生图提交任务突然激增的时候，生产者-mq中间件-消费者应该做什么处理：生产者端批量发送/多线程发送，非核心任务限流/延迟发送；消费者端扩容增加实例，优化消费代码，批量拉取；中间件可以扩容分区；多次消费失败的可以放死信队列这样的地方。 -- 这里或许可以再说扩大缓冲区范围并且异步发送？反正我觉得就是多线程/异步/缓存/扩容这些解决方法，我没有再多说，其实我觉得消息中间件处理信息能力应该是比生产者消费者好的，如果对业务无影响可以等待尖峰过去，毕竟本来mq就是削峰填谷。2、mysql的索引结构，mysql索引失效或慢sql的可能原因：B+树索引；索引失效：回表代价大/出现！=扫描/is null条件且null占比高等条件让优化器放弃使用索引，违反最左前缀，索引列隐式转换/使用函数运算，模糊查询%abc，or两列未全部用索引； -- 这里还提了一嘴，mysql8.0以后优化器有几率把违反联合索引最左前缀原则的语句修改掉，比如(a,b)这样的联合索引，只根据where b过滤在a取值不多的情况下sql优化器是能帮我们拼上a的。慢sql：没走索引，索引失效，深度分页，锁竞争，死锁，mysql连接池占满。 -- 感觉超级大事务也会有影响？这里当时没说，而且数分取数也经常出来慢sql，就是数据太大了，这里好像也没说清楚。3、Server 层和存储引擎层：server层建立连接，解析sql里面关键字，分析语法是不是合法，之后预处理检测字段是不是存在，优化器优化，然后走执行计划，调引擎层api执行，引擎层查数据返回给server层过滤排序；引擎层存数据检索数据事务管理等。 -- 这里倒是没说query cache，我觉得这东西没啥大用后面也没了。4、执行计划询问引擎层，访问索引结构，表元数据等引擎层信息来预测执行路径和大概扫描行数，模拟执行过程 -- 我感觉就这个意思？这里不知道对不对，先模拟执行一遍。5、死锁：两个事务执行顺序交叉，类似于a和b互相转账；update/insert导致的间隙锁冲突；DDL和DML语句冲突；对二级索引上间隙锁对主键索引id也会上锁，影响一些数据插入；insert插入唯一列时，因为purge线程延迟，导致线程等待插入数据列被回收，拿到s型nexykey锁阻塞等待；不走索引的update让全表间隙锁；性能毛刺：死锁和锁等待，连接池耗尽，主从复制配置不合理，网络波动，大事务，频繁页分裂，缓存失效。 -- 我后面看还有因为并行度调整不合理、刷盘和主从复制时间过长和查询涉及数据太多导致的毛刺(其实也可以扩大化就是慢sql)，总之这些没说。6、看连接池状态：这个不会，应该是说错了，其实直接看板就能看吧，收集一些相关指令放到下面：-- 最大连接数限制SHOW VARIABLES LIKE 'max_connections';-- 连接超时设置（非交互式/交互式）SHOW VARIABLES LIKE 'wait_timeout';SHOW VARIABLES LIKE 'interactive_timeout';-- 线程缓存大小SHOW VARIABLES LIKE 'thread_cache_size';-- 当前连接数/运行中连接数SHOW STATUS LIKE 'Threads_connected';  -- 当前总连接数SHOW STATUS LIKE 'Threads_running';    -- 非Sleep状态的活跃连接数-- 连接统计信息SHOW STATUS LIKE 'Connections';        -- 历史总连接次数SHOW STATUS LIKE 'Max_used_connections'; -- 峰值连接数SHOW STATUS LIKE 'Aborted_connects';   -- 失败连接尝试次数-- 线程缓存效率SHOW STATUS LIKE 'Threads_cached';     -- 缓存中的线程数SHOW STATUS LIKE 'Threads_created';    -- 已创建的线程总数-- 显示所有活跃连接SHOW FULL PROCESSLIST;-- 看引擎层SHOW ENGINE INNODB STATUS  -- 具体这个的作用放附件图片了7、三大日志：undolog：回滚日志，服务于事务回滚和mvcc机制，记录回滚需要的信息，可以形成类似版本链的结构，当没有活跃事务需要它 && 对应行被删除时会被purge回收，靠redolog刷盘实现持久化；redo log：重做日志记录某页修改和undolog，有持久化到磁盘的刷盘机制，在系统崩溃后可以根据redolog恢复数据，redolog一个环循环写，满了会强制刷脏页；binlog：记录数据修改和数据库表变化的日志，server层实现，binlog追加写，用于主从同步，可以记录实际sql也可以记录修改后行数据；redolog和binlog有二阶段提交，避免主从不一致，redolog先写入变为prepare，后面binlog写入成功后把redolog改为commit，根据日志内事务XA ID来判断崩溃恢复时间点。-- 这里我没说redolog和double write buffer交互过程，其实我当时是记得大概逻辑的，怕说错了没敢说，也没说undolog和redolog是在引擎层，redolog是innodb特有的，不过我觉得无伤大雅吧