事务

如题；node后台使用mysql数据库，并使用事务来管理数据库操作。 这里主要讲一个事务的封装并写了一个INSERT 插入操作。 code： 基础code： db.config.js const mysql = require('mysql') const pool = mysql.createPool({ connectionLimit: 20, //连接池连接数 host: 'localhost', //数据库地址，这里用的是本地 database: 'xxxx', //数据库名称 user: 'xxxxx', // username password: '*****' // password }) //返回一个Promise链接 const connectHandle = () => new Promise((resolve, reject) => { pool.getConnection((err, connection) => { if(err) { console.error('链接错误：' + err.stack + '\n' + '链接ID：' + connection.threadId) reject(err) } else { resolve(connection) } }) }) module.exports = connectHandle 事务操作

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

1， mysql的复制原理以及流程。 （1）先问基本原理流程，3个线程以及之间的关联。 （2）再问一致性，延时性，数据恢复。 （3）再问各种工作遇到的复制bug的解决方法 2，mysql中myisam与innodb的区别，至少5点。 （1） 问5点不同 1>.InnoDB支持事物，而MyISAM不支持事物 2>.InnoDB支持行级锁，而MyISAM支持表级锁 3>.InnoDB支持MVCC, 而MyISAM不支持 4>.InnoDB支持外键，而MyISAM不支持 5>.InnoDB不支持全文索引，而MyISAM支持。（X) （2） 问各种不同mysql版本的2者的改进 （3）2者的索引的实现方式 3，问mysql中varchar与char的区别以及varchar(50)中的30代表的涵义。 （1）varchar与char的区别 char是一种固定长度的类型，varchar则是一种可变长度的类型 （2）varchar(50)中50的涵义 最多存放50个字符 （3）int（20）中20的涵义 int(M)中的M indicates the maximum display width (最大显示宽度)for integer types. The maximum legal display width is 255. （4）为什么MySQL这样设计？ 4

　　如果一个数据库声称支持事务的操作，那么该数据库必须要具备以下四个特性： ⑴ 原子性（Atomicity） 　　原子性试纸事务包含所有的操作要么全部成功，要么全部失败回滚，事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对是数据库有任何影响。 ⑵ 一致性（Consistency） 　　一致性是指事务必须使数据库从一个一致性的状态转为为另一个一致性的状态，也就是说一个事务执行之前和执行之后都必须处于一致性的状态。 　　比如银行转账，加上A用户和B用户两者账户的钱一共有500，那么不管A用户和B用户之间如何转账，事务结束之后两个用户的钱加起来还是500，这就是事务的一致性。 ⑶ 隔离性（Isolation） 　　隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。 　　即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。 　　关于事务的隔离性数据库提供了多种隔离级别，稍后会介绍到。 ⑷ 持久性（Durability） 　　持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。 　

来源： https://www.cnblogs.com/panbin/p/11324005.html

如何并发的访问数据库呢？答案就是 加锁 。 接下来说一下， 数据库的锁机制，数据库中都有哪些锁？ 　　 首先呢，锁是一种 并发控制技术 ，锁是用来在多个用户同时访问同一个数据的时候保护数据的。 有2种基本的锁类型： 　　 共享（S）锁： 多个事务可封锁一个共享页；任何事务都不能修改该页；通常是该页被读取完毕，S锁立即被释放。在执行select语句的时候需要给操作对象（表或一些记录）加上共享锁，但加锁之前需要检查是否有排他锁，如果没有，则可以加共享锁（一个对象上可以加N个共享锁），否则不行。共享锁通常在执行完select语句之后被释放，当然也可能是在事务结束（包括正常结束和异常结束）的时候被释放，主要取决与数据库所设置的事务隔离级别。 　　 排它（X）锁： 仅允许一个事务封锁此页；其他任何事务必须等到X锁被释放才能对该页进行访问；X锁一直到事务结束才能被释放。执行insert、update、delete语句的时候需要给操作的对象加排它锁，在加排他锁之前必须确认该对象上没有其他任何锁，一旦加上排它锁之后，就不能再给这个对象加其他任何锁。排它锁的释放通常是在事务结束的时候（当然也有例外，就是在数据库事务隔离级别被设置为Read Uncommitted（读未提交数据）的时候，这种情况下排他锁会在执行完更新操作之后被释放，而不是在事务结束的时候）。 按锁的机制 既然使用了锁

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（隔离性）

转载自 https://m.nowcoder.com/tutorial/93/8ac75a692a3b4b0a868796b9f008bc2c MySQL引擎 MySQL中的数据用各种不同的技术存储在文件（或内存）中。这些技术中的每一种技术都使用不同的存储机制、索引技巧和锁定水平并且最终提供广泛的不同的功能和能力。通过选择不同的技术，你能够获得额外的速度或功能，从而改善你的应用的总体功能。 数据库引擎是用于存储、处理和保护数据的核心服务。利用数据库引擎可控制访问权限并快速处理事务，从而满足企业内大多数需要处理大量数据的应用程序的要求。 MySQL存储引擎主要有：MyISAM、InnoDB、Memory、Blackhole、CSV、Performance_Schema、Archieve、Federated、Mrg_Myiasm. 但是最常用的是InnoDB和MyISAM。 InnoDB InnoDB是一个事务型的存储引擎，有行级锁定和外键约束。 InnoDB引擎提供了对数据库ACID事务的支持，并且实现了SQL的四种隔离级别。 该引擎还提供了行级锁定和外键约束，它的设计目标是处理大容量数据库系统，它本身其实就是基于MySQL后台的完整数据库系统，MySQL运行时InnoDB会在内存中建立缓冲池，用于缓冲数据和索引。 但是该引擎不支持FULLTEXT类型的索引 而且它没有保存表的行数

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 是一个典型的最终一致性系统。 在工程实践上