@sujin190 我表述有问题，我不是指 java 无法显式进入阻塞，而是我想知道如果翻译成 c/c++代码，这个阻塞是如何实现的，涉及那些操作系统或者硬件级别的操作，我不理解这个过程。

@lixuda py 提供了 ffi 接口和 IO 复用以后，理论上多大项目都没问题，语言只是工具，不要听一些人胡说

使用一种语言解析其他语言的 AST 本身不是常见需求，尤其对于 GO 这种生态，我不看你能找到别人写好的项目

@lostvincent 感谢回复，我考虑了一下觉得我要的应该是主从，只是网上搜索信息一般集群指向 rac，似乎并非主从方案。

@zw1one 分表拆不太开，子表方案测试过，拆了一万多张，性能反而下降很严重，目前用的表内分区的方案。orcl 的集群我不是很了解，网上资料没有 mysql 这么多，我查到 rac 集群的方案，感觉多实例读一块共享存储，不如多实例。还有一种方案也许是同表内多分区存在不同实例里，但我不会配，似乎也没有类似的方案

62 播放也能被你正好看到？这推广好硬，好硬啊

楼主说的应该是静态类型。不过静态类型也有几种程度的静态类型，

第一层比较浅的，是你指定关键位置的特定类型，满足两个最小目标，其一是 runtime 可以动态检查是否所有输入都满足该类型，其二是使用 IDE 可以看到提示。这个就是目前 python 使用的方案，虽然 runtime 检查没有杀手级产品，mypy 并不好用，不过仅满足项目需求的侵入式检查框架自己实现成本也不太大，而 IDE 补全在 pycharm 里已经有，虽然对 sublime 用户并不友好，但总体来说堪用。

第二层完全静态，对于 python 是愚蠢且无意义的，动态是一项伟大的发明，这是动态语言后发但能逐渐蚕食静态类型语言的原因，因为它确实解决了静态的痛点。python 的设计哲学是高动态与强大的描述能力，对比 c++的哲学（ Zero-Overhead Abstraction ）可以明显感受到本质不同。别的不说，假如存在静态 python，它有良好的优化空间和高速的 JIT 解释器，但写代码时不是光标注`lst: list`就完事了，大多数时候你还要标注数组中储存对象的类型，比如`lst: list[int]`，从此以后你只能往 list 里面增加 int 类型，甚至无法添加 float 。你能接受吗？如果如此为什么我不使用其他语言？

@mingl0280 f2b 这东西得接入日志吧，咋接 windows 日志不会啊。至于自己写，怕是写完以后因为运行占用太多 CPU 资源导致以为被攻击┓( ´∀` )┏

@seakingii 有一说一，我觉得 c#在 web 领域还不如 py

@shiji 不好意思，学生 ID 是学生表的主键，写问题时比较头昏直接写上去了，成绩表有业务无关的主键

@jhdxr 数据库是 mysql，但是想了解一下 oracle 怎么实现这个复杂操作，大佬能指点一下么

说句题外话，请问 windows 上有类似 fai2ban 的工具吗？

flask 本身属于比较慢的那类，同步框架本身慢一些，flask 又不是 tornado，bottle 之流。要减轻开销最好上异步

@binux 提这个问题主要是我 8 核才提升 2 倍性能，比较诡异所以来问一下，看大家的跑分感觉可能是我硬件问题，不是 python 或者调用方式有问题。物理 8 核心分配 8 线程，资源足够的情况下执行顺序先后完成时间差别不大，属于比较粗略的计算方式，因为不需要进程间通讯。

@LeeReamond 128 核的话，多进程又为啥会是 5x 加速呢，毕竟有 8 个进程。。神秘

@no1xsyzy 看到你的讨论想说些题外话。目前 python 指定核心分配进程有可用方案了吗？能想到一个典型场景是 gunicorn 每个进程绑定后线路应该能提高一些。

另外绑定核心这件事应该怎么理解，比如我的主线程绑定到 a 核心，然后我新开了一个线程调用 dll 插件，这个操作过程用释放 gil，那这个并行线程是会另找地方还是只能在当前核心上排队？

@no1xsyzy 刚才群里跟大佬讨论，大佬说你这个进程间通讯时间都没算，测个屁。我倒只是想得出个大方向结论，没想那么精确，不过我觉得在预激的基础上，进程间通讯的开销应该在微秒级，最慢不会超过几毫秒，这不是影响 4 秒执行时间延长到 12 秒的理由

@vipppppp 我无法解释你的跑分结果，虽然这个代码也只是图一乐，并不严谨，但是应该不会影响大方向结论。比如你在超多核的机器上多线程反而特别慢，我觉得有可能是同一段逻辑在不同物理核心上交替运行，期间资源移来移去产生的开销。不过在 12 线程上也这么慢就不合理了，12 线程可不太像是双路 cpu 。。。因为是纯 python 实现，正常多线程的 speedup 就应该是 1.0 左右

@vipppppp 感谢，看来确实可能是我之前忽略了睿频的问题，不过大佬你这个结果里多进程是符合期望的，多线程在 gil 下顺序执行，不应该这么慢