@xinxingi 你也要看看 op 会不会 spark ，搞这么个数据替换又重新学个新技能，而且这个新技能还不熟练

@DinnyXu 主要的瓶颈是这个单表有 2-3 亿的数据，查询更新个 100w 数据不是轻轻松松吗，而是如何在 2-3 亿的表中去更这 100w 条数据。

这里 op 还没有把表结构发出来，我们不知道这个表是否有对应的索引，如果没有索引，在单表 2-3 亿的数据量下去查询，效率极低，每次只能分页查询一定的数据量。

个人建议：op 第一步先针对改表的索引进行查询，使查询语句尽量走在索引上，然后分页查询一定的数据，并开启轮询进行更新，上传和更新不一定是一个步骤，可以分为多个步骤。

通过分页查询出这些数据，集体上传，并获取 url ，上传完毕后，再分页进行更新。

我感觉大多数人都没理解到 OP 的意思，查个数据，上传并更新 OP 不会写这些代码？

现在的市场要求更高了，何况你是应届，任何行业都是一样的，你不敲代码，你大学如果学的相关的专业多少有点吃亏吧，当然这也不是绝对的。你应该多了解当下的行情，尽可能的多提高自己，放低要求先去一些小公司积累一些经验。

@DinnyXu CR 是有的

有冒烟用例，等同于单元测试吧，但是等级比单元测试低一等。CR

@shuiixng 这个真的看运气的，我和我同事都被要求上传资料了，可能第一批申请的大部分都会核算吧

@Outshine 支付这一块，如果不想用户超时，第一个要规避的是唤起支付那用户输入密码可能会超时，还有一种是三方回调的时候可能会超时，因为根据你的说明是在回调后扣减库存，表示该笔订单已完成。回调这个地方你不能太依赖三方。特别是做这种限时的订单

@Outshine 你说的的订单过期用户操作很极限，我给你举例个场景，你看极限不。点击支付的时候，该笔订单需要在 5 秒内支付完成，5 秒内用户已经唤起支付了，但是输入密码最后一位的时候，已经超过 5 秒了，但是这个订单其实也属于超时了对不。

@Outshine 微信唤起支付那个页面，系统是不可控的，你可以去试试

@jaggle op 说了 2 种情况啊，我说的明显是解决第一种情况，回调超时的话处理更简单。

@jaggle 假设我订单有效时长设置 30 秒，回调回来的时候已经超过 30 秒了？ 那就计算总体库存数量呗。不可能所有人的回调都超时了吧，没超时的就把订单库存买完了啊。超时那个运气不好，自动退款就行了。

@crazychang 技术要求不高，学历到是卡的死死的

假如用户在超时前发起了支付但是在超时后才支付成功：
OP 的这个问题是：用户在下单前发起的支付，这个时候订单还未超时，常见的手机支付，微信或支付宝在唤起支付时，付钱的那一刻，也就是输入密码或者面容识别，OP 的系统是无法感知的。

举个例子：
- OP 的订单设置为 10 分钟内必须支付完成。
- 用户在 10 分钟内发起了支付，此时已经停留在输入密码的界面。
- 用户停留在输入密码的界面超过 10 分钟，并且成功付钱了，OP 需要控制的是这个过程

解决方案：在用户点击支付时(此次在输入密码的界面)，进行预下单，这个时候会生成一笔订单，我对接过的支付宝和微信中有一个订单过期参数，OP 需要将这个参数设置为你的订单超时时间，这样用户停留在输入密码页面超过 10 分钟后，付钱的时候三方系统会通过你的这个超时参数判断，是不是已经超时了，从而拒绝该笔订单。

楼上说随机的，我今天早上就接到了审核电话，然后就是我同事也接到了，这随机概率这么大吗？

相同的数据存字典，建立枚举关系。比如 1-10 个字段，是一个组合，可以把这些组合合并为一个字段，然后映射对应的枚举

我用的 MX Anywhere 2s ，用过其它的蓝牙鼠标很多款，几乎都有卡顿和飘，这款相对来说比较稳定

买之前：希望能够用来学习，做笔记
买之后：每年过年回家坐火车的时候追剧
平时：吃灰，从不打开