一次性取到太大的结果集不一定就是好。除了加大对应的配置参数之外，可以考虑把一条sql查分为N条sql，这个可以具体的自己测试，比如每次取三个小时四个小时这样试试看得到一个平衡。

梳理sql，减少慢查询。通过多次查询来组合数据优化数据结构，操作+时间应该是一个索引(或者是时间+操作)。其实简而言之就是减少复杂sql，尽量通过其他方法去弥补。

如果是单机的话，flock是很好的阻塞锁解决方案。事务跟锁是两个概念，并不能混为一谈。。如果是分布式锁的话，redis会比mysql更合适，因为redis的性能会更好，实现也很简单。

事务跟并发没有任何关系。你使用事务只能保证这一段逻辑成功或者失败，而不能保证并发时能控制住你的程序逻辑。对并发进行控制还是需要锁 来解决，比如楼上有提到的mysql 实现乐观锁。如 upadte table set a = a - 1 where a = 5; 只有在a=5的情况下这个update才会真...

用js做一些限制，做混淆加密，提高对方修改的难度。

单进程所以原子性，，但是回滚另外一个概念了吧。。

竟然都在说json_encode性能好。。其实这个是跟你要处理的数据和PHP版本有关系的。不过还是建议json存储，更通用更语义化更方便使用。

token = aesHash(uid +'|' + mKey + '+' time)response.cookie(token, token);

可以自己重写session，方便对各种规则进行设定校验。

var page = document.getElementsByName('tag');for (var i = 0; i < tag.length; i++) {tag[i].onclick=fun;}function fun(){console.log(this.vaule);}

1、异步延迟还是会经常出现的，这个时候可以采取主动查询的方案。由系统定时或者用户触发查询支付状态接口。当然这个接口要谈。2、explain3、这个你回答的也太简单了，json只是说交互的数据格式。协议、安全、性能，每个点都能扯上几句起码代表还算比较了解的。

2、大量update的确会对表造成一些影响。不过不建议大量拆表，这样虽然可以降低写的压力。但是代码结构可能维护起来就很灾难了。毕竟不可能无限进行分表。。建议前面加一层cache。redis or memcache。 数据id_key 进行incr操作，达到某个值进行同步到数据库。比如rand...

还有就是js对象最后一个值结束还是别加逗号了

把所有的xhr实例都放到一个数组或者对象里。

看具体情况，对并发比较大的情况下redis会比较有优势，而且incr系列api又是保证原子性操作。mysql速度会稍微差些，ssd也不会有内存快。对于这种有key/value操作显然nosql产品更有优势。

一个访问不等于一次数据库查询。复杂的业务可能要从几十张表获取数据。而且复杂度是随着访问量几何增长。最最重要的是访问量不会那么均匀，服务器负载也没有那么乐观。。