mysql事务

基于GTID的复制 简介 基于GTID的复制是MySQL 5.6后新增的复制方式. GTID (global transaction identifier) 即全局事务ID, 保证了在每个在主库上提交的事务在集群中有一个唯一的ID。 在原来基于日志的复制中, 从库需要告知主库要从哪个偏移量进行增量同步, 如果指定错误会造成数据的遗漏, 从而造成数据的不一致. 而基于GTID的复制中, 从库会告知主库已经执行的事务的GTID的值, 然后主库会将所有未执行的事务的GTID的列表返回给从库. 并且可以保证同一个事务只在指定的从库执行一次。 GTID开启配置如下： SHOW VARIABLES LIKE '%GTID%'; 结果： 实战 1、在主库上建立复制账户并授予权限 基于GTID的复制会自动地将没有在从库执行的事务重放, 所以不要在其他从库上建立相同的账号. 如果建立了相同的账户, 有可能造成复制链路的错误. mysql> create user 'repl'@'172.%' identified by '123456'; 注意在生产上的密码必须依照相关规范以达到一定的密码强度, 并且规定在从库上的特定网段上才能访问主库. mysql> grant replication slave on *.* to 'repl'@'172.%'; 查看用户 mysql> select user,

MySQL Replication 大家都非常熟悉了，我也不会写怎么搭建以及复制的原理，网上相关文章非常多，大家可以自己去搜寻。我在这里就是想总结一下mysql主从复制需要注意的地方。有人说主从复制很简单嘛，就是master，slave的server_id不一样就搞定。确实，简单的来说就是这么简单。但是真正在生产环境我们需要注意的太多了。首先说说主库宕机或者从库宕机后复制中断的问题。 虽然很多知识点或许我博客其他文章中都有提到过，或者重复了，但是我还是想总结一下。 主库意外宕机 如果没有设置主库的sync_binlog选项，就可能在奔溃前没有将最后的几个二进制日志事件刷新到磁盘中。备库I/O线程因此也可一直处于读不到尚未写入磁盘的事件的状态中。当主库从新启动时，备库将重连到主库并再次尝试去读该事件，但主库会告诉备库没有这个二进制日志偏移量。解决这个问题的方法是指定备库从下一个二进制日志的开头读日志。但是一些事件将永久丢失。可以使用前面文章提到的工具来检查主从数据一致以及修复 pt-table-checksum 。即使开启了sync_binlog，myisam表的数据仍然可能在奔溃的时候损坏。对于innodb表，如果innodb_flush_log_at_trx_commit没有设置为1，也可能丢失数据，但是数据不会损坏。 因此主库的参数建议开启 sync_binlog=1

上一篇 关于事务与锁的文章 最后其实留下了一个悬而未决的问题。像 SELECT ... LOCK IN SHARE MODE; 这种可能会扫表的操作，明确会添加的是IS锁，剩下会加哪些锁其实和具体的 WHERE 子句有关。那么到底有几个锁实例的存在怎么确定呢？ mysql > SELECT * FROM account ; + ----+------------+---------+ | id | account_id | balance | + ----+------------+---------+ | 1 | 10 | 3000 | | 2 | 20 | 3000 | | 3 | 30 | 3000 | + ----+------------+---------+ 3 rows in set ( 0.01 sec ) mysql > SELECT * FROM account WHERE account_id < 10 LOCK IN SHARE MODE ; Empty set ( 0.04 sec ) mysql > SHOW ENGINE INNODB STATUS \G ; ---TRANSACTION 476C0DC, ACTIVE 29 sec 3 lock struct ( s ) , heap size 376 , 2 row lock ( s ) MySQL

MySQL 的逻辑架构图设计图 连接/线程处理： 管理客户端连接/会话[mysql threads] 解析器： 通过检查SQL查询中的每个字符来检查SQL语法，并 为每个SQL查询 生成 SQL_ID 。 此外，身份验证检查（用户凭据）将在此阶段发生。 优化程序： 根据存储引擎创建有效的查询执行计划。 它将重写一个查询。 示例：InnoDB具有共享缓冲区，因此优化器将从中获取预缓存的数据。 使用表统计信息优化器将为SQL查询生成执行计划。 授权检查（用户访问权限）将在此阶段发生。 元数据缓存： 缓存对象元数据信息和统计信息。 查询缓存： 来自内存的共享相同查询。如果在查询缓存中找到来自客户端的相同查询，则MySQL服务器从查询缓存中检索结果，而不是再次解析和执行该查询。 它是会话的共享缓存，因此可以发送一个客户端生成的结果集以响应另一个客户端发出的相同查询。 查询缓存基于 SQL_ID .SELECT数据进入视图是使用查询缓存预缓存数据的最佳示例。 密钥缓存： 缓存表索引。在 MySQL 中密钥是索引（在oracle密钥是约束），如果索引大小小，那么它将缓存索引结构和数据叶。如果索引很大，那么它将只缓存索引结构。由MyISAM 使用存储引擎。 存储引擎： 管理物理数据（文件管理）和位置的MySQL组件。 存储引擎负责执行SQL语句并从数据文件中获取数据。 用作插件

MYISAM 不支持事务，是mysql5.6之前最常用的非事务存储引擎。 查询速度相对较快，但读写都会对数据加锁，在频繁读写业务中容易产生大量阻塞，影响整体性能 CSV 不支持事务，以csv格式存储的非事务存储引擎。 由于不支持事务，读写时会对数据加锁。通常用在不同系统间的数据交换，但不建议作为业务核心引擎来存储数据 Archive 不支持事务，只允许查询和新增数据而不允许修改的非事务存储引擎。 常用在归档类日志，这种只会新增而不会修改的数据中，另外Archive存储占用的物理空间更小 Memory 不支持事务，是一种易失性非事务存储引擎，数据存储在内存中。 特点是速度快，但mysql一旦重启，数据对消失。 主要用处是在mysql内部，在执行一些大sql过程中，需要存储临时中间结果的数据集，且这数据在符合某种条件下会将中间数据集存储在Memory种以加快sql执行速度 INNODB 支持事务，最常用的事务性存储引擎，5.7之后的默认存储引擎，一般如果没什么特别的要求，都会选这个引擎 INNODB引擎按主键顺序聚集存储，主键本身也会占用物理空间，因此主键的大小会影响查询效率。 另外数据是按主键逻辑顺序来存储，若主键顺序经常无缘变化，会造成数据迁移，带来IO性能的消耗。因此在一般情况下，建议使用自增ID为主键 在需要事务支持的场景中，一定不要混合使用事务存储引擎和非事务存储引擎

什么是事务 事务是数据库执行操作的最小单元 事务可以有一个sql组成，也可以由多个sql组成 组成事务的sql要么全执行成功，要么全执行失败 事务的语法 START TRANSACTION / BEGIN SELECT ... UPDATE ... INSERT ... COMMIT / ROLLBACK 用start transaction 或者 begin 开始一个事务 中间只能是dml语句，增删改查 commit：提交1个事务 rollback：回滚1个事务 为什么要有事务 允许多个人同时操作相同得数据，是为了增强数据库的并发性，并发能带给更大的吞吐量，更优的资源利用率和更好的性能 但并发也会带来问题，比如多个用户同时修改数据时，容易破坏数据的一致性，为了解决并发带来的资源争用和一致性问题，mysql提供了 事务功能和基于锁的多版本控制机制 persist ：修改后对当前的session和所有连接到mysql中的新连接都有效，且在mysql重启后也不会丢失 global ：修改后只会对新的连接到mysql的连接有效，且mysql重启后，做的修改会丢失 session ：（对开发人员来说是最常使用的）只会影响到当前的连接，当连接断开后，所做的修改就会失效 ####将事务设置为SERIALIZABLE的示例 serializable 如上图示，在串行化事务隔离级别中

MySql 非关系型数据库--稳定--开源 事务 逻辑上的一组操作，要么都执行，要么都不执行。 事务的ACID: 原子性（Atomicity） :事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行; 一致性（Consistency） :事务应确保数据库的状态从一个一致状态转变为另一个一致状态，一致状态的含义是数据库中的数据应满足完整性约束。(应该类似于物理上的能量守恒吧，能量之间互相转换，不会凭空消失与产生)； 隔离性（Isolation） ：多个事务并发执行时，一个事务的执行不应影响其他事务的执行； 持久性（Durability） ：已被提交的事务对数据库的修改应该永久保存在数据库中，宕机也可以恢复。 事务并发所产生的的问题 脏读（Dirty read）： A事务读取了B事务未提交的数据，A事务读到的数据就是脏数据。 丢失修改（Lost to modify）： A事务与B事务读取同一数据，A事务先对该数据进行修改，B后再进行修改，B修改的结果会对A做的修改进行覆盖，导致A修改的数据丢失。 不可重复读 （Unrepeatableread）： A事务开启，在此事务内多次访问某数据，期间B事务对该数据进行了修改，在A事务内两次独读到的该数据可能会不一致。 幻读 （Phantom read）：A事务读取了部分数据，B事务又插入了一些数据，A事务再次读取时

一、御前 1 win+R DOS 输入 net start mtsql 和 net stop mysql 启动和停止Mysql 服务，也可通过计算机——管理——服务和应用程序——服务——MYSQL——右击 启动mysql服务出现服务名无效的原因及解决方法【失败】 问题原因：mysql服务没有安装。 解决办法： 在 mysql bin目录下 以管理员的权限 执行 mysqld -install命令 以管理员的权限 mysqld -remove ，卸载mysql服务 2 登录和退出 路径： DOS：mysql -uroot -p 输入密码 exit; 退出 show databases; 查看数据库 Command Line Client登录和退出 3 常见操作 \h 或者 help; source D:\test.sql 即执行test.sql文件 4 图形 MYSQL Workbench 另外介绍第三方 SQLyog 二、数据库和表的基本操作 1、MySQL支持的数据类型 1）数值类型 字符串类型 日期和时间类型 2）数据库基本操作 CREATE DATABASE 数据库名称; SHOW DATABASE; SHOW CREATE DATABASE 数据库名称; 查看已经创建的数据库的创建信息 CREATE DATABASE 数据库名称 CHARACTER SET gbk;

前言 遇到Mysql死锁问题，我们应该怎么排查分析呢？之前线上出现一个insert on duplicate死锁问题，本文将基于这个死锁问题，分享排查分析过程，希望对大家有帮助。 死锁案发还原 表结构： CREATE TABLE `song_rank` ( `id` int(11) NOT NULL AUTO_INCREMENT, `songId` int(11) NOT NULL, `weight` int(11) NOT NULL DEFAULT '0', PRIMARY KEY (`id`), UNIQUE KEY `songId_idx` (`songId`) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 隔离级别： mysql> select @@tx_isolation; +-----------------+ | @@tx_isolation | +-----------------+ | REPEATABLE-READ | +-----------------+ 1 row in set, 1 warning (0.00 sec) 数据库版本： +------------+ | @@version | +------------+ | 5.7.21-log | +------------+ 1 row in

知乎锁总结 https://zhuanlan.zhihu.com/p/29150809 使用 RC隔离级别 精心设计索引 ， 并尽量使用索引访问数据， 使加锁更更精确， 从而减少锁冲突的机会 选择 合理的事务大小 ，小事务发生锁冲突的几率也更小 给记录集显式加锁时， 最好⼀次性请求足够级别的锁 。⽐比如要修改数据的话，最好直接申请排 他锁，而不是先申请共享锁，修改时再请求排他锁，这样容易产生死锁 不同的程序访问⼀组表时，应尽量 约定以相同的顺序访问各表 ，对⼀个表而言，尽可能以固定 的顺序存取表中的行。这样可以大大减少死锁的机会 尽量 用相等条件访问数据 ，这样可以避免间隙锁对并发插入的影响 除非必须，查询时不要显式加锁 。 MySQL的MVCC可以实现事务中的查询不⽤用加锁，优化事务 性能；MVCC只在COMMITTED READ（读提交）和REPEATABLE READ（可重复读）两种隔 离级别下⼯工作 来源： https://www.cnblogs.com/oklizz/p/11454358.html