(转) MySQL_纠结一个MySQL引擎选择，请大家一起讨论支招
先非常简单的介绍下应用场景吧：
（1）网站应用，读大于写，或者说至少80%是select
（2）核心业务比较简单，核心就三种数据A、B、C；这三类数据都是简单的数据类型，不涉及大字段或者很长的char类型
（3）数据量的估算暂定为2年左右的预期增长吧
     （i）A的数据量大约在10~50万之间，即预期前期（前半年）10万左右，2年内增长到50万左右。
     （ii）B的数据量大约是A的15倍左右。
     （iii）C的数量大约是B的20倍左右。
     （iv）即，如果A有20万条，B大约300万条，C大约6000万条。
（4）因为是一个接近服务器的东西，并发数不会太高，预期150~300rps

数据库本身没得选，就是MySQL。其他客观条件决定了。
当然，这个数据量分表是必须的了，这里就不多说了。前期设计的时候就考虑到了分表。

现在主要是上线的引擎选择：MyISAM还是InnoDB？

两种引擎的差异挺大，具体到这个应用，分别的最具有吸引力的地方：
MyISAM：表结构、数据、索引单独存储
InnoDB：行锁
对于事务的支持，有则更好，没有也无妨，毕竟业务逻辑不负责，在应用里面处理也不错

望大家支招。
======================


建议InnoDB吧，虽然MyISAM很适合你目前描述的场景，但MyISAM的数据恢复简单就是灾难，除非数据丢失不重要。
使用MC+InnoDB 解决性能问题。

=======================

谢谢大家支招

前两天测试了下3000万条数据的情况（数据根据实际场景随即生成，不是顺序的插入2000万条数据）。
目前而言，针对的key的select性能还是可以接受。

为了测试MySQL配置与数据量的一个大致关系。第一阶段的测试基于极其有限资源（表空间用单数据文件，MySQL配置小内存）
之前配置了一个实例，MySQL整体的内存占用量配置在180~200M之间，表空间接近4G。基于此配置，对于C表基于A外键（业务如此，数据库并不建外键）的select第一次在0.7秒左右，第二次就压到0.01秒了（当然了，基于索引的检索，DB cache罢了）。实际应用中如果再加上一级应用缓存（至于用ＭＣ或者其他当时候再确定），ＤＢ的压力会更小一些。测试的整体情况而言，是可以接受的。

后续会逐渐增大数据量、分割表空间、分表甚至做更多分割、慢慢增大MySQL数据量进行测试。。。。。

平时还要很多其他杂事，估计测试过程会比较长。。。。期望春节前能完成。

============================

现阶段还考虑到单表建库，这个从数据管理的角度最好了；但是对于开发的整体要求比较高、底层的框架变动也不少。。。

平衡中。。。。
===========================
如果读远远大于写，并且不需要事务支持，建议myisam，前端加缓存分压，表大分表。

========================