面试让你造飞机，上班让你拧螺丝？

• 确实，在实际工作当中，大部分的工作内容都是围绕curd。但是，有些时候，对于数据结构和算法没有深入理解的人来说，一个小问题，需要磨很久才能搞定。举个实际工作当中的例子。
• 项目中有一个同步数据的需求，同步数据的接口返回如下内容。最小的offset和最大的offset，以及需要同步的内容（这些内容需要作为其他接口的请求参数），请求参数包含偏移量offset和页数page_size。

{    "message_list": {        "media_message_outer_dto": [{            "offset": 123,            "show_id": "lwi912lka",            "time_stamp": "2018-11-12",            "type": "SHOW",            "video_id": "123",            "video_source_type": "YOUKU"        }]    },    "max_offset": 54678656,    "min_offset": 54671234}

• 现在问题来了，第一次的请求参数中的offset肯定是设为0，请求之后拿到 min_offset 和 max_offset 的值。这个接口会返回过去一个月的更新记录，而项目需要的只是同步昨天的更新。也就是说，需要在min_offset 和 max_offset 之间找到offset的值，这个值对应昨天更新的开始。要怎么样去找到这个值呢？
• 最终简化一下问题： 现在库里边有若干数据，数据里会包含当前数据更新的时间戳，已经按照更新时间排序，这些数据存放的偏移量最小是min_offset，最大是max_offset。现在最需要取出最近更新的那一小部分数据。问从什么位置（offset）开始取效率最高？
• 最low的办法肯定就是啥也不管，从头开始取，只要是早于昨天的数据就丢弃。这种办法就不评论了。
• 可能有人会抖机灵，说请求一次之后知道max_offset了，从max_offset往回捯就行。看似巧妙，实际上逻辑行不通！假设A数据在昨天更新了两次，往回捯的话，昨天第一次的更新就会更改第二次的更新。但是，第二次更新的A才是最终需要同步的，因为它更加新。这种方法看似简便，实际上会出现数据不一致的问题！更加致命！
• 一个非常熟悉的办法就可以高效地解决这个问题。二分查找！第一次请求拿到min_offset 和 max_offset之后计算0.5 （min_offset+max_offset），请求之后判断时间戳是否晚于前天，不是则继续计算新的offset，0.5 （当前offset + max_offset），直到满足时间戳条件。
• 写代码需要时刻审视自己代码的效率，看上去简单的功能，如果执行效率比较低的话，需要及时反省，找到性能的瓶颈。