高并发时候的表类型如何选择？"MyISAM" OR "innoDB"
目前在捣鼓一个小型的互联网项目，从项目开始到现在，mysql一直是系统性能的瓶颈。我之前没有很系统的接触过或仔细的研究过mysql，一直都是遇到问题，解决问题，也不知道是否会给后期项目带来什么风险。

我分享几次调优的经验，希望版主以及达人们能够给点建议。

第一阶段：
这个阶段表的数据量还不算很大，只是有个别的表开始超过百万，这时候的瓶颈主要体现sql上
解决方法：我写了个shell，作为mysql的性能监控。当cpu超标时，记录正在执行的sql。同时分析数据库慢查询日志。针对速度可能会慢的sql，挨个排查。有些是由于索引引起，有些将业务逻辑简化，有些将表关联打散，有些做冗余表。

第二阶段： 
这个阶段表的数据量扩展了一个数量级，特别是几个主表【用户表】、【动态表】、【用户关系表】等，都达到了百万级的数据量,经常性出现sql locked的情况，已经不是单个sql的问题 
解决方法：再多次优化sql无果的情况下，我将几个大表的类型都从myisam改成了innoDB，将表锁改成行锁。

现在的问题：
这个项目对数据的完整性要求不是很严格，所以不需要实现事务。看网上的几个帖子都说：当需要事务的时候才用的上innoDB，其他时候还是myisam性能更高。我想请教如何在myisam的基础上，尽可能的支持高并发，这是数据库层面的问题，还是业务逻辑的问题？

@ACMAIN_CHM

------解决方案--------------------
网上有很多错误的帖子误导别人 所以在全面了解innodb以后就会没理由不选择他了 全面抛弃myisam吧
------解决方案--------------------
另外监控用线程的工具要比你自己写脚本完美的多

单单看个cpu和没监控差不错
------解决方案--------------------
你的这样情况，还是应该使用INNODB， INNODB在访问性能上不如MYISQM，但支持行锁。
------解决方案--------------------
INNODB性能不如MYisam,但INNODB支持行锁的。
------解决方案--------------------
就我个人理解，关于数据库的优化，其实是分很多方面来说的，首先，假设你在SQL上的优化已经无可挑剔，业务方面也做得尽量简单，那么你可以考虑做这样几个事。
减轻单表压力：
1.在你原来表的基础上启用分区表，或者分表，把表按照ID取HASH到几张表示，减小lock table的概率，可在原来的代码层下加一个逻辑层专门完成这个任务
2.根据项目读写负载，适当增加Slave服务器，并且按照业务区分不同从服务器的功能，最大可能利用缓存。
减轻整体数据库压力：
3.把不同的功能分布到不同的服务器上，每个数据库服务器只针对一个功能
4.尽量使用缓存，一层一层减轻数据库压力，能延时更新的就延时更新，从业务上减轻压力
PS：
1.Mysql官方有说明，我自己也做过测试，Innodb表的运行速度和MyIsam的速度差不多，而且Innodb在数据的安全性上要比Myisam好一些，高并发Update情况下，Innodb的表现较好，一般不会锁住整张表，Select的表现两者相当
2.如果表设计的合理，理论上来说，现在的服务器配置，单表1亿左右是没有问题的，实际操作的时候，个人经验1KW左右是个比较合理的范围(相对于维护，备份等工作)

尼玛，老子从来没写过这么多字