Mysql 优化总结【0.0.1】

数据库的优化可以从四个方面来优化:

1. 从结构层: web 服务器采用负载均衡服务器,mysql 服务器采用主从复制,读写分离

负载均衡

Nginx负载均衡服务器 在nginx里面配置一个upstream，然后把相关的服务器ip都配置进去。然后采用轮询的方案，然后在nginx里面的配置项里，proxy-pass指向这个upstream，这样就能实现负载均衡。

nginx的负载均衡有4种模式：

轮询（默认）每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

Weight 指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。

ip_hash 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

fair（第三方）按后端服务器的响应时间来分配请求，响应时间短的优先分配。

url_hash（第三方）

使用nginx与apache相比

最核心的区别在于apache是同步多进程模型，一个连接对应一个进程；nginx是异步的，多个连接（万级别）可以对应一个进程 （nginx 处理请求是异步非阻塞的，而apache 则是阻塞型的）
在高并发下nginx 能保持低资源低消耗高性能。
apache 相对于nginx 的优点： rewrite ，比nginx 的rewrite 强大 模块超多，基本想到的都可以找到 少bug 。

主从复制

原理: 在主库上把数据库上把更改记录到二进制日志
从库将主库的日志复制到自己的中继日志
从库读取中继日志中的事件，将其重放在从库数据库中

解决的问题

数据分布：随意停止或开始复制，并在不同地理位置分布数据备份

负载均衡：降低单个服务器的压力

高可用和故障切换：帮助应用程序避免单点失败

升级测试：可以使用更高版本的 MYSQL作为从库

读写分离

也是目前常用的优化，从库读主库写，一般不要采用双主或多主引入很多复杂性，尽量采用文中的其他方案来提高性能。同时目前很多拆分的解决方案同时也兼顾考虑了读写分离

2. 从储存层: 采用合适的存储引擎,采用三范式

目前广泛使用的是MyISAM和InnoDB两种引擎：

核心区别

MyISAM是非事务安全型的，而InnoDB是事务安全型的。
MyISAM锁的粒度是表级，而InnoDB支持行级锁定。
MyISAM支持全文类型索引，而InnoDB不支持全文索引。
MyISAM相对简单，所以在效率上要优于InnoDB，小型应用可以考虑使用MyISAM。
MyISAM表是保存成文件的形式，在跨平台的数据转移中使用MyISAM存储会省去不少的麻烦。
InnoDB表比MyISAM表更安全，可以在保证数据不会丢失的情况下，切换非事务表到事务表（alter table tablename type=innodb）。

应用场景

MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。如果应用中需要执行大量的SELECT查询，那么MyISAM是更好的选择。

InnoDB用于事务处理应用程序，具有众多特性，包括ACID事务支持。如果应用中需要执行大量的INSERT或UPDATE操作，则应该使用InnoDB，这样可以提高多用户并发操作的性能。

Mysql的存储引擎和索引

InnoDB使用的是聚簇索引，将主键组织到一棵B+树中，而行数据就储存在叶子节点上，若使用"where id = 14"这样的条件查找主键，则按照B+树的检索算法即可查找到对应的叶节点，之后获得行数据。若对Name列进行条件搜索，则需要两个步骤：第一步在辅助索引B+树中检索Name，到达其叶子节点获取对应的主键。第二步使用主键在主索引B+树种再执行一次B+树检索操作，最终到达叶子节点即可获取整行数据。

MyISM使用的是非聚簇索引，非聚簇索引的两棵B+树看上去没什么不同，节点的结构完全一致只是存储的内容不同而已，主键索引B+树的节点存储了主键，辅助键索引B+树存储了辅助键。表数据存储在独立的地方，这两颗B+树的叶子节点都使用一个地址指向真正的表数据，对于表数据来说，这两个键没有任何差别。由于索引树是独立的，通过辅助键检索无需访问主键的索引树。

三范式

第一范式：若关系模式 R 的每一个属性是不可再分解的，且有主键，则属于第一范式。
第二范式：若 R 属于第一范式，且所有的非主键属性都完全函数依赖于主键属性，则满足第二范式。
第三范式：若 R 属于第二范式，且所有的非主键属性没有一个是传递函数依赖于候选主键属性，则满足第三范式。
在实际使用中，可以根据需求适当的逆范式。

3. 从设计层: 采用分区分表,索引,表字段合适的字段属性,适当采用逆范式,开启 mysql 缓存

分库分表

工作原理

对用户而言，分区表是一个独立的逻辑表，但是底层 MYSQL将其分成了多个物理子表，这对用户来说是透明的，每一个分区表都会使用一个独立的表文件。

创建表时使用 partition by子句定义每个分区存放的数据，执行查询时，优化器会根据分区定义过滤那些没有我们需要数据的分区，这样查询只需要查询所需数据在的分区。

分区的主要目的是将数据按照一个较粗的粒度分在不同的表中，这样可以将相关的数据存放在一起，而且如果想一次性删除整个分区的数据也很方便。

分区的好处

可以让单表存储更多的数据

分区表的数据更容易维护，可以通过清楚整个分区批量删除大量数据，也可以增加新的分区来支持新插入的数据。另外，还可以对一个独立分区进行优化、检查、修复等操作

• 部分查询能够从查询条件确定只落在少数分区上，速度会很快
• 分区表的数据还可以分布在不同的物理设备上，从而搞笑利用多个硬件设备
• 可以使用分区表赖避免某些特殊瓶颈，例如InnoDB单个索引的互斥访问、ext3文件系统的inode锁竞争
• 可以备份和恢复单个分区

分区的限制和缺点：

• 一个表最多只能有1024个分区
• 如果分区字段中有主键或者唯一索引的列，那么所有主键列和唯一索引列都必须包含进来
• 分区表无法使用外键约束
• NULL值会使分区过滤无效
• 所有分区必须使用相同的存储引擎

分区的类型

RANGE分区：基于属于一个给定连续区间的列值，把多行分配给分区

LIST分区：类似于按RANGE分区，区别在于LIST分区是基于列值匹配一个离散值集合中的某个值来进行选择

HASH分区：基于用户定义的表达式的返回值来进行选择的分区，该表达式使用将要插入到表中的这些行的列值进行计算这个函数可以包含MySQL中有效的、产生非负整数值的任何表达式

KEY分区：类似于按HASH分区，区别在于KEY分区只支持计算一列或多列，且MySQL服务器提供其自身的哈希函数。必须有一列或多列包含整数值

分区适合的场景
表非常大，无法全部存在内存，或者只在表的最后有热点数据其他都是历史数据

分区表的数据更易维护,可以对独立的分区进行独立的操作

分区表的数据可以分布在不同的机器上,从而高效使用资源

可以使用分区表来避免某些特殊的瓶颈

备份和恢复独立的分区

垂直拆分

垂直分库是根据数据库里面的数据表的相关性进行拆分，比如：一个数据库里面既存在用户数据，又存在订单数据，那么垂直拆分可以把用户数据放到用户库、把订单数据放到订单库。垂直分表是对数据表进行垂直拆分的一种方式，常见的是把一个多字段的大表按常用字段和非常用字段进行拆分，每个表里面的数据记录数一般情况下是相同的，只是字段不一样，使用主键关联[比如将users分成了users和usersExtra两个表

优点：

• 可以使得行数据变小，一个数据块(Block)就能存放更多的数据，在查询时就会减少I/O次数(每次查询时读取的Block 就少)

• 可以达到最大化利用Cache的目的，具体在垂直拆分的时候可以将不常变的字段放一起，将经常改变的放一起

数据维护简单

缺点是：

• 主键出现冗余，需要管理冗余列

• 会引起表连接JOIN操作（增加CPU开销）可以通过在业务服务器上进行join来减少数据库压力

• 依然存在单表数据量过大的问题（需要水平拆分）

• 事务处理复杂

水平拆分

水平拆分是通过某种策略将数据分片来存储，分库内分表和分库两部分，每片数据会分散到不同的MySQL表或库，达到分布式的效果，能够支持非常大的数据量。前面的表分区本质上也是一种特殊的库内分表

库内分表，仅仅是单纯的解决了单一表数据过大的问题，由于没有把表的数据分布到不同的机器上，因此对于减轻MySQL服务器的压力来说，并没有太大的作用，大家还是竞争同一个物理机上的IO、CPU、网络，这个就要通过分库来解决

前面垂直拆分的用户表如果进行水平拆分,分为Users_A_M Users_N_Z两张表

实际情况中往往会是垂直拆分和水平拆分的结合，即将Users_A_M和Users_N_Z再拆成Users和UserExtras，这样一共四张表

优点是:

• 不存在单库大数据和高并发的性能瓶颈

• 应用端改造较少

• 提高了系统的稳定性和负载能力

缺点是：

• 分片事务一致性难以解决

• 跨节点Join性能差，逻辑复杂

• 数据多次扩展难度跟维护量极大

分片原则

• 能不分就不分

• 分片数量尽量少，分片尽量均匀分布在多个数据结点上，因为一个查询SQL跨分片越多，则总体性能越差，虽然要好于所有数据在一个分片的结果，只在必要的时候进行扩容，增加分片数量

• 分片规则需要慎重选择做好提前规划，分片规则的选择，需要考虑数据的增长模式，数据的访问模式，分片关联性问题，以及分片扩容问题，最近的分片策略为范围分片，枚举分片，一致性Hash分片，这几种分片都有利于扩容

• 尽量不要在一个事务中的SQL跨越多个分片，分布式事务一直是个不好处理的问题

• 查询条件尽量优化，尽量避免Select * 的方式，大量数据结果集下，会消耗大量带宽和CPU资源，查询尽量避免返回大量结果 集，并且尽量为频繁使用的查询语句建立索引。

通过数据冗余和表分区赖降低跨库Join的可能

这里特别强调一下分片规则的选择问题，如果某个表的数据有明显的时间特征，比如订单、交易记录等，则他们通常比较合适用时间范围分片，因为具有时效性的数据，我们往往关注其近期的数据，查询条件中往往带有时间字段进行过滤，比较好的方案是，当前活跃的数据，采用跨度比较短的时间段进行分片，而历史性的数据，则采用比较长的跨度存储。

总体上来说，分片的选择是取决于最频繁的查询SQL的条件，因为不带任何Where语句的查询SQL，会遍历所有的分片，性能相对最差，因此这种SQL越多，对系统的影响越大，所以我们要尽量避免这种SQL的产生。

索引

索引是什么

MySQL官方对索引的定义为：索引(Index)是帮助MySQL高效获取数据的数据结构。我们可以简单理解为：快速查找排好序的一种数据结构。Mysql索引主要有两种结构：B+Tree索引和Hash索引。我们平常所说的索引，如果没有特别指明，一般都是指B树结构组织的索引(B+Tree索引)。

Mysql索引为什么选择B+树

• mysql 主要是由 server 层和存储层两部分构成的。server 层主要包括连接器、查询缓存，分析器、优化器、执行器。存储层主要是用来存储和查询数据的，常用的存储引擎有 InnoDB、MyISAM，MySQL 5.5.5版本后使用 InnoDB 作为默认存储引擎。

• 几种常见的数据类型哈希表适合等值查询，由于是无序的，区间查询会很慢有序数组适合等值和区间查询，但是数组具有连续性，插入和删除操作都可能需要移动其他元素。二叉搜索树由于树的高度，区间查询需要中序遍历，都会导致查询效率很慢。

• B+ 树就是通过二叉搜索树推演改进的

• B+ 树就是一种多叉树，是由二叉搜索树不断演变过来的，为了满足区间快速查询，B+ 树的叶子节点通过双向链表串联起来。

• 这里使用双向链表是为了支持顺序和倒序查询，虽然双向链表相对于单向链表虽然会浪费一倍的指针空间，但是在硬盘中这点空间几乎微乎其微，用这点空间换时间是一件很值得的事情。

• B+ 树的子节点数不超过 m 个，同时也不能少于 m/2 个，一旦超过就需要分裂，一旦少于就需要合并。

• 而InnoDB 在底层是采用 B+ 树这种数据结构来存储数据的。

Mysql为什么加索引就快

哎 又停电！！！！一会来电再继续更新 先对付着看，哎哎哎…偌大的北京，为什么我总被停电？？？？

不加索引，会比较整个数据库，因为他不知道数据是不是规律的。添加了索引，相当于加了一个目录，给索引字段排序，比较的时候只用几次就可以查找到你需要的数据。数据越多，索引约有用。也可以说拿空间换时间。
索引对性能的影响：
大大减少服务器需要扫描的数据量。
帮助服务器避免排序和临时表。将随机I/O变顺序I/O。
大大提高查询速度，降低写的速度、占用磁盘。
索引的使用场景：
对非常小的表，大部分情况下全表扫描效率更高。
对中大型表，索引非常有效
特大型的表，建立和使用索引的代价随着增长，可以使用分区技术来解决。
索引的类型
索引都是实现在存储引擎层的。
普通索引：最基本的索引，没有任何约束
唯一索引：与普通索引类似，但具有唯一性约束
主键索引：特殊的唯一索引，不允许有空值
组合索引：将多个列组合在一起创建索引，可以覆盖多个列
外键索引：只有InnoDB类型的表才可以使用外键索引，保证数据的一致性、完整性和实现级联操作
全文索引：MySQL自带的全文索引只能用于MyISAM，并且只能对英文进行全文检索，一般使用全文索引引擎
主键索引和唯一索引的区别：
一个表只能有一个主键索引，可以有多个唯一索引
主键索引一定是唯一索引，唯一索引不是主键索引
主键和外键构成参照完整性约束，防止数据不一致
MySQL索引的创建原则
索引并不是越多越好，要根据查询有针对性的创建，考虑在WHERE和ORDER BY命令上涉及的列建立索引，可根据EXPLAIN来查看是否用了索引还是全表扫描
应尽量避免在WHERE子句中对字段进行NULL值判断，否则将导致引擎放弃使用索引而进行全表扫描
使用多列索引必须满足最左匹配.
OR关键字的两个字段必须都是用了索引,该查询才会使用索引.
LIKE关键字匹配’%'开头的字符串,不会使用索引.
值分布很稀少的字段不适合建索引，例如"性别"这种只有两三个值的字段
字符字段只建前缀索引
字符字段最好不要做主键
不用外键，由程序保证约束
尽量不用UNIQUE，由程序保证约束;
使用多列索引时主意顺序和查询条件保持一致，同时删除不必要的单列索引
选择合适的索引列
1）查询频繁的列，在where，group by，order by，on从句中出现的列
2）where条件中<，<=，=，>，>=，between，in，以及like 字符串+通配符（%）出现的列
3）长度小的列，索引字段越小越好，因为数据库的存储单位是页，一页中能存下的数据越多越好
4）离散度大（不同的值多）的列，放在联合索引前面。查看离散度，通过统计不同的列值来实现，count越大，离散程度越高：
表字段的选择
创建表时表字段设计
1.表字段避免null值出现，null值很难查询优化且占用额外的索引空间，推荐默认数字0代替null。
2.尽量使用INT而非BIGINT，如果非负则加上UNSIGNED（这样数值容量会扩大一倍），当然能使用TINYINT、SMALLINT、MEDIUM_INT更好。
3.使用枚举或整数代替字符串类型
4.尽量使用TIMESTAMP而非DATETIME
5.单表不要有太多字段，建议在20以内
6.用整型来存IP
Sql语句编写规范
1.使用limit对查询结果的记录进行限定
2.避免select *，将需要查找的字段列出来
3.使用连接（join）来代替子查询
4.拆分大的delete或insert语句
5.可通过开启慢查询日志来找出较慢的SQL
6.不做列运算：SELECT id WHERE age + 1 = 10，任何对列的操作都将导致表扫描，它包括数据库教程函数、计算表达式等等，查询时要尽可能将操作移至等号右边
7.sql语句尽可能简单：一条sql只能在一个cpu运算；大语句拆小语句，减少锁时间；一条大sql可以堵死整个库
9.不用函数和触发器，在应用程序实现
10.避免%xxx式查询
12.使用同类型进行比较，比如用’123’和’123’比，123和123比
15.列表数据不要拿全表，要使用LIMIT来分页，.每页数量也不要太大
缓存
缓存可以发生的层次：
MySQL内部：在系统调优参数介绍了相关设置]
数据访问层：比如MyBatis针对SQL语句做缓存，而Hibernate可以精确到单个记录，这里缓存的对象主要是持久化对象Persistence Object
应用服务层：这里可以通过编程手段对缓存做到更精准的控制和更多的实现策略，这里缓存的对象是数据传输对象Data Transfer Object
Web层：针对web页面做缓存
浏览器客户端：用户端的缓存
可以根据实际情况在一个层次或多个层次结合加入缓存。这里重点介绍下服务层的缓存实现，目前主要有两种方式：
直写式（Write Through）：在数据写入数据库后，同时更新缓存，维持数据库与缓存的一致性。这也是当前大多数应用缓存框架如Spring Cache的工作方式。这种实现非常简单，同步好，但效率一般。
回写式（Write Back）：当有数据要写入数据库时，只会更新缓存，然后异步批量的将缓存数据同步到数据库上。这种实现比较复杂，需要较多的应用逻辑，同时可能会产生数据库与缓存的不同步，但效率非常高。
缓存集群
如果用户量越来越大，此时你可以不停的加机器，比如说系统层面不停加机器，就可以承载更高的并发请求。然后数据库层面如果写入并发越来越高，就扩容加数据库服务器，通过分库分表是可以支持扩容机器的，如果数据库层面的读并发越来越高，就扩容加更多的从库。
但是这里有一个很大的问题：数据库其实本身不是用来承载高并发请求的，所以通常来说，数据库单机每秒承载的并发就在几千的数量级，而且数据库使用的机器都是比较高配置，比较昂贵的机器，成本很高。如果你就是简单的不停的加机器，其实是不对的。
所以在高并发架构里通常都有缓存这个环节，缓存系统的设计就是为了承载高并发而生。所以单机承载的并发量都在每秒几万，甚至每秒数十万，对高并发的承载能力比数据库系统要高出一到两个数量级。
所以你完全可以根据系统的业务特性，对那种写少读多的请求，引入缓存集群。具体来说，就是在写数据库的时候同时写一份数据到缓存集群里，然后用缓存集群来承载大部分的读请求。这样的话，通过缓存集群，就可以用更少的机器资源承载更高的并发。

4. sql 语句层:结果一样的情况下,采用效率高,速度快节省资源的 sql 语句执行
   查找查询慢的原因
   导致SQL执行慢的原因
   1.硬件问题。如网络速度慢，内存不足，I/O吞吐量小，磁盘空间满了等
   2.没有索引或者索引失效。（一般在互联网公司，DBA会在半夜把表锁了，重新建立一遍索引，因为当你删除某个数据的时候，索引的树结构;就不完整了。所以互联网公司的数据做的是假删除.一是为了做数据分析,二是为了不破坏索引 ）
   3.数据过多（分库分表）
   4.服务器调优及各个参数设置（调整my.cnf）
   找切入点
   1.先观察，开启慢查询日志，设置相应的阈值（比如超过3秒就是慢SQL），在生产环境跑上个一天过后，看看哪些SQL比较慢。
   2.Explain显示mysql如何使用索引和慢SQL分析。比如SQL语句写的烂，索引没有或失效，关联查询太多（有时候是设计缺陷或者不得以的需求）等等。
   Explain 参数: id select子句或操作表的顺序 select_type 查询的类型,主要用于区别普通查询,联合查询,子查询等复杂查询 table 显示一行的数据时关于哪张表的 type 查询类型从最好到最差依次是:system>const>eq_ref>ref>range>index>All,一般情况下,得至少保证达到range级别,最好能达到ref possible_keys 显示可能应用在这张表中的索引,一个或多个,查询到的索引不一定是真正被用到的 key 实际使用的索引,如果为null,则没有使用索引,因此会出现possible_keys列有可能被用到的索引,但是key列为null,表示实际没用索引。 key_len 表示索引中使用的字节数,而通过该列计算查询中使用的 索引长度,在不损失精确性的情况下,长度越短越好,key_len显示的值为索引字段的最大可能长度,并非实际使用长度,即,key_len是根据表定义计算而得么不是通过表内检索出的 .ref 显示索引的哪一列被使用了,如果可能的话是一个常数,哪些列或常量被用于查找索引列上的值 rows 根据表统计信息及索引选用情况,大只估算出找到所需的记录所需要读取的行数 Extra 说明mysql会对数据使用一个外部的索引排序,而不是按照表内的索引顺序进行读取,mysql中无法利用索引完成的排序操作称为”文件排序”
   3.Show Profile是比Explain更近一步的执行细节，可以查询到执行每一个SQL都干了什么事，这些事分别花了多少秒
   4.找DBA或者运维对MySQL进行服务器的参数调优。
   查询sql的优化
   用EXPLAIN或DESCRIBE(简写:DESC)命令分析一条查询语句的执行信息.
   可通过开启慢查询日志来找出较慢的SQL
   不做列运算：SELECT id WHERE age + 1 = 10，任何对列的操作都将导致表扫描，它包括数据库教程函数、计算表达式等等，查询时要尽可能将操作移至等号右边
   sql语句尽可能简单：一条sql只能在一个cpu运算；大语句拆小语句，减少锁时间；一条大sql可以堵死整个库
   不用SELECT *
   OR改写成IN：OR的效率是n级别，IN的效率是log(n)级别，in的个数建议控制在200以内
   不用函数和触发器，在应用程序实现
   避免%xxx式查询
   在MySQL中,尽量使用JOIN来代替子查询.因为子查询需要嵌套查询,嵌套查询时会建立一张临时表,临时表的建立和删除都会有较大的系统开销,而连接查询不会创建临时表,因此效率比嵌套子查询高.
   使用同类型进行比较，比如用’123’和’123’比，123和123比
   尽量避免在WHERE子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描
   对于连续数值，使用BETWEEN不用IN：SELECT id FROM t WHERE num BETWEEN 1 AND 5
   列表数据不要拿全表，要使用LIMIT来分页，每页数量也不要太大
   升级硬件
   Scale up，这个不多说了，根据MySQL是CPU密集型还是I/O密集型，通过提升CPU和内存、使用SSD，都能显著提升MySQL性能
   NoSql
   在MySQL上做Sharding是一种戴着镣铐的跳舞，事实上很多大表本身对MySQL这种RDBMS的需求并不大，并不要求ACID，可以考虑将这些表迁移到NoSQL，彻底解决水平扩展问题，例如：
   日志类、监控类、统计类数据
   非结构化或弱结构化数据
   对事务要求不强，且无太多关联操作的数据
   添加中间表
   对于将大量连接查询的表可以创建中间表,从而减少在查询时造成的连接耗时.
   增加冗余字段
   类似于创建中间表,增加冗余也是为了减少连接查询.

Mysql事务处理
事务（transaction）是作为一个单元的一组有序的数据库操作。如果组中的所有操作都成功，则认为事务成功，即使只有一个操作失败，事务也不成功。如果所有操作完成，事务则提交，其修改将作用于所有其他数据库进程。如果一个操作失败，则事务将回滚，该事务所有操作的影响都将取消。
ACID 四大特性,原子性、隔离性、一致性、持久性。
原子性（Autmic）：事务在执行性，要做到“要么不做，要么全做！”，就是说不允许事务部分得执行。即使因为故障而使事务不能完成，在rollback时也要消除对数据库得影响！
一致性（Consistency）：事务得操作应该使使数据库从一个一致状态转变倒另一个一致得状态！就拿网上购物来说吧，你只有即让商品出库，又让商品进入顾客得购物篮才能构成事务！
隔离性（Isolation）：如果多个事务并发执行，应象各个事务独立执行一样！
持久性（Durability）：一个成功执行得事务对数据库得作用是持久得，即使数据库应故障出错，也应该能够恢复！
MYSQL的事务处理主要有两种方法。
用begin,rollback,commit来实现
a) begin 开始一个事务
b) rollback 事务回滚
c) commit 事务确认
d) rollback和commit不能并列使用，当你同时使用，只有前面的一个有效，而后面的无效，即是你或执行commit或执行rollback
直接用set来改变mysql的自动提交模式
MYSQL默认是自动提交的，也就是你提交一个QUERY，它就直接执行！我们可以通过set autocommit=0 禁止自动提交set autocommit=1 开启自动提交来实现事务的处理。
注意当你用 set autocommit=0 的时候，你以后所有的SQL都将做为事务处理，直到你用commit确认或rollback结束，注意当你结束这个事务的同时也开启了个新的事务！按第一种方法只将当前的作为一个事务！
通用事务例子
这一系列事件是独立于所使用的编程语言，可以建立在任何使用的语言来创建应用程序的逻辑路径。
可以通过使用mysql_query()函数在PHP中执行这些SQL命令。
BEGIN WORK开始事务发出SQL命令
发出一个或多个SQL命令，如SELECT，INSERT，UPDATE或DELETE检查是否有任何错误，一切都依据的需要。如果有任何错误，那么问题ROLLBACK命令，否则发出COMMIT命令。
事务操作
开启事务 START TRANSACTION 或 BEGIN
提交事务（关闭事务） COMMIT
放弃事务（关闭事务） ROLLBACK
折返点 SAVEPOINT adqoo_1
ROLLBACK TO SAVEPOINT adqoo_1
发生在折返点 adqoo_1 之前的事务被提交，之后的被忽略
事务的终止 设置“自动提交”模式
SET AUTOCOMMIT = 0
每条SQL都是同一个事务的不同命令，之间由 COMMIT
ROLLBACK隔开
掉线后，没有 COMMIT 的事务都被放弃
事务锁定模式 系统默认： 不需要等待某事务结束，可直接查询到结果，但不能再进行修改、删除。
缺点：查询到的结果，可能是已经过期的。
优点：不需要等待某事务结束，可直接查询到结果
设定锁定模式
SELECT …… LOCK IN SHARE MODE（共享锁）
查询到的数据，就是数据库在这一时刻的数据（其他已commit事务的结果，已经反应到这里了）
SELECT 必须等待，某个事务结束后才能执行
SELECT …… FOR UPDATE（排它锁）
例如 SELECT * FROM tablename WHERE id<200那么id<200的数据，被查询到的数据，都将不能再进行修改、删除、SELECT …… LOCK IN SHARE MODE操作一直到此事务结束
共享锁 和 排它锁 的区别：在于是否阻断其他客户发出的 SELECT …… LOCK IN SHARE MODE命令
INSERT / UPDATE / DELETE
所有关联数据都会被锁定，加上排它锁
防插入锁
例如 SELECT * FROM tablename WHERE id>200那么id>200的记录无法被插入
死锁
自动识别死锁
先进来的进程被执行，后来的进程收到出错消息，并按ROLLBACK方式回滚
innodb_lock_wait_timeout = n 来设置最长等待时间，默认是50秒
事务隔离模式
SET [SESSION|GLOBAL] TRANSACTION ISOLATION LEVEL
READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE
a) 不带SESSION、GLOBAL的SET命令
只对下一个事务有效
e) SET SESSION
为当前会话设置隔离模式
f) SET GLOBAL
为以后新建的所有MYSQL连接设置隔离模式（当前连接不包括在内）
隔离模式
READ UNCOMMITTED
不隔离SELECT
其他事务未完成的修改（未COMMIT），其结果也考虑在内
READ COMMITTED
把其他事务的 COMMIT 修改考虑在内
同一个事务中，同一 SELECT 可能返回不同结果
REPEATABLE READ（默认）
不把其他事务的修改考虑在内，无论其他事务是否用COMMIT命令提交过
同一个事务中，同一 SELECT 返回同一结果（前提是本事务，不修改）
SERIALIZABLE
和REPEATABLE READ类似，给所有的SELECT都加上了 共享锁
出错处理
根据出错信息，执行相应的处理