@wbd31 大部分题目谷歌一下都会有详细答案的，如果找了还没明确的话欢迎再回复讨论

@liprais 譬如可以怎么改进？

重新看了一眼楼主需求：
本着节约服务器资源（省钱）的思想

觉得这个不应该换 golang...

@lazyfighter 3F 我已经回复过了会阻塞.....

复现成功插个眼蹲一手答案，另外几个测试 case：
1. insert into t VALUES (6,5,6); -- 阻塞
2. insert into t VALUES (6,4,6); -- 执行

不靠谱猜测：
1. 阻塞肯定是因为锁定区域有重叠；
2. 既然重叠那肯定是猜测 session A 锁定了 [10, 15] 这部分，session B 锁定了 [5, 10] 的这部分（边界是开区间闭区间暂且不进行确认，但是必然是有重叠区域的，例如这里的猜测 [10]）。

其他的提示信息：
1. Explain 结果显示 session A 的查询使用了 Backward index scan ，提示这里对 idx_c 的使用是反向的，因此 15 的 Next-Key 是 10 （可能）没错。

蹲一手答案。

@YadongZhang 说的太对了

很多时候只是因为开源了某个项目 /服务 /代码，其他人可以自由使用，不代表使用一定就得不收钱

以前压制组做过比较久的时间，说一下组里面一些比较实践向的做法（但不一定科学、有依据）。

我们在拿到 1080p 的蓝光原盘的时候，通常需要决定要转码成 1080p + 720p 发布，还是仅仅产出 720p ，那这个决定的因素在于蓝光原盘本身是否具有 1080p 级别的细节，因此反向考虑，如果它压缩成 720p 后，再拉伸至 1080p ，如果画面跟原来的 1080p 没什么区别，那说明它就只具有 720p 级别的细节。

4K 也可以做一样的处理，如果 4K resize 到 1080p ，再 resize 到 4k ，前后比较一下差别明显的话，说明有 4k 存在的意义，否则只需要保留 1080p 即可。

不科学的地方在于 “比较” 的过程是靠肉眼看的，那每个人的所见、感受肯定是有差异的，只能说对于从低分辨率拉伸上去的源，跟原生高分辨率 & 高码率拍摄的源，差距是非常明显能判断的；但是一些高分辨率 & 低码率的素材在 resize 过程中变化比较暧昧，就很见仁见智了。

@MeteorVIP 其实不刷流量，赚魔力值也行呀，反正挂着也是白浪费电费，性能不用追求太多咧

@GeruzoniAnsasu 我看你的描述很多时候只需要 wait group 吧。。wait group 的使用非常简单，只有需要 goroutine 间通信的时候才会需要 channel 呀，业务应用里面 goroutine 大部分场景都是用来并行做一些事情，例如并行发起 http 调用，我 golang 用了有小几年了没有感觉到什么不适而且觉得很好理解

当然你可能在描述一些多个 channel 之间共同协作，需要知道互相的结果，需要传递数据的情况，我不了解在其他语言怎么做的，但是我觉得常规开发里面写出这样的逻辑设计本来就已经对可读性不友好了，不能说只怪 golang 吧

@TtTtTtT 怎么会难懂呢...或许你可以举一些认为难懂的例子大家康康具体是哪里不容易阅读

@bearboss 自增区间会有反解的风险但是并不能说太明显

1. base62 算法你可以自由实现，包括如果不按照 ABC..XYZabc...xyz123..89 这个顺序，如果我将数字安插在不同字母之间作为 base62 算法的 base 呢？只要保证生成和解析是相同即可，不一定是服务外能简单猜测到的排序
2. 除了单纯的自增，在分布式场景中你的短链生成的机器有非常多，例如 50 个机器，每个机器除了有它自己的号段以外，还需要将机器号埋入 base62 之前的明文，例如我为每台机器分配名字：33869 、22193 这些都是无规则的 ID ，可以进一步混淆 base62 前的明文

类似的 trick 还可以举例好几种，仍然有反解的风险，但是我理解这个东西得看是否产生价值，如果反解要花很多时间的话那我觉得服务端的目的已经基本达到了

@InFaNg 有没有什么更稳定的唯一 ID 生成方案呢，或者你这里已经用了 base62 了，那有没有什么稳定的唯一十进制数生成方案呢，这里的 DB 查询完全可以避开的

$random_number = rand(14776337, 916132832); // [62^4 + 1, 62^5]
while ($db->where('id', $random_number)->getValue('fwlink', 'count(*)') > 0) {
$random_number = rand(14776337, 916132832); // [62^4 + 1, 62^5]
}

这个方案不会在短连接数量很多的时候产生一些冲突吗，这里大概有 9 亿的可用值，也就是说数据量达到 3 亿左右基本上就有 1/3 的请求会需要查 > 1 次 DB

另外在访问的时候，相当于所有的访问都要去查询 DB ，即使链接是用户随便输入的

无恶意纯随便探讨一下，小工具做得挺有意思的页面简洁好看。

形式挺好的 star 了

有些公司的记录是不太准确的，例如列表里面某公司只有高绩效（前 20%）才能拿到所述的年终奖，并不能代表大部分人的情况

小心一会又有人来喷你说刷题是服从性测试了

@yifangtongxing28 这说法也太极端了吧，为什么不能允许别人从刷题中有什么收获呢，包括代码怎么写比较优雅、良好的命名习惯、数组的定义 for 循环的姿势，双指针的玩法，这些在实际项目中都有过踪影