189 8069 5689
MySQL 可能是最著名的 关系数据库管理系统 (RDBMS),作为一款免费开源软件开发，最初由 MYSQL AB 公司提供支持，但现在归 Oracle 所有。
成都创新互联公司专注为客户提供全方位的互联网综合服务，包含不限于成都网站建设、做网站、沧县网络推广、小程序制作、沧县网络营销、沧县企业策划、沧县品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们最大的嘉奖；成都创新互联公司为所有大学生创业者提供沧县建站搭建服务，24小时服务热线：028-86922220，官方网址：www.cdcxhl.com
在 MySQL 中，用于表的“存储引擎”决定了数据的处理方式。有几种可用的存储引擎，但最常用的是 InnoDB 和 MyISAM 。
在本文中，我们将了解它们的显着特征以及它们之间的主要区别。
在本教程中，您将学习：
在我们讨论两个主要 MySQL 存储引擎之间的特性和区别之前，先来了解一下什么是存储引擎？
存储引擎，也称为“ 表处理程序 ”，基本上是解释和管理与数据库表的 SQL 查询相关的操作的数据库部分。
在最新版本的 MySQL 中，可以使用“ 可插拔 ”架构来组织和管理存储引擎，存在多种存储引擎，但最常用的两个是 InnoDB 和 MyISAM 。
要获得我们正在使用的数据库中可用存储引擎的列表，我们所要做的就是发出一个简单的 SQL 查询，因此我们需要做的第一件事就是打开一个 MySQL 交互式提示并使用数据库用户登录及其密码：
如果登录成功，提示将变为mysql，在这里，我们可以运行我们的 SQL 查询来可视化可用的存储引擎：
执行查询后，我们应该获得类似于以下内容的结果：
在上表中，作为查询结果生成，我们可以通过查看Support每行列中的值轻松了解支持哪些存储引擎，“YES”值表示存储引擎可用，否则“NO”。相反，同一列中的“DEFAULT”值表示相应的引擎（在本例中为 InnoDB）是服务器使用的默认引擎。
“ Transactions ”和“ Savepoints ”列中存在的值分别表示存储引擎是否支持事务和回滚。正如我们通过查看表可以看到的，只有 InnoDB 引擎可以。
关于存储引擎的信息存在于“ INFORMATION_SCHEMA ”数据库的“ ENGINES ”表中，因此我们也可以发出标准的“SELECT”查询来获取我们需要的数据：
我们将获得与上面看到的相同的结果。
让我们看看两个最常用的存储引擎 InnoDB 和 MyISAM 之间的主要特性和区别是什么。
正如我们已经说过的， InnoDB 是自 MySQL 以来的默认存储引擎5.5。
此存储引擎的一些主要功能如下：
对事务的支持提供了一种安全的方式来执行多个查询以保持数据一致。
当多个修改数据的操作被执行并且我们想要确保它们只有在所有操作都成功并且没有错误发生时才有效时，我们想要使用事务。
典型的处理方式是启动事务并执行查询：如果出现错误，则执行回滚，否则提交更改。
当使用 InnoDB 数据锁定发生在行级别时，因此在事务期间锁定的数据量是有限的。
InnoDB 有两种类型的锁：
一个共享锁允许谁拥有它读取该行的交易，而一个排它锁允许交易执行其修改行的操作，所以要更新或删除数据。
当一个事务在某行上获得共享锁，而另一个事务需要相同的锁类型时，立即授予；但是，如果第二个事务在同一行上请求排他锁，它将不得不等待。
如果第一个事务持有该行的排他锁，则第二个事务将不得不等待该锁被释放以获得共享锁或排他锁。
外键是一个非常重要的特性，因为它们可用于基于表之间的逻辑关系来强制执行数据完整性。想象一下，我们的数据库中有三个表（假设它被称为“testdb”）：一个user包含现有用户的job表，一个注册所有可用作业的user_job表，以及一个用于表示用户和用户之间存在的多对多关系的表。作业（一个用户可以有多个作业，多个作业可以与同一个用户关联）。
该user_job表就是所谓的连接表或关联表，因为它的唯一目的是表示用户-工作关联。该表有两列，一个叫user_id和其他job id。表中会存在两个外键约束，强制执行以下规则：user_id列中的值只能引用表id列中的值，列中的user值job_id必须引用表id列中的现有值job.
这将强制执行完整性，因为仅允许现有用户和作业的 ID 存在于关联表中。删除涉及表中一个或多个关联的用户或作业user_job也是不允许的，除非为相应的外键设置了CASCADE DELETE规则。在这种情况下，当删除用户或作业时，它们所涉及的关系也将被删除。
MyISAM 曾经是默认的 MySQL 存储引擎，但已被 InnoDB 取代。使用此引擎时，数据锁定发生在表级别，因此执行操作时锁定的数据更多。
与 InnoDB 不同，MyISAM 不支持事务回滚和提交，因此必须手动执行回滚。MyISAM 和 InnoDB 之间的另一个很大区别是前者不支持外键。MyISAM 更简单，并且在对有限数据集进行读取密集型操作时可能具有优势（有争议）。
在表上使用 MyISAM 时，会设置一个标志，指示该表是否需要修复，例如在突然关闭之后。稍后可以使用适当的工具执行表修复。
如何知道特定表使用了什么存储引擎？我们所要做的就是发出一个简单的查询。
例如，要知道user我们在前面的例子中提到的表使用了什么存储引擎，我们将运行：
注意上面的查询我们使用了G，为了让查询结果垂直显示，优化空间。执行查询后，我们将获得以下结果：
在这种情况下，通过查看“Engine”列中存储的值，我们可以清楚地看到该表使用的是“InnoDB”引擎。获取相同信息的另一种方法是INFORMATION_SCHEMA.TABLES直接查询表：
上面的查询将只返回表使用的引擎：
如果我们稍微更改查询，我们可以获得数据库中所有表名的列表以及它们使用的引擎：
如果我们要为一个表设置一个特定的存储引擎，我们可以在创建时指定它。例如，假设我们正在创建job表，并且出于某种原因我们想要使用 MyISAM 存储引擎。我们将发出以下 SQL 查询：
相反，如果我们想要更改用于已存在表的存储引擎，我们只需要使用ALTERSQL 语句。假设我们要将上一个示例中创建的“job”表所使用的存储引擎更改为 InnoDB；我们会运行：
在本教程中，我们学习了什么是数据库存储引擎，并且我们看到了两个最常用的 MySQL 引擎的主要特性： InnoDB 和 MyISAM 。
我们看到了如何检查哪些引擎可用、哪些引擎用于表以及如何使用 SQL 查询设置和修改表引擎。
这次的NoSQL专栏系列将先整体介绍NoSQL，然后介绍如何把NoSQL运用到自己的项目中合适的场景中，还会适当地分析一些成功案例，希望有成功使用NoSQL经验的朋友给我提供一些线索和信息。
NoSQL概念随着web2.0的快速发展，非关系型、分布式数据存储得到了快速的发展，它们不保证关系数据的ACID特性。NoSQL概念在2009年被提了出来。NoSQL最常见的解释是“non-relational”，“Not Only SQL”也被很多人接受。（“NoSQL”一词最早于1998年被用于一个轻量级的关系数据库的名字。）
NoSQL被我们用得最多的当数key-value存储，当然还有其他的文档型的、列存储、图型数据库、xml数据库等。在NoSQL概念提出之前，这些数据库就被用于各种系统当中，但是却很少用于web互联网应用。比如cdb、qdbm、bdb数据库。
传统关系数据库的瓶颈
传统的关系数据库具有不错的性能，高稳定型，久经历史考验，而且使用简单，功能强大，同时也积累了大量的成功案例。在互联网领域，MySQL成为了绝对靠前的王者，毫不夸张的说，MySQL为互联网的发展做出了卓越的贡献。
在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站不多。
到了最近10年，网站开始快速发展。火爆的论坛、博客、sns、微博逐渐引领web领域的潮流。在初期，论坛的流量其实也不大，如果你接触网络比较早，你可能还记得那个时候还有文本型存储的论坛程序，可以想象一般的论坛的流量有多大。
Memcached+MySQL
后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。
Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展，然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端。当时，如果你去面试，你说你有Memcached经验，肯定会加分的。
Mysql主从读写分离
由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。
分表分库随着web2.0的继续高速发展，在Memcached的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候，MySQL推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群，但是由于在互联网几乎没有成功案例，性能也不能满足互联网的要求，只是在高可靠性上提供了非常大的保证。
MySQL的扩展性瓶颈
在互联网，大部分的MySQL都应该是IO密集型的，事实上，如果你的MySQL是个CPU密集型的话，那么很可能你的MySQL设计得有性能问题，需要优化了。大数据量高并发环境下的MySQL应用开发越来越复杂，也越来越具有技术挑战性。分表分库的规则把握都是需要经验的。虽然有像淘宝这样技术实力强大的公司开发了透明的中间件层来屏蔽开发者的复杂性，但是避免不了整个架构的复杂性。分库分表的子库到一定阶段又面临扩展问题。还有就是需求的变更，可能又需要一种新的分库方式。
MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小。
关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题。
NOSQL的优势易扩展NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。
大数据量，高性能
NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。
灵活的数据模型
NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。
高可用NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如Cassandra，HBase模型，通过复制模型也能实现高可用。
总结NoSQL数据库的出现，弥补了关系数据（比如MySQL）在某些方面的不足，在某些方面能极大的节省开发成本和维护成本。
MySQL和NoSQL都有各自的特点和使用的应用场景，两者的紧密结合将会给web2.0的数据库发展带来新的思路。
在大数据时代，“多种架构支持多类应用”成为数据库行业应对大数据的基本思路，数据库行业出现互为补充的三大阵营，适用于事务处理应用的OldSQL、适用于数据分析应用的NewSQL和适用于互联网应用的NoSQL。但在一些复杂的应用场景中，单一数据库架构都不能完全满足应用场景对海量结构化和非结构化数据的存储管理、复杂分析、关联查询、实时性处理和控制建设成本等多方面的需要，因此不同架构数据库混合部署应用成为满足复杂应用的必然选择。不同架构数据库混合使用的模式可以概括为：OldSQL+NewSQL、OldSQL+NoSQL、NewSQL+NoSQL三种主要模式。下面通过三个案例对不同架构数据库的混合应用部署进行介绍。
OldSQL+NewSQL 在数据中心类应用中混合部署
采用OldSQL+NewSQL模式构建数据中心，在充分发挥OldSQL数据库的事务处理能力的同时，借助NewSQL在实时性、复杂分析、即席查询等方面的独特优势，以及面对海量数据时较强的扩展能力，满足数据中心对当前“热”数据事务型处理和海量历史“冷”数据分析两方面的需求。OldSQL+NewSQL模式在数据中心类应用中的互补作用体现在，OldSQL弥补了NewSQL不适合事务处理的不足，NewSQL弥补了OldSQL在海量数据存储能力和处理性能方面的缺陷。
商业银行数据中心采用OldSQL+NewSQL混合部署方式搭建，OldSQL数据库满足各业务系统数据的归档备份和事务型应用，NewSQL MPP数据库集群对即席查询、多维分析等应用提供高性能支持，并且通过MPP集群架构实现应对海量数据存储的扩展能力。
商业银行数据中心存储架构
与传统的OldSQL模式相比，商业银行数据中心采用OldSQL+NewSQL混合搭建模式，数据加载性能提升3倍以上，即席查询和统计分析性能提升6倍以上。NewSQL MPP的高可扩展性能够应对新的业务需求，可随着数据量的增长采用集群方式构建存储容量更大的数据中心。
OldSQL+NoSQL 在互联网大数据应用中混合部署
在互联网大数据应用中采用OldSQL+NoSQL混合模式，能够很好的解决互联网大数据应用对海量结构化和非结构化数据进行存储和快速处理的需求。在诸如大型电子商务平台、大型SNS平台等互联网大数据应用场景中，OldSQL在应用中负责高价值密度结构化数据的存储和事务型处理，NoSQL在应用中负责存储和处理海量非结构化的数据和低价值密度结构化数据。OldSQL+NoSQL模式在互联网大数据应用中的互补作用体现在，OldSQL弥补了NoSQL在ACID特性和复杂关联运算方面的不足，NoSQL弥补了OldSQL在海量数据存储和非结构化数据处理方面的缺陷。
数据魔方是淘宝网的一款数据产品，主要提供行业数据分析、店铺数据分析。淘宝数据产品在存储层采用OldSQL+NoSQL混合模式，由基于MySQL的分布式关系型数据库集群MyFOX和基于HBase的NoSQL存储集群Prom组成。由于OldSQL强大的语义和关系表达能力，在应用中仍然占据着重要地位，目前存储在MyFOX中的统计结果数据已经达到10TB，占据着数据魔方总数据量的95%以上。另一方面，NoSQL作为SQL的有益补充，解决了OldSQL数据库无法解决的全属性选择器等问题。
淘宝海量数据产品技术架构
基于OldSQL+NoSQL混合架构的特点，数据魔方目前已经能够提供压缩前80TB的数据存储空间，支持每天4000万的查询请求，平均响应时间在28毫秒，足以满足未来一段时间内的业务增长需求。
NewSQL+NoSQL 在行业大数据应用中混合部署
行业大数据与互联网大数据的区别在于行业大数据的价值密度更高，并且对结构化数据的实时处理、复杂的多表关联分析、即席查询、数据强一致性等都比互联网大数据有更高的要求。行业大数据应用场景主要是分析类应用，如：电信、金融、政务、能源等行业的决策辅助、预测预警、统计分析、经营分析等。
在行业大数据应用中采用NewSQL+NoSQL混合模式，充分利用NewSQL在结构化数据分析处理方面的优势，以及NoSQL在非结构数据处理方面的优势，实现NewSQL与NoSQL的功能互补，解决行业大数据应用对高价值结构化数据的实时处理、复杂的多表关联分析、即席查询、数据强一致性等要求，以及对海量非结构化数据存储和精确查询的要求。在应用中，NewSQL承担高价值密度结构化数据的存储和分析处理工作，NoSQL承担存储和处理海量非结构化数据和不需要关联分析、Ad-hoc查询较少的低价值密度结构化数据的工作。
当前电信运营商在集中化BI系统建设过程中面临着数据规模大、数据处理类型多等问题，并且需要应对大量的固定应用，以及占统计总数80%以上的突发性临时统计(ad-hoc)需求。在集中化BI系统的建设中采用NewSQL+NoSQL混搭的模式，充分利用NewSQL在复杂分析、即席查询等方面处理性能的优势，及NoSQL在非结构化数据处理和海量数据存储方面的优势，实现高效低成本。
集中化BI系统数据存储架构
集中化BI系统按照数据类型和处理方式的不同，将结构化数据和非结构化数据分别存储在不同的系统中：非结构化数据在Hadoop平台上存储与处理;结构化、不需要关联分析、Ad-hoc查询较少的数据保存在NoSQL数据库或Hadoop平台;结构化、需要关联分析或经常ad-hoc查询的数据，保存在NewSQL MPP数据库中，短期高价值数据放在高性能平台，中长期放在低成本产品中。
结语
当前信息化应用的多样性、复杂性，以及三种数据库架构各自所具有的优势和局限性，造成任何一种架构的数据库都不能完全满足应用需求，因此不同架构数据库混合使用，从而弥补其他架构的不足成为必然选择。根据应用场景采用不同架构数据库进行组合搭配，充分发挥每种架构数据库的特点和优势，并且与其他架构数据库形成互补，完全涵盖应用需求，保证数据资源的最优化利用，将成为未来一段时期内信息化应用主要采用的解决方式。
目前在国内市场上，OldSQL主要为Oracle、IBM等国外数据库厂商所垄断，达梦、金仓等国产厂商仍处于追赶状态;南大通用凭借国产新型数据库GBase 8a异军突起，与EMC的Greenplum和HP的Vertica跻身NewSQL市场三强;NoSQL方面用户则大多采用Hadoop开源方案。
当为大家描述我们的整体服务架构时，最常见的两个问题是：
为什么采用结构化方式将数据存储在SQL数据库中，而不使用NoSQL平台？
为什么自己维护数据中心，而不将Evernote托管到云服务提供商？
这两个问题都很有趣，我们先来探讨第一个。
对特定的应用而言，相比一个单一的SQL实例，一个现代的键值存储引擎具备显著的性能优势和可扩展性。
CREATE TABLE notebooks ( id int UNSIGNED NOT NULL PRIMARY KEY, guid binary(16) NOT NULL, user_id int UNSIGNED NOT NULL, name varchar(100) COLLATE utf8_bin NOT NULL, ... ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE notes ( id int UNSIGNED NOT NULL PRIMARY KEY, guid binary(16) NOT NULL, user_id int UNSIGNED NOT NULL, notebook_id int UNSIGNED NOT NULL, title varchar(255) NOT NULL, ... FOREIGN KEY (notebook_id) REFERENCES notebooks(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
如果你在Windows客户端上创建了一个名为“Cooking”的记事本，并立即在其中粘贴了一个名为“Quick Tomato Sauce”的食谱，客户端会立刻进行如下同步：
调用NoteStore.createNotebook() 请求服务器创建记事本，并返回以创建记事本的GUID。
通过指定记事本的GUID，调用NoteStore.createNote()在记事本中创建笔记。
每次API调用都通过SQL事物予以实现，可以让客户端完全信任服务器的任何提示。ACID兼容的数据库可以做到这些：
原子性（Atomicity）：如果API调用成功，那么所有的改动都会保存；如果API调用失败，所有的改动都不会提交。
一致性（Consistency）： 在API调用完成后，所有的账户都可用，并能保证内部状态的一致性。每篇笔记都与记事本相关联，以避免出现孤立项。数据库不允许删除关联有记事的记事本，这得感谢FOREIGN KEY约束。
持久性（Durability）：当服务器发送记事本已创建完毕的回执后，客户端会认为它的存在具有持久性，以便进行后续的操作。变更的持久性，可以让客户端知道在任何时刻对服务状态的影响都能保持一致性。
对我们的同步协议而言，持久性最为重要。如果客户端不能确定服务器端的变更具有持久性，那么协议将会变得复杂而低效。
“大数据”问题
得益于事务处理的数据库的ACID属性，同样使得数据集非常难以扩展，以超出单台服务器的范围。数据库集群和多主复制技术并不理想，键值存储为实现可扩展性提供了一条捷径。
所幸，Evernote暂时不需要考虑这个问题。即便是我们有近10亿的笔记，和近20亿的资源文件，这也并不能称得上是一个大数据集。通过按用户分区，它被划分成了2千万个独立的数据集。
我们尚未遇到所谓“大数据”引发的问题，倒是遇到了许多“中数据”的存储问题，这就是通过规整分区形成的分片存储架构。
也许以后……
我们对新的存储系统非常感兴趣，非常乐意应用在哪些对ACID要求不强，但确实需要横向扩展的新项目中。例如，我们的报告分析系统已经逐渐超出了MySQL平台的承受力，需要被更快、更先进的系统所取代。
我们现在对以Evernote用户元数据为基础的MySQL分片存储颇为满意，尽管这不会引起那些IT弄潮儿的兴趣。