@Livid @sparanoid
请帮我删除 43 楼的回复，谢谢。

发一下牢骚之后发现不能删除贴，请帮我删除掉该回帖。

这家公司有一件事情我非常介意。
为什么 JSON 存储思维导图会被你们申请成了专利？我就想问下，思维导图本身就是无限节点，JSON 基本都是标配的技术。如果要序列化和反序列化的话，这 JSON 应该是最好的选择了吧？为什么变成你们独有的？

@laobingge 谢谢，你的话对我很有帮助。

4 楼正解。
只要不是明目张胆的在 app 内说某某地可以买到什么样什么样的 key，一般这种都属于礼品性质的不会禁止。不然肯定要被人告垄断的。

那什么*聘，现在恶心的不要不要的。你不给点钱，看你简历的怕都是机器人吧。

我想问下，MD5 是你想出来的，还是有人教你的？如果有人教你的，赶紧删除了他，因为他可能让你损失 1 个亿。

我猜楼主是想做成一个无法被人类读取的订单号，来防止别人猜测业务量？
这叫分布式 ID，随便搜索下就有一堆的方案。

其实这也是业务硬伤，这相当于查询到所有城市的数据之后，然后再进行一次 delete_time is null 的遍历，数据量大了，慢是肯定的。

我建议做 4 点，
1，依据 city_id 拆表（垂直水平都行，百万级别我建议 range 分区就行）
2，拆分 SQL 语句，根据分区分表特征，多次查询后合并
3，考虑 BY `id` DESC 是否有存在的必要性，假如本身就是 ID 插入的，这里其实可以忽略
4，delete_time is null，永远都比不上 isDelete = 1 的时候来得快

@redam 加点钱买 16 寸的，香到隔壁去了。重点点有什么关系，开发 13 寸我是受够了。

这次 13 寸的升级，对比去年 16 寸的提升，连挤牙膏都不算。。。别整了。

看到你这个题目我特地起床回答下，希望没误导大家。
前端、客户端，大多数情况下 5 秒是 OK 的（产品经理说 ok 就 ok ）。

但是关于这个设置多少，其实可以很复杂。主要是网络和服务器的处理机制环境是很复杂的一个流程，比如 DNS 解析和数据来回传输、握手机制、代理分发等等。因为一个请求发出之后，只要服务器没有出错你的请求都是会被正确处理的。所以如果客户端响应时间太短，但是这个请求没有中断而被服务端继续执行了，后果就是服务端处理了某些东西，但是你却没有收到正确的数据。所以，客户端的响应时间，除了要照顾用户的心理刻度时间之外，还要考虑上面说到的这些。
（我认为的公式：最大超时时间=数据发送最大接受时间+服务器处理超时最大值+数据量回发最大接受时间， 最小时间=产品经理认可时间）。

@wingoo 不行，我喝可乐都上瘾了。那东西无糖的不得劲，有糖的不敢喝。。。

@046569 道理是这个道理。喝茶也有说喝茶的好，所以问一下大家，看看要不要跟上。

@ccming 哥，我们别虚，来真的。看看大家有没有实际效果，我再跟上。