mysql事务

MySQL数据库设计规范 目录 1. 规范背景与目的 2. 设计规范 2.1 数据库设计 2.1.1 库名 2.1.2 表结构 2.1.3 列数据类型优化 2.1.4 索引设计 2.1.5 分库分表、分区表 2.1.6 字符集 2.1.7 程序DAO层设计建议 2.1.8 一个规范的建表语句示例 2.2 SQL编写 2.2.1 DML语句 2.2.2 多表连接 2.2.3 事务 2.2.4 排序和分组 2.2.5 线上禁止使用的SQL语句 1. 规范背景与目的 MySQL数据库与 Oracle、 SQL Server 等数据库相比，有其内核上的优势与劣势。我们在使用MySQL数据库的时候需要遵循一定规范，扬长避短。本规范旨在帮助或指导RD、QA、OP等技术人员做出适合线上业务的数据库设计。在数据库变更和处理流程、数据库表设计、SQL编写等方面予以规范，从而为公司业务系统稳定、健康地运行提供保障。 2. 设计规范 2.1 数据库设计 以下所有规范会按照【高危】、【强制】、【建议】三个级别进行标注，遵守优先级从高到低。 对于不满足【高危】和【强制】两个级别的设计，DBA会强制打回要求修改。 2.1.1 库名 【强制】库的名称必须控制在32个字符以内，相关模块的表名与表名之间尽量提现join的关系，如user表和user_login表。 【强制】库的名称格式：业务系统名称_子系统名

mysql补充 mysql使用流程 开启服务端，mysqld或者net start mysql cmd下键入mysql -u root -p，输入设置好的密码，连接mysql客户端 show databases；展示所有的mysql仓库 创建一个库：create database CRM；然后show databases； 切换数据库使用use + 库名，例如：use crm； 在切换仓库下创建一张表，命令：create table student(id int,name char(10),age int); 再执行show tables;就可以看到有了一个student表 查看一下这个表里的数据select * from student； 接下来正常执行表的增删查改操作即可 mysql目录介绍 总结：其实这些库就是我们电脑上对应的文件夹，在mysql中显示为对应的库，来方便我们管理数据，而文件或者文件夹这种与硬盘打交道的事情就交给mysql了，我们只需要对mysql库中的数据进行操作就可以了 指令补充 show variables like "%char%"; # 查看字符集编码指令 mysql -h 127.0.0.1 -P 3306 -u root -p # MySQL客户端连接服务端时的完整指令 show variables like "storage_engine%";

mysql数据库，当且仅当引擎是InnoDB，才支持事务； 1、隔离级别 事务的隔离级别分为： 未提交读 (read uncommitted)、 已提交读 (read committed)、 可重复读 (repeatable read)、 串行化 (serializable)。 未提交读 A事务已执行，但未提交；B事务查询到A事务的更新后数据；A事务回滚；---出现脏数据 已提交读 A事务执行更新；B事务查询；A事务又执行更新；B事务再次查询时，前后两次数据不一致；---不可重复读 可重复读 A事务无论执行多少次，只要不提交，B事务查询值都不变；B事务仅查询B事务开始时那一瞬间的数据快照； 串行化 不允许读写并发操作，写执行时，读必须等待； 2、数据库设置 //查看当前事物级别： SELECT @@tx_isolation; //设置mysql的隔离级别： set session transaction isolation level 设置事务隔离级别 //设置read uncommitted级别： set session transaction isolation level read uncommitted; //设置read committed级别： set session transaction isolation level read committed; /

对于一个MYSQL数据库（InnoDB），事务的开启与提交模式无非下面这两种情况： 1>若参数autocommit=0，事务则在用户本次对数据进行操作时自动开启，在用户执行commit命令时提交，用户本次对数据库开始进行操作到用户执行commit命令之间的一系列操作为一个完整的事务周期。若不执行commit命令，系统则默认事务回滚。总而言之，当前情况下事务的状态是自动开启手动提交。 2>若参数autocommit=1（系统默认值），事务的开启与提交又分为两种状态： ①手动开启手动提交：当用户执行start transaction命令时（事务初始化），一个事务开启，当用户执行commit命令时当前事务提交。从用户执行start transaction命令到用户执行commit命令之间的一系列操作为一个完整的事务周期。若不执行commit命令，系统则默认事务回滚。 ②自动开启自动提交：如果用户在当前情况下（参数autocommit=1）未执行start transaction命令而对数据库进行了操作，系统则默认用户对数据库的每一个操作为一个孤立的事务，也就是说用户每进行一次操作系都会即时提交或者即时回滚。这种情况下用户的每一个操作都是一个完整的事务周期。 来源： https://my.oschina.net/mskk/blog/3099649

1.储存引擎解释 首先确定一点，存储引擎的概念是MySQL里面才有的，不是所有的关系型数据库都有存储引擎这个概念，后面我们还会说，但是现在要确定这一点。　　 　　在讲清楚什么是存储引擎之前，我们先来个比喻，我们都知道录制一个视频文件，可以转换成不同的格式，例如mp4，avi，wmv等，而存在我们电脑的磁盘上也会存在于不同类型的文件系统中如windows里常见的ntfs、fat32，存在于linux里常见的ext3，ext4，xfs，但是，给我们或者用户看懂实际视频内容都是一样的。直观区别是，占用系统的空间大小与清晰程度可能不一样。 那么数据库表里的数据存储在数据库里及磁盘上和上述的视频格式及存储磁盘文件的系统格式特征类似，也有很多种存储方式。 　　但是对于用户和应用程序来说同样一张表的数据，无论用什么引擎来存储，用户能够看到的数据是一样的。不同储引擎存取，引擎功能，占用空间大小，读取性能等可能有区别。说白了，存储引擎就是在如何存储数据、提取数据、更新数据等技术方法的实现上，底层的实现方式不同，那么就会呈现出不同存储引擎有着一些自己独有的特点和功能，对应着不同的存取机制。 　　因为在关系数据库中数据的存储是以表的形式存储的，所以存储引擎也可以称为表类型(即：对表的存储、操作等的实现方法不同)，表是什么，表本质上就是磁盘上的文件。 　　其实MySQL支持多种存储引擎

一个设计良好的数据库可以帮我们保证事务具有四大特性(ACID)： 原子性：原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。 一致性：如果事务执行之前数据库是一个完整的状态，那么事务结束后，无论事务是否执行成功，数据库仍然是一个完整的状态。 　　数据库的完整状态：当一个数据库中的所有的数据都符合数据库中所定义的所有约束，此时可以称数据库是一个完整的状态。 隔离型：多个用户并发访问数据库时，一个用户的事务不能被其他用户的事务所干扰，多个并发事务之间数据要相互隔离。 持久性：指一个事务一旦被提交，他对数据库的影响是永久性的。 数据库可以保证原子性，一致性，持久性。但是隔离级别需要根据并发情况进行设置， 将数据库设计成单线程，可以防止所有的线程安全问题，自然也就保证了隔离型的问题，但是如果这样，那么效率就会极其低下。 如果两个线程并发修改，一定会相互捣乱，这时必须利用锁机制防止多个线程的并发修改 如果两个线程并发查询，没有线程安全问题。 如果两个线程一个修改，一个查询： 　　四大隔离级别： 　　Read uncommitted:---不防止任何隔离型问题，不能防止脏读/不可重复读/幻读问题。 　　Read commit:---可以防止脏读问题，但是不能防止 不可重复读/幻读问题。(oracle默认隔离级别) 　　Repeatable read:--

锁 (Lock) 锁是一种保证数据安全的机制和手段，其并不是特定于某项技术的，其主要是通过在并发下控制多个操作的顺序执行，以此来保证数据安全地变动 例如在程序中，当多个线程修改共享变量时，可以给修改操作上锁 (syncronized) ；在数据库中，当多个用户修改表中同一数据时，我们可以给该行数据上锁 悲观锁 (Pessimistic Concurrency Control) 总是假设最坏的情况，每次取数据的时候都认为别人会修改，所以每次取数据都会加锁。这样别人在操作这条数据的时候，如果没有拿到锁，就会发生阻塞，操作就无法执行。 数据库中的行锁，表锁，读锁，写锁等都是悲观锁 乐观锁 (Optimistic Concurrency Control) 总是假设最好的情况，每次取数据的时候都认为别人不会修改数据，所以不对数据加锁。但是会在更新的时候判断一下在此期间别人有没有更新这个数据，判断可以使用版本号机制和 CAS 算法实现。 乐观锁通常是通过在表中增加一个版本 (version) 或时间戳 (timestamp) 来实现，其中版本最为常用． 事务从数据库中取数据时，会将该数据的版本也取出来 (v1) ，当事务对数据变动完毕需要提交至数据库时，会将之前取出的 v1 与数据的最新版本 v2 进行对比 v1 = v2 ：说明数据变动期间没有其他事务对该数据进行修改

Reference： https://time.geekbang.org/column/article/117247 死锁产生 行锁的具体实现算法有三种：record lock、gap lock以及next-key lock。 record lock是专门对索引项加锁； gap lock是对索引项之间的间隙加锁； next-key lock则是前面两种的组合，对索引项及其之间的间隙加锁。 只在可重复读或以上隔离级别下的特定操作才会取得gap lock或next-key lock，在Select、Update和Delete时，除了基于唯一索引的查询之外，其它索引查询时都会获取gap lock或next-key lock，即锁住其扫描的范围。主键索引也属于唯一索引，所以主键索引是不会使用gap lock或next-key lock。 在MySQL中，gap lock默认是开启的，即innodb_locks_unsafe_for_binlog参数值是disable的，且MySQL中默认的是RR事务隔离级别。 当执行以下查询SQL时，由于order_no列为非唯一索引，此时又是RR事务隔离级别，所以SELECT的加锁类型为gap lock，这里的gap范围是(4,+∞）。 1 SELECT id FROM demo.order_record where order_no = 4 for

目录 一 存储引擎解释 二 MySQL存储引擎分类 三 存储引擎的使用 一 存储引擎解释 　　首先确定一点，存储引擎的概念是MySQL里面才有的，不是所有的关系型数据库都有存储引擎这个概念，后面我们还会说，但是现在要确定这一点。　　 　　在讲清楚什么是存储引擎之前，我们先来个比喻，我们都知道录制一个视频文件，可以转换成不同的格式，例如mp4，avi，wmv等，而存在我们电脑的磁盘上也会存在于不同类型的文件系统中如windows里常见的ntfs、fat32，存在于linux里常见的ext3，ext4，xfs，但是，给我们或者用户看懂实际视频内容都是一样的。直观区别是，占用系统的空间大小与清晰程度可能不一样。 那么数据库表里的数据存储在数据库里及磁盘上和上述的视频格式及存储磁盘文件的系统格式特征类似，也有很多种存储方式。 　　但是对于用户和应用程序来说同样一张表的数据，无论用什么引擎来存储，用户能够看到的数据是一样的。不同储引擎存取，引擎功能，占用空间大小，读取性能等可能有区别。说白了，存储引擎就是在如何存储数据、提取数据、更新数据等技术方法的实现上，底层的实现方式不同，那么就会呈现出不同存储引擎有着一些自己独有的特点和功能，对应着不同的存取机制。 　　因为在关系数据库中数据的存储是以表的形式存储的，所以存储引擎也可以称为表类型(即：对表的存储、操作等的实现方法不同)，表是什么

默认情况下，innodb的参数设置的非常小，在生产环境中远远不够用 比如最重要的两个参数 innodb_buffer_pool_size 默认是8M innodb_flush_logs_at_trx_commit 默认设置的是1 也就是同步刷新log(可以这么理解) innodb_buffer_pool_size： 这是InnoDB最重要的设置，对InnoDB性能有决定性的影响。默认的设置只有8M，所以默认的数据库设置下面InnoDB性能很差。在只有 InnoDB存储引擎的数据库服务器上面，可以设置60-80%的内存。更精确一点，在内存容量允许的情况下面设置比InnoDB tablespaces大10%的内存大小。 innodb_data_file_path：指定表数据和索引存储的空间，可以是一个或者 多个文件。最后一个数据文件必须是自动扩充的，也只有最后一个文件允许自动扩充。这样，当空间用完后，自动扩充数据文件就会自动增长（以8MB为单位）以 容纳额外的数据。例如： innodb_data_file_path=/disk1 /ibdata1:900M;/disk2/ibdata2:50M:autoextend两个数据文件放在不同的磁盘上。数据首先放在ibdata1 中，当达到900M以后，数据就放在ibdata2中。一旦达到50MB，ibdata2将以8MB为单位自动增长