数据库系统工作原理：
1. 用户向数据库发起连接；
2. MySQL数据库验证权限。如果权限不够，直接拒绝 ，权限ok进入下一步；
3. 用户开始发起SQL语句；
4. MySQL数据库解析器开始解析SQL语句；
5. MySQL开始查询自己的本地缓存，有的话直接反馈给用户，没有的话，进入下一步；
6. 经过解析器。对SQL语句进行定位，最后找到所需要的数据，在本地缓存一份，然后反馈给用户。
MySQL数据库引擎：
1. innoDB 优势：提供了良好的事物管理、崩溃、修复能力和并发控制
缺点：读写效率稍差，占用的数据空间相对比较大
使用场合：在承载的大部分项目执行insert和update的话，应选择InnoDB
2. MyISAM 优势：占用空间小，处理速度快
缺点：不支持事务日志的完整性和并发性
使用场合:在承载的大部分项目是读多写少的项目平台中，而myISAM的读写性能是比InnoDB强不少的
3. MEMORY 优势：存储速度快
缺点：缺乏稳定性和完整性
事务具有四个特性：原子性（atomiocity） 一致性（consistency）隔离性（Isolation） 持久性（Durability） 简称为ACID特性
通俗的说事务: 指一组操作,要么都成功执行,要么都不执行.---->原子性
在所有的操作没有执行完毕之前,其他会话不能够看到中间改变的过程-->隔离性
事务发生前,和发生后,数据的总额依然匹配----->一致性
事务产生的影响不能够撤消------>持久性
如果出了错误,事务也不允许撤消, 只能通过"补偿性事务"。
mysql常见的三种锁级别——表级锁、页面锁、行级锁；其中表级锁有两种模式——表共享读锁和表独占写锁。
行级锁的优点如下：
1.当很多连接分别进行不同的查询时减小LOCK状态。
2.如果出现异常，可以减少数据的丢失。因为一次可以只回滚一行或者几行少量的数据。
行级锁的缺点如下：
1.占用更多的内存。
2.需要的I/O更多，所以我们经常把行级锁用在写操作而不是读操作。
3.容易出现死锁。
Mysql复制的几种模式：
1. 基于sql语句的复制
2. 基于行的复制
3. 混合模式复制
异步复制（Asynchronous replication）
MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。
全同步复制（Fully synchronous replication）
指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。
半同步复制（Semisynchronous replication）
介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。
主从复制：
MySQL主从复制的原理就是从服务器读取主服务器的binlog，然后根据binlog的记录来更新数据库。
MySQL的replication是一个异步的复制过程，在master和slave之间实现整个复制过程主要由3个线程来完成，在slave端有IO和SQL线程，这两个线程的状态必须是yes。
mysql主从架构中其实就一个主在工作，而从就相当于一个备份机器，从通过日志监测的方式来备份主库上的数据而保证主库的数据安全。在这种架构中如果从上的数据做了改变，主数据是不会发生任何变化的。
一般通过 主从复制（Master-Slave）的方式来同步数据，再通过读写分离（MySQL-Proxy）来提升数据库的并发负载能力
MYSQL5.5版本特性：
1.引擎的变更---linux下默认innodb
2.cpu内核以及cpu物理数支持增加
3.复制功能增强：支持半同步
4.增强表分区功能
附：
MySQL 5.1 中，在复制方面的改进就是引进了新的复制技术：基于行的复制。
简言之，这种新技术就是关注表中发生变化的记录，而非以前的照抄 binlog 模式。
从 MySQL 5.1.12 开始，可以用以下三种模式来实现：
-- 基于SQL语句的复制(statement-based replication, SBR)：在主服务器上执行的SQL语句，在从服务器上执行同样的语句。MySQL默认采用基于语句的复制，效率比较高。 一旦发现没法精确复制时， 会自动选择基于行的复制。
-- 基于行的复制(row-based replication, RBR)：把改变的内容复制过去，而不是把命令在从服务器上执行一遍. 从mysql5.0开始支持
-- 混合模式复制(mixed-based replication, MBR)：混合类型的复制: 默认采用基于语句的复制，一旦发现基于语句的无法精确的复制时，就会采用基于行的复制。
相应地，binlog的格式也有三种：STATEMENT，ROW，MIXED。 MBR 模式中，SBR 是默认的。
在运行时可以动态低改变binlog的格式，除了以下几种情况：
. 存储过程或者触发器中间
. 启用了NDB
. 当前会话试用 RBR 模式，并且已打开了临时表
如果binlog采用了 MIXED 模式，那么在以下几种情况下会自动将binlog的模式由 SBR 模式改成 RBR 模式。
. 当DML语句更新一个NDB表时
. 当函数中包含 UUID() 时
. 2个及以上包含 AUTO_INCREMENT 字段的表被更新时
. 行任何 INSERT DELAYED 语句时
. 用 UDF 时
. 视图中必须要求使用 RBR 时，例如创建视图是使用了 UUID() 函数
设定主从复制模式的方法非常简单，只要在以前设定复制配置的基础上，再加一个参数：
binlog_format="STATEMENT"
#binlog_format="ROW"
#binlog_format="MIXED"
当然了，也可以在运行时动态修改binlog的格式。例如
mysql> SET SESSION binlog_format = ‘STATEMENT‘;
mysql> SET SESSION binlog_format = ‘ROW‘;
mysql> SET SESSION binlog_format = ‘MIXED‘;
mysql> SET GLOBAL binlog_format = ‘STATEMENT‘;
mysql> SET GLOBAL binlog_format = ‘ROW‘;
mysql> SET GLOBAL binlog_format = ‘MIXED‘;
两种模式各自的优缺点：
SBR 的优点：
历史悠久，技术成熟
binlog文件较小
binlog中包含了所有数据库更改信息，可以据此来审核数据库的安全等情况
binlog可以用于实时的还原，而不仅仅用于复制
主从版本可以不一样，从服务器版本可以比主服务器版本高
SBR 的缺点：
不是所有的UPDATE语句都能被复制，尤其是包含不确定操作的时候。
调用具有不确定因素的 UDF 时复制也可能出问题
使用以下函数的语句也无法被复制：
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非启动时启用了 --sysdate-is-now 选项)
INSERT ... SELECT 会产生比 RBR 更多的行级锁
复制需要进行全表扫描(WHERE 语句中没有使用到索引)的 UPDATE 时，需要比 RBR 请求更多的行级锁
对于有 AUTO_INCREMENT 字段的 InnoDB表而言，INSERT 语句会阻塞其他 INSERT 语句
对于一些复杂的语句，在从服务器上的耗资源情况会更严重，而 RBR 模式下，只会对那个发生变化的记录产生影响
存储函数(不是存储过程)在被调用的同时也会执行一次 NOW() 函数，这个可以说是坏事也可能是好事
确定了的 UDF 也需要在从服务器上执行
数据表必须几乎和主服务器保持一致才行，否则可能会导致复制出错
执行复杂语句如果出错的话，会消耗更多资源
RBR 的优点：
任何情况都可以被复制，这对复制来说是最安全可靠的
和其他大多数数据库系统的复制技术一样
多数情况下，从服务器上的表如果有主键的话，复制就会快了很多
复制以下几种语句时的行锁更少：
* INSERT ... SELECT
* 包含 AUTO_INCREMENT 字段的 INSERT
* 没有附带条件或者并没有修改很多记录的 UPDATE 或 DELETE 语句
执行 INSERT，UPDATE，DELETE 语句时锁更少
从服务器上采用多线程来执行复制成为可能
RBR 的缺点：
binlog 大了很多
复杂的回滚时 binlog 中会包含大量的数据
主服务器上执行 UPDATE 语句时，所有发生变化的记录都会写到 binlog 中，而 SBR 只会写一次，这会导致频繁发生 binlog 的并发写问题
UDF 产生的大 BLOB 值会导致复制变慢
无法从 binlog 中看到都复制了写什么语句(加密过的)
当在非事务表上执行一段堆积的SQL语句时，最好采用 SBR 模式，否则很容易导致主从服务器的数据不一致情况发生
另外，针对系统库 mysql 里面的表发生变化时的处理规则如下：
如果是采用 INSERT，UPDATE，DELETE 直接操作表的情况，则日志格式根据 binlog_format 的设定而记录
如果是采用 GRANT，REVOKE，SET PASSWORD 等管理语句来做的话，那么无论如何都采用 SBR 模式记录
注：采用 RBR 模式后，能解决很多原先出现的主键重复问题。
实例:
对于insert into db_allot_ids select * from db_allot_ids 这个语句:
在BINLOG_FORMAT=STATEMENT 模式下:
BINLOG日志信息为:
-----------------------------------------
BEGIN
/*!*/;
# at 173
#090612 16:05:42 server id 1 end_log_pos 288 Query thread_id=4 exec_time=0 error_code=0
SET TIMESTAMP=1244793942/*!*/;
insert into db_allot_ids select * from db_allot_ids
/*!*/;
-----------------------------------------
在BINLOG_FORMAT=ROW 模式下:
BINLOG日志信息为:
-----------------------------------------
BINLOG ‘
hA0yShMBAAAAMwAAAOAAAAAAAA8AAAAAAAAAA1NOUwAMZGJfYWxsb3RfaWRzAAIBAwAA
hA0yShcBAAAANQAAABUBAAAQAA8AAAAAAAEAAv/8AQEAAAD8AQEAAAD8AQEAAAD8AQEAAAA=
‘/*!*/;
-----------------------------------------
本文出自 “拔电源的运维空间” 博客，请务必保留此出处http://zhangdj.blog.51cto.com/9210512/1887201
原文地址：http://zhangdj.blog.51cto.com/9210512/1887201
