Altale

@Celebi 这个现在性价比应该不是很妙呀

Hi，看 Shopee 的机会可以 At 我，可以帮忙介绍下不同部门，选一个符合你要求的，对深圳这边的部门职位比较熟悉 :)

觉得算法的思路上有在日常工作中帮到过我，包括更优雅的递归和遍历、了解到了一点语法糖、熟练不依赖各种包来完成一些东西，这是其一

其二就是写代码是一线工程师最直接的能力体现，代码都写不好，人家为什么要相信你能在工作中如何如何好呢，能不能写出来是一方面，思路、设计、代码结构也是一方面，有的公司也并不是没写出来直接挂的，遇到过好几个面试官都有尝试引导甚至做不出来换一题给机会的。

所以建议大家跳槽的时候还是多多准备下算法题，不会花很多时间，多看看题解和别人写的代码，对自己没坏处

@whywhywhy 是的呀不加班呀..

友情 ding 一下同事~

曾经有段实践尝试过推行第三点的写作，但是个人认为对于不太愿意（也可能只是工作比较忙，没有合适的时间）总结和沉淀的同学来说，确实是比较累人（ KPI 化）的，产出结果也不太理想。所以希望大家多多提点建议或者方案，如果好落地推行的话~回头再来 V2 反馈给大家

其实让数据库执行你的查询，同一条 sql 在数据分布不同的情况下执行路径也会大有不同，问题太过 general 了，问人还不如相信数据库的分析

@myd 那提供的条件太有限了，无法知道具体的查询 pattern，范围，这些建议都给不了

方案没有，但是提个小建议，第二点问题可能是错的

“加 2 个普通索引 online_time 和 offline_time，只能用一个，也有可能都用不上”

这个方案最理想的情况是两个索引都使用上，最终取交集，具体情况要看 DBMS 的统计数据认为交集的方案开销是否比其他查询路径小。

另一个小建议是如果你这个表很大，还有其他字段，那么加这两个索引：
- online_time - user_id
- offline_time - user_id

将取交集的操作继续缩小为不需要回表的方案，性能可能有大幅提升（安利测试看看）