新版本测试 + 逐步替换旧版本

我个人觉得还是有必要的，MongoDB有锁库(低版本)和锁表(中版本)的问题，即使有存储文件的分片，但是在建立索引、以及在查索引的时候开销还是巨大！！！！数据过亿的时候还是坑多！

这个纯看个人爱好

获取不到 此信息浏览器不会上报给服务端

部署两个域名啊: [链接]和 [链接] , 相关的地方跨域即可。

反向代理的时候使用http的长链接：http版本为1.1 + keepalive

有一定的影响是肯定的，不过应该很小，具体有多少影响需要你们自己做一下测试。

因为 start 里面已经开始事件循环了。你可以理解为这里面是死循环。

[链接] 好像这个不错，国人做的。

select * from tb_name where {代码...} order by id asc;

事实上，你改写成 INNER JOIN 后，性能已经得到了改进。 第一条查询的 cost 为： {代码...} 第二条查询的 cost 为： {代码...} 所以你的目的已经达到了。 改进的原因是，使用 INNER JOIN 后，覆盖索引（covering index）发挥了作用，整个匹配过程只需要 film_id 和 t...

1、断开链接会自动rollback2、死锁或者这个锁超时的时候，也会rollback

但是也有人说尽量不要去使用外键，在程序中控制数据的完整性约束性就可以了，否则不方便维护你要看是什么人说的。很多程序员的数据库水平比不上用户。这些人认为程序是万能的。很多DBA认为数据是最重要的，比程序活的长。程序不能用了，数据仍是企业的重要资产。

但是也有人说尽量不要去使用外键，在程序中控制数据的完整性约束性就可以了，否则不方便维护你要看是什么人说的。很多程序员的数据库水平比不上用户。这些人认为程序是万能的。很多DBA认为数据是最重要的，比程序活的长。程序不能用了，数据仍是企业的重要资产。

这种问题都是经常问的，网上搜出来也是一堆所谓的解决方案，大家都是重复提问重复回答哇。@BUBBAK 的回答已经七七八八了。首先，你要知道你的Mysql瓶颈在哪条语句上，开启慢查询，设置好你自己的指标，然后观察。得到数据后，对你的mysql语句优化，具体方法百度已经...

要是我 我直接在 NGINX 成面上干掉大部分流量

{代码...}