思考很久，还是从金山离职了，以后就是真正的旧金山。接下来准备休息一段时间后去参加百度面试。所以这段时间可以专心的更新一些技术文章，顺便把前面欠下的几个应用一起写了，包括极客密码和开源自己的博客。另外大家有什么感兴趣的项目或者对什么技术比较有兴趣，可以联系我一起讨论！
一直在用MySQL，但我从来没测试过MySQL的性能，只是觉得MySQL很强大，玩转千万数据都能轻轻松松。正好MAC上装了MySQL。就测试了一把，顺便把过程分享出来。
1.MySQL超过最大连接数会怎样？
MySQL超过最大连接数其实很常见，只不过现在的程序员都习惯了加缓存（反正不要钱，配置成本又低。静态缓存一般框架自带，Redis基本没学习成本。）所以比较少遇到这种情况。下面是测试代码，我将mysql的连接方法写在了循环中，在数据插入成功后，再关闭数据库连接……
测试结果：
每开16300左右个连接，程序就会等待15秒左右。说明MySQL的最大连接数是16300，虽然每次执行完之后都调用了close命令。但是MySQL需要15秒左右的时间来回收连接资源。因此造成了这种现象。但是通过查看MySQL的最大连接数是151（多出来的1是给管理员用的，查看命令”show variables like ‘%max_connections%’;“）
为什么会到16300左右才有超过连接数的情况？
我把MySQL的最大连接数设置的是151，不过无论你写多少，实际MySQL服务器允许的最大连接数是固定的16384；我还发现16384/1024=16K，这难道是巧合？谷歌找了很久还是没找到满意的答案，根据MySQL官方的说法16384这个参数是写死的……可以参考这里的文档：http://dev.mysql.com/doc/refman/5.5/en/too-many-connections.html
在实际的应用场景中，如果16384的连接数都用完了，我们该怎么做？按照MySQL官方的说法，这个时候就应该想办法加缓存来解决这种极端的问题。加缓存还不行，就考虑负载均衡和MySQL集群来解决。再不行的话，数据库基本不适用于这种场景了。像淘宝，数据量在Oracle都无法承受的时候，只能自己写分布式文件系统TFS（国内公司，在大数据处理方面技术最牛掰的非淘宝莫属）。
2.对比MyISAM和InnoDB引擎的性能差异。
InnoDB支持事务，更稳定，所以大家更倾向于选择他。MySQL官方也推荐尽量使用InnoDB引擎，所以MyISAM用的越来越少。今天主要说说他的优点和缺点。
首先我创建了两张表，结构都一样，只不过引擎一个是MyISAM一个是InnoDB。
下面是同时插入299999万条数据是结果：
一共执行了71.919545888901秒 myisam
一共执行了158.843219041824秒 innodb
重复尝试了两次，myisam耗时基本一样，并没有随着数据的增长影响到数据的插入。innodb第二次执行费时483.51841115952秒。与第一相比增长了3倍。第三次耗时481.97113108635秒，之后时间基本稳定在480秒。
查询速度的对比：第一次查询MyISAM比InnoDB快30%左右，第二次查询，MyISAM自带了缓存，所以快了整整二十倍，InnoDB速度没变化。之后对两张表分别加了索引，查询速度都明显提升。不过同样的数据MyISAM还是要更快。
3.关于MyISAM和InnoDB的表锁问题
在插入数据的同时，执行耗时的like查询操作，结果如下：
MyISAM：查询和插入都受到了影响。执行了5次select操作，插入数据一共执行了160.80337119102秒，耗时多了两倍多。
InnoDB：InnoDB也未能幸免，插入的同时查询时间增加了一倍，但是插入数据的性能基本没变，还是471.35298991203秒。所以对于更新和插入操作频繁的表，InnoDB更有优势。
对于有like的查询MyISAM会锁表，对于有like的更新InnoDB也会锁表，因此SQL语句的优化就显得格外重要。对于没有条件的查询和更新我测试的时间都不是很准。但是根据两种引擎的特性，InnoDB在数据插入时只会行锁，只对查询有影响。反过来查询操作不会影响更新和插入的性能，所以插入和更新操作频繁的表，InnoDB的确更稳定。
4.关于limit的优化
limit第一个参数越大，越费时。比如数据一共999999条，通过limit 999900,99的性能远远低于通过order by id desc limit 0，99。
最后总结，如果数据量只是在百万级别，而且不会用到事务，更新插入操作少，查询多的情况用MyISAM性能远远优于InnoDB。比如博客的文章表。更新频繁的表用InnoDB更合适，比如博客中的留言评论表。