1.关于索引
在 innodb 使用 b+树索引的原因主要是双向链表链接叶子节点便于范围查询、非叶子节点不存储数据便于放入内存、多路比二叉树高度低，性能好。
2.SQL 优化
后端必须掌握的命令是 explain，查看执行计划就是 explain 加 sql 语句
重点 key，检查使用的索引，row，可能的扫描行数
type，查看
创建索引的字段：区分度很高的字段、频繁的 where 语句使用的、频繁的 order by 访问的、（关联条件里的列）
在 innodb 中要获得总行数，不希望全表扫描带来的开销，第一种就是使用一个 redis 存储，维护，如果允许不一致就定期发送，否则就持续的跟进 binlog，第二种是使用 explain 查看执行计划，这是对全表扫描行数的估算。
分页查询的一个问题是随着页码的增加，扫描的行数也增加，没有利用索引，解决方法是每次从偏移 0 开始，用 where id>max_id 去解决，其中 max_id 是上一页的最大 id
3.超时相关
超时涉及两种，一种是单接口的超时时间，另一个就是整个链路的超时时间对于第二种应该更加重要，因为客户就是通过这个感受延迟的。
实现链路超时控制的方法，一种是传递过期时间，另一个就是传递剩余时间，两者都不是完美的，第一种可能因为时钟不一致出现问题，第二种可能因为没有考虑网络中的延迟，而网络延迟是不确定的。
4.在游戏开发，比如无畏契约可能要考虑的问题？
第一个就是射击到服务端确认有一个时延，这个时延可能目标就移动了，结果就是射击者认为自己命中了，而服务端可能判断未命中。
解决方法，时延回退回去确认，射击时点击鼠标，客户端直接显示开火，把参数信息时间信息等传递到服务端，服务端去检查之前存储的位置信息等，判断，然后计算伤害并返回响应给客户端去显示。
这个时延不能过长，否则可能躲避者感觉到自己已经找到掩体仍然被击中。
第二个问题是客户端被攻击，有人开挂怎么办，第一个是伤害做服务端的权威校验，判断不能使用非法操作，另一个就是对于不在目标视野内的敌人不发送到内存，使用迷雾的思想去设计。
5.手撕
第一个是最长重复子串，判断一个字符串的子串是否存在两个相同的，如果有返回最长的那个结果
思想是使用二分，能够用二分解决的题目的一个特点是如果一个满足，更多或者更少就也一定满足，这里就是如果长度为 mid 的能找到，最长的一定是大于等于 mid。
具体的判断是使用 hash，对于某段如果字符串相同，结果就会一样，base 使用 131。
第二个是接雨水，用栈很容易解决，只要栈顶高度比当前高度矮就会被当前柱子遮住可以计算栈顶能组成的面积，具体这种问题写代码的时候不要忘记栈里是下标而不是高度，我好像这个问题犯过几次了。
第三个是力扣 93 判断合法 IP 划分，具体就是要把完整的划分成四块，且每块都是 0 到 255 的值，不能是连续两个前导 0，使用 dfs，判断到最后位置是不是这样划分了。
第四个是 678有效括号，使用贪心的思想，low 存储最少没有匹配的左括号，high 表示最多没有匹配的，如果 high 小于 0 说明右过多了，如果 low 小于 0 没事说明