multipart 上传文件

可以的，mark 一个

怎么可能会不稳定...这种情况第一时间必须是怀疑是 SQL 的问题...
先看看关联的字段类型是否一致？

如果使用 Java 成员的话，不是很懂第一问和第二问在实现上有什么区别。。
不使用类成员的话，用内部类实现闭包？

@windcode 回复不支持 markdown 真是蛋疼，缩进都没了，上面的 else 是 while...else，不是 try...except...else。

装饰器加设置重试

```python
def request_retry(times):
def decorator(func):
def wrapper(*args, **kwargs):
while times > 0:
try:
return func(*args, **kwargs)
# 各种异常捕获
except RequestException as e:
times -= 1
else:
raise HTTPRequestFailedException() # 自定义的异常
return wrapper
return decorator
```

Promise 或 async/await 了解一下

火币

@u3u 楼主看起来像是用的网页版网易云。楼主可以试试架着梯子也是没法看腾讯视频的。

最近膨胀了，深圳二套房都敢点进来了...

优先考虑分区表。分区表在 MySQL 的底层存储同样也是多表，不同分区的数据和索引都是独立的 idb 文件，和分表区别不大，还不需要修改业务代码。
若用评论时间来作为 key 进行分区，楼主的部分业务逻辑虽然不需要改代码，但涉及到跨分区的查询依然无法提高性能，还可能比未分区前性能更低。
我建议对 aid 来进行 hash 分区，即对 aid 的值求 hash 后对分区数 n 取模，这样不会造成明显的数据倾斜现象。MySQL 有现成的 hash 分区。
缺点就是分区数固定，不好扩展，但要是能预估好表的大小，分区数可以设置多一些，问题也不是很大。

参考 MySQL 的 Join 实现：(Nested Loop join)[https://dev.mysql.com/doc/refman/5.7/en/nested-loop-joins.html]
遍历 A 是避免不了的，那我们可以在 B 上做索引来实现加速。
楼主自己想到了将 B 转为 K-V 形式这就相当于 hash 索引，时间复杂度为 O(n)。
当然可以将 B 做成其他的数据结构，比如平衡树等。

Git 用 gitlab，文档都在 confluence 上，设计稿及其他项目文件自建 ftp。

同楼上，一次返回十万条数据的 SQL 本身就没有上线的可能了。