Mysql

一、锁的概述 在计算机中，锁是协调多个过程或线程并发拜访某一资源的一种机制。 在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。 如何保证数据并发拜访的一致性、有效性是所有数据库必须解决的一个问题，锁抵触也是影响数据库并发拜访性能的一个重要因素。 从这个角度来说，锁对数据库而言显得尤其重要，也更加简单。 二、锁的分类 2.1 按数据操作的类型分类： 读锁（共享锁）：针对同一份数据，多个读操作能够同时进行而不会相互影响。写锁（排它锁）：以后操作没有实现之前，它会阻断其余的写操作或读操作。2.2 按数据操作的粒度分： 表锁：操作时，会锁定整个表。开销小，加锁快；不会呈现死锁；锁定力度大，产生锁抵触概率高，并发度最低。行锁：操作时，会锁定以后操作的表的某些行。开销大，加锁慢；会呈现死锁；锁定粒度小，产生锁抵触的概率低，并发度高。页锁：操作时，会锁定以后操作的表的某些页。开销和加锁速度介于表锁和行锁之间；会呈现死锁；锁定粒度介于表锁和行锁之间，并发度个别。很难抽象地说哪种锁更好，只能就具体利用的特点来说哪种锁更适合！ 仅从锁的角度来说，表级锁更适宜于以查问为主，只有大量按索引条件更新数据的利用，如Web 利用；而行级锁则更适宜于有大量按索引条件并发更新大量不同数据，同时又有并查问的利用，如一些在线事务处理（OLTP）零碎。 三、MySQL的锁 绝对其余数据库而言，MySQL的锁机制比较简单，其最显著的特点是不同的存储引擎反对不同的锁机制。InnoDB存储引擎反对行锁和表锁，MEMORY和MyISAM等存储引擎只反对表锁。 3.1 MyISAM的表锁 MyISAM存储引擎在执行查问语句（SELECT），会主动给波及的所有表加读锁，在执行更新操作（UPDATE、DELETE、INSERT等），会主动给波及的表加写锁，这个过程并不需要用户干涉。 为了不便演示，咱们利用零碎提供的显式加锁指令： 读锁：lock table table_name read;写锁：lock table table_name write;解锁：unlock tables;建设一个MyISAM存储引擎的表，并插入一些数据： create table tb_myisam(id INT AUTO_INCREMENT,name VARCHAR(30),age INT,PRIMARY KEY(id)) engine=myisam; insert into tb_myisam(name,age) value('zhang3',20);insert into tb_myisam(name,age) value('li4',21);insert into tb_myisam(name,age) value('wang5',22);3.1.1 在两个会话终端来演示MyISAM的读锁： 3.1.2 演示MyISAM的写锁： 3.2 InnoDB的表锁和行锁 InnoDB存储引擎在执行更新操作（UPDATE、DELETE、INSERT等），会主动给波及的表或行加写锁。InnoDB存储引擎对于一般SELECT语句，不会加任何锁。如果读的数据正在执行UPDATE或DELETE操作，这时读操作不会期待写锁的开释，而是间接读取该数据的快照，具体读取那份快照数据，和零碎的隔离级别无关。对于SELECT语句，零碎提供了显式加锁指令： 读锁：select * from table_name where ... lock in share mode;写锁：select * from table_name where ... for update;建设一个MyISAM存储引擎的表，并插入一些数据： ...

一、索引原理 索引是进步数据库查问性能的一个重要办法。 应用索引用可疾速找出某个列中蕴含特定值的行。不应用索引，必须从第一条记录开始读，可能要读完整个表，能力找出相干的行。 应用索引就像查字典一样，咱们能够依据拼音、笔画、偏旁部首等排序的目录(索引)，疾速查找到须要的字。 之前介绍MySQL存储引擎的文章（聊一聊MySQL的存储引擎），测试比照了两种存储引擎(MyISAM或者InnoDB)，应用主键索引查问，效率快了几十倍。 尽管索引大大提高了查问(select)速度，但同时也会升高更新(insert,update,delete)表的速度，因为更新表时，数据库不仅要更新和保留数据，还要更新和保留索引文件。当然索引文件也占用存储空间。 二、索引生效的场景 索引尽管放慢了查问效率，但应用办法不当，就会呈现索引生效。 上面实际操作，列举一些索引生效的场景。 CREATETABLE customer(id INTAUTO_INCREMENT,companyVARCHAR(30),nameVARCHAR(30),sex enum('male','female'),age INT,phoneVARCHAR(30),addressVARCHAR(60),PRIMARYKEY (id));CREATEINDEX index_company ON customer(company);CREATEINDEX index_age ON customer(age);CREATEINDEX index_phone ON customer(phone);CREATEINDEX index_phone_name ON customer(phone,name);下面创立了一个客户表，以及三个单列索引和一个组合索引，咱们来查看一下索引： mysql>show index from customer; # (因为排版问题，去掉了一些信息)+------------+------------------+--------------+-------------+------------+|Non_unique | Key_name |Seq_in_index | Column_name | Index_type |+------------+------------------+--------------+-------------+------------+| 0 | PRIMARY | 1 | id | BTREE || 1 | index_company | 1 | company | BTREE || 1 | index_age | 1 | age | BTREE || 1 | index_phone | 1 | phone |BTREE || 1 | index_phone_name | 1 | phone | BTREE || 1 | index_phone_name | 2 | name | BTREE |+------------+------------------+--------------+-------------+------------+6 rows inset (0.01 sec)下面显示包含一个默认的主键索引，还有三个单列索引，两个组合索引项。其中主键索引为惟一(unique)索引，索引类别(Index_type)显示为BTREE，理论为B+树。 ...

一、前言 存储引擎(storage engine)是MySQL的专用称说，数据库行业老大哥Oracle，以及SQL Server，PostgreSQL等都没有存储引擎的说法。 MySQL区别于其余数据库的重要特点就是，其插件式(pluggable)的表存储引擎。 引擎(engine)是外来音译词，习惯上认为是发动机，如同和数据库搭不上关系。 最早MySQL的存储引擎称为“数据表处理器”，可能是听起来太老土，起初才改成高大上的存储引擎。 存储引擎的性能是接管下层传下来的指令，而后对表中的数据进行读取或写入的操作。揭示一下，存储引擎操作的对象是表(table)，而不是数据库(database)。 MySQL5.5版本之后开始采纳InnoDB为默认存储引擎，之前版本默认的存储引擎为MyISAM。 咱们来看一下MySQL8.0反对哪些存储引擎： mysql> showengines;+--------------------+---------+---------+--------------+------+------------+| Engine | Support | Comment | Transactions| XA | Savepoints |+--------------------+---------+---------+--------------+------+------------+| FEDERATED | NO | | NULL | NULL | NULL || MEMORY | YES | | NO | NO | NO || InnoDB | DEFAULT | | YES | YES | YES ||PERFORMANCE_SCHEMA | YES | | NO | NO | NO || MyISAM | YES | ... | NO | NO | NO || MRG_MYISAM | YES | | NO | NO | NO || BLACKHOLE | YES | | NO | NO | NO || CSV | YES | | NO | NO | NO || ARCHIVE | YES | | NO | NO | NO |+--------------------+---------+---------+--------------+------+------------+9 rows in set (0.00sec)能够看到MySQL8.0反对9种存储引擎，默认应用InnoDB，而且只有InnoDB反对事务(Transactions)和分布式事务(XA),保留点(Savepoints)就是事务回滚所须要的性能。 ...

一、字符集概述 字符集（Character Set）是多个字符的汇合，字符集品种较多，每个字符集蕴含的字符个数不同，常见字符集名称：ASCII、GB2312、BIG5、Unicode等。 UTF(Unicode Tranformation Format)是Unicode的其中一个应用形式，即把Unicode转做某种格局的意思，包含UTF-8，UTF-16，UTF-32。 UTF-8（8-bit Unicode Transformation Format）是一种针对Unicode的可变长度字符编码，又称万国码。 UTF-8用1到6个字节编码Unicode字符。用在网页上能够同一页面显示中文简体繁体及其它语言（如英文，日文，韩文）。 UTF-16应用一个或两个未调配的16位代码单元的序列对Unicode代码点进行编码。 UTF-32行将每一个Unicode代码点示意为雷同值的32位整数。 上面是UTF-8的编码方式： 一个字节：0xxxxxxx 二、MySQL的字符集 MySQL的字符集包含字符集（charset）和校对规定（collation）两个概念。 字符集定义了存储字符串的形式，校对规定定义了比拟字符串的形式。 MySQL8.0反对40多种字符集的270多种校对规定。 能够应用以下指令，来查看MySQL零碎反对的字符集和校对规定。如下： mysql> show charset; MySQL8.0之前创立表不指定字符集的话，默认采纳latin1字符集，MySQL8.0之后版本才改为默认utf8mb4(most bytes 4)字符集，昆仑数据库存储节点采纳的是MySQL8.0架构，当然也是默认utf8mb4。 UTF-8，在MySQL中写作utf8，真的有所不同。 MySQL从4.1版本开始反对utf8。可能过后的utf8还没有定义4-6个字节规范，或者MySQL设计者认为1-3个字节的utf8曾经够用了。 所以过后MySQL设计的utf8只反对1-3个字节的编码，不是残缺的utf8，这种编码方式始终保留至今。 尽管在MySQL在5.5.3之后减少了utf8mb4字符集，但一段时间开发人员都习惯采纳utf8等字符集来反对中文。 MySQL的utf8会导致一些4个字节编码的生僻汉字插入谬误。 还有当初APP端的emoji表情是4个字节的字符，如果不转码，间接更新到数据库也会报出异样。 历史起因导致MySQL的utf8常常让人误会，已经让很多开发人员吃了苦头，网上有些文章比方：“永远不要在MySQL中应用utf8”，看着都挺吓人。 当然过个几年4个字节的utf8mb4编码可能又不够用了，那MySQL又要减少utf8mb5、utf8mb6。 字符除了须要存储，还须要排序或比拟大小，波及与字符集绝对应的校对规定。在MySQL8.0中查看一下utf8mb4对应的校对规定： mysql> show collationlike 'utf8mb4%';+----------------------------+---------+-----+---------+| Collation | Charset | Id | Default |+----------------------------+---------+-----+---------+|utf8mb4_0900_ai_ci | utf8mb4 |255 | Yes ||utf8mb4_0900_as_ci | utf8mb4 |305 | ||utf8mb4_0900_as_cs | utf8mb4 |278 | ||utf8mb4_0900_bin | utf8mb4 |309 | || utf8mb4_bin | utf8mb4 | 46 | || ................... | | | |75 rows in set (0.00sec)utf8mb4的校对规定默认utf8mb4_0900_ai_ci。其中0900示意Unicode版本9.0.0，后缀含意如下表： ...

前言 之前文章介绍了MySQL8.0主从复制，以及衍生进去的主主复制（可点如下链接查看）。 MySQL8.0轻松搞定GTID主从复制MySQL8.0轻松搞定GTID主主复制明天来聊一聊MySQL8.0的组复制。 主从复制技术仅解决了数据同步的问题，如果主服务器宕机，意味着数据库管理员须要染指，利用零碎可能须要批改数据库连贯地址或者重启能力实现。 组复制只有不是大多数节点坏掉就能够持续工作，有自动检测机制，当不同节点产生资源争用抵触时，不会呈现谬误，依照先到者优先准则进行解决。比方，3台服务器的集群，容许其中1台宕机。 组复制工作模式： 单主模式，其中只有一个服务器承受更新，单主是零碎主动选举进去的。多主模式，其中所有服务器都能够承受更新。昆仑数据库存储节点的单个分片，采纳的是单主模式的组复制。 在单主模式下，当主节点宕机时，将主动抉择新的主节点，选举办法如下图所示： 在多主模式下，每个节点都能够写数据，因而不存在节点选举，如果组成员产生故障，业务切换节点即可。如下图所示： 上面介绍在装置好MySQL8的centos8虚拟机上，实现单主模式组复制，以及多主模式组复制的过程： 虚拟机列表： G1: 192.168.25.150 **一、G1配置** 1.1. 批改主机名，并重启失效 vim /etc/hosts 1.2. 敞开防火墙并设置开机不启动 systemctl stop firewalld.service 1.3. 敞开Selinux并设置开机不启动 setenforce 0 1.4. 删除auto.cnf，重启主动生成server-uuid rm -f /var/lib/mysql/auto.cnf 1.5. 设置配置文件 vim /etc/my.cnf 1.6. 重启MySQL systemctl restart mysqld.service 1.7. 登录mysql,增加用于同步的数据库账号 `mysql> set sql_log_bin=0; #不记录二进制日志` 1.8. 启动组复制性能 ## 第一个主须要关上bootstrap_group，启动复制服务后，再敞开 1.9. 查看组员状况 mysql> select * from performance_schema.replication_group_members;二、G2，G3配置 反复1.1-1.9步骤 步骤1.5配置文件, G2，G3别离批改如下 server_id=2 步骤1.8只需启动复制服务 mysql>start group_replication; 步骤1.9查看组员状况 mysql> select * from performance_schema.replication_group_members;至此，单主模式的组复制曾经搭建胜利。 ...

前言 之前文章介绍了GTID主从复制，实现了一主多从的MySQL架构，明天咱们来介绍一下主主复制的架构。 原理：主主复制就是依据主从复制的原理，将两个主库设置互为主从即可。 变动：在这两个主库的根底上，还能够搭建双主多从架构。 **上面介绍在装置好MySQL8的centos8虚拟机上，实现GTID主主复制，以及双主多从复制的过程： 虚拟机列表：** Master1: 192.168.25.149 一、Master1配置 1.1 删除auto.cnf，重启主动生成server-uuid rm -f /var/lib/mysql/auto.cnf 1.2 设置server-id，关上GTIT vim /etc/my.cnf 1.3 重启MySQL systemctl restart mysqld.service 1.4 登录mysql,增加用于同步的数据库账号 mysql> create user 'kunlun'@'%' identified by '123456';二、Master2配置 2.1 删除auto.cnf，重启主动生成server-uuid rm -f /var/lib/mysql/auto.cnf 2.2 设置server-id，关上GTID vim /etc/my.cnf 2.3 重启MySQL systemctl restart mysqld.service 2.4 登录mysql,增加用于同步的数据库账号 mysql> create user 'kunlun'@'%' identified by '123456';三、Master1启动主从复制 3.1 登录MySQL,配置主从同步 mysql> change master to 3.2 启动从库服务 mysql> start slave; 3.3 查看状态 ...

为什么须要主从复制？ 艰深来讲，如果对数据库的读和写都在同一个数据库服务器中操作，业务零碎性能会升高。 为了晋升业务零碎性能，优化用户体验，能够通过做主从复制来加重主数据库的负载。 而且如果主数据库宕机，可疾速将业务零碎切换到从数据库上，可防止数据失落。 主从复制原理 主库将更新记录保留于Binlog文件中，并通过Binglog Dump线程发送给从库。从库的I/O线程从主库读取Binlog更新的数据，写入到Relay log中。从库的SQL线程读取Relay log文件的数据写入从库，实现同步。 采纳GTID (Global Transaction ID)主从复制形式，保障了每个在主库上提交的事务在集群中有一个惟一的ID。 这种形式强化了数据库的主从一致性，故障复原以及容错能力。 相比于晚期通过master_log_file，master_log_pos同步的主从复制，省去了从库宕机重启后，须要重新配置的问题。 接下来介绍在虚拟机centos8版本，实现GTID主从复制的三大步骤： 一．MySQL8.0装置 1.1、应用rpm来装置MySQL wget https://repo.mysql.com/mysql80-community-release-el8-1.noarch.rpm1.2、启动mysql并设置开机自启动 systemctl start mysqld.service 1.3、敞开防火墙并设置开机不启动 systemctl stop firewalld.service 1.4、登录，无需明码，以后最新版本为8.0.26 mysql 1.5、查看BINLOG状态，最新版本默认曾经开启 mysql> show variables like '%log_bin%'; 1.6、复制装置好MySQL8的虚拟机镜像，作为从库二．主库配置 2.1、设置server-id，关上GTIT vim /etc/my.cnf 2.2、登录mysql,增加用于同步的数据库账号 mysql> create user 'kunlun'@'%' identified by '123456';三．从库配置 3.1、删除auto.cnf，重启主动生成server-uuid rm -f /var/lib/mysql/auto.cnf 3.2、设置server-id, 主库和从库server-id不要反复 vim /etc/my.cnf 3.3、登录mysql,配置主从同步 mysql> change master to 3.4、启动从库服务 mysql> start slave; 3.5、查看状态 mysql> show slave status\G ...

背景 目前很多公司都不思考退出外键了，很多人工作中也不怎么应用外键了，毕竟每次做DELETE 或者UPDATE都必须思考外键束缚，会导致开发的时候很苦楚,测试数据极为不不便。 在笔者看来，在相应的场景下，如果应用的一个性能弊大于利，可能就不会抉择了。所以是否应用外键取决相应的场景，也不可去齐全摈弃外键。 为什么会很少应用外键呢？ 目前应用外键的确存在一些不便，这也是大多数人不应用的起因所在。我具体总结了会存在这么几个起因： 1、减少数据库压力 外键等于把数据的一致性事务实现，全副交给数据库服务器实现，并且有了外键，当做一些波及外键字段的增、删、更新操作之后，须要触发相干操作去查看，而不得不耗费资源。 2、死锁问题 若是高并发大流量事务场景，应用外键还可能容易造成死锁。 3、开发不不便 有外键时，无论开发还是保护，须要手工保护数据时，都不太不便，要思考级联因素。 4、数据刷库 理论开发过程中，免不了要常常刷库，导入或删除数据，外键的存在会让表删除或插入失败（表数据变更有程序要求）。 5、外键保护 随着我的项目的迭代，表之间的关系也会发生变化，比方有个外键须要删除；或是要新增一个外键，但因为现有数据不准，导致外键加不下来，长此以往，ER图也不能残缺的显示表关系，这ER图看还是不看？ 外键真的就没有用了吗？ 存在即正当，每一个产品，每一个性能既然存在，在某些中央也是存在劣势的。笔者总结了一下外键的几个劣势点： 1、数据库的一致性 由数据库本身保证数据一致性、完整性会更牢靠，程序很难100％保证数据的一致性、完整性，而用外键即便在数据库服务器当机或者呈现其余问题的时候，也可能最大限度的保证数据的一致性和完整性。 2、ER图可靠性 有主外键的数据库设计能够减少ER图的可读性（也有特地的公司产品特地重视的这一方面）。 总结 1、如是单机且低并发，也不须要性能调优，再或者不能用程序保证数据的一致性，完整性，能够应用外键，如学校的，保证数据的一致性与残缺，基数也不大。 2、如果为了高并发，分布式，使零碎性能更优，以及更好保护，则不要去应用外键。

在做数据库设计时，咱们常常须要给很多表减少一个‘类型’ 字段，比方人的性别有‘男’， ‘女’，学校的类型有‘幼儿园’，‘小学’，‘中学’，‘大学’，汽车的类型有‘轿车’，‘suv’，‘mpv’等，这种字段的实质特点是它们蕴含 “无限个离散值”。 对于这种字段，应用enum数据类型是最合适的，mysql和PostgreSQL都有此数据类型。enum类型有这么一些特点： 1、在表中enum字段存储的理论是其程序值（整数），而不是字符串。 2、依照enum值做查找和比拟的时候，依照程序值来查找和比拟，而不是依照enum项的字符串。不过mysql在这个方面有个问题（见下文截图）：与其某个enum项雷同的字符串做范畴比拟（>, <, >=, <=)时候，并没有依照程序值比拟，而是依照字面值比拟了。然而mysql在依照enum列做排序的时候，却也可能正确滴依照enum项的程序值来排序。 3、postgresql的enum类型须要事后定义好，而后在create table的时候应用该类型。这样做的益处是多个表能够应用同一个enum类型，不用屡次定义而导致不统一等问题。 4、能够对enum列定义索引，索引key排序也是依照enum程序值排序，并且索引key也是enum程序值（整数）。 上面的截图是应用昆仑分布式数据库做的示例。外面mysql的示例是应用昆仑分布式数据库的存储节点（mysql8.0.15）做的。创立应用enum数据类型的表，而后插入数据。 对enum类型的列做范畴查找和等值查找，程序值决定enum项的大小关系。 依照enum类型的列排序时候，会依照其程序值而不是字面字符串 做排序。查问元数据表能够看到enum类型的元数据。 mysql的enum用法：能够做等值查找，然而范畴查找没有依照程序值而是依照enum项的 字面字符串 来比拟的，这样做其实是谬误的。 mysql中enum列的定义，依照 enum项 呈现的程序给每个enum项赋予 程序值，从0开始。 依照enum列排序时，是依照enum项 的 程序值来排序的。从元数据字典能够看到‘职级’这个enum类型的enum项的程序值。 插入更多行后，再次排序，依然是依照enum列的程序值而不是字面字符串 来排序的。 mysql对enum列也是依照程序值排序，然而与enum字符串做大小比拟时候无奈聪慧滴依照程序值来比拟。 在举例说明enum的用法之后，我列举一下不应用enum的数据库设计当中不好的设计方案。这些计划应该被摒弃，切不可模拟。 1、有人间接应用字符串类型，比方varchar(N) 类型的列，来存储这样的字段值，这样的问题是，有可能下层利用的谬误会输出意外的字段值，比方上例中学校类型字段，如果应用层数据处理不充沛，导致插入一行Rx.type = ‘大 学’，那么这样的行Rx也齐全能够插入到表中。于是当你查找 类型=‘大学’ 的行时候，就找不到Rx了。还有一个问题是空间利用率问题。在mysql和postgresql中，enum字段理论存储的是enum值的数值，通常会比存储字符串节俭空间，而且在查找和比拟时，数值比拟也比字符串比拟更快。 2、另有人会在db的表中应用数字来代表类型，而后在应用层实现数字与类型字符串的转换。比方上例学校类型中，用1代表‘幼儿园’，2代表‘小学’等，而后在应用层残缺这种数字与字符串之间的转换，向最终用户展现字符串，向db的对应字段中存入数字。这样做的问题是，减少了应用层开发的工作量和保护开销。构想前期须要减少更多类型值，还要批改应用层代码。而且，没有应用层代码，还齐全无奈了解字段值的意义（当然，能够减少正文阐明），影响数据的可读性。 从这里能够看出enum类型的几个长处： 1、数据校验，回绝非法值。 2、高效存储和计算。 3、数据可读性强，不须要依赖利用代码来解释。 4、不须要应用程序做任何数值解释和转换，升高应用软件开发和保护的老本。 所以，强烈建议数据库设计和利用零碎设计的时候，适当的时候应用enum类型。 KunlunDB我的项目已开源 【GitHub：】https://github.com/zettadb 【Gitee：】https://gitee.com/zettadb END

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 本篇来源于客户征询的问题。 问题概要为：记忆中在 MySQL 里对用户进行受权操作后都须要执行 flush privileges 能力失效，怎么我在你写的波及到用户受权相干的文章里都没有看到执行 flush privileges 语句？ 对于这个问题的解答，首先得明确语句 flush privileges 的作用是什么？flush privileges 是 flush 语句汇合里的一条子项，执行它的作用是来同步 MySQL 磁盘和内存中的受权数据，让其保持一致。说具体点就是全量读取受权表的磁盘数据并且齐全笼罩内存中的受权数据，又或者反着同步磁盘上的受权数据。 具体能够参考官网手册链接：https://dev.mysql.com/doc/ref... 接下来用两个简略示例阐明执行 flush privileges 语句的机会。第一，何时应用？当受权数据在磁盘和内存中不统一时，存在两种机会：一是内存数据较新；另一个则是磁盘数据较新。当这两点中的任意一点存在时都须要执行 flush privileges 语句。比方间接对表 mysql.user 执行 DML 语句，那么此时磁盘数据较新，须要手动执行 flush privileges 语句来笼罩内存中的受权数据。举个例子，用户 ytt_u1 领有的权限数据如下： mysql:(none)>show grants for ytt_u1;+-------------------------------------+| Grants for ytt_u1@% |+-------------------------------------+| GRANT SELECT ON *.* TO `ytt_u1`@`%` |+-------------------------------------+1 row in set (0.00 sec)管理员来间接更新底层用户表数据： 勾销 select 权限。 ...

咱们都晓得在数据库查问时，索引能够极大的进步查问效率。通常在应用的时候，都会针对频繁查问的关键字段建设索引。 比方，当以交易日期（trans_date）来查问交易记录时，通常会对该字段增加索引，以便在大量数据的状况下晋升查问效率。 针对trans_date字段，创立union_idx_query索引，那么在上面以trans_date为查问条件的语句中，毫无疑问是会走索引的： select count(1) from A; // 40000EXPLAIN select * from A where trans_date = '20220222'; 此时，咱们会想当然的认为，只有创立了索引，其余状况的应用同样会走索引。比方上面的查问语句： select count(1) from t_trans_log_info where trans_date > '20220122'; //11200EXPLAIN select * from t_trans_log_info where trans_date > '20220122';下面的查问语句应用了”>“来进行范畴的查问，而且trans_date字段同样创立了索引，那么上述SQL语句是否会走索引呢？答案是不肯定。 explain上述SQL语句，发现没有走索引，而是进行了全表扫描。 但当换一个查问参数时： select count(1) from t_trans_log_info where trans_date > '20220222'; //1120EXPLAIN select * from t_trans_log_info where trans_date > '20120222';explain的结果显示走了索引： 为什么同样的查问语句，只是查问的参数值不同，却会呈现一个走索引，一个不走索引的状况呢？ 答案很简略：上述索引生效是因为DBMS发现全表扫描比走索引效率更高，因而就放弃了走索引。 也就是说，当Mysql发现通过索引扫描的行记录数超过全表的10%-30%时，优化器可能会放弃走索引，主动变成全表扫描。某些场景下即使强制SQL语句走索引，也同样会生效。 相似的问题，在进行范畴查问（比方\>、< 、>=、<=、in等条件）时往往会呈现上述情况，而下面提到的临界值依据场景不同也会有所不同。 所以，如果你在我的项目中采纳了上述形式的查问，又心愿它可能走索引，就须要特地留神了。通常须要增加一些其余的限度条件或用其余形式来保障索引的有效性。 博主简介：《SpringBoot技术底细》技术图书作者，热爱钻研技术，写技术干货文章。 公众号：「程序新视界」，博主的公众号，欢送关注~ 技术交换：请分割博主微信号：zhuan2quan

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。[toc] 明天介绍MGR集群的日常治理保护操作，包含主节点切换，单主&多主模式切换等。手工操作以及利用MySQL Shell两种形式都会别离介绍。 当初有个三节点的MGR集群： mysql> select * from performance_schema.replication_group_members;+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+| group_replication_applier | af39db70-6850-11ec-94c9-00155d064000 | 172.16.16.10 | 3306 | ONLINE | PRIMARY | 8.0.25 || group_replication_applier | b05c0838-6850-11ec-a06b-00155d064000 | 172.16.16.11 | 3306 | ONLINE | SECONDARY | 8.0.25 || group_replication_applier | b0f86046-6850-11ec-92fe-00155d064000 | 172.16.16.12 | 3306 | ONLINE | SECONDARY | 8.0.25 |+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+1. 切换主节点当主节点须要进行保护时，或者执行滚动降级时，就能够对其进行切换，将主节点切换到其余节点。 在命令行模式下，能够应用 group_replication_set_as_primary() 这个udf实现切换，例如： ...

作者：付祥 现居珠海，次要负责 Oracle、MySQL、mongoDB 和 Redis 保护工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 1. 环境阐明1.1. MySQL版本root@3306 (none)> SELECT @@VERSION;+------------+| @@VERSION |+------------+| 5.7.34-log |+------------+1 row in set (0.01 sec)1.2. binlog 相干参数root@3306 (none)> select @@log_bin,@@log_slave_updates;+-----------+---------------------+| @@log_bin | @@log_slave_updates |+-----------+---------------------+| 1 | 1 |+-----------+---------------------+1 row in set (0.00 sec)root@3306 (none)>1.3. GTID 相干参数root@3306 (none)> select@@binlog_gtid_simple_recovery,@@enforce_gtid_consistency,@@gtid_mode;+-------------------------------+----------------------------+-------------+| @@binlog_gtid_simple_recovery | @@enforce_gtid_consistency | @@gtid_mode |+-------------------------------+----------------------------+-------------+| 1 | ON | ON |+-------------------------------+----------------------------+-------------+1 row in set (0.01 sec)root@3306 (none)>1.4. 半同步相干参数root@3306 (none)> show global variables like '%semi%';+-------------------------------------------+------------+| Variable_name | Value |+-------------------------------------------+------------+| rpl_semi_sync_master_enabled | ON || rpl_semi_sync_master_timeout | 1000 || rpl_semi_sync_master_trace_level | 32 || rpl_semi_sync_master_wait_for_slave_count | 1 || rpl_semi_sync_master_wait_no_slave | ON || rpl_semi_sync_master_wait_point | AFTER_SYNC || rpl_semi_sync_slave_enabled | ON || rpl_semi_sync_slave_trace_level | 32 |+-------------------------------------------+------------+8 rows in set (0.00 sec)root@3306 (none)>1.5. 多线程同步相干参数root@3306 (none)> select@@binlog_transaction_dependency_tracking,@@slave_parallel_type,@@slave_parallel_workers;+------------------------------------------+-----------------------+--------------------------+| @@binlog_transaction_dependency_tracking | @@slave_parallel_type |@@slave_parallel_workers |+------------------------------------------+-----------------------+--------------------------+| COMMIT_ORDER | LOGICAL_CLOCK |2 |+------------------------------------------+-----------------------+--------------------------+1 row in set (0.00 sec)root@3306 (none)>2.故障景象MySQL 从库所在主机故障重启后，sql_thread 线程报错： ...

大家好，我是咔咔 不期速成，日拱一卒 本期来聊聊MySQL的加锁规定，晓得这些规定后能够判断SQL语句的加锁范畴，同时也能够写出更好的SQL语句，避免幻读问题的产生，在能力范畴内最大水平的晋升MySQL并发处理事务能力。 当初你应该晓得了MVCC解决了快照读下的幻读问题，但以后读的幻读问题还是基于锁解决的，也就是next-key lock。 最新文章死磕MySQL系列总目录 为什么MySQL字符串不加引号索引生效？《死磕MySQL系列 十一》 关上order by的大门，一探到底《死磕MySQL系列 十二》 重重封闭，让你一条数据都拿不到《死磕MySQL系列 十三》 闯祸了，生成环境执行了DDL操作《死磕MySQL系列 十四》 一、理解next-key lock在文章幻读：据说有人认为我是被MVCC干掉的这期文章中，具体阐明了幻读在以后读、快照读下的解决形式。 快照读简略来说就是简略的select操作，没有加任何锁，在Innodb存储引擎下执行简略的select操作时，会记录下以后的快照读数据，之后的select会沿用第一次快照读的数据，即便有其它事务提交也不会影响以后的select后果，因而通过快照读查问的数据尽管是统一的，但有可能不是最新的数据，而是历史数据。 这个是从官网文档中获取的材料，解释在以后读下Innodb应用next-key lock锁来解决幻读问题。 To prevent phantoms, InnoDB uses an algorithm called next-key locking that combines index-row locking with gap locking. InnoDB performs row-level locking in such a way that when it searches or scans a table index, it sets shared or exclusive locks on the index records it encounters. Thus, the row-level locks are actually index-record locks. In addition, a next-key lock on an index record also affects the “gap” before that index record. That is, a next-key lock is an index-record lock plus a gap lock on the gap preceding the index record. If one session has a shared or exclusive lock on record R in an index, another session cannot insert a new index record in the gap immediately before R in the index order.大抵意思，为了避免幻读，Innodb应用next-key lock算法，将行锁(record lock)和间隙锁(gap lock)联合在一起。Innodb行锁在搜寻或者扫描表索引时，会在遇到的索引记录上设置共享锁或者排它锁，因而行锁理论是索引记录锁。另外， 在索引记录上设置的锁同样会影响索引记录之前的“间隙(gap)”。即next-key lock是索引记录行加上索引记录之前的“gap”上的间隙锁定。二、next-key lock 加锁规定加锁规定总结为以下几点，不同MySQL版本会有渺小的差别 ...

对于MYSQL字段null值，咱们都不会生疏，诸如咱们会用上面相似的SQL语句建表，为了业务须要（或者某种便捷），会给某些字段默认值为NULL（或者说已经有设置过默认值为NULL的状况） CREATE TABLE `test` ( `id` bigint(20) NOT NULL DEFAULT '0', `name` varchar(255) DEFAULT NULL, `description` longtext NOT NULL, `school` char(25) DEFAULT '', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8为什么咱们会或多或少接触过NULL值列呢？请看下列解释： Null is a special constraint of columns. The columns in table will be added null constrain if you do not define the column with "not null" key words explicitly when creating the table. Many programmers like to define columns by default ...

之前在这里编写自定义SQL通过注解的形式能够胜利，然而XML始终失败：报错Invalid bound statement (not found)起初看官网文档找到了线索 之前也尝试过一些办法，不晓得为什么均有效。比方：1，在 Configuration 类上应用注解 MapperScan2，SqlSessionFactory不要应用原生的，请应用MybatisSqlSessionFactory等等都有效 起初走通了一个办法，步骤如下：1,在Resources文件夹下创立一个Mapper文件夹 比方咱们须要在Admin表中应用增删改查，创立AdminMapper.xml，对应MybatisPlus中的AdminMapper接口 2,之后咱们在application.yml中配置mapper文件夹的门路 mybatis-plus: mapper-locations: classpath:mapper/*.xml3,就能够在AdminMapper.xml中写sql语句了,写法和Mybatis一样 <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd"><mapper namespace="scrm.mapper.AdminMapper"> <select id="getAll" resultType="java.util.LinkedHashMap"> SELECT ad.id,ad.name FROM admin ad WHERE ad.id IN ( SELECT DISTINCT creater_id FROM canal ) </select></mapper>4,编写测试类 package scrm;import org.junit.jupiter.api.Test;import org.springframework.boot.test.context.SpringBootTest;import scrm.mapper.AdminMapper;import scrm.model.entity.Admin;import javax.annotation.Resource;import java.util.List;import java.util.Map;@SpringBootTestpublic class Canal { @Resource AdminMapper adminMapper; @Test public void createrList(){ List<Map<String, Object>> mapList = adminMapper.getAll(); System.out.println("admin"+mapList); }}5,输入后果： 备注：在这篇文章收到了启发：https://blog.csdn.net/qq_4266...

数据库实现了数据的长久化，但咱们最终要在程序里解决数据啊，那java代码中怎么去拜访数据库读写数据呢？ 这就要用到sun公司设定的一套数据库规范了，这套规范就是JDBC（Java Database Connectivity）。但它只是标准，不做具体实现。于是数据库厂商又依据JDBC规范，实现自家的驱动Driver。如：mysql驱动com.mysql.cj.jdbc.Driver，Oracle的驱动oracle.jdbc.OracleDriver。有了这套解决方案，java就能够拜访数据库中的数据了。 public interface Connection extends Wrapper, AutoCloseable {} public interface Statement extends Wrapper, AutoCloseable {} public interface PreparedStatement extends Statement {} public interface CallableStatement extends PreparedStatement {} public interface ResultSet extends Wrapper, AutoCloseable {}Java中提倡面向接口开发，而最经典的接口设计莫过于JDBC数据库接口。 如有问题能够观看视频： https://www.bilibili.com/vide... Connection链接、Statement语句、PreparedStatement预处理语句、CallableStatement存储过程、ResultSet后果集。 调用形式有三种： Statement语句、PreparedStatement预处理语句、CallableStatement存储过程，举荐应用第二种PreparedStatement，避免SQL注入，其也是预编译性能高。 应用步骤 导入jar包(丰盛的工具类)获取和数据库的连贯(用户名、明码)通过程序执行SQL通过程序处理后果idea 创立我的项目并导入jar包 创立stage2 Java工程创立lib目录，拷贝驱动objbc6-11.1.0.7.0到lib目录下我的项目援用这个内部jar包 入门案例 package cn.tedu.jdbc; import java.sql.*; //测试 jdbc//需要：查问cgb2104库里的students表里的所有数据public class Test1 { public static void main(String[] args) throws Exception { //1,注册驱动 Class.forName("com.mysql.jdbc.Driver"); //2,获取和数据库的连贯//String url= "jdbc:mysql://localhost:3306/cgb2104?characterEncoding=utf8";//指定要连贯哪个数据库String url= "jdbc:mysql:///cgb2104?characterEncoding=utf8";//指定要连贯哪个数据库 String user= "root" ; //应用的用户名 String pwd= "root" ; //应用的明码 Connection conn = DriverManager.getConnection(url, user, pwd); //3,获取传输器,执行SQL Statement st = conn.createStatement(); //4,执行SQL ResultSet rs = st.executeQuery("select * from students"); //5,解析后果集 while( rs.next() ){//next()判断后果集中是否有数据 for (int i = 1; i <= 5 ; i++) { //获取每列的值并打印 System.out.println( rs.getString(i) ); } } //6,开释资源 rs.close(); //敞开后果集 st.close();//敞开传输器 conn.close();//敞开连贯 }}SQL注入 ...

①装置服务： mysqld --install②初始化：　mysqld --initialize --console③开启服务： net start mysql④敞开服务： net stop mysql⑤登录mysql： mysql -u root -pEnter PassWord：(明码)⑥批改明码： alter user 'root'@'localhost' identified by 'root'; (by 接着的是明码)⑦标记删除mysql服务： sc delete mysql

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。半同步简介MASTER节点在执行完客户端提交的事务后不是立即返回后果给客户端，而是期待至多一个SLAVE节点接管并写到relay log中才返回给客户端。半同步绝对于异步复制而言，进步了数据的安全性，同时也造成了肯定水平的提早，这个提早起码是一个TCP往返的工夫。所以，半同步复制最好在低延时的网络中应用。MySQL从5.5开始就反对半同步复制，在5.7.2版本的时候对半同步复制进行了一次改良；原先的半同步策略为 AFTER_COMMIT 改良后的策略为 AFTER_SYNC 两者的差别在于SLAVE节点ACK应答MASTER的机会不同。两种模式介绍AFTER_COMMIT 模式介绍MASTER将每个事务写入到二进制日志并刷盘保留，同时将事务发送给SLAVE，而后将事务提交给存储引擎解决并进行提交，而后期待SLAVE返回确认信息，在收到确认信息后，MASTER将后果返回给客户端，而后以后客户端能够持续工作。AFTER_SYNC 模式介绍MASTER将每个事务写入到二进制日志并刷盘保留，同时将事务发送给SLAVE，而后期待SLAVE返回确认信息，收到确认信息后，将事务提交给存储引擎解决并进行提交，并将后果返回给客户端，而后以后客户端能够持续工作。两种形式比拟对于第一种 AFTER_COMMIT 形式，以后客户端只有在服务器向存储引擎提交数据并收到SLAVE返回的确认后，才会收到事务的返回后果。在事务提交之后收到SLAVE返回确认信息之前，此刻其余客户端能够看到以后客户端提交的事务信息。 如果SLAVE节点因为网络等起因并未收到MASTER节点传递过去的事务，而MASTER节点此刻crash了。HA进行故障转移，客户端都连到SLAVE节点上，这时先前在MASTER节点看到的事务在SLAVE节点并未看到，就会产生事务失落的状况。对于第二种 AFTER_SYNC 形式，当事务被SLAVE确认后MASTER在存储引擎层面进行提交事务后，所有客户端能力看到事务造成的数据更改。因而，所有客户端在MASTER上同一时刻看到是雷同的数据。 当MASTER节点crash的状况下，所有在MASTER上提交的事务都被复制到SLAVE(保留到中继日志中)。 MASTER服务器意外crash。此刻HA进行故障转移到SALVE后，客户端看到的数据是无损的，因为SLAVE是最新的。 留神，然而，在这种状况下，MASTER不能间接复原应用，因为它的二进制日志可能蕴含未提交的事务，此刻当二进制日志复原并用于业务需要时，可能会导致与SLAVE的抵触。如何开启半同步形式1：半同步以插件的模式存在，咱们能够间接在线开启即可（本次采纳这次形式）# 主节点开启[root@GreatSQL][(none)]>INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';Query OK, 0 rows affected (0.02 sec)# 从节点开启[root@GreatSQL][(none)]>INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';Query OK, 0 rows affected (0.02 sec)# PS：个别状况下所有节点都同步部署master和slave插件，这样故障切换的时候会比拟不便解决形式2：在my.cnf配置中进行开启# 主从节点都同步配置开启plugin-load="rpl_semi_sync_master=semisync_master.so;rpl_sync_slave=semisync_slave.so"rpl_semi_sync_master_enabled=1rpl_semi_sync_slave_enabled=1查看插件开启状况形式1：查问plugin# 主节点查看[root@GreatSQL][test]>show plugins;| rpl_semi_sync_master | ACTIVE | REPLICATION | semisync_master.so | GPL |# 从节点查看[root@GreatSQL][(none)]>show plugins;| rpl_semi_sync_slave | ACTIVE | REPLICATION | semisync_slave.so | GPL |形式二：查问information_schema.plugins信息更全面# 主节点信息(Thu Feb 17 03:03:12 2022)[root@GreatSQL][(none)]>select * from information_schema.plugins where plugin_name like "%semi%"\G;*************************** 1. row *************************** PLUGIN_NAME: rpl_semi_sync_master PLUGIN_VERSION: 1.0 PLUGIN_STATUS: ACTIVE PLUGIN_TYPE: REPLICATION PLUGIN_TYPE_VERSION: 4.0 PLUGIN_LIBRARY: semisync_master.soPLUGIN_LIBRARY_VERSION: 1.10 PLUGIN_AUTHOR: Oracle Corporation PLUGIN_DESCRIPTION: Semi-synchronous replication master PLUGIN_LICENSE: GPL LOAD_OPTION: ON1 row in set (0.00 sec)ERROR:No query specified# 从节点信息(Thu Feb 17 16:05:19 2022)[root@GreatSQL][(none)]>select * from information_schema.plugins where plugin_name like "%semi%"\G;*************************** 1. row *************************** PLUGIN_NAME: rpl_semi_sync_slave PLUGIN_VERSION: 1.0 PLUGIN_STATUS: ACTIVE PLUGIN_TYPE: REPLICATION PLUGIN_TYPE_VERSION: 4.0 PLUGIN_LIBRARY: semisync_slave.soPLUGIN_LIBRARY_VERSION: 1.10 PLUGIN_AUTHOR: Oracle Corporation PLUGIN_DESCRIPTION: Semi-synchronous replication slave PLUGIN_LICENSE: GPL LOAD_OPTION: ON1 row in set (0.00 sec开启半同步性能因为下面是在线装置插件的，所以插件装置实现后，服务还要启动一下# 主节点启用半同步复制[root@GreatSQL][test]>SET GLOBAL rpl_semi_sync_master_enabled = on;Query OK, 0 rows affected (0.00 sec)# 从节点启用半同步复制[root@GreatSQL][(none)]>SET GLOBAL rpl_semi_sync_slave_enabled = on;Query OK, 0 rows affected (0.00 sec)以上设置实现后，从节点重启IO线程(Mon Feb 14 15:19:58 2022)[root@GreatSQL][(none)]>(Mon Feb 14 15:19:58 2022)[root@GreatSQL][(none)]>STOP SLAVE IO_THREAD;Query OK, 0 rows affected, 1 warning (0.01 sec)(Mon Feb 14 15:21:41 2022)[root@GreatSQL][(none)]>START SLAVE IO_THREAD;Query OK, 0 rows affected, 1 warning (0.01 sec)查看半同步是否运行# 主节点[root@GreatSQL][test]>show status like 'Rpl_semi_sync_master_status';+-----------------------------+-------+| Variable_name | Value |+-----------------------------+-------+| Rpl_semi_sync_master_status | ON |+-----------------------------+-------+1 row in set (0.00 sec)# 从节点[root@GreatSQL][(none)]>show status like 'Rpl_semi_sync_slave_status';+----------------------------+-------+| Variable_name | Value |+----------------------------+-------+| Rpl_semi_sync_slave_status | ON |+----------------------------+-------+1 row in set (0.01 sec)查看主节点error.log，能够看进去从节点曾经启用半同步复制了# 要害信息 Start semi-sync binlog_dump to slave (server_id: 3306)2022-02-14T02:16:35.411061-05:00 13 [Note] [MY-010014] [Repl] While initializing dump thread for slave with UUID <652ade08-8b1c-11ec-9f62-00155dcff90a>, found a zombie dump thread with the same UUID. Master is killing the zombie dump thread(12).2022-02-14T02:16:35.411236-05:00 13 [Note] [MY-010462] [Repl] Start binlog_dump to master_thread_id(13) slave_server(3306), pos(, 4)2022-02-14T02:16:35.411263-05:00 13 [Note] [MY-011170] [Repl] Start asynchronous binlog_dump to slave (server_id: 3306), pos(, 4).2022-02-14T02:16:35.411419-05:00 12 [Note] [MY-011171] [Repl] Stop asynchronous binlog_dump to slave (server_id: 3306).2022-02-14T02:19:33.913084-05:00 9 [Note] [MY-011130] [Repl] Semi-sync replication initialized for transactions.2022-02-14T02:19:33.913133-05:00 9 [Note] [MY-011142] [Repl] Semi-sync replication enabled on the master.2022-02-14T02:19:33.913638-05:00 0 [Note] [MY-011166] [Repl] Starting ack receiver thread.2022-02-14T02:21:46.899725-05:00 14 [Note] [MY-010014] [Repl] While initializing dump thread for slave with UUID <652ade08-8b1c-11ec-9f62-00155dcff90a>, found a zombie dump thread with the same UUID. Master is killing the zombie dump thread(13).2022-02-14T02:21:46.899894-05:00 14 [Note] [MY-010462] [Repl] Start binlog_dump to master_thread_id(14) slave_server(3306), pos(, 4)2022-02-14T02:21:46.899953-05:00 14 [Note] [MY-011170] [Repl] Start semi-sync binlog_dump to slave (server_id: 3306), pos(, 4).以上，MySQL半同步复制搭建结束！ ...

mysqlmysql日志binlog次要记录mysql的逻辑日志，采纳追加写的形式应用场景：1. 主从复制 2. 数据恢复 redologmysql 采纳先写日志，后写磁盘的形式，宕机的时候停业通过redolog来进行复原undo日志用于回滚mysql的幻读其实分为两种状况 以后读的幻读状况 以后读select 永远读到的数据不会产生任何变动，通过mvvc实现快照读的幻读状况 快照读通过锁实现，都曾经锁住了，你插入个基基！A. select *from t;B. insert into t values(1)C. insert into t values(1)c报错：这种场景不是幻读，网上一顿瞎几把乱说的这种查的时候是通过快照读的，插入的时候又是通过以后读，什么狗币货色！，网上一大堆概念谬误，通过以后读和快照读的数据不一样，来示意幻读。https://xie.infoq.cn/article/... mysql 打断点https://juejin.cn/post/684490... mysql加锁是给索引加锁的，如果字段没索引就会给全表加索引 FieldTypeNullKeyDefaultExtraidint(1)NOPRINULLauto_incrementnamevarchar(8)YES NULL INSERT INTO `test` VALUES ('100', '小罗');INSERT INTO `test` VALUES ('500', '小黄');INSERT INTO `test` VALUES ('700', '小明');INSERT INTO `test` VALUES ('1100', '小红');主键索引：1. 如果是等值查问，且id存在则只会锁住一条记录a: select *from T where id=100 for update;b: insert into T values(200,'张三');后果：可能失常插入2. 如果等值查问，且id不存在，会锁住一个范畴a：select *from T where id=200 for update;b: 插入的时候[100,500]的这个范畴内都不能进行插入1. 在一般索引列上，不论是何种查问，只有加锁，都会产生间隙锁，这跟惟一索引不一样！2. 在一般索引跟惟一索引中，数据间隙的剖析，数据行是优先依据一般索引排序，再依据惟一索引排序。mysql为什么采纳b＋数1. b+数叶子节点存放数据，非叶子节点只寄存指针，这样的话，非叶子节点可能寄存更多的数据，导致数的高度变低，而磁盘查找效率次要又树的高度来决定。2. 查问效率稳固的，因为根节点到叶子节点的门路是雷同的3. 叶子节点通过指针连贯在一起，这样的话不便做范畴查问聚簇索引和非聚簇索引的区别1. 聚簇索引的数据在物理是间断的，叶子节点寄存的是数据【整行的值】，非聚簇索引数据不间断，叶子节点寄存指针为什么采纳自增id1. 如果数据是间断的，只有在前面插入数据就行2. 不是间断的，如果插入的页满了，就须要登程页决裂，把其余数据拷贝到其余页，页决裂是很耗时的，数据会导致页的合并3. 不必自增id用其余值得花会导致二级索引的叶子节点占用空间较大注： b加数叶子节点其实寄存的页，页外面在通过二分查找 ...

问题形容centos7装置mysql5.7时遇到一个诡异的问题 sudo yum localinstall https://dev.mysql.com/get/mysql57-community-release-el7-11.noarch.rpmsudo yum install mysql-community-server而后遇到了上面的问题Public key for mysql-community-libs-compat-xxx.rpm is not installed具体输入如下 Downloading packages:Delta RPMs disabled because /usr/bin/applydeltarpm not installed.(1/9): libaio-0.3.109-13.el7.x86_64.rpm | 24 kB 00:00:00 warning: /var/cache/yum/x86_64/7/mysql57-community/packages/mysql-community-common-5.7.37-1.el7.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 3a79bd29: NOKEYPublic key for mysql-community-common-5.7.37-1.el7.x86_64.rpm is not installed(2/9): mysql-community-common-5.7.37-1.el7.x86_64.rpm | 311 kB 00:00:00 (3/9): mysql-community-libs-5.7.37-1.el7.x86_64.rpm | 2.4 MB 00:00:00 (4/9): mysql-community-libs-compat-5.7.37-1.el7.x86_64.rpm | 1.2 MB 00:00:00 (5/9): openssl-1.0.2k-24.el7_9.x86_64.rpm | 494 kB 00:00:00 (6/9): openssl-libs-1.0.2k-24.el7_9.x86_64.rpm | 1.2 MB 00:00:00 (7/9): postfix-2.10.1-9.el7.x86_64.rpm | 2.4 MB 00:00:00 (8/9): mysql-community-client-5.7.37-1.el7.x86_64.rpm | 25 MB 00:00:01 (9/9): mysql-community-server-5.7.37-1.el7.x86_64.rpm | 174 MB 00:00:16 ---------------------------------------------------------------------------------------------------------------------------------------------------------------Total 12 MB/s | 207 MB 00:00:16 Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysqlImporting GPG key 0x5072E1F5: Userid : "MySQL Release Engineering <mysql-build@oss.oracle.com>" Fingerprint: a4a9 4068 76fc bd3c 4567 70c8 8c71 8d3b 5072 e1f5 Package : mysql57-community-release-el7-11.noarch (installed) From : /etc/pki/rpm-gpg/RPM-GPG-KEY-mysqlIs this ok [y/N]: yPublic key for mysql-community-libs-compat-5.7.37-1.el7.x86_64.rpm is not installed Failing package is: mysql-community-libs-compat-5.7.37-1.el7.x86_64 GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql解决形式：rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022胜利就点个赞吧，谢谢。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。介绍MySQL Test Run 简称MTR，是MySQL官网提供的自动化测试框架，执行脚本在公布门路的mysql-test目录下。 次要测试步骤，是通过执行一个case(*.test)中的语句（包含sql语句和其余治理语句），将case的输入记录保留在后果文件(*.result)中，或者是将语句执行后果与规范的输入后果作diff，如果呈现偏差就会报错。 MySQL自动化框架包含一组测试用例和用于运行它们的程序：perl 脚本(mysql-test-run.pl)和 c++ 二进制(mysqltest)。 perl 脚本：负责管制流程，包含启停、辨认执行哪些用例、创立文件夹、收集后果等操作。mysqltest：负责执行测试用例，包含读文件，解析特定语法，执行用例。装置装置依赖包本次装置环境是CentOS 8.5 yum -y install perl* -y下载安装包并解压本文采纳的MySQL版本是8.0.28，可依据须要自行抉择版本。 cd /home/wget https://dev.mysql.com/get/Downloads/MySQL-8.0/mysql-test-8.0.28-linux-glibc2.12-x86_64.tar.xztar -xvf mysql-test-8.0.28-linux-glibc2.12-x86_64.tar.xzmv mysql-8.0.28-linux-glibc2.12-x86_64 mysql_mtr_8.0.28cd /home/mysql_mtr_8.0.28/cp -r /path-to-db/* /home/mysql_mtr_8.0.28/ #将mysql安装包目录下的文件与mtr目录合并cd /home/mysql_mtr_8.0.28/mysql-test #进入mtr目录也可通过下载源码包进行编译装置，本次暂不进行介绍。 次要目录介绍include 蕴含.inc文件，用于测试开始时判断是否满足测试条件，在测试用例中通过source命令引入，就像C/C++的头文件，在mtr的体系中，咱们能够将许多可反复利用的测试语句，提取到*.inc文件中，放到对应的include目录中，以便在*.test中间接调用。 suite 蕴含所有测试suite，每一个suite为一个测试用例集，个别地，咱们将若干个测试性能点同属于一个功能模块的testcase放在一个大目录下，这个蕴含了t和r目录的大目录被称为一个testsuite。其中a.test文件会放在t目录，而a.result放在r目录。 测试示例咱们通过一个最简略的例子来阐明这个框架是怎么应用的。 创立测试用例在 mysql-test/t 目录下创立一个文件名为 mytest.test的测试用例： # vi mytest.test--disable_warningsDROP TABLE IF EXISTS t1;SET @@sql_mode='NO_ENGINE_SUBSTITUTION';--enable_warningsSET SQL_WARNINGS=1;CREATE TABLE t1 (a INT);INSERT INTO t1 VALUES (1);INSERT INTO t1 VALUES (2);DROP TABLE t1; 执行并查看后果# ./mtr --record mytest.testLogging: ./mtr mytest.testMySQL Version 8.0.28Checking supported features... - SSL connections supportedCollecting tests...Checking leftover processes...Removing old var directory...Creating var directory '/usr/local/mysql/mysql-test/var'...Installing system database...Using parallel: 1==============================================================================TEST RESULT TIME (ms) or COMMENT--------------------------------------------------------------------------worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 13000..13009worker[1] mysql-test-run: WARNING: running this script as _root_ will cause some tests to be skipped[100%] main.mytest [ pass ] 12--------------------------------------------------------------------------The servers were restarted 0 timesSpent 0.012 of 4 seconds executing testcasesCompleted: All 1 tests were successful. 看到successful阐明执行胜利。 ...

装置环境:windows10 专业版在卡法的过程中,咱们大部分会应用到数据库,本次介绍mysql数据库的装置教程!从官网下载社区版服务器压缩包 https://dev.mysql.com/downloads/mysql/ 在解压出的目录下新建my.ini文件,配置如下: [mysqld]# 设置3306端口port=3306# 设置mysql的装置目录basedir=G:\mysql-8.0.21-winx64# 设置mysql数据库的数据的寄存目录datadir=G:\mysql-8.0.21-winx64\data# 容许最大连接数max_connections=200# 容许连贯失败的次数。这是为了避免有人从该主机试图攻打数据库系统max_connect_errors=10# 服务端应用的字符集默认为UTF8character-set-server=utf8# 创立新表时将应用的默认存储引擎default-storage-engine=INNODB# 默认应用“mysql_native_password”插件认证default_authentication_plugin=mysql_native_password[mysql]# 设置mysql客户端默认字符集default-character-set=utf8[client]# 设置mysql客户端连贯服务端时默认应用的端口port=3306default-character-set=utf85.执行 mysqld --initialize-insecure 指令进行配置，装置门路会默认生成一个data文件夹 //留神:这里是要进入到 bin 目录下执行 命令的,步骤5和以下步骤都是在bin目录下执行的;6.如果你在操作的过程中呈现了以下谬误: 解决办法:是装置上面图片的软件 你就会发现这个谬误曾经解决了!6.而后在执行以下命令: 1.输出mysqld --install装置mysql服务2. 启动服务 net start mysql可能你会发现,mysql 服务无奈启动,此时,谬误如下: 遇到这个问题,解决办法如下:而后在执行:* mysqld --initialize-insecure* mysqld --install* net start mysql此时,你会发现mysql 曾经启动了!7.执行如下命令: 1. mysql -uroot -p;// 提醒输出明码,间接敲回车就能够了。1. show databases; 能够看到默认的数据库2. use mysql;3. ALTER USER 'root'@'localhost' IDENTIFIED BY 'chen'; //批改明码 ,此时我把明码批改成了 chen ,大家能够依据需要进行批改!做完以上的操作之后配置一下环境变量就能够啦。8.本期的分享到了这里就完结啦,心愿对你有所帮忙,让咱们一起致力走向巅峰!

MySQL 锁数据库锁设计初衷是解决并发问题，在多线程执行状况下保障最终后果如预期 能够通过 select * from sys.innodb_lock_waits; 查看被阻塞的事务 两阶段锁协定两阶段锁协定：在 InnoDB 事务中，行锁是在须要的时候才加上的，但并不是不须要了就立即开释，而是要等到事务完结时才开释 事务在执行的时候，并不是一次性把所有行锁都持有，而是执行到哪一行就拿哪一行的锁，等到最初 commit 的时候，一起开释 锁分类不同锁之间的兼容性： 行级锁共享锁（S Lock）和排他锁（X Lock）S 锁 容许事务读一行数据 X 锁 容许事务删除或更新一行数据 表级锁意向锁（Intention Locks）意向锁是为了 InnoDB 容许持有事务多种粒度的锁而设计的，容许在一行上同时持有表锁和行锁 意向锁一共有两种类型： 动向共享锁（IS）：想要获取一张表中某几行 S 锁，能够通过 SELECT ... FOR SHARE 设立动向排它锁（IX）：想要获取一张表中某几行 X 锁，能够通过 SELECT ... FOR UPDATE 设立记录锁（Record Locks）单个行记录的锁，总是会锁定索引记录，如果创建表时没有设置索引，就会锁定隐式创立的主键 例如：SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE; 会阻止任何事务更新、删除、批改该行数据 间隙锁（Gap Locks）锁定一个范畴，不蕴含记录自身，在可反复读隔离级别下才会失效，雷同区间的间隙锁之间是不互斥的 例如：SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE; 会阻止任何事务批改 [10,20] 之间的记录 ...

装置环境:windows10 专业版在卡法的过程中,咱们大部分会应用到数据库,本次介绍mysql数据库的装置教程!从官网下载社区版服务器压缩包 https://dev.mysql.com/downloads/mysql/ 在解压出的目录下新建my.ini文件,配置如下: [mysqld]# 设置3306端口port=3306# 设置mysql的装置目录basedir=G:\mysql-8.0.21-winx64# 设置mysql数据库的数据的寄存目录datadir=G:\mysql-8.0.21-winx64\data# 容许最大连接数max_connections=200# 容许连贯失败的次数。这是为了避免有人从该主机试图攻打数据库系统max_connect_errors=10# 服务端应用的字符集默认为UTF8character-set-server=utf8# 创立新表时将应用的默认存储引擎default-storage-engine=INNODB# 默认应用“mysql_native_password”插件认证default_authentication_plugin=mysql_native_password[mysql]# 设置mysql客户端默认字符集default-character-set=utf8[client]# 设置mysql客户端连贯服务端时默认应用的端口port=3306default-character-set=utf85.执行 mysqld --initialize-insecure 指令进行配置，装置门路会默认生成一个data文件夹 //留神:这里是要进入到 bin 目录下执行 命令的,步骤5和以下步骤都是在bin目录下执行的;6.如果你在操作的过程中呈现了以下谬误: 解决办法:是装置上面图片的软件 你就会发现这个谬误曾经解决了!6.而后在执行以下命令: 1.输出mysqld --install装置mysql服务2. 启动服务 net start mysql可能你会发现,mysql 服务无奈启动,此时,谬误如下: 遇到这个问题,解决办法如下:而后在执行:* mysqld --initialize-insecure* mysqld --install* net start mysql此时,你会发现mysql 曾经启动了!7.执行如下命令: 1. mysql -uroot -p;// 提醒输出明码,间接敲回车就能够了。1. show databases; 能够看到默认的数据库2. use mysql;3. ALTER USER 'root'@'localhost' IDENTIFIED BY 'chen'; //批改明码 ,此时我把明码批改成了 chen ,大家能够依据需要进行批改!做完以上的操作之后配置一下环境变量就能够啦。8.本期的分享到了这里就完结啦,心愿对你有所帮忙,让咱们一起致力走向巅峰!

mysql DNS反向解析会导致mysql慢： 查看DNS反向解析（呈现unauthenticated user阐明DNS反向解析在烦扰） mysql -u root -p’xxxxx’ -e “show processlist;” | grep user解决办法： vi /etc/my.iniskip-name-resolve:wq service mysql restart不想重启mysql解决办法：在/etc/hosts里手动加下ip和服务器名的对应关系

索引索引实质是一种数据结构，目标是为了进步数据查问的效率，尽可能减少 IO 次数。 大大减少服务器须要扫描的数据量帮忙服务器缩小排序过程和防止生成长期表能够把 随机 IO 转变为 程序 IO无效应用索引会大大晋升查问效率，但会减少磁盘空间和升高插入效率 常见的索引类型哈希索引哈希索引（Hash Index）是基于哈希表实现，是一种键值对（Key-Value）存储的数据结构； 长处：等值查问效率较高 毛病：范畴查问效率较低，须要一个一个查找 MySQL 中只有 Memory 引擎显示反对哈希索引，也是其默认索引类型 有序数组有序数组的元素是递增或递加的，能够通过二分算法，在 log(n) 工夫复杂度查到对应元素 长处：范畴查问效率较高 毛病：减少新元素速度较慢，须要拷贝数组 树形索引二叉树, 红黑树, B Tree, B+Tree 等 高性能索引策略图片来自《高性能 MySQL 第三版》 聚簇索引聚簇索引中索引即数据，数据行寄存在索引的叶子节点中 因数据行在磁盘中只寄存了一份，因而一个表只有一个聚簇索引 如果表中没定义主键，InnoDB 会抉择一个惟一的非空索引代替，如果没有非空索引则会隐式创立一个 6 字节大小的指针作为主键，同时也会成为聚簇索引 非聚簇索引非聚簇索引也称为二级索引，索引的叶子节点中寄存的是主键的值 当应用因为非聚簇索引查问时，因为非聚簇索引叶子节点中寄存的是主键的值，当查到主键的值后，须要依据主键再查到对应的数据行，这一过程叫做回表 基于非聚簇索引的查问须要多扫描一棵索引树。因而，咱们在利用中应该尽量应用主键查问 多列索引建设多列索引，数据会保留在索引树的节点上，能够利用笼罩索引准则，缩小回表 多列索引的索引项是依照索引定义外面呈现的字段程序排序的 笼罩索引当应用二级索引查问时，如果查问的内容保留在索引树上，则间接返回保留再索引数树的数据即可，不须要再回表查问 最左前缀B+ 树这种索引构造，能够利用索引的最左前缀，来定位记录 如果在 (name,age) 列上建设了索引，依据最左前缀，查问 name 也会走索引，从而能够缩小保护索引个数 只有满足最左前缀，就能够利用索引来减速检索。最左前缀能够是联结索引的最左 N 个字段，也能够是字符串索引的最左 M 个字符 like aa% 后含糊查问索引无效，like %aa 含糊查问索引有效 索引下推MySQL 5.6 引入的索引下推优化(index condition pushdown)，能够在索引遍历过程中，对索引中蕴含的字段先做判断(where条件里的匹配)，间接过滤掉不满足条件的记录，缩小回表次数 在仅能利用最左前缀索的场景下（而不是能利用全副联结索引），对不在最左前缀索引中的其余联结索引字段加以利用 explain 输入的 Extra 字段中会有 Using index condition; 即代表本次查问会利用到索引，且会利用到索引下推 ...

云起实验室 夏季训练营（1.17-3.8）可补卡！！！领云小宝五期夏季实战，从入门到进阶，以最佳实际帮忙开发者，疾速云上实际，云上学习。体验有礼，点击返回：https://developer.aliyun.com/adc/series/wintercamp夏季实战营第一期：从零到一上手玩转云服务器单期工作处分：实战营技能证书+定制鼠标三期工作处分：全网首发冬奥限量版云小宝五期工作处分：夏季实战营奖牌+定制书包+无影试用 体验简介本试验提供一个Linux零碎。首先，装置mysql；而后，执行mysql的罕用操作；最初，学习根本的SQL语句。 体验此场景后，你能够把握的能力有： MySQL装置MySQL日常运维治理根本SQL语句的应用背景常识业务背景MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发，目前属于Oracle旗下产品。MySQL 是最风行的关系型数据库管理系统，在 WEB 利用方面MySQL是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件之一。 MySQL是一种关联数据库管理系统，关联数据库将数据保留在不同的表中，而不是将所有数据放在一个大仓库内，这样就减少了速度并进步了灵活性。 MySQL所应用的 SQL 语言是用于拜访数据库的最罕用标准化语言。MySQL 软件采纳了双受权政策，它分为社区版和商业版，因为其体积小、速度快、总体领有成本低，尤其是开放源码这一特点，个别中小型网站的开发都抉择 MySQL 作为网站数据库。 因为其社区版的性能卓越，搭配 PHP 和 Apache 可组成良好的开发环境。 技术背景与其余的大型数据库例如：Oracle、DB2、SQL Server等相比，MySQL 自有它的不足之处，然而这丝毫也没有缩小它受欢迎的水平。对于个别的集体使用者和中小型企业来说，MySQL 提供的性能曾经入不敷出，而且因为 MySQL 是开放源码软件，因而能够大大降低总体领有老本。 Linux 作为操作系统，Apache 和 Nginx 作为 Web 服务器，MySQL 作为数据库，PHP/Perl/Python 作为服务器端脚本解释器。因为这四个软件都是收费或开放源码软件（FLOSS)，因而应用这种形式不必花一分钱（除开人工成本）就能够建设起一个稳固、收费的网站零碎，被业界称为 LAMP 或 LNMP 组合。 MySQL装置与配置MySQL是一个关系型数据库管理系统，本步骤领导您如何在ECS实例上装置MySQL。 1.执行如下命令，更新YUM源。 rpm -Uvh http://dev.mysql.com/get/mysql57-community-release-el7-9.noarch.rpm执行如下命令，装置MySQL。yum -y install mysql-community-server --nogpgcheck执行如下命令，查看MySQL版本号。mysql -V返回后果如下，示意您已胜利装置MySQL。 执行如下命令，启动MySQL服务。systemctl start mysqld执行如下命令，设置MySQL服务开机自启动。systemctl enable mysqld配置MySQL的root用户明码。执行如下命令，查看/var/log/mysqld.log文件，获取root用户的初始密码。 grep 'temporary password' /var/log/mysqld.log返回后果如下所示，您能够查看到root用户的初始密码。 ...

MySQL配置文件my.cnf 例子最具体翻译,能够保留做笔记用。 #BEGIN CONFIG INFO #DESCR: 4GB RAM, 只应用InnoDB, ACID, 大量的连贯, 队列负载大 #TYPE: SYSTEM #END CONFIG INFO # # 此mysql配置文件例子针对4G内存。 # 次要应用INNODB #解决简单队列并且连贯数量较少的mysql服务器 # # 将此文件复制到/etc/my.cnf 作为全局设置, # mysql-data-dir/my.cnf 作为服务器指定设置 # (@localstatedir@ for this installation) 或者放入 # ~/.my.cnf 作为用户设置. # # 在此配置文件中, 你能够应用所有程序反对的长选项. # 如果想获悉程序反对的所有选项 # 请在程序后加上"--help"参数运行程序. # # 对于独立选项更多的细节信息能够在手册内找到 # # # 以下选项会被MySQL客户端利用读取. # 留神只有MySQL附带的客户端应用程序保障能够读取这段内容. # 如果你想你本人的MySQL应用程序获取这些值 # 须要在MySQL客户端库初始化的时候指定这些选项 # [client] #password = [your_password] port = @MYSQL_TCP_PORT@ socket = @MYSQL_UNIX_ADDR@ # *** 利用定制选项 *** # # MySQL 服务端 # [mysqld] # 个别配置选项 port = @MYSQL_TCP_PORT@ socket = @MYSQL_UNIX_ADDR@ # back_log 是操作系统在监听队列中所能放弃的连接数, # 队列保留了在MySQL连贯管理器线程解决之前的连贯. # 如果你有十分高的连贯率并且呈现"connection refused" 报错, # 你就应该减少此处的值. # 查看你的操作系统文档来获取这个变量的最大值. # 如果将back_log设定到比你操作系统限度更高的值,将会没有成果 back_log = 50 # 不在TCP/IP端口上进行监听. # 如果所有的过程都是在同一台服务器连贯到本地的mysqld, # 这样设置将是加强平安的办法 # 所有mysqld的连贯都是通过Unix sockets 或者命名管道进行的. # 留神在windows下如果没有关上命名管道选项而只是用此项 # (通过 "enable-named-pipe" 选项) 将会导致mysql服务没有任何作用! #skip-networking # MySQL 服务所容许的同时会话数的下限 # 其中一个连贯将被SUPER权限保留作为管理员登录. # 即使曾经达到了连接数的下限. max_connections = 100 # 每个客户端连贯最大的谬误容许数量,如果达到了此限度. # 这个客户端将会被MySQL服务阻止直到执行了"FLUSH HOSTS" 或者服务重启 # 非法的明码以及其余在链接时的谬误会减少此值. # 查看 "Aborted_connects" 状态来获取全局计数器. max_connect_errors = 10 # 所有线程所关上表的数量. # 减少此值就减少了mysqld所须要的文件描述符的数量 # 这样你须要确认在[mysqld_safe]中 "open-files-limit" 变量设置关上文件数量容许至多4096 table_cache = 2048 # 容许内部文件级别的锁. 关上文件锁会对性能造成负面影响 # 所以只有在你在同样的文件上运行多个数据库实例时才应用此选项(留神仍会有其余束缚!) # 或者你在文件层面上应用了其余一些软件依赖来锁定MyISAM表 #external-locking # 服务所能解决的申请包的最大大小以及服务所能解决的最大的申请大小(当与大的BLOB字段一起工作时相当必要) # 每个连贯独立的大小.大小动静减少 max_allowed_packet = 16M # 在一个事务中binlog为了记录SQL状态所持有的cache大小 # 如果你常常应用大的,多申明的事务,你能够减少此值来获取更大的性能. # 所有从事务来的状态都将被缓冲在binlog缓冲中而后在提交后一次性写入到binlog中 # 如果事务比此值大, 会应用磁盘上的临时文件来代替. # 此缓冲在每个连贯的事务第一次更新状态时被创立 binlog_cache_size = 1M # 独立的内存表所容许的最大容量. # 此选项为了避免意外创立一个超大的内存表导致永尽所有的内存资源. max_heap_table_size = 64M # 排序缓冲被用来解决相似ORDER BY以及GROUP BY队列所引起的排序 # 如果排序后的数据无奈放入排序缓冲, # 一个用来代替的基于磁盘的合并分类会被应用 # 查看 "Sort_merge_passes" 状态变量. # 在排序产生时由每个线程调配 sort_buffer_size = 8M # 此缓冲被应用来优化全联结(full JOINs 不带索引的联结). # 相似的联结在极大多数状况下有十分蹩脚的性能体现, # 然而将此值设大可能加重性能影响. # 通过 "Select_full_join" 状态变量查看全联结的数量 # 当全联结产生时,在每个线程中调配 join_buffer_size = 8M # 咱们在cache中保留多少线程用于重用 # 当一个客户端断开连接后,如果cache中的线程还少于thread_cache_size, # 则客户端线程被放入cache中. # 这能够在你须要大量新连贯的时候极大的缩小线程创立的开销 # (一般来说如果你有好的线程模型的话,这不会有显著的性能晋升.) thread_cache_size = 8 # 此容许应用程序给予线程零碎一个提醒在同一时间给予渴望被运行的线程的数量. # 此值只对于反对 thread_concurrency() 函数的零碎有意义( 例如Sun Solaris). # 你可能够尝试应用 [CPU数量]*(2..4) 来作为thread_concurrency的值 thread_concurrency = 8 # 查问缓冲常被用来缓冲 SELECT 的后果并且在下一次同样查问的时候不再执行间接返回后果. # 关上查问缓冲能够极大的进步服务器速度, 如果你有大量的雷同的查问并且很少批改表. # 查看 "Qcache_lowmem_prunes" 状态变量来查看是否以后值对于你的负载来说是否足够高. # 留神: 在你表常常变动的状况下或者如果你的查问原文每次都不同, # 查问缓冲兴许引起性能降落而不是性能晋升. query_cache_size = 64M # 只有小于此设定值的后果才会被缓冲 # 此设置用来爱护查问缓冲,避免一个极大的后果集将其余所有的查问后果都笼罩. query_cache_limit = 2M # 被全文检索索引的最小的字长. # 你兴许心愿缩小它,如果你须要搜寻更短字的时候. # 留神在你批改此值之后, # 你须要重建你的 FULLTEXT 索引 ft_min_word_len = 4 # 如果你的零碎反对 memlock() 函数,你兴许心愿关上此选项用以让运行中的mysql在在内存高度缓和的时候,数据在内存中放弃锁定并且避免可能被swapping out # 此选项对于性能无益 #memlock # 当创立新表时作为默认应用的表类型, # 如果在创立示意没有特地执行表类型,将会应用此值 default_table_type = MYISAM # 线程应用的堆大小. 此容量的内存在每次连贯时被预留. # MySQL 自身常不会须要超过64K的内存 # 如果你应用你本人的须要大量堆的UDF函数 # 或者你的操作系统对于某些操作须要更多的堆, # 你兴许须要将其设置的更高一点. thread_stack = 192K # 设定默认的事务隔离级别.可用的级别如下: # READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE transaction_isolation = REPEATABLE-READ # 外部(内存中)长期表的最大大小 # 如果一个表增长到比此值更大,将会主动转换为基于磁盘的表. # 此限度是针对单个表的,而不是总和. tmp_table_size = 64M # 关上二进制日志性能. # 在复制(replication)配置中,作为MASTER主服务器必须关上此项 # 如果你须要从你最初的备份中做基于工夫点的复原,你也同样须要二进制日志. log-bin=mysql-bin # 如果你在应用链式从服务器构造的复制模式 (A->B->C), # 你须要在服务器B上关上此项. # 此选项关上在从线程上重做过的更新的日志, # 并将其写入从服务器的二进制日志. #log_slave_updates # 关上全查问日志. 所有的由服务器接管到的查问 (甚至对于一个谬误语法的查问) # 都会被记录下来. 这对于调试十分有用, 在生产环境中经常敞开此项. #log # 将正告打印输出到谬误log文件. 如果你对于MySQL有任何问题 # 你应该关上正告log并且认真审查谬误日志,查出可能的起因. #log_warnings # 记录慢速查问. 慢速查问是指耗费了比 "long_query_time" 定义的更多工夫的查问. # 如果 log_long_format 被关上,那些没有应用索引的查问也会被记录. # 如果你常常减少新查问到已有的零碎内的话. 一般来说这是一个好主见, log_slow_queries # 所有的应用了比这个工夫(以秒为单位)更多的查问会被认为是慢速查问. # 不要在这里应用"1", 否则会导致所有的查问,甚至十分快的查问页被记录下来(因为MySQL 目前工夫的精确度只能达到秒的级别). long_query_time = 2 # 在慢速日志中记录更多的信息. # 个别此项最好关上. # 关上此项会记录使得那些没有应用索引的查问也被作为到慢速查问附加到慢速日志里 log_long_format # 此目录被MySQL用来保留临时文件.例如, # 它被用来解决基于磁盘的大型排序,和外部排序一样. # 以及简略的长期表. # 如果你不创立十分大的临时文件,将其搁置到 swapfs/tmpfs 文件系统上兴许比拟好 # 另一种抉择是你也能够将其搁置在独立的磁盘上. # 你能够应用";"来搁置多个门路 # 他们会依照roud-robin办法被轮询应用. #tmpdir = /tmp # *** 复制无关的设置 # 惟一的服务辨识号,数值位于 1 到 2^32-1之间. # 此值在master和slave上都须要设置. # 如果 "master-host" 没有被设置,则默认为1, 然而如果疏忽此选项,MySQL不会作为master失效. server-id = 1 # 复制的Slave (去掉master段的正文来使其失效) # # 为了配置此主机作为复制的slave服务器,你能够抉择两种办法: # # 1) 应用 CHANGE MASTER TO 命令 (在咱们的手册中有残缺形容) - # 语法如下: # # CHANGE MASTER TO MASTER_HOST=<host>, MASTER_PORT=<port>, # MASTER_USER=<user>, MASTER_PASSWORD=<password> ; # # 你须要替换掉 <host>, <user>, <password> 等被尖括号突围的字段以及应用master的端口号替换<port> (默认3306). # # 例子: # # CHANGE MASTER TO MASTER_HOST='125.564.12.1', MASTER_PORT=3306, # MASTER_USER='joe', MASTER_PASSWORD='secret'; # # 或者 # # 2) 设置以下的变量. 不论如何, 在你抉择这种办法的状况下, 而后第一次启动复制(甚至不胜利的状况下, # 例如如果你输出错明码在master-password字段并且slave无奈连贯), # slave会创立一个 master.info 文件,并且之后任何对于蕴含在此文件内的参数的变动都会被疏忽 # 并且由 master.info 文件内的内容笼罩, 除非你敞开slave服务, 删除 master.info 并且重启slave 服务. # 因为这个起因,你兴许不想碰一下的配置(正文掉的) 并且应用 CHANGE MASTER TO (查看下面) 来代替 # # 所须要的惟一id号位于 2 和 2^32 - 1之间 # (并且和master不同) # 如果master-host被设置了.则默认值是2 # 然而如果省略,则不会失效 #server-id = 2 # # 复制构造中的master - 必须 #master-host = <hostname> # # 当连贯到master上时slave所用来认证的用户名 - 必须 #master-user = <username> # # 当连贯到master上时slave所用来认证的明码 - 必须 #master-password = <password> # # master监听的端口. # 可选 - 默认是3306 #master-port = <port> # 使得slave只读.只有用户领有SUPER权限和在下面的slave线程可能批改数据. # 你能够应用此项去保障没有应用程序会意外的批改slave而不是master上的数据 #read_only #*** MyISAM 相干选项 # 关键词缓冲的大小, 个别用来缓冲MyISAM表的索引块. # 不要将其设置大于你可用内存的30%, # 因为一部分内存同样被OS用来缓冲行数据 # 甚至在你并不应用MyISAM 表的状况下, 你也须要仍旧设置起 8-64M 内存因为它同样会被外部长期磁盘表应用. key_buffer_size = 32M # 用来做MyISAM表全表扫描的缓冲大小. # 当全表扫描须要时,在对应线程中调配. read_buffer_size = 2M # 当在排序之后,从一个曾经排序好的序列中读取行时,行数据将从这个缓冲中读取来避免磁盘寻道. # 如果你增高此值,能够进步很多ORDER BY的性能. # 当须要时由每个线程调配 read_rnd_buffer_size = 16M # MyISAM 应用非凡的相似树的cache来使得突发插入 # (这些插入是,INSERT SELECT, INSERT VALUES (), (), , 以及 LOAD DATA # INFILE) 更快. 此变量限度每个过程中缓冲树的字节数. # 设置为 0 会敞开此优化. # 为了最优化不要将此值设置大于 "key_buffer_size". # 当突发插入被检测到时此缓冲将被调配. bulk_insert_buffer_size = 64M # 此缓冲当MySQL须要在 REPAIR, OPTIMIZE, ALTER 以及 LOAD DATA INFILE 到一个空表中引起重建索引时被调配. # 这在每个线程中被调配.所以在设置大值时须要小心. myisam_sort_buffer_size = 128M # MySQL重建索引时所容许的最大临时文件的大小 (当 REPAIR, ALTER TABLE 或者 LOAD DATA INFILE). # 如果文件大小比此值更大,索引会通过键值缓冲创立(更慢) myisam_max_sort_file_size = 10G # 如果被用来更快的索引创立索引所应用临时文件大于制订的值,那就应用键值缓冲办法. # 这次要用来强制在大表中长字串键去应用慢速的键值缓冲办法来创立索引. myisam_max_extra_sort_file_size = 10G # 如果一个表领有超过一个索引, MyISAM 能够通过并行排序应用超过一个线程去修复他们. # 这对于领有多个CPU以及大量内存状况的用户,是一个很好的抉择. myisam_repair_threads = 1 # 主动检查和修复没有适当敞开的 MyISAM 表. myisam_recover # 默认敞开 Federated skip-federated # *** BDB 相干选项 *** # 如果你运行的MySQL服务有BDB反对然而你不筹备应用的时候应用此选项. 这会节俭内存并且可能减速一些事. skip-bdb # *** INNODB 相干选项 *** # 如果你的MySQL服务蕴含InnoDB反对然而并不打算应用的话, # 应用此选项会节俭内存以及磁盘空间,并且减速某些局部 #skip-innodb # 附加的内存池被InnoDB用来保留 metadata 信息 # 如果InnoDB为此目标须要更多的内存,它会开始从OS这里申请内存. # 因为这个操作在大多数古代操作系统上曾经足够快, 你个别不须要批改此值. # SHOW INNODB STATUS 命令会显示当先应用的数量. innodb_additional_mem_pool_size = 16M # InnoDB应用一个缓冲池来保留索引和原始数据, 不像 MyISAM. # 这里你设置越大,你在存取表外面数据时所须要的磁盘I/O越少. # 在一个独立应用的数据库服务器上,你能够设置这个变量到服务器物理内存大小的80% # 不要设置过大,否则,因为物理内存的竞争可能导致操作系统的换页平稳. # 留神在32位零碎上你每个过程可能被限度在 2-3.5G 用户层面内存限度, # 所以不要设置的太高. innodb_buffer_pool_size = 2G # InnoDB 将数据保留在一个或者多个数据文件中成为表空间. # 如果你只有单个逻辑驱动保留你的数据,一个单个的自增文件就足够好了. # 其余状况下.每个设施一个文件个别都是个好的抉择. # 你也能够配置InnoDB来应用裸盘分区 - 请参考手册来获取更多相干内容 innodb_data_file_path = ibdata1:10M:autoextend # 设置此选项如果你心愿InnoDB表空间文件被保留在其余分区. # 默认保留在MySQL的datadir中. #innodb_data_home_dir = <directory> # 用来同步IO操作的IO线程的数量. This value is # 此值在Unix下被硬编码为4,然而在Windows磁盘I/O可能在一个大数值下体现的更好. innodb_file_io_threads = 4 # 如果你发现InnoDB表空间损坏, 设置此值为一个非零值可能帮忙你导出你的表. # 从1开始并且减少此值晓得你可能胜利的导出表. #innodb_force_recovery=1 # 在InnoDb外围内的容许线程数量. # 最优值依赖于应用程序,硬件以及操作系统的调度形式. # 过高的值可能导致线程的互斥平稳. innodb_thread_concurrency = 16 # 如果设置为1 ,InnoDB会在每次提交后刷新(fsync)事务日志到磁盘上, # 这提供了残缺的ACID行为. # 如果你违心对事务平安折衷, 并且你正在运行一个小的食物, 你能够设置此值到0或者2来缩小由事务日志引起的磁盘I/O # 0代表日志只大概每秒写入日志文件并且日志文件刷新到磁盘. # 2代表日志写入日志文件在每次提交后,然而日志文件只有大概每秒才会刷新到磁盘上. innodb_flush_log_at_trx_commit = 1 # 减速InnoDB的敞开. 这会阻止InnoDB在敞开时做全革除以及插入缓冲合并. # 这可能极大减少关机工夫, 然而取而代之的是InnoDB可能在下次启动时做这些操作. #innodb_fast_shutdown # 用来缓冲日志数据的缓冲区的大小. # 当此值快满时, InnoDB将必须刷新数据到磁盘上. # 因为基本上每秒都会刷新一次,所以没有必要将此值设置的太大(甚至对于长事务而言) innodb_log_buffer_size = 8M # 在日志组中每个日志文件的大小. # 你应该设置日志文件总合大小到你缓冲池大小的25%~100% # 来防止在日志文件覆写上不必要的缓冲池刷新行为. # 不论如何, 请留神一个大的日志文件大小会减少复原过程所须要的工夫. innodb_log_file_size = 256M # 在日志组中的文件总数. # 通常来说2~3是比拟好的. innodb_log_files_in_group = 3 # InnoDB的日志文件所在位置. 默认是MySQL的datadir. # 你能够将其指定到一个独立的硬盘上或者一个RAID1卷上来进步其性能 #innodb_log_group_home_dir # 在InnoDB缓冲池中最大容许的脏页面的比例. # 如果达到限额, InnoDB会开始刷新他们避免他们障碍到洁净数据页面. # 这是一个软限度,不被保障相对执行. innodb_max_dirty_pages_pct = 90 # InnoDB用来刷新日志的办法. # 表空间总是应用双重写入刷新办法 # 默认值是 "fdatasync", 另一个是 "O_DSYNC". #innodb_flush_method=O_DSYNC # 在被回滚前,一个InnoDB的事务应该期待一个锁被批准多久. # InnoDB在其领有的锁表中自动检测事务死锁并且回滚事务. # 如果你应用 LOCK TABLES 指令, 或者在同样事务中应用除了InnoDB以外的其余事务平安的存储引擎 # 那么一个死锁可能产生而InnoDB无奈留神到. # 这种状况下这个timeout值对于解决这种问题就十分有帮忙. innodb_lock_wait_timeout = 120 [mysqldump] # 不要在将内存中的整个后果写入磁盘之前缓存. 在导出十分微小的表时须要此项 quick max_allowed_packet = 16M [mysql] no-auto-rehash # 仅仅容许应用键值的 UPDATEs 和 DELETEs . #safe-updates [isamchk] key_buffer = 512M sort_buffer_size = 512M read_buffer = 8M write_buffer = 8M [myisamchk] key_buffer = 512M sort_buffer_size = 512M read_buffer = 8M write_buffer = 8M [mysqlhotcopy] interactive-timeout [mysqld_safe] # 减少每个过程的可关上文件数量. # 正告: 确认你曾经将全零碎限度设定的足够高! # 关上大量表须要将此值设b open-files-limit = 8192

表构造本文总结自《MySQL技术底细：InnoDB存储引擎（第2版）》索引组织表InnoDB 存储引擎中，表都是依据主键程序组织寄存的，这种存储形式的表称为索引组织表（Index organized table） InnoDB 存储引擎表中，每张表都有主键，如果创立表时没有显式定义主键，则会依照以下规定创立： 如果表中有非空惟一索引（Unique Not Null），咋设该列为主键如果没有，则会主动创立 6 字节大小的指针如果有多个非空惟一索引，则会抉择定义索引程序时的第一个InnoDB 逻辑存储构造 表空间表空间能够看做 InnoDB 存储引擎最高层，所有数据都寄存在表空间中，落到磁盘上即 ibdata 文件，能够通过 innodb_file_per_table 参数设置每张表独自放到一个表空间内 段表空间由各种段组成，如：数据段、索引段、回滚段等 因为 InnoDB 存储引擎表是索引组织的，因而数据段即为 B+ 树的叶子节点，索引段为 B+ 树的非索引节点 区区是由间断的页组成，任何状况下大小都为 1MB，默认状况下 InnoDB 存储引擎页大小为 16KB，一个区由 64 个间断的页组成 页页是 InnoDB 磁盘治理的最小单位，默认状况下 InnoDB 存储引擎页大小为 16KB 行用于寄存每一行数据

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。[toc] 本文介绍如何利用MySQL Shell + GreatSQL 8.0.25构建一个三节点的MGR集群。 MySQL Shell是一个客户端工具，可用于方便管理和操作MySQL，反对SQL、JavaScript、Python等多种语言，也包含欠缺的API。MySQL Shell反对文档型和关系型数据库模式，通过X DevAPI能够治理文档型数据，通过AdminAPI能够治理InnoDB Cluster、InnoDB ClusterSet及InnoDB ReplicaSet等。 1. 装置筹备筹备好上面三台服务器： IP端口角色172.16.16.103306mgr1172.16.16.113306mgr2172.16.16.123306mgr3确保三个节点间的网络是能够互通的，并且没有针对3306和33061端口的防火墙拦挡规定。 利用yum装置MySQL Shell，版本抉择和GreatSQL雷同的8.0.25： $ yum install mysql-shell-8.0.25假设曾经参考前文 3. 装置部署MGR集群 做好MySQL Server的初始化并启动三个实例。 接下来间接利用MySQL Shell部署MGR。 2. 利用MySQL Shell构建MGR集群利用MySQL Shell构建MGR集群比较简单，次要有几个步骤： 查看实例是否满足条件。创立并初始化一个集群。一一增加实例。首先，用管理员账号 root 连贯到第一个节点： #在本地通过socket形式登入$ mysqlsh -Spath/mysql.sock root@localhostPlease provide the password for 'root@.%2Fmysql.sock': ********Save password for 'root@.%2Fmysql.sock'? [Y]es/[N]o/Ne[v]er (default No): yesMySQL Shell 8.0.25...执行命令 \status 查看以后节点的状态，确认连贯失常可用。 执行 dba.configureInstance() 命令开始查看以后实例是否满足装置MGR集群的条件，如果不满足能够间接配置成为MGR集群的一个节点： MySQL localhost JS > dba.configureInstance()Configuring local MySQL instance listening at port 3306 for use in an InnoDB cluster...This instance reports its own address as 172.16.16.10:3306#提醒以后的用户是管理员，不能间接用于MGR集群，须要新建一个账号ERROR: User 'root' can only connect from 'localhost'. New account(s) with proper source address specification to allow remote connection from all instances must be created to manage the cluster.1) Create remotely usable account for 'root' with same grants and password2) Create a new admin account for InnoDB cluster with minimal required grants3) Ignore and continue4) CancelPlease select an option [1]: 2 <-- 这里咱们抉择计划2，即创立一个最小权限账号Please provide an account name (e.g: icroot@%) to have it created with the necessaryprivileges or leave empty and press Enter to cancel.Account Name: GreatSQLPassword for new account: ********Confirm password: ********applierWorkerThreads will be set to the default value of 4.The instance '172.16.16.10:3306' is valid to be used in an InnoDB cluster.Cluster admin user 'GreatSQL'@'%' created.The instance '172.16.16.10:3306' is already ready to be used in an InnoDB cluster.Successfully enabled parallel appliers.实现查看并创立完新用户后，退出以后的管理员账户，并用新创建的MGR专用账户登入，筹备初始化创立一个新集群： ...

创立表 减少 删除 查找 批改 连表(inner join)

#!/bin/bash# 一键装置mysql5.7.35#安装包下载目录MYSQL_DOWNLOAD_DIR=/data/software/#数据包目录MYSQL_INSTALL_DIR=/data/modules/#数据库信息info_mysql(){ echo "======> MYSQL装置信息 <======"; echo "Mysql版本:5.7.35 "; echo "下载目录:/data/software/ "; echo "装置目录:/data/modules/ ";}#旧版mysqluninstall_mysql(){ echo "\n======> MYSQL装置筹备 <======"; echo "残留Mysql检测......." echo "卸载旧版mysql......." echo [+] Uninstall Mysql yum remove mysql* -y yum remove mariadb* -y if [ -f "/etc/my.cnf" ];then rm -rf /etc/my.cnf fi if [ -f "/root/.mysql_sercret" ];then rm -rf /root/.mysql_sercret fi if [ -d "/var/lib/mysql" ];then rm -rf /var/lib/mysql fi if [ -d "/usr/lib64/mysql" ];then rm -rf /usr/lib64/mysql fi if [ -d "/usr/share/mysql" ];then rm -rf /usr/share/mysql fi echo "卸载实现!"} #下载mysqlIS_CINTINUE='y';download_mysql(){ echo "装置目录检测......." if [ ! -d "/data/software" ]; then echo "创立下载目录......." mkdir -p /data/software/ fi if [ ! -d "/data/modules/mysql/" ]; then echo "创立数据目录......." mkdir -p /data/modules/ fi echo " 目录准备就绪 !"; echo "======> MYSQL装置过程 <======"; cd /data/software/ read -p " 确认是否装置？【y/n】" IS_CINTINUE if [[ $IS_CINTINUE == 'y' ]]; then echo "请稍等,大概须要20分钟,正在下载MYSQL......."; cd /data/software/ file="/data/software/mysql-boost-5.7.35.tar.gz" if [ ! -f $file ]; then echo "File not found!" yum install -y wget && wget -c https://cdn.mysql.com/archives/mysql-5.7/mysql-boost-5.7.35.tar.gz; echo "下载实现,正在解压......."; tar -zxvf mysql-boost-5.7.35.tar.gz -C /data/modules/ cd /data/modules/ mv /data/modules/mysql-5.7.35/ mysql exit 0 fi echo "解压实现,执行装置......."; #yum install -y wget && wget -c https://cdn.mysql.com/archives/mysql-5.7/mysql-5.7.35-el7-x86_64.tar.gz; else echo "请您自行下载安装包！"; exit; fi}#装置mysqlinstall_mysql(){ echo "======> 装置mysql依赖....... <======"; yum -y install gcc gcc-devel gcc-c++ gcc-c++-devel autoconf* automake* zlib* libxmlncurses-devel ncurses libgcrypt libtool* cmake openssl openssl-devel bisonbison-devel perl-Data-Dumper boost boost-doc boost-devel yum -y install gcc make cmake ncurses-devel libxml2-devel libtool-ltdl-devel gcc-c++ autoconf automake bison zlib-devel echo "======> 装置前的设置 <======"; sleep 2s cd /data/modules/mysql/ mkdir data sleep 2s cmake -DCMAKE_INSTALL_PREFIX=/data/modules/mysql/ \ -DMYSQL_DATADIR=/data/modules/mysql/data \ -DSYSCONFDIR=/etc \ -DWITH_MYISAM_STORAGE_ENGINE=1 \ -DWITH_INNOBASE_STORAGE_ENGINE=1 \ -DWITH_MEMORY_STORAGE_ENGINE=1 \ -DWITH_READLINE=1 \ -DMYSQL_UNIX_ADDR=/tmp/mysqld.sock \ -DMYSQL_TCP_PORT=3306 \ -DWITH_BOOST=/data/modules/mysql/boost \ -DENABLED_LOCAL_INFILE=1 \ -DWITH_PARTITION_STORAGE_ENGINE=1 \ -DEXTRA_CHARSETS=all \ -DDEFAULT_CHARSET=utf8 \ -DDEFAULT_COLLATION=utf8_general_ci echo "======> 创立mysql用户和组 <======"; cd /data/modules/mysql/ sleep 2s make && make install groupadd mysql && useradd mysql -g mysql -M -s /sbin/nologin && chown mysql:mysql /data/modules/mysql/ # if [ $? -eq 0 ];then # echo "======> 设置胜利！开始编译装置，大概须要20分钟，急躁期待...<======"; # sleep 2s # make && make install # if [ $? -eq 0 ]; then # cd ~ # echo "======> 编译胜利！开始设置组和用户！ <======"; # sleep 2s # groupadd mysql && useradd mysql -g mysql -M -s /sbin/nologin && chown mysql:mysql /data/modules/mysql/ # else # echo "======> 编译失败！ <======"; # exit; # fi # else # echo "======> 设置失败！ <======"; # exit; # fi echo "======> 装置实现! <======";}#配置Mysqlconfiguration_mysql(){echo "======> 配置mysql <======";cd /data/modules/mysql/touch mysql.pidecho "10254" > /data/modules/mysql/mysql.pidtouch mysql.errtouch mysqld.sockchown mysql:mysql /data/modules/mysql/mysql.pidchown mysql:mysql /data/modules/mysql/mysql.errchown mysql:mysql /data/modules/mysql/data/mysqld.sockcat > /etc/my.cnf<<EOF[client]port = 3306socket = /data/modules/mysql/data/mysqld.sock[mysqld]#server-id = 6878 #运行IDbind-address=0.0.0.0 #绑定地址运行近程连贯port=3306 #Mysql凋谢的端口user=mysql #数据库登录用户basedir=/data/modules/mysql/ #Mysql装置的绝对路径datadir=/data/modules/mysql/data #Mysql数据寄存的绝对路径socket=/data/modules/mysql/data/mysqld.sock #套接字文件log-error=/data/modules/mysql/mysql.err #mysql生成的谬误日志寄存的门路pid-file=/data/modules/mysql/mysql.pid #为mysqld程序指定一个寄存过程ID的文件character_set_server=utf8 #数据库字符编码symbolic-links=0 #是否开启链接符号explicit_defaults_for_timestamp=true #数据库timestamp类型的列自动更新 EOFsleep 2secho "初始化mysql.......";cd /data/modules/mysql/bin./mysqld --defaults-file=/etc/my.cnf --basedir=/data/modules/mysql/ --datadir=/data/modules/mysql/data/ --user=mysql --initializeln -s /data/modules/mysql/bin/mysql /usr/bin}#将mysql设置成为服务启动service_mysql(){ echo "======> 制作服务启动 <======"; cd /data/modules/mysql /bin/cp -rf support-files/mysql.server /etc/init.d/mysqld chmod a+wrx /etc/init.d/mysqld if [ $? -eq 0 ]; then echo "======> 服务设置胜利！ <======"; cd ~ service mysqld start sleep 2s service mysqld stop sleep 2s else echo "======> 服务设置失败！ <======"; fi echo "======> 增加到开机启动项！ <======"; chkconfig --add mysqld if [ $? -eq 0 ]; then echo "======> 设置开机启动项胜利！ <======"; else echo "======> 设置开机启动项失败！ <======"; fi service mysqld stop echo "======> 配置环境变量 <======"; echo "export PATH=$PATH:/data/modules/mysql/bin/" >>/etc/profile source /etc/profile echo "启动mysql服务....... "； service mysqld start echo "Mysql曾经启动....... "；}#启动数据库设置明码# mysql_password='123456'# up_mysql(){# cd /data/modules/mysql/# echo "======> 请输出数据库明码: <======";# read -p "输出明码：" -s mysql_password echo# echo password read, is "$mysql_password"# # read -p " 确认是否装置？【y/n】" IS_CINTINUE# # ./bin/mysqladmin -u root password "123456"# if [ $? -eq 0 ];then# echo "设置root明码胜利！";# else# echo "设置root明码失败！";# fi# source /etc/profile# }#完结装置end_mysql(){ echo "运行端口: 3306" echo "数据库用户: mysql" echo "数据库root明码(root@localhost前面):" cat /data/modules/mysql/mysql.err | grep root@localhost: echo "数据库装置门路: /data/modules/mysql/ " echo "数据库数据门路: /data/modules/mysql/data " mysql -uroot -p}#装置流程mysql(){ #数据库信息 info_mysql #旧版数据库卸载 uninstall_mysql #下载数据库 download_mysql #装置数据库 install_mysql #配置数据库 configuration_mysql #数据库以服务启动 service_mysql #启动MySQL设置明码 #显示数据库信息 info_mysql end_mysql}mysql

作者：李鹏博 爱可生 DBA 团队成员，会变身，次要负责 MySQL 故障解决和 SQL 审核优化。对技术执着，为客户负责。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 随着 MySQL 版本的不断更新，对 DDL 操作的反对也在一直的欠缺和更新：比方从 MySQL 5.6 引入 Online DDL ，在 MySQL 5.7 对 Online DDL 进一步欠缺，到当初的 8.0 版本，则对 DDL 的实现从新进行了设计，比方 DDL 操作反对原子个性，在 MySQL 8.0.27 引入并行 DDL 。本篇就来探索一下 MySQL 8.0.27 的并行 DDL 对于 DDL 操作速度的晋升。 MySQL 8.0.14 引入了 innodb_parallel_read_threads 变量来管制扫描聚簇索引的并行线程。MySQL 8.0.27 引入了 innodb_ddl_threads 变量来管制用于创立二级索引时的并行线程数量，此参数个别和一并引入的 innodb_ddl_buffer_size 一起应用，innodb_ddl_buffer_size 用于指定进行并行 DDL 操作时可能应用的 buffer 大小，buffer 是在所有的 DDL 并行线程中平均分配的，所以个别如果调大 innodb_ddl_threads 变量时，也须要调大 innodb_ddl_buffer_size 的大小。 innodb_ddl_threads 、innodb_ddl_buffer_size 和 innodb_parallel_read_threads 的默认大小别离为： ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GTID概述MySQL5.6 在原有主从复制的根底上减少了一个新的复制形式，即基于GTID的复制形式，它由UUID和事务ID两个局部组成，具备如下特点。GTID事务是全局唯一性的，并且一个事务对应一个GTID值。一个GTID值在同一个MySQL实例上只会执行一次。GTID相较与传统复制的劣势主从搭建更加简便，不必手动顺便指定position地位。复制集群内有一个对立的标识，辨认、治理上更不便。故障转移更容易，不必像传统复制那样须要找 log_file 和 log_Pos的地位。通常状况下GTID是间断没有空洞的，更能保证数据的一致性，零失落。绝对于ROW复制模式，数据安全性更高，切换更简略。比传统的复制更加平安，一个GTID在一个MySQL实例上只会执行一次，防止反复执行导致数据凌乱或者主从不统一。GTID本身存在哪些限度在一个复制组中，必须都要开启GTID。MySQL5.6开启GTID须要重启。不反对sql_slave_skip_counte操作，传统复制能够应用这个命令跳过事务。不容许在一个SQL同时更新一个事务引擎和非事务引擎的表，如InnoDB和MyISAM。对于create temporary table 和drop temporary table语句不反对。不反对create table … select 语句复制。GTID工作原理简略介绍master节点在更新数据的时候，会在事务前产生GTID信息，一起记录到binlog日志中。slave节点的io线程将binlog写入到本地relay log中。而后SQL线程从relay log中读取GTID，设置gtid_next的值为该gtid，而后比照slave端的binlog是否有记录。如果有记录的话，阐明该GTID的事务曾经运行，slave会疏忽。如果没有记录的话，slave就会执行该GTID对应的事务，并记录到binlog中。如何开启GTID复制除传统复制须要开启的binlog相干参数之外，GTID同步需额定开启如下参数设置，留神主从节点须要同步开启。gtid_mode=on # 开启GTIDenforce-gtid-consistency=on # 须要同步设置该参数log-slave-updates=1 # 5.6 版本须要开启该参数查看GTID相干参数[root@GreatSQL][(none)]>show variables like '%gtid%';+----------------------------------+-------------------------------------------------------------------------------------+| Variable_name | Value |+----------------------------------+-------------------------------------------------------------------------------------+| binlog_gtid_simple_recovery | ON || enforce_gtid_consistency | ON || gtid_executed | 613743f5-8b1c-11ec-9922-00155dcff911:1-14 || gtid_executed_compression_period | 0 || gtid_mode | ON || gtid_next | AUTOMATIC || gtid_owned | || gtid_purged | || session_track_gtids | OFF |+----------------------------------+-------------------------------------------------------------------------------------+9 rows in set (0.00 sec)参数简要阐明参数名含意介绍binlog_gtid_simple_recovery该参数是管制当MySQL服务重启或启动时候主动寻找GTIDs的值。enforce_gtid_consistency该参数是强制要求只容许复制事务平安的事务，请看下面步骤的具体限度。gtid_executed曾经执行过的GTID信息。gtid_executed_compression_period启用GTID时，服务器会定期在mysql.gtid_executed表上执行压缩。通过设置gtid_executed_compression_period零碎变量，能够管制压缩表之前容许的事务数，从而管制压缩率。设置为0时，则不进行压缩。gtid_mode是否开启GTID模式gtid_next示意下一个要执行的GTID信息gtid_owned该参数蕴含全局和session，全局示意所有服务器领有GTIDs，session级别示意以后client领有的所有GTIDs。gtid_purged曾经purge掉的GTIDs，purged掉的GTIDs会蕴含到gtid_executed中。session_track_gtids该参数是管制用于捕捉的GTIDs和在OK PACKE返回的跟踪器。GTID与传统模式建设复制时候语句的不同点# 传统复制change master to master_host="127.0.0.1",master_port=3310,MASTER_USER='sync',MASTER_PASSWORD='GreatSQL',MASTER_LOG_FILE='log-bin.000005', MASTER_LOG_POS=4111;# GTID复制change master to master_host="127.0.0.1",master_port=3310,MASTER_USER='sync',MASTER_PASSWORD='GreatSQL',MASTER_AUTO_POSITION=1GTID同步在建设复制的时候，将传统复制由人为指定binlog的pos位点改为了MASTER_AUTO_POSITION=1主动获取binlog的pos位点。 GTID同步状态简略解析除了传统的查看binlog和pos值之外，GTID模式能够更直观的查看某个事务执行的状况。[root@GreatSQL][(none)]>show slave status\G;*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.6.215 Master_User: sync Master_Port: 3306 Connect_Retry: 60 Master_Log_File: binlog.000001 Read_Master_Log_Pos: 2425 Relay_Log_File: mgr2-relay-bin.000002 Relay_Log_Pos: 2634 Relay_Master_Log_File: binlog.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 2425 Relay_Log_Space: 2842 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 2153306 Master_UUID: 613743f5-8b1c-11ec-9922-00155dcff911 Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 613743f5-8b1c-11ec-9922-00155dcff911:1-10 Executed_Gtid_Set: 613743f5-8b1c-11ec-9922-00155dcff911:1-10,652ade08-8b1c-11ec-9f62-00155dcff90a:1-2 Auto_Position: 1 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: Master_public_key_path: Get_master_public_key: 0 Network_Namespace:1 row in set, 1 warning (0.01 sec)ERROR:No query specifiedGTID相要害参数阐明参数名含意介绍Retrieved_Gtid_SetSlave节点曾经接管到的Master节点的GTIDsExecuted_Gtid_SetSlave节点曾经执行的GTIDsAuto_Position主动获取position地位，显示为1总结篇幅所限临时写这么多，下周会持续出对于主从复制相干的内容，欢送追更，另外受限于集体能力和教训，内容不免错漏，若有谬误欢送评论区指出更正。Enjoy GreatSQL :) ...

I、参数 innodb_file_per_table OFF表的数据放在零碎共享表空间，也就是跟数据字典放在一起ON每个 InnoDB 表数据存储在一个以 .ibd 为后缀的文件中，V5.6.6-默认1、倡议ON，因为，一个表独自存储为一个文件更容易治理，而且 drop table 命令间接删除这个文件。而如果是放在共享表空间中，即便表删掉了，空间也是不会回收的。2、删除整个表时应用 drop table 命令回收表空间。然而删除某些行就会遇到问题：表中的数据被删除了，然而表空间却没有被回收。II、为什么表中的数据被删除了，然而表空间却没有被回收1、删除一行只是标记为删除，理论磁盘空间未回收，可复用。2、delete 命令把整个表的数据删除的后果是，所有的数据页都会被标记为可复用。然而磁盘上，文件不会变小。 这些能够复用，而没有被应用的空间，看起来就像是“空洞”。3、空洞的起因：①删除表记录，被删除的记录只是被标记删除，索引值所在的空间能被复用，然而没有真正的删除； ②新增表记录，如果索引的值是随机扩散的，那么会造成数据页的决裂，也会造成空洞；③更新索引上的值，实际上是把旧值标记为删除，而后新增一个新值，旧值尽管能被复用，然而还是造成了空洞。 III、重建表 alter table A engine=InnoDB 以去除空洞，膨胀空间MySQL 5.6 之前要求在整个 DDL 过程中，表 A 中不能有更新。也就是说，这个 DDL 不是 Online 的。 如果在这个过程中，有新的数据要写入到表 A 的话，就会造成数据失落。 Online DDL（V5.6-）1、建设一个临时文件，扫描表 A 主键的所有数据页；2、用数据页中表 A 的记录生成 B+ 树，存储到临时文件中；3、生成临时文件的过程中，将所有对 A 的操作记录在一个日志文件（row log）中，对应的是图中 state2 的状态；4、临时文件生成后，将日志文件中的操作利用到临时文件，失去一个逻辑数据上与表 A 雷同的数据文件，对应的就是图中 state3 的状态；5、用临时文件替换表 A 的数据文件。 Online DDL 其实是会先获取MDL写锁, 再进化成MDL读锁；但MDL写锁持有工夫比拟短，所以能够称为Online；而MDL读锁，不阻止数据增删查改，但会阻止其它线程批改表构造；IV、Online 和 inplace1、DDL 过程如果是 Online 的，就肯定是 inplace 的；2、反过来未必，也就是说 inplace 的 DDL，有可能不是 Online 的。截止到 MySQL 8.0，添加全文索引（FULLTEXT index）和空间索引 (SPATIAL index) 就属于这种状况。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。Linux 操作系统有诸多自带和第三方的监控工具，以下从不同维度来整顿罕用的一些监控工具。CPUtop（经典的Linux工作管理工具）示例：top -n 1 -bvmstat（展示给定工夫距离的服务器的状态值,包含服务器的CPU使用率，内存应用）示例：vmstat 1 10 #每1秒采集一次共采集10次pidstat（过程实时监控）示例：pidstat -u 1 -p pidmpstat（多CPU实时监控工具）示例：mpstat -P ALL 1 5sar （性能监控和瓶颈查看）示例：sar -udstat（dstat 是一个能够取代vmstat，iostat，netstat和ifstat这些命令的多功能产品）示例：dstat 2 10（每2秒采集一次共采集10次）内存top示例：top -n 1 -bpidstat示例：pidstat -rfree（查看以后零碎的物理内存应用状况）示例：free -mhsar （性能监控和瓶颈查看）示例：sar -r 10 3（每10秒采样一次，间断采样3次）vmstat示例：vmstat 2 1磁盘IOiostat （IO实时监控）示例：iostat -d -x -k 1 10iotop（监控零碎中各个过程对IO的使用量）示例：iotoppidstat示例: pidstat -dsar示例：sar -dvmstat示例：vmstat 2 1网络netstat（监控TCP/IP网络)示例：netstat -nltupiftop（实时流量监控工具）示例：iftop -i em2ss（获取socket统计信息,它能够显示和netstat相似的内容）示例：ss -aA tcpsar示例：sar -n EDEV 1 5tcpdump（抓包工具）示例：tcpdump -i em1 host 192.168.1.1 and port 80tcpflow（剖析网络流量） 示例：tcpflow -i em1 port 80nload（用于查看linux网络流量情况,实时输入） 示例：nload -t 200 -i 1024 -o 128 -U M零碎负载CPU负载阐明如果某个程序频繁的进行计算、逻辑判断等操作，那么此类程序次要依赖于CPU的处理速度，故称之为"计算密集型程序"。IO负载阐明如果某个程序频繁的从磁盘中读取写入文件，那么这种类型的操作次要依赖于磁盘的读取速度，也就是输入输出（input/output）简写为I/O。此类I/O负载的程序，称为I/O密集型程序。top示例：topuptime示例：uptimesar示例：sar -q 1 20其余工具htop（相似top，比top更加人性化）glances（相似top，基于 Python 的零碎遥测监控工具）strace（罕用来跟踪过程执行时的零碎调用和所接管的信号）dtrace（动静跟踪）valgrind（内存透露检测）dmesg（内核信息）Enjoy GreatSQL :) ...

事务事务个性原子性（A）事务要么全副胜利，要么全副失败，不会处于中间状态 一致性（C）对数据有特定的预期状态，如非空，外键等等，这些更应该由应用层提供，数据库应该只用来保留数据而不解决具体逻辑 依据论文作者评论所说 C 只是为了使 ACID 更加顺口 隔离性（I）并发执行的多个事务之间须要肯定的隔离级别来保证数据的正确性 持久性（D）数据库须要保障事务一旦提交，就应该永恒保留到磁盘中 事务隔离级别隔离级别越高，并行性能越低，从而导致性能降落 查看 MySQL 的默认隔离级别，能够看到 MySQL 默认隔离级别为：可反复读 mysql> show variables like 'transaction_isolation';+-----------------------+-----------------+| Variable_name | Value |+-----------------------+-----------------+| transaction_isolation | REPEATABLE-READ |+-----------------------+-----------------+读未提交当事务还没提交时，其所做的更改就会被其它事务看到，会导致脏读（Dirty Read） 读提交当一个事务提交后，所做批改才会被其它事务所看到 该隔离级别是大多数数据库默认的，如 Oracle, PostgreSQL, SQL Server 等 可反复读在同一个事务执行过程中屡次读取同样记录的后果是一样的，会导致幻读（Phantom Read），当事务中须要应用 SELECT 语句查问，依据后果再更新数据就会导致更新谬误 如：给员工没工作时安顿新工作，当事务开始的时候查问到该员工须要安顿新工作，在执行 INSERT 操作安顿新工作时，别的事务在这个期间也安顿了新工作，就会导致工作安顿两份 MySQL 通过多版本并发管制（MVCC）技术解决了幻读问题，用于进步高并发下的吞吐性能 MVCC通过保留某个工夫点的快照来实现的，InnoDB 的 MVCC 是通过在每行记录前面保留两个暗藏的列实现的，一个是创立工夫，另一个是删除工夫（存储的不是具体的工夫，而是零碎版本号，每次开启事务会主动递增） 串行化对于某一行数据的读取和批改都会加锁，会重大影响性能 MySQL 采纳两阶段提交（2PL）来实现可串行化隔离 MySQL 事务启动形式显示启动事务begin 或 start transaction 配套的提交语句是 commit，回滚语句是 rollback。 set autocommit=0 这个命令会将这个线程的主动提交关掉。意味着如果你只执行一个 select 语句，这个事务就启动了，而且并不会主动提交。这个事务继续存在直到你被动执行 commit 或 rollback 语句，或者断开连接。 能够通过 select * from information_schema.INNODB_TRX; 查问以后数据库的所有事务 ...

SQL执行流程连接器能够通过下边命令连贯到 MySQL 服务中 mysql -h$ip -P$port -u$user -p$password当连贯胜利后如不执行 SQL，连贯会进入 Sleep 状态，能够通过 show processlist; 查问到以后所有连贯 如果连贯太长时间（由 wait_timeout 管制，单位为秒）没有执行工作，则会被断开连接，能够通过 show variables like 'wait_timeout'; 查看默认工夫 当用户连贯胜利后，权限就确定下来。即便批改权限，依然须要下次从新连贯能力失效 查问缓存（Query Cache）因为缓存效率不高，在 MySQL8 （MySQL官网阐明）中曾经被删除 Although MySQL Query Cache was meant to improve performance, it has serious scalability issues and it can easily become a severe bottleneck.弃用缓存次要起因： 对表中数据的任何一个更新，都会导致与该表无关的所有缓存生效，如果数据批改比拟频繁则会导致缓存性价比很低查问必须 byte-for-byte 都雷同，也就是雷同的语句才会查问到缓存，Query Cache 不会对查问做任何解析优化语法分析语法分析阶段次要有两个工作： 解析语句，把传入的 SQL 语句生成对应的外部数据结构（解析树）查看语句中的关键词，表，字段是否存在优化器当对应的 SQL 曾经转化为解析树后，就须要通过优化器进行优化，尽可能减少扫描的行数。当优化器阶段执行后，整个语句的执行计划就曾经确定下来 MySQL 优化器所做优化次要包含： 重写查问决定表的读写程序抉择适合的索引执行器MySQL 通过分析器晓得了你要做什么，通过优化器晓得了该怎么做，于是就进入了执行器阶段，开始执行语句。 首先会查看语句是否由执行权限，如果没有则会返回权限谬误 存储引擎只负责存储数据，执行器通过获取存储引擎的一行一行数据，来确定最终查问后果 为什么权限查看要放到执行阶段呢？有些时候，SQL语句要操作的表不只是SQL字面上那些。比方如果有个触发器，得在执行器阶段（过程中）能力确定。优化器阶段前是无能为力的

resultMap元素是mybatis中高级查问映射的一个元素，当表中字段名与pojo类中的属性不同，或者是多表查问，嵌套查问个别都会应用resultMap元素进行自定义映射。

前几天做一个后盾治理的我的项目，发现前端拿到的工夫戳值是对的，然而存入数据库之后却始终存储的是2147483647，通过new Date()解析之后是Mon Jan 26 1970 04:31:23 GMT+0800 (中国规范工夫)，真是百思不得其解，前端用的是element-ui的dateTimePicker获取的日期和工夫。起初通过多方排查之后，确定以及必定前端没有问题，nodejs搭建的服务端也没问题，问题就出在了mysql数据库。起初我留神到了长度/值这个属性，最开始我设置字段类型是INT，给了50的长度（其实始终最长就是11，尽管显示的50），然而起初我想将其批改的更长时发现，始终只能放弃在11的长度值（对于数据库并不精通的我只晓得我申请数据须要数字类型）。起初到网上一查发现了始终显示2147483647的起因，其实就是长度的问题，2147483647就是INT的最大贮存长度（可能说的有误，对数据库不够业余）。于是我就将字段类型改为了Varchar，前端申请到数据时将字符串类型的数据转换成了数字类型。最终得以解决，通过这次问题又学到一个知识点，就很棒！

Rainbond 这款产品始终致力于买通企业应用交付的全流程，这个流程中不可或缺的一环是企业应用的一直降级、迭代。Rainbond 特有的能力，是能够将囊括多个服务组件的企业应用零碎进行打包，并执行一键装置、降级以及回滚的操作。上述的内容仅仅解决了应用程序自身的版本控制问题。企业应用的降级迭代流程想要齐全实现自动化，还须要可能主动解决数据库表构造（Schema）的版本控制。通过一直的摸索，Rainbond 首先在源码构建畛域借助业界当先的 Liquibase 集成了云原生时代的数据库 Schema 版本治理的能力。Schema版本治理难题数据库表构造（Schema）定义了数据表（Table）的名字，以及每一个数据表中所蕴含的数据列（Column）的名字、属性等信息。它形容了一个数据库所领有的框架，记录在数据库中的数据都须要遵循 Schema 里的定义。 区别于应用程序本身的降级，Schema 版本治理问题，实质上是一种长久化数据的降级，这一特色随同着两个疑难： 长久化数据如何降级：云原生时代的交付，曾经无奈跳脱出容器化、平台化的特色。各大云原生平台在进行软件交付过程中，都不会轻易将长久化数据纳入版本控制体系中去。起因很简略，每个交付环境中的数据都是不同的，降级过程中很难抉择长久化数据的对立版本治理计划。哪些长久化数据须要降级：既然难以抉择长久化数据的对立版本治理计划，那么退而求其次，是否能够优先选择必要的长久化数据进行版本治理。放大范畴之后，就突出了数据库表构造这一非凡长久化数据类型。其版本治理的必要性是不言而喻的，应用程序自身从V1版本升级到了V2版本，那么对应的数据库表构造也须要减少必要的新表、新列。这两个疑难引出了本文的宗旨：在企业级软件交付畛域，如何正当的在每次降级的过程中解决数据库表构造（Schema）的版本控制？ 传统软件交付畛域，在 Schema 版本治理方面有两种支流的解决方案： 人工解决：这是最根底的 Schema 版本治理形式。现场交付人员不仅须要解决应用程序的降级流程，也间接操作数据库，实现 Schema 的降级。这种办法最间接，然而无奈自动化解决的流程都具备一些通病：低效、易错。代码解决：这是一种进阶的形式。通过在应用程序外部引入第三方库，来进行 Schema 的版本治理。这一操作曾经能够罢黜交付现场的人工解决流程，交付人员只须要将应用程序进行更新，程序自身会连贯到数据库，对 Schema 作出自动化的变更。这种形式的自动化水平曾经能够满足要求，然而也具备引入第三方库的通病：技术老本晋升、侵入性、与语言或框架绑定。云原生时代的解决思路云原生时代，应用程序的使用者、交付者都心愿通过所选用的平台来赋能本人的应用程序。在本文探讨的畛域中，这种期待能够具体的形容为：借助平台能力，以无侵入的形式，将 Schema 版本治理能力赋予利用，使得利用在进行一键降级时， Schema 也主动实现降级。 Rainbond 作为一款云原生利用治理平台，也在一直摸索为利用赋能之道。在 Schema 版本治理畛域，实现了在源码构建过程中集成 Schema 版本治理的能力。利用自身不须要改变任何代码，仅仅须要将两种类型的文件放进代码根目录下的指定目录下即可。这两种文件别离是：定义了数据库实例连贯地址的配置文件，降级 Schema 所应用的 Sql 脚本文件。 对于源码构建源码构建性能，自身就是一种 Rainbond 对利用的赋能。云原生时代，利用都在向容器化的方向迈进。容器化的过程中看似无奈罢黜 Dockerfile 的编写，实则不然。源码构建性能能够间接对接源代码，将其编译成为可运行的容器镜像。整个过程不须要开发人员的染指，提供代码仓库地址即可，极大的升高了开发人员的技术累赘。 在源码构建的流程中，以无侵入的形式集成了很多能力。比方通过纳入 Pinpoint-agent 的形式集成 APM 能力。再比方通过纳入 jmx-exporter 的形式集成自定义业务监控能力。明天重点形容的，是通过纳入 Liquibase 的形式，集成 Schema 版本控制能力。 对于LiquibaseLiquibase 是一款专门用于数据库表构造版本控制的 CI/CD 工具。从 2006 年开始，Liquibase 团队始终致力于让数据库变更治理更简略，尤其是在麻利软件开发畛域。这一工具基于 Apache 2.0 协定开源。 通过长期的迭代，Liquibase 曾经十分成熟牢靠，通过 sql、yaml、xml、json 在内的多种文件格式，开发人员能够疾速的定义出合乎 Liquibase 格调的数据库表构造变更文件，这种文件被称之为 changelog。基于 changelog 中的定义，Liquibase 能够十分不便的在多个变更操作版本之间降级与回滚。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。一、部署实例1.下载2个软件http://ftp.kaist.ac.kr/mysql/Downloads/MySQL-5.7/mysql-5.7.35-winx64.ziphttp://ftp.kaist.ac.kr/mysql/Downloads/MySQL-8.0/mysql-8.0.26-winx64.zip2.解压一下 3.初始化记录下明码C:\Users\Administrator>D:\test\mysql-5.7.35-winx64\bin\mysqld --initialize --console2022-01-20T03:37:59.769162Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).2022-01-20T03:38:03.808644Z 0 [Warning] InnoDB: New log files created, LSN=457902022-01-20T03:38:03.901775Z 0 [Warning] InnoDB: Creating foreign key constraint system tables.2022-01-20T03:38:04.079914Z 0 [Warning] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: 5fd0428e-79a2-11ec-b336-00155d9ebf27.2022-01-20T03:38:04.092275Z 0 [Warning] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened.2022-01-20T03:38:05.824394Z 0 [Warning] A deprecated TLS version TLSv1 is enabled. Please use TLSv1.2 or higher.2022-01-20T03:38:05.824844Z 0 [Warning] A deprecated TLS version TLSv1.1 is enabled. Please use TLSv1.2 or higher.2022-01-20T03:38:05.826505Z 0 [Warning] CA certificate ca.pem is self signed.2022-01-20T03:38:07.018691Z 1 [Note] A temporary password is generated for root@localhost: pE.Yu96:XQEp初始化数据如下图，默认是在安装程序的data目录上面 ...

存储引擎是解决不同表类型的SQL操作的MySQL组件。InnoDB是默认且最通用的存储引擎。（MySQL 8.0中的CREATE TABLE语句默认创立InnoDB表。）确定您的服务器反对哪些存储引擎，应用SHOW ENGINES语句。Support列中的值示意是否能够应用引擎。mysql> SHOW ENGINES\G*************************** 1. row *************************** Engine: PERFORMANCE_SCHEMA Support: YES Comment: Performance SchemaTransactions: NO XA: NO Savepoints: NO*************************** 2. row *************************** Engine: InnoDB Support: DEFAULT Comment: Supports transactions, row-level locking, and foreign keysTransactions: YES XA: YES Savepoints: YES*************************** 3. row *************************** Engine: MRG_MYISAM Support: YES Comment: Collection of identical MyISAM tablesTransactions: NO XA: NO Savepoints: NO*************************** 4. row *************************** Engine: BLACKHOLE Support: YES Comment: /dev/null storage engine (anything you write to it disappears)Transactions: NO XA: NO Savepoints: NO*************************** 5. row *************************** Engine: MyISAM Support: YES Comment: MyISAM storage engineTransactions: NO XA: NO Savepoints: NO...MySQL 8.0反对的存储引擎列表如下 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。[toc] 本文介绍如何利用GreatSQL 8.0.25构建一个三节点的MGR集群。 1. 装置筹备筹备好上面三台服务器： IP端口角色172.16.16.103306mgr1172.16.16.113306mgr2172.16.16.123306mgr3确保三个节点间的网络是能够互通的，并且没有针对3306和33061端口的防火墙拦挡规定。 下载GreatSQL二进制文件包，下载地址：https://gitee.com/GreatSQL/Gr... 。 本文以 CentOS x86_64 环境为例，下载的二进制包名为： GreatSQL-8.0.25-15-Linux-glibc2.28-x86_64.tar.xz，放在 /usr/local 目录下并解压缩： $ cd /usr/local$ tar xf GreatSQL-8.0.25-15-Linux-glibc2.28-x86_64.tar.xz$ cd GreatSQL-8.0.25-15-Linux-glibc2.28-x86_64$ lsbin COPYING-jemalloc include LICENSE LICENSE-test mysqlrouter-log-rotate README.router run support-filescmake docs lib LICENSE.router man README README-test share var2. 初始化MySQL Server首先筹备好 /etc/my.cnf 配置文件： #/etc/my.cnf[mysqld]user = mysqlbasedir=/usr/local/GreatSQL-8.0.25-15-Linux-glibc2.28-x86_64datadir=/data/GreatSQLport=3306server_id=103306log-binlog_slave_updates=1gtid_mode=ONenforce_gtid_consistency=ON本文仅以能失常启动MySQL Server和部署MGR为目标，所以这份配置文件极为简略，如果想要在正式场合应用，能够参考这份配置文件。 先初始化MySQL Server： $ mkdir -p /data/GreatSQL && chown -R mysql:mysql /data/GreatSQL$ /usr/local/GreatSQL-8.0.25-15-Linux-glibc2.28-x86_64/bin/mysqld --defaults-file=/etc/my.cnf --initialize-insecure留神：不要在生产环境中应用 --initialize-insecure 选项进行初始化装置，因为这么做的话，超级管理员root账号默认是空明码，任何人都能够应用该账号登录数据库，存在平安危险，本文中只是为了演示不便才这么做。 启动MySQL Server： $ /usr/local/GreatSQL-8.0.25-15-Linux-glibc2.28-x86_64/bin/mysqld --defaults-file=/etc/my.cnf &如果不出意外，则能失常启动MySQL Server。用同样的办法也实现对另外两个节点的初始化。 ...

#明码策略参数SHOW VARIABLES LIKE 'validate_password%';validate_password.policy（校验规定），取值范畴[0,1,2]，默认值1。0（LOW）：只校验长度；1（MEDIUM）：校验长度、大小写和特殊字符；2（STRONG）：校验长度、大小写、特殊字符和dictionary_file

什么是MySQL?MySQL 是一种关系型数据库，在Java企业级开发中十分罕用，因为 MySQL 是开源收费的，并且不便扩大。阿里巴巴数据库系统也大量用到了 MySQL，因而它的稳定性是有保障的。MySQL是凋谢源代码的，因而任何人都能够在 GPL(General Public License) 的许可下下载并依据个性化的须要对其进行批改。MySQL的默认端口号是3306。 MySQL数据库入门教程B站传送门：https://www.bilibili.com/video/BV1fx411X7BD 课程简介： 本套是MySQL数据库视频教程是能源节点教学总监杜老师讲述，其中具体解说了MySQL的相干常识，包含MySQL概述，MySQL应用环境，MySQL零碎个性，MySQL初学根底，MySQL管理工具，如何装置MySQL及MySQL新个性，通过观看本套Java视频教程就可把握MySQL全套常识。 事务相干什么是事务?事务是逻辑上的一组操作，要么都执行，要么都不执行。 事务最经典也常常被拿出来说例子就是转账了。如果小明要给小红转账1000元，这个转账会波及到两个要害操作就是：将小明的余额缩小1000元，将小红的余额减少1000元。万一在这两个操作之间忽然呈现谬误比方银行零碎解体，导致小明余额缩小而小红的余额没有减少，这样就不对了。事务就是保障这两个要害操作要么都胜利，要么都要失败。 事物的四大个性(ACID)介绍一下? 原子性： 事务是最小的执行单位，不容许宰割。事务的原子性确保动作要么全副实现，要么齐全不起作用；一致性： 执行事务前后，数据保持一致，多个事务对同一个数据读取的后果是雷同的；隔离性： 并发拜访数据库时，一个用户的事务不被其余事务所烦扰，各并发事务之间数据库是独立的；持久性： 一个事务被提交之后。它对数据库中数据的扭转是长久的，即便数据库产生故障也不应该对其有任何影响。 并发事务带来哪些问题?在典型的应用程序中，多个事务并发运行，常常会操作雷同的数据来实现各自的工作（多个用户对对立数据进行操作）。并发尽管是必须的，但可能会导致以下的问题。 脏读（Dirty read）: 当一个事务正在拜访数据并且对数据进行了批改，而这种批改还没有提交到数据库中，这时另外一个事务也拜访了这个数据，而后应用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是“脏数据”，根据“脏数据”所做的操作可能是不正确的。失落批改（Lost to modify）: 指在一个事务读取一个数据时，另外一个事务也拜访了该数据，那么在第一个事务中批改了这个数据后，第二个事务也批改了这个数据。这样第一个事务内的批改后果就被失落，因而称为失落批改。 例如：事务1读取某表中的数据A=20，事务2也读取A=20，事务1批改A=A-1，事务2也批改A=A-1，最终后果A=19，事务1的批改被失落。不可反复读（Unrepeatableread）: 指在一个事务内屡次读同一数据。在这个事务还没有完结时，另一个事务也拜访该数据。那么，在第一个事务中的两次读数据之间，因为第二个事务的批改导致第一个事务两次读取的数据可能不太一样。这就产生了在一个事务内两次读到的数据是不一样的状况，因而称为不可反复读。幻读（Phantom read）: 幻读与不可反复读相似。它产生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查问中，第一个事务（T1）就会发现多了一些本来不存在的记录，就如同产生了幻觉一样，所以称为幻读。 不可反复度和幻读区别：不可反复读的重点是批改，幻读的重点在于新增或者删除。 例1（同样的条件, 你读取过的数据, 再次读取进去发现值不一样了 ）：事务1中的A学生读取本人的工资为 1000的操作还没实现，事务2中的B学生就批改了A的工资为2000，导 致A再读本人的工资时工资变为 2000；这就是不可反复读。 例2（同样的条件, 第1次和第2次读出来的记录数不一样 ）：假某工资单表中工资大于3000的有4人，事务1读取了所有工资大于3000的人，共查到4条记录，这时事务2 又插入了一条工资大于3000的记录，事务1再次读取时查到的记录就变为了5条，这样就导致了幻读。 事务隔离级别有哪些?MySQL的默认隔离级别是?SQL 规范定义了四个隔离级别： READ-UNCOMMITTED(读取未提交)： 最低的隔离级别，容许读取尚未提交的数据变更，可能会导致脏读、幻读或不可反复读。READ-COMMITTED(读取已提交)： 容许读取并发事务曾经提交的数据，能够阻止脏读，然而幻读或不可反复读仍有可能产生。REPEATABLE-READ(可反复读)： 对同一字段的屡次读取后果都是统一的，除非数据是被自身事务本人所批改，能够阻止脏读和不可反复读，但幻读仍有可能产生。SERIALIZABLE(可串行化)： 最高的隔离级别，齐全遵从ACID的隔离级别。所有的事务顺次一一执行，这样事务之间就齐全不可能产生烦扰，也就是说，该级别能够避免脏读、不可反复读以及幻读。MySQL InnoDB 存储引擎的默认反对的隔离级别是 REPEATABLE-READ（可重读）。咱们能够通过SELECT @@tx_isolation;命令来查看 mysql> SELECT @@tx_isolation;@@tx_isolationREPEATABLE-READ这里须要留神的是：与 SQL 规范不同的中央在于InnoDB 存储引擎在 REPEATABLE-READ（可重读）事务隔离级别下应用的是Next-Key Lock 锁算法，因而能够防止幻读的产生，这与其余数据库系统(如 SQL Server)是不同的。所以说InnoDB 存储引擎的默认反对的隔离级别是 REPEATABLE-READ（可重读） 曾经能够齐全保障事务的隔离性要求，即达到了 SQL规范的SERIALIZABLE(可串行化)隔离级别。 ...

慢查、备份慢查 ： 记录没有索引的 SQL记录大于 1s 的所有 SQL慢查关联是基于实例的，会受到对应的所有慢查的邮件备份 ： 保留三天的全量（本地、近程、异地）增量（基于 binlog）慢查是为了解决什么问题 ？ 为了晋升用户体验，减少 SQL 的查问速度 互联网公司具体操作如下： 每天晚上去找到对应的慢查文件。对慢查文件进行剖析，比方 SQL 查问工夫过长等等。发对应的文件给开发，让其作出调整。比方 建设索引等等如何找到慢查的文件？ 次要有两种形式 ： 批改 MySQL 的配置文件 my.ini 定义其查问工夫，以及查问日志记录 # 查问工夫定义long_query_time = 10# 查问日志记录log-query-log = Onslow_query_log_file = "mysql_slow_query.log"# 记录没有应用索引的 querylog-query-not-using-indexes通过 MySQL 数据指令开启慢查问 set global slow_query_log = ON;set global long_query_time = 3600;set global log_querise_not_usng_indeses = ON;互联网公司什么时候备份 ？ 在甲方的话个别保留三天的全量备份，在本地、近程。 binlog 个别状况下不必备份，因为咱们数据库个别至多是一主一从这样的，不备份的话，问题也不会太大。

诚实说这部分相干的知识点早就曾经筹备好了，只是苦于不晓得该组织这些内容而已，昨晚想到了该如何组织这部分内容。 本系列的文章不加阐明，个别都是在InnoDB数据引擎探讨。 在开始看本篇文章之前，倡议先看: SQL查问模型和查疑补漏LeetCode刷题四部曲之SQL篇(一)MySQL优化学习手札(一)MySQL优化学习笔记手札(二)buffer pool 缓存池 的引入简介咱们在那里曾经唠叨过一条SQL由客户端发送给MySQL的服务端会产生些什么了，对此没有理解的，倡议翻一下《MySQL优化学习手札(一)》 到目前为止，从宏观上来看，SQL被发送给MySQL服务端之后，MySQL的存储引擎依据SQL从磁盘中提取进去对应的数据，但你晓得磁盘的速度绝对于的内存的速度是很慢的，即便是固态硬盘。如果每次提取数据都从磁盘中提取数据，那未免有点太慢了吧。对于InnoDB作为存储引擎的表, MySQL的开发者设计了缓存，来防止每次提取数据都从缓存池外面提取数据。InnoDB存储引擎在解决客户端的申请时，当须要拜访一个页的一条记录时, 就会把残缺的页的数据加载到内存中，也就是说即便咱们只须要拜访一个页的一条记录，那也须要把整个页的数据加载到内存中。将整个页加载到内存中后就能够进行读写访问了, 在进行读写访问之后并不焦急把该页对应的内存空间开释掉，而是将其缓存起来，这样未来有请申请再次拜访该页面时，就能够防止间接从磁盘中提取数据了。 为了缓存磁盘中的页，在MySQL服务器启动的时候就向操作系统申请了一片间断的内存，这片内存也就是buffer pool，通过 SHOW ENGINE INNODB STATUS;能够看到缓存池的根本状态: Buffer Pool中默认的缓存页大小和在磁盘上默认的页大小是一样的，都是16KB。每个缓存页都会有一些对应的管制信息，包含页号、缓存页在Buffer Pool中的地址等，每个缓存页对应的管制信息占用内存大小是雷同，咱们称管制信息所占用的 内存为管制块，管制块和缓存页是一一对应的，都位于缓存池中，管制块位于缓存页之前。像上面这样: 这个碎片是啥? 申请的内存空间在调配了管制块和缓存页，不够一个管制块和缓存页所需的内存空间呗，又假如管制块和缓存页所占用的内存一样，咱们极其假如一下缓存池只有57KB，只够凑一个管制块和缓存页，剩下25KB，这25KB就是内存碎片。 每个管制块大概占用缓存页大小的5%，在MySQL 5.7.21这个版本占用的大小是808字节。而咱们设置的innodb_buffer_pool_size并不蕴含这部分管制块占用的内存大小，也就是说InnoDB在Buffer Pool向操作系统申请间断的内存空间时，这片间断的内存空间个别会比innodb_buffer_pool_size的值大5%左右。Buffer Pool的大小能够通过MySQL的配置文件my.ini来指定，当初咱们来看一下我MySQL上面Buffer Pool的配置: InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes and row data. The bigger you set this the less disk I/O is needed to access data in tables. On a dedicated database server you may set this parameter up to 80% of the machine physical memory size. Do not set it too large, though, because competition of the physical memory may cause paging in the operating system. Note that on 32bit systems you might be limited to 2-3.5G of user level memory per process, so do not set it too high. ...

一、前言最近在线上遇到了因缓存和数据库数据不统一而引发的问题。经排查后，发现是因为咱们写操作采纳的策略是先写数据库，再删缓存。如果写操作后马上去读的话，因为缓存被删，会去数据库查数据。又因为数据库主从提早，会加载从库的旧数据到缓存。于是产生了数据库已被批改为新数据，但缓存仍然是旧数据的状况。 这次线上的事件，引申出了一个陈词滥调的话题，如何保障数据库与缓存一致性？明天咱们就来谈谈这个事。 二、不统一场景剖析1、 无并发时首先看一下最简略的状况。当一个写申请心愿把数据从D1改成D2。 因为咱们写申请须要进行两个操作：1、写数据库；2、更新/删除缓存。这两个操作并非是一个事务，所以必然有可能产生其中一个胜利一个失败的状况（个别是后一个，因为如果前一个操作失败，个别不会再做第二个操作）。这样会引申出以下两种状况。 先将DB数据由D1批改为D2再删除或更新缓存（该步骤产生异样，即失败了）最终，数据库数据是D2，缓存数据仍旧为D1。 先更新缓存数据由D1到D2更新数据库产生异样最终，数据库数据是D1，缓存数据已被批改为D2。2、 并发时接下来探讨更简单的状况，也就是在读写并发时可能产生的不统一。 首先明确的是，在读未命中缓存的时候，咱们的做法个别是去查数据库，而后把查到的值写入到缓存中。但在写数据时，策略往往不尽相同。咱们经常会思考两个问题。1）先操作缓存还是先操作数据库；2）删缓存还是更新缓存。 1）先DB后缓存1. 写数据库后更新缓存首先是未命中读+写操作并发的场景。线程A读缓存，未命中线程A读DB，失去Data1线程B写DB，将数据从Data1更新至Data2线程B写缓存，更新为Data2线程A写缓存，更新为之前读到的Data1最终，DB值为Data2，但缓存中值为Data1。其次是写操作并发的场景。线程A写DB，写入Data1线程B写DB，写入Data2线程A更新缓存，写入Data1线程B更新缓存，写入Data2最终，DB值为Data2，缓存值为Data1.2. 写数据库后删除缓存写数据库之后删除缓存，仿佛能够解决以上的问题，如下图所示。 但这不是万能的，就例如我在开篇提到的线上问题，采纳的正是写DB+删缓存策略。因为咱们我的项目读QPS十分大，但写QPS不高。故采纳了读写拆散的主从架构。写申请都在主库上进行，读申请则拜访从库，并依赖主从同步保证数据统一。因为主从同步须要工夫，就可能产生以下的状况导致DB与缓存数据不统一。 2）先缓存后DB1. 删缓存后写数据库 线程A写申请，先删缓存线程B读缓存，未命中线程B读DB，失去D1线程A写数据库，D1更新为D2线程B写缓存D1最终，DB的数据是D2，而缓存是D1。2. 更新缓存后写数据库 线程B读缓存，未命中线程A写申请，缓存由D1更新至D2线程B读DB，失去D1线程A写DB，有D1更新至D2线程B写缓存D1最终，DB的数据是D2，缓存的数据是D1。三、不统一的解决形式在缓存与数据库不统一之后，若过期工夫十分长，且期间没有写操作，会造成读的时候有很长一段时间数据是谬误的。那么如何去修改或者说尽量保障统一呢？ 1、提早双删顾名思义，提早双删就是在写完数据库之后，隔一小段时间\( \Delta(T) \)，再删一次缓存。当然第二次删缓存是异步进行的。 对以下两种状况，采纳提早双删策略后，都能保障在一段时间后，缓存中的脏数据被删除。也就是达到了最终一致性。但期间可能有申请读到的是脏数据。 这一小段时间\( \Delta(T) \)该怎么取值呢？首先晓得，\( \Delta(T) \)之后再删一次的目标是为了删除并发的未命中读产生的脏数据。所以个别要略大于一次读的申请，且略大于主从同步的提早。 2、删除缓存重试机制删缓存这一步可能会产生异样，为了保障删缓存胜利，能够引入重试机制。对于删缓存失败的操作，进入重试队列。重试队列选型能够是Kafka，也能够是Redis中的列表。对于一致性要求没那么高的，甚至能够在单机内存中寄存队列。 3、读取binlog校对缓存应用组件/中间件获取数据库的binlog。binlog若采纳Row模式，解析后个别会有数据行最新数据的信息。通过这个信息去查缓存，若发现不统一则删除缓存；若统一，则不作解决。 四、总结其实最终应用哪种策略去写数据，都要根据本人服务的个性来做取舍，并没有万能的策略（除非应用串行化或者做很多限度保证数据强统一，这时会升高零碎可用性）。 业界常常应用的Cache Aside策略，也就是对于写申请先更新数据库再删缓存的这种做法，在咱们的服务中会遇到不少问题。所以最终改成了先更新数据库再更新缓存。 对于线上的状况，能够尝试不同的策略，并在后盾做数据库与缓存的一致性统计，联合业务特点抉择最合适的计划。

前言为了MySQL8.0.28装置教程我居然在MySQL官网文档逛了一天，至此献给想入门MySQL8.0的初学者。以目前最新版本的MySQL8.0.28为示例进行装置与初步应用的具体解说，面向初学者的具体教程。无论是Windows还是Linux上装置，咱都会。这兴许是迄今为止全网最最最具体的MySQL8.0.28的装置与应用教程。 温故而知新，能够为师矣。咱缺的是学习的路径吗？答案并不是，而是不足学习的办法。官网文档是很具体的，而且是权威的，其它的那些书籍、博文啊都是基于官网文档以及本人的应用经验总结的。写这篇文章的用意，心愿大家能够总结本人的学习办法，长于利用官网文档来晋升本人。 倡议初学者多在命令行窗口下进行练习，游刃有余。达到肯定的熟练程度，再借助客户端工具进步咱们的工作效率。最终目标是啥？活下去呗，进步捞金能力。当然开个玩笑，回到正题，接着往下看。 从下载到装置，再到遗记明码解决方案。一步步应用命令行窗口学会基本操作，而后应用客户端近程连贯工具。最初配合时下比拟炽热的Java语言进行演示如何应用JDBC连贯最新的MySQL8.0数据库，以及执行查问返回后果。 注释咱也不多哔哔，间接上干货，要的就是实用性和性价比！ 一、MySQL8.0.28下载能够下载msi文件一键装置或者解压版zip文件进行命令行初始化装置。 MySQL官网下载地址 https://dev.mysql.com/downloads/mysql/ 1、Windows版本下载在Windows下能够抉择下载msi文件或者解压版zip文件。个别应用，抉择我应用紫色框线选中的即可。对于上面的Debug Test Suite，是带有许多的测试套件在外面，对于有测试需要的人员能够进行下载。 2、Linux版本下载依据本人须要的Linux发行版版本适配的MySQL进行抉择。比方，我集体抉择的是本人比拟相熟的Redhat7系列进行下载。同样有bundle版本，蕴含了一些插件和依赖在外面，便于应用rpm包装置。装置单个的server服务，须要装置其它的依赖包比拟繁琐。对于初学者，倡议间接下载RPM bundle版本。我偏不，就要折腾。那也行，请接着往下看，一样提供了具体装置步骤。 3、注意事项个别人能够能没认真看，官网会提醒登录，加了button按钮字体十分显眼，而上面的的我须要立刻下载则字体很小。所以留神了，抉择上面的No thanks，我须要立刻下载。抉择的是社区版本，收费提供下载。 二、MySQL8.0装置初学者尝鲜，倡议在Windows下装置。 个别状况，默认装置一个MySQL版本服务实例。也不排除估算无限，在同台服务器上安装多个实例进行测试。默认端口3306，如果在公布（生产）环境倡议批改默认端口，达到不让他人一下就猜到的目标。接下来装置测试多个MySQL服务版本共存一个操作系统下，只针对于Windows下装置多个服务（没有应用虚拟机工具，真机环境下测试）。Linux下有便捷的yum源以及apt形式装置，一键装置所需依赖，但也有比拟繁琐的rpm包装置。 1、Windows下装置配置环境变量，编辑零碎环境变量，控制面板>所有控制面板项>零碎>高级系统配置>零碎环境变量： #变量名MySQL_HOME#变量值D:\work\mysql-8.0.28-winx64\bin msi文件装置就不介绍了，傻瓜式的一键装置，留神抉择门路。 次要介绍解压版本zip的装置与实例化： mysql-8.0.28-winx64.zip1.1、解压下面筹备的安装包mysql-8.0.28-winx64.zip 在解压后的D:\work\mysql-8.0.28-winx64目下新增my.ini文件，默认解压版是没有的。而后退出如下配置： [client]# 设置mysql客户端默认字符集default-character-set=utf8 [mysqld]# 设置3307端口,有多个服务，为了不抵触批改默认的3306端口为3307port=3307# 设置mysql的装置目录basedir=D:\\work\\mysql-8.0.28-winx64# 设置 mysql数据库寄存目录datadir=D:\\work\\mysql-8.0.28-winx64\\data# 容许最大连接数max_connections=20# 服务端应用的字符集默认为8比特编码的latin1字符集character-set-server=utf8# 创立新表时将应用的默认存储引擎default-storage-engine=INNODB1.2、实例化 以管理员身份运行CMD命令窗口，切换到mysql解压后的目录下： -- 第一步执行d:，切换到D盘d:-- 第二步执行cd命令，切换到集体装置mysql的bin目录下cd D:\work\mysql-8.0.28-winx64\设置为空明码，去掉不必要的麻烦。 mysqld --initialize-insecure1.3、装置服务 进入到解压后MySQL的bin目录下，执行装置服务命令： cd D:\work\mysql-8.0.28-winx64\binmysqld installmysqld install --service -mysql8如果没有装置多个服务，应用mysqld install即可。能够不必指定服务名，默认的服务名为MySQL。 1.4、服务命令应用，须要管理员身份运行CMD命令，留神看我的门路是在bin目录下执行的 我没有配置MySQL8的零碎环境变量，所以都在MySQL的bin目录中执行命令。 启动服务net start mysql # 启动服务net start mysqlD:\work\mysql-8.0.28-winx64\bin>net start mysql8MySQL8 服务正在启动 .MySQL8 服务曾经启动胜利。进行服务net stop mysql # 进行服务net stop mysql D:\work\mysql-8.0.28-winx64\bin>net stop mysql8MySQL8 服务正在进行..MySQL8 服务已胜利进行。删除服务sc delete mysql ...

本篇翻译自David Carr博客，原文地址如下：https://daveismyname.blog/use...Sequel Pro是一个卓越的近程数据库治理端，当你数据库表内容时这里有个根本的搜寻过滤栏在表视图的顶部。 这个过滤栏很有用，当你只是检索一个字段时。然而如果你想过滤两个字段的话，则不能在这操作了。 在过来我都是通过写sql语句来实现查问过滤，但当初有个更加简便的形式能够实现。这个办法并不好找，你能够点击Table -> Advanced Filter Content弹出，一个更快的形式是应用shift + command + F.快捷键。

select city,name,age from t where city='杭州' order by name limit 1000;I-1全字段排序执行过程1、初始化sort_buffer，确定放入name、city、age这三个字段；2、从索引city找到第一个满足city='杭州’条件的主键id，也就是图中的ID_X；3、到主键id索引取出整行，取name、city、age三个字段的值，存入sort_buffer中；4、从索引city取下一个记录的主键id；5、反复步骤3、4直到city的值不满足查问条件为止，对应的主键id也就是图中的ID_Y；6、对sort_buffer中的数据依照字段name做疾速排序；7、依照排序后果取前1000行返回给客户端。 I-2全字段排序毛病：1、造成sort_buffer中寄存不下很多数据，因为除了排序字段还寄存其余字段，对sort_buffer的利用效率不高2、当所需排序数据量很大时，会有很多的临时文件，排序性能也会很差 I-3全字段排序长处：MySQL认为内存足够大时会优先选择全字段排序，因为这种形式比rowid 排序防止了一次回表操作 全字段排序相干知识点：MySQL会为每个线程调配一个内存（sort_buffer）用于排序该内存大小为sort_buffer_size：如果排序的数据量小于sort_buffer_size，排序将会在内存中实现；如果排序数据量很大，内存中无奈存下这么多数据，则会应用磁盘临时文件来辅助排序，也称内部排序；在应用内部排序时，MySQL会分成好几份独自的临时文件用来寄存排序后的数据，而后在将这些文件合并成一个大文件。II-1rowid排序执行过程1、初始化sort_buffer，确定放入两个字段，即name和id；2、从索引city找到第一个满足city='杭州’条件的主键id，也就是图中的ID_X；3、到主键id索引取出整行，取name、id这两个字段，存入sort_buffer中；4、从索引city取下一个记录的主键id；反复步骤3、4直到不满足city='杭州’条件为止，也就是图中的ID_Y；5、对sort_buffer中的数据依照字段name进行排序；遍历排序后果，取前1000行，并依照id的值回到原表中取出city、name和age 三个字段返回给客户端。 II-2rowid排序毛病：回表的操作是随机IO，会造成大量的随机读，不肯定就比全字段排序缩小对磁盘的拜访 II-3rowid排序长处：更好的利用内存的sort_buffer进行排序操作，尽量减少对磁盘的拜访 rowid排序相干知识点：mysql会通过遍历索引将满足条件的数据读取到sort_buffer，并且依照排序字段进行疾速排序如果查问的字段不蕴含在辅助索引中，须要依照辅助索引记录的主键返回汇集索引取出所需字段该形式会造成随机IO，在MySQL5.6提供了MRR的机制，会将辅助索引匹配记录的主键取出来在内存中进行排序，而后在回表依照状况建设联结索引来防止排序所带来的性能损耗，容许的状况下也能够建设笼罩索引来防止回表III-1联结索引排序：创立一个city和name的联结索引alter table t add index city_user(city, name);1、从索引 (city,name) 找到第一个满足city='杭州’条件的主键id；2、到主键id索引取出整行，取name、city、age三个字段的值，作为后果集的一部分间接返回；3、从索引 (city,name) 取下一个记录主键id；4、反复步骤2、3，直到查到第1000条记录，或者是不满足city='杭州’条件时循环完结。 III-2联结索引毛病：保护索引须要老本 III-3联结索引长处：查问过程不须要长期表，也不须要排序，性能优化很多。 IV-1笼罩索引排序：city、name和age的联结索引alter table t add index city_user_age(city, name, age);1、从索引 (city,name,age) 找到第一个满足city='杭州’条件的记录，取出其中的city、name和age这三个字段的值，作为后果集的一部分间接返回；2、从索引 (city,name,age) 取下一个记录，同样取出这三个字段的值，作为后果集的一部分间接返回；3、反复执行步骤2，直到查到第1000条记录，或者是不满足 city='杭州’条件时循环完结。 IV-2联结索引毛病：保护索引须要老本 IV-3联结索引长处：查问过程不须要长期表，也不须要排序，性能优化很多。 如何确定一个排序语句是否应用了临时文件：/* 关上optimizer_trace，只对本线程无效 */SET optimizer_trace='enabled=on'; /* @a保留Innodb_rows_read的初始值 */select VARIABLE_VALUE into @a from performance_schema.session_status where variable_name = 'Innodb_rows_read';/* 执行语句 */select city, name,age from t where city='杭州' order by name limit 1000; /* 查看 OPTIMIZER_TRACE 输入 */SELECT * FROM `information_schema`.`OPTIMIZER_TRACE`\G/* @b保留Innodb_rows_read的以后值 */select VARIABLE_VALUE into @b from performance_schema.session_status where variable_name = 'Innodb_rows_read';/* 计算Innodb_rows_read差值 */select @b-@a;

前言谁说MySQL查问千万级别的数据很拉跨？我明天就要好好的和你拉拉家常，畅谈到深夜，一起过元旦！这篇文章也是年前的最初一篇，心愿能带给大家些许播种，人不知;鬼不觉查找文档和参考实体书籍就写了这么多，本人都感觉到意外。不禁感叹到，晓得的越多，才晓得不晓得的更多。 开发人员或者是DBA都应该关注MySQL应用的存储引擎，抉择适合存储引擎对你的利用性能晋升是显著的。在浏览到本文的时候，必定是有肯定的MySQL或者其它数据库根底的，不然有些中央看着会很吃力。重点中央，我都进行了加粗解决，这样更容易获取要害知识点。 对于存储引擎，一篇文章也不可能八面玲珑，对集体感觉比拟重要、于工作无益的方面进行论述。如果真的去深挖，预计得一本书的篇幅。顺带还介绍一些数据类型抉择、字符集设置、索引的应用；视图、存储过程、函数以及触发器啊等等会在下一篇博文进行具体的形容。但本文不会做太具体的叙述。本篇文章以存储引擎的抉择为外围，如果有呈现瑕疵的中央，心愿您能留下贵重的倡议。 明天发现了一个神奇的参数：-site:xxxx.net 注释一、存储引擎的抉择（表类型）1、存储引擎的介绍与到少数关系型数据库的区别在于MySQL有一个存储引擎的概念，针对不同的存储需要能够抉择最合适的存储引擎。MySQL中的插件式的存储引擎是其一大特色，用户能够依据利用的需要抉择如何存储、是否索引，是否应用事务。嘿嘿，你也能够依据业务环境去适配最适宜本人业务的存储引擎。 Oracle从中嗅到了商机，收买了MySQL，从此有了企业版（商业反对）。社区版仍旧能够收费下载。另一大魅力也是因为开源，社区高度沉闷，人人都可奉献。接下来介绍几种应用比拟多的存储引擎，存储引擎并无优劣之分，有的只是谁更适宜对应的生产业务环境。 MySQL5.0中反对的存储引擎有FEDERATED、MRG_MYISAM、MyISAM、BLACKHOLE、CSV、MEMORY、ARCHIVE、NDB Cluster、BDB、EXAMPLE、InnoDB（MySQL5.5以及MariaDB10.2之后的默认存储引擎）、PERFORMANCE_SCHEMA（非常规存储数据引擎）。上面给出MySQL与MariaDB反对的存储器引擎的比照，能够看出MariaDB新增了Aria引擎： 查看存储引擎 通过MySQL登录自带的字符界面输出show engines\G;或者应用反对MySQL查问的工具SQLyog、phpMyAdmin、MySQL workbench等查问反对的引擎，这里只展现局部哟： [test@cnwangk ~]$ mysql -uroot -pEnter password: mysql> show engines\G;*************************** 2. row *************************** Engine: MRG_MYISAM Support: YES Comment: Collection of identical MyISAM tablesTransactions: NO XA: NO Savepoints: NO*************************** 3. row *************************** Engine: MyISAM Support: YES Comment: MyISAM storage engineTransactions: NO XA: NO Savepoints: NO*************************** 6. row *************************** Engine: MEMORY Support: YES Comment: Hash based, stored in memory, useful for temporary tablesTransactions: NO XA: NO Savepoints: NO*************************** 8. row *************************** Engine: InnoDB Support: DEFAULT Comment: Supports transactions, row-level locking, and foreign keysTransactions: YES XA: YES Savepoints: YES9 rows in set (0.00 sec)作用形容： ...

咱们都晓得，事务具备 ACID 四个个性——原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。但你晓得 MySQL 是通过什么技术手段来实现的吗？ ACID 简介先来简略回顾一下 ACID 的定义： 原子性：事务作为一个整体被执行，蕴含在其中的对数据库的操作要么全副被执行，要么都不执行。 一致性：事务开始前和事务完结后，数据库的完整性没有被毁坏。即写入的数据必须完全符合所有的预设束缚、触发器、级联回滚等。 隔离性：多个事务并发执行时，一个事务的执行不应影响其余事务的执行。 持久性：已被提交的事务对数据库的批改应该永恒保留在数据库中。即便零碎挂了，数据也不会丢。 咱们依照：持久性 -> 原子性 -> 隔离性 -> 一致性 的程序来探讨。 PS：本文基于 InnoDB 持久性咱们晓得程序修改数据的时候，是先将数据从磁盘加载到内存，而后批改完再由内存写回磁盘。长久化其实就是将内存里的数据写入磁盘。因而，持久性的要害就在于如何保证数据能够由内存顺利写入磁盘。 咱们有以下几个计划： 计划一： 加载数据到内存批改内存而后写回磁盘提交事务计划二： 加载数据到内存批改内存提交事务后盾写回磁盘第一种计划，靠谱是靠谱，但性能太低，会重大连累 MySQL 的吞吐量。 第二种计划尽管性能上来了，但如果在第四步时宕机了，而零碎认为事务已提交，这时候就会失落数据了。 那怎么办呢？MySQL 给出的计划是 WAL（Write Ahead Log）机制。WAL 翻译过去就是先写日志的意思。这个日志就是 redo log。具体做法是： 加载数据到内存批改内存写入 redo log提交事务后盾写回磁盘如果第五步时零碎宕机，也能够通过 redo log 来复原。 你可能有疑难：写入 redo log 不也有磁盘 I/O 吗？这不是脱了那啥再那啥，多此一举吗？写 redo log 和写表的区别就在于随机写和程序写。MySQL 的表数据是随机存储在磁盘中的，而 redo log 是一块固定大小的间断空间。而磁盘程序写入要比随机写入快几个数量级。 因而，这种计划即保障了数据的平安，性能上也可能承受。 原子性如果一个事务做了如下操作： 插入一条数据 insert into user values('1','小刘','18')更新一条数据 update user set name = '小水' where id = 2删除一条数据 delete from user where id = 3依据原子性的规定，这三个操作要么都胜利，要么都失败。那么问题就来了，如何保障 3 失败的状况下，让 1，2 也回退呢？ ...

本题应用的是 MySQL8.0，没有在 MySQL5.6 版本中测验过，不保障正确。 题目题目起源：性别变更 将所有数据 sex 的 f 和 m 对换，仅应用单个 update 语句，且不产生两头长期表 create table salary ( id int primary key, name varchar(255), sex varchar(255), salary int)insert into salary values(1, 'A', 'm', 2500),(2, 'B', 'f', 1500),(3, 'C', 'm', 5500),(4, 'D', 'f', 500);SQL：办法一update salary set sex = case sex when 'm' then 'f' else 'm' end;解析如果 sex = 'm' ， 那么就设置为 f ，否则设置为 m 。 应用 case sex when 'm' then 'f' else 'm' end 就能够实现 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。导语通过一段时间的筹备和整顿，万里数据库《零根底学习MySQL》课程正式在腾讯课堂上线了。课程地址：https://ke.qq.com/course/4333819明年还将推出《实战MySQL》课程，该课程面向高级MySQL DBA等有肯定MySQL根底的同学。课程介绍1. 适宜学习人员对MySQL零根底或者只有简略理解的同学均可加入本课程。在校学生，高中生，大学生等。对MySQL感兴趣的，想要转行的在职人员。刚踏入数据库行业的同仁。后端开发人员，全栈开发人员。财务，会计等业余人员。2. 课程劣势门槛低，零根底的群体也可学习。授课老师领有多年MySQL一线运维教训。行业专家大神坐镇领导。老师在线互动答疑，有专属答疑QQ群。学习优良并通过认证考核者，有机会免技术面试退出万里数据库。3. 学习后播种把握MySQL的根底语法，包含增删改查等。把握MySQL的触发器、存储过程、函数等。把握如何进行数据检索，过滤，分组等。理解数据库的事务个性，锁机制。理解数据库的索引设计。理解数据库的平安治理，包含服务器平安，利用平安。把握数据库的主从原理。把握数据库的常见故障案例及解决办法。4. 如何利用到生产中对开发人员，能够写出更高效的SQL语句。对学生，把握一门数据库技术，未来踏入职场更有竞争力。对财务人员，更轻松应答财销需要。对数据库同行，疾速进入MySQL数据库这个畛域。万里数据库介绍万里数据库成立于2000年，是国内晚期曾参加MySQL数据库外围代码开发的厂商，专一数据库畛域20年，以做中国优良的分布式数据库为指标。开源MySQL分支GreatSQL也是由万里数据库保护的，我的项目地址：https://gitee.com/GreatSQL/Gr...微信公众号GreatSQL社区续输入高质量技术分享干货文章，微信群和QQ群汇聚业内泛滥相干从业人员和DBA群体，欢送扫下方二维码退出。万里数据库出品的《实战MGR》、《深入浅出MGR》等收费课程也公布到bilibili平台，地址：https://space.bilibili.com/13... ，欢送关注。Enjoy GreatSQL :) 本文由博客一文多发平台 OpenWrite 公布！

云起实验室 夏季训练营（1.17-3.8）可补卡！！！五期夏季实战，从入门到进阶，以最佳实际帮忙开发者，疾速云上实际，云上学习。体验有礼，点击返回：https://developer.aliyun.com/adc/series/wintercamp夏季实战营第一期：从零到一上手玩转云服务器单期工作处分：实战营技能证书+定制鼠标三期工作处分：全网首发冬奥限量版云小宝五期工作处分：夏季实战营奖牌+定制书包+无影试用 体验简介本场景将提供一台配置了Alibaba Cloud Linux 2操作系统的ECS实例（云服务器）。通过本教程的操作，您能够在Alibaba Cloud Linux 2操作系统的ECS实例上装置、配置以及近程拜访MySQL数据库。 装置MySQLMySQL是一个关系型数据库管理系统，本步骤领导您如何在ECS实例上装置MySQL。 1、在实验室页面右侧，单击 图标，切换至Web Terminal。 2、执行如下命令，更新YUM源。 rpm -Uvh http://dev.mysql.com/get/mysql57-community-release-el7-9.noarch.rpm3、执行如下命令，装置MySQL。 yum -y install mysql-community-server --nogpgcheck4、执行如下命令，查看MySQL版本号。 mysql -V返回后果如下，示意您已胜利装置MySQL。 配置MySQL本步骤领导您如何配置MySQL。1）执行如下命令，启动MySQL服务。 systemctl start mysqld2）执行如下命令，设置MySQL服务开机自启动。 systemctl enable mysqld3）执行如下命令，查看/var/log/mysqld.log文件，获取root用户的初始密码。 阐明 ： 下一步对MySQL进行安全性配置时，会应用该初始密码。 grep 'temporary password' /var/log/mysqld.log返回后果如下所示，您能够查看到root用户的初始密码。 4）MySQL安全性配置。 执行如下命令，对MySQL进行安全性配置。 mysql_secure_installationb. 输出root用户的初始密码按下Enter键。 c. root用户的现有明码已过期，输出root用户的新密码并按下Enter键。 阐明 : 新密码长度为8至30个字符，必须同时蕴含大小写英文字母、数字和特殊符号。特殊符号能够是()` ~!@#$%^&*-+=|{}[]:;‘<>,.?/。 d. 再次输出root用户的新密码并按下Enter键。 e. 输出N并按下Enter键，不更改root用户明码。 f. 输出Y按下Enter键，删除匿名用户。 g. 输出Y按下Enter键，禁止root账号近程登录。 h. 输出Y按下Enter键，删除test库以及对test库的拜访权限。 i. 输出Y按下Enter键，从新加载受权表。 近程拜访MySQL数据库您能够应用数据库客户端或阿里云提供的数据管理服务DMS（Data Management Service）来近程拜访MySQL数据库。本步骤领导您创立新的MySQL用户，通过DMS近程拜访MySQL数据库。 1、在ECS实例上，创立近程登录MySQL的账号。 a. 执行如下命令，应用root用户登录数据库。 ...

环境：windows2008 r2；mysql5.6单实例，引擎类型为innodb，表内数据存储所应用表空间类型为独立表空间；未进行数据库备份，未开启binlog。 故障：因为人为误操作应用Delete命令删除数据时未增加where子句进行筛选，导致全表数据被删除，删除后未对该表进行任何操作。 本案例MySQL数据库数据恢复剖析：1、故障类型：因为未对生产环境进行备份也未开启binlog日志，无奈间接还原数据库，属于典型的表内mysql delete数据误删除。2、故障剖析与可行性计划制订：对于mysql innodb误删除导致记录失落的复原计划有三种：备份还原、binlog还原和记录深度解析。对于本案例前两种计划不实用，只能应用记录深度解析的形式进行复原。此复原计划的原理为模仿innodb引擎记录治理形式，依据表构造信息将二进制文件解析为字符记录。 本案例MySQL数据库数据恢复过程：1、获取数据文件：管理员将表构造文件及表数据文件（.ibd）发送给北亚数据恢复工程师。2、应用北亚数据恢复核心自研的数据恢复工具进行复原： 在本案例中数据库管理员提供了表构造脚本，能够应用本工具中的5+3性能进行复原。首先读取表构造信息： 开始解析记录： 本工具默认将记录提取为SQL备份格局，期待解析结束后还原到数据库查看后果（为保障客户隐衷要害信息已打码）： 验收数据：随机筛选表内数据交由管理员验证，并统计复原记录总数。通过验证后数据正确，总数合乎原表内记录条数。

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。1. 传统主从复制技术架构传统主从复制的形式是在master节点上执行数据更新事务，而后记录这些事务到binlog中，再将binlog发送到slave节点转储成relay log，在slave节点上再有独自的线程读取这些relay log而后从新执行或利用这些事务，它是shared-nothing的，每个节点都有一份残缺的数据正本，其技术流程图如下所示： 传统主从复制技术架构图MySQL还提供了半同步复制，这是在传统主从复制的根底上减少了一个同步的步骤，master节点上提交事务前，要先等到slave节点确认收到事务信息才能够（所以前文才说当slave节点响应慢时会影响master节点的事务提交），其技术流程图如下所示： 半同步复制技术架构图2. MGR组复制技术架构MGR也是shared-nothing的，每个节点都有一份残缺的数据正本，节点间通过GCS（Group Communication System）进行交互。GCS层提供了节点间的全局音讯及其有序性的保障。 MGR能够做到在任何节点、任何工夫都能执行读写事务（不含只读事务），不过读写事务要被整个复制组确认后能力提交。如果是只读事务则没有这个限度，任何节点都能够发动及提交。 当读写事务筹备提交前，它会向复制组收回一个原子播送，内容包含：该事务批改的数据，及其所对应的writeset。复制组中所有节点要么接管该事务，要么都不接管。如果组中所有节点都接管该事务音讯，那么它们都会依照与之前发送事务的雷同程序收到该播送音讯。因而，所有组成员都以雷同的程序接管事务的写集，并为事务建设全局程序。 在多个节点上并行执行的事务是可能产生抵触的，这时候就须要比照判断两个并行事务的writeset来确认，这个过程称为事务认证，也叫做冲突检测。事务冲突检测是行级别的，也就是说两个并行的事务更新同一行时，则视为产生抵触。这时的做法是全局程序在后面的事务能够胜利，所有节点都提交该事务。而全局程序在前面的事务会失败回滚，各节点会删除该事务。这实际上是个分布式的谁先提交谁先博得事务的规定。倡议：如果常常产生节点间的事务抵触，那最好将这些事务放在同一个节点上执行，这样它们在本地事务并发管制协调下可能都能够提交胜利，而不至于因为MGR的冲突检测而导致某个事务总是被回滚。 对于正在利用或外化的事务，MGR容许它们不肯定依照原有程序执行，只有不毁坏事务的一致性和有效性即可。MGR默认要求是最终一致性，也就是说当所有事务都利用结束后，所有节点的数据是统一的。当流量微小时，事务可能会被外化而导致程序轻微不统一。例如在多主模式下，一个本地事务在通过认证后会被立刻外化，只管此时可能还有个有这更早全局程序的近程事务还没被利用，只有MGR的认证线程认为这个事务不会产生抵触即可。在单主模式下，在Primary节点上的本地并发事务，在不产生抵触的状况下，其提交和外化的程序可能和该事物的全局事务程序有轻微不统一。在Secondary节点上，因为没有写事务，因而它们的事务程序和全局事务程序是统一的。 下图形容了MGR的组复制协定，能够看到和传统主从复制（及半同步复制）的一些差别。为了简略起见，图中少了共识算法和Paxos相干的信息： MGR技术架构图 3. MGR的单主和多主模式MGR反对单主或多主两种模式。 在启动时，通过设置选项 group_replication_single_primary_mode 来决定应用哪种模式，各节点中该值的设置要求统一。设置为 ON 时示意采纳 单主模式，当设置为 OFF 时示意采纳 多主模式。 在运行过程中，不能在线批改 group_replication_single_primary_mode 的值，然而从MySQL 8.0.13开始，能够通过调用 group_replication_switch_to_single_primary_mode() 和 group_replication_switch_to_multi_primary_mode() 这两个udf在线批改运行模式，或者通过MySQL Shell批改。 在 单主模式 下，有且只有一个（Primary）节点能够写入数据，其余（Secondary）节点都只能读数据。而在 多主模式 下，能够在任意节点上同时读写数据。 MGR最多只能反对9个节点，无论单主还是多主模式。 4. 节点治理MGR由一组节点形成，每个节点都有惟一的名字，以 UUID 的格局体现。节点能够动静退出或来到（也可能是被动被驱赶）MGR。 MGR的组成员服务用于保护定义各沉闷节点的信息，这些沉闷节点信息也称之为组视图（view）。各节点的组视图是统一的，这示意在给定时刻组中有哪些沉闷成员。 MGR各节点除了在事务提交时要保持一致外，也包含组视图发生变化时也要达成统一。当有新节点退出，或现有节点来到时，都会触发新的组视图变更。 当有节点被动来到集群时，它会触发集群主动重配置，剩下的节点会就新的组视图达成统一。但若节点是因为网络异样或宕机等起因意外来到集群时，则无奈触发主动重配置，这时候集群故障检测机制会在该节点来到一段时间后辨认到这个状态，并收回重配置组视图的提议。重配置组视图须要失去多数派成员的批准才行，当无奈造成统一时，就无奈实现主动重配置，须要人工染指解决。无奈造成一致意见可能的起因有，剩下的节点数没达到总结点数的一半以上，也就是无奈造成多数派。 在节点被确认故障之前，或在重新配置组以删除该故障节点前，容许该节点短暂离线，而后尝试重新加入集群。在这种状况下，该节点可能会失落它以前的状态（事务数据），如果此时其余节点向它发送了蕴含解体前的音讯，则这就可能会导致数据不统一等问题。 为了解决这个问题，从MySQL 5.7.22开始，MGR会查看具备雷同地址+端口的节点再次以新身份退出集群的状况，确认以后是否还有其旧身份存在。这时候其新身份不能退出，直到旧身份能从集群中删掉。留神：，选项 group_replication_member_expel_timeout 的作用是设置一个期待期，使得节点在被正式驱赶前有更多工夫尝试从新加回集群，也就是说处于被狐疑状态的节点，在超时之前还可尝试重新加入集群，再次作为沉闷节点。当节点超过 group_replication_member_expel_timeout 阈值并被从集群中驱赶时，或节点执行 STOP GROUP_REPLICATION 退出集群，或因节点宕机等状况下，该节点必须以新身份重新加入集群。 5. 故障检测MGR自带故障检测机制，它能发现并报告哪个节点处于静默状态，达到肯定条件后会认为这个节点已死。它是个分布式的故障检测服务，提供了哪个节点处于（被狐疑）已死状态的信息。 当一个节点静默（不被动发信息，也不回复其余节点的信息）时，可能会触发被狐疑。当节点A在给定工夫内还没有收到节点B的音讯时，则产生音讯超时并引发狐疑。在这之后，集群内其余成员如果一致同意（多数派达成统一）对该节点的狐疑是确定的话，则会断定该节点产生了故障。 如果某个节点因为网络故障和其余节点断开连接了，那么它可能也会狐疑其余节点产生了故障。但因为它不能造成多数派决定，因而这个狐疑是有效的，此时该节点无奈执行任何读写事务，最多只能执行只读事务。 当网络不稳固时，随便两个节点间可能频繁断开和重连，实践上说可能会导致所有节点都会标记为驱赶，集群会退出并须要重建。为了防止这种状况，从MySQL 8.0.20开始，GCS会跟踪标记为驱赶的节点，并决定某个可疑节点是否还留在多数派节点中，这使得集群中至多有一个节点而不会退出。当被驱赶节点正式被从集群中移出时，GCS会删掉起被标记为驱赶的记录，使得它前面还能从新加回。 6.容错机制MGR是基于分布式的Paxos算法实现，因而要求有多数派节点存活以保障投票。这就决定了在不影响零碎整体可用性前提下，可容忍产生故障的节点数量。假如总节点数是n，可容忍产生故障的节点数是f，则它们的关系是：n = 2*f + 1。简言之，容忍产生故障的节点数，不高于总节点数的一半。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。1. 为什么是MGRMGR是MySQL Group Replication的缩写，即MySQL组复制。 在以往，咱们个别是利用MySQL的主从复制或半同步复制来提供高可用解决方案，但这存在以下几个比较严重的问题： 主从复制间容易产生复制提早，尤其是在5.6以前的版本，以及当数据库实例中存在没有显式主键表时，很容易产生。主从复制节点间的数据一致性无奈自行实现最终一致性。当主节点产生故障时，如果有多个从节点，无奈主动从中抉择适合的节点作为新的主节点。如果采纳（加强）半同步复制，那么当有个从节点因为负载较高、网络提早或其余意外因素使得事务无奈及时确认时，也会反过来影响主节点的事务提交。因为上述几个显著的毛病，因而MySQL推出了全新的高可用解决方案 -- 组复制，这是本系列文章要着重介绍的新个性。 MGR是MySQL 5.7.17开始引入的，但随着5.7版本逐步退出历史舞台（MySQL 5.7已于2020年10月起不再做大的性能更新，只有修修补补以及针对安全更新），更多MGR相干个性都只在MySQL 8.0上才有。 因而，如果线上还有基于MySQL 5.7版本的MGR环境的话，倡议尽快降级、迁徙到MySQL 8.0版本。进一步揭示，举荐MySQL 8.0.22及之后的版本，整体会更稳固牢靠，也有些很不错的新性能（不只是MGR方面的）。 2. MGR技术概要MGR具备以下几个特点： 基于shared-nothing模式，所有节点都有一份残缺数据，产生故障时能够间接切换。MGR提供了数据一致性保障，默认是最终一致性，可依据业务特色须要自行调整一致性级别。反对在线增加、删除节点，节点治理更不便。反对故障自动检测及主动切换，产生故障时能主动切换到新的主节点，再配合MySQL Router中间件，应用层无需干涉或调整。反对单节点、多节点写入两种模式，可依据架构或业务须要抉择哪种计划，不过强烈建议选用单主模式。MGR能够抉择单主（Single-Primary）模式 如上图所示，一开始S1节点是Primary角色，提供读写服务。当它产生故障时，剩下的S2-S5节点会再投票选举出S2作为新的Primary角色提供读写服务，而S1节点再达到肯定超时阈值后，就会被踢出。 亦可抉择多主（Multi-Primary）模式（再次强烈建议选用单主模式） 如上图所示，一开始S1-S5所有节点都是Primary角色，都能够提供读写服务，任何一个节点产生故障时，只须要把指向这个节点的流量切换下就行。 上述两种架构模式下，利用端通过MySQL Router连贯后端在MGR服务，当后端节点产生切换时，Router会主动感知，对利用端来说简直是通明的，影响很小，架构上也更灵便。 3. MGR技术架构首先来个MGR的技术架构图： MGR是以Plugin形式嵌入MySQL，部署更灵便不便。 事务从Server层通过钩子（hook）进入MGR API接口层，再散发到各组件层，在组件层实现事务Capture/Apply/Recover，通过复制协定层（Replication Protocol Logics）传输事务，最初经由GCS协调事务在各节点的最终一致性。 MGR节点间由组通信零碎（GCS）提供反对，它提供了故障检测机制、组成员角色治理，以及平安且有序的消息传递，这些机制可确保在各节点间统一地复制数据。这项技术的外围是Paxos算法的实现，在MySQL里称之为XCom，由它充当MGR的通信引擎。 对于要提交的事务，组中的多数派节点必须就全局事务序列中给定的事务程序达成统一。各节点做出决定提交或停止事务的抉择，但所有节点都要做出雷同的决定。如果产生网络分区，导致节点间无奈达成统一决定，则在网络复原前，MGR无奈工作。 MGR反对单主和多主两种模式，在单主模式下，各节点会主动选定主节点，只有该主节点能同时读写，而其余（从）节点只能只读。在多主模式下，所有节点都能够进行读写。 绝对于MariaDB Galera Cluster（以及基于此技术的Percona XtraDB Cluster，上面为了书写不便，都统称为PXC），集体认为MGR具备以下几个劣势： PXC的音讯播送机制是在节点间循环的，须要所有节点都确认音讯，因而只有有一个节点故障，则会导致整个PXC都产生故障。而MGR则是多数派投票模式，个别少数派节点故障时，个别不影响整体的可用性。这也是PXC存在的最大问题。PXC的节点间数据传输除了binlog，还有个gcache，这相当于是给MySQL又减少两个黑盒子。而MGR则都是基于原生binlog的，没有新增黑盒子，运行起来更牢靠，须要排障时也更不便。产生网络分区时，整个PXC集群都不可用。而MGR则至多还能提供只读服务。PXC的流控机制影响更大，一旦触发流控，所有节点都受到影响。而MGR触发流控后，只会影响本地节点，不影响近程节点。当然了，MySQL的流控做的也比拟毛糙，在GreatSQL中进一步欠缺和优化。执行DDL期间，整个PXC集群都不可同时执行DML，也就是说不反对Online DDL。而MGR是反对的，这也是很大的劣势。绝对于传统主从复制（Replication），我认为MGR的劣势有以下几点： 主从复制非常容易产生复制提早，尤其是当表中没有显式主键时。而在MGR里，要求表肯定要有主键（或是可用作汇集索引的非空惟一索引），防止了这个问题。半同步复制中，一旦slave因为锁或其余起因响应慢的话，也会导致master事务被阻塞。MGR是采纳多数派确认机制，个别节点响应慢对Primary节点的影响没那么大（不要选用AFTER模式）。主从复制没有相似MGR那样提供事务数据的一致性保障。MGR自带了事务数据一致性保障机制。以上是我依据MySQL、MariaDB、Percona的材料整顿失去的观点，不肯定精确和全面，有不欠缺的中央还请留言斧正。 4. 小结本节次要介绍了什么是MGR，MGR的技术架构概要，以及MGR绝对PXC的几个技术劣势。 MGR是MySQL四部策略走的要害一环，依附MGR和MySQL Shell、MySQL Router已实现了读节点扩大，以及写节点扩大（MGR多主模式），下一步预计实现sharding，让咱们刮目相待。 置信MGR也是MySQL将来几年的重头戏，倡议跟紧方向，不要错过这班列车。 参考资料、文档MySQL 8.0 Reference Manual数据库内核开发 - 温正湖Group Replication原理 - 宋利兵免责申明因集体程度无限，专栏中不免存在错漏之处，请勿间接复制文档中的命令、办法间接利用于线上生产环境。请读者们务必先充沛了解并在测试环境验证通过前方可正式施行，防止造成生产环境的毁坏或侵害。 Enjoy GreatSQL :) 文章举荐：GreatSQL季报（2021.12.26） https://mp.weixin.qq.com/s/FZ... 技术分享|sysbench 压测工具用法浅析 https://mp.weixin.qq.com/s/m1... 故障剖析 | linux 磁盘io利用率高，剖析的正确姿态 https://mp.weixin.qq.com/s/7c... ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 咱们时常会遇到的场景： 用银行卡在 ATM 机取款、在 APP 上转账、网购付款等等环节，因明码间断输错肯定的次数，银行卡即被锁定而无奈应用，除非拿着有效证件去银行柜台人工解锁才可失常应用。 随着MySQL 数据库被越来越多的金融场景应用，相似间断输错银行卡明码而导致的锁卡性能跃然纸上。MySQL 从 8.0.19 开始，就推出了相似策略：Failed-Login Tracking and Temporary Account Locking 。 翻译过去就是 失败登录追踪和长期明码锁定，前面咱们简称为：FLTTAL 。 和之前几个明码策略不同，FLTTAL 没有全局参数匹配，只能在创立用户或者是更改用户属性时被匹配。 有两个选项： FLTTAL 有以下几个须要留神的点：failed_login_attempts 和 password_lock_time 必须同时不为 0 ，FLTTAL 能力失效。创立新用户不指定 failed_login_attempts 和 password_lock_time ，则默认敞开 FLTTAL 。已应用FLTTAL的用户，管理员对其 alter user 后不扭转原有明码验证策略。一旦账户被锁定，即便输出正确明码也无奈登录。还有最重要的一点：因为 FLTTAL 对明码验证正确与否的连续性，任意一次胜利登录，FLTTAL 计数器重置。例如 failed_login_attempts 设置为 3 ，前两次明码间断输错，第三次输出正确的明码，FLTTAL 计数器重置。那接下来咱们来看下如何具体应用这个明码验证策略：对于普通用户的应用办法：管理员创立用户 test1@'localhost' ，并且设置 FLTTAL 策略：失败重试次数为 3 ，明码锁定工夫为 3 天。 mysql:(none)>create user test1@'localhost' identified by 'test' failed_login_attempts 3 password_lock_time 3; Query OK, 0 rows affected (0.14 sec)明码间断输错 3 次，test1@'localhost' 账号被锁定： ...

从零开始学Mysql - 字符集和编码（下）引言 这个系列的文章是依据《MySQL是怎么运行的：从根儿上了解MySQL》这本书的集体笔记总结专栏，这里非常举荐大家精读一下这本书，也是目前市面上集体所知的讲述Mysql原理的为数不多的好书之一，好了废话不多说咱们上面进入正题。 上篇：从零开始学Mysql - 字符集和编码（上） 因为这个系列波及的知识点还是挺多的，这里先依据文章的知识点汇总了一份集体思维导图：幕布地址 回顾上篇 因为上一篇和本篇编写的间隔时间比拟久，这里咱们先来回顾一下上一篇讲了什么内容： 在Mysql数据中，字符串的大小比拟实质上是通过上面两种形式进行比拟，简而言之字符串的大小比拟是依赖字符集和比拟规定来进行比拟的。 将字符对立转为大写或者小写再进行二进制的比拟或者大小写进行不同大小的编码规定编码简述和把握几个比拟罕用的字符集： ASCII 字符集：收录128个字符，ISO 8859-1 字符集：在ASCII 字符集根底上进行扩大，共256个字符，字符集叫做latin1，也是Mysql5.7之前默认的字符集（Mysql8.0之后默认字符集为utf8mb4）GB2312：首先须要留神的是不仅仅只有“汉字”哦，比拟非凡的是采纳了变长编码规定，变长编码规定值得是依据字符串的内容进行不同的字符集进行编码，比方'啊A'中‘啊’应用两个字节编码，'A'因为能够应用ASCII 字符集示意所以能够只应用一个字节进行编码GBK 字符集：对于GB2312进行字符集的扩大，其余和GB2312编码规定统一UTF8字符集：UTF-8规定依照1-4个字节的变长编码方式进行编码，最初UTF8和gbk一样也兼容了ASCII的字符集提醒：这里有一个思考题目那就UTF-8mb3和UTF8-mb4的字符集有什么区别？这里也暗藏了一个历史遗留问题带来的坑，如果次要应用Mysql数据库这个坑有必要认真理解一下，在上篇的文章最初给出答案，这里不再赘述。查看字符集命令：show charset;，比方：show charset like 'big%';比拟规定查看：show collation [like 匹配模式]，比方show collation like 'utf_%';字符集和比拟规定的级别分为四种： 服务器级别：能够通过配置文件进行设置，然而启动之后无奈批改服务器级别的字符集或者比拟规定。数据库级别：如果没有指定数据库级别比拟规定或者字符集，则默认应用服务器的。表级别：表级别在默认的状况下应用数据库级别的字符集和比拟规定。列级别：列级别规定应用比拟少，通常在建表的时候指定，然而通常不倡议同一个表应用不同字符集的列。最初，咱们回顾一下字符集和比拟规定的常见命令。数据库级别查看字符集查看比拟规定零碎变量批改/创立形式案例服务器级别show variables like 'character_set_server';SHOW VARIABLES LIKE 'collation_server'character_set_server：以后服务器比拟规定collation_server：以后服务器比拟规定批改配置文件[server] character_set_server=gbkcollation_server=gbk_chinese_ciCREATE DATABASE charset_demo_db CHARACTER SET gb2312 COLLATE gb2312_chinese_ci;数据库级别show variables like 'character_set_database';show variables LIKE 'collation_database';character_set_database：以后数据库字符集 Collation_database：以后数据库比拟规定alter database 数据库名 [[DEFAULT] CHARACTER SET 字符集名称] [[DEFAULT] COLLATE 比拟规定名称];CREATE DATABASE charset_demo_db CHARACTER SET gb2312 COLLATE gb2312_chinese_ci;表级别show table status from '数据库名称' like '数据表名称'SELECT TABLE_SCHEMA, TABLE_NAME,TABLE_COLLATION FROM INFORMATION_SCHEMA.TABLES where TABLE_NAME = '数据表名称'未设置状况下默认参考数据库的级别设置CREATE TABLE 表名 (列的信息)[[DEFAULT] CHARACTER SET 字符集名称] [COLLATE 比拟规定名称]]ALTER TABLE 表名[[DEFAULT] CHARACTER SET 字符集名称] [COLLATE 比拟规定名称]create table test( id int auto_increment primary key) character set utf8mb4 COLLATE utf8mb4_0900_ai_ci列级别show full columns from admin like 'username';show full columns from admin like 'username';未设置状况下默认参考数据表的级别设置CREATE TABLE 表名( 列名 字符串类型 [CHARACTER SET 字符集名称] [COLLATE 比拟规定名称], 其余列...);ALTER TABLE t MODIFY col VARCHAR(10) CHARACTER SET gbk COLLATE gbk_chinese_ci; 文章目标 在介绍注释之前，这里先提前总结本文的次要内容。 ...

作者：莫善 某互联网公司高级 DBA。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 需要介绍业务有两个 MySQL 集群是通过 MQ 进行同步的，昨晚 MQ 出现异常，报了很多主键抵触，想请 dba 帮忙校验一下两个集群的数据是否统一。 一、前言当接到这个需要的时候并没当回事，隐约有点印象 pt-table-checksum 能通过 dsn 实现 MySQL 的数据校验，所以过后就应承下来了。未曾想，啪啪打脸，回想起来真是粗率了。 本文参考的是 pt-table-checksum 的校验逻辑，基于数据块去遍历每个表，而后比对 checksum 的值判断该块是否统一，本文次要是想聊聊我在实现数据校验脚本过程中遇到的问题以及解决思路，心愿对大家有帮忙。 二、测试 dsn利用线上的配置文件搭建一套主从环境。 搭建步骤略本例应用 mysql 5.7.26 进行测试本例应用 percona-toolkit-3.2.1 进行测试1、校验主从数据一致性这个用例将通过 dsn 形式连贯从库。 配置 dsn 过程略$ ./bin/pt-table-checksum h='192.168.1.1',u='mydba',p='test123456',P=6666 --nocheck-replication-filters --replicate=test.checksums --no-check-binlog-format -d dbatest1 --recursion-method dsn=t=percona_schema.dsnsChecking if all tables can be checksummed ...Starting checksum ... TS ERRORS DIFFS ROWS DIFF_ROWS CHUNKS SKIPPED TIME TABLE01-13T17:48:20 0 0 0 0 1 0 0.377 dbatest1.dbatest能够看到测试通过，能失常做校验。2、校验非主从数据一致性这个用例将通过 dsn 形式连贯从库，然而会将从库的复制链路 stop 掉，并清空复制信息。 ...

云服务器具备上面这些劣势，采纳云服务器计划的用户群体越来越大。 一、应用云服务器不须要购买硬件设施，不须要专门的机房托管这些服务器，只须要依照所需的资源领取肯定的费用就能租用须要的资源。数据中心不仅提供硬件环境和系统软件资源，还提供咨询服务，将各种硬件和系统软件资源在治理后盾进行图形化展现，不便操作，无需业余的技术去配置服务器、数据库等这些业余简单操作。 二、绿色环保，缩小硬件设施的购买和折旧、淘汰老本。 三，云服务器供应商提供业余技术人员对服务器进行保护，节约了设施的运行保护、服务的搭建配置等老本，企业能够将更多资源投入到本身的业务中。 北亚数据恢复核心遇到越来越多云服务器的数据恢复问题。在这分享一个云服务器的数据恢复案例。 环境： 某云ECS网站服务器， linux操作系统， mysql数据库版本号5.6。 故障： 在执行数据库版本更新测试时，将本应在测试库中执行的sql脚本放到生产库中去执行，导致局部表被truncate，另有局部表内大量数据被delete。该实例内数据表均采纳innodb作为默认存储引擎。 云服务器数据恢复流程： 1.因为ECS内有其余业务仍在运行，为保障被truncate表底层数据不被毁坏，北亚数据恢复工程师先对mysql的data目录所在分区进行备份。 2.因为须要复原的12个表内不存在大字段类型值和myisam引擎表，为节约数据传输工夫，扫描数据段后，北亚数据恢复工程师下载获取数据复原所必须的数据库段碎片。因为innodb引擎数据恢复必须依赖表构造信息，mysql的表构造信息存储于对应表名的.frm文件内。在本复原案例中frm文件完整，可间接应用。下载须要复原的表对应的.frm文件。 3.北亚数据恢复工程师剖析零碎表。读取数据段内零碎表信息，获取须要复原的12个表在零碎表内的注册信息。 4.复原被truncate的表。北亚数据恢复工程师在下载实现的数据段文件内提取对应于各表的数据页，解析对应表的.frm文件，获取到该表的表构造信息。通过表构造信息获取到底层数据调配规定后，依照规定拆分数据段内的二进制数据，并对不同类型的数据进行字符展现转换（各类整形、浮点型、工夫型等），实现数据段到sql语句的转换。 5.复原被delete数据的表，根本流程同truncate表的复原相似，不同点在于数据解析时须要提取被标注为“delete”的记录。 6.数据还原。北亚数据恢复工程师依据解析出的表构造信息在数据恢复环境中的mysql实例内创立表，并将复原出的数据导入。 7.数据前期解决。因为间接从底层抓取出的记录可能存在主键不惟一（引擎在存储时产生的长期记录）和记录反复（缓冲段）以及乱码（扫描数据段时呈现特征值匹配胜利但不属于该表的数据段）等状况，北亚数据恢复工程师解决提取出存在异样的记录。 数据验证： 开启远程桌面，由管理员进行数据验证，查看复原进去的数据是否正确、数据量是否失常。通过验证，truncate表复原残缺可用，delete记录的表复原残缺可用。

AACCESSIBLE (R)ACCOUNTACTIONACTIVE; added in 8.0.14 (nonreserved)ADD (R)ADMIN; became nonreserved in 8.0.12AFTERAGAINSTAGGREGATEALGORITHMALL (R)ALTER (R)ALWAYSANALYSE; removed in 8.0.1ANALYZE (R)AND (R)ANYARRAY; added in 8.0.17 (reserved); became nonreserved in 8.0.19AS (R)ASC (R)ASCIIASENSITIVE (R)ATATTRIBUTE; added in 8.0.21 (nonreserved)AUTOEXTEND_SIZEAUTO_INCREMENTAVGAVG_ROW_LENGTHBBACKUPBEFORE (R)BEGINBETWEEN (R)BIGINT (R)BINARY (R)BINLOGBITBLOB (R)BLOCKBOOLBOOLEANBOTH (R)BTREEBUCKETS; added in 8.0.2 (nonreserved)BY (R)BYTECCACHECALL (R)CASCADE (R)CASCADEDCASE (R)CATALOG_NAMECHAINCHANGE (R)CHANGEDCHANNELCHAR (R)CHARACTER (R)CHARSETCHECK (R)CHECKSUMCIPHERCLASS_ORIGINCLIENTCLONE; added in 8.0.3 (nonreserved)CLOSECOALESCECODECOLLATE (R)COLLATIONCOLUMN (R)COLUMNSCOLUMN_FORMATCOLUMN_NAMECOMMENTCOMMITCOMMITTEDCOMPACTCOMPLETIONCOMPONENTCOMPRESSEDCOMPRESSIONCONCURRENTCONDITION (R)CONNECTIONCONSISTENTCONSTRAINT (R)CONSTRAINT_CATALOGCONSTRAINT_NAMECONSTRAINT_SCHEMACONTAINSCONTEXTCONTINUE (R)CONVERT (R)CPUCREATE (R)CROSS (R)CUBE (R); became reserved in 8.0.1CUME_DIST (R); added in 8.0.2 (reserved)CURRENTCURRENT_DATE (R)CURRENT_TIME (R)CURRENT_TIMESTAMP (R)CURRENT_USER (R)CURSOR (R)CURSOR_NAMEDDATADATABASE (R)DATABASES (R)DATAFILEDATEDATETIMEDAYDAY_HOUR (R)DAY_MICROSECOND (R)DAY_MINUTE (R)DAY_SECOND (R)DEALLOCATEDEC (R)DECIMAL (R)DECLARE (R)DEFAULT (R)DEFAULT_AUTHDEFINERDEFINITION; added in 8.0.4 (nonreserved)DELAYED (R)DELAY_KEY_WRITEDELETE (R)DENSE_RANK (R); added in 8.0.2 (reserved)DESC (R)DESCRIBE (R)DESCRIPTION; added in 8.0.4 (nonreserved)DES_KEY_FILE; removed in 8.0.3DETERMINISTIC (R)DIAGNOSTICSDIRECTORYDISABLEDISCARDDISKDISTINCT (R)DISTINCTROW (R)DIV (R)DODOUBLE (R)DROP (R)DUAL (R)DUMPFILEDUPLICATEDYNAMICEEACH (R)ELSE (R)ELSEIF (R)EMPTY (R); added in 8.0.4 (reserved)ENABLEENCLOSED (R)ENCRYPTIONENDENDSENFORCED; added in 8.0.16 (nonreserved)ENGINEENGINESENGINE_ATTRIBUTE; added in 8.0.21 (nonreserved)ENUMERRORERRORSESCAPEESCAPED (R)EVENTEVENTSEVERYEXCEPT (R)EXCHANGEEXCLUDE; added in 8.0.2 (nonreserved)EXECUTEEXISTS (R)EXIT (R)EXPANSIONEXPIREEXPLAIN (R)EXPORTEXTENDEDEXTENT_SIZEFFAILED_LOGIN_ATTEMPTS; added in 8.0.19 (nonreserved)FALSE (R)FASTFAULTSFETCH (R)FIELDSFILEFILE_BLOCK_SIZEFILTERFIRSTFIRST_VALUE (R); added in 8.0.2 (reserved)FIXEDFLOAT (R)FLOAT4 (R)FLOAT8 (R)FLUSHFOLLOWING; added in 8.0.2 (nonreserved)FOLLOWSFOR (R)FORCE (R)FOREIGN (R)FORMATFOUNDFROM (R)FULLFULLTEXT (R)FUNCTION (R); became reserved in 8.0.1GGENERALGENERATED (R)GEOMCOLLECTION; added in 8.0.11 (nonreserved)GEOMETRYGEOMETRYCOLLECTIONGET (R)GET_FORMATGET_MASTER_PUBLIC_KEY; added in 8.0.4 (reserved); became nonreserved in 8.0.11GLOBALGRANT (R)GRANTSGROUP (R)GROUPING (R); added in 8.0.1 (reserved)GROUPS (R); added in 8.0.2 (reserved)GROUP_REPLICATIONHHANDLERHASHHAVING (R)HELPHIGH_PRIORITY (R)HISTOGRAM; added in 8.0.2 (nonreserved)HISTORY; added in 8.0.3 (nonreserved)HOSTHOSTSHOURHOUR_MICROSECOND (R)HOUR_MINUTE (R)HOUR_SECOND (R)IIDENTIFIEDIF (R)IGNORE (R)IGNORE_SERVER_IDSIMPORTIN (R)INACTIVE; added in 8.0.14 (nonreserved)INDEX (R)INDEXESINFILE (R)INITIAL_SIZEINNER (R)INOUT (R)INSENSITIVE (R)INSERT (R)INSERT_METHODINSTALLINSTANCEINT (R)INT1 (R)INT2 (R)INT3 (R)INT4 (R)INT8 (R)INTEGER (R)INTERVAL (R)INTO (R)INVISIBLEINVOKERIOIO_AFTER_GTIDS (R)IO_BEFORE_GTIDS (R)IO_THREADIPCIS (R)ISOLATIONISSUERITERATE (R)JJOIN (R)JSONJSON_TABLE (R); added in 8.0.4 (reserved)JSON_VALUE; added in 8.0.21 (nonreserved)KKEY (R)KEYS (R)KEY_BLOCK_SIZEKILL (R)LLAG (R); added in 8.0.2 (reserved)LANGUAGELASTLAST_VALUE (R); added in 8.0.2 (reserved)LATERAL (R); added in 8.0.14 (reserved)LEAD (R); added in 8.0.2 (reserved)LEADING (R)LEAVE (R)LEAVESLEFT (R)LESSLEVELLIKE (R)LIMIT (R)LINEAR (R)LINES (R)LINESTRINGLISTLOAD (R)LOCALLOCALTIME (R)LOCALTIMESTAMP (R)LOCK (R)LOCKED; added in 8.0.1 (nonreserved)LOCKSLOGFILELOGSLONG (R)LONGBLOB (R)LONGTEXT (R)LOOP (R)LOW_PRIORITY (R)MMASTERMASTER_AUTO_POSITIONMASTER_BIND (R)MASTER_COMPRESSION_ALGORITHMS; added in 8.0.18 (nonreserved)MASTER_CONNECT_RETRYMASTER_DELAYMASTER_HEARTBEAT_PERIODMASTER_HOSTMASTER_LOG_FILEMASTER_LOG_POSMASTER_PASSWORDMASTER_PORTMASTER_PUBLIC_KEY_PATH; added in 8.0.4 (nonreserved)MASTER_RETRY_COUNTMASTER_SERVER_IDMASTER_SSLMASTER_SSL_CAMASTER_SSL_CAPATHMASTER_SSL_CERTMASTER_SSL_CIPHERMASTER_SSL_CRLMASTER_SSL_CRLPATHMASTER_SSL_KEYMASTER_SSL_VERIFY_SERVER_CERT (R)MASTER_TLS_CIPHERSUITES; added in 8.0.19 (nonreserved)MASTER_TLS_VERSIONMASTER_USERMASTER_ZSTD_COMPRESSION_LEVEL; added in 8.0.18 (nonreserved)MATCH (R)MAXVALUE (R)MAX_CONNECTIONS_PER_HOURMAX_QUERIES_PER_HOURMAX_ROWSMAX_SIZEMAX_UPDATES_PER_HOURMAX_USER_CONNECTIONSMEDIUMMEDIUMBLOB (R)MEDIUMINT (R)MEDIUMTEXT (R)MEMBER; added in 8.0.17 (reserved); became nonreserved in 8.0.19MEMORYMERGEMESSAGE_TEXTMICROSECONDMIDDLEINT (R)MIGRATEMINUTEMINUTE_MICROSECOND (R)MINUTE_SECOND (R)MIN_ROWSMOD (R)MODEMODIFIES (R)MODIFYMONTHMULTILINESTRINGMULTIPOINTMULTIPOLYGONMUTEXMYSQL_ERRNONNAMENAMESNATIONALNATURAL (R)NCHARNDBNDBCLUSTERNESTED; added in 8.0.4 (nonreserved)NETWORK_NAMESPACE; added in 8.0.16 (nonreserved)NEVERNEWNEXTNONODEGROUPNONENOT (R)NOWAIT; added in 8.0.1 (nonreserved)NO_WAITNO_WRITE_TO_BINLOG (R)NTH_VALUE (R); added in 8.0.2 (reserved)NTILE (R); added in 8.0.2 (reserved)NULL (R)NULLS; added in 8.0.2 (nonreserved)NUMBERNUMERIC (R)NVARCHAROOF (R); added in 8.0.1 (reserved)OFF; added in 8.0.20 (nonreserved)OFFSETOJ; added in 8.0.16 (nonreserved)OLD; added in 8.0.14 (nonreserved)ON (R)ONEONLYOPENOPTIMIZE (R)OPTIMIZER_COSTS (R)OPTION (R)OPTIONAL; added in 8.0.13 (nonreserved)OPTIONALLY (R)OPTIONSOR (R)ORDER (R)ORDINALITY; added in 8.0.4 (nonreserved)ORGANIZATION; added in 8.0.4 (nonreserved)OTHERS; added in 8.0.2 (nonreserved)OUT (R)OUTER (R)OUTFILE (R)OVER (R); added in 8.0.2 (reserved)OWNERPPACK_KEYSPAGEPARSERPARTIALPARTITION (R)PARTITIONINGPARTITIONSPASSWORDPASSWORD_LOCK_TIME; added in 8.0.19 (nonreserved)PATH; added in 8.0.4 (nonreserved)PERCENT_RANK (R); added in 8.0.2 (reserved)PERSIST; became nonreserved in 8.0.16PERSIST_ONLY; added in 8.0.2 (reserved); became nonreserved in 8.0.16PHASEPLUGINPLUGINSPLUGIN_DIRPOINTPOLYGONPORTPRECEDESPRECEDING; added in 8.0.2 (nonreserved)PRECISION (R)PREPAREPRESERVEPREVPRIMARY (R)PRIVILEGESPRIVILEGE_CHECKS_USER; added in 8.0.18 (nonreserved)PROCEDURE (R)PROCESS; added in 8.0.11 (nonreserved)PROCESSLISTPROFILEPROFILESPROXYPURGE (R)QQUARTERQUERYQUICKRRANDOM; added in 8.0.18 (nonreserved)RANGE (R)RANK (R); added in 8.0.2 (reserved)READ (R)READS (R)READ_ONLYREAD_WRITE (R)REAL (R)REBUILDRECOVERRECURSIVE (R); added in 8.0.1 (reserved)REDOFILE; removed in 8.0.3REDO_BUFFER_SIZEREDUNDANTREFERENCE; added in 8.0.4 (nonreserved)REFERENCES (R)REGEXP (R)RELAYRELAYLOGRELAY_LOG_FILERELAY_LOG_POSRELAY_THREADRELEASE (R)RELOADREMOTE; added in 8.0.3 (nonreserved); removed in 8.0.14REMOVERENAME (R)REORGANIZEREPAIRREPEAT (R)REPEATABLEREPLACE (R)REPLICA; added in 8.0.22 (nonreserved)REPLICAS; added in 8.0.22 (nonreserved)REPLICATE_DO_DBREPLICATE_DO_TABLEREPLICATE_IGNORE_DBREPLICATE_IGNORE_TABLEREPLICATE_REWRITE_DBREPLICATE_WILD_DO_TABLEREPLICATE_WILD_IGNORE_TABLEREPLICATIONREQUIRE (R)REQUIRE_ROW_FORMAT; added in 8.0.19 (nonreserved)RESETRESIGNAL (R)RESOURCE; added in 8.0.3 (nonreserved)RESPECT; added in 8.0.2 (nonreserved)RESTART; added in 8.0.4 (nonreserved)RESTORERESTRICT (R)RESUMERETAIN; added in 8.0.14 (nonreserved)RETURN (R)RETURNED_SQLSTATERETURNING; added in 8.0.21 (nonreserved)RETURNSREUSE; added in 8.0.3 (nonreserved)REVERSEREVOKE (R)RIGHT (R)RLIKE (R)ROLE; became nonreserved in 8.0.1ROLLBACKROLLUPROTATEROUTINEROW (R); became reserved in 8.0.2ROWS (R); became reserved in 8.0.2ROW_COUNTROW_FORMATROW_NUMBER (R); added in 8.0.2 (reserved)RTREESSAVEPOINTSCHEDULESCHEMA (R)SCHEMAS (R)SCHEMA_NAMESECONDSECONDARY; added in 8.0.16 (nonreserved)SECONDARY_ENGINE; added in 8.0.13 (nonreserved)SECONDARY_ENGINE_ATTRIBUTE; added in 8.0.21 (nonreserved)SECONDARY_LOAD; added in 8.0.13 (nonreserved)SECONDARY_UNLOAD; added in 8.0.13 (nonreserved)SECOND_MICROSECOND (R)SECURITYSELECT (R)SENSITIVE (R)SEPARATOR (R)SERIALSERIALIZABLESERVERSESSIONSET (R)SHARESHOW (R)SHUTDOWNSIGNAL (R)SIGNEDSIMPLESKIP; added in 8.0.1 (nonreserved)SLAVESLOWSMALLINT (R)SNAPSHOTSOCKETSOMESONAMESOUNDSSOURCESPATIAL (R)SPECIFIC (R)SQL (R)SQLEXCEPTION (R)SQLSTATE (R)SQLWARNING (R)SQL_AFTER_GTIDSSQL_AFTER_MTS_GAPSSQL_BEFORE_GTIDSSQL_BIG_RESULT (R)SQL_BUFFER_RESULTSQL_CACHE; removed in 8.0.3SQL_CALC_FOUND_ROWS (R)SQL_NO_CACHESQL_SMALL_RESULT (R)SQL_THREADSQL_TSI_DAYSQL_TSI_HOURSQL_TSI_MINUTESQL_TSI_MONTHSQL_TSI_QUARTERSQL_TSI_SECONDSQL_TSI_WEEKSQL_TSI_YEARSRID; added in 8.0.3 (nonreserved)SSL (R)STACKEDSTARTSTARTING (R)STARTSSTATS_AUTO_RECALCSTATS_PERSISTENTSTATS_SAMPLE_PAGESSTATUSSTOPSTORAGESTORED (R)STRAIGHT_JOIN (R)STREAM; added in 8.0.20 (nonreserved)STRINGSUBCLASS_ORIGINSUBJECTSUBPARTITIONSUBPARTITIONSSUPERSUSPENDSWAPSSWITCHESSYSTEM (R); added in 8.0.3 (reserved)TTABLE (R)TABLESTABLESPACETABLE_CHECKSUMTABLE_NAMETEMPORARYTEMPTABLETERMINATED (R)TEXTTHANTHEN (R)THREAD_PRIORITY; added in 8.0.3 (nonreserved)TIES; added in 8.0.2 (nonreserved)TIMETIMESTAMPTIMESTAMPADDTIMESTAMPDIFFTINYBLOB (R)TINYINT (R)TINYTEXT (R)TLS; added in 8.0.21 (nonreserved)TO (R)TRAILING (R)TRANSACTIONTRIGGER (R)TRIGGERSTRUE (R)TRUNCATETYPETYPESUUNBOUNDED; added in 8.0.2 (nonreserved)UNCOMMITTEDUNDEFINEDUNDO (R)UNDOFILEUNDO_BUFFER_SIZEUNICODEUNINSTALLUNION (R)UNIQUE (R)UNKNOWNUNLOCK (R)UNSIGNED (R)UNTILUPDATE (R)UPGRADEUSAGE (R)USE (R)USERUSER_RESOURCESUSE_FRMUSING (R)UTC_DATE (R)UTC_TIME (R)UTC_TIMESTAMP (R)VVALIDATIONVALUEVALUES (R)VARBINARY (R)VARCHAR (R)VARCHARACTER (R)VARIABLESVARYING (R)VCPU; added in 8.0.3 (nonreserved)VIEWVIRTUAL (R)VISIBLEWWAITWARNINGSWEEKWEIGHT_STRINGWHEN (R)WHERE (R)WHILE (R)WINDOW (R); added in 8.0.2 (reserved)WITH (R)WITHOUTWORKWRAPPERWRITE (R)XX509XAXIDXMLXOR (R)YYEARYEAR_MONTH (R)ZZEROFILL (R)ZONE; added in 8.0.22 (nonreserved)MySQL 8.0新关键字和保留字下表显示了与MySQL 5.7相比在MySQL 8.0中增加的关键字和保留字。保留的关键字标有（R）。 ...

备份备份单个数据库： mysqldump -u root -h 127.0.0.1 -ppassport dbname > backdb.sql 备份多个数据库： mysqldump -u root -h 127.0.0.1 -ppassport --databases dbname1, dbname2 > backdb.sql备份数据库表： mysqldump -u root -h 127.0.0.1 -ppassport dbname tbname1, tbname2 > backdb.sql备份零碎中所有数据库： (包含零碎数据库) mysqldump -u root -h 127.0.0.1 -ppassport --lock-all-tables --all-databases > all.sql复原复原所有数据 办法1： (毛病 若数据中不存在对应数据库须要手动创立) mysqldump -u root -ppassport -h 127.0.0.1 --all-databases < all.sql复原所有数据 办法2： (举荐 长处复原所有数据) mysqldump -u root -ppassport -h 127.0.0.1 --all-databases < all.sql复原所有数据 办法3： (mysql 命令行) ...

作者：胡呈清 爱可生 DBA 团队成员，善于故障剖析、性能优化，集体博客：https://www.jianshu.com/u/a95...，欢送探讨。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 已知 change buffer 的原理 参考资料：https://juejin.im/post/684490... 对于一般二级索引，当插入、批改、删除二级索引记录时，即便数据不在 innodb buffer pool 中，也不须要先把数据从磁盘读取到内存。只须要在 change buffer 中实现 DML 操作，下次读取时才会从磁盘读取数据页到内存，并与 change buffer 进行 merge，从而失去正确的数据。这缩小了 DML 时的随机 IO。 疑难依照上述原理，应用 change buffer 二级索引不须要读取磁盘，那 delete、update 是如何失去 affected rows 的？ 答无妨先作出假如： 如果 delete、update 是以主键、惟一索引做为筛选条件，则读取磁盘或者 innodb buffer pool 中的主键、惟一索引来确定 affected rows。对于一般索引页上记录的删除或者批改，还是间接应用 change buffer，不须要独自将一般索引页从磁盘上读取到内存。如果 delete、update 是以一般二级索引做为筛选条件，以 delete 为例（update 外部实现是先 delete 再 insert）：delete from t where a=100; 如果索引页不在内存中，则须要先从磁盘读取 a 索引，找到 a = 100 的记录对应的 id（主键值），再从磁盘扫描主键索引（回表）将 id 满足条件的记录读取到内存。而后在 innodb buffer pool 中把对应的主键索引页、二级索引页中的记录删除。这里不应用 change buffer。验证接下来设计两个试验来验证上述假如。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。查看形式已知至多有两种形式能够实现1.开启 general_log 就能够察看到开启命令mysql> set global general_log=ON;执行一些操作[root@mgr2 ~]# mysql -uGreatSQL -pGreatSQL -h192.168.6.217 -P3306mysql> use test;mysql> show tables;+----------------+| Tables_in_test |+----------------+| book || student || t1 |+----------------+3 rows in set (0.01 sec)mysql> select * from t1;+------+--------+| id | name |+------+--------+| 1 | 哈哈 || 2 | 你好 || 3 | 呵呵 |+------+--------+5 rows in set (0.00 sec)mysql> delete from test.t1 where id=4;Query OK, 1 row affected (0.02 sec)查看general_log日志信息，曾经残缺记录到了。2022-01-20T21:46:17.073491-05:00 32 Connect GreatSQL@192.168.6.216 on using TCP/IP2022-01-20T21:46:17.074048-05:00 32 Query select @@version_comment limit 12022-01-20T21:46:20.217080-05:00 32 Query SELECT DATABASE()2022-01-20T21:46:20.217657-05:00 32 Init DB test2022-01-20T21:46:20.218960-05:00 32 Query show databases2022-01-20T21:46:20.220347-05:00 32 Query show tables2022-01-20T21:46:20.222050-05:00 32 Field List book2022-01-20T21:46:20.222644-05:00 32 Field List student2022-01-20T21:46:20.223106-05:00 32 Field List t12022-01-20T21:46:22.856100-05:00 32 Query show tables2022-01-20T21:46:31.156616-05:00 32 Query select * from t12022-01-20T21:46:43.136448-05:00 32 Query delete from test.t1 where id=42.抓包这里采纳 MySQL Sniffer 进行抓包。1.MySQL Sniffer 介绍MySQL Sniffer 是一个基于 MySQL 协定的抓包工具，实时抓取 MySQL Server 端的申请，并格式化输入。输入内容包拜访括工夫、拜访用户、起源 IP、拜访 Database、命令耗时、返回数据行数、执行语句等。有批量抓取多个端口，后盾运行，日志宰割等多种应用形式，操作便捷，输入敌对。开源出品方：奇虎360github 地址：https://github.com/Qihoo360/m...2.装置依赖包yum install gcc gcc-c++ cmake libpcap-devel glib2-devel libnet-devel -y3.装置命令git clone https://github.com/Qihoo360/mysql-sniffer.gitcd mysql-sniffermkdir projcd projcmake ../make编译过程中呈现一些问题，参考 https://www.cnblogs.com/kerry... 解决，感激！ ...

本题应用的是 MySQL8.0，没有在 MySQL5.6 版本中测验过，不保障正确。 题目题目起源：体育馆的人流 查找出每行人数大于 100 且 id 间断的三行或者更多好记录 create table stadium ( id int, visit_date date, people int)insert into stadium values(1, '2017-01-01', 10),(2, '2017-01-02', 109),(3, '2017-01-03', 150),(4, '2017-01-04', 99),(5, '2017-01-05', 145),(6, '2017-01-06', 1455),(7, '2017-01-07', 199),(8, '2017-01-09', 188);SQL：办法一select * from ( select *, count(*) over(partition by diff) as counts from ( select *, id - row_number() over(order by id) as diff from stadium where people >= 100 ) as base) as s where counts >= 3;解析问题的关键在于如何晓得哪几天的 id 是间断的。 ...

明天看到这个文章：MySQL数据查问太多会OOM吗？ 我记得mysql对于大数据的查问会应用硬盘作为长期表（当内存不够用时候），而不仅仅是利用内存做长期表吧！这个文章中没有提及硬盘的事件，是我记错了吗？

本题应用的是 MySQL8.0，没有在 MySQL5.6 版本中测验过，不保障正确。 题目查出超过或等于 5 名学生的课（学生的课不被反复计算） create table courses ( student varchar(255), class varchar(255))insert into courses values('A', 'Math'),('B', 'English'),('C', 'Math'),('D', 'Biology'),('E', 'Math'),('F', 'Computer'),('G', 'Math'),('H', 'Math'),('I', 'Math');SQL：办法一select class from courses group by class having count(*) >= 5;解析题目起源：超过5名学生的课 学生的课不反复，所以依照 class 分组，在应用 having 筛选出大于等于 5 课的同学 SQL：办法二select class from ( select class, count(*) as num from courses group by class) as c where num >= 5;解析首先查出每门课的学生人数，应用 group by 分组把这次查问作为一个长期表再次对这张表进行查问，筛选条件是人数大于等于 5 人。更多解题参考：https://github.com/astak16/bl... ...

MySQL 8 JSON多值索引背景介绍咱们有个 node model，对应的存储表名也叫 node。这个model外面，有一些简单配置，是用 json 的格局存储的。这个json配置外面，有个字段会指向另一个node，所以在删除某个node的时候须要查看这个node是否被援用了，如果被援用则不容许删除。这个查看操作，不可能是全表扫描，因而须要创立索引。于是就有了要给 JSON 字段创立多值索引的需要。 建表 & 索引表的schema就不放这里了，次要是有个叫 units_json 字段，其它不重要。 而后创立索引，留神这里是多值，所以用了ARRAY ALTER TABLE `node` ADD INDEX `jump_node_code_index`( (CAST(units_json -> '$.units[*].decisionEntries[*].capsules[*].jumpNodeCode' AS CHAR(50) ARRAY)) );下面那个 $.units[*]... 是 jsonPath 的定义语法，不理解的同学能够自行谷歌一下。查问MySQL 8 中，JSON_EXTRACT 函数能够用 -> 操作符示意。上面这个查问语句，能够将所有 jumpNodeCode 查出来，也就是所有的跳转节点。 SELECT units_json -> '$.units[*].decisionEntries[*].capsules[*].jumpNodeCode' FROM node;条件查问上面这个查问语句应用了 MEMBER OF 作为条件。意思是将所有援用了 xxxNode 的节点全副查出来。这个查问语句将用于删除查看。 SELECT node_id, `code`, `name` FROM nodeWHERE 'xxxNode' MEMBER OF (units_json -> '$.units[*].decisionEntries[*].capsules[*].jumpNodeCode');编写jOOQ 工具类咱们我的项目的ORM框架应用jOOQ，国内绝对MyBatis而言小众很多。但我比拟喜爱用jOOQ，感兴趣的同学可自行谷歌。jOOQ 没有提供MySQL这种比较复杂语法，于是自行封装了个工具类 public class JooqSyntax { /** * * @param value 查看值 * @param field 列 * @param jsonPath json文档语法 * @return jooq 条件 */ public static Condition memberOfCondition(Object value, TableField<?, ?> field, String jsonPath) { return DSL.condition("{0} MEMBER OF ({1})", value, jsonField(field, jsonPath) ); } public static Field<Object> jsonField(TableField<? extends Record, ?> field, String jsonPath) { return DSL.field("{0} -> {1}", field, jsonPath); } }单元测试，次要是用于阐明如何应用。 ...

1月7日，由阿里云实时数仓Hologres和开发者社区独特举办了实时数仓年度发布会。在发布会上，来自阿里云的资深技术专家果贝从阿里的外围场景登程，深度解读了实时数仓技术倒退的新趋势：一站式、在线化、麻利化。在发布会上，Hologres产品负责人合一针对以后数仓的新趋势，重磅公布了Hologres年度重点能力，助力企业更好的建设一站式实时数仓。 本文将会从多个角度总结Hologres的重点性能，以帮忙用户更加理解和应用Hologres。 源于业务翻新，继续业务演进Hologres从诞生至今曾经走过6年的工夫，首次提出服务剖析一体化（Hybrid Serving & Analytical Processing，简称HSAP）理念，逐渐倒退为企业级一站式数仓，不仅在阿里团体外部服务泛滥外围业务（如淘宝、天猫、1688、菜鸟、本地生存、达摩院等），也在继续云上服务能力输入，助力国内、国内更多企业搭建企业级实时数仓。截止目前，曾经在寰球13个Region同步提供服务。 全新迭代，年度重磅公布Highlight21年Hologres在引擎能力上重点发力，经验了三个外围版本的迭代，下一代产品也曾经在内测中，仍旧放弃着疾速迭代的节奏。通过行列共存、高可用部署、读写拆散、疾速Failover等能力，显著改善了数据服务的稳定性，丰盛了业务应用场景：1、性能继续晋升：每个大版本继续优化引擎性能，在优化器、查问引擎、存储引擎多个层面改良，以32core TPCH 100G测试后果为例，在1.1版本相比去年0.8版本有256%的性能晋升（查问局部），晋升效果显著 2、强化高并发的服务（serving）能力：行存吞吐晋升100%，列存吞吐晋升30%，反对行列共存，一份数据反对多个场景，列存降级AliORC格局，更高的压缩比，显著升高存储老本。 3、企业级高可用部署和企业级治理能力上重点发力，通过透出更多维度更细粒度的观测性指标，晋升企业的自运维能力。 上面将会针对重点性能进行更加细粒度的介绍。 原生JSON反对JSON是近期Hologres重点发力的畛域，因为数据采集越来越灵便，数据加工也越来越麻利，过来须要打宽拉平的JSON数据，往往保留了原始的不标准构造。因而如何解决Schemeless场景就尤为重要。 传统上，JSON作为一个数据单位，采纳Schema on Read模式，提供了存储上的灵活性，但限度了剖析时的效率，为了拜访JSON中局部节点不得不读取整个JSON数据结构，效率十分低下，存储上也很难压缩。 Hologres翻新了JSON数据的存储形式，在底层存储上采纳相似列存的存储格局，将JSON中不同的节点门路映射为虚构的列，提供原生的列存压缩、索引能力，在查问层，主动下推JSON拜访算子，极大的减速了JSON数据过滤、统计的效率。在协定层，齐全兼容了PG的标准，反对了JSON、JSONB等类型，反对PG原生的各种结构、拜访、更新的算子。基于这些翻新的能力，JSON成为Hologres举荐的数据类型，适宜于埋点日志剖析的场景。 Binlog全链路事件驱动相似于传统数据库MySQL中的Binlog概念，在Hologres中，Binlog用来记录数据库中表数据的批改记录，比方Insert/Delete/Update的操作。通过Flink、JDBC生产Hologres BInlog，实现数仓档次间全链路实时开发，在分层治理的前提下，缩短数据加工端到端提早。典型利用场景如下： 数据实时复制、同步场景，典型的场景就是把一张Hologres的行存表实时转化成另一张列存表，行存反对点查点写，列存反对多维分析型需要，同步的逻辑由Flink反对。这个是Hologres在V1.1版本之前的一种典型用法。在Hologres 1.1中反对了行列共存表后，能够一张表满足行存和列存两种需要，免去了额定的调度开销。实现事件的全链路驱动：通过Flink生产Hologres Binlog，实现事件驱动的加工开发，实现ODS向DWD，DWD向DWS等的全实时加工作业。数据变动监控：监控数据的实时变动，比方监控库存数据、敏感字段等的实时变动，触发告警。数据在实例间同步：用户能够创立多个Hologres实例，别离用于公共层加工、业务域加工等职责，不同实例之间能够通过Binlog实现数据的实时同步，实现了数据的实时流动和分享。 实时离线一体化数仓Hologres+MaxComputeMaxCompute是阿里云可扩大的大数据加工引擎，技术成熟、服务稳固。Hologres与MaxCompute均采纳盘古存储引擎，底层技术雷同。Hologres采纳原生向量化查问引擎减速查问MaxCompute数据，实现对MaxCompute的查问减速能力，此种场景无需数据迁徙和导入数据，高性能和全兼容的拜访各种MaxCompute文件格式，为BI工具和大数据数仓之间建设起交互式剖析的快速通道。Hologres新版本中，曾经默认应用原生的向量引擎直读MaxCompute，缩小跨引擎的RPC调用，更少的引擎间数据序列化，同一个引擎，有利于缓存的复用，性能晋升30%-80%。 实时离线一体化计划中很重要的是数据交换的简化，甚至无需数据挪动。表面查问是不须要挪动数据的场景，但因为表面没有索引和SSD的优化，查问性能和并发能力低于内表场景，在性能敏感的场景下，依然倡议数据从MaxCompute同步到Hologres中，在同步操作中，同步的效率就更加重要。目前通过存储技术的翻新，反对了MaxCompute与Hologres之间每秒百万行的双向同步，简化了数据开发、数据回刷的场景。 MaxCompute与Hologres元数据的买通也是一项继续的工作，晚期Hologres反对了元数据的批量导入，能够把整个project的全副表一次性导入，也反对批量更新。最近Hologres反对了元数据的主动导入与刷新，当MaxCompute侧有新的表创立，或者表构造的变更，无需手动刷新，元数据能够主动同步到Hologres，体验更简便。 与此同时，为了更加敌对麻利的反对MaxCompute减速场景，Hologres提供了一种新的服务状态：共享集群。在该状态下，用户无需提前部署实例，而是采纳Serverless的形式，依据查问数据的扫描量计费，这个状态仅反对MaxComputeBI减速场景，不能创立内表和索引，对于过来应用MaxCompute Lightning查问减速的用户能够平滑切换到这种共享集群中，不必从新建表，不必批改BI协定，可用连接数比Lightning更多，服务更稳固。 减速数据湖摸索传统架构湖和仓还是比拟割裂的，有些企业在建设数据湖时，对数据治理和数据管理绝对比拟艰难，随着企业过程的推动，越来越多的企业开始摸索湖仓一体。Hologres在往年重点优化了湖仓一体场景，反对了表面间接拜访OSS数据和数据回流OSS，反对DLF集成，减速数据湖摸索，助力湖仓一体建设 。 深入流量剖析场景流量剖析是Hologres继续减少的场景，目前反对了高性能的Bitmap库RoaringBitmap，能够以常量复杂度，疾速计算UV，是解决互联网级别高基数准确去重、UV计算的要害伎俩，宽泛应用在用户画像、标签筛选等典型场景，在阿里妈妈广告场景中被深度应用。 同时Hologres也内置了更多的漏斗剖析、留存剖析、明细圈人等函数，通过这些内置的函数，极大的简化了开发的工作，也保障了简单操作的执行效率。 多负载资源隔离资源组隔离是无效撑持混合负载的一种伎俩，Hologres反对了单实例多资源组的设计，在这个设计中，总的计算资源被划分为若干资源组，不同的资源组示意了肯定的CPU和内存资源，同时设定用户与资源组之间的绑定关系，绑定之后，用户只能应用对应资源组的计算资源，所有未绑定的用户会应用零碎默认的Default资源组。目前资源组之间资源不共享，不抢占，资源组外部多个用户共享同一组资源。 如上图的右侧是一个用户视角的划分，一个256Core1024G的实例，划分为3个资源组，不同的利用场景采纳不同的账号，比方OLAP剖析用Default资源组，调配50%，在线点查须要20%的资源，而数据实时写入调配30%的资源。通过资源组的隔离能力，防止了Bad Query把全副资源吃尽的问题，能够依据业务优先级分配资源。 高可用部署资源组隔离是一种单实例外部不同线程池之间的计算资源的隔离，无奈做到故障隔离和100%的读写隔离。因而Hologres持续翻新更好的高可用计划，在V1.1版本，反对了共享存储的多实例部署计划。在该计划中，主实例具备残缺能力，数据可读可写，权限、零碎参数可配置，而子实例处于只读状态，所有的变更都通过主实例实现，实例之间共享一份数据存储，实例间数据异步实时同步，提早在毫秒级别。 利用场景：1.读写拆散：这个计划实现了残缺的读写拆散性能，保障不同业务场景的SLA，在高吞吐的数据写入和简单的架构作业、OLAP、AdHoc查问、线上服务等场景中，负载之间物理上齐全隔离，不会因写入产生查问的抖动。2.多类型负载细粒度资源分配：一个主实例能够配置多个只读从实例，实例之间能够依据业务状况配置不同规格，例如应用256Core作为写入和加工实例，512Core作为OLAP只读实例，128Core作为在线Serving实例，32Core作为开发测试实例。 在线服务高可用：任何零碎都有不稳固的时刻，磁盘损坏，零碎Bug等等，在撑持在线高可用服务场景下，须要在零碎级别撑持冗余的高牢靠能力，在一个服务零碎呈现故障时，能够疾速切换到备用系统上，且切换的工夫要尽量短，数据状态保持一致。能够通过部署多个子实例的模式，提供多个Endpoint接入，当某个实例呈现故障时，应用层能够疾速切换到其余Endpoint上，实现了零碎的高可用和灾备切换。加强零碎可观测性零碎可观测性通过HoloWeb继续可视化透出，包含慢查问、执行打算、沉闷连贯等，晋升企业自运维能力： 慢Query日志：反对对系统中产生的慢Query或失败Query通过工夫、plan、cpu耗费等各项指标进行诊断、剖析和采取优化措施，进步自助诊断能力。沉闷连贯：通过对沉闷连贯的可视化查看，定位连贯状态、连接数以及用户等的状况，以达到剖析实例连贯状态和诊断运行SQL的目标。执行打算：通过多种可视化展示的形式，对Query进行运行剖析、执行剖析，具体算子解读，并进行优化倡议疏导，防止自觉调优，升高性能调优门槛，疾速达到性能调优的目标。企业级平安能力降级企业级平安能力再次降级，反对数据加密、访问控制、容灾备份等：1）数据加密： 基于密钥治理服务KMS（Key Management Service）对数据进行加密存储，提供数据动态爱护能力，满足企业监管和平安合规需要。与MaxCompute无缝买通，反对减速MaxCompute加密数据，向实时离线一体化更进一步。反对数据脱敏，对接数据保护伞，晋升数据隐衷性。2）访问控制 反对IP白名单，实现更加细粒度的平安拜访。对接ActionTrial，反对实例级别行为审计。3）容灾备份 反对同城跨机房容灾（专有云）反对容灾，异地多活，并实现读写拆散和读的高并发，同样也能够基于多个实例实现读的高可用。除此之外，还能够进行版本热降级，存储系统迁徙。PG生态兼容反对更加丰盛的数据类型、更多元的扩大函数，同时在BI可视化剖析上继续发力，无缝对接更多BI工具，升高学习门槛，也向PostgreSQL兼容更进一步。 继续专一于一站式实时数仓Hologres将来会持续专一在实时数仓的可靠性、效率和可运维能力上，致力于Real-time，专一于One SQL、One Data，晋升企业级可运维性，升高开发门槛，实现企业级一站式实时数仓的终极目标。具体会在以下方面发力： Real-Time简化实时数仓的开发体验，反对Pull模式，被动从上游的消息中间件拉取数据，简化数据落库的过程。正在研发实时物化视图的能力，通过实时物化视图，用户能够把简单的加工逻辑形容为视图的定义，Hologres保障视图与表之间的实时同步个性，通过SQL表白数据的加工逻辑，实现数据分层的实时化，与数据流动的自动化。 OneSQL欠缺Hologres SQL的表达能力，反对OLAP/Serving/AI多个场景，继续改善稳定性和效率，不仅要查的快，更要查的稳。继续优化实时离线一体化体验，进一步缩小数据挪动的需要。欠缺JSON的各类索引和压缩效率。会反对UDF能力，欠缺可扩展性，将更多的扩大可能性交给用户。对计算资源的弹性也是重点方向。 OneData进一步与DLF、MaxCompute、EMR等存储和元数据系统买通，防止数据孤岛，反对湖仓一体解决方案。正在研发存储冷热分层，在SSD根底上引入HDD，能够显著升高用户的存储老本。 Ops最初是可运维性，会继续在零碎可观测、可调优发力，防止零碎黑盒话，支持系统热降级、热扩容，升高运维危险。会极大改善数据治理能力，与DataWorks单干，反对更多的元数据分析与诊断。 附件：发布会PPT下载对于本次发布会的PPT材料，请移步钉钉用户群获取

最近遇到一个需要，一个表里有50个字段左右。我须要写一个详情接口，把这些字段都查出来。我想这很简略呀，我间接select * 不就好了嘛。于是我就这样干了 select * from foo;嗯，仿佛很完满，然而忽然发现，这个表里有个敏感字段的内容是不能输入的，也就是我得从其中去掉一个字段。那就麻烦了，我可不想select column1,column2,column3,column4, 这样一个个写，要是这样一个个的写完，这么多的字段，我手都得残废了。我就想能不能写个SQL来主动拼接字段名称。答案当然是能够的，咱们来看看这个SQL select GROUP_CONCAT(concat('`', COLUMN_NAME,'`')) from information_schema.`COLUMNS` where TABLE_SCHEMA='dbname' and TABLE_NAME='tablename';对的，就这样就能够了。这下难受了。当然SQL语句后面的 select 前面 from 和where 就依据本人的理论须要来补充了。 简略阐明一下，应用下面SQL的时候要把dbname换成你的数据库的名称，tablename换成表名。比方咱们查wordpress的wp_user表。 mysql> select GROUP_CONCAT(concat('`', COLUMN_NAME,'`')) from information_schema.`COLUMNS` where TABLE_SCHEMA='blog' and TABLE_NAME='wp_users';+--------------------------------------------------------------------------------------------------------------------------------------------+| GROUP_CONCAT(concat('`', COLUMN_NAME,'`')) |+--------------------------------------------------------------------------------------------------------------------------------------------+| `ID`,`user_login`,`user_pass`,`user_nicename`,`user_email`,`user_url`,`user_registered`,`user_activation_key`,`user_status`,`display_name` |+--------------------------------------------------------------------------------------------------------------------------------------------+1 row in set (0.06 sec)有人说，要不要解析一下这个SQL。好的，这就解析一下 从information_schema.COLUMNS 这个表里把所有的字段名称查出来，就是 COLUMN_NAME 这个字段。通过concat函数，给字段名前后加上`这个字符通过 group_concat这个函数，拼接成一行。

上篇文章中，松哥和大家分享了索引的两个应用规定： 索引上不要应用函数运算。应用笼罩索引防止回表。当然，凡事有个度，用哪一种策略也要联合具体的我的项目来定，不能为了 SQL 优化而摈弃了业务。 明天，松哥在前文的根底上，再来和大家分享一条索引规定，一起来学习下。 咱们常说，MySQL 中的 like 要慎用，因为会全表扫描，这是一件可怕的事！不过呢，也看状况，有的 like 其实也能用索引：有的时候 like 用索引效率很高，有的时候 like 尽管用了索引效率却低的可怕。 咱们一起来剖析下。 1. 最左匹配准则我还是举个例子吧，假如我有如下一张表： CREATE TABLE `user` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `username` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL, `birthday` date DEFAULT NULL, `age` int(11) DEFAULT NULL, `address` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL, PRIMARY KEY (`id`), KEY `username` (`username`,`age`)) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;username 和 age 组成了复合索引，复合索引名为 username，下文提到的 username 索引都是指该复合索引。 依据上篇文章（是时候检查一下应用索引的姿态是否正确了！）的解说，咱们晓得，对于如下 SQL： select username,age from user2 where username='javaboy' and age=99;这个 SQL 在查问的过程中，会用到笼罩索引，防止回表，进步查问效率。 ...

作者：xuty 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 一. 纲要本文分享下对于 my2sql 的一些改良，并且接入到 DBeaver 中供开发便捷应用的一个理论案例。 置信很多 DBA 日常都会遇到开发误删除数据（DML闪回）或者须要追溯数据变动起因（解析原始SQL）的需要，当这种需要愈发多的时候（别问为什么，说多了都是泪），就会很厌倦此类工作，因而就想着实现一套工具供开发或者施行本人应用，而不须要 DBA 接入解决。 my2sql 是集体用过的很多 binlog 解析工具中比拟杰出的一个，因为它解析性能比拟优异，且应用也绝对简略。 误删除数据闪回：依赖于 my2sql 的性能，能够疾速生成指定表指定操作的 DML 操作回滚语句，确认后执行回滚 SQL 即可回复数据。追溯数据变动起因：my2sql 无奈实现该性能，须要依赖 DBA 手动解析 binlog ，剖析 rows_query_log ，失去原始执行 SQL 进一步剖析。咱们以如下图为例：闪回性能即须要实现rollback，生成对应DML的回滚SQL，这是my2sql自带的性能；而想要晓得数据变动的真正起因，则须要实现query，失去原始执行SQL才比拟好剖析（当然须要保障MySQL中开启了binlog_rows_query_log_events才会在binlog中记录原始SQL）。 二. my2sql改良为了更加不便非 DBA 应用，对于 my2sql 进行了一些改良，次要包含2点： 实现 query 能力，其实就是在原有的根底上，减少解析Rows_query对应的 event 性能，让 my2sql 也能够依据库表、操作类型解析失去对应的原始 SQL ，而非只能实现行数据的回滚SQL or 前滚SQL 。原生的 my2sql 应用上通常须要指定star-file，即起始binlog，这对于不相熟 MySQL 的人来说比拟麻烦，如果不指定起始 binlog ，光指定工夫范畴，那么 my2sql 会从第一个 binlog 开始解析，比拟费时，性能不好。这里我的做法是，只须要输出工夫范畴，因为这个对于开发来说比较简单，而 binlog 的范畴则会通过输出的工夫范畴，主动适配，原理是对于 MySQL 中存在的每个 binlog 都会只解析其第一个 event ，失去每个 binlog 工夫范畴，而后依据输出工夫范畴，就能够主动匹配对应的 binlog 范畴，这样就不须要解析无用的 binlog ，节省时间。吐槽：MySQL 中为了失去每个 binlog 的工夫区间真的好难，官网就不能在 show binary logs 中减少工夫输入吗？ ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。1、问题形容在做MGR测试的时候偶然遇到gtid_executed事务ID不间断的问题，然而并不影响数据库的失常运行。景象如下 GreatDB Cluster[sysbench]> select @@gtid_executed;+-----------------------------------------------------------------+| @@gtid_executed |+-----------------------------------------------------------------+| 5cd1a64d-7358-11ec-b349-080027fa2d35:1-1286:2052-2290:3052-3277 |+-----------------------------------------------------------------+1 row in set (0.00 sec)2、确认起因查看官网文档发现以下参数：group_replication_gtid_assignment_block_size 以下是对官网文档的翻译和了解 group_replication_gtid_assignment_block_size为每个成员保留的间断GTID数。每个成员从中进行耗费，并在其须要的时候获取更多的GTID数（相似于分布式事务中的全局序列，该零碎变量设置的值示意每个成员每一次从全局序列中获取多大范畴的间断数字范畴来作为本身写事务的GTID号）。 该零碎变量是组范畴的配置设置，它必须在所有组成员上设置雷同的值，在组复制运行时不容许批改，要使得批改值失效，须要齐全从新疏导组（应用零碎变量group_replication_bootstrap_group= on来从新疏导组）。 全局变量，动静变量，整型类型，默认值为1000000，取值范畴：32位平台为1~4294967295，64位平台为1~9223372036854775807，MySQL 5.7.17版本引入。 官网文档地址：https://dev.mysql.com/doc/ref... 通过对文档理解到MGR会为每个实例节点调配一段间断的GTID值，所以狐疑是MGR产生了主从切换，从而导致GTID的事务ID不间断 2.1、复现问题为不便测试批改group_replication_gtid_assignment_block_size为1000，并重启MGR GreatDB Cluster[(none)]> set persist group_replication_gtid_assignment_block_size=1000;Query OK, 0 rows affected (0.00 sec)GreatDB Cluster[(none)]> set global group_replication_bootstrap_group=on;Query OK, 0 rows affected (0.00 sec)GreatDB Cluster[(none)]> start group_replication;Query OK, 0 rows affected (2.45 sec)GreatDB Cluster[(none)]> set global group_replication_bootstrap_group=off;Query OK, 0 rows affected (0.00 sec)把82切换为主节点而后通过sysbench模仿业务GreatDB Cluster[sysbench]> select @@gtid_executed;+---------------------------------------------+| @@gtid_executed |+---------------------------------------------+| 5cd1a64d-7358-11ec-b349-080027fa2d35:1-5445 |+---------------------------------------------+1 row in set (0.00 sec)GreatDB Cluster[sysbench]> select * from performance_schema.replication_group_members;+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+| group_replication_applier | cf43d5d7-7354-11ec-af9a-080027fa2d35 | 172.16.50.81 | 4444 | ONLINE | PRIMARY | 8.0.25 || group_replication_applier | cf520b3b-7354-11ec-b785-08002792d155 | 172.16.50.82 | 4444 | ONLINE | SECONDARY | 8.0.25 || group_replication_applier | cf85763c-7354-11ec-898d-0800276e4bea | 172.16.50.83 | 4444 | ONLINE | SECONDARY | 8.0.25 |+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+3 rows in set (0.00 sec)GreatDB Cluster[sysbench]> SELECT group_replication_set_as_primary('cf520b3b-7354-11ec-b785-08002792d155');+--------------------------------------------------------------------------+| group_replication_set_as_primary('cf520b3b-7354-11ec-b785-08002792d155') |+--------------------------------------------------------------------------+| Primary server switched to: cf520b3b-7354-11ec-b785-08002792d155 |+--------------------------------------------------------------------------+1 row in set (1.38 sec)GreatDB Cluster[sysbench]> select * from performance_schema.replication_group_members;+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+| group_replication_applier | cf43d5d7-7354-11ec-af9a-080027fa2d35 | 172.16.50.81 | 4444 | ONLINE | SECONDARY | 8.0.25 || group_replication_applier | cf520b3b-7354-11ec-b785-08002792d155 | 172.16.50.82 | 4444 | ONLINE | PRIMARY | 8.0.25 || group_replication_applier | cf85763c-7354-11ec-898d-0800276e4bea | 172.16.50.83 | 4444 | ONLINE | SECONDARY | 8.0.25 |+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+3 rows in set (0.00 sec)模仿业务在新的主节点写业务 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。3306 福州站，以下内容是由万里数据库，研发工程师唐洁分享的MySQL闪回计划残缺PPT。 Enjoy GreatSQL :) 文章举荐：GreatSQL MGR FAQhttps://mp.weixin.qq.com/s/J6... 万答#12，MGR整个集群挂掉后，如何能力主动选主，不必手动干涉https://mp.weixin.qq.com/s/07... 『2021数据技术嘉年华·ON LINE』：《MySQL高可用架构演进及实际》https://mp.weixin.qq.com/s/u7... 一条sql语句慢在哪之抓包剖析https://mp.weixin.qq.com/s/AY... 万答#15，都有哪些状况可能导致MGR服务无奈启动https://mp.weixin.qq.com/s/in... 技术分享 | 为什么MGR一致性模式不举荐AFTERhttps://mp.weixin.qq.com/s/rN... 对于 GreatSQLGreatSQL是由万里数据库保护的MySQL分支，专一于晋升MGR可靠性及性能，反对InnoDB并行查问个性，是实用于金融级利用的MySQL分支版本。 Gitee: https://gitee.com/GreatSQL/Gr... GitHub: https://github.com/GreatSQL/G... Bilibili：https://space.bilibili.com/13... 微信&QQ群：可搜寻增加GreatSQL社区助手微信好友，发送验证信息“加群”退出GreatSQL/MGR交换微信群 QQ群：533341697微信小助手：wanlidbc 本文由博客一文多发平台 OpenWrite 公布！

一、背景 咱们的业务只存近一段时间的数据，因而有大量表须要清理历史数据，目前应用的delete清理数据，存在以下问题。为防止同时反对大量delete，咱们的清理工作只在低峰期串行执行，导致工作过多时须要排队，甚至失败的状况；数据清理应用delete语句，表数据量较大时，对数据库造成很大压力；即便咱们删除了旧数据，已删除的数据仍占据存储空间，底层数据文件并没有立即变小，以至于造成数据空洞。查看MySQL官网文档时，发现了分区表，因而基于官网文档总结一下。 二、什么是分区表？ MySQL逻辑上为一个表，物理上存储在多个文件中，这是 MySQL 反对的性能（5.1 开始）, 8.0 版本只 InnoDB 和 NDB 反对分区表。 三、分区表有啥优缺点？ 长处： 和单个磁盘或文件系统分区相比，能够存储更多的数据。优化查问： where 子句中蕴含分区条件时，能够间接扫描必要的分区。波及聚合函数的查问时，能够很容易地在每个分区上并行处理，最终只需汇总失去后果。对于曾经过期或者不须要保留的数据，能够通过删除与这些数据无关的分区来疾速删除数据。跨多个磁盘来扩散数据查问，以取得更大的查问吞吐量。毛病：新建、删除分区操作的时候，会获取表的MDL锁，这是一把全局锁，可能会对业务产生慢查的影响；分区表在执行alter语句时，比方减少、删除分区，更容易呈现MDL锁抵触，引起慢查等状况；InnoDB分区表不反对外键 四、分区类型 4.1 Range 分区 依据分区表键值的范畴把数据存储到表的不同分区中，实用于以工夫或日期作为分区类型，不便数据清理。 CREATE TABLE employees ( id INT NOT NULL, fname VARCHAR(30), lname VARCHAR(30), hired DATE NOT NULL DEFAULT '1970-01-01', separated DATE NOT NULL DEFAULT '9999-12-31', job_code INT NOT NULL, store_id INT NOT NULL ) PARTITION BY RANGE (store_id) ( PARTITION p0 VALUES LESS THAN (6), PARTITION p1 VALUES LESS THAN (11), PARTITION p2 VALUES LESS THAN (16), PARTITION p3 VALUES LESS THAN (21) ); -- 应用函数将日期转换 CREATE TABLE employees_1 ( id INT NOT NULL, fname VARCHAR(30), lname VARCHAR(30), hired DATE NOT NULL DEFAULT '1970-01-01', separated DATE NOT NULL DEFAULT '9999-12-31', job_code INT NOT NULL, store_id INT NOT NULL ) PARTITION BY RANGE (year(hired)) ( PARTITION p0 VALUES LESS THAN (6), PARTITION p1 VALUES LESS THAN (11), PARTITION p2 VALUES LESS THAN (16), PARTITION p3 VALUES LESS THAN (21) ); -- 应用date 或 datetime 例作为分区例时 可应用 RANGE COLUMNS 对表进行分区 CREATE TABLE employees_2 ( id INT NOT NULL, fname VARCHAR(30), lname VARCHAR(30), hired DATE NOT NULL DEFAULT '1970-01-01', separated DATE NOT NULL DEFAULT '9999-12-31', job_code INT NOT NULL, store_id INT NOT NULL ) PARTITION BY RANGE COLUMNS (hired) ( PARTITION p0 VALUES LESS THAN ('1970-01-01'), PARTITION p1 VALUES LESS THAN ('1971-01-01'), PARTITION p2 VALUES LESS THAN ('1972-01-01'), PARTITION p3 VALUES LESS THAN ('1973-01-01') );小提示： ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。试验环境GreatSQL 8.0.25 InnoDB1.索引下推介绍1.索引下推，英文全称（Index Condition Pushdown）简称 ICP 。2.MySQL5.6 版本推出的用于优化查问的性能。3.某些特定索引条件下，ICP 可缩小存储引擎查问回表的次数。2.实用条件1.当须要拜访全表记录时，ICP 用于 range、ref、eq_ref 和 ref_or_null 拜访办法。2.ICP 能够用于 InnoDB 和 MyISAM 表，包含分区 InnoDB 和 MyISAM 表。3.对于InnoDB表，ICP 仅用于二级索引。ICP 的指标是缩小整行记录读取的次数，从而缩小I/O操作。对于InnoDB 汇集索引，残缺的记录曾经被读取到 InnoDB 缓冲区，在这种状况下应用 ICP 不会缩小I/O。4.虚构列上创立的二级索引，不反对 ICP。5.应用子查问的SQL 不反对 ICP。6.调用存储过程的SQL 不反对 ICP，因为存储引擎无奈调用位于 MySQL Server 中的存储过程。7.触发器 不反对 ICP。3.如何启用ICP 默认是开启的，能够通过下列命令进行敞开、启用、查看# 敞开ICPSET optimizer_switch = 'index_condition_pushdown=off'; # 开启ICPSET optimizer_switch = 'index_condition_pushdown=on';# 查看ICP以后状态show VARIABLES like '%optimizer_switch%'4.ICP 如何工作不应用 ICP 优化时的查问步骤 1.获取下一行，首先读取索引信息，而后依据索引将整行数据读取进去。2.而后通过where条件判断以后数据是否符合条件，合乎返回数据。应用 ICP 优化时的查问步骤 1.获取下一行的索引信息。2.查看索引中存储的列信息是否合乎索引条件，如果合乎将整行数据读取进去，如果不合乎跳过读取下一行。3.用残余的判断条件，判断此行数据是否符合要求，符合要求返回数据5.试验测试表构造如下CREATE TABLE `student` ( `id` int NOT NULL AUTO_INCREMENT COMMENT '自增id', `uid` int NOT NULL COMMENT '学号', `age` int NOT NULL COMMENT '年龄', `name` char(32) NOT NULL COMMENT '姓名', `sex` char(4) NOT NULL COMMENT '性别', `grade` int NOT NULL COMMENT '年级', `class` varchar(32) NOT NULL COMMENT '班级', `major` varchar(64) NOT NULL COMMENT '业余', PRIMARY KEY (`id`), KEY `idx_anm` (`age`,`name`,`major`)) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci 现有一个需要，查问年龄16、姓陈、学习软件工程的同学信息 ...

本文是生产环境中产生死锁的一次事变排查笔记，通过浏览本文你能够理解到： Innodb中罕用的锁有哪些？各种锁之间是兼容还是不兼容的？Update语句的加锁原理是什么？ 上面就跟我一起来还原一下事故现场吧 操作背景MySQL 8.0.20开启主动提交事务（autocommit=1）事务隔离级别可反复度REPEATABLE-READ（RR）操作的表没有主键和索引复现步骤注：客户端一也就是事务一，后文不在阐明的状况下默认 新建一张空白表t,字段只有两个id和name，没有主键 CREATE TABLE `t` ( `id` int DEFAULT NULL, `name` varchar(45) DEFAULT NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci新建客户端一开启新事务一，客户端二开启新事务二 客户端一新增一条数据 insert into t values(1,'1'); Query OK, 1 row affected (0.00 sec)客户端二新增一条数据 insert into t values(2,'2');Query OK, 1 row affected (0.00 sec)客户端一执行更新语句,此时会产生阻塞，期待执行，没有输入后果 update t set name ='update 1' where id =1; 客户端二执行更新语句，此时返回发现死锁，也就是咱们本文要探讨的状况，此时是谁与谁在抢夺资源 update t set name='update2' where id =2;ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction此时客户端一返回响应执行胜利，也就是咱们看到的产生了死锁然而一个数据插入胜利，另一个数据插入失败的状况 ...

什么是MVCC在学习MVCC前，先理解一下以后读和快照读 以后读 比方lock in share mode（共享锁），for update，update，delete，insert（排它锁）这些操作都是一些以后读，以后读的定义就是读取以后数据的最新版本，读取时还要保障其它并发事务不能批改数据，会对读取的记录进行加锁 快照读 不加锁的select就是快照读，即不加锁的非阻塞读，快照读的前提是隔离级别不是串行级别，串行级别下快照读会进化为以后读。快照读的实现是基于多版本并发管制，即MVCC。即快照读可能读取到的数据不肯定是最新版本，而有可能是之前的历史版本 MVCC即多版本并发管制，保留无关已更改行的旧版本的信息以及反对事务性能，例如 并发和回滚，这些信息以回滚段的形式存储在UndoLog中。MVCC就是为了实现读写不抵触不加锁，读也就是快照读，不是以后读 什么是UndoLog回滚日志（撤销日志），MVCC的重要组成部分，单个事务对记录变更操作的记录汇合。如果另一个事务须要查看原始数据满足一致性读，则须要去undolog中检索，UndoLog保留在UndoLog Segments中，UndoLog Segments 保留在Rollback Segments中，回滚段保留在Undo表空间和全局长期表空间中。UndoLog个别是逻辑日志，记录数据的变更版本信息 mvcc实现原理基于隐式字段+UndoLog+Read View实现 UndoLog中的每条记录都有暗藏字段DB_TRX_ID 创立该条记录或者最初批改该条记录的事务IDDB_ROLL_PTR 回滚指针，指向以后这条记录的上一个版本DB_ROW_ID 暗藏的主键UndoLog ，在insert，update，delete 时产生的回滚日志 Read View 可读视图组成 [未提交事务数组]，最大的事务id 可读视图判断规定生成一致性视图规定read-view 由执行时所有未提交事务的id数组（数组里最小的trx_id为min_id）和已创立的事务id（max_id）组成，查问的数据后果依据生成 的read-view做比照失去快照的后果 版本链比对判断规定 如果落在绿色局部（trx_id<min_id） ,示意这个版本是已提交事务生成的，这个事务是可见的如果落在黄色局部（min_id<=trx_id<=max_id）,分两种状况解决 a. 若row的trx_id在数组中，示意这个事务是由还没提交的事务生成的，不可见，以后本人的事务是可见的 b. 若row的trx_id不在数组中，示意这个事务是曾经提交的事务生成的，可见 如果落在红色局部(trx_id>max_id)， 示意这个版本是由未来启动的事务创立的 ，必定不可见对于删除的状况能够认为是update的非凡状况，delete数据的时候会将版本上最新的数据复制一份，而后将trx_id批改成删除操作的trx_id，同时将该条记录的头信息（record header ）里的（deleted_flag）标记位写上true，示意以后记录曾经被删除，在查问时依照下面的规定查到对应的记录，如果deleted_flag标记位为true，意味着数据曾经被删除，则不会被返回。 举例说明MVCC实现原理表阐明t 事务操作表，演示表，undolog日志演示操作表t1 ,辅助表，生成事务id隔离级别可反复读 验证查看数据库隔离级别（只有可反复读和读提交下MVCC无效） 在RR级别下的某个事务对某条记录的第一次快照读会创立一个快照及read-view，将以后零碎沉闷的其它事务记录起来，尔后在调用快照读的时候还是应用的同一个read-view，所以只有以后事务在其它事务更新提交之前应用快照读，那么之后的快照读都是对立个read-view，所以对之后的批改不可见。 在RR级别下，快照读生成read-view时，read-view会记录此时所有其它事务的快照，这些事务对与以后事务都是不可见的，而早于read-view创立的事务都是可见的 而在RC级别下，事务中每次都会生成一个新的read-view和快照，这就是咱们在RC级别下能够看到别的事务提交的更新的起因 总之就是在RC级别下，每个事务都会获取最新的read-view；而在RR级别下，则是同一个事物的第一个selete才会创立快照，之后的快照读都是第一次创立的read-view，都是同一个read-view 上面为不同时刻不同事务时序图 transaction100，200，300 为三个更新事务 select1，2为两个读取事务 Transaction 100Transaction 200Transaction 300select 1select 2begin;begin;begin;begin;begin;update t1 set t1col='t1colval' where id = '1';(辅助表t1中更新数据，生成一个事务ID100) update t1 set t1col='t1colval200' where id = '2';(辅助表t1生成事务ID200) update t set name = 'zuiyu300' where id = '1' ;(第一次更新数据) commit; select name from t where id = '1' ;(第一次读，创立readview[100,200] 300) 此时读出来的后果是name=zuiyu300 update t set name='zuiyu100' where id = '1'; Update t set name ='zuiyu101' where id = '1'; select name from t where id = '1'; (第二次读，持续应用第一次创立的readview[100,200] 300) 此时读出来的后果是name=zuiyu300 commit; update t set name='zuiyu200' where id = '1'; update t set name='zuiyu201' where id = '1'; select name from t where id = '1'; (第三次读，持续应用第一次创立的readview[100,200] 300) 此时读出来的后果是name=zuiyu300select name from t where id = '1';（此时会生成一个readview [200],300）,此时后果name=zuiyu101 commit; commit;commit;第一次读取时 ...

最近在写调试站点https://www.xuebuapp.com/的时候，发现emoji表情放入mysql数据库的时候，不被辨认进去，主动变成????? 符号，不能算是被转码，是不辨认~遇到这种状况其实把数据库编码改一下就行了，刚开始我的数据库编码是utf-8，改成utf8mb4_general_ci或者utf8mb4 都能够，改完保留搞定~

MySQL语法入门（二）数据库加密函数SELECT MD5('hello');-- 5d41402abc4b2a76b9719d911017c592SELECT MD5('HELLO');-- eb61eead90e3b899c6bcbe27ac581660SELECT AES_ENCRYPT('hello', 'key');SELECT AES_DECRYPT(AES_ENCRYPT('hello', 'key'), 'key');-- helloSELECT SHA('hello');-- aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d控制流函数SELECT IF(1 > 2, 3, 4);-- 4SELECT IFNULL(1, 2);-- 1；第一个参数为空返回第二个参数，反之，返回第一个参数SELECT IFNULL(NULL, 2);-- 2SELECT NULLIF(1, 1);-- null；第一个参数和第二个参数相等，返回null，反之，返回第一个参数SELECT NULLIF(1, 2);-- 1;SELECT CASE WHEN 1 THEN 2 ELSE 3 END;-- 2SELECT CASE WHEN 0 THEN 4 ELSE 5 END;-- 5SELECT CASE WHEN 0 THEN 1 WHEN 1 THEN 2 ELSE 3 END;-- 2 SELECT CASE WHEN 0 THEN 1 WHEN 0 THEN 2 ELSE 3 END;-- 3 SELECT CASE 'cat' WHEN 'cat' THEN 1 WHEN 'dog' THEN 2 ELSE 3 END;-- 1 格式化函数和类型转换函数SELECT DATE_FORMAT(NOW(), '%W %D %M %Y %r');-- Tuesday 14th January 2025 01:38:27 PM SELECT TIME_FORMAT('25:11:44', '%h:%i %p');-- 01:11 AMSELECT INET_ATON('192.168.1.11');-- 3232235787；IP地址转成数字SELECT INET_NTOA(3232235787);-- 192.168.1.11；数字转成IP地址SELECT 2 + '23';-- 25SELECT 3 + CAST('11' AS SIGNED);-- 14SELECT 'f' = BINARY 'F';-- 0SELECT 'f' = 'F';-- 1SELECT 'f' = CAST('F' AS BINARY);-- 0SELECT 'f' = CAST('F' AS CHAR);-- 1SELECT CONVERT( '14' , SIGNED);-- 14SELECT CONVERT( 'abc' USING UTF8);-- abc

一、背景简介作为一个DBA难免不了会遇到性能问题，那么咱们遇到性能问题该如何进行排查呢？例如咱们在高并发的业务下，呈现业务响应慢，解决工夫长咱们又该如何动手进行排查，本片文章将剖析io高的状况下如何剖析及定位。 二、环境复现环境配置：本次测试应用128C_512G_4TSSD服务器配置，MySQL版本为8.0.27场景模仿：应用sysbench创立5个表，每个表2亿条数据，执行产生笛卡尔积查问的sql语句，产生io,能够模仿业务压力。首先应用sysbench进行数据压测三、零碎层面底层故障排查Shell> sysbench --test=/usr/local/share/sysbench/oltp_insert.lua --mysql-host=XXX --mysql-port=3306 --mysql-user=pcms --mysql-password=abc123 --mysql-db=sysbench --percentile=99 --table-size=2000000000 --tables=5 --threads=1000 prepare应用sysbench进行模仿高并发 shell> sysbench --test=/usr/local/share/sysbench/oltp_write_only.lua --mysql-host=xxx --mysql-port=3306 --mysql-user=pcms --mysql-password=abc123 --mysql-db=sysbench --percentile=99 --table-size=2000000000 --tables=5 --threads=1000 --max-time=60000 --report-interval=1 --threads=1000 --max-requests=0 --mysql-ignore-errors=all run执行笛卡尔积sql语句 mysql> select SQL_NO_CACHE b.id,a.k from sbtest_a a left join sbtest_b b on a.id=b.id group by a.k order by b.c desc;3.1 查看以后服务器状态shell> toptop - 19:49:05 up 10 days, 8:16, 2 users, load average: 72.56, 40.21, 17.08Tasks: 1288 total, 1 running, 586 sleeping, 0 stopped, 0 zombie%Cpu(s): 19.7 us, 4.2 sy, 0.0 ni, 75.9 id, 1.0 wa, 0.0 hi, 0.2 si, 0.0 stKiB Mem : 53542118+total, 23667507+free, 22735366+used, 71392448 buff/cacheKiB Swap: 0 total, 0 free, 0 used. 23128006+avail Mem 由上可知：目前一分钟负载为72.56，且呈上升趋势，并且存在io压力 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。简介Prometheus 一套开源的监控&报警&工夫序列数据库的组合，通常 Kubernetes 中都会配合 Prometheus 进行监控, 因为Prometheus 自带的图像不够弱小，Grafana 作为 Dashboard 配合Prometheus 作为展现。Grafana 也是能够间接拜访 MySQL 的Performance Schema 作为展现。架构 通过Prometheus 采集 mysql exporter 与 node exporter ,通过 Grafana 作为展现 部署基于docker 形式部署，本文仅作为本地测试展现 1. node_exporter 部署node_exporter 会采集零碎cpu ，内存， 磁盘， 网卡等应用状况，因为mysql 自身并没有采集零碎的相干配置，因而咱们能够通过node_exporter 进行关联cd /opt/node_exporterwget https://github.com/prometheus/node_exporter/releases/download/v0.14.0/node_exporter-0.14.0.linux-amd64.tar.gz -O node_exporter.tar.gz tar -zxf node_exporter.tar.gz配置成零碎服务cat > /etc/systemd/system/node_exporter.service << EOF[Unit]Description=node_exporterDocumentation=https://prometheus.io/After=network.target[Service]Type=simpleUser=prometheus # 零碎用户名称ExecStart=/opt/node_exporter/node_exporterRestart=on-failure[Install]WantedBy=multi-user.targetEOF启动服务systemctl enable node_exportersystemctl start node_exporter查看curl 127.0.0.1:9100/metrics进行验证是否失效 2. mysql_exporter 部署mysql_exporter 通过查问 mysql 的 performance_schema 生成对应的 metric数据库调配一个用户给 exporter CREATE USER 'exporter'@'%' IDENTIFIED BY '123456' WITH MAX_USER_CONNECTIONS 3; GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'%'; flush privileges;docker-compose.ymlversion: '2.1'services: mysqld-exporter: image: prom/mysqld-exporter container_name: mysqld-exporter environment: - DATA_SOURCE_NAME=exporter:123456@(192.168.5.242:3306)/ ports: - "9104:9104" restart: "always"启动 ...

明天在测试库上做一个关联查问时呈现了捞出多余的值的状况，当初换个表名重现一下再解释。 如图所示，现有两张表 user表，通过rid和和role表的id关联role表，只有id和alias字段从图中的数据来看，实践上执行上面的sql后应该呈现下图的后果，一个用户对应一个role，有1条数据 SELECT * from rd_user u, rd_role r where u.rid = r.id where r.id = 123456789012345611 然而实际上执行下面的语句却呈现了2条数据，如图 一开始我被搞懵了，狐疑是本人对join的了解出问题了，百度各种join后确定本人的了解没问题。而后又试了好几种分步查问，还是呈现谬误的后果。最初从新查看表构造时发现一个十分坑爹的点，user表的rid数据类型竟然是varchar ，然而role的id字段是bigint 本人又新建了两张表试了下，发现用varchar和bigint关联在个别状况下是没问题的，然而在一直尝试后发现，当这个字段长度大于16位时（这个论断不太精确），就会呈现上图的状况。于是把user表的rid字段改成bigint后查问出错的问题就解决了。 按理说到这里就完事了，然而我还是放不下，为啥数据库会出错呢？于是又查了会儿材料，有了一些小发现。 在一篇文章中，一个博主呈现了另一种状况：他的是char和int问题， 在执行 select 0 = 'abc'时发现后果是true 依据他的博文写到mysql官网文档说在数字和字符串执行比拟时会主动做转换。 其中，如果varchar是数字+字母的组合，会主动截取后面数字局部，再和数字做比拟。 比方上面这句后果也是true。 select 1 = '1abc'官网文档地址 MySQL :: MySQL 5.7 Reference Manual :: 12.4.2 Comparison Functions and Operators Comparison operations result in a value of 1 (TRUE), 0 (FALSE), or NULL. These operations work for both numbers and strings. Strings are automatically converted to numbers and numbers to strings as necessary. ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。介绍新业务上线的时候通常须要对数据库性能进行压力测试，以确认是否满足需要，明天简略介绍下sysbench的用法： 1.sysbench 是一个开源跨平台的多线程性能测试工具。2.能够用来进行 CPU、内存、磁盘IO、线程、数据库的性能测试。3.目前反对的数据库是 MySQL、Oracle 和 PostgreSQL。装置1.YUM 装置 curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bashsudo yum -y install sysbench2.装置实现后会有一些 lua 脚本 [root@mgr1 src]# ll /usr/share/sysbench/total 132-rwxr-xr-x. 1 root root 1452 May 8 2020 bulk_insert.lua-rw-r--r--. 1 root root 14369 May 8 2020 oltp_common.lua-rwxr-xr-x. 1 root root 1290 May 8 2020 oltp_delete.lua-rwxr-xr-x. 1 root root 2415 May 8 2020 oltp_insert.lua......3.局部lua脚本阐明 insert.lua 单值插入数据bulk_inert.lua 批量插入数据delete.lua 删除数据select.lua 简略主键查问oltp.lua 混合读写测试用法1.sysbench 罕用参数 sysbench [general-options]... --test=<test-name> [test-options]... command--num-threads=N # 创立测试线程的数，默认为1.--max-requests=N # 申请的最大数目，默认为10000，0 代表不限度。--max-time=N # 最大执行工夫，单位是s。默认是0,不限度。--forced-shutdown=STRING # 超过 max-time 的时候会强制中断。默认是off。--thread-stack-size=SIZE # 每个线程的堆栈大小。默认是32K。--init-rng=[on|off] # 在测试开始时是否初始化随机数发生器。默认是off。--test=STRING # 指定测试项目名称。--debug=[on|off] # 是否显示更多的调试信息。默认是off。--validate=[on|off] # 在可能状况下执行验证查看。默认是off。--version=[on|off] # 版本信息。--help=[on|off] # 帮忙信息。2.能够测试的我的项目 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。MyISAM的实用场景越来越少了。随着MySQL 8.0的推出，零碎表曾经全面采纳InnoDB引擎，不再须要MyISAM引擎。另外，MGR中也不反对MyISAM引擎。 因而，基本上能够思考全面禁止应用MyISAM引擎了，问题是，这可行吗？ 答案是必定的，能够做到。 从MySSQL 5.7.8开始，新增一个选项 disabled_storage_engines，只须要设置下即可： disabled_storage_engines = MyISAM这就完满地实现禁用MyISAM的目标了。 另外，这么设置的话，是不会影响MySQL实例初始化的。即使是在MySQL 5.7版本中，零碎表要应用MyISAM引擎，也不会影响生成MyISAM引擎的零碎表。 disabled_storage_engines is disabled and has no effect if the server is started with any of these options: --bootstrap, --initialize, --initialize-insecure, --skip-grant-tables.不过，设置该选项后可能会影响 mysql_upgrade 降级： Setting disabled_storage_engines might cause an issue with mysql_upgrade. For details, see Section 4.4.7, “mysql_upgrade — Check and Upgrade MySQL Tables”.执行 mysql_upgrade 进行降级时可能会报错： mysql_upgrade: [ERROR] 3161: Storage engine MyISAM is disabled(Table creation is disallowed).这时候须要长期敞开该选项，期待降级实现后再从新启用即可。 Enjoy GreatSQL :) ...

mvcc是通过两个暗藏字段来实现的 一个事务删除列 一个事务开始列。 select语句 只会查找版本早于或等于以后版本的事务的数据，这样能够保障事务的读取的行，要么在事务开始前就开始，要么是事务本人操作的数据读取行的删除版本号要么未定义，要么大于事务以后版本号。insert语句 将以后事务的版本记录到插入数据行的事务开始列delete语句 将以后事务版本记录到以后数据行的删除列uodate语句 将以后事务的版本记录到新插入一条数据数据行的事务开始列，同时记录到原数据的删除列MVCC只工作在可反复读和读已提交两个隔离级别 其余的不兼容。串行化是因为会对所有数据行间接加锁 读未提交是因为每次读到都是最新最新数据 不须要事务版本这种来管制

次要做字符集和编码格局的转换（用记事本就行，就是文本转换） 之前那个阿里云服务器是装的mysql8.0，而指标服务器的数据库是mysql5.7mysql5.7不反对utf8mb4_0900_ai_ci字符集，编码格局也不是utf8mb4。 故做以下操作：1.原数据库：转储SQL数据->构造和数据2.替换字符串: 1>字符集替换：utf8mb4_0900_ai_ci -> utf8_general_ci 2>留神下指标数据库的编码格局支不反对原数据库的编码格局，比方原数据库的编码格局是utf8mb4，而指标数据库只反对utf8，那就： 编码格局替换：utf8mb4 -> utf8 3.导入已批改的mysql文件在指标DBMS里建同名新数据库，而后导入刚刚已批改的mysql文件即可

在应用mysql数据库的时候遇到了多种数字的类型，次要有tinyint，smallint，int，bigint这几种类型。 从开发的职场小白到技术大牛，毋庸置疑根本都晓得它们最大的区别必定是长度不同，那么他们有什么区别呢？ 1个字符等于8个字节 tinyint从 -2^7 (-128) 到 2^7 - 1 (123) 的整型数据，unsigned 是从 0 到 2^8 的整型数据，存储大小为 1 字节。 smallint从 -2^15 (-32,768) 到 2^15 – 1 (32,767) 的整型数据，unsigned 是从 0 到 2^16 的整型数据，存储大小为 2 个字节。 int从 -2^31 (-2,147,483,648) 到 2^31 – 1 (2,147,483,647) 的整型数据，unsigned 是从 0 到 2^32 的整型数据，存储大小为 4 个字节。 bigint从 -2^63 (-9223372036854775808) 到 2^63-1 (9223372036854775807) 的整型数据，unsigned 是从 0 到 2^64 的整型数据，存储大小为 8 个字节。 在反对整数值的中央都能够应用bigint类型的，但不是抉择的长度越长越好。就拿人的性别来说，有男女之分，咱们齐全能够应用tinyint来示意，一个字节就能够搞定了，防止资源的节约。 一旦数据类型确定好，每个数字在磁盘上占用空间就固定下来，与数值自身大小毫无关系。

事务事务就是要保障一组数据库操作，要么全副胜利，要么全副失败。在 MySQL 中，事务反对是在引擎层实现的。ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔离性、持久性）隔离性事务并发问题：脏读（dirty read）：一个事务读取了其它事务update后未提交的数据。 不可反复读（non-repeatable read）：一个事务读取了其它事务update或delete后已提交的数据。 幻读（phantom read）：一个事务读取了其它事务新insert曾经提交的数据（前后读取数量不统一）。 事务隔离级别读未提交RU（read uncommitted）：一个事务还没提交时，它做的变更就能被别的事务看到。 读提交RC（read committed）：一个事务提交之后，它做的变更才会被其余事务看到。 可反复读RR（repeatable read）：一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是统一的。 串行化Serial（serializable ）：对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当呈现读写锁抵触的时候，后拜访的事务必须等前一个事务执行实现，能力继续执行。 InnoDB的默认隔离级别是可反复读(repeatable read) 实例mysql> create table T(c int) engine=InnoDB;mysql> insert into T(c) values(1);事务A事务B启动事务A，查问失去值1启动事务B 查问失去值1 将1改为2查问失去值V1 提交事务B查问失去值V2 提交事务A 查问失去值V3 读未提交：V1，V2，V3值都是2 读提交：V1=1，V2=2，V3=2 可反复读：V1=1，V2=1，V3=2（事务A在执行期间看到的数据前后必须是统一的） 串行化：V1=1，V2=1，V3=2（事务 B 执行时会被锁住，直到事务 A 提交后，才能够继续执行） 视图在实现上，数据库外面会创立一个MVCC视图，拜访的时候以视图的逻辑后果为准。读未提交RU：间接返回记录上的最新值，没有视图概念。 查看级别： 读未提交：间接返回记录上的最新值，没有视图概念。 读提交RC：在每个 SQL 语句开始执行的时候创立的，能够看到另外一个事务曾经提交的内容。 可反复读RR：在事务启动时创立的，整个事务存在期间都用这个视图。 串行化Serial：间接用加锁的形式来防止并行拜访，没有视图概念。 配置形式：将启动参数 transaction-isolation 的值设置成 READ-COMMITTED 查看级别：show variables like 'transaction_isolation' 注：Mysql5.7前的版本为show variables like 'tx_isolation'; 事务隔离的实现MVCC：多版本并发管制，通过undo log(回滚日志)版本链和read-view（读视图）实现事务隔离在 MySQL 中，每条记录在更新的时候除了记录变更记录，还会记录一条变更相同的回滚操作记录，前者记录在redo log，后者记录在undo log。 记录上的最新值，通过回滚操作，都能够失去前一个状态的值。 ...

本题应用的是 MySQL8.0，没有在 MySQL5.6 版本中测验过，不保障正确。 题目题目起源：超过经理支出的员工 经理也属于员工。每个员工都有一个 Id，此外还有一列对应员工的经理的 Id。查问支出超过他们经理的员工的姓名 create table employee ( id int, name varchar(255), salary int, managerId int);insert into employee values (1, 'Joe', 70000, 3),(2, 'Henry', 80000, 4),(3, 'Sam', 60000, null),(4, 'Max', 90000, null);SQLselect employee.name from employee left join employee eon employee.managerId = e.idwhere employee.salary > e.salary;解析managerId 是经理 id ，同时经理也是员工，也就是说没有 managerId 是普通员工，有 managerId 的是经理。 所以将 employee 自连贯，连贯条件是 employee.managerId = e.id ，就能够把普通员工和经理连接起来了。 而后在筛选出 employee.salary > e.salary 的员工就行了。 更多解题参考：https://github.com/astak16/bl... ...

文章首发地址 数据库的创立应用间接创立数据库 create database community;查看以后在哪个库里边 select database();进入库的操作 use community;判断是否存在,如果不存在则创立数据库 create database if not exists community; 创立数据库并指定字符集为 utf-8 create database community default character set utf-8; 查看某个库是什么字符集 show create database community;查看以后mysql应用的字符集 show variables like 'character%'; mysql创立表罕用de数据类型mysql常见数据类型 <1>整数型 类型 大小 范畴（有符号） 范畴（无符号unsigned） 用处 TINYINT 1 字节 (-128，127) (0，255) 小整数值 SMALLINT 2 字节 (-32768，32767) (0，65535) 大整数值 MEDIUMINT 3 字节 (-8388608，8388607) (0，16777215) 大整数值 INT 4 字节 (-2147483648，2147483647) (0，4294967295) 大整数值 BIGINT 8 字节 （） (0，2的64次方减1) 极大整数值<2>浮点型 FLOAT(m,d） 4 字节 单精度浮点型 备注：m代表总个数，d代表小数位个数 DOUBLE(m,d） 8 字节 双精度浮点型 备注：m代表总个数，d代表小数位个数 <3>定点型 DECIMAL(m,d） 依赖于M和D的值 备注：m代表总个数，d代表小数位个数 <4>字符串类型 类型 大小 用处 CHAR 0-255字节 定长字符串 VARCHAR 0-65535字节 变长字符串 TINYTEXT 0-255字节 短文本字符串 TEXT 0-65535字节 长文本数据 MEDIUMTEXT 0-16777215字节 中等长度文本数据 LONGTEXT 0-4294967295字节 极大文本数据 char的优缺点：存取速度比varchar更快，然而比varchar更占用空间 varchar的优缺点：比char省空间。然而存取速度没有char快 <5>工夫型 数据类型 字节数 格局 备注 date 3 yyyy-MM-dd 存储日期值 time 3 HH:mm:ss 存储时分秒 year 1 yyyy 存储年 datetime 8 yyyy-MM-dd HH:mm:ss 存储日期+工夫 timestamp 4 yyyy-MM-dd HH:mm:ss 存储日期+工夫，可作工夫戳mysql创立表语法 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。如何在多个数据中心部署多套MGR集群，并实现故障疾速切换。上篇文章介绍了如何在多数据中心部署多套MGR集群，并构建集群间的复制通道。这样一旦主AZ不可用时，在校验完数据后，就能够切换到备用AZ的MGR集群，十分不便。 本文咱们持续深刻介绍如何利用 Async Replication Auto failover 实现故障主动转移的。 1、什么是Async Replication Auto failover从MySQL 8.0.22开始，推出一个新个性"Async Replication Auto failover"，当MGR集群产生故障时，其从库能够更不便的实现疾速主动切主。直译过去是“异步复制主动故障转移”，但实际上它也是反对半同步复制场景的。 You can use MySQL Server's new asynchronous connection failover mechanism to automatically establish an asynchronous (source to replica) replication connection to a new source after the existing connection from a replica to its source fails. The connection fails over if the replication I/O thread stops due to the source stopping or due to a network failure. The asynchronous connection failover mechanism can be used to keep a replica synchronized with multiple MySQL servers or groups of servers that share data. To activate asynchronous connection failover for a replication channel set SOURCE_CONNECTION_AUTO_FAILOVER=1 on the CHANGE MASTER TO statement for the channel, and set up a source list for the channel using the asynchronous_connection_failover_add_source and asynchronous_connection_failover_delete_source functions.具体介绍见官网文档 17.4.9 Switching Sources with Asynchronous Connection Failover ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。0. 内容提纲运行环境部署MGR A&B部署MGR A、B之间的复制通道几个注意事项如何在多个数据中心部署多套MySQL MGR集群以便疾速切换。在金融利用场景下，常常会要求在同城多核心部署高可用数据库架构，以期实现在产生故障时能达到疾速切换的指标。 在同一个数据中心内，能够部署MGR集群，就能够实现疾速灵便切换。 而即使是在同城，跨数据中心时，网络条件好的话，提早可能也在 1ms 之内。这种网络条件下，如果要在同城多核心部署MGR集群也是能够尝试的（如果业务并发量不是特地高的话），但思考到多数据中心间有较大概率会呈现光缆被挖断等危险，所以还是不倡议这么做。 因而，最好还是在同一个数据中心内部署一套独立的MGR集群，再通过主从复制（replication）形式（能够是异步复制或半同步复制），把数据复制一份到另一个数据中心内的MGR集群里，这样一旦主机房出现异常时，就能够疾速切换到备用机房了，并且不放心数据库的高可用保障等级。 下面该计划的架构示意图。 接下来一起来实现这个架构计划的施行。 1. 运行环境本次采纳3个节点部署这套架构，各节点用处阐明见下 每个节点上都运行两个实例，别离是3306、4306端口，其中3306端口的实例形成MGR A集群，4306端口的实例形成MGR B集群。 除了MySQL官网社区版本外，如果想体验更牢靠、稳固、高效的MGR，举荐应用GreatSQL版本。本文采纳GreatSQL 8.0.22版本，对于这个版本的阐明详见 GreatSQL，打造更好的MGR生态。 部署MGR A&B依照惯例形式部署MGR即可，上面是一份要害配置参考：group_replication_single_primary_mode=ONlog_error_verbosity=3group_replication_bootstrap_group=OFF group_replication_transaction_size_limit=<默认值150MB，但倡议调低在20MB以内，不要应用大事务>group_replication_communication_max_message_size=10Mgroup_replication_flow_control_mode=“DISABLED” #官网版本的流控机制不太正当，其实能够思考敞开group_replication_exit_state_action=READ_ONLYgroup_replication_member_expel_timeout=5 #如果网络环境不好，能够适当调高slave_parallel_type=LOGICAL_CLOCKslave_parallel_workers=128 #能够设置为逻辑CPU数量的2-4倍binlog_transaction_dependency_tracking=writesettransaction_write_set_extraction=XXHASH64slave_checkpoint_period=2更多对于MGR以及复制的配置参考这份指南：MGR最佳实际。 启动MGR A，确认工作失常： [root@GreatSQL mgrA-1][(none)]> select * from performance_schema.replication_group_members;+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+| group_replication_applier | 5499a6cb-91cb-11eb-966f-525400e802e2 | mgrA-1 | 3306 | ONLINE | PRIMARY | 8.0.22 || group_replication_applier | ec2fcbeb-976c-11eb-a652-525400e2078a | mgrA-2 | 3306 | ONLINE | SECONDARY | 8.0.22 || group_replication_applier | edfbdeda-91c8-11eb-a3c6-525400fb993a | mgrA-3 | 3306 | ONLINE | SECONDARY | 8.0.22 |+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+[root@GreatSQL mgrA-1][(none)]> select @@global.group_replication_group_name;+---------------------------------------+| @@global.group_replication_group_name |+---------------------------------------+| f195537d-19ac-11eb-b29f-5254002eb6d6 |+---------------------------------------+用同样的办法，再部署MGR B，并确认工作失常： ...

1.Error Log记录MySQL运行过程中的Error、Warning、Note等信息，零碎出错或者某条记录出问题能够查看Error日志。MySQL的谬误日志默认以hostname.err寄存在MySQL的日志目录，能够通过以下语句查看默认装置时，谬误日志通常在配置文件（my.cnf）中 mysqld 局部的 log-error 配置项进行设置；利用 MySQL 零碎变量 log_error 能够查看谬误日志的文件名批改谬误日志的地址能够在 my.cnf 中增加--log-error = [filename]来开启mysql谬误日志。配置如下： log_error = /data/mysql_data/error.log2.Slow LogMySQL 慢查问日志（slow query log）记录了执行工夫超过指定阈值的 SQL 语句，能够用于监控须要执行优化的查问语句。如果启用了慢查问日志，任何执行工夫超过 long_query_time 并且执行次数达到 min_examined_row_limit 次的查问语句都会被记录到慢查问日志中。查看日志性能是否开启：show variables like "%slow%";援用slow_query_log 配置为ON ， 阐明开启慢日志查看下默认设置的慢查问的工夫：show variables like "%long_query%"; 查看一下日志文件的输入： 对于慢查问日志的剖析，举荐应用 mysqldumpslow 或者 pt-query-digest 工具 3.Relay LogMySQL 中继日志（relay log）只存在于主从复制构造中的从节点上，用于保留主节点传输过去的数据变更事件，而后将这些事件利用于从节点。中继日志与二进制日志相似，也是由一组带编号的文件组成；同时还蕴含了一个索引文件，记录了所有曾经应用过的中继日志文件。中继日志文件默认寄存在数据目录中。 其中 relay_log 和 relay_log_index 别离对应为中继日志的文件名和索引文件名。 中继日志文件的格局和二进制日志文件的格局雷同，因而也能够应用 mysqlbinlog 工具进行读取 4.Binlog什么是binlog binlog记录了数据库表构造和表数据变更，比方update/delete/insert/truncate/create，它不会记录selectbinlog长什么样 binlog咱们能够简略了解为：存储着每条变更的SQL语句默认状况下binlog日志是二进制格局，无奈间接查看，能够应用mysqlbinlog来查看，mysqlbinlog是mysql官网提供的一个binlog查看工具。binlog个别用来做什么 次要有两个作用：复制和复原数据1.MySQL在公司应用的时候往往都是一主多从构造的，从服务器须要与主服务器的数据保持一致，这就是通过binlog来实现的2.数据库的数据被干掉了，咱们能够通过binlog来对数据进行复原。因为binlog记录了数据库表的变更，所以咱们能够用binlog进行复制(主从复制)和复原数据。5.Redo Log什么是redo logupdate table set name='ws' where id = 3援用MySQL执行这条SQL语句，必定是先把id=3的这条记录查出来，而后将name字段给改掉。这没问题吧？援用实际上Mysql的根本存储构造是页(记录都存在页里边)，所以MySQL是先把这条记录所在的页找到，而后把该页加载到内存中，将对应记录进行批改。问题1：如果在内存中把数据改了，还没来得及落磁盘，而此时的数据库挂了怎么办？显然这次更改就丢了。redo log 的作用其实写redo log的时候，也会有buffer，是先写buffer，再真正落到磁盘中的。至于从buffer什么时候落磁盘，会有配置供咱们配置。援用redo log的作用是当咱们批改的时候，写完内存了，但数据还没真正写到磁盘的时候。此时咱们的数据库挂了，咱们能够依据redo log来对数据进行复原。援用因为redo log是程序IO，所以写入的速度很快，并且redo log记录的是物理变化（xxxx页做了xxx批改），文件的体积很小，复原速度很快。援用什么时候开释 ...

题目题目起源：回升的温度 形容：查找与之前（昨天）日期相比温度更高的所有日期的 id 。 应用的是 MySQL8.0，没有在 MySQL5.6 版本中测验过，不保障正确。 create table weather ( id int primary key auto_increment, recordDate date, temperature int);insert into weather(recordDate, temperature) values('2015-01-01', 10),('2015-01-02', 25),('2015-01-03', 20),('2015-01-04', 30);SQL：办法一select weather.id from weather join weather w1on datediff(weather.recordDate, w1.recordDate) = 1and weather.temperature > w1.temperature;解析只有一张表，当初要找出明天温度比昨天温度高的日期 id 。 所以须要用自连贯，也就是把 weather 和 weather 进行本身连贯。 在自连之后，须要将自连后的表取个别名 w1 ，如果不取别名的话，两个 weather 表名会抵触。这里把 weather 作为明天表， w1 作为昨天表。 两表自连之后须要有连贯条件，连贯条件是 明天和昨天的日期。 MySQL 提供了datediff 函数，用来比拟两个日期之间的时间差，如果两个工夫之间相差 1 天，那么就是明天和做题。 最初在筛选出明天的温度高于昨天温度的数据。 SQL：办法二select weather.id from weather join weather w1 on weather.recordDate = adddate(w1.recordDate, interval 1 day) and weather.temperature > w1.temperature;解析思路和办法一的思路是一样的，区别在于计算明天和昨天的办法不一样。 ...