问题总结：
整个过程大致是经历了项目拷打，基础八股文测试基础理论，最后手撕数字字符串转数字
接下来是一些提问和回答
Q:看简历你是做了豆瓣这个项目，在这个项目你实现了什么功能？
A:歌手服务，歌单服务
Q:歌手歌单服务的业务流程你是怎么设计和实现的？
A:(这里支支吾吾说不上来)。大概答了思路是通过爬虫爬取原豆瓣FM页面的数据，并且经过对爬取的数据进行重新组装实现的。复盘后觉得可以回答自己对歌手，歌曲这两个模型设计的理解，从实际的业务，到抽象的模型一共是经历了3层抽象的提取。歌手和歌曲是最基础的两个模型，能够作为直接对象输出数据展示在前端，在这两者的基础上，豆瓣FM里还对应了不同的板块，每个板块内还整合了各种不同的主题。因为每个板块都对应了一类的主题，那如果说有5个不同的板块，那我们就要创建五个不同的类，那样的极大的增加了代码的复杂程度和代码量。所以在此基础上我们再主题进行抽象，将主题抽象成一个类，设置一个属性:子类型sujectSubType用来区分不同的主题。再设置了name属性来区分不同的板块名称。类的数量减少，通用性增强了。再经过分析其实兆赫功能和歌单功能类似，只是多组合了个歌曲，所以可以再抽象一个属性subjectType来区分两者，最终非常复杂的一套系统，其实最终只有一个主要的Subject类作为存储数据的类，而作为Singer和Song这两个基础的类就可以通过Subject的数据进行组装。整套系统主要的3个类就可以完成多数的复杂功能。
Q:数据库有了解过吗？MySQL分页查询是怎么实现的？
A:(这里也是答不上来)。其实我是用了MyBatis支持的分页插件pagehelper，基本让我不用额外处理Mybatis XML的逻辑。直接使用doSelectPage的方法自动执行分页逻辑，返回分页对象Page。
合理解释：SELECT 字段列表 FROM 表名 LIMIT 起始索引，查询记录数;
Q:SQL写过吗？现在想要查询某个分数表中分数排序最高的前三位，在评论区写一下。
A:(内心崩溃了这个也没答上来，之前光顾着刷笔试题，面经一点没看直接面试了，大家别学我)
合理解释：SELECT name FROM user ORDER BY score DESC LIMIT 3;
Q:现在有a，b，c三张表，是ac关联b查询快比单是查询b表快，为什么？
A:(这里的话没太理解问的问题什么意思，估计是想问单个索引和组合索引哪个效率高。)
合理解释：组合索引 比对每个列分别建索引更有优势，因为索引建立得越多就越占磁盘空间，在更新数据的时候速度会更慢。另外建立多列索引时，顺序也是需要注意的，应该将严格的索引放在前面，这样筛选的力度会更大，效率更高。
结论：全文索引 > 联合索引 > json函数查询 > like查询
数据量越大，全文索引速度越明显，就10万的量，查询速度大概比直接查询快了20倍左右，如果是百万或千万级别的表，提升差距会更加大，所以有条件还是老老实实用全文索引吧
手撕代码：数字字符串转数字(简单题，数字里有小数点，用进位法的思路解决本题)
Q:用户登录注册怎么实现？数据库存储的密码加密处理用的是什么算法？
A:(没答上来)
合理解释：在用户注册过程中，对密码首先进行一个加盐值的处理，在对其使用md5算法生成唯一对应的序列，然后保存在数据库中，当需要登录检测时候，也对输入的密码进行加盐处理，md5算法转化，然后和数据库中已经得密码进行比对。
Q:解释一下Cookie和Session的区别，说说Session在你的项目中是怎么存储的
A:(学过好多东西都忘了，这个也没答上来)
合理解释:Cookie和Session的主要区别呢是，一个保存在本地的浏览器，一个存储在服务器中，当用户第一次登录注册的时候，用户将他的userid发送给我们的服务器，服务器接受之后生成一个唯一的sessionId保存在服务器内，同时以Cooie为载体返回给客户端，客户端将含有sessionId的cookie保存在本地中，每当客户端想访问其他页面的时候，就不在需要重复验证，只需要从cookie中去除sessionId，看看是否已经在服务器端存在了，如果存在则正常访问，否则跳转验证页面
面试心得体会：
1.老老实实准备好再来面试，不然真的会被拷打得很惨
2.MySQL是一个面试中非常关注的技术点，可以下点功夫去学习MySQL，让其成为自己的一个技术亮点，之后也会在博客里来发布自己对《高性能MySQL》这一本的学习
3.虽然秋招很难，但是永远对编程有热爱，合理面对每次的面试结果，从失败中总结经验教训，如果失败没有反思，失败只会失败之母。
同各位一起共勉，加油，奥利给
3174
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
