Innodb存储引擎的数据（包括索引）存放在相同的文件中，这一点和MySQL默认存储引擎MyISAM的区别较大，后者分别存放于独立的文件。除此之外，Innodb的数据存放格式也比较独特，每个Innodb表都会将主键以聚簇索引的形式创建。所有的数据都是以主键来作为升序排列在物理磁盘上面，所以主键查询并且以主键排序的查询效率也会非常高。

由于主键是聚族索引的缘故，Innodb的基于主键的查询效率非常高。如果我们在创建一个Innodb存储引擎的表的时候并没有创建主键，那么Innodb会尝试在创建于我们表上面的其他索引，如果存在由单个not null属性列的唯一索引，Innodb则会选择该索引作为聚族索引。如果也没有任何单个not null属性列的唯一索引，Innodb会自动生成一个隐藏的内部列，该列会在每行数据上占用6个字节的存储长度。所以，实质上每个Innodb表都之少会有一个索引存在。

在Innodb上面除了聚族索引之外的索引被成为secondary index，每个secondary index上都会包含有聚族索引的索引键信息，方便通过其他索引查找数据的时候能够更快的定位数据位置所在。

Innodb存储引擎和MyISAM存储引擎最大区别主要有四点，第一点是缓存机制，第二点是事务支持，第三点是锁定实现，最后一点就是数据存储方式的差异。

一、Innodb缓存相关优化
1、innodb_buffer_pool_size的合理设置
Innodb存储引擎的缓存机制和MyISAM的最大区别就在于Innodb不仅仅缓存索引，同时还会缓存实际的数据。所以，完全相同的数据库，使用Innodb存储引擎可以使用更多的内存来缓存数据库相关的信息，当然前提是要有足够的物理内存。

innodb_buffer_pool_size参数用来设置Innodb最主要的Buffer(Innodb_Buffer_Pool)的大小，也就是缓存用户表及索引数据的最主要缓存空间，对Innodb整体性能影响也最大。无论是MySQL官方手册还是网络上很多人所分享的Innodb优化建议，都简单的建议将Innodb的Buffer Pool设置为整个系统物理内存的50%～80%之间。

2、如何分析MySQL内存使用
假设是一台单独给MySQL使用的主机，物理内存总大小为8G，MySQL最大连接数为500，同时还使用了MyISAM存储引擎，这时候我们的整体内存该如何分配呢？
内存分配为如下几大部分：
a）系统使用，假设预留800M；
b）线程独享，约2GB=500*(1MB+1MB+1MB+512KB+512KB)，组成大概如下：
sort_buffer_size：1MB
join_buffer_size：1MB
read_buffer_size：1MB
read_rnd_buffer_size：512KB
thread_statck：512KB
c）MyISAM Key Cache，假设大概为1.5GB；
d）Innodb Buffer Pool最大可用量：8GB-800MB-2GB-1.5GB=3.7GB；
假设这个时候我们还按照50%～80%的建议来设置，最小也是4GB，而通过上面的估算，最大可用值在3.7GB左右，那么很可能在系统负载很高当线程独享内存差不多出现极限情况的时候，系统很可能就会出现内存不足的问题了。而且上面还仅仅只是列出了一些使用内存较大的地方，如果进一步细化，很可能可用内存会更少。

1、Query Cache实现原理
MySQL的Query Cache实现原理实际上并不是特别的复杂，简单的来说就是将客户端请求的Query语句（当然仅限于SELECT类型的Query）通过一定的hash算法进行一个计算而得到一个hash值，存放在一个hash桶中。同时将该Query的结果集（Result Set）也存放在一个内存Cache中的。存放Query hash值的链表中的每一个hash值所在的节点中同时还存放了该Query所对应的Result Set的Cache所在的内存地址，以及该Query所涉及到的所有Table的标识等其他一些相关信息。

系统接受到任何一个SELECT类型的Query的时候，首先计算出其hash值，然后通过该hash值到Query Cache中去匹配，如果找到了完全相同的Query，则直接将之前所Cache的Result Set返回给客户端而完全不需要进行后面的任何步骤即可完成这次请求。

而后端的任何一个表的任何一条数据发生变化之后，也会通知Query Cache，需要将所有与该Table有关的Query的Cache全部失效，并释放出之前占用的内存地址，以便后面其他的Query能够使用。

对于基于性能的数据库Schema设计，我们并不能完全以规范化范式理论来作为唯一的指导。在设计过程中，应该从实际需求出发，以性能提升为根本目标来展开设计工作，很多时候为了尽可能提高性能，我们必须做反范式设计。

一、高效的模型设计

1、适度冗余-让Query尽两减少Join
数据库的规范化理论其实质是在概念上的单一化，虽然规范后的数据库中的表一般都较小，使表中相关列最少。这虽然可能在某些情况下增强了数据库的可维护性，但在系统要完成一些数据的查询检索时，可能要用复杂的Join才能实现，这势必会造成查询检索的性能低下。如果我们通过拆分Join，通过多次简单的查询来在应用中实现Join逻辑，那所带来的网络开销将会是非常巨大的。

2、大字段垂直分拆-summary表优化
大字段垂直拆分策略相对于前面介绍的适度冗余策略在做法上可以说差不多是完全相反的做法。适度冗余策略是将别的表中的字段拿过来在自己身上也存一份数据，而大字段垂直拆分简单来说就是将自己身上的字段拆分出去放在另外（单独）的表里面。

三、DISTINCT的实现与优化
DISTINCT实际上和GROUP BY的操作非常相似，只不过是在GROUP BY之后的每组中只取出一条记录而已。所以，DISTINCT的实现和GROUP BY的实现也基本差不多，没有太大的区别。

同样可以通过松散索引扫描或者是紧凑索引扫描来实现，当然，在无法仅仅使用索引即能完成DISTINCT的时候，MySQL只能通过临时表来完成。

但是，和GROUP BY有一点差别的是，DISTINCT并不需要进行排序。也就是说，在仅仅只是DISTINCT操作的Query如果无法仅仅利用索引完成操作的时候，MySQL会利用临时表来做一次数据的“缓存”，但是不会对临时表中的数据进行filesort操作。

1、通过松散索引扫描完成DISTINCT
执行计划中的Extra信息为“Using index for group-by”，这代表什么意思？为什么我没有进行GROUP BY操作的时候，执行计划中会告诉我这里通过索引进行了GROUP BY呢？其实这就是于DISTINCT的实现原理相关的，在实现DISTINCT的过程中，同样也是需要分组的，然后再从每组数据中取出一条返回给客户端。而这里的Extra信息就告诉我们，MySQL利用松散索引扫描就完成了整个操作。

二、GROUP BY的实现与优化
由于GROUP BY实际上也同样需要进行排序操作，而且与ORDER BY相比，GROUP BY主要只是多了排序之后的分组操作。当然，如果在分组的时候还使用了其他的一些聚合函数，那么还需要一些聚合函数的计算。所以，在GROUP BY的实现过程中，与ORDER BY一样也可以利用到索引。

在MySQL中，GROUP BY的实现同样有多种（三种）方式

1、使用松散（Loose）索引扫描实现GROUP BY
何谓松散索引扫描实现GROUP BY呢？实际上就是当MySQL完全利用索引扫描来实现GROUP BY的时候，并不需要扫描所有满足条件的索引键即可完成操作得出结果。

在执行计划的Extra信息中有信息显示“Using index for group-by”，实际上这就是告诉我们，MySQL Query Optimizer通过使用松散索引扫描来实现了我们所需要的GROUP BY操作。

要利用到松散索引扫描实现 GROUP BY，需要至少满足以下几个条件：
◆ GROUP BY条件字段必须在同一个索引中最前面的连续位置；
◆ 在使用GROUP BY的同时，只能使用MAX和MIN这两个聚合函数；
◆ 如果引用到了该索引中GROUP BY条件之外的字段条件的时候，必须以常量形式存在；

除了常规的Join语句之外，还有一类Query语句也是使用比较频繁的，那就是ORDER BY，GROUP BY以及DISTINCT这三类查询。考虑到这三类查询都涉及到数据的排序等操作，所以我将他们放在了一起，下面就针对这三类Query语句做基本的分析。

一、ORDER BY的实现与优化

1、在MySQL中，ORDER BY的实现有如下两种类型：
◆ 一种是通过有序索引而直接取得有序的数据，这样不用进行任何排序操作即可得到满足客户端要求的有序数据返回给客户端；
◆ 另外一种则需要通过MySQL的排序算法将存储引擎中返回的数据进行排序然后再将排序后的数据返回给客户端。

2、第一种情况：
这种利用索引实现数据排序的方法是MySQL中实现结果集排序的最佳做法，可以完全避免因为排序计算所带来的资源消耗。所以，在我们优化Query语句中的ORDER BY的时候，尽可能利用已有的索引来避免实际的排序计算，可以很大幅度的提升ORDER BY操作的性能。

一、Join的实现原理

在MySQL中，只有一种Join算法，就是大名鼎鼎的Nested Loop Join，他没有其他很多数据库所提供的Hash Join，也没有Sort Merge Join。顾名思义，Nested Loop Join实际上就是通过驱动表的结果集作为循环基础数据，然后一条一条的通过该结果集中的数据作为过滤条件到下一个表中查询数据，然后合并结果。如果还有第三个参与Join，则再通过前两个表的Join结果集作为循环基础数据，再一次通过循环查询条件到第三个表中查询数据，如此往复。

MySQL 8.0支持Hash Join了。

二、Join语句的优化

1、尽可能减少Join语句中的Nested Loop的循环总次数
如何减少Nested Loop的循环总次数？最有效的办法只有一个，那就是让驱动表的结果集尽可能的小，这也正是优化基本原则之一“永远用小结果集驱动大的结果集”。

2、优先优化Nested Loop的内层循环
不仅仅是在数据库的Join中应该做的，实际上在我们优化程序语言的时候也有类似的优化原则。内层循环是循环中执行次数最多的，每次循环节约很小的资源，在整个循环中就能节约很大的资源。