Mysql 基础

数据库框架发展

Mysql复制的三个步骤：

主服务器把数据记录到二进制日志中

从服务器把主服务器的二进制日志拷到中继日志上

从服务器把中继日志的时间重做，更新到自己的数据库上

（同步并非实时）

Char和Varchar的区别：Char定长，Varchar变长。

Mysql优化：

优化sql语句

memecached缓存

读写数据库分开

更新索引

旧数据移除备份

Myisam与Innodb的区别

Myisam读速度比Innodb快

Myisam不提供事务和外键，Innodb提供

Myisam是表级锁，Innodb是行级锁

Myisam支持全文索引（英文），Innodb不支持

Myisam支持GIS数据，Innodb不支持

Myisam的主键范围小于Innodb

Innodb的大批量插入操作比较慢，默认开启自动提交事务

Myisam大批量读并且修改的操作较慢，因为会锁住整张表，无法读，导致进程饥饿。

HEAP：HEAP允许只驻留在内存里的临时表格。驻留在内存里让HEAP要比ISAM和MYISAM都快，但是它所管理的数据是不稳定的，而且如果在关机之前没有进行保存，那么所有的数据都会丢失。在数据行被删除的时候，HEAP也不会浪费大量的空间。HEAP表格在你需要使用SELECT表达式来选择和操控数据的时候非常有用。要记住，在用完表格之后就删除表格。

Mysql的一致性和完整性

事务：原子性、一致性、隔离性、持久性

一致性：保证每个操作都是原子的，要么都成功，要么都回滚。

数据库并发操作存在的异常情况：

1.更新丢失（LostUpdate）：

A和B事务并发执行，A事务执行更新后，提交；B事务在A事务更新后，B事务结束前也做了对该行数据的更新操作，然后回滚，则两次更新操作都丢失了。

第一类丢失更新(回滚丢失，Lost update)。

在事务A期间，事务B对数据进行了更新；在事务A撤销之后，覆盖了事务B已经提交的数据。

SQL92没有定义这种现象，标准定义的所有隔离界别都不允许第一类丢失更新发生。

第二类丢失更新(覆盖丢失/两次更新问题，Second lost update)。

在事务A期间，事务B对数据进行了更新；在事务A提交之后，覆盖了事务B已经提交的数据。

第二类丢失更新，实际上和不可重复读是同一种问题。

2.脏读取（DirtyReads）：

A和B事务并发执行，B事务执行更新后，A事务查询B事务没有提交的数据，B事务回滚，则A事务得到的数据不是数据库中的真实数据。也就是脏数据，即和数据库中不一致的数据。

3.不可重复读取（Non-repeatableReads）：

A和B事务并发执行，A事务查询数据，然后B事务更新该数据并提交，A再次查询该数据时，发现该数据变化了。

4.幻读（PhantomReads）：也称为幻像（幻影）。

A和B事务并发执行，A事务查询数据，B事务插入或者删除数据并提交，A事务再次查询发现,结果集中,有以前没有的数据或者以前有的数据消失了。

**

为了避免上面出现几种情况在标准SQL规范中定义了4个事务隔离级别，不同隔离级别对事务处理不同。

**

1. READ-UNCOMMITTED未授权读取/未提交读

允许脏读取但不允许更新丢失。

如果一个事务已经开始写数据，则另外一个事务不允许同时进行写操作，但允许其他事务读此行数据。通过“排他写锁”实现。

2. READ-COMMITTED授权读取/提交读

允许不可重复读取但不允许脏读取。

更新语句提交以后别的事务才能读到这个改变。读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。通过“瞬间共享读锁”和“排他写锁”实现，

在此隔离级下，SELECT命令不会返回尚未提交（Committed）的数据，也不能返回脏数据。

3. REPEATABLE-READ可重复读取

禁止不可重复读取和脏读取。但是有时可能出现幻影数据

在同一个事务里面先后执行同一个查询语句的时候，确保得到的结果是一样的。读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。通过“共享读锁”和“排他写锁”实现，

在此隔离级下，用SELECT命令读取的数据在整个命令执行过程中不会被更改。此选项会影响系统的效能，非必要情况最好不用此隔离级。

4. SERIALIZABLE串行/可串行读。

事务只能一个接着一个地执行，但不能并发执行。如果仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作事务访问到。

完整性：

1.实体完整性：实体的完整性强制表的标识符列或主键的完整性(通过索引,唯一约束,主键约束或标识列属性).

2.域完整性：限制类型(数据类型),格式(通过检查约束和规则),可能值范围(通过外键约束,检查约束,默认值定义,非空约束和规则).

3.引用完整性：在删除和输入记录时,引用完整性保持表之间已定义的关系.引用完整性确保键值在所有表中一致.这样的一致辞性要求不能引用不存在的值.如果一个键值更改了,那么在整个数据库中,对该键值的引用要进行一致的更改.

4.自定义完整性：用户自己定义的业务规则.

约束和数据完整性

主键（Primary key）

外键（Foreign key）

唯一（unique）

检查（check）:MySQL不支持。

默认（default）

数据库3范式：

第1规范：没有重复的组或多值的列，这是数据库设计的最低要求。

第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组成部分。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。

第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。

Mysql 索引

索引的优点：

1、通过创建唯一索引，保证数据库表每行数据的唯一性

2、大大加快数据查询速度

3、在使用分组和排序进行数据查询时，可以显著减少查询中分组和排序的时间

索引的缺点：

1、维护索引需要耗费数据库资源

2、索引需要占用磁盘空间，索引文件可能比数据文件更快达到最大文件尺寸

3、当对表的数据进行增删改的时候，因为要维护索引，速度会受到影响

Mysql索引分类

1、普通索引和唯一索引

主键索引是一种特殊的唯一索引，不允许有空值

2、单列索引和复合索引

单列索引只包含单个列，复合索引指多个字段上创建的索引，只有在查询条件中使用了创建索引时的第一个字段，索引才会被使用。使用复合索引时遵循最左前缀集合

3、全文索引

全文索引类型为FULLTEXT，在定义索引的列上支持值的全文查找，允许在这些索引列中插入重复值和空值。全文索引可以在CHAR、VARCHAR、TEXT类型列上创建。MYSQL只有MYISAM存储引擎支持全文索引

4、空间索引

空间索引是对空间数据类型的字段建立的索引，MYSQL中的空间数据类型有4种，分别是GEOMETRY、POINT、LINESTRING、POLYGON。MYSQL使用SPATIAL关键字进行扩展，使得能够用于创建正规索引类型的语法创建空间索引。创建空间索引的列，必须将其声明为NOT NULL，空间索引只能在存储引擎为MYISAM的表中创建

Mysql索引类型:

full-text(myisam)

b-tree(innodb,myisam)

hash(innodb,myisam)

r-tree(myisam,GIS)

视图的作用

1.安全：可对真正的数据进行改名

2.快速：可事先联表，减少联表查询的开销

3.灵活：可升级数据库而不影响查询

基本配置

你需要经常察看以下3个配置项。不然，可能很快就会出问题。

innodb_buffer_pool_size:这是你安装完InnoDB后第一个应该设置的选项。缓冲池是数据和索引缓存的地方：这个值越大越好，这能保证你在大多数的读取操作时使用的是内存而不是硬盘。典型的值是5-6GB(8GB内存)，20-25GB(32GB内存)，100-120GB(128GB内存)。

innodb_log_file_size：这是redo日志的大小。redo日志被用于确保写操作快速而可靠并且在崩溃时恢复。一直到MySQL 5.1，它都难于调整，因为一方面你想让它更大来提高性能，另一方面你想让它更小来使得崩溃后更快恢复。幸运的是从MySQL 5.5之后，崩溃恢复的性能的到了很大提升，这样你就可以同时拥有较高的写入性能和崩溃恢复性能了。一直到MySQL 5.5，redo日志的总尺寸被限定在4GB(默认可以有2个log文件)。这在MySQL 5.6里被提高。

一开始就把innodb_log_file_size设置成512M(这样有1GB的redo日志)会使你有充裕的写操作空间。如果你知道你的应用程序需要频繁的写入数据并且你使用的时MySQL 5.6，你可以一开始就把它这是成4G。

max_connections:如果你经常看到‘Too many connections’错误，是因为max_connections的值太低了。这非常常见因为应用程序没有正确的关闭数据库连接，你需要比默认的151连接数更大的值。max_connection值被设高了(例如1000或更高)之后一个主要缺陷是当服务器运行1000个或更高的活动事务时会变的没有响应。在应用程序里使用连接池或者在MySQL里使用进程池有助于解决这一问题。

InnoDB配置

从MySQL 5.5版本开始，InnoDB就是默认的存储引擎并且它比任何其他存储引擎的使用都要多得多。那也是为什么它需要小心配置的原因。

innodb_file_per_table：这项设置告知InnoDB是否需要将所有表的数据和索引存放在共享表空间里（innodb_file_per_table = OFF） 或者为每张表的数据单独放在一个.ibd文件（innodb_file_per_table = ON）。每张表一个文件允许你在drop、truncate或者rebuild表时回收磁盘空间。这对于一些高级特性也是有必要的，比如数据压缩。但是它不会带来任何性能收益。你不想让每张表一个文件的主要场景是：有非常多的表（比如10k+）。

MySQL 5.6中，这个属性默认值是ON，因此大部分情况下你什么都不需要做。对于之前的版本你必需在加载数据之前将这个属性设置为ON，因为它只对新创建的表有影响。

innodb_flush_log_at_trx_commit：默认值为1，表示InnoDB完全支持ACID特性。当你的主要关注点是数据安全的时候这个值是最合适的，比如在一个主节点上。但是对于磁盘（读写）速度较慢的系统，它会带来很巨大的开销，因为每次将改变flush到redo日志都需要额外的fsyncs。将它的值设置为2会导致不太可靠（reliable）因为提交的事务仅仅每秒才flush一次到redo日志，但对于一些场景是可以接受的，比如对于主节点的备份节点这个值是可以接受的。如果值为0速度就更快了，但在系统崩溃时可能丢失一些数据：只适用于备份节点。

innodb_flush_method: 这项配置决定了数据和日志写入硬盘的方式。一般来说，如果你有硬件RAID控制器，并且其独立缓存采用write-back机制，并有着电池断电保护，那么应该设置配置为O_DIRECT；否则，大多数情况下应将其设为fdatasync（默认值）。sysbench是一个可以帮助你决定这个选项的好工具。

innodb_log_buffer_size: 这项配置决定了为尚未执行的事务分配的缓存。其默认值（1MB）一般来说已经够用了，但是如果你的事务中包含有二进制大对象或者大文本字段的话，这点缓存很快就会被填满并触发额外的I/O操作。看看Innodb_log_waits状态变量，如果它不是0，增加innodb_log_buffer_size。

其他设置

query_cache_size: query cache（查询缓存）是一个众所周知的瓶颈，甚至在并发并不多的时候也是如此。 最佳选项是将其从一开始就停用，设置query_cache_size = 0（现在MySQL 5.6的默认值）并利用其他方法加速查询：优化索引、增加拷贝分散负载或者启用额外的缓存（比如memcache或redis）。如果你已经为你的应用启用了query cache并且还没有发现任何问题，query cache可能对你有用。这是如果你想停用它，那就得小心了。

log_bin：如果你想让数据库服务器充当主节点的备份节点，那么开启二进制日志是必须的。如果这么做了之后，还别忘了设置server_id为一个唯一的值。就算只有一个服务器，如果你想做基于时间点的数据恢复，这（开启二进制日志）也是很有用的：从你最近的备份中恢复（全量备份），并应用二进制日志中的修改（增量备份）。二进制日志一旦创建就将永久保存。所以如果你不想让磁盘空间耗尽，你可以用 PURGE BINARY LOGS 来清除旧文件，或者设置 expire_logs_days 来指定过多少天日志将被自动清除。

记录二进制日志不是没有开销的，所以如果你在一个非主节点的复制节点上不需要它的话，那么建议关闭这个选项。

skip_name_resolve：当客户端连接数据库服务器时，服务器会进行主机名解析，并且当DNS很慢时，建立连接也会很慢。因此建议在启动服务器时关闭skip_name_resolve选项而不进行DNS查找。唯一的局限是之后GRANT语句中只能使用IP地址了，因此在添加这项设置到一个已有系统中必须格外小心。