学历有要求吗？

突然想到力扣链表找环的问题，有快慢指针和哈希表两种做法，两者时间复杂度相同但是前者省内存，可是前者难于理解和维护，后者简单易懂，假如实际业务上有类似地方，我可能会用哈希表的做法。

哭了，下班就 10：30 了

看了大家对 64GB 手机的评论，又去看了一下自己手机的剩余容量……才发现又得加 500 块钱升级 128GB 的了😭

最好不要自己换 容易坏

支持一下

@maemual 这…那看起来似乎真没什么含金量

加索引应该也要扫描索引树吧。
插入的时候更新 count，似乎会影响插入效率。
将数据同步到其他数据库例如 es 或者从库，查询从这些里面查好像不错。
定时任务周期性的计算 count 也可以，查询时直接用结果，也是有一定的时延。

93 年的不是 27 嘛

Redis 使用 hash，大 key 使用文章 ID，小 key 为 userid，定时任务隔一段时间落库，没做过点赞，不知道这样是否能满足需求？

善始善终，我会好好做的！

后台 worker 一直扫库感觉可行，不过要给订单状态和下单时间做个联合索引，保证扫库时用到索引不会扫很多无用的行，但是数据库中数据量大的话加索引是件很麻烦的事……而且最好保证 worker 只有一个。

Redis 做延时队列如果挂了可能存在丢消息的风险，必须有补偿机制。

用 mq 延时消息感觉最合适，不过消费 mq 也可能有重复的消息？如果有的话做好消息幂等就好了。感觉 mq 可能遇到的问题 1 是 mq 容量和性能，这个要自己压测了； 2 是如果消费速度慢的话（数据库事务加互斥锁），实际关单时间要＞规定时间。

1.是否加索引
2.能否优化，使用覆盖索引
3.索引加的是否合适
4.尽量使用索引来避免排序操作
5.减少不必要的列查询，减少磁盘读取与网络传输字节
6.大查询切分成小查询，减小加锁的事务
7.分解关联查询，分解成单表查询然后应用层关联
8.应用层加缓存
9.尽可能将随机读优化为顺序读
10.空间换时间，能否冗余一些字段减少慢查询
11.其它等等……

高性能 MySQL 上有讲很多，可以看下，然后总结下

@ZGW1314 差不多，一个圈子的

楼上对这个薪资有的说高，有的说低，应该是不同圈子的原因吧。同 17 年一本毕业接近 3 年，毕业后很多同学一起来北京工作，现在 80%都 21k 以上了，有低的可能 16-18 的样子，这是我周围的真实情况，所以感觉楼主 17k 确实是被压价了。

递推应该可以用矩阵快速幂来优化

想法重要。
想法以及思想决定技术的高度。技术差的眼界以及经验都不够，想法肯定少。技术大牛在制定技术架构以及方案时，看的更多，能有很多想法，多种方案，权衡利弊，举一反三，可以避免以后很多踩坑。