mysql事务

164. 数据库的三范式是什么？ 第一范式：强调的是列的原子性，即数据库表的每一列都是不可分割的原子数据项。 第二范式：要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性。 第三范式：任何非主属性不依赖于其它非主属性。 表类型如果是 MyISAM ，那 id 就是 8。 表类型如果是 InnoDB，那 id 就是 6。 165. 一张自增表里面总共有 7 条数据，删除了最后 2 条数据，重启 MySQL 数据库，又插入了一条数据，此时 id 是几？ InnoDB 表只会把自增主键的最大 id 记录在内存中，所以重启之后会导致最大 id 丢失。 166. 如何获取当前数据库版本？ 使用 select version() 获取当前 MySQL 数据库版本。 167. 说一下 ACID 是什么？ Atomicity（原子性）：一个事务（transaction）中的所有操作，或者全部完成，或者全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。即，事务不可分割、不可约简。 Consistency（一致性）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设约束、触发器、级联回滚等。 Isolation（隔离性）

MySQL常见的两种存储引擎：MyISAM与InnoDB Mysql索引使用的数据结构主要有BTree索引 和 哈希索引 。对于哈希索引来说，底层的数据结构就是哈希表，因此在绝大多数需求为单条记录查询的时候，可以选择哈希索引，查询性能最快；其余大部分场景，建议选择BTree索引。 Mysql的BTree索引使用的是B数中的B+Tree，但对于主要的两种存储引擎的实现方式是不同的。   MyISAM: B+Tree叶节点的data域存放的是数据记录的地址。在索引检索的时候，首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其data域的值，然后以data域的值为地址读取相应的数据记录。这被称为“非聚簇索引”。   InnoDB: 其数据文件本身就是索引文件。相比MyISAM，索引文件和数据文件是分离的，其表数据文件本身就是按B+Tree组织的一个索引结构，树的叶节点data域保存了完整的数据记录。这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。这被称为“聚簇索引（或聚集索引）”。而其余的索引都作为辅助索引，辅助索引的data域存储相应记录主键的值而不是地址，这也是和MyISAM不同的地方。在根据主索引搜索时，直接找到key所在的节点即可取出数据；在根据辅助索引查找时，则需要先取出主键的值，在走一遍主索引。 因此，在设计表的时候

https://www.cnblogs.com/soundcode/p/5590710.html 编者按：本文由「高可用架构后花园」群讨论整理而成。 有人的地方，就有江湖 有江湖的地方，就有纷争 问题的起源 在电商等业务中，系统一般由多个独立的服务组成，如何解决分布式调用时候数据的一致性？ 具体业务场景如下，比如一个业务操作，如果同时调用服务 A、B、C，需要满足要么同时成功；要么同时失败。A、B、C 可能是多个不同部门开发、部署在不同服务器上的远程服务。 在分布式系统来说，如果不想牺牲一致性，CAP 理论告诉我们只能放弃可用性，这显然不能接受。为了便于讨论问题，先简单介绍下数据一致性的基础理论。 强一致 当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。 弱一致性 系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。 最终一致性 弱一致性的特定形式。系统保证在没有后续更新的前提下，系统 最终 返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。 在工程实践上

Read uncommitted 读未提交 公司发工资了，领导把5000元打到singo的账号上，但是该事务并未提交，而singo正好去查看账户，发现工资已经到账，是5000元整，非常高 兴。可是不幸的是，领导发现发给singo的工资金额不对，是2000元，于是迅速回滚了事务，修改金额后，将事务提交，最后singo实际的工资只有 2000元，singo空欢喜一场。 出现上述情况，即我们所说的 脏读 ，两个并发的事务，“事务A：领导给singo发工资”、“事务B：singo查询工资账户”，事务B读取了事务A尚未提交的数据。 当隔离级别设置为 Read uncommitted 时，就可能出现脏读，如何避免脏读，请看下一个隔离级别。 Read committed 读提交 singo拿着工资卡去消费，系统读取到卡里确实有2000元，而此时她的老婆也正好在网上转账，把singo工资卡的2000元转到另一账户，并在 singo之前提交了事务，当singo扣款时，系统检查到singo的工资卡已经没有钱，扣款失败，singo十分纳闷，明明卡里有钱，为 何...... 出现上述情况，即我们所说的 不可重复读 ，两个并发的事务，“事务A：singo消费”、“事务B：singo的老婆网上转账”，事务A事先读取了数据，事务B紧接了更新了数据，并提交了事务，而事务A再次读取该数据时，数据已经发生了改变。

一、背景 　　前面有说到InnoDB是事务型引擎，那什么是事务？事务的特性是什么？它所对应的隔离级别是哪些？是怎么实现的？下面来详细讨论下。 二、事务的理解 　　事务就是一组原子性的SQL查询，或者说一个独立的工作单元。如果数据库引擎能够成功地对数据库应用该组查询的全部语句，那么就执行该组语句。如果其中有任何一条语句因为崩溃或其他原因无法执行，那么所有的语句都不会执行。也就是说，事务内的语句，要么全部执行成功，要么全部执行失败。 　　可以用银行转账的例子来解释事务的必要性。如果一个银行的数据库有两张表，支票表和储蓄表，现在用户张三从他的支票账户转移200元到他的储蓄账号，那么需要发生至少三个步骤： 检查支票账号的余额高于200元； 从支票账号余额中减去200元； 在储蓄账号余额中增加200元。 　　上述三个步骤的操作必须打包在一个事务中，任何一个事务的失败，则必须回滚所有的步骤，即支票账号和储蓄账号都回到这个转账操作的最初状态。 　　可以用start transaction语句开始一个事务，然后用commit提交事务将修改的数据持久保留或使用rollback撤销所有的修改。事务SQL的样本如下： start transaction; select balance from checking where customer_id=1; update checking set

点击打开链接 Python的ORM框架SQLAlchemy基本操作和常用技巧，包含大量实例,非常好的一个学习SQLAlchemy的教程,需要的朋友可以参考下 python编程语言下的一款开源软件。提供了SQL工具包及对象关系映射（ORM）工具，使用MIT许可证发行。 MySQL InnoDB 使用，所以使用其他 数据库 的也不能完全照搬本文。 mysql [python] view plain copy apt-get install mysql-server apt-get install mysql-client apt-get install libmysqlclient15-dev [python] view plain copy apt-get install python-mysqldb python ez_setup.py [python] view plain copy easy_install MySQL-Python [python] view plain copy easy_install SQLAlchemy 操作系统，遇到问题就 Google 一下吧。我是在 Mac OS X 上开发的，途中也遇到些问题，不过当时没记下来…… 值得一提的是我用了 MySQL-Python 来连 MySQL，因为不支持异步调用，所以和 Tornado 不是很搭

创建一个连接引擎 engine=create_engine( "mysql+pymysql://root:password@localhost:3306/test",echo= True) from sqlalchemy import func, or_, not_ user = User(name='a') session.add(user) user = User(name='b') session.add(user) user = User(name='a') session.add(user) user = User() session.add(user) session.commit() query = session.query(User) print query # 显示SQL 语句 print query.statement # 同上 for user in query: # 遍历时查询 print user.name print query.all() # 返回的是一个类似列表的对象 print query.first().name # 记录不存在时，first() 会返回 None # print query.one().name # 不存在，或有多行记录时会抛出异常 print query.filter(User.id == 2).first().name

MySQL事务 MySQL 事务主要用于处理操作量大，复杂度高的数据。比如说，在一个商城系统中，用户执行购买操作，那么用户订单中应该加一条，库存要减一条，如果这两步由于意外只进行了其中一步那么就会发生很大的问题。而事务可以很好的解决这个问题。 事务是数据库处理操作，其中执行就好像它是一个单一的一组有序的工作单元。换言之在组内每个单独的操作是成功的，那么一个事务才是完整的。如果事务中的任何操作失败，整个事务将失败。 事务性质： 原子性：确保工作单位中所有操作都成功完成；否则，事务被中止，在失败时会回滚到事务操作以前的状态。 一致性：可确保数据库在正确的更改状态进行一个成功的提交事务。 隔离性：使事务相互独立的操作。 持久性：确保了提交事务的结果或系统故障情况下仍然存在作用。 TCL(事务控制语言)： begin; 操作; commit; BEGIN或START TRANSACTION; #显式地开启一个事务 COMMIT;或COMMIT WORK; #二者等阶。COMMIT会提交事务并使已对数据库进行的所有修改成为永久性的。未COMMIT的操作都存放在内存中，仅当前客户端可以查看到，其他客户端看不到，当前客户端关闭后就清空了 ROLLBACK;或ROLLBACK WORK; #二者等阶。回滚会结束用户的事务，并撤销正在进行的所有未提交的修改 SET AUTOCOMMIT=0

01 概述 数据库是一个多用户使用的共享资源。当多个用户并发地存取数据时，在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据，破坏数据库的一致性。加锁是实现数据库并发控制的一个非常重要的技术。当事务在对某个数据对象进行操作前，先向系统发出请求，对其加锁。加锁后事务就对该数据对象有了一定的控制，在该事务释放锁之前，其他的事务不能对此数据对象进行更新操作。 OLTP 场景下通常要求具有很高的并发性。并发事务实际上取决于资源的使用状况，原则上应尽量减少对资源的锁定时间，减少对资源的锁定范围，从而能够尽量增加并发事务的数量，那么影响并发的因素有哪些呢？本文将从巨杉分布式数据库本身的机制以及隔离级别、数据库锁、参数、及实际例子进行详解，读完本文将对巨杉数据库并发性与锁机制有一个初步的了解。 02 隔离级别与并发性 在单用户环境中，每个事务都是顺序执行的，而不会遇到与其他事务的冲突。但是，在多用户环境下，多个事务并发执行。因此每个事务都有可能与其他正在运行的事务发生冲突。有可能与其他事务发生冲突的事务称为交错的或并行的事务，而相互隔离的事务称为串行化事务，这意味着同时运行它们的结果与一个接一个连续地运行它们的结果没有区别。在多用户环境下，在使用并行事务时，会发生四种现象： 丢失更新：这种情况发生在两个事务读取并尝试更新同一数据时

我们为什么要使用数据库的事务呢？使用事务有什么缺点呢？ 使用原因：保持数据的匹配和一致性。 缺点： 并发操作中过度使用事务影响性能，因为事务用到了锁技术。 我是李福春，今天我们来复习一下事务的特性。 你可以收获下图中的知识点。 下面我们发散一下。 事务特性 原子性： 要么全部成功要么全部失败 一致性： 保证事务的前后一致性 隔离性：事物之间的执行不能互相干扰 持久性： 事务终结的标志，内存的数据持久化到硬盘中 并发场景下事务出现的问题 脏读： 不可重复读 幻读： 依赖id的自增做为依据。 隔离级别 读未提交 隔离度最弱 脏读 不可重复度 幻读 读已提交 不可重复度 幻读 可重复读 数据库默认 幻读 可串行化 性能最低 没有问题 innodb mvcc 不能解决幻读 如何跟合理的使用事务 没有数据一致性要求场景 不使用事务 只有查询的场景: 不需要使用事务 更新记录表，然后更新统计表 不要使用事务， 使用事务触发或者定时任务； 内容繁杂的大事务 分拆成各种小事务，各种反向操作辅助 原创不易，转载请注明出处。 来源： https://www.cnblogs.com/snidget/p/12556761.html