1)在经常需要搜索的列上，可以加快搜索的速度。
2)在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构。
3)在经常用于连接两张表的列上，这些列主要是一些外键，可以加快连接的速度。
4)在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的。
5)在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间。
6)在经常使用在WHERE子句中的列上面创建索引，加快条件的判断速度。
1)表记录太少。
2)经常增删改的表。
3)数据重复且分布平均的表字段，因此应该只为最经常查询和经常排序的数据列建立索引(如果某个数据列包含许多重复的内容，为它建立索引就没有太大的实际效果)。
4)where条件查询中用不到的字段
1)为查询缓存优化你的查询
大多数的 Mysql 服务器都开启了查询缓存。这是提高性最有效的方法之一，而且
这是被 Mysql 的数据库引擎处理的。当有很多相同的查询被执行了多次的时候，
这些查询结果会被放到一个缓存中，这样，后续的相同的查询就不用操作表而直接
访问缓存结果了。 这里最主要的问题是，对于程序员来说，这个事情是很容易被忽
略的。因为，我们某些查询语句会让 Mysql 不使用缓存。请看下面的示例:
1:SELECT username FROM user WHERE signup_date >= CURDATE()
2:SELECT username FROM user WHERE signup_date >= '2014-06-24'
上面两条 SQL 语句的差别就是 CURDATE() ，Mysql 的查询缓存对这个函数不起作用。
所以，像 NOW() 和 RAND() 或是其它的诸如此类的 SQL 函数都不会开启查询缓存，因为
这些函数的返回是会不定的易变的。所以，你所需要的就是用一个变量来代替 Mysql 的函数，从而开启缓存。
2)EXPLAIN 你的 SELECT 查询
使用 EXPLAIN 关键字可以让你知道 Mysql 是如何处理你的 SQL 语句的。这可以帮你分析你的查询语句或是表结构的性能瓶颈。 EXPLAIN 的查询结果还会告诉你你的索引主键被如何利用的，你的数据表是如何被搜索和排序的……等等，等等
3)当只要一行数据时使用 LIMIT 1
加上 LIMIT 1 可以增加性能。Mysql 数据库引擎会在找到一条数据后停止搜索，而不是继续往后查少下一条符合记录的数据。
4)为搜索字段建索引
索引并不一定就是给主键或是唯一的字段。如果在你的表中，有某个字段你总要会经常用来做搜索，那么，请为其建立索引吧。
5)在 Join 表的时候使用相当类型的列，并将其索引
如果你的应用程序有很多 JOIN 查询，你应该确认两个表中 Join 的字段是被建过索引的。这样，Mysql 内部会启动为你优化 Join 的 SQL 语句的机制。
而且，这些被用来 Join 的字段，应该是相同的类型的。例如:如果你要把 DECIMAL 字段和一个 INT 字段 Join 在一起，Mysql 就无法使用它们的索引。对于那些 STRING 类型，还需要有相同的字符集才行。(两个表的字符集有可能不一样)
6)千万不要 ORDER BY RAND()
想打乱返回的数据行?随机挑一个数据?真不知道谁发明了这种用法，但很多新手很喜欢这样用。但你确不了解这样做有多么可怕的性能问题。
如果你真的想把返回的数据行打乱了，你有 N 种方法可以达到这个目的。这样使用只让你的数据库的性能呈指数级的下降。这里的问题是:Mysql 会不得不去执行 RAND()函数(很耗 CPU 时间)，而且这是为了每一行记录去记行，然后再对其排序。就算是你用了 Limit 1 也无济于事(因为要排序)
7)避免 SELECT *
从数据库里读出越多的数据，那么查询就会变得越慢。并且，如果你的数据库服务器和 Web 服务器是两台独立的服务器的话，这还会增加网络传输的负载。
8)永远为每张表设置一个 ID
我们应该为数据库里的每张表都设置一个 ID 做为其主键，而且最好的是一个 INT 型的(推荐使用 UNSIGNED)，并设置上自动增加的 AUTO_INCREMENT 标志。
就算是你 users 表有一个主键叫 “email”的字段，你也别让它成为主键。使用 VARCHAR 类型来当主键会使用得性能下降。另外，在你的程序中，你应该使用表的 ID 来构造你的数据结构。 而且，在 Mysql 数据引擎下，还有一些操作需要使用主键，在这些情况下，主键的性能和设置变得非常重要，比如，集群，分区…… 在这里，只有一个情况是例外，那就是“关联表”的“外键”，也就是说，这个表的主键，通过若干个别的表的主键构成。我们把这个情况叫做“外键”。比如:有一个“学生表”有学生的 ID，有一个“课程表”有课程 ID，那么，“成绩表”就是“关联表”了，其关联了学生表和课程表，在成绩表中，学生 ID 和课程 ID 叫“外键”其共同组成主键。
9)使用 ENUM 而不是 VARCHAR
ENUM 类型是非常快和紧凑的。实际上，其保存的是 TINYINT，但表面上显示为字符串。通常用来表示一些有限大小的选项列表。比如"性别"、"国家"、"民族"、"状态"等，这些字段的取值是有限且固定的，这个时候，我们就应该使用 ENUM 而不是 VARCHAR。
10)尽可能的使用 NOT NULL
除非你有一个很特别的原因去使用 NULL 值，你应该总是让你的字段保持 NOT NULL。这看起来好像有点争议，请往下看。 首先，问问你自己“Empty”和“NULL”有多大的区别(如果是 INT，那就是 0 和 NULL)?如果你觉得它们之间没有什么区别，那么你就不要使用 NULL。(你知道吗?在 Oracle 里，NULL 和 Empty 的字符串是一样的！) 不要以为 NULL 不需要空间，其需要额外的空间，并且，在你进行比较的时候，你的程序会更复杂。 当然，这里并不是说你就不能使用 NULL 了，现实情况是很复杂的，依然会有些情况下，你需要使用 NULL 值。
11)固定长度的表会更快
如果表中的所有字段都是“固定长度”的，整个表会被认为是 “static” 或 “fixed-length”。 例如，表中没有如下类型的字段: VARCHAR，TEXT，BLOB。只要你包括了其中一个这些字段，那么这个表就不是“固定长度静态表”了，这样，Mysql 引擎会用另一种方法来处理。 固定长度的表会提高性能，因为 Mysql 搜寻得会更快一些，因为这些固定的长度是很容易计算下一个数据的偏移量的，所以读取的自然也会很快。而如果字段不是定长的，那么，每一次要找下一条的话，需要程序找到主键。 并且，固定长度的表也更容易被缓存和重建。不过，唯一的副作用是，固定长度的字段会浪费一些空间，因为定长的字段无论你用不用，他都是要分配那么多的空间。
12)垂直分割
“垂直分割”是一种把数据库中的表按列变成几张表的方法，这样可以降低表的复杂度和字段的数目，从而达到优化的目的。(以前做项目，见过一张表有 100 多个字段，很恐怖)
拆分大的 DELETE 或 INSERT 语句
如果你需要在一个在线的网站上去执行一个大的 DELETE 或 INSERT 查询，你需要非常小心，要避免你的操作让你的整个网站停止相应。因为这两个操作是会锁表的，表一锁住了，别的操作都进不来了。
Apache 会有很多的子进程或线程。所以，其工作起来相当有效率，而我们的服务器也不希望有太多的子进程，线程和数据库链接，这是极大的占服务器资源的事情，尤其是内存。 如果你把你的表锁上一段时间，比如 30 秒钟，那么对于一个有很高访问量的站点来说，这 30 秒所积累的访问进程/线程，数据库链接，打开的文件数，可能不仅仅会让你的 Web 服务 Crash，还可能会让你的整台服务器马上掛了。
13)越小的列会越快
对于大多数的数据库引擎来说，硬盘操作可能是最重大的瓶颈。所以，把你的数据变得紧凑会对这种情况非常有帮助，因为这减少了对硬盘的访问。 参看 Mysql 的文档 Storage Requirements 查看所有的数据类型。 如果一个表只会有几列罢了(比如说字典表，配置表)，那么，我们就没有理由使用 INT 来做主键，使用 MEDIUMINT, SMALLINT 或是更小的 TINYINT 会更经济一些。如果你不需要记录时间，使用 DATE 要比 DATETIME 好得多。
14)选择正确的存储引擎
在 Mysql 中有两个存储引擎 MyISAM 和 InnoDB，每个引擎都有利有弊。酷壳以前文章《Mysql: InnoDB 还是 MyISAM?》讨论和这个事情。 MyISAM 适合于一些需要大量查询的应用，但其对于有大量写操作并不是很好。甚至你只是需要 update 一个字段，整个表都会被锁起来，而别的进程，就算是读进程都无法操作直到读操作完成。另外，MyISAM 对于 SELECT COUNT(*) 这类的计算是超快无比的。 InnoDB 的趋势会是一个非常复杂的存储引擎，对于一些小的应用，它会比 MyISAM 还慢。它支持“行锁” ，于是在写操作比较多的时候，会更优秀。并且，他还支持更多的高级应用，比如:事务、外键。
14)小心“永久链接”
“永久链接”的目的是用来减少重新创建 Mysql 链接的次数。当一个链接被创建了，它会永远处在连接的状态，就算是数据库操作已经结束了。而且，自从我们的 Apache 开始重用它的子进程后——也就是说，下一次的 HTTP 请求会重用 Apache 的子进程，并重用相同的 Mysql 链接。
1)如果条件中有 or，即使其中有条件带索引也不会使用(这也是为什么尽量少用 or 的原因 )
注意:要想使用 or，又想让索引生效，只能将 or 条件中的每个列都加上索引**
2)对于多列索引，不是使用的第一部分，则不会使用索引
3)like 查询是以 % 开头
4)隐式类型转换，会导致索引失效，例如age字段类型是int，我们where age = “1”，这样就会触发隐式类型转换。
5)如果 Mysql 估计使用全表扫描要比使用索引快，则不使用索引
6)对索引字段进行函数运算。
7)对索引列运算(如，+、-、*、/)，索引失效。
8)索引字段上使用(!= 或者 < >，not in)时，会导致索引失效。
9)索引字段上使用is null， is not null，可能导致索引失效。
10)相join的两个表的字符编码不同，不能命中索引，会导致笛卡尔积的循环计算
11)联合索引，查询时的条件列不是联合索引中的第一个列，索引失效。
1)存储结构
MyISAM:每个 MyISAM 在磁盘上存储成三个文件。第一个文件的名字以表的名字开始，扩展名指出文件类型。
.frm(文件存储表定义)
MYD(MYData，存储数据文件)
MYI(MYIndex，存储索引文件)
InnoDB:所有的表都保存在同一个数据文件中(也可能是多个文件，或者是独立的表空间文件，这个具体要看独立表空间是否默认开启，如果默认开始(5.7 已经默认)，那便是多个文件)，InnoDB 表的大小只受限于操作系统文件的大小，一般为 2GB。
2)存储空间
MyISAM:可被压缩，存储空间较小。支持三种不同的存储格式:静态表(默认，但是注意数据末尾不能有空格，会被去掉)、动态表、压缩表。
InnoDB:需要更多的内存和存储，它会在主内存中建立其专用的缓冲池用于高速缓冲数据和索引。
3)可移植性、备份及恢复
MyISAM:数据是以文件的形式存储，所以在跨平台的数据转移中会很方便。在备份和恢复时可单独针对某个表进行操作。
InnoDB:免费的方案可以是拷贝数据文件、备份 binlog，或者用 Mysqldump，在数据量达到几十 G 的时候就相对痛苦了。
4)事务支持
MyISAM:强调的是性能，每次查询具有原子性，其执行速度比 InnoDB 类型更快，但是不提供事务支持。
InnoDB:提供事务支持事务，外键等高级数据库功能。 具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。
5)联合索引
MyISAM:可以和其他字段一起建立联合索引。引擎的自动增长列必须是索引，如果是组合索引，自动增长可以不是第一列，他可以根据前面几列进行排序后递增。
InnoDB:InnoDB 中必须包含只有该字段的索引。引擎的自动增长列必须是索引，如果是组合索引，自动增长也必须是组合索引的第一列。
6)表锁差异
MyISAM:只支持表级锁，用户在操作 MyISAM 表时，select，update，delete，insert 语句都会给表自动加锁，如果加锁以后的表满足 insert 并发的情况下，可以在表的尾部插入新的数据。
InnoDB:支持事务和行级锁，是 InnoDB 的最大特色。行锁大幅度提高了多用户并发操作的新能。但是 InnoDB 的行锁，只是在 Where 的主键是有效的，非主键的 WHERE 都会锁全表的。
7)全文索引
MyISAM:支持 FULLTEXT 类型的全文索引
InnoDB:不支持 FULLTEXT 类型的全文索引，但是 innodb 可以使用 Sphinx 插件支持全文索引，并且效果更好。
8)表主键
MyISAM:允许没有任何索引和主键的表存在，索引都是保存行的地址。
InnoDB:如果没有设定主键或者非空唯一索引，就会自动生成一个 6 字节的主键(用户不可见)，数据是主索引的一部分，附加索引保存的是主索引的值。
9)表的具体行数
MyISAM:保存有表的总行数，如果 select count() from table;会直接取出出该值。
InnoDB:没有保存表的总行数，如果使用 select count() from table；就会遍历整个表，消耗相当大，但是在加了 where 条件后，MyISAM 和 InnoDB 处理的方式都一样。
10)CURD 操作
MyISAM:如果执行大量的 SELECT，MyISAM 是更好的选择。
InnoDB:如果你的数据执行大量的 INSERT 或 UPDATE，出于性能方面的考虑，应该使用 InnoDB 表。DELETE 从性能上 InnoDB 更优，但 DELETE FROM table 时，InnoDB 不会重新建立表，而是一行一行的删除，在 innodb 上如果要清空保存有大量数据的表，最好使用 truncate table 这个命令。
11)外键
MyISAM:不支持
InnoDB:支持
简略版:
① InnoDB 支持事务，MyISAM 不支持
② InnoDB 支持外键，而 MyISAM 不支持。
③ InnoDB 是聚集索引，使用 B+Tree 作为索引结构，数据文件是和 索引绑在一起的 ，必须要有主键，通过主键索引效率很高。但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。
MyISAM 是非聚集索引，也是使用 B+Tree 作为索引结构，索引和数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。
也就是说:InnoDB 的 B+ 树主键索引的叶子节点就是数据文件，辅助索引的叶子节点是主键的值；而 MyISAM 的 B+ 树主键索引和辅助索引的叶子节点都是数据文件的地址指针。
④ InnoDB 支持表、行(默认)级锁，而 MyISAM 支持表级锁
⑤ InnoDB 表必须有主键(用户没有指定的话会自己找或生产一个主键)，而 Myisam 可以没有
事务的特性及原理
说到 Mysql 事务，首先要提他的四大特性(ACID):
原子性(Atomicity)、一致性(Consistent)、隔离性(Isolation)以及持久性(Durable)。正是这些特性，才保证了数据库事务的安全性。
1、原子性(Atomicity)
原子性是指一个事务是一个不可分割的工作单位，其中的操作要么都做，要么都不做；如果事务中一个 SQL 语句执行失败，则已执行的语句也必须回滚，数据库退回到事务前的状态。
实现原理:
实现原子性的关键，是当事务回滚时能够撤销所有已经成功执行的 SQL 语句。In-noDB 实现回滚，靠的是 undo log:当事务对数据库进行修改时，InnoDB 会生成对应的 undo log。如果事务执行失败或调用了 rollback，导致事务需要回滚，便可以利用 undo log 中的信息将数据回滚到修改之前的样子。
介绍一下 Mysql 的事务日志:Mysql 的日志有很多种，如二进制日志、错误日志、查询日志、慢查询日志等，此外 InnoDB 存储引擎还提供了两种事务日志:redo log(重做日志)和 undo log(回滚日志)。其中 redo log 用于保证事务持久性；undo log 则是事务原子性和隔离性实现的基础。
undo log 属于逻辑日志，它记录的是 SQL 执行相关的信息。当发生回滚时，InnoDB 会根据 undo log 的内容做与之前相反的工作:对于每个 insert，回滚时会执行 delete；对于每个 delete，回滚时会执行 insert；对于每个 update，回滚时会执行一个相反的 update，把数据改回去。
以 update 操作为例:当事务执行 update 时，其生成的 undo log 中会包含被修改行的主键(以便知道修改了哪些行)、修改了哪些列、这些列在修改前后的值等信息，回滚时便可以使用这些信息将数据还原到 update 之前的状态。
2、持久性(Durable)
持久性是指事务一旦提交，它对数据库的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。
实现原理:
redo log 和 undo log 都属于 InnoDB 的事务日志，下面先聊一下 redo log 存在的背景。
InnoDB 作为 Mysql 的存储引擎，数据是存放在磁盘中的，但如果每次读写数据都需要磁盘 IO，效率会很低。为此，InnoDB 提供了缓存(Buffer Pool)，Buffer Pool 中包含了磁盘中部分数据页的映射，作为访问数据库的缓冲:当从数据库读取数据时，会首先从 Buffer Pool 中读取，如果 Buffer Pool 中没有，则从磁盘读取后放入 Buffer Pool；当向数据库写入数据时，会首先写入 Buffer Pool，Buffer Pool 中修改的数据会定期刷新到磁盘中(这一过程称为刷脏)。
Buffer Pool 的使用大大提高了读写数据的效率，但是也带了新的问题:如果 Mysql 宕机，而此时 Buffer Pool 中修改的数据还没有刷新到磁盘，就会导致数据的丢失，事务的持久性无法保证。
于是，redo log 被引入来解决这个问题:当数据修改时，除了修改 Buffer Pool 中的数据，还会在 redo log 记录这次操作；当事务提交时，会调用 fsync 接口对 redo log 进行刷盘。如果 Mysql 宕机，重启时可以读取 redo log 中的数据，对数据库进行恢复。redo log 采用的是 WAL(Write-ahead logging，预写式日志)，所有修改先写入日志，再更新到 Buffer Pool，保证了数据不会因 Mysql 宕机而丢失，从而满足了持久性要求。
既然 redo log 也需要在事务提交时将日志写入磁盘，为什么它比直接将 Buffer Pool 中修改的数据写入磁盘(即刷脏)要快呢?主要有以下两方面的原因:
(1)刷脏是随机 IO，因为每次修改的数据位置随机，但写 redo log 是追加操作，属于顺序 IO。
(2)刷脏是以数据页(Page)为单位的，Mysql 默认页大小是 16KB，一个 Page 上一个小修改都要整页写入；而 redo log 中只包含真正需要写入的部分，无效 IO 大大减少。
Redolog 和 Binlog
我们知道，在 Mysql 中还存在 binlog(二进制日志)也可以记录写操作并用于数据的恢复，但二者是有着根本的不同的:
(1)作用不同:redo log 是用于 crash recovery 的，保证 Mysql 宕机也不会影响持久性；binlog 是用于 point-in-time recovery 的，保证服务器可以基于时间点恢复数据，此外 binlog 还用于主从复制。
(2)层次不同:redo log 是 InnoDB 存储引擎实现的，而 binlog 是 Mysql 的服务器层(可以参考文章前面对 Mysql 逻辑架构的介绍)实现的，同时支持 InnoDB 和其他存储引擎。
(3)内容不同:redo log 是物理日志，内容基于磁盘的 Page；binlog 的内容是二进制的，根据 binlog_format 参数的不同，可能基于 SQL 语句、基于数据本身或者二者的混合。
(4)写入时机不同:binlog 在事务提交时写入，redo log 的写入时机相对多元。
前面曾提到:当事务提交时会调用 fsync 对 redo log 进行刷盘；这是默认情况下的策略，修改 innodb_flush_log_at_trx_commit 参数可以改变该策略，但事务的持久性将无法保证。
innodb_flush_log_at_trx_commit 参数
当设置为 0，该模式速度最快，但不太安全，Mysqld 进程的崩溃会导致上一秒钟所有事务数据的丢失。
当设置为 1，该模式是最安全的，但也是最慢的一种方式。在 Mysqld 服务崩溃或者服务器主机 crash 的情况下，binary log 只有可能丢失最多一个语句或者一个事务。
当设置为 2，该模式速度较快，也比 0 安全，只有在操作系统崩溃或者系统断电的情况下，上一秒钟所有事务数据才可能丢失。
除了事务提交时，还有其他刷盘时机:如 master thread 每秒刷盘一次 redo log 等，这样的好处是不一定要等到 commit 时刷盘，commit 速度大大加快。
3、一致性(Consistent)
一致性是指事务执行结束后，数据库的完整性约束没有被破坏，事务执行的前后都是合法的数据状态。数据库的完整性约束包括但不限于:实体完整性(如行的主键存在且唯一)、列完整性(如字段的类型、大小、长度要符合要求)、外键约束、用户自定义完整性(如转账前后，两个账户余额的和应该不变)。
实现
可以说，一致性是事务追求的最终目标:前面提到的原子性、持久性和隔离性，都是为了保证数据库状态的一致性。此外，除了数据库层面的保障，一致性的实现也需要应用层面进行保障。
实现一致性的措施包括:
1.保证原子性、持久性和隔离性，如果这些特性无法保证，事务的一致性也无法保证
2.数据库本身提供保障，例如不允许向整形列插入字符串值、字符串长度不能超过列的限制等
3.应用层面进行保障，例如如果转账操作只扣除转账者的余额，而没有增加接收者的余额，无论数据库实现的多么完美，也无法保证状态的一致
4、隔离性(Isolation)
与原子性、持久性侧重于研究事务本身不同，隔离性研究的是不同事务之间的相互影响。隔离性是指，事务内部的操作与其他事务是隔离的，并发执行的各个事务之间不能互相干扰。
严格的隔离性，对应了事务隔离级别中的 Serializable (可串行化)，但实际应用中出于性能方面的考虑很少会使用可串行化。隔离性追求的是并发情形下事务之间互不干扰。SQL 标准定义了 4 类隔离级别:Read Uncommitted(读取未提交内容)、Read Committed(读取提交内容)、Repeatable Read(可重读)、Serializable(可串行化)。
简单起见，我们仅考虑最简单的读操作和写操作(暂时不考虑带锁读等特殊操作)，那么隔离性的探讨，主要可以分为两个方面:(一个事务)写操作对(另一个事务)写操作的影响:锁机制保证隔离性 (一个事务)写操作对(另一个事务)读操作的影响:MVCC 保证隔离性。
Mysql 中有哪几种锁?表级锁:开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。
行级锁:开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
页面锁:开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。
表级锁:开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。
行级锁:开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
页面锁:开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。
SQL 标准定义的四个隔离级别为:
1、read uncommited : 读到未提交数据
2、read committed: 脏读， 不可重复读
3、repeatable read: 可重读
4、serializable : 串行事物
InnoDB:支持事务处理，支持外键，支持崩溃修复能力和并发控制。如果需要对事务的完整性要求比较高(比如银行)，要求实现并发控制(比如售票)，那选择InnoDB有很大的优势。如果需要频繁的更新、删除操作的数据库，也可以选择InnoDB，因为支持事务的提交(commit)和回滚(rollback)。
MyISAM:插入数据快，空间和内存使用比较低。如果表主要是用于插入新记录和读出记录，那么选择MyISAM能实现处理高效率。如果应用的完整性、并发性要求比 较低，也可以使用。
MEMORY:所有的数据都在内存中，数据的处理速度快，但是安全性不高。如果需要很快的读写速度，对数据的安全性要求较低，可以选择MEMOEY。它对表的大小有要求，不能建立太大的表。所以，这类数据库只使用在相对较小的数据库表。
MyISAM特点
不支持行锁(MyISAM只有表锁)，读取时对需要读到的所有表加锁，写入时则对表加排他锁；
不支持事务
不支持外键
不支持崩溃后的安全恢复
在表有读取查询的同时，支持往表中插入新纪录
支持BLOB和TEXT的前500个字符索引，支持全文索引
支持延迟更新索引，极大地提升了写入性能
对于不会进行修改的表，支持 压缩表 ，极大地减少了磁盘空间的占用
InnoDB特点
支持行锁，采用MVCC来支持高并发，有可能死锁
支持事务
支持外键
支持崩溃后的安全恢复
不支持全文索引
MyISAM和InnoDB两者的应用场景:
- MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。如果应用中需要执行大量的SELECT查询，那么MyISAM是更好的选择。
- InnoDB用于事务处理应用程序，具有众多特性，包括ACID事务支持。如果应用中需要执行大量的INSERT或UPDATE操作，则应该使用InnoDB，这样可以提高多用户并发操作的性能。
但是实际场景中，针对具体问题需要具体分析，一般而言可以遵循以下几个问题:
- 数据库是否有外键?
- 是否需要事务支持?
- 是否需要全文索引?
- 数据库经常使用什么样的查询模式?在写多读少的应用中还是Innodb插入性能更稳定，在并发情况下也能基本，如果是对读取速度要求比较快的应用还是选MyISAM。
- 数据库的数据有多大? 大尺寸倾向于innodb，因为事务日志，故障恢复。
由于 hash 索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引。
可能很多人又有疑问了，既然 Hash 索引的效率要比 B-Tree 高很多，为什么大家不都用 Hash 索引而还要使用 B-Tree 索引呢?
任何事物都是有两面性的，Hash 索引也一样，虽然 Hash 索引效率高，但是 Hash 索引本身由于其特殊性也带来了很多限制和弊端，主要有以下这些。
(1)Hash 索引仅仅能满足"=","IN"和"<=>"查询，不能使用范围查询。
由于 Hash 索引比较的是进行 Hash 运算之后的 Hash 值，所以它只能用于等值的过滤，不能用于基于范围的过滤，因为经过相应的 Hash 算法处理之后的 Hash 值的大小关系，并不能保证和Hash运算前完全一样。
(2)Hash 索引无法被用来避免数据的排序操作。
由于 Hash 索引中存放的是经过 Hash 计算之后的 Hash 值，而且Hash值的大小关系并不一定和 Hash 运算前的键值完全一样，所以数据库无法利用索引的数据来避免任何排序运算；
(3)Hash 索引不能利用部分索引键查询。
对于组合索引，Hash 索引在计算 Hash 值的时候是组合索引键合并后再一起计算 Hash 值，而不是单独计算 Hash 值，所以通过组合索引的前面一个或几个索引键进行查询的时候，Hash 索引也无法被利用。
(4)Hash 索引在任何时候都不能避免表扫描。
前面已经知道，Hash 索引是将索引键通过 Hash 运算之后，将 Hash运算结果的 Hash 值和所对应的行指针信息存放于一个 Hash 表中，由于不同索引键存在相同 Hash 值，所以即使取满足某个 Hash 键值的数据的记录条数，也无法从 Hash 索引中直接完成查询，还是要通过访问表中的实际数据进行相应的比较，并得到相应的结果。
(5)Hash 索引遇到大量Hash值相等的情况后性能并不一定就会比B-Tree索引高。
对于选择性比较低的索引键，如果创建 Hash 索引，那么将会存在大量记录指针信息存于同一个 Hash 值相关联。这样要定位某一条记录时就会非常麻烦，会浪费多次表数据的访问，而造成整体性能低下。
优点:
A.提高数据查询的效率,降低数据库的IO成本
B.通过索引对数据进行排序,降低数据排序的成本,降低CPU的消耗
缺点:
A.索引本身也是一张表,该表保存了主键与索引字段,并指向实体表的记录,所以索引列也要占用空间
B.虽然索引大大提高了查询的速度,同时反向影响增删改操作的效率,因为表中数据变化之后,会导致索引内容不准,所以也需要更新索引表信息,增加了数据库的工作量
C.随着业务的不断变化,之前建立的索引可能不能满足查询需求,需要消耗我们的时间去更新索引
单值索引: 一个索引只包含单列,一个表可以有多个单列索引
唯一索引: 索引列的值必须唯一,但是允许有空值
复合索引: 一个索引可以同时包含多列
① 查看表的读取顺序
② 查看数据库读取操作的操作类型
③ 查看哪些索引有可能被用到
④ 查看哪些索引真正被用到
⑤ 查看表之间的引用
⑥ 查看表中有多少行记录被优化器查询
用法:explain + sql语句;
select_type :表示查询中每个select子句的类型
type :表示Mysql在表中找到所需行的方式，又称“访问类型”
possible_keys :指出Mysql能使用哪个索引在表中找到行，查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用。
key :显示Mysql在查询中实际使用的索引，若没有使用索引，显示为NULL。
key_len :表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度
ref :表示上述表的连接匹配条件，即哪些列或常量被用于查找索引列上的值
Extra :包含不适合在其他列中显示但十分重要的额外信息
表级锁:开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。
行级锁:开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。
页面锁:开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般
排查死锁的步骤:
查看死锁日志show engine innodb status;
找出死锁Sql
分析sql加锁情况
模拟死锁案发
分析死锁日志
分析死锁结果
① char。char存储定长数据很方便，char字段上的索引效率级高，比如定义char(10)，那么不论你存储的数据是否达到了10个字节，都要占去10个字节的空间。
② varchar。存储变长数据，但存储效率没有char高。如果一个字段可能的值是不固定长度的，我们只知道它不可能超过10个字符，把它定义为 varchar(10)是最合算的。varchar类型的实际长度是它的值的实际长度+1。为什么“+1”呢?这一个字节用于保存实际使用了多大的长度。
从空间上考虑，用varchar合适；从效率上考虑，用char合适，关键是根据实际情况找到权衡点。
优化SQL语句，优化数据库字段，加缓存，分区表，读写分离以及垂直拆分，解耦模块，水平切分等。
高并发大多的瓶颈在后台，在存储Mysql的正常的优化方案如下:
(1)代码中sql语句优化
(2)数据库字段优化，索引优化
(3)加缓存，redis/memcache等
(4)主从，读写分离
(5)分区表
(6)垂直拆分，解耦模块
(7)水平切分
方案分析:
1、方法1个方法2是最简单，也是提升效率最快的方式。因为每条语句都命中了索引，是最高效的。但是如果是为了使sql达到最优而去建索引，那么索引就泛滥了，对于千万级以上的表来说，维护索引的成本大大增加，反而增加了数据库的内存的开销。
2、数据库字段的优化。曾经发现一高级程序员在表字段的设计上，一个日期类型，被设计为varchar类型，不规范的同时，无法对写入数据校验，做索引的效率也有差别
3、缓存适合读多写少更新频度相对较低的业务场景，否则缓存异议不大，命中率不高。缓存通常来说主要为了提高接口处理速度，降低并发带来的db压力以及由此产生的其他问题。
4、分区不是分表，结果还是一张表，只不过把存放的数据文件分成了多个小块。在表数据非常大的情况下，可以解决无法一次载入内存，以及大表数据维护等问题。
5、垂直拆分将表按列拆成多表，常见于将主表的扩展数据独立开，文本数据独立开，降低磁盘io的压力。
6、水平拆，水平拆分的主要目的是提升单表并发读写能力(压力分散到各个分表中)和磁盘IO性能(一个非常大的.MYD文件分摊到各个小表的.MYD文件中)。如果没有千万级以上数据，为什么要拆，仅对单表做做优化也是可以的；再如果没有太大的并发量，分区表也一般能够满足。所以，一般情况下，水平拆分是最后的选择，在设计时还是需要一步一步走。
错误日志 :记录出错信息，也记录一些警告信息或者正确的信息。
查询日志 :记录所有对数据库请求的信息，不论这些请求是否得到了正确的执行。
慢查询日志:设置一个阈值，将运行时间超过该值的所有SQL语句都记录到慢查询的日志文件中。
二进制日志:记录对数据库执行更改的所有操作。
中继日志
事务日志
重做日志(redo log)
回滚日志(undo log)
二进制日志(binlog)
错误日志(errorlog)
慢查询日志(slow query log)
一般查询日志(general log)
中继日志(relay log)
InnoDB中，事务日志通过重做(redo)日志文件和InnoDB存储引擎的日志缓冲来实现。当开始一个事务时,会记录该事务的一个LSN(日志序列号)，当事务执行时，会往InnoDB的日志缓冲里插入事务日志，当事务提交时，必须将innoDB存储引擎的日志缓冲写入磁盘。也就是在写数据前，需要先写日志。这种方式称为预写日志方式。
InnoDB通过预写日志的方式来保证事务的完整性。这意味着磁盘上存储的数据页和内存缓冲池中的数据页是不同步的，对于内存缓冲池中页的修改，先是写入重做日志文件，然后再写入磁盘，因此是一种异步的方式。
事务有时还需要撤销，这就需要undo。对数据库进行修改时，数据库不但会产生redo，而且会产生一定量的undo，如果你执行的事务或语句由于某种原因失败了，或者如果你用一条rollback语句请求回滚，就可以利用这些undo信息将数据回滚到修改之前的样子。
数据库的乐观锁和悲观锁是什么?乐观并发控制(乐观锁)和悲观并发控制(悲观锁)是并发控制主要采用的技术手段。
悲观锁:假定会发生并发冲突，屏蔽掉一切可能违反数据完整性的操作，在读取的时候就对数据进行加锁， 在该用户读取数据的期间，其他任何用户都不能来修改该数据，但是其他用户是可以读取该数据的， 只有当自己读取完毕才释放锁。
乐观锁:假定不会发生并发冲突，只在提交的时候检查是否发生并发冲突。
事务和锁的存在都是为了更好地解决并发访问造成的数据不一致性问题。乐观锁和悲观锁都是为了解决并发控制问题，乐观锁可以看做一种在最后提交时检测冲突的手段，而悲观锁是一种避免冲突的手段。
(1)乐观锁:假设不会发生并发冲突，只在提交的时候检查是否发生并发冲突。可以使用版本号机制和CAS算法实现。
版本号机制:一般在数据表中加一个数据版本号version字段，表示数据被修改的次数，当数据被修改时version值加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若当前读取到的version值与第一次读取到的数据库version值相等时才更新，否则重试更新操作，直到更新成功。
例子:
假设数据库中帐户信息表中有一个 version 字段，当前值为 1 ；而当前帐户余额字段( balance )为 100 。
操作员A此时将其读出( version=1 )，并从其帐户余额中扣除 50(100-50 =50)；
在操作员A操作的过程中，操作员B也读入此用户信息( version=1 )，并从其帐户余额中扣除20 (100-20=80 )。
操作员A完成了修改工作，将数据版本号加一( version=2 )，连同帐户扣除后余额( balance=50 )，提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 ；
操作员B完成了操作，也将版本号加一( version=2 )试图向数据库提交数据( balance=80 )，但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 2 ，数据库记录当前版本也为 2 ，不满足 “ 当前最后更新的version与操作员第一次的版本号相等 “ 的乐观锁策略，因此，操作员B的提交被驳回。
CAS机制:即compare and swap(比较与交换)，无锁编程，在不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，因此也叫非阻塞同步。
CAS过程是这样:它包含3个参数:内存值V(要更新变量的值)，旧的预期值A，要修改的值B。当且仅当预期值A的值等于内存值V时，才会将内存值V修改为B，否则不会执行任何操作(V值和A值不同，则说明已经有其他线程做了更新)。一般情况下是一个自旋操作，即不断的重试。
例子:
假设 t1，t2 线程同时更新同一变量56的值。
因为t1和t2线程都同时去访问同一变量56，所以他们会把主内存的值完全拷贝一份到自己的工作内存空间，所以t1和t2线程的预期值都为56。
假设t1在与t2线程竞争中线程t1能去更新变量的值，而其他线程都失败。(失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次发起尝试)。t1线程去更新变量值改为57，然后写到内存中。此时对于t2来说，内存值变为了57，与预期值56不一致，就操作失败了(想改的值不再是原来的值)。
乐观锁的优势和劣势 :
优势:如果数据库记录始终处于悲观锁加锁状态，可以想见，如果面对几百上千个并发，那么要不断的加锁减锁，而且用户等待的时间会非常的长， 乐观锁机制避免了长事务中的数据库加锁解锁开销，大大提升了大并发量下的系统整体性能表现。所以如果系统的并发非常大的话，悲观锁定会带来非常大的性能问题，所以建议就要选择乐观锁定的方法， 而如果并发量不大，完全可以使用悲观锁定的方法。乐观锁也适合于读比较多的场景。
劣势: 乐观锁只能在提交数据时才发现业务事务将要失败，如果系统的冲突非常的多，而且一旦冲突就要因为重新计算提交而造成较大的代价的话，乐观锁也会带来很大的问题。而且乐观锁也无法解决脏读的问题 。
(2)悲观锁:假定会发生并发冲突，在读取的时候就对数据进行加锁， 在该用户读取数据的期间，其他任何用户都不能来修改该数据，但是其他用户是可以读取该数据的， 只有当自己读取完毕才释放锁。
在数据库中可以使用Repeatable Read的隔离级别(可重复读)来实现悲观锁，它完全满足悲观锁的要求(加锁)。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。
悲观锁的优势和劣势 :
优势: 能避免冲突的发生 。
劣势: 开销较大，而且加锁时间较长，对于并发的访问性支持不好。
两种锁的使用场景:
如果冲突很少，或者冲突的后果不会很严重，那么通常情况下应该选择乐观锁，因为它能得到更好的并发性；
如果冲突太多或者冲突的结果对于用户来说痛苦的，那么就需要使用悲观策略，它能避免冲突的发生。
一般乐观锁适用于写比较少的情况下(多读场景)，即冲突真的很少发生的时候；悲观锁适用于多写的情况，多写的情况一般会经常产生冲突。
存储过程是一个预编译的SQL语句，优点是允许模块化的设计，就是说只需创建一次，以后在该程序中就可以调用多次。如果某次操作需要执行多次SQL，使用存储过程比单纯SQL语句执行要快。
存储过程与触发器的区别?存储过程:
存储过程是一组SQL命令集合，经过预编译存放在系统中。也就是将常用的或很复杂的工作，预先用SQL语句写好并用一个指定的名称存储起来，以后只要调用它就可以完成相应的功能。
触发器:
触发器(Trigger)是个特殊的存储过程，它不是由用户主动发起调用的，而是当发生某一事件而触发，由系统自动调用。比如当用户在数据库中新增一条商品记录，我们希望同时在库存中做登记，而库存登记不是人工去录入，是在发生新增商品记录这一事件时发生，由系统自动完成录入，这个工作就可以交给一个特殊的存储过程来完成，这个存储过程就是触发器。
联合索引:指对表上的多个列做索引。只有在查询条件中使用了创建索引时的第一个字段，索引才会被使用。使用组合索引时遵循最左前缀原则。
主键索引: 数据列不允许重复，不允许为NULL，一个表只能有一个主键。
唯一索引: 数据列不允许重复，允许为NULL值，一个表允许多个列创建唯一索引。
普通索引: 基本的索引类型，没有唯一性的限制，允许为NULL值。
全文索引:是目前搜索引擎使用的一种关键技术，对文本的内容进行分词、搜索。
覆盖索引:查询列要被所建的索引覆盖，不必读取数据行
组合索引:多列值组成一个索引，用于组合搜索，效率大于索引合并
联合索引是指对表上的多个列做索引。在Mysql建立联合索引时会遵循最左前缀匹配的原则，即最左优先，在检索数据时从联合索引的最左边开始匹配。
最左前缀匹配原则:
最左优先，在检索数据时从联合索引的最左边开始匹配。
对列col1、列col2和列col3建一个联合索引:KEY test_col1_col2_col3 on test(col1,col2,col3);
联合索引 test_col1_col2_col3 相当于建立了(col1)、(col1,col2)、(col,col2,col3)三个索引。
(1)SELECT * FROM test WHERE col1="1" AND clo2="2" AND clo4=|"4"
上面这个查询语句执行时会依照最左前缀匹配原则，检索时会使用索引(col1,col2)进行数据匹配。
(2)索引的字段可以是任意顺序的，如:
SELECT * FROM test WHERE col1=“1” AND clo2=“2”
SELECT * FROM test WHERE col2=“2” AND clo1=“1”
这两个查询语句都会用到索引(col1,col2)，Mysql创建联合索引的规则是首先会对联合合索引的最左边的，也就是第一个字段col1的数据进行排序，在第一个字段的排序基础上，然后再对后面第二个字段col2进行排序。其实就相当于实现了类似 order by col1 col2这样一种排序规则。
有人会疑惑第二个查询语句不符合最左前缀匹配:首先可以肯定是两个查询语句都保函索引(col1,col2)中的col1、col2两个字段，只是顺序不一样，查询条件一样，最后所查询的结果肯定是一样的。既然结果是一样的，到底以何种顺序的查询方式最好呢?此时我们可以借助Mysql查询优化器explain，explain会纠正sql语句该以什么样的顺序执行效率最高，最后才生成真正的执行计划。
(3)如果只查询col2:SELECT * FROM test WHERE col2=2;
第一个col字段是绝对有序的，而第二字段就是无序的了。所以通常情况下，直接使用第二个字段col2进行条件判断是用不到索引的。当然是col2字段的索引数据也是有序的情况下才能使用咯，什么时候才是有序的呢?在col1字段是等值匹配的情况下，cid才是有序的。这也就是Mysql索引规则中要求复合索引要想使用第二个索引，必须先使用第一个索引的原因。(而且第一个索引必须是等值匹配)。
聚集索引和非聚集索引区别?一个表中只能拥有一个聚集索引，而非聚集索引一个表可以存在多个。
聚集索引，索引中键值的逻辑顺序决定了表中相应行的物理顺序；非聚集索引，索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同。
索引是通过二叉树的数据结构来描述的，我们可以这么理解聚簇索引:索引的叶节点就是数据节点。而非聚簇索引的叶节点仍然是索引节点，只不过有一个指针指向对应的数据块。
聚集索引:物理存储按照索引排序；非聚集索引:物理存储不按照索引排序；
drop直接删掉表。
truncate删除表中数据，再插入时自增长id又从1开始。
delete删除表中数据，可以加where字句。
(1)truncate和delete只删除数据，而drop则删除整个表(结构和数据)。
(2)delete语句执行删除的过程是每次从表中删除一行，并且同时将该行的删除操作作为事务记录在日志中保存以便进行进行回滚操作。truncate table则一次性地从表中删除所有的数据并不把单独的删除操作记录记入日志保存，删除行是不能恢复的。并且在删除的过程中不会激活与表有关的删除触发器。执行速度快。
(3)执行速度:drop> truncate >delete
(4)delete语句是dml，这个操作会放到rollback segement中，事务提交之后才生效。如果有相应的trigger(触发器)，执行的时候将被触发；
truncate、drop是ddl，操作立即生效，原数据不放到rollback segment中，不能回滚，操作不触发trigger。
(5)当表被truncate后，这个表和索引所占用的空间会恢复到初始大小， delete操作不会减少表或索引所占用的空间。
(5)应用范围:truncate只能对table；delete可以是table和view
如果直接删除一个表drop，对数据量很大的表，这个过程会占用比较长的时间，如果先truncat后drop table:1、可以降低操作失败的风险；2、可以降低数据字典锁占用的时间，降低系统开销。
drop、delete与truncate分别在什么场景之下使用?不再需要一张表的时候，用drop
想删除部分数据行时候，用delete，并且带上where子句
保留表而删除所有数据的时候用truncate
表格的每一行都由主键唯一标识,一个表只有一个主键。
主键也是候选键。按照惯例，候选键可以被指定为主键，并且可以用于任何外键引用。
超键:在关系中能唯一标识元组的属性集称为关系模式的超键。一个属性可以为作为一个超键，多个属性组合在一起也可以作为一个超键。超键包含候选键和主键。
候选键:是最小超键，即没有冗余元素的超键。
主键:数据库表中对存储数据对象予以唯一和完整标识的数据列或属性的组合。一个数据列只能有一个主键，且主键的取值不能缺失，即不能为空值(Null)。
外键:在一个表中存在的另一个表的主键称此表的外键。
如果我们定义了主键(PRIMARY KEY)，那么InnoDB会选择主键作为聚集索引、如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引、如果也没有这样的唯一索引，则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增，这个ROWID不像ORACLE的ROWID那样可引用，是隐含的)。
使用自增列(INT/BIGINT类型)做主键，这时候写入顺序是自增的，和B+数叶子节点分裂顺序一致；
该表不指定自增列做主键，同时也没有可以被选为主键的唯一索引(上面的条件)，这时候InnoDB会选择内置的ROWID作为主键，写入顺序和ROWID增长顺序一致；
除此以外，如果一个InnoDB表又没有显示主键，又有可以被选择为主键的唯一索引，但该唯一索引可能不是递增关系时(例如字符串、UUID、多字段联合唯一索引的情况)，该表的存取效率就会比较差。
视图(View)是一个命名的虚表，它由一个查询来定义，可以当作表使用。
视图有什么用(应用场景):
1、当一个查询你需要频频的作为子查询使用时，视图可以简化代码，直接调用而不是每次都去重复写这个东西。
2、系统的数据库管理员，需要给他人提供一张表的某两列数据，而不希望他可以看到其他任何数据，这时可以建一个只有这两列数据的视图，然后把视图公布给他。
创建视图sql语句:
CREATE VIEW view_name AS
SELECT column_name(s)
FROM table_name
WHERE condition
视图与表的区别:
1、视图是已经编译好的sql语句，而表不是。
2、视图没有实际的物理记录，而表有。
3、表是内容，视图是窗口。
4、表只用物理空间而视图不占用物理空间，视图只是逻辑概念的存在，表可以及时对它进行修改，但视图只能由创建的语句来修改。
5、视图是查看数据表的一种方法，可以查询数据表中某些字段构成的数据，只是一些SQL语句的集合。从安全的角度说，视图可以不给用户接触数据表，从而不知道表结构。
6、表属于全局模式中的表，是实表；视图属于局部模式的表，是虚表。
7、视图的建立和删除只影响视图本身，不影响对应的基本表。
8、不能对视图进行update或者insert into操作。
非关系型数据库的优势:
性能:NOSQL是基于键值对的，可以想象成表中的主键和值的对应关系，而且不需要经过SQL层的解析，所以性能非常高。
可扩展性:同样也是因为基于键值对，数据之间没有耦合性，所以非常容易水平扩展。
关系型数据库的优势:
复杂查询:可以用SQL语句方便的在一个表以及多个表之间做非常复杂的数据查询。
事务支持:使得对于安全性能很高的数据访问要求得以实现。
其他:
1.对于这两类数据库，对方的优势就是自己的弱势，反之亦然。
2.NOSQL数据库慢慢开始具备SQL数据库的一些复杂查询功能，比如MongoDB。
3.对于事务的支持也可以用一些系统级的原子操作来实现例如乐观锁之类的方法来曲线救国，比如Redis set nx。
什么是 内连接、外连接、交叉连接、笛卡尔积等?内连接: 只连接匹配的行
左外连接: 包含左边表的全部行(不管右边的表中是否存在与它们匹配的行)，以及右边表中全部匹配的行
右外连接: 包含右边表的全部行(不管左边的表中是否存在与它们匹配的行)，以及左边表中全部匹配的行
例如1:
SELECT a.,b. FROM luntan LEFT JOIN usertable as b ON a.username=b.username
例如2:
SELECT a.,b. FROM city as a FULL OUTER JOIN user as b ON a.username=b.username
全外连接: 包含左、右两个表的全部行，不管另外一边的表中是否存在与它们匹配的行。
交叉连接: 生成笛卡尔积－它不使用任何匹配或者选取条件，而是直接将一个数据源中的每个行与另一个数据源的每个行都一一匹配
例如:
SELECT type,pub_name FROM titles CROSS JOIN publishers ORDER BY type
复制代码
1.以A，B两张表为例
A left join B
选出A的所有记录，B表中没有的以null 代替
right join 同理
2.inner join
A,B的所有记录都选出，没有的记录以null代替
3.cross join (笛卡尔积)
A中的每一条记录和B中的每一条记录生成一条记录
例如A中有4条，B中有4条，cross join 就有16条记录
％对应于0个或更多字符，_只是LIKE语句中的一个字符。
count(*)、count(1)、count(column)的区别count():对行的数目进行计数，包含NULL
count(column) :对特定的列的值具有的行进行计数，不包含NULL值。
count(1)这个用法和count()的结果是一样的，包含null。
性能问题:
任何情况下SELECT COUNT() FROM tablename是最优选择;
尽量减少SELECT COUNT() FROM tablename WHERE COL = ‘value’ 这种查询;
杜绝SELECT COUNT(COL) FROM tablename WHERE COL2 = ‘value’ 的出现。
如果表没有主键，那么count(1)比count()快。
如果有主键，那么count(主键,联合主键)比count()快。
如果表只有一个字段，count()最快。
count(1)跟count(主键)一样，只扫描主键；count()跟count(非主键)一样，扫描整个表。明显前者更快一些。
如果是utf8字符集的话，需要升级至utf8_mb4方可支持。
你是如何监控你们的数据库的?你们的慢日志都是怎么查询的?监控的工具有很多，例如zabbix，lepus，我这里用的是lepus。
slow_query_log :慢查询开启状态。
slow_query_log_file :慢查询日志存放的位置(这个目录需要Mysql的运行帐号的可写权限，一般设置为Mysql的数据存放目录)。
long_query_time :查询超过多少秒才记录。
开启慢日志查询:set global slow_query_log='ON';
那么开启了慢查询日志后，什么样的SQL才会记录到慢查询日志里面呢?
这个是由参数long_query_time控制，默认情况下long_query_time的值为10秒，可以使用命令修改，也可以在my.cnf参数里面修改。运行时间大于long_query_time(非大于等于)，才会记录到慢查询日志里。
InnoDB存储引擎的四大特性?插入缓冲、二次写、自适应哈希索引、预读
(1)插入缓冲:
一般情况下，主键是行唯一的标识符。通常应用程序中行记录的插入顺序是按照主键递增的顺序进行插入的。因此，插入聚集索引一般是顺序的，不需要磁盘的随机读取。因为，对于此类情况下的插入，速度还是非常快的。
如果索引是非聚集的且不唯一，在进行插入操作时，数据的存放对于非聚集索引叶子节点的插入不是顺序的，这时需要离散地访问非聚集索引页，由于随机读取的存在而导致了插入操作性能下降。(这是因为B+树的特性决定了非聚集索引插入的离散性。)
插入缓冲对于非聚集索引的插入和更新操作，不是每一次直接插入索引页中，而是先判断插入的非聚集索引页是否在缓存池中。如果在，则直接插入；如果不在，则先放入一个插入缓冲区中，好似欺骗数据库这个非聚集的索引已经插入到叶子结点了，然后再以一定的频率执行插入缓冲和非聚集索引页子节点的合并操作，这时通常能将多个插入合并到一个操作中(因为在一个索引页中)，这就大大提高了对非聚集索引执行插入和修改操作的性能。
插入缓冲的使用要满足两个条件:
索引是辅助索引
索引不是唯一的
(辅助索引不能是唯一的，因为在把它插入到插入缓冲时，我们并不去查找索引页的情况。如果去查找肯定又会出现离散读的情况，插入缓冲就失去了意义。)
存在的问题:
在写密集的情况下，插入缓冲会过多的占用缓冲池内存，默认情况下最大可以占用1/2的缓冲池内存。
(2)二次写
当数据库宕机时，可能发生数据库正在写一个页面，而这个页只写了一部分的情况，我们称之为部分写失效。当写入失效发生时，先通过页的副本来还原该页，再重做日志，这就是两次写。
doublewrite步骤:
当一系列机制(main函数触发、checkpoint等)触发数据缓冲池中的脏页进行刷新时，并不直接写磁盘，而是会通过memcpy函数将脏页拷贝到内存中的doublewrite buffer，之后通过doublewrite buffer再分两次、每次1MB顺序写入共享表空间的物理磁盘上。
然后马上调用fsync函数，同步脏页进磁盘。在这个过程中，doublewrite页的存储是连续的，因此写入磁盘为顺序写，性能很高在完成doublewrite页的写入后，再将doublewrite buffer中的页写入到各个表空间文件中，此时的写入则是离散的。
如果操作系统在将页写入磁盘的过程中崩溃了，在恢复过程中，InnoDB存储引擎可以从共享表空间中的doublewrite中找到该页的一个副本，将其拷贝到表空间文件，再应用重做日志，就完成了恢复过程。因为有副本所以也不担心表空间中数据页是否损坏。
(3)自适应哈希索引
InnoDB存储引擎会监控对表上索引的查找，如果观察到建立哈希索引可以带来速度的提升，则建立哈希索引，所以称为自适应的。自适应哈希索引通过缓冲池的B+树构造而来，因此建立的速度很快，而且不需要将整个表都建哈希索引，InnoDB存储引擎会自动根据访问的频率和模式来为某些页建立哈希索引。
(4)预读
InnoDB 提供了两种预读的方式，一种是 Linear read ahead，由参数innodb_read_ahead_threshold控制，当你连续读取一个 extent 的 threshold 个 page 的时候，会触发下一个 extent 64个page的预读。另外一种是Random read-ahead，由参数innodb_random_read_ahead控制，当你连续读取设定的数量的page后，会触发读取这个extent的剩余page。
InnoDB 的预读功能是使用后台线程异步完成的。
事务就是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。事务是数据库维护数据一致性的单位，在每个事务结束时，都能保持数据一致性。
myisamchk是用来做什么的?它用来压缩MyISAM表，这减少了磁盘或内存使用。
列对比运算符是什么?在SELECT语句的列比较中使用=，<>，<=，<，> =，>，<<，>>，<=>，AND，OR或LIKE运算符。
BLOB和TEXT有什么区别?BLOB是一个二进制对象，可以容纳可变数量的数据。TEXT是一个不区分大小写的BLOB。
BLOB和TEXT类型之间的唯一区别在于对BLOB值进行排序和比较时区分大小写，对TEXT值不区分大小写。
Mysql如何优化DISTINCT?DISTINCT在所有列上转换为GROUP BY，并与ORDER BY子句结合使用。
SELECT DISTINCT t1.a FROM t1,t2 where t1.a=t2.a;
SELECT * FROM user LIMIT 0,50;
最多支持多少个索引列?16个
通用SQL函数有哪些?- CONCAT(A, B) – 连接两个字符串值以创建单个字符串输出。通常用于将两个或多个字段合并为一个字段。
- FORMAT(X, D)- 格式化数字X到D有效数字。
- CURRDATE(), CURRTIME()- 返回当前日期或时间。
- NOW() – 将当前日期和时间作为一个值返回。
- MONTH()，DAY()，YEAR()，WEEK()，WEEKDAY() – 从日期值中提取给定数据。
- HOUR()，MINUTE()，SECOND() – 从时间值中提取给定数据。
- DATEDIFF(A，B) – 确定两个日期之间的差异，通常用于计算年龄
- SUBTIMES(A，B) – 确定两次之间的差异。
- FROMDAYS(INT) – 将整数天数转换为日期值。
NUMERIC和DECIMAL类型被Mysql实现为同样的类型，这在SQL92标准允许。他们被用于保存值，该值的准确精度是极其重要的值，例如与金钱有关的数据。当声明一个类是这些类型之一时，精度和规模的能被(并且通常是)指定。
锁的优化策略- 读写分离
- 分段加锁
- 减少锁持有的时间
- 多个线程尽量以相同的顺序去获取资源
不能将锁的粒度过于细化，不然可能会出现线程的加锁和释放次数过多，反而效率不如一次加一把大锁。
- 设计良好的数据库结构，允许部分数据冗余，尽量避免join查询，提高效率。
- 选择合适的表字段数据类型和存储引擎，适当的添加索引。
- Mysql库主从读写分离。
- 找规律分表，减少单表中的数据量提高查询速度。- 添加缓存机制，比如memcached，apc等。
- 不经常改动的页面，生成静态页面。
- 书写高效率的SQL。比如 SELECT * FROM TABEL 改为 SELECT field_1, field_2, field_3 FROM TABLE.
- Where子句中:where表之间的连接必须写在其他Where条件之前，那些可以过滤掉最大数量记录的条件必须写在Where子句的末尾.HAVING最后。
- 用EXISTS替代IN、用NOT EXISTS替代NOT IN。
- 避免在索引列上使用计算
- 避免在索引列上使用IS NULL和IS NOT NULL
- 对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
- 应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描
- 应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描
- 视图能够简化用户的操作
- 视图使用户能以多种角度看待同一数据
- 视图为数据库提供了一定程度的逻辑独立性
- 视图能够对机密数据提供安全保护
第一范式:1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；
第二范式:2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；
第三范式:3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。
范式化设计优缺点:
优点:可以尽量得减少数据冗余，使得更新快，体积小
缺点:对于查询需要多个表进行关联，减少写得效率增加读得效率，更难进行索引优化
反范式化:
优点:可以减少表得关联，可以更好得进行索引优化
缺点:数据冗余以及数据异常，数据得修改需要更多的成本
数据完整性(Data Integrity)是指数据的精确(Accuracy)和可靠性(Reliability)。
分为以下四类:
- 实体完整性:规定表的每一行在表中是惟一的实体。
- 域完整性:是指表中的列必须满足某种特定的数据类型约束，其中约束又包括取值范围、精度等规定。
- 参照完整性:是指两个表的主关键字和外关键字的数据应一致，保证了表之间的数据的一致性，防止了数据丢失或无意义的数据在数据库中扩散。
- 用户定义的完整性:不同的关系数据库系统根据其应用环境的不同，往往还需要一些特殊的约束条件。用户定义的完整性即是针对某个特定关系数据库的约束条件，它反映某一具体应用必须满足的语义要求。
与表有关的约束:包括列约束(NOT NULL(非空约束))和表约束(PRIMARY KEY、foreign key、check、UNIQUE) 。
解释Mysql外连接、内连接与自连接的区别?先说什么是交叉连接: 交叉连接又叫笛卡尔积，它是指不使用任何条件，直接将一个表的所有记录和另一个表中的所有记录一一匹配。
内连接 则是只有条件的交叉连接，根据某个条件筛选出符合条件的记录，不符合条件的记录不会出现在结果集中，即内连接只连接匹配的行。
外连接 其结果集中不仅包含符合连接条件的行，而且还会包括左表、右表或两个表中
的所有数据行，这三种情况依次称之为左外连接，右外连接，和全外连接。
左外连接，也称左连接，左表为主表，左表中的所有记录都会出现在结果集中，对于那些在右表中并没有匹配的记录，仍然要显示，右边对应的那些字段值以NULL来填充。右外连接，也称右连接，右表为主表，右表中的所有记录都会出现在结果集中。左连接和右连接可以互换，Mysql目前还不支持全外连接。
存储时间Datatime:以 YYYY-MM-DD HH:MM:SS 格式存储时期时间，精确到秒，占用8个字节得存储空间，datatime类型与时区无关
Timestamp:以时间戳格式存储，占用4个字节，范围小1970-1-1到2038-1-19，显示依赖于所指定得时区，默认在第一个列行的数据修改时可以自动得修改timestamp列得值
Date:(生日)占用得字节数比使用字符串.datatime.int储存要少，使用date只需要3个字节，存储日期月份，还可以利用日期时间函数进行日期间得计算
Time:存储时间部分得数据
注意:不要使用字符串类型来存储日期时间数据(通常比字符串占用得储存空间小，在进行查找过滤可以利用日期得函数)
使用int存储日期时间不如使用timestamp类型
SQL注入产生的原因:程序开发过程中不注意规范书写sql语句和对特殊字符进行过滤，导致客户端可以通过全局变量POST和GET提交一些sql语句正常执行。
防止SQL注入的方式:
开启配置文件中的magic_quotes_gpc 和 magic_quotes_runtime设置
执行sql语句时使用addslashes进行sql语句转换
Sql语句书写尽量不要省略双引号和单引号。
过滤掉sql语句中的一些关键词:update、insert、delete、select、 * 。
提高数据库表和字段的命名技巧，对一些重要的字段根据程序的特点命名，取不易被猜到的。
事务(transaction)是作为一个单元的一组有序的数据库操作。如果组中的所有操作都成功，则认为事务成功，即使只有一个操作失败，事务也不成功。如果所有操作完成，事务则提交，其修改将作用于所有其他数据库进程。如果一个操作失败，则事务将回滚，该事务所有操作的影响都将取消。
B树和B+树的区别?B+树是一种平衡查找树。在B+树中，所有记录节点都是按键值的大小顺序存放在同一层的叶节点中，各叶结点指针进行连接。
(平衡二叉树AVL:首先符合二叉查找树的定义(最结点的值比根节点小，右结点的值比根结点大)，其次必须满足任何节点的左右两个子树的高度最大差为1。)
B树 :每个节点都存储key和data，所有节点组成这棵树，并且叶子节点指针为nul，叶子结点不包含任何关键字信息。
B+树:所有的叶子结点中包含了全部关键字的信息，及指向含有这些关键字记录的指针，且叶子结点本身依关键字的大小自小而大的顺序链接，所有的非终端结点可以看成是索引部分。
20、为什么说B+比B树更适合实际应用中操作系统的文件索引和数据库索引?
(1)B+的磁盘读写代价更低
B+的内部结点并没有指向关键字具体信息的指针。因此其内部结点相对B树更小。如果把所有同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说IO读写次数也就降低了。
(2)B+tree的查询效率更加稳定
由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。
如果是等值查询，那么哈希索引明显有绝对优势，因为只需要经过一次算法即可找到相应的键值；当然了，这个前提是，键值都是唯一的。如果键值不是唯一的，就需要先找到该键所在位置，然后再根据链表往后扫描，直到找到相应的数据；
从示意图中也能看到，如果是范围查询检索，这时候哈希索引就毫无用武之地了，因为原先是有序的键值，经过哈希算法后，有可能变成不连续的了，就没办法再利用索引完成范围查询检索；
同理，哈希索引也没办法利用索引完成排序，以及like ‘xxx%’ 这样的部分模糊查询(这种部分模糊查询，其实本质上也是范围查询)；
哈希索引也不支持多列联合索引的最左匹配规则；
B+树索引的关键字检索效率比较平均，不像B树那样波动幅度大，在有大量重复键值情况下，哈希索引的效率也是极低的，因为存在所谓的哈希碰撞问题。
减少开销。建一个联合索引(col1,col2,col3)，实际相当于建了(col1),(col1,col2),(col1,col2,col3)三个索引。每多一个索引，都会增加写操作的开销和磁盘空间的开销。对于大量数据的表，使用联合索引会大大的减少开销！
覆盖索引。对联合索引(col1,col2,col3)，如果有如下的sql: select col1,col2,col3 from test where col1=1 and col2=2。那么Mysql可以直接通过遍历索引取得数据，而无需回表，这减少了很多的随机io操作。减少io操作，特别的随机io其实是dba主要的优化策略。所以，在真正的实际应用中，覆盖索引是主要的提升性能的优化手段之一。
效率高。索引列越多，通过索引筛选出的数据越少。有1000W条数据的表，有如下sql:select from table where col1=1 and col2=2 and col3=3,假设假设每个条件可以筛选出10%的数据，如果只有单值索引，那么通过该索引能筛选出1000W10%=100w条数据，然后再回表从100w条数据中找到符合col2=2 and col3= 3的数据，然后再排序，再分页；如果是联合索引，通过索引筛选出1000w10% 10% *10%=1w，效率提升可想而知！
从本质上来说，联合索引还是一颗B+树，不同的是联合索引的键值的数量不是1，而是大于等于2。
对于查询 SELECT * FROM TABLE WHERE a=xxx and b=xxx，显然可以使用(a,b)这个联合索引。对于单个的a列查询 SELECT * FROM TABLE WHERE a=xxx 也是可以使用(a,b)索引。但对于b列的查询 SELECT * FROM TABLE WHERE b=xxx 不可以使用这颗B+树索引。因为叶节点上的b值为1,2,1,4,1,2，显然不是排序的，因此对于b列的查询使用不到(a,b)的索引。
联合索引的第二个好处是，可以对第二个键值进行排序。例如，在很多情况下我们都需要查询某个用户的购物情况，并按照时间排序，去除最近3次的购买记录，这是使用联合索引可以避免多一次的排序操作，因为索引本身在叶节点已经排序了。
【注】:对于相同的第一个键值的数据，第二个键值是排好序的。
对于单个列a的查询往往使用单个键的索引，因为其叶节点包含单个键值，能存放的记录更多。
我们想要删除百万数据的时候可以先删除索引
然后批量删除其中无用数据
删除完成后重新创建索引。
Inner join 内连接，在两张表进行连接查询时，只保留两张表中完全匹配的结果集
left join 在两张表进行连接查询时，会返回左表所有的行，即使在右表中没有匹配的记录。
right join 在两张表进行连接查询时，会返回右表所有的行，即使在左表中没有匹配的记录。
Mysql的存储引擎InnoDB使用重做日志(redo log)保证一致性与持久性，回滚日志(undo log)保证原子性，使用各种锁来保证隔离性。
事务是如何通过日志来实现的?Undo 记录某 数据 被修改 前 的值，可以用来在事务失败时进行 rollback；
Redo 记录某 数据块 被修改 后 的值，可以用来恢复未写入 data file 的已成功事务更新的数据。
Redo Log 保证事务的持久性
Undo Log 保证事务的原子性(在 InnoDB 引擎中，还用 Undo Log 来实现 MVCC)
用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步。 用于数据库的基于时间点的还原。
不考虑事务的隔离性，会发生几种问题?通过锁可以实现事务隔离性的要求，使得事务可以并发地工作。因为事务隔离性的要求，锁会带来3种问题:丢失更新、脏读、不可重复读。
丢失更新:
指一个事务正在访问修改数据，与此同时另一个事务也在访问修改此数据，两个事务互相不知道对方的存在。假如在是事务A修改数据前事务B已经修改过1次数据，那么事务A最终只能查询到假数据，丢失了更新操作。
解决方案:
悲观锁的方式:
加锁，建议最后一步更新数据的时候加上排它锁，不要在一开始就加锁。执行到了最后一步更新，首先做一下加锁的查询确认数据有没有没改变，如果没有被改变，则进行数据的更新，否则失败。 一定要是做加锁的查询确认，因为如果你不加锁的话，有可能你在做确认的时候数据又发生了改变。
乐观锁的方式:使用版本控制实现。
脏读:
一个事务读取了另一个事务未提交的数据，那这个读取就是脏读。
解决方法:
把数据库的事务隔离级别调整到read commited。
不可重复读:
不可重复读是指在一个事务内多次读同一数据，在这个事务还没有结束时，另外一个事务也访问并修改该同一数据，那么在第一个事务的两次读数据之间，由于第二个事务的修改，第一个事务两次读到的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为不可重复读。
如何避免:
InnoDB存储引擎中，通过使用Next-Key Lock算法来避免不可重复读的问题。在Next-Key Lock算法下，对于索引的扫描，不仅仅是锁住扫描到的索引，而且还能锁住这些索引覆盖的范围。因此对于这个范围内的插入都是不允许的。InnoDB存储引擎的默认事务隔离级别是READ REPEATABLE，采用Next-Key Lock算法，就避免了不可重复读的现象。
解决办法:
把数据库的事务隔离级别调整到 REPEATABLE READ ， 读取时候不允许其他事务修改该数据，不管数据在事务过程中读取多少次，数据都是一致的。
幻读:
是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。
如何避免:
Repeatable read及以上级别通过间隙锁来防止幻读的出现，即锁定特定数据的前后间隙让数据无法被插入。
共享锁和排它锁是具体的锁，是数据库机制上的锁。
共享锁(读锁): 在同一个时间段内，多个用户可以读取同一个资源，读取的过程中数据不会发生任何变化。读锁之间相互不阻塞， 多个用户可以同时读，但是不能允许有人修改。
排它锁(写锁): 在任何时候只能有一个用户写入资源，当进行写锁时会阻塞其他的读锁或者写锁操作，只能由这一个用户来写，其他用户既不能读也不能写。
表锁:开销较小，一旦有用户访问这个表就会加锁，其他用户就不能对这个表操作了，应用程序的访问请求遇到锁等待的可能性比较高。
页锁:是Mysql中比较独特的一种锁定级别，锁定颗粒度介于行级锁定与表级锁之间，所以获取锁定所需要的资源开销，以及所能提供的并发处理能力也同样是介于上面二者之间。另外，页级锁定和行级锁定一样，会发生死锁。
行锁:开销较大，能具体的锁定到表中的某一行数据，但是能更好的支持并发处理， 会发生死锁。
先简单介绍一下一些组件的基本作用:
连接器: 身份认证和权限相关(登录 Mysql 的时候)。
查询缓存: 执行查询语句的时候，会先查询缓存(Mysql 8.0 版本后移除，因为这个功能不太实用)。
分析器: 没有命中缓存的话，SQL 语句就会经过分析器，分析器说白了就是要先看你的 SQL 语句要干嘛，再检查你的 SQL 语句语法是否正确。
优化器: 按照 Mysql 认为最优的方案去执行。
执行器: 执行语句，然后从存储引擎返回数据。
水平分库:以字段为依据，按照一定策略(hash、range等)，将一个库中的数据拆分到多个库中。
水平分表:以字段为依据，按照一定策略(hash、range等)，将一个表中的数据拆分到多个表中。
垂直分库:以表为依据，按照业务归属不同，将不同的表拆分到不同的库中。
垂直分表:以字段为依据，按照字段的活跃性，将表中字段拆到不同的表(主表和扩展表)中。
sharding-jdbc目前是基于jdbc驱动，无需额外的proxy，因此也无需关注proxy本身的高可用。
Mycat是基于 Proxy，它复写了 Mysql 协议，将 Mycat Server 伪装成一个 Mysql 数据库。
事务问题:需要用分布式事务啦
跨节点Join的问题:解决这一问题可以分两次查询实现
跨节点的count,order by,group by以及聚合函数问题:分别在各个节点上得到结果后在应用程序端进行合并。
数据迁移，容量规划，扩容等问题
ID问题:数据库被切分后，不能再依赖数据库自身的主键生成机制啦，最简单可以考虑UUID
跨分片的排序分页问题(后台加大pagesize处理?)
数据库自增长序列或字段。
UUID
雪花算法
Redis生成ID
利用zookeeper生成唯一ID
方案一:如果id是连续的，可以这样，返回上次查询的最大记录(偏移量)，再往下limit
select id，name from employee where id>1000000 limit 10.
方案二:在业务允许的情况下限制页数:
建议跟业务讨论，有没有必要查这么后的分页啦。因为绝大多数用户都不会往后翻太多页。
方案三:order by + 索引(id为索引)
select id，name from employee order by id limit 1000000，10
SELECT a.* FROM employee a, (select id from employee where 条件 LIMIT 1000000,10 ) b where a.id=b.id
方案四:利用延迟关联或者子查询优化超多分页场景。(先快速定位需要获取的id段，然后再关联)
select for update有什么含义，会锁表还是锁行还是其他?select查询语句是不会加锁的，但是select for update除了有查询的作用外，还会加锁呢，而且它是悲观锁哦。至于加了是行锁还是表锁，这就要看是不是用了索引/主键啦。 没用索引/主键的话就是表锁，否则就是是行锁。
Mysql中in 和exists的区别?副表数据小于主表用in；副表数据大于主表用exists
Mysql的主从延迟，你怎么解决?主从复制分了五个步骤进行:
步骤一:主库的更新事件(update、insert、delete)被写到binlog
步骤二:从库发起连接，连接到主库。
步骤三:此时主库创建一个binlog dump thread，把binlog的内容发送到从库。
步骤四:从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log
步骤五:还会创建一个SQL线程，从relay log里面读取内容，从Exec_Master_Log_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db
主从同步延迟的原因:
一个服务器开放Ｎ个链接给客户端来连接的，这样有会有大并发的更新操作, 但是从服务器的里面读取binlog的线程仅有一个，当某个SQL在从服务器上执行的时间稍长 或者由于某个SQL要进行锁表就会导致，主服务器的SQL大量积压，未被同步到从服务器里。这就导致了主从不一致， 也就是主从延迟。
数据库连接池原理:在内部对象池中，维护一定数量的数据库连接，并对外暴露数据库连接的获取和返回方法。
应用程序和数据库建立连接的过程:
通过TCP协议的三次握手和数据库服务器建立连接
发送数据库用户账号密码，等待数据库验证用户身份
完成身份验证后，系统可以提交SQL语句到数据库执行
把连接关闭，TCP四次挥手告别。
数据库连接池好处:
- 资源重用 (连接复用)。
- 更快的系统响应速度。
- 新的资源分配手段 统一的连接管理，避免数据库连接泄漏。
覆盖索引:查询列要被所建的索引覆盖，不必从数据表中读取，换句话说查询列要被所使用的索引覆盖。
回表:二级索引无法直接查询所有列的数据，所以通过二级索引查询到聚簇索引后，再查询到想要的数据，这种通过二级索引查询出来的过程，就叫做回表。