mysql数据库

Reference： https://time.geekbang.org/column/article/117247 死锁产生 行锁的具体实现算法有三种：record lock、gap lock以及next-key lock。 record lock是专门对索引项加锁； gap lock是对索引项之间的间隙加锁； next-key lock则是前面两种的组合，对索引项及其之间的间隙加锁。 只在可重复读或以上隔离级别下的特定操作才会取得gap lock或next-key lock，在Select、Update和Delete时，除了基于唯一索引的查询之外，其它索引查询时都会获取gap lock或next-key lock，即锁住其扫描的范围。主键索引也属于唯一索引，所以主键索引是不会使用gap lock或next-key lock。 在MySQL中，gap lock默认是开启的，即innodb_locks_unsafe_for_binlog参数值是disable的，且MySQL中默认的是RR事务隔离级别。 当执行以下查询SQL时，由于order_no列为非唯一索引，此时又是RR事务隔离级别，所以SELECT的加锁类型为gap lock，这里的gap范围是(4,+∞）。 1 SELECT id FROM demo.order_record where order_no = 4 for

参考了这篇文章： http://www.cnblogs.com/LBSer/p/5183300.html 《 mysql死锁问题分析 》 写的不错。 如果Mysql死锁，会报出： 1.1 死锁成因&&检测方法 我们mysql用的存储引擎是innodb，从日志来看，innodb主动探知到死锁，并回滚了某一苦苦等待的事务。问题来了，innodb是怎么探知死锁的？ 直观方法是在两个事务相互等待时，当一个等待时间超过设置的某一阀值时，对其中一个事务进行回滚，另一个事务就能继续执行。这种方法简单有效，在innodb中，参数innodb_lock_wait_timeout用来设置超时时间。 仅用上述方法来检测死锁太过被动，innodb还提供了 wait-for graph算法 来主动进行死锁检测，每当加锁请求无法立即满足需要并进入等待时，wait-for graph算法都会被触发。 1.2 innodb隔离级别、索引与锁 1.2.1 锁与索引的关系 假设我们有一张消息表（msg），里面有3个字段。假设id是主键，token是非唯一索引，message没有索引。 id: bigint token: varchar(30) message: varchar(4096) innodb对于主键使用了 聚簇索引 ，这是一种数据存储方式，表数据是和主键一起存储，主键索引的叶结点存储行数据。对于普通索引

本文转载自： https://www.cnblogs.com/arli/p/6914057.html 作者：arli 转载请注明该声明。 0.先推荐一个工具——lombok,pom文件如下： < dependency > < groupId > org.projectlombok </ groupId > < artifactId > lombok </ artifactId > < scope > compile </ scope > </ dependency > 可以使用注解@Data 编译时自动生成get,set方法,构造函数,toString方法。 @Entity public class Account { @Id private String id; private String account; @Column(name = "call_phone" ) private String phone; @Column(name = "nick_name" ) private String nickname; private String password; private String salt; private int userType; private String createUser; private Timestamp createTime; private

解决ava.sql.SQLException: The server time zone value '乱码' 原因 1.mysql数据库与驱动的版本不匹配 我的mysql是8.0.16版本的 所以导入的驱动包版本要正确 <!-- mysql--> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.16</version> </dependency> 2.时区的问题 加上&&serverTimezone=GMT spring.datasource.url=jdbc:mysql://127.0.0.1:3306/springboot?characterEncoding=UTF-8&&serverTimezone=GMT spring.datasource.username=root spring.datasource.password=***** 来源： https://www.cnblogs.com/mengxiaoleng/p/12207826.html

今天测试Linux 各个软件源 ，发现mysql 配置官方源之后，yum install -y mysql 安装了 mysql lastst 最新版， 安装完之后，奇葩的是没有提示输入密码， 所以 mysql 可以进入 提示输入密码，没有密码， 再经过几个折腾，包括什么跳过密码验证等等方法试过之后还是不行，发现直接查日志最为方便， 翻遍各种配置文件，改来该去 /etc/my.cnf mysql主配置文件 // 在这个配置文件结尾加上 skip-grant-tables 可以跳过密码验证 /var/lib/mysql 数据库文件存放位置 /var/log mysql 数据库的日志输出存放位置 查看文档之后发现，mysql 在初次启动之后，会生成一个随机初始密码， 可以从日志中 筛选 到 ， cat var/log/mysqld.log |grep password 就可以查询到当时的密码， 如图所示 这个初始密码第一次登陆是必须要修改的，所以使用这个密码登录之后，改为自己设置的密码 ALTER USER 'root'@'localhost' IDENTIFIED BY '你的密码'; 新密码设置的时候如果设置的过于简单会报错，所以必须设置得复杂一些。 来源： https://www.cnblogs.com/thelovelybugfly/p/12207552.html

canal 基于Mysql数据库增量日志解析  1.前言  最近太多事情 工作的事情，以及终身大事等等 耽误更新，由于最近做项目需要同步监听 未来电视 mysql的变更了解到公司会用canal做增量监听，就尝试使用了一下 这里做个demo 简单的记录一下。  2.canal简介  canal：主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费的中间件 当前的 canal 支持源端 MySQL 版本包括 5.1.x , 5.5.x , 5.6.x , 5.7.x , 8.0.x  3.MySQL 注备复制原理   3.1 mysql主备复制工作原理   1.MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件binary log events，可以通过 show binlog events 进行查看)  2.MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)  3.MySQL slave 重放 relay log 中事件，将数据变更反映它自己的数据   3.2 canal 工作原理   1.canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送dump 协议  2

特点 原子性(Atomicity),一致性(Consistency),隔离型(Isolation)以及持久性(Durability) 一、事务的目的 1、可靠性和并发处理 可靠性：数据库要保证当insert或update操作时抛异常或者数据库crash的时候需要保障数据的操作前后的一致，想要做到这个，我需要知道我修改之前和修改之后的状态，所以就有了undo log和redo log。 并发处理：也就是说当多个并发请求过来，并且其中有一个请求是对数据修改操作的时候会有影响，为了避免读到脏数据，所以需要对事务之间的读写进行隔离，至于隔离到啥程度得看业务系统的场景了，实现这个就得用MySQL 的隔离级别。 二、实现事务功能的三个技术 1、日志文件(redo log 和 undo log) 2、锁技术 3、MVCC 1.1 redo log 与 undo log介绍 1.1.1redo log 什么是redo log ? redo log叫做重做日志，是用来实现事务的持久性。该日志文件由两部分组成：重做日志缓冲（redo log buffer）以及重做日志文件（redo log）,前者是在内存中，后者在磁盘中。 当事务提交之后会把所有修改信息都会存到该日志中。假设有个表叫做tb1(id,username) 现在要插入数据（3，ceshi） start transaction; select

事物机制 5.0版本后出现的,解决: 避免写入直接操作数据文件,直接操作数据文件是很危险的事 MySQL有5种日志文件,其中只有redo日志和undo日志与事物有关 RDBMS=SQL语句 + 事务(ACID) 原子性 事务是一个或者多个SQL语句组成的整体,要么全部执行成功,要么全都执行失败 ,事务执行之后,不允许停留在中间某个状态 把10部门中MANGER员工调往20部门,其他岗位员工调往30部门,然后删除10部门 事务: 开启事务 UPDATE语句 DELETE语句 提交事务 默认情况下,MySQL执行每条SQL语句都会自动开启和提交事务 为了让多条SQL语句纳入一个事务下,可以手动管理事务 START TRANSACTION; SQL语句 [COMMIT | ROLLBACK]; COMMIT:持久化提交 ROLLBACK:回滚 START TRANSACTION; -- 启动事务机制 delete from t_emp; delete from t_dept; SELECT * FROM t_emp; SELECT * FROM t_dept; -- COMMIT; -- 提交同步(给注释掉了) ROLLBACK ; -- 回滚不同步 事务的一致性 不管在任何给定的时间\并发事务有多少, 事务必须保证运行结果的一致性,不允许数据歧义 隔离性

1、子查询（Where） where （这个值是计算出来的） 本质 ： 在where语句中嵌套一个子查询语句 -- ================ where ================= -- 1、查询 数据库结构-1 的所有考试结果（学号，科目编号，成绩），降序排列 -- 方式一： 使用连接查询 SELECT `StudentNo`,r.`SubjectNo`,`StudentResult` FROM `result` r INNER JOIN `subject` sub ON r.SubjectNo = sub.SubjectNo WHERE SubjectName = '数据库结构-1' ORDER BY StudentResult DESC -- 方式二： 使用子查询（由里及外） -- 查询所有数据库结构-1 的学生学号 SELECT `StudentNo`,`SubjectNo`,`StudentResult` FROM `result` WHERE SubjectNo = ( SELECT SubjectNo FROM `subject` WHERE SubjectName = '数据库结构-1' ) ORDER BY StudentResult DESC -- 查询课程为 高等数学-2 且分数不小于 80 的同学的学号和姓名 SELECT s

order by 的排序优化 1、 ORDER BY 子句尽量使用index方式排序，避免使用filesort方式排序。 2、ORDER BY 满足两种方式会使用index方式排序： order by使用索引最左前列 使用where 子句与order by 子句条件列组合满足索引最左前列 3、如果不在索引列上，filesort有两种算法，mysql就要启动双路和单路排序. 双路排序 （1）mysql4.1之前是使用双路排序，两次扫描磁盘，最终得到数据，读取行指针和order by列，对他们进行排序，然后扫描已经排好序的列表，按照列表中的值重新从数据库列表中读取对应的数据输出。 （2）从磁盘读取字段，在buffer中进行排序，再从磁盘取其他字段。 （3）取一批数据，要扫描两次磁盘，进行两次I/O操作，由于I/O操作很耗时，索引在4.1之后采用另一种算法，单路排序。 单路排序 从磁盘中读取查询所需要的列，按照order by列在buffer进行排序，然后扫描排序后的列表进行输出，它的效率更高一点，避免了第二次读取数据。并且随机I/O变成了顺序I/O，但是它会使用更大的内存空间，因为它把数据都保存在内存当中。 注意 在sort buffer中，单路排序比双路排序使用了更多的内存空间，因为单路排序把所有字段都取出，所有有可能导致取出的数据总大小超出sort_buffer的容量