mysql事务

我们知道，在关系数据库标准中有四个事务隔离级别： 未提交读(Read Uncommitted)：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据 提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 可重复读(Repeated Read)：可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读 串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞 查看InnoDB系统级别的事务隔离级别： 以下为引用的内容： mysql> SELECT @@global.tx_isolation; +-----------------------+ | @@global.tx_isolation | +-----------------------+ | REPEATABLE-READ　　　| +-----------------------+ 1 row in set (0.00 sec) 查看InnoDB会话级别的事务隔离级别： 以下为引用的内容： mysql> SELECT @@tx_isolation; +-----------------+ | @@tx_isolation　| +-------------

★　 脏读　　　　： 读取了前一事务 未提交 的数据 ; 　　不可重复读 ： 读取了前一事务 提交 的数据； ★　幻读 与 不可重复读　　　　 　　common　　：都是读取了另一条已经提交的事务（这点与脏读不同）； 　　differences ： 　　　　不可重复读 ：查询的都是同一个数据项 　　　　幻读 　　 ：针对的是一批数据整体（比如数据的个数） 不可重复读eg: 　　< 当隔离级别设置为Repeatable read 时，可以避免不可重复读 > 　　eg2: 在事务A中，读取到张三的工资为5000，操作没有完成，事务还没提交。 　　　　与此同时，事务B把张三的工资改为8000，并提交了事务。 　　　　随后，在事务A中，再次读取张三的工资，此时工资变为8000。在一个事务中前后两次读取的结果并不致，导致了不可重复读。(大部分数据库缺省的事物隔离级别都不会出现这种状况) 幻读eg: 　　eg1: 目前工资为5000的员工有10人，事务A读取所有工资为5000的人数为10人。 　　　　此时，事务B插入一条工资也为5000的记录，并且commit了。 　　　　这时，事务A再次读取工资为5000的员工，记录为11人。此时产生了幻读。 　　　　(大部分数据库缺省的事物隔离级别都会出现这种状况，此种事物隔离级别将带来表级锁) 　　eg2：

参考资料 一、视图 视图的含义： 视图是一个虚拟表，是从数据库中一个或者多个表中导出来的表。 1、创建视图 #语法：CREATE VIEW 视图名称 AS SQL语句 create view teacher_view as select tid from teacher where tname='李平老师'; #于是查询李平老师教授的课程名的sql可以改写为 mysql> select cname from course where teacher_id = (select tid from teacher_view); +--------+ | cname | +--------+ | 物理 | | 美术 | +--------+ rows in set (0.00 sec) #！！！注意注意注意： #1. 使用视图以后就无需每次都重写子查询的sql，但是这么效率并不高，还不如我们写子查询的效率高 #2. 而且有一个致命的问题：视图是存放到数据库里的，如果我们程序中的sql过分依赖于数据库中存放的视图， 那么意味着，一旦sql需要修改且涉及到视图的部分，则必须去数据库中进行修改，而通常在公司中数据库有专门的DBA负责， 你要想完成修改，必须付出大量的沟通成本DBA可能才会帮你完成修改，极其地不方便 2、查看视图 select * from course_view; create

事务 概念 事务由单独单元的一个或多个SQL语句组成，在这 个单元中，每个MySQL语句是相互依赖的。 而整个单独单 元作为一个不可分割的整体，如果单元中某条SQL语句一 旦执行失败或产生错误，整个单元将会回滚。所有受到影 响的数据将返回到事物开始以前的状态；如果单元中的所 有SQL语句均执行成功，则事物被顺利执行。 存储引擎 概念 在mysql中的数据用各种不同的技术存储 在文件（或内存）中。 查看 通过 show engines； 来查看mysql支持的存储引擎。 常见引擎 在mysql中用的最多的存储引擎有：innodb， myisam ,memory 等。其中innodb支持事务，而 myisam、memory等不支持事务。 事务特点 事务的ACID(acid)属性 1. 原子性（Atomicity） 原子性是指事务是一个不可分割的工作单位，事务中的操作要么 都发生，要么都不发生。 2. 一致性（Consistency） 事务必须使数据库从一个一致性状态变换到另外一个一致性状态 。 3. 隔离性（Isolation） 事务的隔离性是指一个事务的执行不能被其他事务干扰，即一个 事务内部的操作及使用的数据对并发的其他事务是隔离的，并发 执行的各个事务之间不能互相干扰。 4. 持久性（Durability） 持久性是指一个事务一旦被提交，它对数据库中数据的改变就是 永久性的

mysql的存储引擎架构把查询处理及其他系统任务和数据的存储/提取相分离 1.1 mysql逻辑架构 　　第一层：链接处理、授权认证、安全等大多数基于网络的工具或者服务都有类似的架构 　　第二层：核心服务，查询解析、分析、优化、缓存、所有的内置函数（日期、时间等），所有跨存储引擎的功能，存储过程、触发器、视图等 　　第三层：存储引擎，负责数据的存储和提取 　　1.1.1 连接管理与安全性 　　　　每个客户端连接都会在服务器进程中拥有一个线程，服务器会缓存线程， 　　1.1.2 优化与执行 　　　　mysql会解析查询，并创建解析书，然后优化。 　　　　在查询之前，会先检查查询缓存 1.2 并发控制 　　1.2.1 读写锁 　　　　读锁和写锁 　　　　1.2.2 锁颗粒 　　　　　　表锁： 　　　　　　行级锁：可以最大程度的支持并发，只在存储引擎层实现 1.3 事务 　　原子性、一致性、隔离性、持久性 　　1.3.1 隔离级别 　　　　未提交读：事务的修改，即使没有提交，对其他事务也都是可见的。脏读 　　　　提交读：一个事务只能看见已经提交的事务的修改。不可重复读 　　　　可重复读：保证了同一个事务中多次读取同样记录的结果是一致的，mvcc，mysql默认隔离级别 　　　　可串行化：强制事务串行执行 　　1.3.2 死锁 　　　　各种死锁检测和死锁超时机制

简述项目中优化sql语句执行效率的方法，从哪些方面，sql语句性能如何分析？ （1）尽量选择较小的列； （2）将where中用的比较频繁的字段建立索引； （3）select中避免使用*； （4）避免在索引列上使用计算、not in和<>等操作； （5）当只需要一行数据时候使用limit1； （6）保证单表数据不超过200w，实时分割表； 针对查询较慢的语句，可以使用explain来分析该语句具体的执行情况。 sql语句应考虑哪些安全性？ （1）少使用root账户，应该为不同的动作分配不同的账户； （2）sql执行出错后，不能把数据库中显示的出错信息，直接展示给用户。防止泄露服务器和数据库相关信息； （3）防止sql注入，对特殊字符进行转义、过滤或者使用预编译的sql语句绑定变量 接下来重点说下Mysql半同步复制， 从MySQL5.5开始，MySQL以插件的形式支持半同步复制 。先来区别下mysql几个同步模式概念： 异步复制（Asynchronous replication） MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。 全同步复制（Fully synchronous

MySQL 5.5 Semi Sync Replication 2009-12-16 | 23:48分类： MySQL | 标签： MySQL5.5 、 Replication 、 semi-sync 、 semi-sync replication | 今天看到MySQL5.5放出了第一个版本 MySQL 5.5 Community Edition - Milestone Release ，最大的增强莫过于加入了 Semi Sync Replication 的支持（虽然仍不完善）。 这里做一个科普，简单介绍一下Semisynchronous Replication： 1. Why Semisynchronous Replication? 之前版本的MySQL Replication都是异步（asynchronous）的，主库在执行完一些事务后，是不会管备库的进度的。如果备库不幸落后，而更不幸的是主库此时又出现Crash（例如宕机），这时备库中的数据就是不完整的。简而言之，在主库发生故障的时候，我们无法使用备库来继续提供数据一致的服务了。 Semisynchronous Replication则一定程度上保证提交的事务已经传给了至少一个备库。 2. 为什么是Semi synchronous而不是Full synchronous？ Semi synchronous中

一、概述 5.5与5.7的半同步复制可能存在差异，从MySQL5.5开始，MySQL以插件的形式支持半同步复制 异步 ：默认情况下，MySQL复制是异步的。主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理。此时若是主若是崩溃了，那提交完成的事务可能并没有传到从上，从而导致数据不一致。 全同步 ：当主库执行完接受到的事务，会等待所有从机执行此事务的返回值，当收到所有从机的返回值时才会返回给客户端。所以对性能的影响严重。 半同步 ：介于以上两者之间，主库在执行完客户端的事务后，会等待至少一个从机接收到并写入relay log中才会返回给客户端。它提高了数据的安全性， 也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。 relay log中继日志 ：在salve中IO线程会拉去master的二进制到relay log中，然后SQL线程会读取relay-log日志的内容并应用到从服务器。 两个插件实现半同步功能。主端有一个插件，从端有一个插件。 半同步复制必须在主和从都有启用，否则使用异步复制。 只有事件写入中继日志并且刷新到磁盘后，从设备才会确认收到事务的事件。 如果无任何从服务器确认事务的情况下发生超时，主服务器将恢复异步复制。当至少一个半同步丛机赶上，主机将返回到半同步复制。 After

复制架构衍生史 在谈这个特性之前，我们先来看看MySQL的复制架构衍生史。 MySQL的复制分为四种： 普通的replication，异步同步。 搭建简单，使用非常广泛，从mysql诞生之初，就产生了这种架构，性能非常好，可谓非常成熟。 但是这种架构数据是异步的，所以有丢失数据库的风险。 semi-sync replication，半同步。性能，功能都介于异步和全同步中间。从mysql5.5开始诞生，目的是为了折中上述两种架构的性能以及优缺点。 sync replication，全同步。目前官方5.7基于Group replication的全同步技术处在labs版本，离正式集成已经不远。全同步技术带来了更多的数据一致性保障。相信是未来同步技术一个重要方向，值得期待。 mysql cluster。 基于NDB引擎，搭建也简单，本身也比较稳定，是mysql里面对数据保护最靠谱的架构，也是目前唯一一个数据完全同步的架构，数据零丢失。不过对业务比较挑剔，限制也较多。 半同步复制 我们今天谈论第二种架构。我们知道，普通的replication，即mysql的异步复制，依靠mysql二进制日志也即binary log进行数据复制。比如两台机器，一台主机(master)，另外一台是从机(slave)。 正常的复制为：事务一（t1）写入binlog buffer；dumper

目录 复习 联合分组 子查询 all与any：区间修饰条件 视图：view 视图的增删改 事务 复习 """ 1、单表查询 增删改查的完整语法 select distinct 字段 from 表 where group by having order by limit 比较：> < = 区间：between and | in | not in 逻辑: and or not 相似：like _% 正则：regexp 聚合函数：group_concat()、max() having：可以对 聚合函数 结果进行筛选，不能使用 聚合函数 别名 order by：分组后对 聚合函数 进行排序，能使用 聚合函数 别名 limit：条数 | 偏移,条数 2、多表查询 内连接：from emp inner join dep on emp.dep_id = dep.id 只保存两表有对应关系的记录 左连接：from emp left join dep on emp.dep_id = dep.id 左表记录全部保存，右边没有对应记录空填充 右连接：from emp right join dep on emp.dep_id = dep.id 右表记录全部保存，左边没有对应记录空填充 全连接： from emp left join dep on emp.dep_id = dep.id union from