mysql事务

MySQL 就是其中之一，它经历了多个版本迭代。数据库锁是 MySQL 数据引擎的一部分，今天我们就一起来学习 MySQL 的数据库锁和它的优化。 MySQL 锁分类 当多个事务或者进程访问同一个资源的时候，为了保证数据的一致性，就需要用到锁机制。 从锁定资源的角度来看，MySQL 中的锁分为： 表级锁 行级锁 页面锁 表级锁：对整张表加锁。开销小，加锁快;不会出现死锁;锁定粒度大，发生锁冲突的概率最高，并发度最低。 行级锁：对某行记录加锁。开销大，加锁慢;会出现死锁;锁定粒度最小，发生锁冲突的概率最低，并发度也最高。 页面锁：开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间，并发度一般。 在实际开发过程中，主要会使用到表级锁和行级锁两种。既然锁是针对资源的，那么这些资源就是数据，在 MySQL 提供插件式存储引擎对数据进行存储。 插件式存储引擎的好处是，开发人员可以根据需要选择适合的存储引擎。 在众多的存储引擎中，有两种引擎被比较多的使用，他们分别是： MyISAM 存储引擎，它不支持事务、表锁设计，支持全文索引，主要面向一些在线分析处理(OLAP)数据库应用。说白了主要就是查询数据，对数据的插入，更新操作比较少。 InnoDB 存储引擎，它支持事务，其设计目标主要面向在线事务处理(OLTP)的应用。 其特点是行锁设计、支持外键，并支持类似于 Oracle

问题 项目里面使用的是 mycat 进行分库分表，但在最近一个系统更新后出现数据库事务锁超时的问题，如下面的错误: 1 Caused by: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction 分析 先在网上搜索了一下之后，发现大多数说的都不是什么好的解决方案，手动kill掉事务，把事务超时时间加长，这些对我现在这个项目都不实际，还是自己分析吧。 对数据库的配置检查了一番，没什么问题，并没有什么更新，然后就对程序进行分析，这个错误是在一次系统更新后才出现的，对这次更新进行了分析，发现频繁超时的那个更新操作去掉了一个分片id参数，比如之前是这样： 1 update update_date = now() where xxx_id = 123 and sharding_id = 23; 这次更新后的操作就是这样子了: 1 update update_date = now() where xxx_id = 123; 分析了一下这个操作， xxx_id 只是一个普通的字段，然而这个操作会锁住所有分片下的表，而加了分片id之后只是锁住了指定分片的那张表。我们使用的是MySQL innoDB引擎，所以，把这个操作变成行锁就好了。 解决方案 MySQL innoDB引擎行锁是建立在索引上的

先简单梳理下Mysql的基本概念，然后分创建时和查询时这两个阶段的优化展开。 1 基本概念简述 1.1 逻辑架构 第一层：客户端通过连接服务，将要执行的sql指令传输过来 第二层：服务器解析并优化sql，生成最终的执行计划并执行 第三层：存储引擎，负责数据的储存和提取 1.2 锁 数据库通过锁机制来解决并发场景-共享锁（读锁）和排他锁（写锁）。读锁是不阻塞的，多个客户端可以在同一时刻读取同一个资源。写锁是排他的，并且会阻塞其他的读锁和写锁。简单提下乐观锁和悲观锁。 乐观锁 ，通常用于数据竞争不激烈的场景，多读少写，通过版本号和时间戳实现。 悲观锁 ，通常用于数据竞争激烈的场景，每次操作都会锁定数据。 要锁定数据需要一定的锁策略来配合。 表锁 ，锁定整张表，开销最小，但是会加剧锁竞争。 行锁 ，锁定行级别，开销最大，但是可以最大程度的支持并发。 但是MySql的存储引擎的真实实现不是简单的行级锁，一般都是实现了多版本并发控制（MVCC）。MVCC是行级锁的变种，多数情况下避免了加锁操作，开销更低。MVCC是通过保存数据的某个时间点快照实现的。 1.3 事务 事务保证一组原子性的操作，要么全部成功，要么全部失败。一旦失败，回滚之前的所有操作。MySql采用自动提交，如果不是显式的开启一个事务，则每个查询都作为一个事务。 隔离级别控制了一个事务中的修改，哪些在事务内和事务间是可见的

MySQL Replication 概述 mysql在互联网领域用的如此广泛很大一部分原因是是源于它的replication机制，简单实用，几台PC机子，很容易提高性能，乃中小网站必备良方。 首先什么情况下要扩展数据库，建个网站，建个数据库，某一天网站火了，访问量暴增，意味着从你服务器上读网页的连接多了，IO瓶颈来了，自然想多加几台机子来分担压力，但是数据还要跟源主机上的数据库内数据保持一致，这时候就是开始扩展数据库的时候，replication就开始派上用场了。 MySQL Replication 俗称MySQL AB复制或主从复制，是MySQL官方推荐的数据同步技术。数据同步基本过程为从数据库会实时去读取主数据库的二进制日志文件，按照日志中记录对从库进行同样的操作，以达到数据同步效果。 MySQL Replication优点： 通过增加从服务器来提高数据库平台的可靠性能。在主服务器上执行写入和更新，在从服务器上向外提供读功能，可以动态地调整从服务器的数量，从而调整数据库平台的高性能。 提高数据安全性，因为数据已复制到从服务器，主数据库数据异常时，可以将从服务器复制进程终止来达到保护数据完整性的特点。 在主服务器上生成实时数据，而在从服务器上分析这些数据，从而缓解主服务器的性能。 MySQL复制类型 异步复制（Asynchronous replication ）

1.概述 从MYSQL5.6 开始，mysql开始支持GTID复制。 基于日志点复制的缺点： 从那个二进制日志的偏移量进行增量同步，如果指定错误会造成遗漏或者重复，导致数据不一致。 基于GTID复制： 1.从服务器会告诉主服务器已执行的事务的GTID值。 2.主库会告诉从哪些GTID事务没有被执行。 同一个事务在指定的从库执行一次。 什么是GTID GTID即全局事务ID,器保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID. GTID=source_id:transaction_id source_id:是主库的server UUID，在数据目录的auto.cnf 文件中。 transaction_id: 从1开始的一个序列。 2.基于GTID复制的步骤 1.在主DB服务器上建立复制帐号。 在主库执行命令 create user repl@'192.168.31.%' identified by 'repl'; grant all privileges on *.* to repl@'192.168.31.%' identified by 'repl'; 2.配置主数据库服务器 修改 /etc/my.cnf log_bin =on server_id=1001 gtid-mode=on enforce_gtid_consistency:强制事务一致性，保证事务的安全

转自： https://www.cnblogs.com/butterfly100/p/9034281.html 一. 数据切分 关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。此时就要考虑对其进行切分了，切分的目的就在于减少数据库的负担，缩短查询时间。 数据库分布式核心内容无非就是数据切分（Sharding），以及切分后对数据的定位、整合。数据切分就是将数据分散存储到多个数据库中，使得单一数据库中的数据量变小，通过扩充主机的数量缓解单一数据库的性能问题，从而达到提升数据库操作性能的目的。 数据切分根据其切分类型，可以分为两种方式：垂直（纵向）切分和水平（横向）切分 1、垂直（纵向）切分 垂直切分常见有垂直分库和垂直分表两种。 垂直分库就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似，每个微服务使用单独的一个数据库。如图： 垂直分表是基于数据库中的"列"进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中。在字段很多的情况下（例如一个大表有100多个字段），通过"大表拆小表"，更便于开发与维护，也能避免跨页问题

原文： https://www.cnblogs.com/roverliang/p/6414457.html MySQL 日志系统 做过大型系统的都知道，日志的作用不用小觑，往往到了项目中后期，对项目进行优化升级都是依据日志做出升级优化的决策的。那么学习MySQL，日志部分当然不能错过。我们面试中实际应用的所谈到的优化都是要从日志中得出来的。系统的学习mysql的日志，有助于我们准确的定位问题，提高自己的工作水平。此外，后面的一系列日志会重点从DBA的运维方面进行着手，系统的去理解MySQL各方面的配置，做到知己知彼，让MySQL成为自己得心应手的数据仓库。 一、MySQL的日志类型 默认情况下，所有的MySQL日志以文件的方式存放在数据库根目录下： [root@roverliang data]# pwd /usr/local/webserver/extend_lib/mysql/data [root@roverliang data]# ls auto.cnf ibdata1 ib_logfile0 ib_logfile1 mysql mytest performance_schema roverliang roverliang.err roverliang.pid test MySQL的日志类型有以下几种： 1. 错误日志（error）,MySQL服务实例启动

最近做项目使用到了分布式事务，下面这篇文章将给大家介绍一下对分布式事务的一些见解，并讲解分布式事务处理框架TX-LCN的执行原理，初学入门，错误之处望各位不吝指正。 什么情况下需要使用分布式事务？ 使用的场景很多，先举一个常见的：在微服务系统中，如果一个业务需要使用到不同的微服务，并且不同的微服务对应不同的数据库。 打个比方：电商平台有一个客户下订单的业务逻辑，这个业务逻辑涉及到两个微服务，一个是库存服务（库存减一），另一个是订单服务（订单数加一），示意图如下： 如果在执行这个业务逻辑时没有使用分布式事务，当库存与订单其中一个出现故障时，就很可能出现这样的情况：库存数据库的值减少了1，但是订单数据库没有变化；或是库存没变化，多了一个订单，也就是出现了数据不一致现象。 所以在类似的场合下我们要使用分布式事务，保证数据的一致性。 分布式事务的解决思路 引入：mysql中的两阶段提交策略 在谈分布式事务的解决思路之前，我们先来看看单一数据源是如何做事务处理的，我们可以从中获取一些启发。 我们以mysql的InnoDB引擎为例，由于mysql中有两套日志机制，一套是存储层的redo log，另一套是server层的binlog，每次更新数据都要对两个日志进行更新。为了防止写日志时只写了其中一个而没有写另外一个，mysql使用了一个叫 两阶段提交 的方式保证事务的一致性。具体是这样的：

1.主键超键候选键外键是什么? 定义： 超键：在关系中可以唯一标识元组的属性集。 初始键：不包含多余属性的超键。 主键：用户选作元组标识的一个附加键程序主键。 外键：如果关系R中的属性集是关系L中的主键，那么该属性集为关系R的外键。 超键 在关系中能唯一标识元组的属性集称为关系模式的超键。 这样我们从示例中可以发现学号是标识学生实体的唯一标识。那么该元组的超键就为学号。 除此之外我们还可以把它跟其他属性组合起来，比如： （ 学号 ， 性别 ） （ 学号 ， 年龄 ） 这样也是超键。 初始键 排除多余属性的超键为预期键。 根据示例可知，学号是一个可以唯一标识元组的唯一标识，因此学号是一个附加键，实际上，指向键是超键的子集，而非（学号，年龄）是超键，但是它不是预设键。因为它还有了额外的属性。 主键 用户选择的预设键作为该元组的唯一标识，那么它就以此为主键。 简单的说，示例中的元组的扩展键为学号，但是我们将他作为该元组的唯一标识，那么学号就以此为主。 外键 外键是相对于主键的，某些在学生记录里，主键为学号，在成绩单表中也有学号插入，因此学号为成绩单表的外键，为学生表的主键。 总结 主键为预期键的子集，外部键为超键的子集，而外键的确定是相对于主键的。 2.数据库事务的四个特性： ACID:原子性，一致性，隔离性，持久性。 原子性：数据库的所有操作要么完成，要么全部不完成

第一章 MySql存储引擎 1.Innodb存储引擎 支持事务，其特点是行锁设计、支持外键。 Innodb是Mysql默认的存储引擎。 2.MyISAM存储引擎 MyIsam存储引擎不支持事务和表锁设计，但是支持全文索引。 第五章 索引与算法 1.常见的索引：B+树索引、全文索引、哈希索引。 2.B+树，是通过二叉查找树，再由平衡二叉树，B树演化而来。 二叉查找树 二叉查找树：左子树的值总是小于根的值，右子树的值总是大于根的值。可以通过中序遍历得到值的排序输出。 平均查找速度比顺序查找来得快。 平衡二叉树(AVL树) 平衡二叉树：首先符合二叉查找树的定义，其次必须满足任何节点的两个子树的高度的最大差为1。 B+树 B+树：是为磁盘或其他直接存取辅助设备设计的一种平衡树。 在B+树中，所有记录节点都是按键值对的大小顺序存放在同一层的叶子节点上，由各叶子节点指针进行连接。 优点 :B+树的高度一般都在2--4层。也就是查找某一键值的行记录时最多只需要2--4次IO就可以了。 B+树索引 B+树索引，分为聚集索引和辅助索引。 聚集索引和辅助索引的区别：叶子节点存放的是否是一整行的信息。 聚集索引 聚集索引：就是按照每张表的主键构造一颗B+树，同时叶子节点存放的即为整张表的行记录数据，也将聚集索引的叶子节点称为数据页。 辅助索引 辅助索引：叶子节点并不包含行记录的全部数据