楼主你家有没有杜邦线？如果有，我教你给简单方法。
两根公对公，一根公对母的杜邦线。
找你电源出来的供电线有没有软驱线？就是小四针
如果有，软驱小 4 针，中间 23 两针是 GND ， 1 针（通常红色）是+5V,4 针（通常黄色）为+12V

用两根公对公把风扇正接+12V ，负接+5V ，这样风扇就只有 7V 左右的电压，转速下降，更静音

然后用一根公对母延长线把 3pin 风扇测速针接到主板测速口，保持风扇速度检测功能存在避免坏了风扇烧 CPU 还不知道

PHP: str_pad

@defunct9
这种美国地址能看得动 youtube 1080P ？如果搞 ss ，最次也是弄个便宜 vps 套 finalspeed 才勉强及格啊
单纯的能访问这种档次的要求，太低了吧……

@yexm0
IP 我都有，我实测了几周，就 PCCW 的稳定性最好，综合速度排第二

@402645707 不换个说法， V2EX 都会自动转移到 chamber ……

@VmuTargh
那应该是你本地服务商的 DNS 不给解析 google 的域名导致的，用我这个就没问题的。
我说的回归，指的是内容已回归，具体你能不能访问到还得看你自己的网络，用我这个方法强制返回 IP 就可以了

@VmuTargh
我这里没啥问题啊，你那里不行么？跟 360 这种把 cdn 堆到家门口的没法比，但是绝对比自己服务器快多了……

@maomengcheng
你们作为平台产品提供方，开放程度应该多考虑考虑，生态系统建立好了，能让更多的开发者在其中找到自己的模式，你们的产品都不用自己推广就能卖。

玩得起全自动化部署自动化实施自动化弹性扩容的，哪个都不是小客户，给他们方便了，比如我之前说的这种模式，如果你能多主动提供类似的方案，很多大的解决方案公司会选择你阿里云可以全自动配置还是去选择别人家 VPS 一点点手动装？即使同等选择，实施人员也会从自己的工作量角度劝真正客户用方便的，这不比 9 折促销什么的拉动消费实在多了……

@msg7086
我觉得这是正常想装文艺结果二逼的典型……

@pubby
不一定会的。导致锁表那个操作并不一定执行频率很高，未必能 show processlist 准确抓到。
卡住以后，堵了太多 update ，然后当那个锁释放的时候，这个待执行 update 队列就变态的大了， show proceslist 只能抓到正常的高密度 update 。

@sujin190
云服务器，你确定不是 IO 的问题？感觉可能性极大……
另外发个 show create table XXX 上来让大家看看吧，感觉也可能是其他联合索引更新导致的锁
你这个 update 操作密度比较大， 100 次每秒，一旦一个其他导致锁的操作阻塞，你的 update 进队列，一秒就堵 100 个查询，导致阻塞的操作的频率，决定了累计程度，时间长就这样了，也是很可能的。

@tanteng 你想多了，两个人微秒级同时操作？总有先后顺序的。

@sujin190
1. 本地服务器 or 云服务器 or RDS 服务？
2. 看你透露出来的表结构，有唯一自增主键，同时 orderid 有唯一索引，根据 orderid 去更新非索引列，这种模型对吧？那么， update 没问题，有问题的是其他查询导致的锁表，然后 update 就进队列了，发生三五十次，因为 update 非常频繁，堆积就很严重了，检查 slowlog 吧。