上海MYSQL大会摘要

【谭俊青：MyISAM和InnoDB的比较】MySQL存储引擎图，使用最多的是MyISAM。一般爱可生推荐InnoDB给客户。MyISAM存储构成：3个文件（tableName.frm, tableName.MYD, tableNameMYI），不支持事务，表锁。

 

【谭俊青：MyISAM和InnoDB的比较】MyISAM行存储格式 1 定长-表结构中没有变长字段，默认就是定长存储。好处（高效能，更好的恢复能力，不需整理） 2 变长-表结构如果包含varchar, varbinary, blob, test等字段，则以变长存储。坏处（可能造成碎片，增加恢复难度）3 压缩格式-只读格式

 

成江东：盛大糖果社区的几个问题 1 并发压力快速提高？ 2 需求变化快？ 3 数据水平拆分？NOSQL数据库能否解决这几个问题。

 

成江东：议题：MongoDB是什么、特性，适用场景，与其他数据库的对比。NOSQL数据库是非关系型的数据库，主要用于社区类web2.0网站。主要解决1 对数据库高并发的需求 2 对海量数据的高效率存储和访问的需求 3 对数据库的高可扩展性和高可用性的需求。

 

 mongoDB是什么？ CAP理论-鱼与熊掌不可得兼。一致性（C)，分区容忍性（P），可用性（A)。一个分布式数据库最多只能同时满足两个。1) CA 传统关系数据库 2) AP：key-value数据库

 

因此，根据CAP理论。mongoDB不能解决：数据库事务一致性需求 2 数据库的写实时性等。MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似 json的bjson格式，因此可以存储比较复杂的数据类型。

 

mongoDB使用JSON格式文档数据库，文档（document），集合。自由数据模式：支持在对象和数组中嵌入其他的对象和数组，mongo模式设计中的一个关键问题就是值得为这个对象新建一个集合呢？还是把这个对象嵌入到其他的集合中。

 

mongoDB的索引设计很重要，支持很全面。包括基本索引， 唯一索引，内嵌文档中key，文档本身，复合索引，在线索引。

 

mongoDB复制和自动分片带来的高可用性。一个失效，自动切换到另外可用的服务器上，几个服务器形成分片集群，2个以上的shards，1个以上的config servers，和任意数量的mongos servers组成，应用程序连接mongos servers。

 

找了5台服务器进行了模拟测试，一个php脚本。发现在初期，分布不均匀，第一台DB上有100多万条，另外2,3台都是30万条左右，增加一台服务器，增加到500万条以后，发现数据已经变为非常均匀的

 

mongoDB的丰富的查询语句：in查询，排序u，exists，查询分片，count，正则，游标，类型匹配，数组元素个数。

 

mongoDB Map/reduce是聚合和过滤数据的工具。mongoDB的性能优异（并发性能有1.5万多秒，无外键约束，五事务，异步写磁盘。） 还有其他特性（GridFS，使用方便，会自动创建数据库db和集合collection，无需显式执行。）

 

mongoDB的适用场景 1 结构不固定，有数据嵌套 2 要求高并发性 3 经常需要做数据水平拆分 4 内存大于数据量（推荐） 不足之处 1 比较占用磁盘空间，性能受内存影响 2 性能依赖内存，同时无法指定内存大小，容易被其他程序占用 3 不支持事务，不支持join 4 每个document限制最大不超过4MB

 

为什么选择mongoDB？性能优异，扩展力强，面向文档，部署简单，功能全面，易于开发，支持全面。邮件组google groups mongodb-user， 豆瓣小组 mongoDB。

 

其他的nosql数据库简要分析：redis可以被看成加强版的memcache，redis和tokyo cabinet，没有mongoDB的自动分片技术，tokyo cabinet是个人维护的，在盛大超过1亿记录测试时候有性能问题。在盛大糖果中有部分应用用到。Cassandra查询不够丰富，稳定性较差。

 

糖果社区有少数应用在用Tokoy Cabinet, 已经尝试mongoDB，将增加一下应用的部署。当然，主要还是在使用MySQL。应该是与MySQL结合起来，互补优势，得到综合的效益。

 

优化包括：表设计，索引规划，语句优化，存储过程，触发器，视图。1 表设计：命名规则（不用保留字，多字节字符），字段类型（数值，字符，二进制，时间，其他）要合适，主要关注性能，磁盘存储，数据精确度等做个平衡选择。比如精确浮点数必须是decimal, 实际上是字符型存储,性能差。

 

1表设计续：引擎选择，MyISAM （快读，高压缩比 表锁）； InnoDB （事务支持，外键支持，行锁，热备支持）；memory （内存数据，表锁）；InnoDB是单机版唯一支持事务的引擎。Memory的安全性查，内存出错就完蛋，但是IO性能肯定很高。

 

1表设计续-引擎介绍：最可靠的引擎 NDB（MySQL Cluster）：支持事务，高并发写，Key-Value 可持续化，99.999%的高可靠性。Archive：比MyISAM更高的压缩比，缺点很多（只能插入，不支持主键）。CSV是EXCEL和MySQL之间沟通的桥梁 BlackHole：缓解Replication中主的压力。

 

1表设计续：【编码选择】单字节，多字节；经常有乱码出现，原因是导出文件，终端系统字符集不支持，再导入到新数据库中，就变成乱码了。【索引规划】唯一索引，普通索引，部分索引，聚簇索引，外键；外键只有innoDB支持，尽量不要随便用外键，会影响性能。

 

【语句优化】关注响应时间，整个时间包括执行时间和传送时间，需要不断研究优化。语句优化的一些好习惯，1) 如果能不再SQL使用内部函数，就不要用; 2) 用join比where性能好; 3) 注意类型匹配，整型不用'', 如'15'和15; 4) 通过增加字段如 column_length，代替column(length);

 

语句优化 5）like 'de' 可以写为 >='de' and <= 'df'；6）去掉不必要的临时表和不必要的字段，排序等；7）缺乏必要的过滤条件；8）MySQL5.5之前对子查询处理不够优化，不如JOIN语句快；9）不同类型的字段做关联查询，需要修改字段类型为一致；10）多记录某一条精确定位慢。

 

 语句优化：11)对复杂查询中，多个字段从一个表中选取，表扫描次数过多，IO操作多，影响速度；

 

使用摘要表 优点：减少对原磁盘表的访问 缺点：要做适当的更新。经常更新的数据，可能不合适。比如对于报告表就比较合适。

 

 写语句优化 触发器的优化，特点：行级，临时行表，前置、后置。视图尽量不要用，对性能很差，因为不用索引。即使要用视图，限制也很多，时间关系不多讲。

 

MySQL Replication 异步数据复制，负载均衡；在线热备，水平扩展；跨网数据复制；Fail Over --- 手动切换。可能6种复制方案，1主1从，1主2从，2主1从（不好，不推荐），1主1从2从 对等复制 1主1主（可能有问题） 三个彼此复制，1主1主1主（可能有问题）

 

MySQL Replication 在Scale out时候性能是不错的，可以分步实施到多个Slave机器上。Slave可以作为在线热备的功能。当主数据库出问题，可以手动设置，把主上的操作全部切换到从机上，保证对外部的访问

 

MySQL Cluster 特点 1)无共享存储的数据存储模式;2)实时同步数据;3)特有应用下的高性能，高事务吞吐量;4)无特殊硬件需求;5)内存存储数据&硬盘存储数据(5.1版本) 6)Fail Over-- 快速，自动; 7)数据节点间心跳机制；

 

MySQL Cluster数据是按照主服务器的方式来存储的，在每一个主里面的数据节点上，都是通过另外的数据节点来提供副本的，一个节点出了问题，还是会能继续服务的。极端情况下，2个点点坏了，或者一个节点的部分和另一节点的其他部分坏了，又该如何考虑呢？

一般，2个管理节点，就可以满足管理集群的需求。但是2个节点坏了，需要第三种高可用性解决方案，MySQL Cluster with Replication. 还作为异地备份的容灾备份。

 

Heartbeat & MySQL Replication 1)心跳机制-资源故障切换的安全管理；2) 虚拟IP管理--对应用访问数据库透明化; 在主从之间加了heartbeat软件，提供自动切换机制。

 

Heartbeat, Block and MySQL Replication 分布式块复制（DRBD）运行在标准网络协议上。通过网络IO提供数据传输，有时候比同步还快。在Active出问题后，必须进行数据同步，修复后切换回修复后的服务器。

 

 MySQL with Shared Storage 1) Active/passive 多实例访问同一份数据文件 2) 特点: 较高的成本开销 同时把数据存储在共享存储SAN里面。

 

以上内容来自 新浪 @thinkinlamp 的围脖