第一部分 入门篇
本篇首先介绍MySQL的应用领域、基础架构和版本，然后介绍MySQL的基础知识，如查询的执行过程、权限机制、连接、存储引擎，最后阐述一些基础概念。
第1章 理解MySQL
本章将介绍MySQL的一些常识，以及目前MySQL的发展现状。
然后简要说明MySQL的基础架构、存储引擎、运行机制，以及工作中应该如何使用MySQL，为后面章节的学习做个铺垫。
1.1 MySQL介绍
1.1.1 应用领域和适用场景
MySQL是目前世界上最流行的开源关系数据库。
在国内，MySQL大量应用于互联网行业，比如，大家所熟知的百度、腾讯、阿里、京东、网易、新浪等都在使用MySQL。
搜索、社交、电商、游戏后端的核心存储往往都是MySQL，有的具有上千台甚至几千台MySQL数据库主机。
可以说，支撑互联网公司日常运转的主要数据库就是MySQL。
近年来，随着业务的发展， 互联网公司产生了许多成熟的架构和技术，这也促使MySQL不断变得更加成熟和稳健。
但MySQL的应用并未局限于互联网应用，许多软件开发商也把MySQL集成到了自己的产品中，这样一来，传统行业的大公司也都可以在企业内部大量使用MySQL存储企业数据了，包括政府信息系统，同样也在大量使用MySQL数据库。
MySQL的定位是通用的数据库，各种类型的应用一般都能利用到MySQL存取数据的优势。
业内生产实践也证明，MySQL更适合中小型数据库、OLTP业务，以目前的软硬件产品水平来看，如果单机数据超过几个TB将难以高效利用MySQL。
MySQL可以作为传统的关系型数据库产品使用，也可以当作一个key-value产品来使用，由于它具有优秀的灾难恢复功能，因此相对于目前市场上的一些key-value产品会更有优势。
我们所说的MySQL更适合OLTP业务、中小型数据库，并不是说MySQL仅限于此，数据的存储往往是一个架构问题，如果配合架构，MySQL也是可以存储海量数据的。
海量数据没有一个明确的标准，对于MySQL来说，我们可以简单地认为海量数据是指单个实例难以处理的几十亿以上的数据。
不过，MySQL对于海量数据的分析就不擅长了，你可能还需要其他产品来协助解决这方面的问题。
一般而言，中小型公司最佳的选择仍然是MySQL，毕竟在这类公司里，海量数据并不常见。
下面让我们来看看部分知名互联网公司的MySQL主机规模，一些公开资料显示如下。
Facebook 2008年有10000台服务器，其中包括1800台MySQL服务器，到2013年已经突破了20万台服务器，按40∶1计 算，MySQL服务器至少也有五千台了。
Twitter早在2011年就有2000~4000台服务器，绝大部分数据后端的持久化存储都是MySQL服务器。
对于国内的几大互联网公司，如阿里、百度、腾讯，依据公开的信息，它们均有千台以上MySQL服务器的规模。
这些大型互联网公司都注重使用MySQL，而且往往也在内部维护了一个MySQL的分支，同时它们也积极参与到MySQL社区，促使MySQL不断改进。
1.1.2 为什么那么多公司和机构选择使用MySQL
它们选择使用MySQL的主要原因有以下两点：低成本、高效能；处于起步阶段的团队、小公司需要一个开放的系统来适应发展的需要。
互联网公司，特别是处于起步阶段的公司，需要一个低成本的系统来构建服务，从而可以把更多的资金用于业务的扩张。
LAMP（其中的“M”指的就是MySQL）的组合已被广泛应用——目前世界上的大部分网站使用的都是LAMP（或者LNMP）组合。
由于它是免费的，LAMP自然就成了第一选择，一般而言，选择成熟可靠、使用人数广泛的产品，公司的技术风险也会大大降低。
同时MySQL是一个开放的系统，源代码开放，社区成熟活跃，在公司发展壮大的过程中，可以不断从外部获取成熟的思想和解决方案。
可以说MySQL已经构建了成熟的生态圈，使用它的人往往能得到许多益处，而且相对于目前市场上的其他产 品，MySQL也具备许多优势。
一些公司出于节省成本和扩展性的考虑，尝试把某些业务从商业数据库迁移到MySQL上，比如阿里，由于数据库集群的规模巨大，传统的基于小型机和高端的存储架构难以扩展，且支出成本庞大，所以把大部分业务逐步迁移到PC服务器的MySQL 集群上，成功地降低了成本。
1.1.3 MySQL的优势是什么，它解决了什么问题
MySQL是一个轻量级的通用关系型数据库，具有稳定、易安装、易使用、高性能等特点，可配合架构进行扩展。
它的安装包不大，百MB级别，安装简单方便，入门也很简单，而一些商业化的关系型数据库产品往往安装包庞大，且配置使用复杂， 需要开发人员或DBA花费几倍的时间去掌握产品的使用。
MySQL起初也有很多Bug，而且不太稳定，但经过十多年的发展，目前的MySQL（5.0/5.1）已经很稳定了。
新的5.5/5.6/5.7 也发布了GA版本，正在持续完善中，截至2015年年底，我们可以看到MySQL 5.1/5.5已经大量应用于生产环境了。
此外，MySQL也是一个高性能的产品，它不仅适用于中小型公司，还能稳定高效地处理大数据。
业内存在一种误解，认为MySQL的扩展性不好，若超过一定的数据量时，性能就会下降。
其实这更多的是一个架构问题，配合成熟的架构，比如在应用层切分数据，MySQL的扩展性就不再是什么问题了，而且很多数据是能够分片到各个MySQL节点的。
Facebook、Twitter、 Google等都在大量使用MySQL存储海量数据。
一些人倾向于用NoSQL产品来存储数据，其实，NoSQL产品，特别是一些key-value单机产品，相对于MySQL来说并没有什么优势。
MySQL同样可以把数据存储为key-value的形式，并且，NoSQL的产品还不是很稳定，一旦数据丢失就可能会导致很严重的损失，又往往因为数据模型简单，所以应用范围狭小。
MySQL成熟稳定且拥有丰富的数据类型，它的关系模型可以满足项目不断增加的商业需求。
1.2 MySQL的基础架构和版本
1.2.1 软件架构中数据库的定位
数据库一般位于整个软件架构的后端，而不直接服务于用户，数据的展示、应用逻辑的处理都是由其他层次的程序来实现的。
比较流行的一种软件架构的分类是“双层”、“三层”、“多层”架构。
客户端直接和数据库服务器通信，比如通过ODBC、 JDBC连接数据库，一般称为“双层架构”或“client-server”架构。
若客户端和数据库之间有一个中间服务器（如Web服务器，中间件），则由中间服务器负责转发请求给数据库服务器，这种模式称为“三层架构”。
在很多较大规模的Web应用中，在Web服务器和数据库服务器之间还可能存在一个应用服务器，这种结构称为“四层架构”。
本书探讨的MySQL是基于目前互联网最常见的架构，如，网站应用、移动互联网应用。它们一般是三层架构，这三层架构分别如下：
1）用户接口层，即各种终端，比如，运行在最终用户计算机上的浏览器。
2）业务逻辑和数据处理层，即应用程序服务器，比如，PHP、Java EE、ASP.NET、Ruby onRails等应用服务。
网站处理网络访问请求的过程可能是这样的：由Nginx接受用户请求，处理静态页面，并且将动态请求转发给后端的PHP服务，PHP服务处理完动态请求后，将结果返还给Nginx，Nginx再返还给用户。有时也称该层为中间件（middle ware）。
3）DBMS，即后端数据存储，如MySQL、PostgreSQL、Redis、Memcached等产品。
相应地，在软件系统架构设计中也存在一种分层设计的方法学。
我们熟知的三层架构（3-tierapplication）是一种应用广泛的分层设计，它把应用分解为表现层、业务逻辑层、数据访问层3个层次。
三层（多层）架构主要的好处是提供了一个灵活 的、可重用的模型，开发者可以通过简单地修改某一层的功能或增加某一层的功能来实现某种需求，而不需要修改整个应用程序。
表现层（UI），即直接和用户交互的界面。
业务逻辑层（BLL），即对业务逻辑进行处理，处理用户的请求，它将许多最终用户的业务逻辑集中到了应用服务器上。
数据访问层（DAL），直接操作数据库，即针对数据的增加、删除、修改、查找等操作。
传统行业的商业数据库往往还承载了许多业务逻辑的功能，这其中就会经常用到存储过程、触发器。
互联网世界的开源数据库虽然也有存储过程、触发器之类的特性，但绝大部分场合下并不会用到这些非核心的基本特性，开发者把数据库更多地看作一个存储数据的容器，并已将核心业务逻辑从数据库功能中分离了出来。
本书主要是讲述MySQL的使用，由于MySQL的优化与软件整体架构的其他组件的关系密切，所以对于Web服务器、缓存产品、队列等产品，也会做一些简单介绍。
作为一个合格的DBA，有必要了解各种应用服务的运行机制，以及是否需要对它们进行优化。
1.2.2 MySQL的基础架构
MySQL是一种关系数据库产品。
关系数据库，顾名思义，是建立在关系模型基础上的数据库。
现实世界中，实体与实体之间的各种联系一般都可以用关系模型来表示。
经过数十年的发展，关系数据库在理论和工业实践中都已经很成熟了。
数据库产品的架构一般可以分为应用层、逻辑层、物理层，对于MySQL，同样可以理解为如下的3个层次。
应用层。负责和客户端、用户进行交互，需要和不同的客户端和中间服务器进行交互，建立连接，记住连接的状态，响 应它们的请求，返回数据和控制信息（错误信息、状态码等）。
逻辑层。负责具体的查询处理、事务管理、存储管理、恢复管理，以及其他的附加功能。
查询处理器负责查询的解析、执行。当接收到客户端的查询时，数据库就会分配一个线程来处理它。
先由查询处理器（优化器）生成执行计划，然后交由计划执行器来执行，执行器有时需要访问更底层的事务管理器、存储管理器来操作数据。
事务管理器、存储管理器主要负责事务管理、并发控制、存储管理。
这其中，将由事务管理器来确保“ACID”特性，通过锁管理器来控制并发，由日志管理器来确保数据持久化，存储管理器一般还包括一个缓冲管理器，由它来确定磁盘和内存缓冲之间的数据传输。
物理层。实际物理磁盘（存储）上的数据库文件，比如，数据文件、日志文件等。
图1-1是MySQL官方文档的一个基础架构图，其中：
Connectors可以理解为各种客户端、应用服务；
Connection Pool可以理解为应用层，负责连接、验证等功能；
Management Services&Utilities、SQL Interface、Parser、Optimizer、Caches&Buffers、Pluggable Storage Engines可以理解为数据库的大脑——逻辑层；
最下方的Files&Logs可以理解为物理层。
1.2.3 MySQL的版本及特性
1.MySQL支持的平台
MySQL支持目前市面上的大部分平台，包括32位和64位平台，一般情况下程序运行在64位平台上比32位更快。
MySQL支 持的平台如下所示：Solaris，Linux，Windows，AIX ，Mac OS ，HPUX
2.MySQL许可协议
Oracle以双重授权（DualLicensed）的方式发布MySQL，它们是GPL和商业许可协议（CommercialLicense）。
如果你在一个遵循GPL的自由（开源）项目中使用MySQL，那么你可以遵循GPL协议使用MySQL，无论是否将其用作商用。
如果某些商业软件中结合了MySQL或修改了MySQL源码，但又不愿意按GPL协议公开软件源码，那么就必须和Oracle公司达成商业许可协议。
简而言之，如果你违反了GPL，则需要购买商业许可。
GPL授予用户以下权利：
以任何目的运行此程序的自由。
再发行复制件的自由。
改进程序，并公开发布改进内容的自由。
需要注意的是，GPL只限制了对外分发的软件，也就是说，如果该软件只在内部使用，无论开不开源都没有关系。
如何使用开源软件并不受GPL的约束，只有在你基于开源软件，修改开源软件的源码时才受GPL约束，
如果你的应用程序只是用到了 MySQL，无论是否商用，都不需要考虑开源。
3.MySQL版本
MySQL目前可分为4个版本：MySQL社区版、MySQL标准版、MySQL企业版、MySQL集群版。
（1）MySQL社区版
可免费下载使用的开源版本，遵循GPL协议，包括如下的这些特性：
可插拔的存储引擎架构
多存储引擎支持InnoDB、MyISAM、NDB（MySQL Cluster即采用NDB存储引擎）、Memory、Merge、Archive、CSV等
复制、分区、存储过程、触发器、视图
信息数据库（Information-Schema）
MySQL连接器 ·MySQL工作台（MySQLWorkbench）
目前已经发布了MySQL 5.0、MySQL 5.1、MySQL 5.5、MySQL 5.6、MySQL 5.7一共5个GA版本。
一般来说，后面的版本比前面的版本功能更强、扩展性更好。
以下3个版本是给商业用户使用的，商业客户可灵活选择多个版本，以满足特殊的商业和技术需求。
（2）MySQL标准版
和社区版差别不大，提供社区版所支持的各种特性。
（3）MySQL企业版
MySQL企业版提供7×24小时的技术支持服务，用户可直接联系MySQL专业支持工程师，获取关于MySQL应用程序开发、 部署和管理的全方位支持。
MySQL企业版提供了更全面的高级功能、管理工具和技术支持，例如：MySQL企业级备份可为数据库提供在线“热”备份， 从而降低数据丢失的风险。它支持完全、增量和部分备份，以及时间点恢复和备份压缩。
MySQL线程池提供了一个高效的线程处理模型，旨在降低客户端连接和语句执行线程的管理开销。
MySQL企业级安全性提供了一些立即可用的外部身份验证模块，可将MySQL轻松集成到现有的安全基础架构中。
其他特性还有MySQL企业级审计、MySQL企业级监视器（MySQL Enterprise Monitor）和MySQL查询分析器（MySQLQuery Analyzer）等。
MySQL的一些新特性出现在了企业版中，但并没有出现在社区版，这导致很多人对于MySQL产生了疑虑，但MySQL的生态已经建立成熟，官方版本和其他分支也都在稳定地发展改进中，一般的中小公司选择社区版本即可。
一些行业、领域要求更好的服务，更高的稳定性，或者有其他复杂的业务需求，对于它们企业版是一个很好的选择。
（4）MySQL集群（MySQL Cluster）版
Oracle收购MySQL之后，对MySQL Cluster做了大量改进，这也是Oracle力推的产品。
集群版是一种分布式、无共享（share- nothing）的架构，也就是说把数据分布在各个节点的内存里。
据官方宣称，集群版可比单机数据库提供更高的可用性，高达 99.999%。
它还有一些好处，比如自动分片、动态添加节点、支持跨IDC复制、减少维护成本等。
但这个产品比较复杂，国内也缺少精通MySQL Cluster的专家，如果一定要使用，建议做好充分的测试验证工作。
据说现在的MySQL Cluster版本已经允许存储部分数据到硬盘上，但由于主要数据需要存放在内存中，因此其部署成本会比较高。
另外，随着MySQL Cluster节点的增多，节点之间通信、同步的代价也越来越大，所以其扩展性也是有限的。
对于海量数据，MySQL Cluster可能不是很好的方案，从理论上来讲，仅仅把热点数据加载到内存是更经济的做法。
1.2.4 MySQL的开发周期
Oracle公司是一家成熟的商业公司，拥有一流的工程能力和执行力，自收购MySQL以来，就增加了相应的开发人员，并且提供了更成熟的开发模式，
目前MySQL的开发进度比收购之前高了很多，许多第三方的优化补丁也都在官方版本中得到了实现。
而之前MySQL的400多名开发人员分布在25个国家，70%的开发人员在家工作，导致了交流沟通不畅，产品开发进展缓慢。
目前MySQL的发展路线更清晰，开发周期大致分为4个阶段。
1）新特性开发。
2）发布实验室版本。 实验室版本可以提前预览到一些正在开发的特性，供用户试用，但是不保证这些特性会被整合到里程碑版本和GA版本。
3）发布里程碑版本（Development Milestone Releases）。
这个时候的版本称为RC（Release Candidate候选）版本，有充分的文档支持，在所有支持的平台上发布，可以让用户试用，以收集反馈。一般平均3~6个月发布一个DMR（里程碑版本）。
4）发布GA版本（GenerallyAvailabilityReleases）。 GA版本是建议用于生产系统的版本。一般18~24个月为一个周期。
1.3 查询执行过程概述
图1-2抽象化地描述了客户端和数据库交互的过程。
如图1-2所示，客户端（Clients）发布查询的流程如下：
首先连接MySQL（ConnectionHandling），然后发布查询，如果缓存 （QueryCache）中有结果集，则直接返回结果集。
如果结果没有被缓存，那么，MySQL解析查询（Parser）将通过优化器 （Optimizer）生成执行计划，
然后运行执行计划通过API（Pluggable Storage Engine API）从存储引擎获取数据，并返回给客户端。
什么是执行计划（查询计划）呢？执行计划就是一系列的操作步骤。
SQL是声明性语言，它只告诉数据库要查询什么，但并不告诉数据库如何去查。
数据库所要做的就是基于算法和统计信息计算出一条最佳的访问路径。
这个工作是由优化器来完成的。优化器会比较不同的执行计划，然后选择其中最优的一套。
1.4 MySQL权限
1.4.1 MySQL权限机制
MySQL权限控制包含如下两个阶段：
阶段1：服务器检查是否允许你连接。
阶段2：假定你能连接，服务器将检查你发出的每一个请求，查看你是否有足够的权限实施它。
例如，如果你从数据库表中选择（SELECT）行或从数据库中删除表，那么服务器要确定你是否对表有SELECT权限或对数据库有DROP权限。
MySQL是通过用户名、密码、IP（主机名）3个要素来验证用户的。
当你想要访问MySQL服务器时，MySQL客户端程序一 般会要求你指定如下参数：MySQL服务器的IP（主机名），端口，用户名，密码
以下是连接MySQL服务器的一个示例，你需要以实际的IP、端口、用户名、密码代替相应的内容。
shell> mysql -h host_ip_address -u user_name -pyour_password -P server_port
1.4.2 赋予权限和回收权限
一般在生产环境下，程序账号有增加、删除、查询、修改这4项功能即可。
如下命令用于赋予查询、插入、修改、删除权限，并进行密码设置。
mysql>grant select,insert,update,delete on db_name.* to user_name@'10.%' identified by 'password';
如下命令用于回收上面所赋予的权限。
mysql>revoke select,insert,update,delete on db_name.* from user_name@ '10.%';
1.5 长连接、短连接、连接池
当数据库服务器和客户端位于不同的主机时，就需要建立网络连接来进行通信。
客户端必须使用数据库连接来发送命令和接收应答、数据。
通过提供给客户端数据库的驱动指定连接字符串后，客户端就可以和数据库建立连接了。
可以查阅程序语言手册来获知通过何种方式使用短连接、长连接。
1.5.1 短连接
短连接是指程序和数据库通信时需要建立连接，执行操作后，连接关闭。
短连接简单来说就是每一次操作数据库，都要打开和关闭数据库连接，基本步骤是：连接→数据传输→关闭连接。
在慢速网络下使用短连接，连接的开销会很大；在生产繁忙的系统中，连接也可能会受到系统端口数的限制，如果要每秒建立几千个连接，那么连接断开后，端口不会被马上回收利用，必须经历一个“FIN”阶段的等待，直到可被回收利用为止，这样就可能会导致端口资源不够用。
在Linux上，可以通过调整/proc/sys/net/ipv4/ip_local_port_range来扩大端口的使用范围；调整/proc/sys/net/ipv4/tcp_fin_timeout来减少回收延期（如果想在应用服务器上调整这个参数，一定要慎重！）。
另外一个办法是主机使用多个IP地址。端口数的限制其实是基于同一个IP:PORT的，如果主机增加了IP，MySQL就可以监听多个IP地址，客户端也可以选择连接某个IP:PORT，这样就增加了端口资源。
1.5.2 长连接
长连接是指程序之间的连接在建立之后，就一直打开，被后续程序重用。
使用长连接的初衷是减少连接的开销，尽管 MySQL的连接比其他数据库要快得多。
以PHP程序为例，当收到一个永久连接的请求时，PHP将检查是否已经存在一个（前面已经开启了的）相同的永久连接。
如果存在，则将直接使用这个连接；如果不存在，则建立一个新的连接。
所谓“相同”的连接是指用相同的用户名和密码到相同 主机的连接。
从客户端的角度来说，使用长连接有一个好处，可以不用每次创建新连接，若客户端对MySQL服务器的连接请求很频繁，永久连接将更加高效。对于高并发业务，如果可能会碰到连接的冲击，推荐使用长连接或连接池。
从服务器的角度来看，情况则略有不同，它可以节省创建连接的开销，但维持连接也是需要内存的。
如果滥用长连接的话，可能会使用过多的MySQL服务器连接。现代的操作系统可以拥有几千个MySQL连接，但很有可能绝大部分都是睡眠 （sleep）状态的，这样的工作方式不够高效，而且连接占据内存，也会导致内存的浪费。
对于扩展性好的站点来说，其实大部分的访问并不需要连接数据库。如果用户需要频繁访问数据库，那么可能会在流量增大的时候产生性能问题，此时长短连接都是无法解决问题的，所以应该进行合理的设计和优化来避免性能问题。
如果客户端和MySQL数据库之间有连接池或Proxy代理，一般在客户端推荐使用短连接。
对于长连接的使用一定要慎重，不可滥用。如果没有每秒几百、上千的新连接请求，就不一定需要长连接，也无法从长连接中得到太多好处。
在Java语言中，由于有连接池，如果控制得当，则不会对数据库有较大的冲击，但PHP的长连接可能导致数据库的连接数超过限制，或者占用过多的内存。
对此，研发工程师、系统运维工程师、DBA需要保持沟通，确定合理的连接策略，千万不要不假思索就采用长连接。
1.5.3 连接池
由于一些数据库创建和销毁连接的开销很大，或者相对于所执行的具体数据操作，连接所耗的资源过多，此时就可能需要添加连接池来改进性能。
数据库连接池是一些网络代理服务或应用服务器实现的特性，如J2EE服务器，它实现了一个持久连接的“池”，允许其他程序、客户端来连接，这个连接池将被所有连接的客户端共享使用，连接池可以加速连接，也可以减少数据库连接，降低数据库服务器的负载。
1.5.4 持久连接和连接池的区别
长连接是一些驱动、驱动框架、ORM工具的特性，由驱动来保持连接句柄的打开，以便后续的数据库操作可以重用连接， 从而减少数据库的连接开销。
而连接池是应用服务器的组件，它可以通过参数来配置连接数、连接检测、连接的生命周期等。
如果连接池或长连接使用的连接数很多，有可能会超过数据库实例的限制，那么就需要留意连接相关的设置了，比如连接池的最小、最大连接数设置，以及php-fpm的进程个数等，否则程序将不能申请新的连接。
1.6 存储引擎简介
运行如下命令可查看表的引擎。
mysql> show table status like 'sys_accont' G
Name: sys_accont
Engine: InnoDB
其中，Engine栏位表示使用的是何种引擎。
MySQL不同于其他数据库，它的存储引擎是“可插拔”的，
意思就是MySQL Server的核心基础代码和存储引擎是分离的，你可以使用最适合应用的引擎，也就是说MySQL支持不同的表使用不同的引擎。
MySQL拥有20多个引擎，下面介绍几个常用的引擎。
1.6.1 InnoDB引擎
在MySQL 5.5及以后的版本中，InnoDB是MySQL的默认引擎，这些年来，InnoDB一直在持续改进，处理能力不断提高，其优秀的性能和可维护性使它成为生产中普遍推荐使用的引擎。
它的优点有：
灾难恢复性好。
支持全部4种级别的事务。默认的事务隔离级别是可重复读（Repeatable Read），它的事务支持是通过多版本并发控制 （MVCC）来提供的。
使用行级锁。
对于InnoDB引擎中的表，其数据的物理组织形式是簇表（Cluster Table），数据按主键来组织，也就是说主键索引和数据是在一起的，数据按主键的顺序物理分布。
数据表的另一种常见形式是非簇表，其索引是有序的，而数据是无序的。
实现了缓冲管理，不仅能缓冲索引也能缓冲数据，并且会自动创建散列索引以加快数据的获取。相比之下，MyISAM只是缓存了索引。
支持外键。
支持热备份。
注意：若无特殊说明，本书都是基于InnoDB引擎论述的。
1.6.2 MyISAM引擎
MyISAM是MySQL5.0/5.1的默认引擎，但MySQL官方的重心早已不在MyISAM引擎上了，近些年来，MyISAM一直没有大的改进，
由于它有许多缺陷，如不支持事务、灾难恢复性差，所以不建议在生产环境中使用。
以下是MyISAM的一些特性。
可以配合锁，实现操作系统下的复制备份、迁移。
使用表级锁，并发性差。
支持全文检索（MySQL InonoDB在5.6以后也支持全文检索）。
主机宕机后，MyISAM表易损坏，灾难恢复性不佳。
无事务支持。
只缓存索引，数据的缓存是利用操作系统缓冲区来实现的。可能引发过多的系统调用且效率不佳。
数据紧凑存储，因此可获得更小的索引和更快的全表扫描性能。
1.6.3 MEMORY存储引擎
MEMORY存储引擎提供“内存”表，也不支持事务、外键。
使用内存表（内存引擎）可以显著提高访问数据的速度，可用于缓存会频繁访问的、可以重构的数据、计算结果、统计值、中间结果。
MEMORY存储引擎不足之处如下：
使用的是表级锁，虽然内存访问快，但如果频繁地读写，表级锁可能会成为瓶颈所在。
只支持固定大小的行。VARCHAR类型的字段会存储为固定长度的CHAR类型，浪费空间。
不支持TEXT、BLOB字段。当有些查询需要使用到临时表（使用的也是MEMORY存储引擎）时如果表中有TEXT、BLOB 字段，那么会转化为基于磁盘的MyISAM表，严重降低性能。
由于内存资源成本昂贵，一般不建议设置过大的内存表，如果内存表满了，就会在MySQL错误日志里发现类似“The table ‘table_name’ is full”这样的错误，可通过清除数据或调整内存表参数来避免报错。
服务器重启后数据会丢失，复制维护时需要小心，具体请参考第12章。
1.6.4 ARCHIVE存储引擎
ARCHIVE存储引擎是被设计用来存储企业中的大量流水数据的存储引擎。
ARCHIVE引擎使用zlib无损数据压缩，让数据都保存在压缩的存档表中。
当数据被插入时，它们被压缩。
它只支持INSERT和SELECT，支持自增键及其上的索引，不支持其他索引。
它适合做日志记录、用户行为分析，不需要 UPDATE、DELETE和索引的数据。
1.6.5 选择合适的引擎
表1-1列举了MySQL部分引擎的特性：是否支持事务、锁级别、是否支持热备份。
其中，5.0版本、5.1版本默认的引擎是 MyISAM，5.5版本、5.6版本默认的引擎是InnoDB。
那么如何选择合适的引擎呢？以下是选择引擎时需要考虑的一些因素。
是否需要事务支持。
是否为高并发，InnoDB实现了行锁，这方面的表现大大优于MyISAM。
索引，不同存储引擎的索引实现不尽相同。
是否需要外键。
高效缓冲数据，InnoDB缓冲数据而MyISAM只缓冲了索引。
备份，是否需要支持热备份。
我们可以灵活地选择引擎，但是从维护的角度来说，维护统一的存储引擎会更方便，所以或者全部是MyISAM，或者全部是InnoDB引擎在现实生产中更常见，也更易于管理。
1.6.6 选择何种平台
业内普遍的做法是把MySQL部署在Linux系统下，所以如果不加特别说明，本书指的都是Linux下的MySQL部署、使用。
为什么互联网公司的生产环境一般使用Linux操作系统，而不考虑在Windows上部署安装MySQL呢？部分原因如下所示。
一般来说，部署在Unix/Linux环境下的软件程序往往有更高的运行效率。
因为这样一个事实：不同的操作系统在它们所采用 的进程和线程模型方面有着相当大的差异。
Unix/Linux编程模型对Apache和MySQL等软件进行优化的工作不仅开始得最早，进行得也最全面彻底，而Windows在这方面就远远落后了。
Oracle公司在收购MySQL后，对Windows版本做了一些增强，这样做更多的是出于商业的考虑，
Windows PC和Windows Server的市场占有率高，无论是作为开发环境或独立软件供应商的后台数据库，Windows下的MySQL都有其巨大的商业价值，
而且可以对MS SQL Server构成一定的威胁，但如果想要获得更好的性能、更高的吞吐量，仍然只有在Linux平台上才能实现。
1.7 MySQL复制架构
下面简要叙述下MySQL的各种复制模式，为了方便理解，假设有A、B、C三个MySQL实例，它们的复制模式有如下几 种。
主从模式 A→B
主主模式 A←→B
链式复制模式 A→B→C
环形复制模式 A→B→C→A
说明：箭头的意思是复制到。
以上4种模式为复制的主要模式，生产中一般建议部署为主从模式，这也是最稳健的一种方式。
为了方便切换，在一定程度上提高可用性，也可以选择主主模式。
需要注意的是，主主模式必须确保任何时刻都只有一个 数据库是主动（Active）状态，也就是说同一个时刻只能写入一个主（Master）节点，否则可能导致数据异常。
链式或环形复制在生产中很少用到，它们的主要缺点在于，随着节点的增加，整个复制系统的稳健性会下降。
后续运维章节（第12章）对复制会有更多的叙述。各种复制模式的基础都是主从模式，可以说，掌握了主从模式也就掌握 了其他各种模式。
1.8 一些基础概念
为了方便后续阅读，让大家对部分概念的理解保持一致，从而更好地理解书中的内容，这里有必要先对下面的这些概念进行阐述。
1.MySQL Server、MySQL实例、MySQL数据库
MySQL数据库指的是实际存在的物理操作系统文件的集合，也可以指逻辑数据的集合。
为了访问、处理数据，我们需要一 个数据库管理系统，也就是MySQL Server（也称为MySQL服务器）。
MySQL实例指的是MySQL进程及其所持有的内存结构，我们对数据的操作实际上是通过MySQL实例来访问物理数据库文件的。
在实际生产中，可以用一个IP:PORT组合来表示一个实例。
如“192.168.7.101:3307”这个MySQL实例表示在主机上起了一 个MySQL服务，它的服务端口是3307。
如果没有特别说明，本书中的实例一词就是指MySQL实例。
现实语境中，我们一般使用实例来描述对于数据库的操作，对于MySQL数据库、MySQL Server、MySQL实例并没有进行严格的区分，没有特别说明的话，大家可以将它们看作是同等的。
2.可扩展性
可扩展性也称为伸缩性，指的是系统不断增长其承载能力的能力。
它是能满足不断增长的负荷而自身的性能仍然尚可的这样一种能力。
3.可用性
可用性可以定义为系统保持正常运行时间的百分比，比如一个系统一共运行了100分钟，有99分钟是正常运行的，那么可用性就是99%。
4.单点故障
单点故障是指系统中的某个部分，一旦失败，将会导致整个系统无法工作。
为了消除单点故障，一般需要增加冗余组件或冗余系统。
比如服务器的电源冗余、网卡冗余、磁盘RAID阵列，冗余的服务器，备用的数据中心等。
如果要设计高可用的服务，单点故障是需要尽量避免的。
5.读写分离
由于数据库只能接受有限的读请求。对于读请求较多的应用，数据库可能会成为瓶颈，为了增加读的能力，提高扩展性， 因此引入了读写分离的技术。
比如，利用复制技术配置多个从库，以承担更多的读请求，或者应用程序直接访问读库，或者通过一个负载均衡软件分发读请求。
写入操作和一些读操作仍然访问主库。
由于MySQL的复制是异步的，所以需要留意复制延时对于读写分离的影响。
小结：
本章主要讲述了MySQL的基础架构、查询的执行过程，以及MySQL常见的部署方式。
MySQL支持许多存储引擎，大家有必要熟悉和了解最常使用的两个引擎：MyISAM、InnoDB。