mysql事务

数据库事务的隔离级别有4种，由低到高分别为Read uncommitted 、Read committed 、Repeatable read 、Serializable 。而且，在事务的 并发 操作中可能会出现脏读，不可重复读，幻读。下面通过事例一一阐述它们的概念与联系。 Read uncommitted 读未提交，顾名思义，就是一个事务可以读取另一个未提交事务的数据。 事例：老板要给程序员发工资，程序员的工资是3.6万/月。但是发工资时老板不小心按错了数字，按成3.9万/月，该钱已经打到程序员的户口，但是事务还没有提交，就在这时，程序员去查看自己这个月的工资，发现比往常多了3千元，以为涨工资了非常高兴。但是老板及时发现了不对，马上回滚差点就提交了的事务，将数字改成3.6万再提交。 分析：实际程序员这个月的工资还是3.6万，但是程序员看到的是3.9万。他看到的是老板还没提交事务时的数据。这就是 脏读 。 那怎么解决脏读呢？Read committed！读提交，能解决脏读问题。 Read committed 读提交，顾名思义，就是一个事务要等另一个事务提交后才能读取数据。 事例：程序员拿着信用卡去享受生活（卡里当然是只有3.6万），当他埋单时（程序员事务开启），收费系统事先检测到他的卡里有3.6万，就在这个时候！！程序员的妻子要把钱全部转出充当家用，并提交。当收费系统准备扣款时

NoSQL入门和概述目录导航： NoSQL入门概述 3V+3高 当下的NoSQL经典应用 NoSQL数据模型简介 NoSQL数据库的四大分类 在分布式数据库中CAP原理CAP+BASE NoSQL 入门概述 互联网时代背景下的大机遇，为什么用NoSQL 单机MySQL的美好年代 在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站不多。 上述架构下，我们来看看数据存储的瓶颈是什么？ 数据量的总大小，一个机器放不下时 数据的索引（B+ Tree）一个机器的内存放不下时 访问量（读写混合）一个实例不能承受 如过满足了上述1 or 3个，需要进化... Memcached（缓存）+ MySQL + 垂直拆分 后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使 用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能 共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。 Memcached作为一个独立的分布式的缓存服务器

概念 MySQL 事务主要用于处理操作量大，复杂度高的数据。比如说，在人员管理系统中，你删除一个人员，你即需要删除人员的基本资料，也要删除和该人员相关的信息，如信箱，文章等等，这样，这些数据库操作语句就构成一个事务！ 在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务。 一般来说，事务是必须满足4个条件（ACID）：：原子性（Atomicity，或称不可分割性）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability） 原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。 隔离性：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化

MongoDB 4.2已经发布，我们来看看它增加了哪些新特性？分布式事务？数据库加密？通配符索引？ 在2019年MongoDB World大会上，CTO Eliot Horowitz介绍了MongoDB 4.2中的一些功能，这些功能扩展了其在数据库技术方面的领先地位：分布式事务（Distributed Transactions），字段级加密（Client Side Field Level Encryption），通配符索引（Wildcard Indexing）、按需物化视图（Materialized Views）。 这些都是重大的改进，表明MongoDB在企业级功能方便更加完善。 MongoDB 4.2提升了事务和分析技术水平。它提供大规模的分布式事务的ACID担保和复杂的数据处理流程，还有最先进的加密控制保护机制。我们可以在任何地方运行MongoDB4.2：在本地数据中心，云上、混合云、Atlas云上。我们可以获得阿里云、AWS，Azure和GCP可用的完全托管，云原生的MongoDB服务。阿里云全球第一个实现了MongoDB异地多活架构。可以支持互联网跨国公司的大规模出海业务。 现在使用MongoDB的公司越来越多了，技术架构方案也越来越成熟。MongoDB新特性也是为了满足更多的企业级业务场景需求。 1. MongoDB 4.2 新特性 先来大体上看看有哪些改进，作为4

简介 SQLite，是一款轻型的数据库，是遵守ACID的关系型数据库管理系统。它的设计目标是嵌入式的，目前Android和iOS的设备内置的都是SQLite数据库。SQLite虽然娇小，但也支持事务和多数的SQL92标准。 主要特点 Zero-Configuration 无需安装和管理配置。 Serverless 无需服务器支持。 Single Database File 数据文件存储在一个单一的磁盘文件。 Stable Cross-Platform Database File 数据库文件格式跨平台，无论是大小端，或者是32bit或64bit机器都没有关系 Compact 完整特性的SQLite编译出来在500KiB左右，裁剪特性甚至可以得到低于300KiB的库（当前版本3.8.11.1）。 Manifest typing 可以声明数据库字段类型，但是字段存储的类型实际的存储类型和实际值相关，单独的一个字段可能包含不同存储类的值。 Variable-length records 可变长度记录，例如你存储一个字符到VARCHAR(100) 的列，实际需要的存储空间一个字符加一个字节的存储空间。 SQL statements compile into virtual machine code SQL语句会被编译成虚拟机代码，这种虚拟机代码直白可读，便于调试。 Public domain

在我眼里，MySQL和Oracle是这样的 而SQLite在是这样的 所以这么萌的数据库，我真的应该多了解她的。 简介 SQLite，是一款轻型的数据库，是遵守ACID的关系型数据库管理系统。它的设计目标是嵌入式的，目前Android和iOS的设备内置的都是SQLite数据库。 SQLite虽然娇小，但也支持事务和多数的SQL92标准。 主要特点 1. Zero-Configuration 无需安装和管理配置。 2. Serverless 无需服务器支持。 3. Single Database File 数据文件存储在一个单一的磁盘文件。 4. Stable Cross-Platform Database File 数据库文件格式跨平台，无论是大小端，或者是32bit或64bit机器都没有关系 5. Compact 完整特性的SQLite编译出来在500KiB左右，裁剪特性甚至可以得到低于300KiB的库（当前版本3.8.11.1）。 6. Manifest typing 可以声明数据库字段类型，但是字段存储的类型实际的存储类型和实际值相关，单独的一个字段可能包含不同存储类的值。 7. Variable-length records 可变长度记录，例如你存储一个字符到VARCHAR(100) 的列，实际需要的存储空间一个字符加一个字节的存储空间。 8. SQL statements

文章目录 binlog 的写入流程 redo log 写入流程 组提交 组提交优化 总结 binlog 的写入流程 事务执行过程中，binlog 首先会被写到 binlog cache 中；事务提交的时候，再讲binlog cache 写到 binlog 文件中。一个事务的 binlog 是原子的，无论多大都需要保证完整性。 系统为每个客户端线程分配一个 binlog cache，其大小由 binlog_cache_size 控制。如果binlog cache 超过阀值，就会临时持久化到磁盘。当事务提交的时候，再将 binlog cache 中完整的事务持久化到磁盘中，并清空 binlog cache。 从上面可以看出，每个客户端线程都有自己独立的 binlog cache，但是会共享一份 binlog files。 上面的 write 是指把binlog cache 写到文件系统的 page cache，并没有写入到磁盘中，因此速度较快。 fsync 是实际的写盘操作，占用磁盘的 IOPS。 write 和 fsync 的写入时机，是由sync_binlog 控制的： sync_binlog=0：每次事务提交都只 write，不 fsync； sync_binlog=1：每次事务提交都会fsync； sync_binlog=N（N>1）：每次提交事务都会 write，累计N

文章目录 按表分发策略 按行分发策略 MySQL5.6 的并行复制 MariaDB 的并行复制 MySQL5.7 的并行复制 MySQL5.7.22 的并行复制 前面介绍的MySQL 的主从复制流程如下所示： 主备延迟的主要原因在于，master A 上产生 binlog 的速度大于slave B 处理 binlog 的速度。数据的积压就在于 sql_thread 处理的速度。在 MySQL 5.6 版本之前，只支持单线程复制。单线程的 binlog 复制，在高并发的场景下会出现严重的主从不一致。要解决这个问题，就需要将上面的 sql_thread 拆解成为多个线程处理。 上图中的 coordinate 就是本文开始的 sql_thread，具体执行 binlog 复制的是 Worker。生产上，Worker 的个数设置为 8-16 个比较合适（32核CPU），因为从库还需要可能还需要处理读的请求。 对于 coordinate 的分发策略，并不能是随机的，因为这样对于SQL 执行不同的顺序，可能会产生不同的结果。此时对于 coordinate 的分发策略要求如下： 不能造成更新覆盖，同一行的更新必须被分发到同一个Worker 中； 同一个事务不能被拆开，必须被分配到同一个Worker 中。 按表分发策略 按表分发的基本思路是，如果两个事务更新不同的表，就可以并行处理。此时因为在不同

各位老铁们，本周老张的《MySQL王者晋级之路》一书终于出版了，现在可以预购啦！ 预购链接地址： 老张的数据库微店 前前后后经历了一年的准备时间，可谓十年磨一剑，把自己从业所有的精华和心血都灌输到其书中。其书中包含了MySQL方方面面的知识点，是之前我的一篇博客“从青铜到王者，快速提升你MySQL数据库段位的全面深入剖析”。用一句学生对我说得话，老师喜欢您的王者荣耀情怀，但更喜欢您的技术情操。讲真，不要错过！特别感谢在我从事技术道路上，帮助过我的前辈及兄弟们，这条路上的所有的辛酸，只有你们最懂我！也要感谢对我博客一直支持的兄弟们！ 今儿的这篇博文，可以让大家快速了解GTID特性，并能灵活地运用到生产环境中，希望对大家有帮助。 GTID原理介绍 GTID又叫全局事务ID（Global Transaction ID），是一个已提交事务的编号，并且是一个全局唯一的编号。MySQL5.6版本之后在主从复制类型上新增了GTID复制。 GTID是由server_uuid和事务id组成的，即GTID = server_uuid:transaction_id。 server_uuid是在数据库启动过程中自动生成的，每台机器的server-uuid不一样。uuid存放在数据目录的auto.cnf文件下。而transaction_id就是事务提交时由系统顺序分配的一个不会重复的序列号。

前言： 什么是事务？ 事务是程序中一系列严密的操作，所有操作执行必须成功完成，否则在每个操作所做的更改将会被撤销，这也是事务的原子性（要么成功，要么失败）。 MySQL的事务是在存储引擎层实现。 MySQL的事务有ACID A：原子性(atomicity)：一个事务必须被视为一个不可分割的单元。 C：一致性(consistency)：数据库是从一种状态切换到另一种状态。 I：隔离性(isolation)：事务在提交之前，对于其他事务不可见。 D：持久性(durablity)：一旦事务提交，所修改的将永久保存到数据库。 1、事务的基本语法 <!--创建表--> mysql> create table bank -> ( -> name varchar(25), -> money float -> ); Query OK, 0 rows affected (0.00 sec) mysql> insert into bank values('lu','1000'),('qi','5000'); <!--插入数据--> Query OK, 2 rows affected (0.00 sec) Records: 2 Duplicates: 0 Warnings: 0 mysql> begin; <!--begin开启事务，start transaction也可开启事务--> Query OK