好,我把图片重新导到社区来吧
csdn 图片存储挂了,丢了 1 个图
该休息休息了。
勇气可嘉,但不提倡。
鼓励下楼主。
说说不开心,当初为何想转算法,其实楼主没有想明白。最近也面了很多候选人,大数据相关的,一般我最后一个问题都是,你未来想做什么,很多人给我的答案是:算法。但是细问都说不出什么原因。每个行业都有自己的深度,不建议转这种门槛高的。需要的时间太长,等你学会了,说不定这个行业热度也已经过了。
更新到最新版本
线上分析问题
为精神点个赞,老哥的态度比很多 35 岁的人都要积极。
和你比,我觉得自己算稳定了啦。看到你还能找到工作,我还怕啥。。。
作者可以自行关闭评论
除了恒温,其他人言论不代表社区!请自动甄别!
不服!
L 黑
没深入过 appium,可以问问其他同学
减少尝试成本,按官方来,我刚开始是 10.几不行
这个不错,只用了 5ms,比之前几个都好。
试了下跟json-iterator
一样,20ms,不行。
是,有其他推荐方案么?我正在找,因为毕竟还有 json 字符串的解析操作无法去掉。
确实有点秃,头发少了很多
东哥,你过分了。
认真读了晓光哥的文章,收益挺多的。努力完善自身,提升能力。THS
但是做算法的去做开发,基本是可以碾压开发的
还没开始入算法行,就开始鄙视开发了,这可要不得。我平时的工作就是跟策略算法团队打交道。各有所专,不可妄下评论。
本来我们设置的索引是 A(店铺),B(订单状态),常规情况下,mysql 自己会用 B 来过滤订单数据,这是他自己算法决定的。但是突然有一天晚上,explain 出来以后,他先以 A 来查询订单,查出来几百多 w 条数据。查询速度达到了 6s 左右,上游已经超时返回了。而且该接口时系统的发起入口,该接口失败,后面调度就走不了啦。订单一直无法指派给骑士。影响了几个小时的订单指派。
第 19 条:上周刚刚出了一个线上事故,就是因为这个原因,mysql 有自动优化的机制,会自动根据数据量而采用它认为的最有效的索引。解决办法:是设置 mysql 强制采用我们设置的索引。