mysql事务

索引相关 关于MySQL的索引,曾经进行过一次总结,文章链接在这里 Mysql索引原理及其优化. 什么是索引? 索引是一种数据结构,可以帮助我们快速的进行数据的查找. 索引是个什么样的数据结构呢? 索引的数据结构和具体存储引擎的实现有关, 在MySQL中使用较多的索引有Hash索引,B+树索引等,而我们经常使用的InnoDB存储引擎的默认索引实现为:B+树索引. Hash索引和B+树所有有什么区别或者说优劣呢? 首先要知道Hash索引和B+树索引的底层实现原理: hash索引底层就是hash表,进行查找时,调用一次hash函数就可以获取到相应的键值,之后进行回表查询获得实际数据.B+树底层实现是多路平衡查找树.对于每一次的查询都是从根节点出发,查找到叶子节点方可以获得所查键值,然后根据查询判断是否需要回表查询数据. 那么可以看出他们有以下的不同: hash索引进行等值查询更快(一般情况下),但是却无法进行范围查询. 因为在hash索引中经过hash函数建立索引之后,索引的顺序与原顺序无法保持一致,不能支持范围查询.而B+树的的所有节点皆遵循(左节点小于父节点,右节点大于父节点,多叉树也类似),天然支持范围. hash索引不支持使用索引进行排序,原理同上. hash索引不支持模糊查询以及多列索引的最左前缀匹配.原理也是因为hash函数的不可预测.AAAA和AAAAB的索引没有相关性.

1.分布式事务原理 在MySQL中，使用分布式事务的应用程序涉及一个或多个资源管理器和一个事务管理器 1> 资源管理器(RM) 用于提供通向事务资源的途径 。数据库服务器 是一种 资源管理器 。该管理器必须可以 提交或回滚由RM 管理的事务 。 2> 事务管理器(TM) 用于协调作为一个分布式事务一部分的事务。 TM于管理每个事务的RMs进行通信 。在一个分布式事务中，各个单个事务均是分布式事务的“分支事务”。分布式事务和分支通过一种命名方法进行标记。 MySQL执行分布式的MYSQL的时候，MySQL相当于一个用于管理分布式事务中的分布式事务的资源管理器。于MySQL服务连接的客户端相当于事务管理器。 2.分布式事务分步骤 第一阶段，所有的 分支都被预定 ，即它们被TM(事务管理器)告知要准备提交， 这意味着用于管理分支的每个RM会记录对于被稳定保存的分支的行动。分支指示是否它们可以这么做 。这些结果被用于第二阶段 第二阶段， TM告知RMs是否要提交或回滚 。如果在预备分支时，所有的分支指示它们能够提交，则所有分支被告知要提交。如果在预备时，有任何分支指示它们将不能提交，则所有分支被告知回滚。 3.分布式事务的语法 xid的组成 4.启动XA事务进行操作 XA END xid [ SUSPEND [ FOR MIGRATE ] ] XA PREPARE xid -- 使事务进行

Pymysql介绍 PyMySQL 是在 Python3.x 版本中用于连接 MySQL 服务器的一个库，而Python2中则使用mysqldb。 PyMySQL 遵循 Python 数据库 API v2.0 规范，并包含了 pure-Python MySQL 客户端库。 通用步骤: 1.引入模块 2.获取与数据库的连接 3.执行SQL语句和存储过程 4.关闭数据库连接 PyMySQL 安装 1.打开cmd命令 cd C:\Users\Administrator\AppData\Local\Programs\Python\Python37\Scripts #切换目录 pip install pymysql 数据库连接 import pymysql #模块导入 #打开数据库连接 db = pymysql.connect( host='数据库ip', user='用户名, passwd='密码', db='数据库名', port=3306, charset='utf8' ) #使用 cursor() 方法创建一个游标对象 cursor cursor = db.cursor() #使用 execute() 方法执行 SQL 查询 cursor.execute("SELECT VERSION()") #使用 fetchone() 方法获取单条数据. data = cursor

01 | 基础架构：一条SQL查询语句是如何执行的？ 02 | 日志系统：一条SQL更新语句是如何执行的？ 03 | 事务隔离：为什么你改了我还看不见？ 04 | 深入浅出索引（上） 05 | 深入浅出索引（下） 06 | 全局锁和表锁 ：给表加个字段怎么有这么多阻碍？ 07 | 行锁功过：怎么减少行锁对性能的影响？ 08 | 事务到底是隔离的还是不隔离的？ 来源：博客园 作者： 你头发少你先说 链接：https://www.cnblogs.com/createtable/p/11445353.html

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 命令行的默认设置下，事务都是自动提交的，即执行 SQL 语句后就会马上执行 COMMIT 操作。因此要显式地开启一个事务务须使用命令 BEGIN 或 START TRANSACTION，或者执行命令 SET AUTOCOMMIT=0，用来禁止使用当前会话的自动提交。 事务控制语句： BEGIN 或 START TRANSACTION 显式地开启一个事务； COMMIT 也可以使用 COMMIT WORK，不过二者是等价的。COMMIT 会提交事务，并使已对数据库进行的所有修改成为永久性的； ROLLBACK 也可以使用 ROLLBACK WORK，不过二者是等价的。回滚会结束用户的事务，并撤销正在进行的所有未提交的修改； SAVEPOINT identifier，SAVEPOINT 允许在事务中创建一个保存点，一个事务中可以有多个 SAVEPOINT； RELEASE SAVEPOINT identifier 删除一个事务的保存点，当没有指定的保存点时，执行该语句会抛出一个异常； ROLLBACK TO identifier 把事务回滚到标记点； SET TRANSACTION 用来设置事务的隔离级别。InnoDB 存储引擎提供事务的隔离级别有READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ 和 SERIALIZABLE

线上某服务时不时报出如下异常（大约一天二十多次）：“Deadlock found when trying to get lock;”。 1 死锁是怎么被发现的？ 1.1 死锁成因&&检测方法 1.2 wait-for graph原理 1.2.1 锁与索引的关系 id: bigint token: varchar(30) message: varchar(4096) 1）delete from msg where id=2； 2）delete from msg where token=’ cvs’; 3）delete from msg where message=订单号是多少’； 1.2.2 锁与隔离级别的关系 1）未提交读（Read uncommitted）； 2）已提交读（Read committed（RC））； 3）可重复读（Repeatable read（RR））； 4）可串行化（Serializable）。 我们较常使用的是RC和RR。 RC级别下尽管加了行锁，但还是避免不了幻读。 RR隔离级别 可以避免幻读发生，怎么实现？当然需要借助于锁了！ gap锁（间隙锁） 。 3 死锁成因 3.1不同表相同记录行锁冲突 3.2相同表记录行锁冲突 3.3不同索引锁冲突 3.4 gap锁冲突 4 如何尽可能避免死锁 1）以固定的顺序访问表和行。比如对第2节两个job批量更新的情形

今天巡检时突然发现有很多锁等待超时的情况，原以为是一个简单的小事，一查，结果令人深思。 发现日志中出现了大量的 ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction 错误 2. 排查过程 发现此类情况后，挑了其中一个SQL脚本手动运行了一下，发现同样报此错误 mysql> UPDATE tbname SET column_name = 2 WHERE col_id= '25945fa285904ea59cd92a73a3850ceb' AND aYear = 2018 AND aMonth = 5; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction 出现此情况，第一反应是查看是否有未提交的事务或有其他的SQL运行时也需要对该条记录进行写操作。 # 查看正在运行的sql select * from information_schema.processlist where info is not null; 结果集中并无对该表的任何操作，因此，很大可能是有未提交的事务了。 # 查看事务 SELECT *FROM information_schema.INNODB_TRX； 　

binglog binglog参数配置：sync_binlog sync_binlog=0 的时候，表示每次提交事务都只写page cache ,不会持久化到硬盘 sync_binlog=1 的时候，表示每日提交事务之后都会写page cache，并且持久化到硬盘 sync_binlog=N 的时候，表示当积累N次事务之后就会一次性写入硬盘 心得 1，如果不是什么特别重要的数据，且并发比较高的时候可以把snc_binlog设置成100-1000中的某个值，这样可以提高性能 2，如果是对特别重要的数据，例如订单数据则建议将sync_binlog的值设置为1，这样能够保证哪怕数据库挂了，也可以保证不丢数据 3，当sync_binglog设置为0的时候，mysql会根据操作系统自动进行写入且mysql默认这个值就是0 redolog redolog参数配置 innodb_flush_log_at_trx_commit 设置为 0 的时候，表示每次事务提交时都只是把 redo log 留在 redo log buffer 中 ; 设置为 1 的时候，表示每次事务提交时都将 redo log 直接持久化到磁盘； 设置为2 的时候，表示每次事务提交都只是吧redolog写到page cache 1 redolog和binlog是怎么关联起来的 答：他们有一个共同的数据字段叫做xid

mysql数据库，当且仅当引擎是InnoDB，才支持事务； 1、隔离级别 事务的隔离级别分为：未提交读(read uncommitted)、已提交读(read committed)、可重复读(repeatable read)、串行化(serializable)。 未提交读 A事务已执行，但未提交；B事务查询到A事务的更新后数据；A事务回滚；---出现脏数据 已提交读 A事务执行更新；B事务查询；A事务又执行更新；B事务再次查询时，前后两次数据不一致；---不可重复读 可重复读 A事务无论执行多少次，只要不提交，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; //设置repeatable read级别：