MySQL事务优化

====================
事务特性

事务隔离级别

事务控制语句

MySQL优化
====================

事务的概念

事务指逻辑上的一组操作，组成这组操作的各个单元，要么全部成功，要么全部不成功。

例如：A——B转帐，对应于如下两条sql语句

update from account set money=money-100 where name=‘a’;

update from account set money=money+100 where name=‘b’;

数据库开启事务命令

start transaction 开启事务

rollback 回滚事务

commit 提交事务

事务的特性(ACID)

原子性（Atomicity）原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。 

一致性（Consistency）事务必须使数据库从一个一致性状态变换到另外一个一致性状态。

隔离性（Isolation）事务的隔离性是多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离。

持久性（Durability）持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。

事务的隔离级别

多个线程开启各自事务操作数据库中数据时，数据库系统要负责隔离操作，以保证各个线程在获取数据时的准确性。

如果不考虑隔离性，可能会引发如下问题：

脏读：指一个事务读取了另外一个事务未提交的数据。 这是非常危险的，假设Ａ向Ｂ转帐100元，对应sql语句如下所示

1.update account set money=money+100 while name=‘b’;

2.update account set money=money-100 while name=‘a’;

不可重复读：在一个事物内读取表中的某一行数据，多次读取结果不同。

例如银行想查询A帐户余额，第一次查询A帐户为200元，此时A向帐户内存了100元并提交了，银行接着又进行了一次查询，此时A帐户为300元了。银行两次查询不一致，可能就会很困惑，不知道哪次查询是准的。

和脏读的区别是，脏读是读取前一事务未提交的脏数据，不可重复读是重新读取了前一事务已提交的数据。

很多人认为这种情况就对了，无须困惑，当然是后面的为准。我们可以考虑这样一种情况，比如银行程序需要将查询结果分别输出到电脑屏幕和写到文件中，结果在一个事务中针对输出的目的地，进行的两次查询不一致，导致文件和屏幕中的结果不一致，银行工作人员就不知道以哪个为准了。

虚读/幻读是指在一个事务内读取到了别的事务插入的数据，导致前后读取不一致。

如丙存款100元未提交，这时银行做报表统计account表中所有用户的总额为500元，然后丙提交了，这时银行再统计发现帐户为600元了，造成虚读同样会使银行不知所措，到底以哪个为准。

事务隔离性的设置语句

数据库共定义了四种隔离级别：

Serializable：可避免脏读、不可重复读、虚读情况的发生。（串行化）

Repeatable read：可避免脏读、不可重复读情况的发生。（可重复读）

Read committed：可避免脏读情况发生（读已提交）。

Read uncommitted：最低级别，以上情况均无法保证。(读未提交)

set transaction isolation level 设置事务隔离级别

select @@tx_isolation 查询当前事务隔离级别

MySQL优化

系统优化：硬件、架构

服务优化

应用优化

影响性能的因素：

应用程序、查询、事务管理、数据库设计、数据分布、网络操作系统、硬件

系统优化：

1、硬件优化

cpu 64位 一台机器8-16颗CPU 内存 96-128G 3-4个实例

硬盘：数量越多越好

性能：ssd（高并发业务） > sas （普通业务）>sata（线下业务） raid 4块盘，性能 raid0 > raid10 > raid5 > raid1

网卡：多块网卡bond

2、软件优化 操作系统：使用64位系统 软件：MySQL 编译优化

服务优化：

MySQL配置原则

配置合理的MySQL服务器，尽量在应用本身达到一个MySQL最合理的使用

针对 MyISAM 或 InnoDB 不同引擎进行不同定制性配置

针对不同的应用情况进行合理配置针对 my.cnf 进行配置，后面设置是针对内存为2G的服务器进行的合理设置

公共选项

选项	缺省值	推荐值	说明
max_connections	100	1024	MySQL服务器同时处理的数据库连接的最大数量
query_cache_size	0 (不打开）	16M	查询缓存区的最大长度，按照当前需求，一倍一倍增加，本选项比较重要
sort_buffer_size	512K	16M	每个线程的排序缓存大小，一般按照内存可以设置为2M以上，推荐是16M，该选项对排序order by，group by起作用
record_buffer	128K	16M	每个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区，可以设置为2M以上
table_cache	64	512	为所有线程打开表的数量。增加该值能增加mysqld要求的文件描述符的数量。MySQL对每个唯一打开的表需要2个文件描述符。

MyISAM 选项

选项	缺省值	推荐值	说明
key_buffer_size	8M	256M	用来存放索引区块的缓存值, 建议128M以上，不要大于内存的30%
read_buffer_size	128K	16M	用来做MyISAM表全表扫描的缓冲大小. 为从数据表顺序读取数据的读操作保留的缓存区的长度
myisam_sort_buffer_size	16M	128M	设置,恢复,修改表的时候使用的缓冲大小，值不要设的太大

InnoDB 选项

选项	缺省值	推荐值	说明
innodb_buffer_pool_size	32M	1G	InnoDB使用一个缓冲池来保存索引和原始数据, 这里你设置越大,你在存取表里面数据时所需要的磁盘I/O越少，一般是内存的一半，不超过2G，否则系统会崩溃，这个参数非常重要
innodb_additional_mem_pool_size	2M	128M	InnoDB用来保存 metadata 信息, 如果内存是4G，最好本值超过200M
innodb_flush_log_at_trx_commit	1	0	0 代表日志只大约每秒写入日志文件并且日志文件刷新到磁盘; 1 为执行完没执行一条SQL马上commit; 2 代表日志写入日志文件在每次提交后,但是日志文件只有大约每秒才会刷新到磁盘上. 对速度影响比较大，同时也关系数据完整性
innodb_log_file_size	8M	256M	在日志组中每个日志文件的大小, 一般是innodb_buffer_pool_size的25%，官方推荐是 innodb_buffer_pool_size 的 40-50%, 设置大一点来避免在日志文件覆写上不必要的缓冲池刷新行为
innodb_log_buffer_size	128K	8M	用来缓冲日志数据的缓冲区的大小. 推荐是8M，官方推荐该值小于16M，最好是 1M-8M 之间

应用优化：

设计合理的数据表结构：

适当的数据冗余对数据表建立合适有效的数据库索引数据查询：

编写简洁高效的SQL语句

表结构设计原则

选择合适的数据类型，如果能够定长尽量定长

使用 ENUM 而不是 VARCHAR,ENUM类型是非常快和紧凑的，在实际上，其保存的是 TINYINT，但其外表上显示为字符串。这样一来，用这个字段来做一些选项列表变得相当的完美 。

不要使用无法加索引的类型作为关键字段，比如 text类型

为了避免联表查询，有时候可以适当的数据冗余，比如邮箱、姓名这些不容易更改的数据

选择合适的表引擎，有时候 MyISAM 适合，有时候InnoDB适合

为保证查询性能，最好每个表都建立有 auto_increment 字段， 建立合适的数据库索引

最好给每个字段都设定 default 值

索引建立原则

一般针对数据分散的关键字进行建立索引，比如ID、QQ，像性别、状态值等等建立索引没有意义字段唯一，最少，不可为null

对大数据量表建立聚集索引，避免更新操作带来的碎片。

尽量使用短索引，一般对int、char/varchar、date/time 等类型的字段建立索引

需要的时候建立联合索引，但是要注意查询SQL语句的编写

谨慎建立 unique 类型的索引（唯一索引）

大文本字段不建立为索引，如果要对大文本字段进行检索， 可以考虑全文索引

频繁更新的列不适合建立索引

order by 字句中的字段，where 子句中字段，最常用的sql语句中字段，应建立索引。

唯一性约束，系统将默认为改字段建立索引。

对于只是做查询用的数据库索引越多越好，但对于在线实时系统建议控制在5个以内。

索引不仅能提高查询SQL性能，同时也可以提高带where字句的update，Delete SQL性能。

Decimal 类型字段不要单独建立为索引，但覆盖索引可以包含这些字段。

只有建立索引以后，表内的行才按照特地的顺序存储，按照需要可以是asc或desc方式。

如果索引由多个字段组成将最用来查询过滤的字段放在前面可能会有更好的性能。

编写高效的 SQL

能够快速缩小结果集的 WHERE 条件写在前面，如果有恒量条件，也尽量放在前面

尽量避免使用 GROUP BY、DISTINCT 、OR、IN 等语句的使用，避免使用联表查询和子查询，因为将使执行效率大大下降

能够使用索引的字段尽量进行有效的合理排列，如果使用了联合索引，请注意提取字段的前后顺序

针对索引字段使用 >, >=, =, <, <=, IF NULL和BETWEEN 将会使用索引，如果对某个索引字段进行 LIKE 查询，使用 LIKE ‘%abc%’不能使用索引，使用 LIKE ‘abc%’ 将能够使用索引

如果在SQL里使用了MySQL部分自带函数，索引将失效，同时将无法使用 MySQL 的 Query Cache，比如 LEFT(), SUBSTR(), TO_DAYS()，DATE_FORMAT(), 等，如果使用了 OR 或 IN，索引也将失效

使用 Explain 语句来帮助改进我们的SQL语句

不要在where 子句中的“=”左边进行算术或表达式运算，否则系统将可能无法正确使用索引

尽量不要在where条件中使用函数，否则将不能使用索引

避免使用 select *, 只取需要的字段

对于大数据量的查询，尽量避免在SQL语句中使用order by 字句，避免额外的开销，替代为使用ADO.NET 来实现。

如果插入的数据量很大，用select into 替代 insert into 能带来更好的性能

采用连接操作，避免过多的子查询，产生的CPU和IO开销

只关心需要的表和满足条件的数据

适当使用临时表或表变量

对于连续的数值，使用between代替in

where 字句中尽量不要使用CASE条件

尽量不用触发器，特别是在大数据表上

更新触发器如果不是所有情况下都需要触发，应根据业务需要加上必要判断条件

使用union all 操作代替OR操作，注意此时需要注意一点查询条件可以使用聚集索引，如果是非聚集索引将起到相反的结果

当只要一行数据时使用 LIMIT 1

尽可能的使用 NOT NULL填充数据库

拆分大的 DELETE 或 INSERT 语句

批量提交SQL语句

架构优化

1）业务拆分：搜索功能，like ，前后都有%，一般不用MySQL数据库

2）业务拆分：某些应用使用nosql持久化存储，例如memcahcedb、redis、ttserver 比如粉丝关注、好友关系等；

3）数据库前端必须要加cache，例如memcached，用户登录，商品查询

4）动态数据静态化。整个文件静态化，页面片段静态化

5）数据库集群与读写分离；

6）单表超过2000万，拆库拆表，人工或自动拆分（登录、商品、订单等）

流程、制度、安全优化

任何一次人为数据库记录的更新，都要走一个流程

1）人的流程：开发-->核心开发-->运维或DBA

2）测试流程：内网测试-->IDC测试-->线上执行

3）客户端管理：phpmyadmin等