mysql事务

day61 保存在MySQL上的一个别名 > 一坨SQL语句 -- delimiter // -- create procedure p1() -- BEGIN -- select * from student; -- INSERT into teacher(tname) values("ct"); -- END// -- delimiter; call p1(); #把sql语句封装进p1中 注释内容（创建存储过程）执行完，可以通过call调用（执行存储过程）。 在函数中： 也可通过pymysql调用存储过程 1 import pymysql 2 3 #打开 4 conn = pymysql.connect(host= "localhost", user = 'root', password='112358', database = 'db3') 5 #拿 6 cursor = conn.cursor() 7 cursor.callproc('p1')#p1存储过程 8 result = cursor.fetchall() #拿 9 10 print(result) 11 #关闭数据库 12 cursor.close() 13 conn.close() cursor.callproc('p1') 执行结果： ((1, '男', 1, '理解'), (2, '女', 1, '钢蛋'

本文主要涉及以下几个个部分： 1. 为什么要加锁 2. 锁的分类 3. 常见语句的加锁分析 4. 如何分析死锁 5. 如何预防死锁 先列出本地的运行环境 数据库版本是5.7，隔离级别是Repeatable-Read(可重复读)，不同的数据库版本和隔离级别对语句的执行结果影响很大。所以需要说明版本和隔离级别 一、为什么要加锁 数据库是一个多用户使用的共享资源。当多个用户并发地存取数据时，在数据库中加锁是为了保证数据库的一致性。 数据库有ACID原则，其中I是隔离性， 脏读：读未提交的数据 不可重复读：读已修改的数据 虚读：读提交了插入/删除的数据 事务隔离机制 和标准SQL规范相比，MySQL中可重复读解决了幻读，实现了串行化隔离级别的功能，同时没有严重影响并发。是通过加锁、阻止插入新数据，来解决幻读的。 二、锁的分类 锁 我们听说过读锁、写锁、共享锁、互斥锁、行锁等等各种名词，简单对这些锁进行了分类。 锁的分类 加锁机制： 1、乐观锁：先修改，保存时判断是够被更新过，应用级别 2、悲观锁：先获取锁，再操作修改，数据库级别 锁粒度： 表级锁：开销小，加锁快，粒度大，锁冲突概率大，并发度低，适用于读多写少的情况。 页级锁：BDB存储引擎 行级锁：Innodb存储引擎，默认选项 兼容性： S锁，也叫做读锁、共享锁，对应于我们常用的 select * from users where id

什么是事务 一件事情有 n个组成单元 要不这n个组成单元同时成功 要不n个单元就同时失败 就是将 n个组成单元放到一个事务中 mysql的事务 默认的事务：一条 sql语句就是一个事务 默认就开启事务并提交事务 手动事务： 1） 显示的开启一个事务： start transaction 2） 事务提交： commit代表从开启事务到事务提交 中间的所有的sql都认为有效 真正的更新数据库 3）事务的回滚：rollback 代表事务的回滚 从开启事务到事务回滚 中间的所有的 sql操作都认为无效数据库没有被更新 一、JDBC事务操作 默认是自动事务： 执行 sql语句：executeUpdate() ---- 每执行一次executeUpdate方法 代表 事务自动提交 通过 jdbc的API手动事务： 开启事务： conn.setAutoComnmit(false); 提交事务： conn.commit(); 回滚事务： conn.rollback(); 事务的特性 ACID l 1）原子性（Atomicity）原子性是指事务是一个不可分割的工作单位，事务中的操作 要么都发生，要么都不发生。 l 2）一致性（Consistency）一个事务中，事务前后数据的完整性必须保持一致。 l 3）隔离性（Isolation）多个事务，事务的隔离性是指多个用户并发访问数据库时， 一个用户的

1.1 mysql逻辑架构 客户端 连接/线程处理 查询缓存——解析器 优化器 存储引擎 1.1.1 连接管理与安全性 每个客户端连接都会在服务器进程中拥有一个线程，这个连接的查询只有在这个单独的线程中执行，该线程只能轮流在某个CPU核心或者CPU中运行。服务器会负责缓存线程，因此不需要为每一个新建的连接创建或销毁线程。 当客户端（应用）连接到mysql服务器时，服务器需要对其进行认证。认证基于用户名、原始主机信息和密码。 1.1.2 优化与执行 优化器会请求存储引擎提供容量或某个具体操作的开销信息，以及表数据的统计信息等。 对于select查询语句，在解析查询之前，服务器会先检查查询缓存（Query Cache），如果能够在其中找到对应的查询，服务器就不必再执行查询解析、优化和执行的过程，而是直接返回查询缓存中的结果集。 1.2 并发控制 1.2.1 读写锁 共享锁（shared lock）和排他锁（exclusive lock），也叫读锁（read lock）和写锁（write lock）。 1.2.2锁粒度 一种提高共享资源并发性的方式就是让锁定对象更有选择性。尽量只锁定需要修改的部分数据，而不是所有的资源。更理想的方式是，只对会修改的数据片进行精确的锁定。任何时候，在给定的资源上，锁定的数据量越少，则系统的并发程度越高，只要相互之间不发生冲突即可。 问题是加锁也需要消耗资源

线上某服务时不时报出如下异常（大约一天二十多次）：“Deadlock found when trying to get lock;”。 Oh, My God! 是死锁问题。尽管报错不多，对性能目前看来也无太大影响，但还是需要解决，保不齐哪天成为性能瓶颈。 为了更系统的分析问题，本文将从死锁检测、索引隔离级别与锁的关系、死锁成因、问题定位这五个方面来展开讨论。 图1 应用日志 1 死锁是怎么被发现的？ 1.1 死锁成因&&检测方法 左图那两辆车造成死锁了吗？不是！右图四辆车造成死锁了吗？是！ 图2 死锁描述 我们mysql用的存储引擎是innodb，从日志来看，innodb主动探知到死锁，并回滚了某一苦苦等待的事务。问题来了，innodb是怎么探知死锁的？ 直观方法是在两个事务相互等待时，当一个等待时间超过设置的某一阀值时，对其中一个事务进行回滚，另一个事务就能继续执行。这种方法简单有效，在innodb中，参数innodb_lock_wait_timeout用来设置超时时间。 仅用上述方法来检测死锁太过被动，innodb还提供了wait-for graph算法来主动进行死锁检测，每当加锁请求无法立即满足需要并进入等待时，wait-for graph算法都会被触发。 1.2 wait-for graph原理 我们怎么知道上图中四辆车是死锁的？他们相互等待对方的资源，而且形成环路

目录 聚合查询 聚合函数 分组查询 F与Q查询 F能够获取表中字段所对应的值 Q查询 Q对象高级用法 orm 字段及参数 自定义字段 orm中的事务操作 1.第一范式: 2.第二范式: 3.第三范式 django中创建事务 聚合查询 ​ 级联删除 级联更新 (外键字段带来的约束) ​ 操作外键字段管理数据时 ​ 书和出版社是一对多的关系 外键字段在书那 ​ 这个时候把出版社删了 所对应的书字段也会自动给删除 ​ 这个时候如果你把出版社主键改变了 那么书籍表中对应的出版社主键值也会改变 聚合函数 ​ 聚合函数必须用在分组之后 ​ 没有分组其实默认就是一组 关键字 aggregate 还需要导入模块 from django.db.models import Max,Min,Sum,Avg,Count res = models.Book.objects.aggregate(sm = Sum('price')) res = models.Book.objects.aggregate(Max('price'),Min('prince'),Sum('price'),Count('price'),Avg('price')) 分组查询 ​ mysql 中用 group by ​ 什么时候用分组 ​ 1.统计每一个部门的平均薪资 ​ 2.统计每一个部门的男女比例 ​ 1.关键字 annotate ​

不知道你是否遇到过这样的情况，去小卖铺买东西，付了钱，但是店主因为处理了一些其他事，居然忘记你付了钱，又叫你重新付。又或者在网上购物明明已经扣款，但是却告诉我没有发生交易。这一系列情况都是因为没有事务导致的。这说明了事务在生活中的一些重要性。有了事务，你去小卖铺买东西，那就是一手交钱一手交货。有了事务，你去网上购物，扣款即产生订单交易。 知识脑图： 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。 数据库本地事务 ACID 说到数据库事务就不得不说，数据库事务中的四大特性，ACID: A:原子性(Atomicity) 一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 就像你买东西要么交钱收货一起都执行，要么要是发不出货，就退钱。 C:一致性(Consistency) 事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成，那么系统中所有变化将正确地应用

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

转自 https://blog.csdn.net/C_J33/article/details/79487941 数据库锁 先看一张图自己整理的数据库锁的树形图 概要 数据库锁一般可以分为两类，一个是悲观锁，一个是乐观锁。 乐观锁一般是指用户自己实现的一种锁机制，假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。乐观锁的实现方式一般包括使用版本号和时间戳。 悲观锁一般就是我们通常说的数据库锁机制，以下讨论都是基于悲观锁。 悲观锁主要表锁、行锁、页锁。在MyISAM中只用到表锁，不会有死锁的问题，锁的开销也很小，但是相应的并发能力很差。innodb实现了行级锁和表锁，锁的粒度变小了，并发能力变强，但是相应的锁的开销变大，很有可能出现死锁。同时inodb需要协调这两种锁，算法也变得复杂。InnoDB行锁是通过给索引上的索引项加锁来实现的，只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁。 表锁和行锁都分为共享锁和排他锁（独占锁），而更新锁是为了解决行锁升级（共享锁升级为独占锁）的死锁问题。 innodb中表锁和行锁一起用，所以为了提高效率才会有意向锁（意向共享锁和意向排他锁）。 为了表锁和行锁而存在的意向锁 官方文档中是这么描述的，

分布式系统下，分布式数据库遇到的挑战 　　分布式系统下，当访问关系型数据库的i/o占用过高，内存不足，访问过慢的情况下，可以考虑流流行的分库分表的策略，但是这样也会到来很多新的技术挑战。 1.分布式事务 　　当还是单体应用，单体数据库时，完全不需要考虑事务的一致性问题，因为mysql已经帮我们处理事务问题(ACID)，但是这只是针对单体情况下，如果是多个数据库，主从备份，读写分离，那么就会可能造成事务不一致的情况，那么什么事分布式事务，分布式 　　事务又该如何解决呢？ 　　 　　1.有关于事务的概念 　　　　本地事务：本地事务的优点就是支持严格的ACID特性，高效，可靠，状态可以只在资源管理器中维护，而且应用编程模型简单。 　　　　全局事务：当事务由全局事务管理器进行全局管理时成为全局事务，事务管理器负责管理全局的事务状态和参与的资源，协同资源的一致提交回滚。 　　　　两阶段事务：两阶段事务提交采用的是X/OPEN组织所定义的 DTP模型 ，通过抽象出来的 AP , TM , RM 的概念可以保证事务的强一致性。 其中 TM 和 RM 间采用 XA 的协议进行双向通信。 与传统的本地事务相比， 　　　　　　　　　　XA事务增加了prepare阶段，数据库除了被动接受提交指令外，还可以反向通知调用方事务是否可以被提交。 因此 TM 可以收集所有分支事务的prepare结果