InnoDB

加锁是实现数据库并发控制的一个非常重要的技术。当事务在对某个数据对象进行操作前，先向系统发出请求，对其加锁。加锁后事务就对该数据对象有了一定的控制，在该事务释放锁之前，其他的事务不能对此数据对象进行更新操作。 什么是锁？ 锁是计算机协调多个进程或线程并发访问某一资源的机制 。 锁保证数据并发访问的一致性、有效性； 锁冲突也是影响数据库并发访问性能的一个重要因素。 锁是Mysql在服务器层和存储引擎层的的并发控制。 为什么要加锁 数据库是一个多用户使用的共享资源。当多个用户并发地存取数据时，在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据，破坏数据库的一致性。 锁是用于管理对公共资源的并发控制。 也就是说在并发的情况下，会出现资源竞争，所以需要加锁。 加锁解决了 多用户环境下保证数据库完整性和一致性。 Lock的对象是事务，用来锁定的是数据库中的对象，如表、页、行。并且一般lock的对象仅在事务commit或rollback后进行释放（不同事务隔离级别释放的时间可能不同）。 锁分类 共享锁||读锁||S 锁(share lock)：其他事务可以读，但不能写。允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。 排他锁||写锁||X 锁(exclusive） ：其他事务不能读取，也不能写。允许获得排他锁的事务更新数据

个人博客网： https://wushaopei.github.io/ (你想要这里多有) 一、锁的概述 1、锁的定义 锁是计算机协调多个进程或线程并发访问某一资源的机制。 在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发性能的一个重要因素。从这个角度来说，锁对于数据库而言显得尤其重要，也更加复杂。 2、应用场景 - - 生活购物 打个比方，我们到淘宝上买一件商品，商品只有一件库存，这个时候如果还有另一个人买， 那么如何解决是你买到还是另一个人买到的问题？ ​ 这里肯定要用到事务，我们先从库存表中取出物品数量，然后插入订单，付款后插入付款表信息，然后更新商品数量。在这个过程中，使用锁可以对有限的资源进行保护，解决隔离和并发的矛盾。 3、锁的分类 3.1 从对数据 操作的类型 （读/写）分： 读锁、写锁 读锁（共享锁） ： 针对同一份数据，多个读操作可以同时进行而不会互相影响 写锁（排它锁）：当前写操作没有完成前，它会阻断其他写操作和读操作 3.2 从对数据 操作的粒度 分： 表锁、行锁 二、表锁 1、特点 偏向MyISAM存储引擎，开销小，加锁快；无死锁；锁定力度大，发生锁冲突的概率最高，并发度最低。 2、案例分析 2.1 建立SQL

用于搜索引擎抓取，以及给刚进来的人展示我的报错信息，解决方案在下面。 MySQL57 服务正在启动 . MySQL57 服务无法启动。 服务没有报告任何错误。 请键入 NET HELPMSG 3534 以获得更多的帮助。 2020-12-15T00:39:28.143958Z 0 [ERROR] InnoDB: The innodb_system data file ‘ibdata1’ must be writable 2020-12-15T00:39:28.143958Z 0 [ERROR] InnoDB: The innodb_system data file ‘ibdata1’ must be writable 2020-12-15T00:39:28.144910Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error 2020-12-15T00:39:28.346376Z 0 [ERROR] Plugin ‘InnoDB’ init function returned error. 2020-12-15T00:39:28.346376Z 0 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed. 2020-12

Ⅰ、死锁的概念 两个或两个以上的事务在执行过程中,因争夺资源而造成的一种互相等待的现象 最常见：AB-BA 稍微复杂：A-B B-C C-A形成如下图的循环 tips： lock wait time out 和 dead lock不是一回事 1.1 死锁的处理机制 锁超时 --innodb_lock_wait_timeout 让一个超时另一个执行,但这个机制在数据库中是不用的 自动死锁检测 通过锁的信息链表和事务等待链表构造出一个等待图(wait-for graph),如下: t1 t2 t3 t4 是事务列表,四个事务之间的边表示等待关系——edge,每个节点(事务)和每个edge加进去的时候会判断下有没有回路,如果有,就那啥,懂的吧? 检测到了后会很聪明地选择其中一个事务回滚,那选择哪个呢？ 根据undo的量判断,回滚量少的,不记得是5.5还是5.6开始才有这个机制,之前的数据库版本是直接回滚后面一个事务,比较挫 5.6版本对图的死锁检测部分的内核算法进行了优化,原来是递归的方式做的,现在通过重写,非递归,提升了性能,所以大并发时5.6性能比5.5好很多,这块也有功劳 Ⅱ、死锁演示 2.1 先模拟下场景 begin： session1： select a for update; session2: begin： select b for update; select a for

前言 说起 MySQL 的查询优化，相信大家收藏了一堆： 不能使用SELECT *； 不使用NULL字段； 合理创建索引； 为字段选择合适的数据类型..... 你是否真的理解这些优化技巧？是否理解其背后的工作原理？你对MySQL了解多少？如果你可以熟练的写出SQL，那么在各个客户端里玩的游刃有余也是很容易的。 前段时间，跳槽到大厂的一位朋友，给我分享了一批MySQL的学习资料大集合，全是干货，都是他在工作中遇到的以及用到的。主要包括： MySQL面试题、MySQL从入门到精通、MySQL基础到高级到调优笔记、MySQL知识总结、MySQL性能调优与架构设计解析文档， 已打包好，文末有免费获取方式。 Part1 MySQL高频面试题及答案解析 进了互联网公司，整天也就是搬砖，等到了面试的时候，发现数据库方面，忘得一塌糊涂，抽时间整理了一些数据库方面的题。 下面是在面试中经常遇见的MySQL面试题清单（都是真材实料，用心整理）： 答案解析： Part2 重学MySQL：从入门到精通 主要包括 MySQL的安装与配置 、 数据库的创建 、 数据表的创建 、 数据类型和运算符 、 MySQL函数 、 查询数据 、 数据表的操作 (插入、更新与删除数据)、 索引 、 存储过程和函数 、 视图 、 触发器 、 用户管理 、 数据备份与恢复 、 日志以及性能优化 等

一、支持的数据类型： 数值类型： 类型 大小 范围（有符号） 范围（无符号） 用途 TINYINT 1 byte (-128，127) (0，255) 小整数值 SMALLINT 2 bytes (-32 768，32 767) (0，65 535) 大整数值 MEDIUMINT 3 bytes (-8 388 608，8 388 607) (0，16 777 215) 大整数值 INT或INTEGER 4 bytes (-2 147 483 648，2 147 483 647) (0，4 294 967 295) 大整数值 BIGINT 8 bytes (-9,223,372,036,854,775,808，9 223 372 036 854 775 807) (0，18 446 744 073 709 551 615) 极大整数值 FLOAT 4 bytes (-3.402 823 466 E+38，-1.175 494 351 E-38)，0，(1.175 494 351 E-38，3.402 823 466 351 E+38) 0，(1.175 494 351 E-38，3.402 823 466 E+38) 单精度 浮点数值 DOUBLE 8 bytes (-1.797 693 134 862 315 7 E+308，-2.225 073 858 507 201 4 E

点击上方 “ 码农沉思录 ” ，选择“设为星标” 优质文章，及时送达 日常在CURD的过程中，都避免不了跟数据库打交道，大多数业务都离不开数据库表的设计和SQL的编写，那如何让你编写的SQL语句性能更优呢？ 先来整体看下MySQL逻辑架构图： MySQL整体逻辑架构图可以分为Server和存储引擎层。 Server层： Server层涵盖了MySQL的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），以及存储过程、触发器、视图等跨存储引擎的实现也在这一层来实现。 连接器：负责跟客户端建立连接、获取权限、维持和管理连接。 分析器：SQL词法分析，SQL语法分析 优化器：索引选择，选择一个执行效率高的，生成执行计划 执行器：操作引擎，返回执行结果 ... 查询缓存：执行SQL语句之前，先查缓存，缓存结果可能是以key-value对方式存储的，key 是查询的语句，value 是查询的结果。 存储引擎层： 负责数据的存储和提取，是一种插件式的架构方式。支持 InnoDB、MyISAM、Memory 等多个存储引擎。MySQL 5.5.5版本开始默认存储引擎是 InnoDB，也是目前常用的存储引擎。 今天我们来看下详细看下优化器里的执行计划如何分析，要分析一个 SQL 的执行效率，就要会看执行计划，根据执行计划优化 SQL，使其能达到高效查询的目的。

前言 MyISAM和InnoDB是MySQL最常用的两个存储引擎，本文将进行详尽的介绍和对比。 对于MySQL其余几种存储引擎，请读者自行搜索学习。 本文会图解两种引擎的索引结构区别，然后讲解索引的原理，理解本文内容，就能够理解索引优化的各种原则的背后原因。 限于篇幅，本篇没有介绍的知识，会在后续博客将逐一讲解。 例如： MySQL引擎的锁机制、多列索引的生效规则、索引优化等主题。 下面SQL在本篇介绍引擎的结构区别时使用的表结构，便于读者更好理解。 CREATE TABLE `user` ( `id` int ( 11 ) NOT NULL AUTO_INCREMENT COMMENT ' 唯一码 ' , `age` int ( 5 ) NOT NULL COMMENT ' 年龄 ' , `name` varchar ( 5 ) NOT NULL COMMENT ' 名字 ' , PRIMARY KEY ( `id` ), KEY `name` ( `name` ) ) ENGINE = InnoDB AUTO_INCREMENT= 92 DEFAULT CHARSET =utf8mb4; B-树、B树和B-tree是同一个数据结构，只不过英语翻译过来之后，有些人误解了以为是多种树。 所以好多讲解树的数据结构的博客完全是误导初学者。 。 。 请读者认真分辨。

mysql 配置 在mysql（5.6、5.7皆可）中创建数据库nacos，导入如下数据库初始化脚本： /* * Copyright 1999-2018 Alibaba Group Holding Ltd. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing

Percona XtraDB Cluster（下文简称PXC集群）提供了MySQL高可用的一种实现方法。PXC集群以节点组成（推荐至少3节点，便于故障恢复，后面会讨论两节点的情况），每个节点都是基于常规的 MySQL/Percona Server，意味着你可以从集群中分离出某节点单独使用。集群中每个节点都包含完整的数据。 PXC集群主要由两部分组成：Percona Server with XtraDB和Write Set Replication patches（使用了Galera library，一个通用的用于事务型应用的同步、多主复制插件）。 PXC的特性和优点： 支持多主复制 支持并行复制 读写强一致性 作为高可用方案，相比其他方案其结构和实施相对简单明了 PXC的局限和劣势： 由于PXC集群内部一致性控制的机制，事务有可能被终止，原因如下：集群允许在两个节点上通知执行操作同一行的两个事务，但是只有一个能执行成功，另一个 会被终止，同时集群会给被终止的客户端返回死锁错误(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)). 写入效率取决于节点中最弱的一台，因为PXC集群采用的是强一致性原则，一个更改操作在所有节点都成功才算执行成功。 所有表都要设置主键。 不支持LOCK TABLE等显式锁操作。 集群吞吐量/性能取决于短板。