Mysql

1.命名标准数据库表名、字段名、索引名等都须要命名标准，可读性高(个别要求用英文)，让他人一看命名，就晓得这个字段示意什么意思。 比方一个表的账号字段，反例如下： acc_no,1_acc_no,zhanghao正例： account_no,account_number表名、字段名必须应用小写字母或者数字，禁止应用数字结尾，禁止应用拼音，并且个别不应用英文缩写。主键索引名为pk_字段名；惟一索引名为uk_字段名；一般索引名则为idx_字段名。2.抉择适合的字段类型设计表时，咱们须要抉择适合的字段类型，比方： 尽可能抉择存储空间小的字段类型，就如同数字类型的，从tinyint、smallint、int、bigint从左往右开始抉择小数类型如金额，则抉择 decimal，禁止应用 float 和 double。如果存储的字符串长度简直相等，应用 char 定长字符串类型。varchar是可变长字符串，不事后调配存储空间，长度不要超过5000。如果存储的值太大，倡议字段类型批改为text，同时抽出独自一张表，用主键与之对应。同一表中，所有varchar字段的长度加起来，不能大于65535. 如果有这样的需要，请应用TEXT/LONGTEXT 类型。3. 主键设计要正当主键设计的话，最好不要与业务逻辑有所关联。有些业务上的字段，比方身份证，尽管是惟一的，一些开发者喜爱用它来做主键，然而不是很倡议哈。主键最好是毫无意义的一串独立不反复的数字，比方UUID，又或者Auto_increment自增的主键，或者是雪花算法生成的主键等等; 4. 抉择适合的字段长度先问大家一个问题，大家晓得数据库字段长度示意字符长度还是字节长度嘛？ 其实在mysql中，varchar和char类型示意字符长度，而其余类型示意的长度都示意字节长度。比方char(10)示意字符长度是10，而bigint（4）示意显示长度是4个字节，然而因为bigint理论长度是8个字节，所以bigint（4）的理论长度就是8个字节。咱们在设计表的时候，须要充分考虑一个字段的长度，比方一个用户名字段（它的长度5~20个字符），你感觉应该设置多长呢？能够思考设置为 username varchar（32）。字段长度个别设置为2的幂哈（也就是2的n次方）。’; 5，优先思考逻辑删除，而不是物理删除什么是物理删除？什么是逻辑删除？ 物理删除：把数据从硬盘中删除，可开释存储空间逻辑删除：给数据增加一个字段，比方is_deleted，以标记该数据曾经逻辑删除。物理删除就是执行delete语句，如删除account_no =‘666’的账户信息SQL如下： delete from account_info_tab whereaccount_no ='666';逻辑删除呢，就是这样： update account_info_tab set is_deleted = 1 where account_no ='666';为什么举荐用逻辑删除，不举荐物理删除呢？ 为什么不举荐应用物理删除，因为复原数据很艰难物理删除会使自增主键不再间断外围业务表 的数据不倡议做物理删除，只适宜做状态变更。6. 每个表都须要增加这几个通用字段如主键、create_time、modifed_time等表必备一般来说，或具备这几个字段： id：主键，一个表必须得有主键，必须create_time：创立工夫，必须modifed_time/update_time: 批改工夫，必须，更新记录时，须要更新它version : 数据记录的版本号，用于乐观锁，非必须remark ：数据记录备注，非必须modified_by :批改人，非必须creator ：创建人，非必须 7. 一张表的字段不宜过多咱们建表的时候，要牢记，一张表的字段不宜过多哈，个别尽量不要超过20个字段哈。笔者记得上个公司，有搭档设计开户表，加了五十多个字段。。。 如果一张表的字段过多，表中保留的数据可能就会很大，查问效率就会很低。因而，一张表不要设计太多字段哈，如果业务需要，切实须要很多字段，能够把一张大的表，拆成多张小的表，它们的主键雷同即可。 当表的字段数十分多时，能够将表分成两张表，一张作为条件查问表，一张作为具体内容表 (次要是为了性能思考)。 8. 尽可能应用not null定义字段如果没有非凡的理由， 个别都倡议将字段定义为 NOT NULL 。 为什么呢？ 首先， NOT NULL 能够防止出现空指针问题。其次，NULL值存储也须要额定的空间的，它也会导致比拟运算更为简单，使优化器难以优化SQL。NULL值有可能会导致索引生效如果将字段默认设置成一个空字符串或常量值并没有什么不同，且都不会影响到应用逻辑， 那就能够将这个字段设置为NOT NULL。9. 设计表时，评估哪些字段须要加索引首先，评估你的表数据量。如果你的表数据量只有一百几十行，就没有必要加索引。否则设计表的时候，如果有查问条件的字段，个别就须要建设索引。然而索引也不能滥用： 索引也不要建得太多，个别单表索引个数不要超过5个。因为创立过多的索引，会升高写得速度。区分度不高的字段，不能加索引，如性别等索引创立完后，还是要留神防止索引生效的状况，如应用mysql的内置函数，会导致索引生效的索引过多的话，能够通过联结索引的话形式来优化。而后的话，索引还有一些规定，如笼罩索引，最左匹配准则等等。。假如你新建一张用户表，如下： CREATE TABLE user_info_tab ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_id` int(11) NOT NULL, `age` int(11) DEFAULT NULL, `name` varchar(255) NOT NULL, `create_time` datetime NOT NULL, `modifed_time` datetime NOT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;对于这张表，很可能会有依据user_id或者name查问用户信息，并且，user_id是惟一的。因而，你是能够给user_id加上惟一索引，name加上一般索引。 ...

FIND_IN_SET(str,strlist) 官网阐明 Returns a value in the range of 1 to N if the string str is in the string list strlist consisting of N substrings.A string list is a string composed of substrings separated by , characters. If the first argument is a constant string and the second is a column of type SET, the FIND_IN_SET() function is optimized to use bit arithmetic. Returns 0 if str is not in strlist or if strlist is the empty string. Returns NULL if either argument is NULL. This function does not work properly if the first argument contains a comma (,) character.重点阐明： ...

事务数据筹备 -- 创立数据表CREATE TABLE account ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(10), balance DOUBLE);-- 增加数据INSERT INTO account (name, balance) VALUES ('张三', 1000), ('李四', 1000);概述在理论的开发过程中，一个业务操作如：转账，往往是要屡次拜访数据库能力实现的。转账是一个用户扣钱，另一个用户加钱。如果其中有一条 SQL 语句出现异常，这条 SQL 就可能执行失败。 事务执行是一个整体，所有的 SQL 语句都必须执行胜利。如果其中有 1 条 SQL 语句出现异常，则所有的 SQL 语句都要回滚，整个业务执行失败。 代码演示 /* 模仿转账的操作 */-- 张三账号-500update account set balance = balance - 500 where name = '张三';-- 李四账号+500update account set balance = balance + 500 where name = '李四';假如当张三账号上-500 元,服务器解体了。李四的账号并没有+500 元，数据就呈现问题了。咱们须要保障其中 一条 SQL 语句呈现问题，整个转账就算失败。只有两条 SQL 都胜利了转账才算胜利。这个时候就须要用到事务. ...

多表查问筹备数据 -- 创立部门表create table dept( id int primary key auto_increment, name varchar(20));-- 向部门表增加数据insert into dept (name) values ('开发部'), ('市场部'), ('财务部');-- 创立员工表create table emp ( id int primary key auto_increment, name varchar(10), gender char(2), salary double, join_date date, dept_id int, foreign key (dept_id) references dept(id) -- 外键，关联部门表主键);-- 向员工表中增加数据insert into emp (name, gender, salary, join_date, dept_id) values('孙悟空','男',7200,'2013-02-24',1),('猪八戒','男',3600,'2010-12-02',2),('唐僧','男',9000,'2008-08-08',2),('白骨精','女',5000,'2015-10-07',3),('蜘蛛精','女',4500,'2011-03-14',1);分类 内连贯用右边表的记录去匹配左边表的记录，如果符合条件的则显示。如：从表.外键=主表.主键。 内连贯也分为两个：隐式内连贯 and 显示内连贯。 隐式内连贯看不到关键字JOIN，条件应用WHERE指定 SELECT 字段名 FROM 左表, 右表 WHERE 条件;代码演示 select * from emp, dept where emp.`dept_id` = dept.`id`;显示内连贯应用INNER JOIN ... ON关键字的语句（INNER能够省略） ...

数据库表的束缚概述对表中的数据进行限度，保证数据的正确性、有效性和完整性。一个表如果增加了束缚，不正确的数据将无奈插入到表中。束缚在创立表的时候增加比拟适合。 分类束缚名束缚关键字主键primary key惟一unique非空not null外键foreign key查看束缚check 注：mysql 不反对主键束缚作用用来惟一标识数据库中的每一条记录。 哪个字段应该作为表的主键？通常不必业务字段作为主键，独自给每张表设计一个 id 的字段，把 id 作为主键。主键是给数据库和程序应用 的，不是给最终的客户应用的。所以主键有没有含意没有关系，只有不反复，非空就行。 如：身份证，学号不倡议做成主键 主键的特点惟一且非空一张表只能有一个主键格局在创立表的时候给字段增加主键 字段名 字段类型 PRIMARY KEY在已有表中增加主键 ALTER TABLE 表名 ADD PRIMARY KEY(字段名);删除主键 ALTER TABLE 表名 DROP PRIMARY KEY;代码演示 -- 创立表学生表 student01, 蕴含字段(id, name, age)将 id 做为主键create table student01 ( id int primary key, -- id为主键 name varchar(20), age int);-- 删除student01下面的主键alter table student01 drop primary key;-- 从新为表student01增加主键alter table student01 add primary key(id);主键自增主键如果让咱们本人增加很有可能反复,咱们通常心愿在每次插入新记录时,数据库主动生成主键字段的值 AUTO_INCREMENT： 示意主动增长，但字段类型必须是整数类型默认 AUTO_INCREMENT 的开始值是 1，如果心愿批改起始值,请应用下列 SQL 语法 ...

MySQL-DQL语句查问不会对数据库中的数据进行批改.只是一种显示数据的形式简略查问查问表所有数据 SELECT * FROM 表名;查问指定列的数据 SELECT 字段名1, 字段名2, 字段名3 ... FROM 表名;别名查问对列指定别名，而后进行查问 SELECT 字段名1 AS 别名, 字段名2 AS 别名, 字段名3 AS 别名 ... FROM 表名;对列和表同时指定别名，而后进行查问 SELECT 字段名1 AS 别名, 字段名2 AS 别名, 字段名3 AS 别名 ... FROM 表名 AS 表别名;代码演示 -- 对列指定别名，而后进行查问select name as '名字', age as '年龄' from students;-- 对列和表同时指定别名，而后进行查问select st.name as '姓名', st.age as '年龄' from students as st;革除反复值应用关键字DISTINCT，去除查问后果中的反复数据 SELECT DISTINCT 字段名 FROM 表名;代码演示 -- 查问指定列的所有记录，包含反复后果select age from human;-- 查问指定列的所有记录，去除反复后果select distinct age from human;查问后果参加运算某列数据和固定值运算 ...

title: MySQL-DML语句date: 2020-11-18 19:22:41tags: - MySQL- 数据库categories: - MySQL- 温习cover: https://gitee.com/jasonM4A1/pictureHost/raw/master/20201117194600.jpgMySQL-DML语句DML操作表中的数据插入字段形式一：(这种键值对的形式，适宜给所有字段赋值，也适宜给局部字段赋值) INSERT INTO 表名 (字段名1, 字段名2, 字段名3...) VALUES (值1, 值2, 值3...);形式二：（这种匿名间接赋值的形式，只能齐全给所有的字段进行赋值） INSERT INTO 表名 VALUES (值1, 值2, 值3...);注意事项： 插入的数据应与字段的数据类型雷同数据的大小应在列的规定范畴内，例如：不能将一个长度为 80 的字符串退出到长度为 40 的列中。在 values 中列出的数据地位必须与被退出的列的排列地位绝对应。在 mysql 中能够应用 value，但不倡议使 用，性能与 values 雷同。字符和日期型数据应蕴含在单引号中。MySQL 中也能够应用双引号做为分隔符。不指定列或应用 null，示意插入空值。代码演示 -- 给所有的字段都赋值insert into students (id, name, age, gender) values (1, 'Jason', 21, '男');-- 给所有的字段匿名间接赋值insert into students values (2, 'Charlie', 22, '男');-- 给局部字段赋值insert into students (id, gender) values (3, '女');蠕虫复制概述 ...

MySQL-DDL语句DDL操作数据库创立数据库创立数据库 CREATE DATABASE 数据库名;判断数据是否存在，不存在则创立数据库 CREATE DATABASE IF NOT EXISTS 数据库名;创立数据库并指定其默认字符集 CREATE DATABASE 数据库名 CHARACTER SET 字符集名;代码演示 -- 间接创立一个名为dataOne的数据库create database dataone;-- 判断数据库datatwo是否存在，如果不存在，则创立一个名为dataTwo的数据库create database if not exists datatwo;-- 创立一个名为dataThree、默认字符集为gbk的数据库create database datathree default character set gbk;查看数据库查看总共有哪些数据库 SHOW DATABASES;查看指定数据库的定义信息 SHOW CREATE DATABASE 数据库名;代码演示 -- 查看所有的数据库show databases;-- 查看名字为mysql的数据库的定义信息show create database mysql;批改数据库批改数据库的默认字符集 ALTER DATABASE 数据库名 DEFAULT CHARACTER SET 字符集名;代码演示 -- 批改名字为liboshuai的数据库的默认字符集为utf8alter database liboshuai default character set utf8;删除数据库删除指定的数据库。 DROP DATABASE 数据库名;代码演示 -- 删除名字为data的数据库drop database data;应用数据库查看正在应用的数据库 SELECT DATABASE();切换到、并应用指定的数据库 ...

MySql根底Java中数据贮存形式比照贮存形式长处毛病内存速度快不能永恒保留，数据的贮存是长期的文件数据可永恒保留操作数据不不便数据库1. 数据可永恒保留2.查问速度快3. 对数据的治理不便占用资源，有的数据库须要购买什么是数据库存储数据的仓库实质上是一个文件系统，还是以文件的形式存在在服务器的电脑上的。应用通过的【SQL语句】对所有的关系型数据库进行数据管理。常见的数据库 下面是市场上前20位的数据库排行榜，上面我对咱们工作中可能会接触到的一些数据库进行简略的介绍。 MySql：开源收费的数据库，小型的数据库。起初 Sun 公司收买了 MySQL，而 Sun 公司又被 Oracle 收买，现隶属于Oracle公司。MySQL6.x 版本也开始免费。Oracle：付费的大型数据库，价格较高，Oracle公司的产品。DB2：IBM公司的付费数据库产品，罕用于银行零碎中。SQL Server：MicroSoft公司付费的中型数据库。大学中教科书应用的数据库，C#、net等语言常应用。SQLite：嵌入式的小型数据库，利用在手机端，如：Android。MySql的装置与卸载MySQL5.7下载、装置和配置 - 简书 (jianshu.com) 卸载mysql时，如何卸载洁净！ - 隋雪儿吖 - 博客园 (cnblogs.com) MySql启动与登录启动MySqlMySQL 服务器启动形式有两种： 通过服务的形式主动启动 通过【windows powerShell】输出命令services.msc，关上【服务】。 在【服务】窗口中，输出m找到【MySql】一项，并将【启动类型】设置为【主动】。 手动启动的形式 以【管理员】的形式关上【windows powerShell】 输出命令net start <mysql服务名称>，启动【MySql】服务。如果须要手动敞开，输出net stop <mysql服务名称>既可。 登录MySqlMySQL 是一个须要账户名明码登录的数据库，登陆后应用，它提供了一个默认的 root 账号，应用装置时设置的明码即可登录。 登录格局一：输出mysql -u用户名 -p明码，间接回车既可（登录失败，能够为用户名或明码加上""）。 登录格局二：输出mysql -u用户名 -p回车，而后更平安的输出明码，最初回车既登录（登录失败，能够为用户名加上""）。 登录格局三：输出mysql -h数据库ip地址 -u用户名 -p明码，而后回车（登录失败，能够为ip地址、用户名或明码加上""）。 登录格局四：输出mysql --host=数据库ip地址 --user=用户名 --password=明码，而后回车（登录失败，能够为ip地址、用户名或明码加上""）。 退出Mysql退出格局一：输出exit，而后回车既可 退出格局二：输出quit，而后回车既可 MySql目录构造MySql下的目录或文件形容bin外面贮存着所有MySql可执行的文件，如：mysql.exebin/MySQLInstanceConfig.exe数据库的配置向导，在装置时呈现的内容dataMySql自带的数据库所在的目录my.inimysql 的配置文件，个别不倡议去批改。C:\ProgramData\MySQL\MySQL Server 5.5\data咱们本人创立的数据库所在的文件夹数据库管理系统、数据库和表的关系一个数据库服务器蕴含多个数据库一个数据库蕴含多张表一张表蕴含多条记录MySql数据类型罕用的数据类型类型名称类型阐明int整型double浮点型varchar字符串型date日期类型。格局为yyyy-MM-dd，只有年月日，没有时分秒具体的数据类型类型名称类型阐明tinyint微整型：很小的整数（占8位二进制）smallint小整型：小的整数（占16位二进制）mediumint中整型：中等长度的整数（占24位二进制）int（integer）整型：整数类型（占32位二进制）float单精度浮点数，占4个字节double双精度浮点数，占8个字节time示意工夫类型date示意日期类型datetime同时能够示意日期和工夫类型char（m）固定长度的字符串，无论应用几个字符串都占满全副，M为0~255之间的整数varchar（m）可变长度的字符串，应用几个字符串就占用几个，M为0~65535之间的整数tinyblob容许长度0~255字节blob容许长度0~65535字节mediumblob容许长度0~167772150字节longblob容许长度0~4294967295字节tinytext容许长度0~255字节text容许长度0~65535字节mediumtext容许长度0~167772150字节longtext容许长度0~4294967295字节MySQL运算符运算符阐明\>、<、<=、>=、=、<><>在 SQL 中示意不等于，在 mysql 中也能够应用!= 没有==BETWEEN...AND在一个范畴之内，如：between 100 and 200 相当于条件在 100 到 200 之间，包头又包尾IN(汇合)汇合示意多个值，应用逗号分隔LIKE '张%含糊查问（%匹配任意多个字符串，_匹配一个字符）IS NULL查问某一列为 NULL 的值，注：不能写=NULLand 或 &&与，SQL 中倡议应用前者，后者并不通用。or 或 \\ 或not 或 ！非SQL语句SQL概述Structured Query Language——结构化查询语言通用的数据库操作语言，是一种所有关系型数据库的查问标准，不同的数据库都反对。但不同的数据库 SQL 语句有一些区别。SQL分类SQL语句粗略的能够分为四大类： ...

前文回顾：实现一个简略的Database1(译文） 译注：cstsck在github保护了一个简略的、相似sqlite的数据库实现，通过这个简略的我的项目，能够很好的了解数据库是如何运行的。本文是第二篇，次要是实现数据库的前端组件，编译器与虚拟机局部性能 Part 2 世界上最简略的SQL编译器与虚拟机咱们正在实现一个sqlite的克隆版本。sqlite的前端是SQL编译器，编译器用来解析字符串并输入一个外部的示意，叫做字节码。 这些字节码被传到虚拟机（virtual machine），在虚拟机中，字节码将被执行。 SQLite Architecture (https://www.sqlite.org/arch.html) 像这样把事件分成两个步骤（SQL编译和虚拟机）有以下两个长处： 缩小各个局部的复杂性（例如：虚拟机不必关怀输出语句语法错误）容许只编译通用查问一次，而后对生成的字节码进行缓存，以此来晋升性能有了这些想法，让咱们来重构主函数，在程序中反对了两个新的关键字： 译注：上面代码中行结尾加减号是绝对与第一局部（part 1）的实现，减少或者删除的代码。代码对main()重构以适宜辨认新关键字，在第一局部中，main()函数只能辨认“.exit”关键字，也就是程序退出命令。 int main(int argc, char* argv[]) { InputBuffer* input_buffer = new_input_buffer(); while (true) { print_prompt(); read_input(input_buffer);- if (strcmp(input_buffer->buffer, ".exit") == 0) {- exit(EXIT_SUCCESS);- } else {- printf("Unrecognized command '%s'.\n", input_buffer->buffer);+ if (input_buffer->buffer[0] == '.') {+ switch (do_meta_command(input_buffer)) {+ case (META_COMMAND_SUCCESS):+ continue;+ case (META_COMMAND_UNRECOGNIZED_COMMAND):+ printf("Unrecognized command '%s'\n", input_buffer->buffer);+ continue;+ } }++ Statement statement;+ switch (prepare_statement(input_buffer, &statement)) {+ case (PREPARE_SUCCESS):+ break;+ case (PREPARE_UNRECOGNIZED_STATEMENT):+ printf("Unrecognized keyword at start of '%s'.\n",+ input_buffer->buffer);+ continue;+ }++ execute_statement(&statement);+ printf("Executed.\n"); } }非SQL语句，像“.exit”这样的命令被称为“meta-commands”。它们都是以“.”结尾，所以咱们在一个独立的函数中查看并且解决它们。 ...

作者：胡呈清 爱可生 DBA 团队成员，善于故障剖析、性能优化，集体博客：https://www.jianshu.com/u/a95...，欢送探讨。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 背景前两天装置 OceanBase 时遇到一个小问题： 很显著，装置OB时要求服务器可用内存至多 8G，不达标就无奈装置。为了凑这3台10G内存的服务器我曾经费了不少劲了，free -m 输入中 free 不是有 9G 吗，为什么还报错？ 认真一看上图，available 只有 6.3G，而 OB 装置报错的 Free 其实是 available。 那为什么 free -m 输入中：free 有 9.3G，而 available 只有 6.3G呢？ 通常咱们会把 MemAvailable 看成是 buffer/cache、free 之和。但实际上不是，它其实还跟 min_free_kbytes 有着密切关系。 min_free_kbyteskswapd 是专门用来定期回收内存的过程。为了掂量内存的应用状况，定义了三个内存阈值（watermark，也称为水位），别离是 watermark[min/low/high]： 上图根本揭示了几个水位的含意，当 MemFree 低于 watermark[low] 时，kswapd 进行内存回收，直到闲暇内存达到 watermark[high] 后进行回收。如果申请内存的速度太快，导致闲暇内存降至 watermark[min] 后，内核就会进行 direct reclaim（间接回收），用回收上来的闲暇页满足内存申请，这样会阻塞应用程序。而 watermark[min] 的大小等于内核参数 min_free_kbytes 的值，其余几个水位的关系是： watermark[low] = watermark[min]*5/4watermark[high] = watermark[min]*3/2MemAvailable显然 watermark[min] 以下的内存属于零碎的自留内存，不会给一般过程申请应用。而 MemAvailable 意为能够调配应用的内存，因而它不该当蕴含这一块内存。实际上其计算公式为： ...

1 引言大家好，明天与大家一起分享一下 mysql DDL执行形式。 一般来说MySQL分为DDL（定义）和DML（操作）。 DDL：Data Definition Language，即数据定义语言，那相干的定义操作就是DDL，包含：新建、批改、删除等；相干的命令有：CREATE，ALTER，DROP，TRUNCATE截断表内容（开发期，还是挺罕用的），COMMENT 为数据字典增加备注。DML：Data Manipulation Language，即数据操作语言，即解决数据库中数据的操作就是DML，包含：选取，插入，更新，删除等；相干的命令有：SELECT,INSERT,UPDATE,DELETE，还有 LOCK TABLE，以及不罕用的CALL – 调用一个PL/SQL或Java子程序，EXPLAIN PLAN – 解析剖析数据拜访门路。咱们能够认为： CREATE，ALTER ，DROP，TRUNCATE，定义相干的命令就是DDL;SELECT，INSERT，UPDATE，DELETE，操作解决数据的命令就是DML；DDL、DML区别： DML操作是能够手动管制事务的开启、提交和回滚的。DDL操作是隐性提交的，不能rollback，肯定要审慎哦！日常开发咱们对一条DML语句较为相熟，很多开发人员都理解sql的执行过程，比拟相熟，然而DDL是如何执行的呢，大部分开发人员可能不太关怀，也认为没必要理解，都交给DBA吧。 其实不然，理解一些能尽量避开一些ddl的坑，那么上面带大家一起理解一下DDL执行的形式，也算抛砖引玉吧。如有谬误，还请各位大佬们斧正。 2 概述在MySQL应用过程中，依据业务的需要对表构造进行变更是个广泛的运维操作，这些称为DDL操作。常见的DDL操作有在表上减少新列或给某个列增加索引。 咱们罕用的易维平台提供了两种形式可执行DDL，包含MySQL原生在线DDL（online DDL）以及一种第三方工具pt-osc。 下图是执行形式的性能比照及阐明： 本文将对DDL的执行工具之Online DDL进行简要介绍及剖析，pt-osc会专门再进行介绍。 3 介绍MySQL Online DDL 性能从 5.6 版本开始正式引入，倒退到当初的 8.0 版本，经验了屡次的调整和欠缺。其实早在 MySQL 5.5 版本中就退出了 INPLACE DDL 形式，然而因为实现的问题，仍然会阻塞 INSERT、UPDATE、DELETE 操作，这也是 MySQL 晚期版本长期被吐槽的起因之一。 在MySQL 5.6版本以前，最低廉的数据库操作之一就是执行DDL语句，特地是ALTER语句，因为在批改表时，MySQL会阻塞整个表的读写操作。例如，对表 A 进行 DDL 的具体过程如下： 依照表 A 的定义新建一个表 B对表 A 加写锁在表 B 上执行 DDL 指定的操作将 A 中的数据拷贝到 B开释 A 的写锁删除表 A将表 B 重命名为 A在以上 2-4 的过程中，如果表 A 数据量比拟大，拷贝到表 B 的过程会耗费大量工夫，并占用额定的存储空间。此外，因为 DDL 操作占用了表 A 的写锁，所以表 A 上的 DDL 和 DML 都将阻塞无奈提供服务。 ...

1 前言对于一个服务端开发来说 MYSQL 可能是他应用最相熟的数据库工具，然而，大部分的Java工程师对MySQL的理解和把握水平，大抵就停留在这么一个阶段:它能够建库、建表、建索引，而后就是对外面的数据进行增删改查，语句性能有点差？没关系，在表里建几个索引或者调整一下查问逻辑就能够了，一条sql，MYSQL是如何解决的，为咱们做了什么，齐全是个黑盒。本文次要通过sql执行的过程突破这样一个黑盒的认知，来理解MYSQL的逻辑架构。 MYSQL的逻辑架构可分为3层:应用层、服务层、存储引擎层。其中存储引擎是MYSQL最有特色的中央，MySQL区别于其余数据库的最重要特点是其插件式的表存储引擎，本文也将着重聊聊最罕用的innoDB存储引擎的架构设计原理，假如现有如下sql： update users set name=’zhangsan’ where id = 10 作为一个java服务端工程师，见到这样一个sql，本能的脑海中立即就浮现出如下信息： 一个表名为users的表有两个字段 id、name，id是主键把users表里的id=10的这个用户名批改为“zhangsan”那么MYSQL是如何解决这样一个sql呢？带着这个问题，咱们来看一下MYSQL是如何通过一个个组件来解决这个sql，来理解MYSQL的整体架构 2 应用层 2.1 连接线程解决 当MYSQL面对下面的sql，首先应该做什么呢？是如何解析？如何抉择索引？如何提交事务？当然不是，首先应该解决的是怎么把sql语句传给它。大家都晓得，如果咱们要拜访数据库，那么，首先就须要和数据库建设连贯，那么这个连贯由谁来建呢，答案就是MYSQL驱动，上面这段maven配置大家应该都很相熟 java程序就是通过这个驱动包来与数据库建设网络连接。下图示意： 从图中能够看到这样一个场景：java程序很多个线程并发申请执行上述sql，咱们都晓得数据库连贯是十分占用资源的，尤其是在高并发的状况下，如果每次都去建设数据库连贯就会有性能问题，也会影响一个应用程序的延展性，针对这个问题，连接池呈现了。下图示意： 从图中可见网络连接交由线程3监听和读取sql申请，至此MYSQL曾经收到咱们的申请，当然MYSQL在建设连贯时还做了用户鉴权,鉴权根据是: 用户名，客户端主机地址和用户明码;在获取连贯后，解决申请时还会做sql申请的平安校验，依据用户的权限判断用户是否能够执行这条sql。 3 服务层 3.1 SQL 接口 从上图中咱们晓得线程3负责监听并读取sql，拿到这个sql之后，如何执行是一项极其简单的工作，所以MYSQL提供了SQL接口这么一个组件，线程3会将sql转交给SQL接口来执行如下图： SQL接口具体解决性能有：DDL、DML、存储过程、视图、触发器等。 3.2 SQL解析器 接着问题来了，SQL接口如何执行本文sql呢？，数据库怎么了解本文这个sql呢？置信懂sql语法的人立马就能晓得什么意思，然而MYSQL是个零碎不是人，它无奈间接了解sql的意思，这个时候要害的组件出场了，SQL解析器的作用次要就是是解析sql语句，最终生成语法树，比方本文sql就能够拆解成如下几个局部： 须要从users表里更新数据须要更新id字段是10的那行数据须要把这行数据的name字段的值改为 “zhangsan”3.3 SQL优化器 当通过SQL 解析器了解了sql语句要干什么之后，该如何实现呢，以本文的更新语句为例，咱们能够有以下两种实现形式： 间接定位到users表中id字段等于10的一行数据，而后查出这行数据数据，而后设置name字段为“zhangsan”；也能够通过更新name字段索引的形式在name索引上遍历id等于10的索引值，而后设置name字段为“zhangsan”。下面两种路径都能实现最终后果，显然第一种门路更好一些，所以,SQL优化器就是从泛滥实现门路当选则一条最优的门路进去，也就是咱们常说的执行打算。 3.4 执行器 通过SQL优化器咱们失去一套执行打算，那么，这个打算怎么执行呢？这个时候就不得不提MYSQL存储引擎，咱们都晓得MySQL和其余关系型数据库不一样的中央在于它的弹性以及能够通过插件模式提供不同品种的存储引擎，相似java接口的多实现，MYSQL必定会有一套规范的存储引擎接口，而执行器就是依照执行打算一步一步的调用存储引擎接口实现sql执行而已，如下图： 上图专门将binlog标出来是为了和下文innodb存储引擎的undo log、redo log做辨别，强调binlog是server层的日志，后续binlog 和redo log的两阶段形式实现事务的提交会再次提到。 3.5 查问缓存 MYSQL服务层为谋求高效也引入了QUERY BUFFER 这个组件，然而这个组件比拟鸡肋，缓存不仅须要sql全字匹配命中，而且对根底表的任何批改都会导致这些表的所有缓存生效，既不合乎当初用户变量的开发模式，大部分时候也不高效。MYSQL从5.7开始不举荐应用默认敞开，8.0中不再反对，具体起因如下图： 截图起源MYSQL开发者专区文档：MySQL :: MySQL 8.0: Retiring Support for the Query Cache 4 存储引擎层 4.1 概述 上文执行器拿到执行打算后，调用存储引擎的接口来实现sql的执行，那么存储引擎如何帮忙咱们去拜访、操作内存以及磁盘上的数据呢？咱们都晓得MYSQL的存储引擎有很多，实现形式各一，上面让咱们持续通过上文的sql来初步理解咱们罕用的Innodb存储引擎的外围原理和架构设计 ...

连贯被MySQL敞开了，阐明Go缓存的连贯生命周期超过了MySQL连贯的生命周期，要防止这个谬误，实质上就须要这两个连贯的生命周期保持一致，或者，更平安一点，Go的更短一些： db.SetConnMaxLifetime(time.Hour)

　技术是为了解决问题而生的，锁被用来实现隔离性，保障并发事务的正确性。上面将具体介绍一下锁机制。　两段锁 & 一次封闭　两段锁　数据库遵循的是两段锁协定，将事务分成两个阶段，加锁阶段和解锁阶段（所以叫两段锁）　加锁阶段：在加锁阶段只能进行加锁操作。　如果事务要读取对象，必须先取得共享锁。能够有多个事务同时取得一个对象的共享锁　如果事务要批改对象，必须先取得独占锁。只能有一个事务取得对象的独占锁。如果某个事务曾经取得了对象的独占锁，则其余尝试获取锁（包含共享锁、独占锁）的事务必须期待，直到加锁胜利能力继续执行　解锁阶段：在解锁阶段只能进行解锁操作。　事务要读取对象 ，必须先取得共享锁，这样避免幻读。事务要批改对象，必须先取得独占锁，这样避免脏写。　两段锁能够这样来实现：事务开始后就处于加锁阶段，始终到执行 rollback 或 commit 之前都是加锁阶段。rollback 和 commit 使事务进入解锁阶段，即在 rollback 或 commit 时开释持有的锁。　一次封闭　一次封闭法恪守两段锁协定。　一次封闭要求每个事务必须一次将所有要应用的数据全副加锁，否则就不能继续执行。　一次封闭存在的问题：　封闭工夫被缩短，并发度被升高：一次就将当前要用到的全副数据加锁，势必缩短了封闭的工夫，从而升高了零碎的并发度。　不适宜用在数据库：一次封闭不适宜用在数据库中，因为在事务开始阶段，数据库并不知道会用到哪些数据。　一次封闭的益处：不会呈现死锁。　为什么要应用两段锁呢？用完间接开释锁不行吗？　不行，用完间接开释会使事务的隔离性受到影响。具体介绍能够看上面的文章。Mysql 锁：灵魂七拷问 (youzan.com)　两段锁 的优劣局限　两段锁的长处 / 作用：　解决事务并发问题：避免脏写、脏读 ......　实现可串行化隔离：将两段锁与谓词锁联合应用，能够避免所有模式的写歪斜以及其余竞争条件，实现可串行化隔离　性能和理论串行相比：相比于理论串行来说，应用两段锁时，多个事务能够并发读取同一个对象　性能和一次封闭来比：相比于一次封闭，两段锁的锁定工夫更短，事务并发性比一次封闭要好　两段锁的毛病：　性能：应用两段锁，事务吞吐量和查问响应工夫相比于其余弱隔离级别降落十分多。局部起因在于锁的获取和开释自身的开销，但更重要的是其升高了事务的并发性。　拜访提早具备十分大的不确定性：如果一个事务须要期待另一个事务开释锁，另一个事务开释锁的机会是不确定的，因而期待它开释锁的耗时是不确定的。　死锁更加频繁：因为两段锁的加锁模式，死锁可能变得更为频繁。因此导致另一个性能问题，即如果事务因为死锁而被强行停止，应用层就必须从头重试，如果死锁过于频繁，则性能和效率必然大打折扣。　数据库系统会自动检测死锁状况，并强行停止其中的一个事务以突破僵局　因为应用了这么多的锁机制，所以很容易呈现死锁景象 ，例如事务 A 可能在期待事务 B 开释它持有的锁， 而事务 B 在期待事务 A 开释它持有的锁。数据库系统会自动检测事务之间的死锁状况，并强行停止其中的一个事务以突破僵局，这样另一个能够持续向前执行 。而被停止的事务须要由应用层来重试。　MySQL 提供的锁　依据加锁的范畴，MySQL 外面的锁大抵能够分成全局锁、表级锁和行级锁三类。　全局锁　全局锁就是对整个数据库实例加锁。　给数据库实例加全局锁的命令：flush tables with read lock;（FTWRL）　开释锁的命令：unlock tables;（表级锁、行级锁开释也是这个命令）　加上全局锁之后，整个数据库处于只读状态，其余线程的以下语句会被阻塞：　数据更新语句（数据的增删改 insert、delete、update）　数据定义语句（DDL、包含建表、批改表构造等）　更新类事务的提交语句（更新类事务就是应用了相似 select * from t1 for update; 带 for update 的查问的事务）　全局锁的典型应用场景是，做全库逻辑备份。也就是把整库每个表存成 .sql 类型的文件。　全局锁的作用相当于是进行更新操作，拿到一个一致性视图。　MySQL 的在可反复读隔离级别下开启一个事务也能够拿到一个一致性视图，并且后者能够做到不影响更新操作。　官网自带了全量逻辑备份工具 mysqldump。　当 mysqldump 应用参数 –single-transaction 的时候，就会应用基于 MVCC 机制的一致性视图。　当 mysqldump 应用参数 –master-data 的时候，就会应用基于全局读锁的一致性视图。　表级锁　表级锁就是对表加锁。　MySQL 外面表级别的锁有三种：　表锁；　元数据锁（meta data lock，MDL）；　意向锁。　表锁　表锁就是对整个数据表加锁。　给数据表加表锁的命令：lock table 表名 read /write;　开释表锁的命令和开释全局锁的命令一样，都是：unlock tables;。如果不手动开释表锁，在客户端断开的时候会主动开释表锁。　须要留神的是，lock tables 语法除了会限度别的线程的读写外，也限定了本线程接下来的操作对象。　举个例子，如果在线程 A 中执行 lock tables t1 read, t2 write; 这个语句，则其余线程写 t1、读写 t2 的语句都会被阻塞。同时，线程 A 在执行 unlock tables 之前，也只能执行读 t1、读写 t2 的操作。连写 t1 都不容许，天然也不能拜访其余表。　意向锁　表锁分为：共享锁、独占锁。　如果咱们想对整个数据表加共享锁，首先要确保表中没有记录被加独占锁　如果咱们想对整个数据表加独占锁，首先要确保表中没有记录被加共享锁 / 独占锁　那么咱们该如何来判断表中是否有记录被加独占锁 / 独占锁呢？咱们能够通过遍历所有记录的形式来查看表中有没有被加锁的记录，而遍历的形式太慢了。　意向锁的提出就是为了加表级别的共享锁 和 独占锁时，疾速判断表中的记录是否被上锁，以防止用遍历的形式来查看表中有没有被加锁的记录，提供判断速度。　意向锁分为：动向共享锁、动向独占锁：　当事务筹备在某条记录上加 共享锁 时，须要先在表级别加一个 动向共享锁；　当事务筹备在某条记录上加 独占锁 时，须要先在表级别加一个 动向独占锁。　这样，如果表级别存在 动向共享锁，就意味着表中有被加 共享锁 的记录；如果表级别存在 动向独占锁，就意味着表中有被加 独占锁 的记录。通过意向锁咱们就能够疾速判断表中是否有记录被加锁。　元数据锁　元数据锁（meta data lock，MDL）是 MySQL 5.5 版本引入的。　MDL 不须要显式应用，在拜访一个表的时候会被主动加 MDL 锁。　MDL 锁分为：MDL 读锁、MDL 写锁：　DML 操作（数据的增删改查：insert、delete、update、select）加 MDL 读锁　DDL 操作（对表构造做变更操作）加 MDL 写锁。　MDL 锁的加锁、开释锁的规定：　MDL 读锁与 MDL 读锁互不烦扰。　MDL 写锁与 MDL 写锁、MDL 写锁与 MDL 读锁互相阻塞。用来保障变更表构造操作的安全性。　MDL 锁应用两段锁：事务取得锁之后， 始终持有锁直到事务完结（包含提交或停止）。　MDL 锁作用是：避免 DDL 操作和 DML 操作并发，保障变更表构造操作的安全性。　须要留神的是，如果申请加 MDL 锁失败，那么再此之后的加锁申请都必须期待（偏心锁机制，遵循先来先执行准则，先来的没有加锁胜利，起初的不能加锁）。因而执行 DDL 操作时要分外留神，如果操作执行工夫过长，前面的 DML 操作都将被阻塞较长时间。　行级锁　行级锁就是对记录加锁。　行级锁又分为各种类型，不同类型的行级锁的作用也不同，行级锁分为：　Record Lock：行锁，单个行记录的锁　Gap Lock：间隙锁，作用于记录与记录之间的空隙，作用仅仅是为了避免满足搜寻条件的记录插入空隙（避免插入幻影记录）　Next-Key Lock：索引区间锁，实质是一个行锁 和 一个 Gap Lock 的结合体　只在可反复读或以上隔离级别下的特定操作才会加间隙锁。在 加读写锁的 select、update 和 delete 时，除了基于惟一索引（主键索引也属于惟一索引）的查问之外，基于其余索引查问时都会加间隙锁。　可能加 Gap Lock 的要求：　必须是可反复读或以上隔离级别　如果是 select，则必须以给读到的记录加读写锁的形式　可反复读隔离级别下的 select ... for update、select ... lock in share mode　可串行化隔离级别下的 select ...（加共享锁）以及下面两种手动加共享锁，排他锁的形式　必须是可能走索引的查问，如果是全表扫描的查问那么没有方法加 Gap Lock。　加锁规定：蕴含了两个 “准则”、两个 “优化” 和一个 “bug”。　准则 1：加锁的根本单位是 next-key lock。next-key lock 是前开后闭区间。　准则 2：查找过程中拜访到的对象才会加锁。　优化 1：索引上的等值查问，给惟一索引加锁的时候，next-key lock 进化为行锁。　优化 2：索引上的等值查问，向右遍历时且最初一个值不满足等值条件的时候，next-key lock 进化为间隙锁。　一个 bug：惟一索引上的范畴查问会拜访到不满足条件的第一个值为止。　共享锁 & 独占锁　表锁、元数据锁、行锁又都分为共享锁和独占锁。　共享锁 - 共享锁兼容：如果事务要读取对象 ，必须先以共享模式取得锁。能够有多个事务同时取得一个对象的共享锁　共享锁 - 独占锁、独占锁 - 独占锁互斥：如果事务要批改对象，必须先以独占模式获取锁。只能有一个事务取得对象的独占锁。如果某个事务曾经取得了对象的独占锁，则其余尝试获取锁（包含共享锁、独占锁）的事务必须期待 ...

“What I cannot create, I do not understand.” – Richard FeynmanI’m building a clone of sqlite from scratch in C in order to understand, and I’m going to document my process as I go.译注：cstsck在github保护了一个简略的、相似sqlite的数据库实现，通过这个简略的我的项目，能够很好的了解数据库是如何运行的，实现教程原文是英文，共有13篇，这里翻译过去以飨读者。原文题目：Let's Build a Simple Database，本文是第一篇 Part 1 介绍&设置REPL作为一名开发人员，在工作中我每天都应用关系型数据库。然而对我来说，它们是一个黑盒。我有一些问题： 数据存储应用什么格局？ （在内存与磁盘中）数据什么时候从内存转移到磁盘？为什么每张表只能有一个主键？事务回滚是怎么工作的？索引是什么格局的？全表扫描时什么时候产生，如何产生的？预处理语句（prepared statement）是应用什么格局存储的？换句话说，数据库是怎么工作的？ 为了弄清楚这些，我从头写了一个数据库。它是模拟sqlite实现的，因为sqlite设计玲珑，并且相比于MySQL和PostgreSQL，它的性能绝对要少很多，所以我心愿能更容易的了解它。在实现上，整个数据库都存储在一个数据文件中。 Sqlite在sqlite的网站上，有很多sqlite的外部文档（https://www.sqlite.org/arch.html）。另外我还拷贝了文档（SQLite Database System: Design and Implementation.）的一个正本（https://play.google.com/store...）。 sqlite architecture (https://www.sqlite.org/zipvfs...) 一个查问通过组件链来获取数据或者批改数据。前端如下组件： 分词器(tokenizer)解析器（parser）代码生成器（code generator）前端的输出是SQL语句。输入则是sqlite的虚拟机字节码（sqlite virtual machine bytecode），实质上是一个能够在数据库运行的编译程序。 译注：数据库实现查问优化模型分为传统的火山模型（Volcano model）与Code gen模型，本文作者实现的是code gen模型。 后端包含如下组件： 虚拟机（virtual machine）B-tree页治理（pager）零碎接口（os interface）virtual machine虚拟机将前端生成的字节码作为指令。它接下来能够在一个或更多的表、索引上执行操作，表以及索引都是存储在叫B-tree的数据结构中。VM 实质上是字节码指令类型的一个大开关语句（a big switch statement on the type of bytecode instruction）。 ...

背景最近在跟着学习一套开源的电商我的项目，建了一个我的项目库所需的数据库。表是有了，然而数据没有。一个电商我的项目怎么能没有多一点的数据呢，于是决定本人一个表造个几十万数据（总共71个表）。对于假数据只有几点简略的要求： 创立工夫要比当初工夫小，并且在肯定的范畴随机更新工夫要比当初工夫大，并且在肯定的范畴随机数据不能是变化无穷的，要有随机变动的特点例如status这种char(1)，数据只有0或者1的字段，不能呈现非法数据......开始创立长期表tmp_table在数据库服务器上安装python环境在数据库服务器上执行命令，生成内容为1~100000的文件( # 这里100000是你一个表的数据量级，你能够自行设定python -c "for i in range(1, 1+100000): print(i)" > mall.txt登录mysql，并执行 -- 抉择本人的数据库use mall-- 加载mall.txt中的数据到tmp_table表中load data infile 'mall.txt' replace into table tmp_table;导出数据库所有表、字段信息执行sql语句 SELECT TABLE_NAME AS '表名', COLUMN_NAME AS '列名', COLUMN_DEFAULT AS '默认值', COLUMN_TYPE AS 列类型FROM information_schema.`COLUMNS`WHERE TABLE_SCHEMA = 'mall'ORDER BY TABLE_NAME, ORDINAL_POSITIONINTO OUTFILE '/var/lib/mysql-files/mallFour.text';其中TABLE_SCHEMA=后批改为本人的库名，INTO OUTFILE '/var/lib/mysql-files/mallFour.text'中的mallFour.text批改为本人的文件名称（然而门路不要批改）。 上面我生成的数据文件： ums_role id \N bigint(20)ums_role name \N varchar(100)ums_role description \N varchar(500)ums_role admin_count \N int(11)ums_role status 1 int(1)ums_role sort 0 int(11)ums_role create_user \N varchar(50)ums_role create_time \N datetimeums_role update_user \N varchar(50)ums_role update_time \N datetimeums_role is_delete 0 char(1)ums_role_permission_relation id \N bigint(20)ums_role_permission_relation role_id \N bigint(20)ums_role_permission_relation permission_id \N bigint(20)ums_role_permission_relation create_user \N varchar(50)ums_role_permission_relation create_time \N datetimeums_role_permission_relation update_user \N varchar(50)ums_role_permission_relation update_time \N datetimeums_role_permission_relation is_delete 0 char(1)..................将生成的表、字段信息文件mallFour.text，下载到本地删除mallFour.text文件中的tmp_table这一行，并在文件最初加上一行文件结尾标识编写Java代码，生成sql语句package com.liboshuai.mall.tiny.utils;import cn.hutool.core.io.FileUtil;import com.liboshuai.mall.tiny.common.enums.AutoMysqlEnum;import java.util.*;import java.util.stream.Collectors;/** * @Author: liboshuai * @Date: 2022-09-17 15:51 * @Description: 随机生成mysql数据工具类 */public class AutoMysqlUtil { private static final String TMP_TABLE = "tmp_table"; private static final String FILE_END_FLAG = "文件结尾标识"; public static void main(String[] args) { // 方才下载到本地的mysql表、字段数据文件地址 List<String> readLines = FileUtil.readLines("C:\\Users\\李博帅\\Desktop\\mall03.txt", "UTF-8"); // 拼接 "INSERT INTO ? SELECT content FROM tmp_table" + tableName 局部 List<String> tableNameList = readLines.stream() .map(readLine -> readLine.split("\\s+")[0]) .collect(Collectors.toList()); Map<String, List<String>> tableNameMap = tableNameList.stream().collect(Collectors.groupingBy(String::toString)); Set<String> tableNameSet = tableNameMap.keySet(); List<StringBuilder> truncateTableMysqlList = tableNameSet.stream() .filter(tableName -> !Objects.equals(tableName, TMP_TABLE) && !tableName.startsWith(FILE_END_FLAG)) .map(tableName -> new StringBuilder("truncate table ") .append(tableName).append(";")) .collect(Collectors.toList()); List<String> columnNameList = readLines.stream() .map(readLine -> readLine.split("\\s+")[1]) .collect(Collectors.toList()); List<String> typeList = readLines.stream() .map(readLine -> readLine.split("\\s+")[3]) .collect(Collectors.toList()); List<StringBuilder> mysqlList = new ArrayList<>(); String tableName = tableNameList.get(0); int flag = 0; for (int i = 0; i < tableNameList.size(); i++) { String tableNameTemp = tableNameList.get(i); boolean equalsOne = Objects.equals(tableNameTemp, tableName); boolean equalsThree = Objects.equals(tableNameTemp, TMP_TABLE); if (!equalsOne &&!equalsThree) { List<String> columnNameTempList = new ArrayList<>(); List<String> typeTempList = new ArrayList<>(); for (int j = flag; j < i; j++) { String columnName = columnNameList.get(j); String type = typeList.get(j); columnNameTempList.add(columnName); typeTempList.add(type); } StringBuilder mysql = new StringBuilder() .append("INSERT INTO ").append(tableName) .append(" SELECT "); for (int j = 0; j < columnNameTempList.size(); j++) { String columnName = columnNameTempList.get(j); String type = typeTempList.get(j); if (Objects.equals(columnName, AutoMysqlEnum.ID.getKey())) { mysql.append(AutoMysqlEnum.ID.getValue()); } else if (Objects.equals(columnName, AutoMysqlEnum.CREATE_TIME.getKey())) { mysql.append(AutoMysqlEnum.CREATE_TIME.getValue()); } else if (Objects.equals(columnName, AutoMysqlEnum.CREATE_USER.getKey())) { mysql.append("CONCAT( '").append(AutoMysqlEnum.CREATE_USER.getValue()).append("', id ), "); } else if (Objects.equals(columnName, AutoMysqlEnum.UPDATE_USER.getKey())) { mysql.append("CONCAT( '").append(AutoMysqlEnum.UPDATE_USER.getValue()).append("', id ), "); } else if (Objects.equals(columnName, AutoMysqlEnum.UPDATE_TIME.getKey())) { mysql.append(AutoMysqlEnum.UPDATE_TIME.getValue()); } else { if (type.startsWith(AutoMysqlEnum.BIGINT.getKey())) { mysql.append(AutoMysqlEnum.BIGINT.getValue()); } else if (type.startsWith(AutoMysqlEnum.VARCHAR.getKey()) || type.startsWith(AutoMysqlEnum.VARBINARY.getKey()) || type.startsWith(AutoMysqlEnum.TEXT.getKey())) { mysql.append("CONCAT( '").append(columnName).append("', id ), "); } else if (type.startsWith(AutoMysqlEnum.INT1.getKey())) { mysql.append(AutoMysqlEnum.INT1.getValue()); } else if (type.startsWith(AutoMysqlEnum.INT2.getKey())) { mysql.append(AutoMysqlEnum.INT2.getValue()); } else if (type.startsWith(AutoMysqlEnum.INT.getKey())) { mysql.append(AutoMysqlEnum.INT.getValue()); } else if (type.startsWith(AutoMysqlEnum.DECIMAL.getKey())) { mysql.append(AutoMysqlEnum.DECIMAL.getValue()); } else if (type.startsWith(AutoMysqlEnum.DATE.getKey())) { mysql.append(AutoMysqlEnum.DATE.getValue()); } else if (type.startsWith(AutoMysqlEnum.DATETIME.getKey())) { mysql.append(AutoMysqlEnum.DATETIME.getValue()); } else if (type.startsWith(AutoMysqlEnum.TIME.getKey())) { mysql.append(AutoMysqlEnum.TIME.getValue()); } else if (type.startsWith(AutoMysqlEnum.CHAR.getKey())) { mysql.append(AutoMysqlEnum.CHAR.getValue()); } } } mysqlList.add(mysql); tableName = tableNameList.get(i); flag = i; } } mysqlList = mysqlList.stream() .map(mysql -> mysql.substring(0, mysql.length() - 2)) .map(mysql -> new StringBuilder(mysql).append(" FROM tmp_table;")) .collect(Collectors.toList()); truncateTableMysqlList.addAll(mysqlList); // mysql文件生成的地址 FileUtil.writeLines(truncateTableMysqlList, "C:\\Users\\李博帅\\Desktop\\mallMysql.sql", "UTF-8"); }}package com.liboshuai.mall.tiny.common.enums;import lombok.AllArgsConstructor;import lombok.Getter;/** * @Author: liboshuai * @Date: 2022-09-17 18:51 * @Description: 主动生成mysql */@Getter@AllArgsConstructor@SuppressWarnings("AlibabaEnumConstantsMustHaveComment")public enum AutoMysqlEnum {// [date, int(2), int(1), varchar(128), varchar(8), char(1), int(11), varchar(16), varchar(32), bigint(11), varchar(50), datetime, bigint(20), varchar(64), varbinary(500), time, decimal(10,2), text, varchar(1000), varchar(100), varchar(255), varchar(200), int(3), varchar(500)] // 依照类型 BIGINT("bigint", "FLOOR( Rand() * 100000), "), INT1("int(1)", "FLOOR(0 + Rand() * 2), "), INT2("int(2)", "FLOOR( Rand() * 100), "), INT("int", "FLOOR( Rand() * 10000), "), DECIMAL("decimal", "FLOOR( Rand() * 100000), "), DATE("date", "ADDDATE(ADDDATE(ADDDATE('2018-01-01', INTERVAL FLOOR(RAND() * 8) YEAR),INTERVAL FLOOR(RAND() * 12) MONTH),INTERVAL FLOOR(RAND() * 31) DAY), "), DATETIME("datetime", "ADDDATE(ADDDATE(ADDDATE(ADDDATE(ADDDATE(ADDDATE('2018-01-01 00:00:00', INTERVAL FLOOR(RAND() * 8) YEAR),INTERVAL FLOOR(RAND() * 12) MONTH),INTERVAL FLOOR(RAND() * 31) DAY), INTERVAL FLOOR(RAND() * 24) HOUR),INTERVAL FLOOR(RAND() * 60) MINUTE),INTERVAL FLOOR(RAND() * 60) SECOND), "), TIME("time", "'00:00:00', "), VARCHAR("varchar", "NULL, "), CHAR("char", "'0', "), VARBINARY("varbinary", "NULL, "), TEXT("text", "NULL, "), // 依照列名 ID("id", "id, "), CREATE_TIME("create_time", "ADDDATE(ADDDATE(ADDDATE(ADDDATE(ADDDATE(ADDDATE('2022-09-17 22:00:00', INTERVAL FLOOR(1 -(RAND() * 4)) YEAR),INTERVAL FLOOR(1 - (RAND() * 12)) MONTH),INTERVAL FLOOR(1 - (RAND() * 31)) DAY),INTERVAL FLOOR(1 - (RAND() * 24)) HOUR),INTERVAL FLOOR(1 - RAND() * 60) MINUTE),INTERVAL FLOOR(1 - (RAND() * 60)) SECOND), "), CREATE_USER("create_user", "admin"), UPDATE_TIME("update_time", "ADDDATE(ADDDATE(ADDDATE(ADDDATE(ADDDATE(ADDDATE('2022-09-17 22:00:00', INTERVAL FLOOR(1 + (RAND() * 4)) YEAR),INTERVAL FLOOR(1 + (RAND() * 12)) MONTH),INTERVAL FLOOR(1 + (RAND() * 31)) DAY),INTERVAL FLOOR(1 + (RAND() * 24)) HOUR),INTERVAL FLOOR(1 + RAND() * 60) MINUTE),INTERVAL FLOOR(1 + (RAND() * 60)) SECOND), "), UPDATE_USER("update_user", "lbs"); private String key; private String value;}执行方才生成的mysql语句文件mallMysql.sql，最终生成数据..................truncate table pms_brand;truncate table pms_comment;truncate table ums_member;truncate table ums_admin_login_log;truncate table oms_cart_item;truncate table sms_home_recommend_subject;truncate table sms_home_new_product;truncate table sms_flash_promotion_session;truncate table cms_subject_product_relation;truncate table pms_product_attribute_value;truncate table oms_order_operate_history;truncate table ums_member_login_log;INSERT INTO cms_help SELECT id, FLOOR( Rand() * 100000), CONCAT( 'icon', id ), CONCAT( 'title', id ), FLOOR(0 + Rand() * 2), FLOOR(0 + Rand() * 2), CONCAT( 'content', id ), CONCAT( 'admin', id ), ADDDATE(ADDDATE(ADDDATE(ADDDATE(ADDDATE(ADDDATE('2022-09-17 22:00:00', INTERVAL FLOOR(1 -(RAND() * 4)) YEAR),INTERVAL FLOOR(1 - (RAND() * 12)) MONTH),INTERVAL FLOOR(1 - (RAND() * 31)) DAY),INTERVAL FLOOR(1 - (RAND() * 24)) HOUR),INTERVAL FLOOR(1 - RAND() * 60) MINUTE),INTERVAL FLOOR(1 - (RAND() * 60)) SECOND), CONCAT( 'lbs', id ), ADDDATE(ADDDATE(ADDDATE(ADDDATE(ADDDATE(ADDDATE('2022-09-17 22:00:00', INTERVAL FLOOR(1 + (RAND() * 4)) YEAR),INTERVAL FLOOR(1 + (RAND() * 12)) MONTH),INTERVAL FLOOR(1 + (RAND() * 31)) DAY),INTERVAL FLOOR(1 + (RAND() * 24)) HOUR),INTERVAL FLOOR(1 + RAND() * 60) MINUTE),INTERVAL FLOOR(1 + (RAND() * 60)) SECOND), '0' FROM tmp_table;INSERT INTO cms_help_category SELECT id, CONCAT( 'name', id ), CONCAT( 'icon', id ), FLOOR( Rand() * 10000), FLOOR( Rand() * 100), FLOOR( Rand() * 10000), CONCAT( 'admin', id ), ADDDATE(ADDDATE(ADDDATE(ADDDATE(ADDDATE(ADDDATE('2022-09-17 22:00:00', INTERVAL FLOOR(1 -(RAND() * 4)) YEAR),INTERVAL FLOOR(1 - (RAND() * 12)) MONTH),INTERVAL FLOOR(1 - (RAND() * 31)) DAY),INTERVAL FLOOR(1 - (RAND() * 24)) HOUR),INTERVAL FLOOR(1 - RAND() * 60) MINUTE),INTERVAL FLOOR(1 - (RAND() * 60)) SECOND), CONCAT( 'lbs', id ), ADDDATE(ADDDATE(ADDDATE(ADDDATE(ADDDATE(ADDDATE('2022-09-17 22:00:00', INTERVAL FLOOR(1 + (RAND() * 4)) YEAR),INTERVAL FLOOR(1 + (RAND() * 12)) MONTH),INTERVAL FLOOR(1 + (RAND() * 31)) DAY),INTERVAL FLOOR(1 + (RAND() * 24)) HOUR),INTERVAL FLOOR(1 + RAND() * 60) MINUTE),INTERVAL FLOOR(1 + (RAND() * 60)) SECOND), '0' FROM tmp_table;..................

明天，咱们发表推出全新的 Amazon Relational Database Service (RDS) 多可用区部署选项，其事务提交提早最多可提速 2 倍，主动故障转移工夫通常少于 35 秒，并蕴含可读的备用实例。 Amazon RDS 提供两种复制选项，以加强可用性和性能： 多可用区部署可提供高可用性和主动故障转移性能。Amazon RDS 会在第二个可用区中创立数据库的存储级别正本。而后，它会将数据从主数据库实例同步复制到备用数据库实例，以实现高可用性。主数据库实例为应用程序申请提供服务，而备用数据库实例则会在呈现故障时随时接管。Amazon RDS 负责管理故障检测、故障转移和修复操作的各方面事宜，以便应用数据库的应用程序具备高可用性。只读正本容许应用程序跨多个数据库实例扩大其读取操作。数据库引擎会将数据异步复制到只读正本。应用程序将写入申请（INSERT、UPDATE 和 DELETE）发送到主数据库，读取申请 (SELECT) 能够在只读正本之间实现负载平衡。如果主节点呈现故障，您能够手动将只读正本晋升为新的主数据库。多可用区部署和只读正本有不同的用处。多可用区部署可为您的应用程序提供高可用性、持久性和主动故障转移的服务。只读正本可为您的应用程序提供读取可扩展性。 然而，如果应用程序既须要高可用性、主动故障转移，同时又须要读取可扩展性，该怎么办？ 隆重介绍具备两个可读备用实例的新 Amazon RDS 多可用区部署选项。从明天开始，咱们将增加一个新选项来部署 RDS 数据库。此选项联合了主动故障转移和只读正本：Amazon RDS 多可用区，并带有两个可读备用实例。此部署选项实用于 MySQL 和 PostgreSQL 数据库。这是一个具备一个主实例和两个可读备用实例的数据库集群。它提供的事务提交提早可提速 2 倍，同时提供主动故障转移性能，通常用时不超过 35 秒。 启用新的多可用区数据库集群部署选项后，RDS 将在三个不同的可用区中配置一个主数据库和两个只读正本。而后，它会监督并在主节点呈现故障时启用故障转移。 与传统的只读正本一样，数据库引擎会在主节点和只读正本之间复制数据。与多可用区单备用部署选项相似，RDS 会自动检测和治理故障转移以实现高可用性。 您不用在高可用性或可扩展性之间进行抉择；具备两个可读备用正本的多可用区数据库集群可同时实现两种特质。 有什么好处？与传统的多可用区部署相比，此新部署选项为您带来了四大劣势：通过改良的提交提早、更快的故障转移、可读的备用实例和失去优化的复制。 首先，应用多可用区数据库集群时，写入操作会变得更快。新的多可用区数据库集群实例利用 M6gd 和 R6gd 实例类型。这些实例由 AWS Graviton2 处理器提供反对。它们装备了用于本地存储的疾速 NVMe SSD，非常适合高速和低提早存储要求。与基于 x86 的同类实例相比，它们的性价比最高可晋升 40%，每个 vCPU 的本地存储容量可减少 50%。 多可用区数据库实例应用 Amazon Elastic Block Store (EBS) 来存储数据和事务日志。新的多可用区数据库集群实例应用实例提供的本地存储来存储事务日志。本地存储通过优化，可为应用程序提供低提早，并进步每秒输出/输入操作数 (IOPS)。写入操作将首先写入本地存储事务日志，而后刷新到数据库存储卷上的永恒存储。 ...

介绍锁机制技术是为了解决问题而生的，锁被用来实现隔离性，保障并发事务的正确性。 两段锁 & 一次封闭两段锁 数据库遵循的是两段锁协定，将事务分成两个阶段，加锁阶段和解锁阶段（所以叫两段锁） 加锁阶段：在加锁阶段只能进行加锁操作。 如果事务要读取对象，必须先取得共享锁。能够有多个事务同时取得一个对象的共享锁如果事务要批改对象，必须先取得独占锁。只能有一个事务取得对象的独占锁。如果某个事务曾经取得了对象的独占锁，则其余尝试获取锁（包含共享锁、独占锁）的事务必须期待，直到加锁胜利能力继续执行解锁阶段：在解锁阶段只能进行解锁操作。事务要读取对象 ，必须先取得共享锁，这样避免幻读。事务要批改对象，必须先取得独占锁，这样避免脏写。 两段锁能够这样来实现：事务开始后就处于加锁阶段，始终到执行 rollback 或 commit 之前都是加锁阶段。rollback 和 commit 使事务进入解锁阶段，即在 rollback 或 commit 时开释持有的锁。 一次封闭 一次封闭法恪守两段锁协定。 一次封闭要求每个事务必须一次将所有要应用的数据全副加锁，否则就不能继续执行。 一次封闭存在的问题： 封闭工夫被缩短，并发度被升高：一次就将当前要用到的全副数据加锁，势必缩短了封闭的工夫，从而升高了零碎的并发度。不适宜用在数据库：一次封闭不适宜用在数据库中，因为在事务开始阶段，数据库并不知道会用到哪些数据。一次封闭的益处：不会呈现死锁。 为什么要应用两段锁呢？用完间接开释锁不行吗？ 不行，用完间接开释会使事务的隔离性受到影响。具体介绍能够看上面的文章。Mysql锁：灵魂七拷问 (youzan.com) 两段锁 的优劣局限两段锁的长处 / 作用： 解决事务并发问题：避免脏写、脏读 ......实现可串行化隔离：将两段锁与谓词锁联合应用，能够避免所有模式的写歪斜以及其余竞争条件，实现可串行化隔离性能和理论串行相比：相比于理论串行来说，应用两段锁时，多个事务能够并发读取同一个对象性能和一次封闭来比：相比于一次封闭，两段锁的锁定工夫更短，事务并发性比一次封闭要好两段锁的毛病： 性能：应用两段锁，事务吞吐量和查问响应工夫相比于其余弱隔离级别降落十分多。局部起因在于锁的获取和开释自身的开销，但更重要的是其升高了事务的并发性。拜访提早具备十分大的不确定性：如果一个事务须要期待另一个事务开释锁，另一个事务开释锁的机会是不确定的，因而期待它开释锁的耗时是不确定的。死锁更加频繁：因为两段锁的加锁模式，死锁可能变得更为频繁。因此导致另一个性能问题，即如果事务因为死锁而被强行停止，应用层就必须从头重试，如果死锁过于频繁，则性能和效率必然大打折扣。数据库系统会自动检测死锁状况，并强行停止其中的一个事务以突破僵局 因为应用了这么多的锁机制，所以很容易呈现死锁景象 ，例如事务 A 可能在期待事务 B 开释它持有的锁， 而事务 B 在期待事务 A 开释它持有的锁。数据库系统会自动检测事务之间的死锁状况，并强行停止其中的一个事务以突破僵局，这样另一个能够持续向前执行 。而被停止的事务须要由应用层来重试。 MySQL 提供的锁依据加锁的范畴，MySQL 外面的锁大抵能够分成全局锁、表级锁和行级锁三类。 全局锁全局锁就是对整个数据库实例加锁。 给数据库实例加全局锁的命令：flush tables with read lock;（FTWRL） 开释锁的命令：unlock tables;（表级锁、行级锁开释也是这个命令） 加上全局锁之后，整个数据库处于只读状态，其余线程的以下语句会被阻塞： 数据更新语句（数据的增删改 insert、delete、update）数据定义语句（DDL、包含建表、批改表构造等）更新类事务的提交语句（更新类事务就是应用了相似 select * from t1 for update; 带 for update 的查问的事务）全局锁的典型应用场景是，做全库逻辑备份。也就是把整库每个表存成 .sql 类型的文件。 ...

以如下left join查问语句为范例： select * from t1 left join t2 on t1.c=t2.a ;以下初始化数据： 1 DROP TABLE IF EXISTS `t1`;2 CREATE TABLE `t1` (3 `a` int DEFAULT NULL,4 `b` varchar(20) DEFAULT NULL5 )6 INSERT INTO `t1` VALUES (1, 'a');7 INSERT INTO `t1` VALUES (1, 'b');8 INSERT INTO `t1` VALUES (4, 'a');9 INSERT INTO `t1` VALUES (5, 'a');10 11 DROP TABLE IF EXISTS `t2`;12 CREATE TABLE `t2` (13 `c` int DEFAULT NULL,14 `d` varchar(20) DEFAULT NULL15 )16 INSERT INTO `t2` VALUES (9, 'i');17 INSERT INTO `t2` VALUES (1, 'i');18 INSERT INTO `t2` VALUES (2, 'i');19 INSERT INTO `t2` VALUES (3, 'i');1.解决join的yacc入口在sys_yacc.yy文件内解析t1 left join t2 on t1.c=t2.a;对应解决地位 ...

天有不测风云，数据库有旦夕祸福。 后面写 Redo 日志的文章介绍过，数据库失常运行时，Redo 日志就是个累赘。 当初，终于到了 Redo 日志扬眉吐气，大显神通的时候了。 本文咱们一起来看看，MySQL 在解体复原过程中都干了哪些事件，Redo 日志又是怎么大显神通的。 本文介绍的解体复原过程，蕴含 server 层和 InnoDB，不波及其它存储引擎，内容基于 MySQL 8.0.29 源码。1. 概述MySQL 解体也是一次敞开过程，只是比失常敞开焦急了一些。 失常敞开时，MySQL 会做一系列收尾工作，例如：清理 undo 日志、合并 change buffer 缓冲区等操作。 具体会进行哪些收尾工作，取决于零碎变量 innodb_fast_shutdown 的配置。解体间接就是戛然而止，撂挑子不干了，还没来得及进行的那些收尾工作怎么办？ 那就只能期待下次启动的时候再干了，这就是本文要介绍的解体复原过程。 2. 读取两次写页面MySQL 一旦解体，Redo 日志就要去援救世界了（MySQL 就是它的世界），Redo 日志援救世界的形式就是把还没来得及刷盘的脏页复原到解体之前那一刻的状态。 尽管 Redo 日志可能用来复原数据页，但这是有前提条件的：数据页必须完整无缺的状态。 本文咱们把零碎表空间、独立表空间、undo 表空间中的页统称为数据页。如果数据页刚写了一半，MySQL 就戛然而止，这个数据页就损坏了，面对这种状况，Redo 日志也是巧妇难为无米之炊。 Redo 日志援救世界之路就要因为这个问题停滞不前吗？ 那显示是不能的，这就该轮到两次写上场了。 两次写的官网名字是 double write，它蕴含内存缓冲区和 dblwr 文件两个局部，InnoDB 脏页刷盘前，都会先把脏页写入内存缓冲区，再写入 dblwr 文件，胜利之后才会把网页刷盘。 两次写通过零碎变量 innodb_doublewrite 管制开启或敞开，本文内容基于该零碎变量的默认值 ON，示意开启两次写。如果网页写入内存缓冲区和 dblwr 文件的程中，MySQL 解体了，表空间中对应的数据页还是残缺的，下次启动时，不须要用两次写页面修复这个数据页。 如果脏页刷盘时，MySQL 解体了，表空间对应的数据页损坏了，下次启动时，利用 Redo 日志到数据页之前，须要用两次写页面修复这个数据页。 dblwr 文件 默认位于 MySQL 数据目录下： ...

环境OS: Ubuntu 20.04MySQL: 8.0.30步骤mysql -u rootmysql> use mysql;# 查看账号信息mysql> select user, host, authentication_string from user;# 设置任意 ip 可应用 root 连贯mysql> update user set host='%' where user='root';# 设置明码为 xxxxgrant all privileges on *.* to 'root'@'%' identified by 'xxxx' with grant option; 本文出自 qbit snap

介绍多版本并发管制多版本并发控制技术（Multiversion Concurrency Control，MVCC） 技术是为了解决问题而生的，通过 MVCC 咱们能够解决以下几个问题： 读写之间阻塞的问题：通过 MVCC 能够让读写相互不阻塞，即读不阻塞写，写不阻塞读，这样就能够晋升事务并发解决能力。升高了死锁的概率：这是因为 MVCC 没有应用锁，读取数据时并不需要加锁，对于写操作，也只锁定必要的行。解决一致性读的问题：一致性读也被称为快照读，当咱们查询数据库在某个工夫点的快照时，只能看到这个工夫点之前事务提交更新的后果，而不能看到这个工夫点之后事务提交更新的后果。MVCC 的思维MVCC 是通过数据行的历史版本来实现数据库的并发管制。 简略来说 MVCC 的思维就是保留数据的历史版本。这样一个事务进行查问操作时，就能够通过比拟版本号来判断哪个较新的版本对以后事务可见。 InnoDB 对 MVCC 的实现MVCC 没有正式的规范，所以在不同的 DBMS 中，MVCC 的实现形式可能是不同的。 InnoDB 对 MVCC 的实现次要是通过 版本链 + ReadView 构造实现。 版本链存储记录的多个版本先介绍聚簇索引记录的暗藏列，再介绍 Undo Log 版本链对于应用 InnoDB 存储引擎的表来说，它的聚簇索引记录中都蕴含 3 个暗藏列 db_row_id：暗藏的行 ID。在没有自定义主键也没有 Unique 键的状况下，会应用该暗藏列作为主键。db_trx_id：操作这个数据的事务 ID，也就是最初一个对该数据进行插入或更新的事务 ID。db_roll_ptr：回滚指针，也就是指向这个记录的 Undo Log 信息。Undo Log 中存储了回滚须要的数据。事务ID 事务执行过程中，只有在第一次真正批改记录时（比方进行 insert、delete、update 操作），才会被调配一个惟一的、枯燥递增的事务 ID，如果没有批改记录操作，依照肯定的策略调配一个比拟大的事务 ID，缩小调配事务 ID 的锁竞争。每当事务向数据库写入新内容时， 所写的数据都会被标记操作所属的事务的事务ID。 在 InnoDB 存储引擎中，版本链由数据行的 Undo Log 组成。 每次对数据行进行批改，都会将旧值记录到 Undo Log，算是该数据行的一个旧版本。 Undo Log 有两个重要的属性：db_roll_ptr、db_trx_id ...

一、介绍MySQL 次要提供的整数类型有 TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，其属性字段能够增加 AUTO_INCREMENT 自增约束条件。下表中列出了 MySQL 中的数值类型。 二、类型对应的存储范畴类型名称存储所占字节能存储整数的范畴正整数范畴TINYINT1-128〜1270 〜255SMALLINT2-32768〜327670〜65535MEDIUMINT3-8388608〜83886070〜16777215INT4-2147483648〜21474836470〜4294967295BIGINT8-9223372036854775808〜92233720368547758070〜18446744073709551615三、罕用的应用场景场景类型自增idINT,BIGINT一些枚举的场景TINYINT固定范畴TINYINT，SMALLINT

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。前言试验总结前言数据库的优化器相当于人类的大脑，大部分时候都能做出正确的决策，制订正确的执行打算，走出一条高效的路，然而它毕竟是基于某些固定的规定、算法来做的判断，有时候并没有咱们人脑思维灵便，当咱们确定优化器抉择执行打算谬误时该怎么办呢，语句上加hint，提醒它抉择哪条路是一种常见的优化办法。 咱们晓得Oracle提供了比拟灵便的hint提醒来批示优化器在多表连贯时抉择哪种表连贯形式，比方use_nl，no_use_nl管制是否应用Nest Loop Join，use_hash,no_use_hash管制是否应用hash join。 然而MySQL长期以来只有一种表连贯形式，那就是Nest Loop Join，直到MySQL8.0.18版本才呈现了hash join， 所以MySQL在管制表连贯形式上没有提供那么多丰盛的hint给咱们应用，hash_join与no_hash_join的hint只是惊鸿一瞥，只在8.0.18版本存在，8.0.19及前面的版本又将这个hint给废除了，那如果咱们想让两个表做hash join该怎么办呢？ 试验咱们来以MySQL8.0.25的单机环境做一个试验。建两个表，别离插入10000行数据，应用主键做这两个表的关联查问。 create table t1(id int primary key,c1 int,c2 int);create table t2(id int primary key,c1 int,c2 int);delimiter //CREATE PROCEDURE p_test()BEGINdeclare i int;set i=1;while i<10001 doinsert into t1 values(i,i,i);insert into t2 values(i,i,i);SET i = i + 1;end while;END;//delimiter ;查问一下两表应用主键字段关联查问时理论的执行打算，如下图所示： 查问一下两表应用非索引字段关联查问时理论的执行打算，如下图所示： 从执行打算能够看出，被驱动表的关联字段上有索引，优化器在抉择表连贯形式时会偏向于抉择Nest Loop Join，当没有可用索引时偏向于抉择hash join。 基于这一点那咱们能够应用no_index提醒来禁止语句应用关联字段的索引。 从下面的执行打算能够看出应用no_index提醒后，优化器抉择了应用hash join。 当索引的选择性不好时，优化器抉择应用索引做Nest Loop Join是效率是很低的。 咱们将试验的两个表中c1列的数据做一下更改,使其选择性变差，并在c1列上建一般索引。 update t1 set c1=1 where id<5000;update t2 set c1=1 where id<5000;create index idx_t1 on t1(c1);create index idx_t2 on t2(c1);当咱们执行sql ： ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。1.论断后行无论ibp（innodb_buffer_pool_size）是否短缺，MySQL的性能都远不如GreatSQL。MySQL的性能均匀约为GreatSQL的70%（最高84.5%，最低61.7%）。在ibp充沛的状况下，随着并发数的减少，MySQL并没有体现出该有的性能晋升，反倒掉头向下，可见还是不够稳固。在ibp不够的状况下，GreatSQL开启thread pool性能有所晋升；当ibp短缺的状况下，区别就不大了。MySQL vs GreatSQL性能数据比照 48G96G144G192GavgMySQL vs GreatSQL0.61730.7350.7210.84490.7295各数据库版本别离为 MySQL 8.0.30 MySQL Community Server - GPLGreatSQL 8.0.25-16 GreatSQL, Release 16, Revision 8bb0e5af2972.测试后果数据2.1 ibp=48GTPS8th16th32th64th128thGreatSQL-thdpool969.161324.211661.572007.982331.4GreatSQL873.061146.851371.341509.81699.19MySQL686.14846.5915.151073.951439.29P.S，后缀加上 thdpool 示意启用了thread pool。 QPS8th16th32th64th128thGreatSQL-thdpool19383.226484.1433231.4940159.5646627.89GreatSQL17461.1622937.1427426.8730196.0233983.78MySQL13722.816929.9418303.032147928785.7 2.2 ibp=96GTPS8th16th32th64th128thGreatSQL-thdpool1074.571407.541706.352206.062810.39GreatSQL1013.21198.51546.532033.042419.47MySQL751.7986.111218.871778.672065.69QPS8th16th32th64th128thGreatSQL-thdpool21491.4628150.733412744121.256207.88GreatSQL20264.0423969.9730930.5640660.8348389.42MySQL15034.1119722.2724377.4735573.3941313.8 2.3 ibp=144GTPS8th16th32th64th128thGreatSQL-thdpool1059.461422.721853.242710.313481.66GreatSQL857.281327.671767.782660.83148.06MySQL857.051149.792038.32516.412510.15QPS8th16th32th64th128thGreatSQL-thdpool21189.1728454.337064.7954206.1369633.25GreatSQL17145.5226553.4835355.4753215.8962961.17MySQL17140.9622995.7340765.9550328.2950202.93 2.4 ibp=192GTPS8th16th32th64th128thGreatSQL1406.861316.022144.174114.553310.67GreatSQL-thdpool1391.21247.932085.814053.763113.97MySQL1367.312629.752940.512687.482797.06QPS8th16th32th64th128thGreatSQL28137.1926320.4342883.458229166213.47GreatSQL-thdpool27823.924958.6841716.1681075.2162279.48MySQL27346.1852595.0158810.1853749.6355941.29 2.5 GreatSQL不同ibp下的数据GreatSQL TPS8th16th32th64th128th QPS8th16th32th64th128thGreatSQL-thdpool(48G)969.161324.211661.572007.982331.4 GreatSQL-thdpool(48G)19383.226484.1433231.4940159.5646627.89GreatSQL(48G)873.061146.851371.341509.81699.19 GreatSQL(48G)17461.1622937.1427426.8730196.0233983.78GreatSQL-thdpool(96G)1074.571407.541706.352206.062810.39 GreatSQL-thdpool(96G)21491.4628150.733412744121.256207.88GreatSQL(96G)1013.21198.51546.532033.042419.47 GreatSQL(96G)20264.0423969.9730930.5640660.8348389.42GreatSQL-thdpool(144G)1059.461422.721853.242710.313481.66 GreatSQL-thdpool(144G)21189.1728454.337064.7954206.1369633.25GreatSQL(144G)857.281327.671767.782660.83148.06 GreatSQL(144G)17145.5226553.4835355.4753215.8962961.17GreatSQL(192G)1406.861316.022144.174114.553310.67 GreatSQL(192G)28137.1926320.4342883.458229166213.47GreatSQL-thdpool(192G)1391.21247.932085.814053.763113.97 GreatSQL-thdpool(192G)27823.924958.6841716.1681075.2162279.48 2.6 MySQL不同ibp下的数据MySQL TPS8th16th32th64th128th QPS8th16th32th64th128thMySQL(48G)686.14846.5915.151073.951439.29 MySQL(48G)13722.816929.9418303.032147928785.7MySQL(96G)751.7986.111218.871778.672065.69 MySQL(96G)15034.1119722.2724377.4735573.3941313.8MySQL(144G)857.051149.792038.32516.412510.15 MySQL(144G)17140.9622995.7340765.9550328.2950202.93MySQL(192G)1367.312629.752940.512687.482797.06 MySQL(192G)27346.1852595.0158810.1853749.6355941.29 ...

介绍弱隔离级别为什么要有弱隔离级别如果两个事务操作的是不同的数据， 即不存在数据依赖关系， 则它们能够平安地并行执行。然而当呈现某个事务批改数据而另一个事务同时要读取该数据， 或者两个事务同时批改雷同数据时， 就会呈现并发问题。 在应用程序的开发中，咱们通常会利用锁进行并发管制，确保临界区的资源不会呈现多个线程同时进行读写的状况，这其实就对应了事务的最高隔离级别：可串行化。可串行化隔离意味着数据库保障事务的最终执行后果与串行 （即一次一个， 没有任何并发） 执行后果雷同。 那么为什么应用程序中能够提供可串行化的隔离级别，而数据库却不能呢？其实根本原因就是应用程序对临界区大多是内存操作，而数据库要保障持久性（Durability），须要把临界区的数据长久化到磁盘，可是磁盘操作比内存操作要慢好几个数量级，一次随机拜访内存、 固态硬盘 和 机械硬盘，对应的操作工夫别离为几十纳秒、几十微秒和几十毫秒，这会导致持有锁的工夫变长，对临界区资源的竞争将会变得异样强烈，数据库的性能则会大大降低。 所以，数据库的研究者就对事务定义了隔离级别这个概念，也就是在高性能与正确性之间做一个衡量，相当于明确地通知使用者，咱们提供了正确性差一点然而性能好一点的模式，以及正确性好一点然而性能差一点的模式，使用者能够依据本人的业务场景来抉择一个适合的隔离级别。 弱隔离级别带来的危险弱隔离级别就是非串行化隔离级别。 较弱的隔离级别， 它能够避免某些并发问题，但并非全副的并发问题。 应用这些弱隔离级别，事务并发执行时，可能会出现异常状况，带来一些难以捉摸的隐患，因而，咱们须要理解弱隔离级别存在的并发问题以及如何防备存在的并发问题。 而后， 咱们就能够应用所把握的工具和办法来构建正确、 牢靠的利用。 各种隔离级别SQL-92 规范定义了 4 种事务的隔离级别：读未提交（Read Uncommitted）、读已提交（Read Committed）、可反复读（Repeatable Read）和可串行化（Serializable），在前面的倒退过程中，又减少了快照隔离级别（Snapshot Isolation）。 不同的弱隔离级别解决了不同的并发问题（正确性问题），同时也存在一些并发问题。 上面是各种隔离级别及对应的并发问题： ✔️代表该隔离级别已解决该并发问题；❌代表该隔离级别未解决该并发问题。 脏写脏读不可反复读更新失落幻读写歪斜读未提交✔️❌❌❌❌❌读已提交✔️✔️❌❌❌❌可反复读✔️✔️✔️✔️❌❌快照✔️✔️✔️✔️✔️❌可串行化✔️✔️✔️✔️✔️✔️SQL 规范对隔离级别的定义还是存在一些缺点，某些定义不置可否，不够准确，且不能做到与实现无关，所以下面的表格只是对常见的隔离级别并发问题的定义，你能够把它当成一个通用的规范参考。 当你应用某一个数据库时，须要读一下它的文档，确定好它的每一种隔离级别具体的并发问题。 MySQL 的默认隔离级别为：可反复读。Oracle、PostgreSQL 的默认隔离级别为：读已提交事务并发执行时，存在的并发问题如果两个事务操作的是不同的数据， 即不存在数据依赖关系， 则它们能够平安地并行执行。然而当呈现某个事务批改数据而另一个事务同时要读取该数据， 或者两个事务同时批改雷同数据时， 就会呈现并发问题。 并发问题总结： 脏写：一个事务笼罩了其余事务尚未提交的写入。脏读：一个事务读到了其余事务尚未提交的写入。不可反复读：一个事务内，屡次读取同一个记录的后果不一样。更新失落：两个事务同时执行“读－批改－写回”操作序列，事务 A 笼罩了 事务 B 的写入，但又没有蕴含 事务 B 批改后的值，最终导致了局部更新数据产生了失落。幻读：一个事务内，屡次读取满足指定条件的数据，读出来的后果不一样。写歪斜：事务首先查问数据，依据返回的后果而作出某些决定，而后批改数据库。当事务提交时，反对决定的前提条件已不再成立。脏写一个事务笼罩了其余事务尚未提交的写入。 脏读一个事务读到了其余事务尚未提交的写入。 举例说明脏读 事务 B 批改了 x，在事务 B 提交之前，事务 A 读到了 x 批改后的数据。这时事务 B 回滚了，相当于事务 A 读到了一个有效的数据（未理论提交到数据库中的数据），事务 A 的读就是脏读。 ...

MySql系列（1）MySqL基础架构 Server层Server 层包含连接器、查问缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核 心服务性能，以及所有的内置函数（如日期、工夫、数学和加密函数等），所有跨存储引擎 的性能都在这一层实现，比方存储过程、触发器、视图等 存储引擎层存储引擎层负责数据的存储和提取。其架构模式是插件式的，反对 InnoDB、MyISAM、 Memory 等多个存储引擎（ InnoDB为默认存储引擎），不同的存储引擎共用一个Server 层。 查问流程 各个组件的作用连接器mysql -h$ip -P$port -u$user -p$passWord连接器负责跟客户端建设连贯、获取权限、维持和治理连贯。连贯命令中的 mysql 是客户端工具，用来跟服务端建设连贯。在实现TCP 握手后， 连接器开始认证身份。 如果用户名或明码不对，收到Access denied for user谬误，客户端程序完结执行。如果用户名明码认证通过，连接器会到权限表外面查问权限。之后，这个连贯外面的权限判断逻辑，都将依赖于此时读到的权限这就意味着，一个用户胜利建设连贯后，即便你用管理员账号对这个用户的权限做了批改， 也不会影响曾经存在连贯的权限。批改实现后，只有再新建的连贯才会应用新的权限设置。 连贯实现后，如果你没有后续的动作，这个连贯就处于闲暇状态。 客户端如果太长时间没动静，连接器就会主动将它断开。这个工夫是由参数 wait_timeout 管制的，默认值是 8 小时。 如果在连贯被断开之后，客户端再次发送申请的话，就会收到一个谬误揭示： Lost connection to MySQL server during query。这时候如果你要持续，就须要重连，而后 再执行申请了。 数 据库外面，长连贯是指连贯胜利后，如果客户端继续有申请，则始终应用同一个连贯。短 连贯则是指每次执行完很少的几次查问就断开连接，下次查问再从新建设一个。 建设连贯的过程通常是比较复杂的，所以我倡议你在应用中要尽量减少建设连贯的动作，也就是尽量应用长连贯。 然而全副应用长连贯后，你可能会发现，有些时候 MySQL 占用内存涨得特地快，这是因 为 MySQL 在执行过程中长期应用的内存是治理在连贯对象外面的。这些资源会在连贯断 开的时候才开释。所以如果长连贯累积下来，可能导致内存占用太大，被零碎强行杀掉 （OOM），从景象看就是 MySQL 异样重启了。 怎么解决这个问题呢？你能够思考以下两种计划。 定期断开长连贯。应用一段时间，或者程序外面判断执行过一个占用内存的大查问后， 断开连接，之后要查问再重连。如果你用的是 MySQL 5.7 或更新版本，能够在每次执行一个比拟大的操作后，通过执行 mysql_reset_connection 来从新初始化连贯资源。这个过程不须要重连和从新做权限验证，然而会将连贯复原到刚刚创立完时的状态。查问缓存MySQL接管到一个查问申请后，会先到查问缓存查问，如果查问缓存中有要查问的key-value （key是查问的语句，value是查问的后果），间接返回value。（之前执行过的语句及其后果可能会以 key-value 对的模式被间接缓存在内存中） 如果语句不在查问缓存中，就会持续前面的执行阶段。执行实现后，执行后果会被存入查问缓存中。如果查问命中缓存，MySQL 不须要执行前面的简单操作，就能够直 接返回后果，这个效率会很高。 ...

本篇文章次要介绍 Redo Log 和 Undo Log： 利用 Redo Log 和 Undo Log 实现本地事务的原子性、持久性Redo Log 的写回策略Redo Log Buffer 的刷盘机会日志：Redo Log 和 Undo Log · 语雀 (yuque.com) 通过写入日志来保障原子性、持久性是业界的支流做法。 介绍 Redo Log 和 Undo LogRedo Log 是什么：Redo Log 被称为重做日志。 Undo Log 是什么：Undo Log 被称为撤销日志、回滚日志。 技术是为了解决问题而生的，通过 Redo Log 咱们能够实现解体复原，避免数据更新失落，保障事务的持久性。也就是说，在机器故障复原后，零碎依然可能通过 Redo Log 中的信息，长久化曾经提交的事务的操作后果。 技术是为了解决问题而生的，Undo Log 的作用 / 性能： 事务回滚：能够对提前写入的数据变动进行擦除，实现事务回滚，保障事务的原子性。实现 MVCC 机制：Undo Log 也用于实现 MVCC 机制，存储记录的多个版本的 Undo Log，造成版本链。Undo Log 中存储了回滚须要的数据。在事务回滚或者解体复原时，依据 Undo Log 中的信息对提前写入的数据变动进行擦除。 Redo Log 和 Undo Log 都是用于实现事务的个性，并且都是在存储引擎层实现的。因为只有 InnoDB 存储引擎反对事务，因而只有应用 InnoDB 存储引擎的表才会应用 Redo Log 和 Undo Log。 ...

作者：王向 爱可生 DBA 团队成员，负责公司 DMP 产品的运维和客户 MySQL 问题的解决。善于数据库故障解决。对数据库技术和 python 有着浓重的趣味。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 前言最近解决了一个比拟根底的问题故障，因为排查过程挺有意思，于是就以此为素材写出了本篇文章。 故障现场防火墙什么的均失常然而无奈被近程拜访到。简略的应用客户端登录了一下。 ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1' (111)依据以往教训大脑中浮现了几个常见的排查此类故障手法 1.排查过程存在 [root@wx ~]# ps -ef|grep [m]ysql mysql 25973 1 1 8月30 ? 02:43:20 /mysqldata/mysql/base/8.0.24/bin/mysqld --defaults-file=/mysqldata/mysql/etc/3308/my.cnf --daemonize --pid-file=/mysqldata/mysql/data/3308/mysqld.pid --user=mysql --socket=/mysqldata/mysql/data/3308/mysqld.sock --port=33082.排查端口绑定状况，竟然没有绑定端口 [root@wx ~]# lsof -i:3308[root@wx ~]# ss -nltp|grep 33083.查看启动日志发现，监听端口等于0 2022-09-06T07:30:41.090649-00:00 0 [Note] [MY-010304] [Server] Skipping generation of SSL certificates as certificate files are present in data directory. 2022-09-06T07:30:41.094320-00:00 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed. 2022-09-06T07:30:41.094806-00:00 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel. 2022-09-06T07:30:41.095177-00:00 0 [Note] [MY-010308] [Server] Skipping generation of RSA key pair through --sha256_password_auto_generate_rsa_keys as key files are present in data directory. 2022-09-06T07:30:41.095500-00:00 0 [Note] [MY-010308] [Server] Skipping generation of RSA key pair through -- caching_sha2_password_auto_generate_rsa_keys as key files are present in data directory. 2022-09-06T07:30:41.124942-00:00 0 [System] [MY-010931] [Server] /mysqldata/mysql/base/8.0.24/bin/mysqld: ready for connections. Version: '8.0.24' socket: '/mysqldata/mysql/data/3306/mysqld.sock' port: 0 MySQL Community Server - GPL. ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。前言之前的大多数人分页采纳的都是这样： SELECT * FROM table LIMIT 20 OFFSET 50可能有的小伙伴还是不太分明LIMIT和OFFSET的具体含意和用法，我介绍一下： LIMIT X 示意: 读取 X 条数据LIMIT X, Y 示意: 跳过 X 条数据，读取 Y 条数据LIMIT Y OFFSET X 示意: 跳过 X 条数据，读取 Y 条数据对于简略的小型应用程序和数据量不是很大的场景，这种形式还是没问题的。 然而你想构建一个牢靠且高效的零碎，肯定要一开始就要把它做好。 明天咱们将探讨曾经被宽泛应用的分页形式存在的问题，以及如何实现高性能分页。 LIMIT和OFFSET有什么问题OFFSET 和 LIMIT 对于数据量少的我的项目来说是没有问题的，然而，当数据库里的数据量超过服务器内存可能存储的能力，并且须要对所有数据进行分页，问题就会呈现，为了实现分页，每次收到分页申请时，数据库都须要进行低效的全表遍历。 全表遍历就是一个全表扫描的过程，就是依据双向链表把磁盘上的数据页加载到磁盘的缓存页里去，而后在缓存页外部查找那条数据。这个过程是十分慢的，所以说当数据量大的时候，全表遍历性能非常低，工夫特地长，应该尽量避免全表遍历。这意味着，如果你有 1 亿个用户，OFFSET 是 5 千万，那么它须要获取所有这些记录 (包含那么多基本不须要的数据)，将它们放入内存，而后获取 LIMIT 指定的 20 条后果。 为了获取一页的数据：10万行中的第5万行到第5万零20行须要先获取 5 万行，这么做十分低效！ 初探LIMIT查问效率数据筹备本文测试应用的环境： [root@zhyno1 ~]# cat /etc/system-releaseCentOS Linux release 7.9.2009 (Core)[root@zhyno1 ~]# uname -aLinux zhyno1 3.10.0-1160.62.1.el7.x86_64 #1 SMP Tue Apr 5 16:57:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux测试数据库采纳的是（存储引擎采纳InnoDB，其它参数默认）： ...

在之前的文章提到过一个问题，而且网上很多文章也是这么说的，前几天有人对这个问题提出了一点不同的意见，抱着审慎的态度做了一个测试。 问题是这样的：COMPACT格局下，NULL值列表是否肯定会占用一个字节的空间？ 对于这个问题，我的答复和网上很多答复是一样的，如果都是NOT NULL就不会有NULL值列表，所以不会占用，反之则会占用。 明天，就对这个问题做一个验证。 存储空间先回顾一下之前的常识。 数据库中的一行记录在最终磁盘文件中也是以行的形式来存储的，对于InnoDB来说，有4种行存储格局：REDUNDANT、 COMPACT、 DYNAMIC 和 COMPRESSED。 InnoDB的默认行存储格局是COMPACT，存储格局如下所示，虚线局部代表可能不肯定会存在。 变长字段长度列表：有多个字段则以逆序存储，咱们只有一个字段所有不思考那么多，存储格局是16进制，如果没有变长字段就不须要这一部分了。 NULL值列表：用来存储咱们记录中值为NULL的状况，如果存在多个NULL值那么也是逆序存储，并且必须是8bit的整数倍，如果不够8bit，则高位补0。1代表是NULL，0代表不是NULL。如果都是NOT NULL那么这个就存在了，每多8个NULL会多占用一个字节的空间。 ROW_ID：一行记录的惟一标记，没有指定主键的时候主动生成的ROW_ID作为主键。 TRX_ID：事务ID。 ROLL_PRT：回滚指针。 最初就是每列的值。 为了阐明分明这个存储格局的问题，我弄张表来测试，这张表只有c1字段是NOT NULL，其余都是能够为NULL的。 可变字段长度列表：c1和c3字段值长度别离为1和2，所以长度转换为16进制是0x01 0x02，逆序之后就是0x02 0x01。 NULL值列表：因为存在容许为NULL的列，所以c2,c3,c4别离为010，逆序之后还是一样，同时高位补0满8位，后果是00000010。 其余字段咱们临时不论他，最初第一条记录的后果就是，当然这里咱们就不思考编码之后的后果了。 这样就是一个残缺的数据行数据的格局，反之，如果咱们把所有字段都设置为NOT NULL，并且插入一条数据a,bb,ccc,dddd的话，存储格局应该这样： 测试这里存在一点点小问题，首先我看到了阿里的数据库月报中的测试和形容。 从这段代码看出之前的猜测，也就是并不是Null标记位只固定占用1个字节==，而是以8为单位，满8个null字段就多1个字节，不满8个也占用1个字节，高位用0补齐他的意思是无论如何都会占用一个字节，然而看了他的测试，发现他的表是容许NULL的，所以他的这个测试无法说明咱们要验证的问题。 依照网上大佬给出的计划，创立表，而后插入测试数据，数据库中存在NULL值。 CREATE TABLE test ( c1 VARCHAR ( 32 ), c2 VARCHAR ( 32 ), c3 VARCHAR ( 32 ), c4 VARCHAR ( 32 ) ) ENGINE = INNODB row_format = compact;应用命令SHOW VARIABLES LIKE 'datadir'找到 ibd 文件地位。 ...

Mac哪款数据库管理工具好用呢？DBeaverEE for Mac是一款运行在MacOS上通用的数据库管理工具。易用性是DBeaverEE的次要指标，反对 MySQL, PostgreSQL, Oracle等罕用数据库。操作简略，功能强大。 DBeaverEE for Mac(数据库管理工具)

作者：袁琳铸 爱可生 DBLE 团队开发成员，次要负责 DBLE 需要开发，故障排查和社区问题解答。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 背景在客户的生产环境中，dble.log 时常呈现 no handler 日志。尽管没有影响客户业务的失常应用，然而须要考察下这个日志打印的起因是什么以及什么样的场景才会打印该日志。 剖析首先对 dble 和 mysql 的日志进行剖析，看看能不能从日志中找到可用信息 dble日志日志中有 no handler 日志和 dble 收到 mysql 发送的 fin 包打印的 stream closed by peer 的日志，并无其余异样。 2022-09-02 03:25:23.450 INFO [0-backendWorker] (com.actiontech.dble.net.response.DefaultResponseHandler.closeNoHandler(DefaultResponseHandler.java:116)) - no handler bind in this service MySQLResponseService[isExecuting = false attachment = null autocommitSynced = true isolationSynced = true xaStatus = 0 isDDL = false complexQuery = false] with response handler [null] with rrs = [null] with connection BackendConnection[id = 342 host = 10.186.62.41 port = 3312 localPort = 51886 mysqlId = 677 db config = dbInstance[name=M1,disabled=false,maxCon=1000,minCon=10]2022-09-02 03:25:23.450 INFO [0-backendWorker] (com.actiontech.dble.net.connection.BackendConnection.close(BackendConnection.java:125)) - connection id 342 mysqlId 677 close for reason no handler2022-09-02 03:25:23.450 INFO [1-NIOBackendRW] (com.actiontech.dble.net.service.AbstractService.beforeInsertServiceTask(AbstractService.java:170)) - prepare close for conn.conn id 342,reason [stream closed by peer]2022-09-02 03:25:23.450 INFO [0-backendWorker] (com.actiontech.dble.net.connection.AbstractConnection.closeImmediatelyInner(AbstractConnection.java:169)) - connection id close for reason [no handler] with connection BackendConnection[id = 342 host = 10.186.62.41 port = 3312 localPort = 51886 mysqlId = 677 db config = dbInstance[name=M1,disabled=false,maxCon=1000,minCon=10]mysql 日志存在连贯超时而敞开连贯的日志，并无其余异样 ...

数据库是一个综合零碎，其背地是倒退了几十年的数据库实践。兴许你会感觉数据库并不难，因为你能够熟练地写出SQL，也能够在各个客户端里玩得熟能生巧。但就以最常见的MySQL为例，作为程序员，你在应用MySQL的过程中，是不是已经遇到过相似的问题： 为什么我的count(*)这么慢？为什么我建了索引，却基本没有成果？为什么我只查一行的语句，也执行这么慢？MySQL对于大表要怎么优化？前段时间，有个大佬面上了某大厂，送给我一批学习材料，整理出来，就造成了以下文档（数据库方面），次要包含MySQL面试题、MySQL根底到高级到调优笔记、MySQL常识总结、MySQL性能调优与架构设计解析文档，已打包好，文末有获取形式。 MySQL面试题 MySQL根底到高级调优笔记学习笔记次要分为12个模块，主目录如下： 因为篇幅字数起因，在这只展现具体目录及内容的截图了，有须要的敌人能够在文末收费获取！ MySQL常识总结次要从六个方面进行总结：MySQL根底模块、MySQL索引模块、MySQL事务模块、MySQL日志模块、MySQL日志篇、MySQL性能优化模块………… 上图： MySQL性能调优与架构设计解析文档一、根底篇 二、性能优化篇 三、架构设计篇 因为篇幅字数起因，以上无关MySQL的学习材料，曾经打包好了，有须要的敌人间接查看下图获取吧！！

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。作者介绍：孙黎，GreatDB 认证DBA问题景象形容测试MySQL单机时，无心发现，MySQL 8.0的 ib_logfilesN的显示如下： ll ib_logfile*-rw-r----- 1 greatsql greatsql 134217728 8月 4 18:36 ib_logfile0-rw-r----- 1 greatsql greatsql 134217728 7月 27 17:31 ib_logfile1-rw-r----- 1 greatsql greatsql 134217728 8月 4 18:03 ib_logfile2-rw-r----- 1 greatsql greatsql 134217728 8月 4 18:36 ib_logfile3其中ib_logfile0、iblogfile3的 最近改变工夫为：2022-08-04 18:36 印象中，MySQL 8.0对 redo 做了大量优化，难道刷盘也做了扭转？ 重现景象连忙登录到MySQL 从新执行一条insert，再察看一下。 1 ib_logfile*2 -rw-r----- 1 greatsql greatsql 134217728 8月 9 22:55 ib_logfile03 -rw-r----- 1 greatsql greatsql 134217728 7月 27 17:31 ib_logfile14 -rw-r----- 1 greatsql greatsql 134217728 8月 4 18:03 ib_logfile25 -rw-r----- 1 greatsql greatsql 134217728 8月 9 22:55 ib_logfile36 [#3#root@greatsql82 /data/mysql8023/data 22:55:45]3 stat ib_logfile07 文件："ib_logfile0"`8 大小：134217728 块：262144 IO 块：4096 一般文件9 设施：fd00h/64768d Inode：75740704 硬链接：110 权限：(0640/-rw-r-----) Uid：( 1000/ greatsql) Gid：( 1000/ greatsql)11 最近拜访：2022-08-04 19:22:32.746184752 +080012 最近更改：2022-08-09 22:55:40.166964294 +080013 最近改变：2022-08-09 22:55:40.166964294 +080014 创立工夫：-`15 [#4#root@greatsql82 /data/mysql8023/data 22:56:13]4 stat ib_logfile316 文件："ib_logfile3"17 大小：134217728 块：262144 IO 块：4096 一般文件18 设施：******* Inode：75740707 硬链接：119 权限：(0640/-rw-r-----) Uid：( 1000/ greatsql) Gid：( 1000/ greatsql)20 最近拜访：2022-08-04 19:22:48.510210526 +080021 最近更改：2022-08-09 22:55:39.741963331 +080022 最近改变：2022-08-09 22:55:39.741963331 +080023 创立工夫：-在MySQL端执行一个事务后，能够看到ib_logfile0、iblogfile3都产生了扭转，iblogfile3先扭转，iblogfile0后扭转，且改变工夫相差不到0.42s ...

事务机制 · 语雀 (yuque.com) 介绍事务技术是为了解决问题而生的，通过事务咱们能够解决以下问题： 多个操作不是一个整体操作，呈现了局部执行胜利的状况，导致数据的状态不统一问题（原子性）一组操作只有局部实现，没有全副实现，然而此时能够拜访到数据的不统一状态问题（可见性问题，隔离性）两组操作并发执行，导致的并发问题......事务存在的意义：保证系统中的数据是正确的，不同数据间不会产生矛盾，也就是保证数据状态的一致性。 事务是什么（事务的概念）：事务是一个或多个操作的组合操作，并且事务对这个组合操作提供一个保障，如果这个组合操作执行之前的数据是统一的（即正确的），那么执行组合操作之后的数据也应该是统一的。不管这个组合操作执行的过程中，产生了系统故障，还是在这个组合操作执行的过程中，是否与其余事务一起执行。（这也对应了下面提到的事务要解决的问题） 即便没有事务反对， 或者下层利用仍然能够工作， 然而在没有原子性保障时， 错误处理就会异样简单， 而不足隔离性则容易呈现并发性方面的各种奇怪问题。 如果咱们冀望多个操作同时胜利或者失败，并且冀望多组操作之间互相隔离（不相互影响），那么就须要通过一个事务来执行。 Oracle 是反对事务的。而 MySQL 中只有 InnoDB 存储引擎反对事务，MyISAM、Memory、Merge 等存储引擎都不反对事务。 对事务进行管制应用事务有两种形式，别离为：隐式事务和显式事务。 隐式事务隐式事务又称主动提交事务，顾名思义就是当执行完一条 SQL 语句后，会主动 commit 提交。 MySQL 默认应用的就是隐式事务。 显式事务如果咱们想敞开主动提交，能够应用下边的两种办法之一： 显式的的应用 start transaction 或者 begin 语句开启一个事务。这样，在本次事务提交或者回滚之前会临时敞开主动提交性能。把零碎变量 autocommit 的值设置为 off 或者 0：set autocommit = off。这样，本次会话将敞开主动提交性能。不管是否显式的开启一个事务，每次执行事务都须要应用 commit 进行提交让事务失效，应用 rollback 对事务进行回滚。须要留神的是：设置 autocommit 的值，只针对以后会话无效。 autocommit 参数的取值有 2 种可能： autocommit = 0：勾销主动提交性能autocommit = 1：应用主动提交性能（默认值）start transaction 比 begin 语句弱小的一点是：能够在 start transaction 语句前面追随几个修饰符，用来设置事务的拜访模式，修饰符如下所示： read only：标识以后事务是一个只读事务。即该事务内的操作只能读取数据，而不能批改数据。read write：标识以后事务是一个读写事务。即该事务内的操作既能够读取数据，也能够批改数据。with consistent snapshot：启动一致性读。即执行该命令后立刻生成 ReadView，而不必等到第一条 select 语句执行。如果咱们想在 start transaction 前面追随多个修饰符的话，应用逗号将修饰符离开即可， ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。一. XDP Socket示例解析源码参见：https://github.com/xdp-projec...该示例演示了如何通过BPF将网络数据包从XDP Hook点旁路到用户态的XDP Socket，解析过程中为突出重点，将只关注重点代码段，一些函数会被精简，比方：错误处理等二. BPF 程序 af_xdp_kern.cBPF程序是运行在内核态的一段代码，如下：struct bpf_map_def SEC("maps") xsks_map = { .type = BPF_MAP_TYPE_XSKMAP, .key_size = sizeof(int), .value_size = sizeof(int), .max_entries = 64, /* Assume netdev has no more than 64 queues */};SEC("xdp_sock")int xdp_sock_prog(struct xdp_md *ctx){ int index = ctx->rx_queue_index; if (bpf_map_lookup_elem(&xsks_map, &index)) return bpf_redirect_map(&xsks_map, index, 0); return XDP_PASS;}struct bpf_map_def SEC("maps") xsks_map： 定义了一个BPF_MAP_TYPE_XSKMAP类型的映射表，当采纳SEC("maps")形式来显示定义时，将在生成的bpf指标文件的ELF格局中看到相干形容，当BPF程序被加载到内核时，会主动创立名为“xsks_map”的描述符， 用户态可通过查找“xsks_map”来获取该map的描述符，这样用户态和内核BPF程序就能够独特拜访该maptype = BPF_MAP_TYPE_XSKMAP：指定该map的类型，它与bpf_redirect_map() 联合应用以将收到的帧传递到指定套接字key_size = sizeof(int)，value_size = sizeof(int)：指定key，value长度针对以上key，value须要阐明一下：对于BPF_MAP_TYPE_XSKMAP类型的map，value必须是XDP socket描述符，key必须是int类型，起因在于bpf_redirect_map()的第二个参数，参见上面2.10max_entries = 64：指定map最多存储64个元素SEC("xdp_sock")：指定prog函数符号，应用层可通过查找"xdp_sock"加载该prog，并绑定到指定网卡int xdp_sock_prog(struct xdp_md *ctx)：当网卡收到数据包时，会在xdp hook点调用该函数int index = ctx->rx_queue_index： 获取该数据包来自网卡到哪个rx队列ID，ctx有许多成员，比方：网卡ID，数据帧等等if (bpf_map_lookup_elem(&xsks_map, &index))： 判断xsks_map是否存在key为index（即rx队列号）的数据，留神，这里实际上就是判断该网卡是否绑定了xdp Socketbpf_redirect_map(&xsks_map, index, 0)：bpf_redirect_map函数作用就是重定向，比方：将数据重定向到某个网卡，CPU， Socket等等；当bpf_redirect_map函数的第一个参数的map类型为BPF_MAP_TYPE_XSKMAP时，则示意将数据重定向到XDP Scoket ...

春节长假某日，阳光明媚，春暖花开，恰逢冬奥会揭幕，想着肯定是一个黄道吉日，必能逆风逆水。没想到却遇到一个有点小挫折的客户报障。 故障起因 故障起因是客户前一天从自建 MySQL 迁徙到云上 RDS，在执行某个并发较高的业务时呈现了大量锁期待，客户过后降级了实例到最高规格，但故障仍旧。客户反馈降级后的实例规格比自建实例高了一倍，自建实例上从未产生过相似状况。后客户依据过后的业务故障模拟了现场，次要是并发执行如下存储过程的时候性能很差： 初步诊断 从存储过程的逻辑看，比较简单，次要波及两个 SQL，一个从表 t（暗藏了实在表名）中 meeting_id 依据传入参数值查问，具体的入参由字符型变量 p_meeting_id 带入；另外一个依据 meeting_id 和刚查出的 phone_id 去更新 t 中的 phone_id 为 phone_id+3。表 t 数据量约 40w 左右。 第一感觉这是个简略问题，预计两个 SQL 的 meeting_id 索引没有失效，查问表上索引后果然发现 meeting_id 和 phone_id 上没有索引，倡议客户在两个字段上别离创立了索引，且 meeting_id 为主键。此时用户执行模仿的并发脚本反馈速度有了显著晋升，200 个并发最高执行工夫 40s 左右，但模仿 500 个并发的时候，超过了 8 分钟还没有执行完。用户反馈在自建 MySQL 上并发 500 执行都是秒级实现。此时在控制台看，这个存储过程在慢查问日志中批量呈现，且扫描行数微小，客户端曾经齐全 hang 住: 进一步优化 尽管优化有了初步的成果， 但间隔客户自建环境性能形容还差距很大，因为并发高， 从监控看测试期间 CPU 到了 100%，狐疑参数 innodb_thread_concurrency 的设置可能不当。此参数的作用是管制 InnoDB 的并发线程下限。也就是说，一旦并发线程数达到这个值，InnoDB 在接管到新申请的时候，就会进入期待状态，直到有线程退出。RDS 默认值为 0，也就是没有限度下限，在高并发的场景下可能会产生较多的上下文切换，导致 CPU 升高。和客户征询了一下，他们自建环境的值设置为 32，倡议他们将 RDS 的值也改为 32 再看看成果。客户很快反馈，批改后确实有成果，500 个并发在 3 分钟内实现，没有再产生 hang 住不动的状况，性能有了进一步的晋升。但参数 innodb_thread_concurrency 进一步调整成果不显著。 ...

我应用的是centos7.9 1.批改数据库配置文件, 使之登录不须要明码此操作须要具备服务器 root 账户权限 1.1切换Linux零碎的 root 用户 注：如果以后应用的是root账户，即不须要再切换 # su - 1.2定位配置文件地位 # locate my.cnf3应用 vi 工具关上配置文件                # vi /etc/my.cnf                在文件内容 [mysqld] 下方增加“跳过明码登录”的代码skip-grant-tables ，保留后退出。 4确认配置文件内容曾经批改 通过cat命令查看my.cnf 配置文件内容。#cat /etc/my.cnf 2.重新启动Mysql服务 2.1在linux中，执行上面命令，重启mysql服务(服务名可能不一样会导致报错，按本人mysql服务名为主) # systemctl restart mysqld 2.2重启实现能够通过查看状态命令进行验证        # systemctl status mysqld3.从新登录 MySQL 查看是否须要明码进行登录        3.1确认不须要明码能够登录 MySQL        在Linux中输出：         # mysql -uroot -p        -- 留神：此时不须要明码也能登录MySQL 数据库, 批改数据库账户明码 4.1更新明码 语法：update user set authentication_string=password('新密码') where user = '用户名'; mysql > update user set authentication_string=password('123456') where user = 'root'; 或者： mysql > SET PASSWORD FOR root@localhost = PASSWORD('123456'); 或者： mysql > SET PASSWORD = PASSWORD('123456'); 4.2刷新权限 mysql > flush privileges;5.还原配置文件设置, 使之登录须要明码 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。什么是WonderShaper如何装置WonderShaperWonderShaper应用帮忙WonderShaper应用示例 查看网卡状态限度网卡速度（单位Kbps）勾销限速WonderShaper在测试中的利用网速单位转换总结1.什么是WonderShaperWonderShaper是用来对特定网卡进行疾速限速的工具，它理论是对linux的tc命令进行封装后的shell脚本，所以应用老本比tc更低，更容易上手，以下配合测速工具speedtest一起应用 2.如何装置WonderShaper#间接拉取WonderShaper，开箱即用git clone https://github.com/magnific0/wondershaper.gitroot@****-5491:/home/soft/wondershaper# ./wondershaper -vVersion 1.4.1root@****-5491:/home/soft/wondershaper# #网速测试工具speedtest装置(Ubuntu)apt install speedtest-cli--yum install speedtest-cli (centos) 3.WonderShaper应用帮忙root@****-5491:/home/soft/wondershaper# ./wondershaper -hUSAGE: ./wondershaper [-hcs] [-a <adapter>] [-d <rate>] [-u <rate>]Limit the bandwidth of an adapterOPTIONS: -h Show this message 【帮忙信息】 -a <adapter> Set the adapter 【指定网卡接口】 -d <rate> Set maximum download rate (in Kbps) and/or 【限度下载速度(Kbps)】 -u <rate> Set maximum upload rate (in Kbps) 【限度上传速度(Kbps)】 -p Use presets in "/etc/systemd/wondershaper.conf" -f <file> Use alternative preset file -c Clear the limits from adapter 【革除指定网卡规定，用于勾销限速】 -s Show the current status of adapter 【显示以后网卡的状态】 -v Show the current version 【显示以后版本】 Configure HIPRIODST in "/etc/systemd/wondershaper.conf" for hosts requiring high priority i.e. in case ssh uses dport 443.MODES: wondershaper -a <adapter> -d <rate> -u <rate> wondershaper -c -a <adapter> wondershaper -s -a <adapter>EXAMPLES: 【应用示例】 wondershaper -a eth0 -d 1024 -u 512 【设置网卡eth0的上行速度为512kbps，上行速度为1024kbps】 wondershaper -a eth0 -u 512 【只设置上行速度为512kbps】 wondershaper -c -a eth0 【革除网卡eth0的规定】 wondershaper -p -f foo.conf 【设置指定的配置文件】root@****-5491:/home/soft/wondershaper#4.WonderShaper应用示例4.1查看网卡状态root@****-5491:/home/soft/wondershaper# ifconfig eno1eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.5.103 netmask 255.255.255.0 broadcast 192.168.5.255 inet6 fe80::2c93:21f9:1931:304 prefixlen 64 scopeid 0x20<link> ether c8:f7:50:7e:50:48 txqueuelen 1000 (Ethernet) RX packets 7748809 bytes 1034513376 (1.0 GB) RX errors 0 dropped 439 overruns 0 frame 0 TX packets 15528838 bytes 4784318169 (4.7 GB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 16 memory 0x91500000-91520000 root@****-5491:/home/soft/wondershaper# ./wondershaper -s -a eno1qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 4528052159 bytes 14890189 pkt (dropped 0, overlimits 0 requeues 4224) backlog 0b 0p requeues 4224 maxpacket 66616 drop_overlimit 0 new_flow_count 35953 ecn_mark 0 new_flows_len 0 old_flows_len 0--测试网速root@****-5491:/home/soft/wondershaper# speedtestRetrieving speedtest.net configuration...Testing from China Telecom (120.36.98.11)...Retrieving speedtest.net server list...Selecting best server based on ping...Hosted by Fuzhou China Mobile,Fujian (Fuzhou) [589.19 km]: 14.449 msTesting download speed................................................................................-- 下载网速是171.43 Mbit/s，Download: 171.43 Mbit/sTesting upload speed......................................................................................................-- 上传网速是4.15 Mbit/sUpload: 4.15 Mbit/s4.2限度网卡速度（单位Kbps）-- 上行2048kbps=2 Mbit/s,上行 1024kbps=1 Mbit/sroot@****-5491:/home/soft/wondershaper# ./wondershaper -a eno1 -d 2048 -u 1024--测试网速root@****-5491:/home/soft/wondershaper# speedtestRetrieving speedtest.net configuration...Testing from China Telecom (120.36.98.11)...Retrieving speedtest.net server list...Selecting best server based on ping...Hosted by Far EasTone Telecom (Miaoli City) [722.10 km]: 174.383 msTesting download speed................................................................................-- 上行速度Download: 1.80 Mbit/sTesting upload speed......................................................................................................--上行速度Upload: 1.28 Mbit/sroot@****-5491:/home/soft/wondershaper# 4.3勾销限速--勾销限速root@****-5491:/home/soft/wondershaper# ./wondershaper -c -a eno1-- 查看网卡状态root@****-5491:/home/soft/wondershaper# ./wondershaper -s -a eno1qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 123022 bytes 471 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0-- 测试网速root@****-5491:/home/soft/wondershaper# speedtestRetrieving speedtest.net configuration...Testing from China Telecom (120.36.98.11)...Retrieving speedtest.net server list...Selecting best server based on ping...Hosted by Far EasTone Telecom (Miaoli City) [722.10 km]: 173.886 msTesting download speed................................................................................Download: 11.29 Mbit/sTesting upload speed......................................................................................................Upload: 2.93 Mbit/sroot@****-5491:/home/soft/wondershaper#5.WonderShaper在测试中的利用测试项目：某外部数据库迁徙工具测试目标：数据迁徙中，对指标端进行限速，当勾销限速后，传输速度能够复原测试步骤：起迁徙过程，在指标端服务器上用WonderShaper工具进行限速： ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。事件起因：在测试一个数据迁徙工具时，源端oracle19c数据迁徙到指标端mysql8.0，提醒迁徙指标端 Unknown database 'SBTEST'，报错如下： 2022-07-29 10:08:19,155 ERROR com.greatsync.connector.jdbc.internal.ComplexJdbcOutputFormat [] - JDBC executeBatch error, retry times = 0java.sql.BatchUpdateException: Unknown database 'SBTEST' at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:1.8.0_312] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[?:1.8.0_312] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:1.8.0_312] at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[?:1.8.0_312] at com.mysql.cj.util.Util.handleNewInstance(Util.java:192) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.util.Util.getInstance(Util.java:167) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.util.Util.getInstance(Util.java:174) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.jdbc.exceptions.SQLError.createBatchUpdateException(SQLError.java:224) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.jdbc.ClientPreparedStatement.executeBatchedInserts(ClientPreparedStatement.java:755) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.jdbc.ClientPreparedStatement.executeBatchInternal(ClientPreparedStatement.java:426) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.jdbc.StatementImpl.executeBatch(StatementImpl.java:795) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.greatsync.connector.jdbc.statement.FieldNamedPreparedStatementImpl.executeBatch(FieldNamedPreparedStatementImpl.java:77) ~[blob_p-90078b57fb2c51eb5935c045d2e493ef0a7d1524-e9c0e1166eea1bd94ba3d5a23c03b9b3:?] at com.greatsync.connector.jdbc.internal.executor.TableSimpleStatementExecutor.executeBatch(TableSimpleStatementExecutor.java:63) ~[blob_p-90078b57fb2c51eb5935c045d2e493ef0a7d1524-e9c0e1166eea1bd94ba3d5a23c03b9b3:?] at com.greatsync.connector.jdbc.internal.executor.TableBufferReducedStatementExecutor.executeBatch(TableBufferReducedStatementExecutor.java:121) ~[blob_p-90078b57fb2c51eb5935c045d2e493ef0a7d1524-e9c0e1166eea1bd94ba3d5a23c03b9b3:?] at com.greatsync.connector.jdbc.internal.ComplexJdbcOutputFormat.attemptFlush(ComplexJdbcOutputFormat.java:243) ~[blob_p-90078b57fb2c51eb5935c045d2e493ef0a7d1524-e9c0e1166eea1bd94ba3d5a23c03b9b3:?] at com.greatsync.connector.jdbc.internal.ComplexJdbcOutputFormat.flush(ComplexJdbcOutputFormat.java:210) ~[blob_p-90078b57fb2c51eb5935c045d2e493ef0a7d1524-e9c0e1166eea1bd94ba3d5a23c03b9b3:?] at com.greatsync.connector.jdbc.internal.ComplexJdbcSinkFunction.lambda$open$0(ComplexJdbcSinkFunction.java:63) ~[blob_p-90078b57fb2c51eb5935c045d2e493ef0a7d1524-e9c0e1166eea1bd94ba3d5a23c03b9b3:?] at org.apache.flink.streaming.runtime.tasks.StreamTask.invokeProcessingTimeCallback(StreamTask.java:1693) ~[flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.streaming.runtime.tasks.StreamTask.lambda$null$22(StreamTask.java:1684) ~[flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.streaming.runtime.tasks.StreamTaskActionExecutor$1.runThrowing(StreamTaskActionExecutor.java:50) ~[flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.streaming.runtime.tasks.mailbox.Mail.run(Mail.java:90) ~[flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.streaming.runtime.tasks.mailbox.MailboxProcessor.processMailsNonBlocking(MailboxProcessor.java:353) ~[flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.streaming.runtime.tasks.mailbox.MailboxProcessor.processMail(MailboxProcessor.java:317) ~[flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.streaming.runtime.tasks.mailbox.MailboxProcessor.runMailboxLoop(MailboxProcessor.java:201) ~[flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.streaming.runtime.tasks.StreamTask.runMailboxLoop(StreamTask.java:809) ~[flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:761) ~[flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.runtime.taskmanager.Task.runWithSystemExitMonitoring(Task.java:958) [flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.runtime.taskmanager.Task.restoreAndInvoke(Task.java:937) [flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.runtime.taskmanager.Task.doRun(Task.java:766) [flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.runtime.taskmanager.Task.run(Task.java:575) [flink-dist_2.11-1.14.4.jar:1.14.4] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_312]Caused by: java.sql.SQLSyntaxErrorException: Unknown database 'SBTEST' at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:120) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:122) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.jdbc.ClientPreparedStatement.executeInternal(ClientPreparedStatement.java:953) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(ClientPreparedStatement.java:1098) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(ClientPreparedStatement.java:1046) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.jdbc.ClientPreparedStatement.executeLargeUpdate(ClientPreparedStatement.java:1371) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.jdbc.ClientPreparedStatement.executeBatchedInserts(ClientPreparedStatement.java:716) ~[mysql-connector-java-8.0.28.jar:8.0.28] ... 22 more于是查看了指标端mysql的databases： ...

之前没有认真钻研过my.cnf文件，明天有工夫钻研了一下my.cnf中的一些概念，这里简略整顿如下，如果有什么问题，还请大家指出。 依照教程装置好MySQL之后，关上etc目录下的my.cnf文件，大略可看到上面这样的参数列表，可能不同版本的mysql参数多少会有一些不统一，然而并不障碍咱们了解。 首先，咱们能够看到这个文件外面有mysqld和mysql_safe两类参数，咱们晓得mysqld和mysql_safe都能够启动mysql服务，那么mysqld和mysql_safe这两个类之间有什么不同呢？要探讨这个问题，咱们须要引入第三个类别mysql.server，并同时探讨这三种启动形式的区别。 问题1.mysql.server，mysqld，mysqld_safe的区别 mysql.server 它是一个服务器启动的shell脚本，次要作用就是为了不便启动和敞开mysql服务，它应用mysql_safe来启动mysql服务器，在mysql.server启动服务器之前，它将目录转换到mysql装置目录外面去，而后调用mysqld_safe。mysql.server通过向服务器发送一个信号来进行它，也能够应用mysqladmin shutdown命令来进行服务器，如果你应用源码或者二进制格局装置mysql（没有主动装置mysql.server这个脚本），你能够手动装置； 这个脚本在mysql装置目录下的support-files目录里边或者在源码包里边；为了能应用service mysqld start命令启动mysql服务，此时须要做的是将mysql.server的脚本复制到/etc/init.d目录下，而后重命名为mysqld，最初给予执行权限。mysqld.server会从配置文件的[mysqld] [mysql.server] 区域读取配置选项； 能够在全局配置文件/etc/my.cnf中配置mysql.server，mysql.server脚本反对上面这些选项；一旦指定，它们必须放在配置文件中，不能放到命令行中（mysql.server反对的命令行参数只有start和stop）； --basedir mysql装置目录； --datadir 数据文件的门路； --pid-file 服务器写本人的过程号的文件；如果这个不指定，mysql应用默认的hostname.pid; The PID file value被传递给mysqld_safe，笼罩了[mysqld_safe]上面指定的值；因为mysql.server读取[mysqld]选项组而不读取[mysqld_safe]选项组，所以为了在应用mysql.server 调用mysqld_safe的时候， mysqld_safe可能取得一样的pid，咱们能够让[mysqld]选项组和[mysqld_safe]选项组应用同一个pid-file; mysql_safe 这是mysql服务启动脚本，它是mysqld的父过程，它调用mysqld启动数据库服务，并在启动MySQL服务器后持续监控其运行状况，并在其死机时重新启动它，当咱们开启mysqld_safe命令的时候，能够避免mysql服务的意外终止，这里做一个小小的测试。 首先查看以后的mysql服务： 而后发现服务中有一个mysql_safe和一个mysqld，其中mysqld_safe的端口号是1929，mysqld的端口号是2228，这个时候，咱们把2228的过程杀掉： 咱们发现，过程号为2228的mysqld过程曾经被杀掉，过程号为1929的mysqld_safe过程还在，又从新生成了一个过程号为2288的mysqld过程，接下来，咱们杀掉mysqld_safe的过程，kill -9 1929，失去的后果如下: 咱们发现杀掉mysqld_safe之后，只剩下过程号为2288的mysqld过程了，并没有生成新的mysqld_safe过程，这个时候，在再次杀掉mysqld过程2288，后果如下： 此时，所有的过程都被敞开掉了，综合上述操作，咱们能够发现，当mysqld_safe过程存在时，咱们无奈间接杀掉mysqld过程，当咱们杀掉mysqld_safe过程的时候，此时才能够杀掉mysqld过程，这便是mysqld_safe的守护过程作用，它能够避免mysqld过程被意外终止。 mysqld mysqld是对于服务器端的程序，要想应用客户端程序,该程序必须运行,因为客户端通过连贯服务器来拜访数据库。 问题2.mysql的三种启动形式: 1、mysqld 启动mysql服务器: 客户端连贯: 2、mysqld_safe 启动mysql服务器: 客户端连贯: 3、mysql.server 启动mysql服务器: 客户端连贯:同1、2 问题3.socket文件mysql.sock详解 mysql有两种连贯形式，一种是TCP/IP的形式，另外一种是socket的形式，mysql.sock次要用户程序与mysqlserver在同一机器上，发动本地连接的时候应用，即无需再连贯服务时应用host和IP，mysql.sock是随着每一次mysql server的启动而生成的，当服务重启时，mysql.sock也会从新生成。利用mysql.sock连贯服务的样例如下： linux下装置mysql连贯的时候常常回提醒说找不到mysql.sock文件，解决办法很简略： 1.如果是新装置的mysql，提醒找不到文件，就搜寻下，指定正确的地位。 2.如果mysql.sock文件误删的话，就须要重启mysql服务，如果重启胜利的话会在datadir目录上面生成mysql.sock 到时候指定即可。 问题4.查看mysql的配置文件调用程序 mysql --help|grep “my.cnf”，当启动mysql服务的时候，会从当前目录的my.cnf中去读对应的参数，优先级程序和输入程序保持一致。 问题5.MySQL的pid文件介绍 MySQL pid 文件记录的是以后 mysqld 过程的 pid，pid 亦即 Process ID。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。事件起因：在测试一个数据迁徙工具时，源端oracle19c数据迁徙到指标端mysql8.0，提醒迁徙指标端 Unknown database 'SBTEST'，报错如下： 2022-07-29 10:08:19,155 ERROR com.greatsync.connector.jdbc.internal.ComplexJdbcOutputFormat [] - JDBC executeBatch error, retry times = 0java.sql.BatchUpdateException: Unknown database 'SBTEST' at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:1.8.0_312] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[?:1.8.0_312] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:1.8.0_312] at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[?:1.8.0_312] at com.mysql.cj.util.Util.handleNewInstance(Util.java:192) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.util.Util.getInstance(Util.java:167) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.util.Util.getInstance(Util.java:174) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.jdbc.exceptions.SQLError.createBatchUpdateException(SQLError.java:224) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.jdbc.ClientPreparedStatement.executeBatchedInserts(ClientPreparedStatement.java:755) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.jdbc.ClientPreparedStatement.executeBatchInternal(ClientPreparedStatement.java:426) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.jdbc.StatementImpl.executeBatch(StatementImpl.java:795) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.greatsync.connector.jdbc.statement.FieldNamedPreparedStatementImpl.executeBatch(FieldNamedPreparedStatementImpl.java:77) ~[blob_p-90078b57fb2c51eb5935c045d2e493ef0a7d1524-e9c0e1166eea1bd94ba3d5a23c03b9b3:?] at com.greatsync.connector.jdbc.internal.executor.TableSimpleStatementExecutor.executeBatch(TableSimpleStatementExecutor.java:63) ~[blob_p-90078b57fb2c51eb5935c045d2e493ef0a7d1524-e9c0e1166eea1bd94ba3d5a23c03b9b3:?] at com.greatsync.connector.jdbc.internal.executor.TableBufferReducedStatementExecutor.executeBatch(TableBufferReducedStatementExecutor.java:121) ~[blob_p-90078b57fb2c51eb5935c045d2e493ef0a7d1524-e9c0e1166eea1bd94ba3d5a23c03b9b3:?] at com.greatsync.connector.jdbc.internal.ComplexJdbcOutputFormat.attemptFlush(ComplexJdbcOutputFormat.java:243) ~[blob_p-90078b57fb2c51eb5935c045d2e493ef0a7d1524-e9c0e1166eea1bd94ba3d5a23c03b9b3:?] at com.greatsync.connector.jdbc.internal.ComplexJdbcOutputFormat.flush(ComplexJdbcOutputFormat.java:210) ~[blob_p-90078b57fb2c51eb5935c045d2e493ef0a7d1524-e9c0e1166eea1bd94ba3d5a23c03b9b3:?] at com.greatsync.connector.jdbc.internal.ComplexJdbcSinkFunction.lambda$open$0(ComplexJdbcSinkFunction.java:63) ~[blob_p-90078b57fb2c51eb5935c045d2e493ef0a7d1524-e9c0e1166eea1bd94ba3d5a23c03b9b3:?] at org.apache.flink.streaming.runtime.tasks.StreamTask.invokeProcessingTimeCallback(StreamTask.java:1693) ~[flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.streaming.runtime.tasks.StreamTask.lambda$null$22(StreamTask.java:1684) ~[flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.streaming.runtime.tasks.StreamTaskActionExecutor$1.runThrowing(StreamTaskActionExecutor.java:50) ~[flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.streaming.runtime.tasks.mailbox.Mail.run(Mail.java:90) ~[flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.streaming.runtime.tasks.mailbox.MailboxProcessor.processMailsNonBlocking(MailboxProcessor.java:353) ~[flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.streaming.runtime.tasks.mailbox.MailboxProcessor.processMail(MailboxProcessor.java:317) ~[flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.streaming.runtime.tasks.mailbox.MailboxProcessor.runMailboxLoop(MailboxProcessor.java:201) ~[flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.streaming.runtime.tasks.StreamTask.runMailboxLoop(StreamTask.java:809) ~[flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:761) ~[flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.runtime.taskmanager.Task.runWithSystemExitMonitoring(Task.java:958) [flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.runtime.taskmanager.Task.restoreAndInvoke(Task.java:937) [flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.runtime.taskmanager.Task.doRun(Task.java:766) [flink-dist_2.11-1.14.4.jar:1.14.4] at org.apache.flink.runtime.taskmanager.Task.run(Task.java:575) [flink-dist_2.11-1.14.4.jar:1.14.4] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_312]Caused by: java.sql.SQLSyntaxErrorException: Unknown database 'SBTEST' at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:120) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:122) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.jdbc.ClientPreparedStatement.executeInternal(ClientPreparedStatement.java:953) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(ClientPreparedStatement.java:1098) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(ClientPreparedStatement.java:1046) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.jdbc.ClientPreparedStatement.executeLargeUpdate(ClientPreparedStatement.java:1371) ~[mysql-connector-java-8.0.28.jar:8.0.28] at com.mysql.cj.jdbc.ClientPreparedStatement.executeBatchedInserts(ClientPreparedStatement.java:716) ~[mysql-connector-java-8.0.28.jar:8.0.28] ... 22 more于是查看了指标端mysql的databases： ...

前言MySQL之所以能成为当初最风行的开源数据库，这跟它的开放性、包容性是分不开的。它的入门门槛低到用一条命令就能把MySQL装置起来，你能在程序开发的入门材料中很容易就找到MySQL的配套应用教程，你能够不必付任何费用就能在本人的环境中部署起来对外承载业务。 《千金良方: MySQL性能优化金字塔法令》这本书既有波及体系结构、PFS、I S、统计信息、复制、锁、InnoDB等基础知识的铺垫(其实并不根底)，又有泛滥案例详解，内容丰盛、翔实，是难得一见的MySQL性能优化参考书，倡议每位DBA以及从事MySQL相干利用开发的读者都读一读。 须要获取的小伙伴能够间接【点击此处】即可获取到！ 内容总览：根底篇 因为文章篇幅过长（共50章），上面开始仅为大家展现局部 案例篇 工具篇 如果看完这些局部内容截图还是不太懂得话上面会给大家展现一下目录：须要获取的小伙伴能够间接【点击此处】获取哦！ 因为内容太过具体，文中只展现了局部内容，残缺文档已备好！！须要获取的小伙伴能够间接【点击此处】即可获取哦！

1.MySQL中执行一条SQL的总体流程一条蕴含函数的SQL语句，在mysql中会通过: 客户端发送，服务器连贯，语法解析，语句执行的过程。 调试源码，剖析函数的具体执行过程，在客户端，执行select to_char(‘test’) from dual。 跟踪堆栈：pthread_start→handle_one_connection→do_handle_one_connect→do_command→dispatch_command，确定SQL函数的执行入口为dispatch_command 调试跟踪SQL外部执行过程为： 2.SQL函数执行过程剖析堆栈信息，确定SQL函数次要执行过程为： SQL_PARSE 语法解析SQL_RESOLVER prepare筹备执行SQL_EXCUTOR 具体执行函数SQL_PARSE堆栈： 1 To_char_instantiator::instantiate(To_char_instantiator * const this, THD * thd, PT_item_list * args) (/home/bob/work/percona-server/sql/item_create.cc:785)2 (anonymous namespace)::Function_factory<To_char_instantiator>::create_func((anonymous namespace)::Function_factory<To_char_instantiator> * const this, THD * thd, LEX_STRING function_name, PT_item_list * item_list) (/home/bob/work/percona-server/sql/item_create.cc:1203)3 PTI_function_call_generic_ident_sys::itemize(PTI_function_call_generic_ident_sys * const this, Parse_context * pc, Item ** res) (/home/bob/work/percona-server/sql/parse_tree_items.cc:259)4 PTI_expr_with_alias::itemize(PTI_expr_with_alias * const this, Parse_context * pc, Item ** res) (/home/bob/work/percona-server/sql/parse_tree_items.cc:337)5 PT_item_list::contextualize(PT_item_list * const this, Parse_context * pc) (/home/bob/work/percona-server/sql/parse_tree_helpers.h:112)6 PT_select_item_list::contextualize(PT_select_item_list * const this, Parse_context * pc) (/home/bob/work/percona-server/sql/parse_tree_nodes.cc:3813)7 PT_query_specification::contextualize(PT_query_specification * const this, Parse_context * pc) (/home/bob/work/percona-server/sql/parse_tree_nodes.cc:1551)8 PT_query_expression::contextualize(PT_query_expression * const this, Parse_context * pc) (/home/bob/work/percona-server/sql/parse_tree_nodes.cc:4178)9 PT_select_stmt::make_cmd(PT_select_stmt * const this, THD * thd) (/home/bob/work/percona-server/sql/parse_tree_nodes.cc:648)10 LEX::make_sql_cmd(LEX * const this, Parse_tree_root * parse_tree) (/home/bob/work/percona-server/sql/sql_lex.cc:5237)11 THD::sql_parser(THD * const this) (/home/bob/work/percona-server/sql/sql_class.cc:2978)12 parse_sql(THD * thd, Parser_state * parser_state, Object_creation_ctx * creation_ctx) (/home/bob/work/percona-server/sql/sql_parse.cc:7333)13 dispatch_sql_command(THD * thd, Parser_state * parser_state, bool update_userstat) (/home/bob/work/percona-server/sql/sql_parse.cc:5237)14 dispatch_command(THD * thd, const COM_DATA * com_data, enum_server_command command) (/home/bob/work/percona-server/sql/sql_parse.cc:1978)15 do_command(THD * thd) (/home/bob/work/percona-server/sql/sql_parse.cc:1426)16 handle_connection(void * arg) (/home/bob/work/percona-server/sql/conn_handler/connection_handler_per_thread.cc:307)17 pfs_spawn_thread(void * arg) (/home/bob/work/percona-server/storage/perfschema/pfs.cc:2899)18 libpthread.so.0!start_thread(void * arg) (/build/glibc-eX1tMB/glibc-2.31/nptl/pthread_create.c:477)19 libc.so.6!clone() (/build/glibc-eX1tMB/glibc-2.31/sysdeps/unix/sysv/linux/x86_64/clone.S:95)SQL_RESOLVER堆栈： ...

数据库构造导出疏忽。 以下操作在Windows上，数据库均为MySQL8.0.30、innodb表。 1. 数据导出再导入对外可提供读服务（容许重启），应用 select outfile + LOAD DATA a. 导出## my.ini配置：# [mysqld]# secure-file-priv=""FLUSH TABLES page FOR EXPORT;select * from page into outfile 'E:/page.text';UNLOCK TABLES;b. 导入## my.ini配置：# [mysqld]# local_infile = 1LOAD DATA LOCAL INFILE 'E:/page.text' INTO TABLE page;长处：操作过程保留数据库残缺数据备份，速度较快。配置更改，须要重启数据库。 c. 尝试其它在线操作dev.mysql.com flush操作在flush后复制 .idb和 .cfg ，在指标服务在线时因为占用权限问题无奈复制，停机复制能够失常启动、但表无法访问，truncate时报错Tablespace is missing for table，放弃。 2. 数据库文件夹停机拷贝进行MySQL服务，将整个MySQL包含装置目录进行停机拷贝。不停机复制会呈现莫名其妙的问题。

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。cgroups 是Linux内核提供的能够限度过程所应用资源的机制，能够对 cpu，内存等资源实现精细化的管制. 什么是cgroups管制族群(cgroup) - 关联一组task和一组subsystem的配置参数。一个task对应一个过程, cgroup是资源分片的最小单位。子系统(subsystem) - 资源管理器，一个subsystem对应一项资源的治理，如 cpu, cpuset, memory等 cpu 子系统，次要限度 cpu 使用率。cpuacct 子系统，能够统计 cgroups 中的过程的 cpu 应用报告。cpuset 子系统，能够为 cgroups 中的过程调配独自的 cpu 节点或者内存节点。memory 子系统，能够限度过程的 memory 使用量。blkio 子系统，能够限度过程的块设施 io。devices 子系统，能够管制过程可能拜访某些设施。net_cls 子系统，能够标记 cgroups 中过程的网络数据包，而后能够应用 tc 模块（traffic control）对数据包进行管制。freezer 子系统，能够挂起或者复原 cgroups 中的过程。ns 子系统，能够使不同 cgroups 上面的过程应用不同的 namespace。层级(hierarchy) - 关联一个到多个subsystem和一组树形构造的cgroup. 和cgroup不同，hierarchy蕴含的是可治理的subsystem mount -t cgroup 能够查看以后曾经挂载的子系统工作(task)- 每个cgroup都会有一个task列表文件tasks，一个task就对应一个过程。cpu 子系统cgroups的创立很简略，只须要在相应的子系统下创立目录即可。上面咱们到 cpu 子系统下创立测试文件夹： 1.创立cpu 零碎的cgroup/sys/fs/cgroup/cpu/ctest执行实现创立就能够看到 root@moyu20:/sys/fs/cgroup/cpu/ctest# ls -l 总用量 0-rw-r--r-- 1 root root 0 7月 29 15:25 cgroup.clone_children-rw-r--r-- 1 root root 0 7月 29 15:25 cgroup.procs-r--r--r-- 1 root root 0 7月 29 15:25 cpuacct.stat-rw-r--r-- 1 root root 0 7月 29 15:25 cpuacct.usage-r--r--r-- 1 root root 0 7月 29 15:25 cpuacct.usage_all-r--r--r-- 1 root root 0 7月 29 15:25 cpuacct.usage_percpu-r--r--r-- 1 root root 0 7月 29 15:25 cpuacct.usage_percpu_sys-r--r--r-- 1 root root 0 7月 29 15:25 cpuacct.usage_percpu_user-r--r--r-- 1 root root 0 7月 29 15:25 cpuacct.usage_sys-r--r--r-- 1 root root 0 7月 29 15:25 cpuacct.usage_user-rw-r--r-- 1 root root 0 7月 29 15:25 cpu.cfs_period_us-rw-r--r-- 1 root root 0 7月 29 15:25 cpu.cfs_quota_us-rw-r--r-- 1 root root 0 7月 29 15:25 cpu.shares-r--r--r-- 1 root root 0 7月 29 15:25 cpu.stat-rw-r--r-- 1 root root 0 7月 29 15:25 cpu.uclamp.max-rw-r--r-- 1 root root 0 7月 29 15:25 cpu.uclamp.min-rw-r--r-- 1 root root 0 7月 29 15:25 notify_on_release-rw-r--r-- 1 root root 0 7月 29 15:25 tasks曾经把cpu子系统 对应管制文件创建好了 ...

一个事务具备ACID个性，也就是（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔离性、持久性），本文次要解说一下其中的Isolation，也就是事务的隔离性。概述四种隔离级别别离是： 读未提交（read uncommitted） 一个事务还没提交时，它批改的数据都能够被别的事物看到。读已提交(read committed) 一个事务提交之后，它批改的数据才会被别的事物看到。可反复读(repeatable read) 一个事务执行过程中看到的数据，总是和这个事务开启时看到的数据是统一的。在可反复读的隔离级别下，未提交的事务对其余事务也是不可见的。串行化(serializable) 数据的读和写都会加锁，读会加读锁，写会加写锁。当遇到读写锁抵触时，后拜访的事务必须等前一个事务执行实现后，再继续执行。以上四种隔离级别，由上往下隔离强度越来越大，然而执行效率会随之升高。在设置隔离级别时候，须要在隔离级别和执行效率两者做均衡取舍。为了便于了解，上面就举一个例子： 在不同隔离级别下，事务A会有哪些不同的返回后果，也就是图中的V1、V2、V3的返回值别离是什么。 如果隔离级别是读未提交，事务B批改后数据无需提交事务，就能被事务A读取，所以V1、V2、V3的值都是2。如果隔离级别是读已提交，事务B批改后须要提交后，批改后的数据能力被事务A读取，所以V1的值是1，事务B提交，事务A读取批改后的数据,所以V2的值是2,V3的值也是2。如果隔离级别是可反复读，整个事务看到的事务和事务开启时看到的数据是统一的，开启看到的数据是1，所以V1、V2的值都是1,事务A提交之后，获取到批改后的数据，所以V3的值是2。如果隔离级别是串行化，会被锁住，此时事务B对应的线程处于阻塞状态，直到事务A提交之后，事务B才会持续将1改成2。所以V1、V2的值是1，V3的值是2。MySQL默认的隔离级别是可反复读。隔离级问题先理解几个基本概念： 脏读：事务A批改数据，事务B读取了数据后事务A报错回滚，批改的数据没有提交到数据库中，此时事务B读取批改的数据就是一个脏读，也就是一个事务读取到另一个事务未提交的数据就是脏读。 不可反复读：事务A在同一个事务上屡次读取同一个数据，在事务A还没有完结时，事务B批改了该数据，因为事务B的批改，导致事务A两次读取的数据不统一，就呈现了不能够反复读的景象。 幻读：事务A依据条件查问失去N条数据，但此时事务B更改或者减少了M条合乎事务A查问的条件的数据。这样当事务A再次查问的时候发现会有N + M条数据，产生了幻读。 几种隔离级别可能会有脏读、不可反复读或者幻读的问题，它们之间的关系如下： 隔离级别脏读不可反复读幻读读未提交√√√读提交×√√可反复读××√串行化×××读未提交：可能会呈现脏读、不可反复读、幻读，读取未提交事务的数据，数据撤回了，就是一种脏读。如果其余事务批改同一个数据，事务读取的数据也是不同的，所以也存在不可反复读。同时也能读取到其余事务增加的数据，所以也存在幻读。读已提交：该隔离级别只能读取到其余事务提交后的数据，所以不存在脏读。然而在第一次读取数据后，其余事务批改后数据并提交事务，此时事务读取到数据就和第一次读到的数据不统一了，也就存在不可反复读。同时其余事务能够增加多条数据，也存在幻读。可反复度读：示意整个事务看到的事务和开启后的事务能看到的数据是统一的，既然数据是统一的，所以不存在不可反复读。而且不会读取其余事务批改的数据，也就是不存在脏读。而对同一个批数据，可能会存在增加的状况，所以可能会存在幻读的状况。窜行化：当产生读写锁抵触时，前面的事务要等后面的事务执行结束之后再执行，所以肯定是先读或者先写的执行结束之后再执行后读或者写，读写依照程序顺次进行，所以不存在脏读、不存在不可反复读、也不存在幻读。隔离级别原理隔离级别的次要是多版本并发管制MVCC,MVCC是通过保留数据在某个工夫点的快照来实现的。 InnoDB实现的MVCC，是通过在每行记录前面保留两个暗藏列来实现，一个是保留行的创立工夫，另一个是保留行的过期工夫。当然存储的不是工夫，而是零碎版本号。每开启一个新的事务，零碎版本号先主动递增，该零碎版本号会作为事务的版本号，用来和查问到的每行记录的版本号做比拟。比方在可反复读隔离级别下，MVCC是如何操作的： SELECT InnoDB会依据以下两个条件查看每行记录： InnoDB只查找版本号早于以后事务的数据行（零碎版本号小于或者等于事务的零碎版本号），这样能够确保事务读取的行，要么是在事务开始前就存在，要么是事务本身插入或者更新过。行的删除版本要么未定义，要么大于以后事务版本号。这能够确保事务读取到的行，在事务开始之前未被删除。只有合乎上述两个条件的记录，能力返回作为查问的后果。INSERT InnoDB为新插入的每一行保留以后零碎版本号作为行版本号。DELETE InnoDB为删除的每一行保留以后零碎版本号作为行删除的标识。UPDATE InnoDB为插入一行新记录，保留以后零碎版本号作为行版本号，同时保留以后零碎版本号到原来的行作为行删除标识。保留着两个额定的零碎版本号，大多数读操作都能够不必加锁。这样设计是的读数据的操作很简略，性能很好，并且也能保障只会读取到符合标准的行。不足之处是每行记录都须要额定的存储空间，须要做更多的行查看工作，以及一些额定的保护工作。 MVCC只在读已提交和可反复读两个隔离级别下失效。其余两个隔离级别下MVCC都不能失效，因为读未提交总是读取到最新的数据行，无需记录以后事务版本号。而串行化会对所有的读写都会进行加锁，先读、先写的先执行，后读、后写的后执行。也不须要记录记录版本号精心比对。InnoDB的行数据有多个版本，每个数据版本都有本人的row trx_id，每个事务或者语句都有本人的一致性视图。查问语句是一致性读，一致性读会依据row trx_id和一致性视图确定数据版本的可见性。 可反复读，只查问在事务启动前就提交实现的数据。读已提交，只查问语句启动前其余事务提交的数据。总结四种隔离级别: 读未提交：数据会读取其余事务未更新到数据的数据。可能会存在脏读、不可反复读、幻读的问题。读已提交(read committed)：数据只能读取其余事务提交的数据，不存在脏读，然而可能会存在不可反复读、幻读的问题。可反复读(repeatable read):事务执行过程中看到的数据，总是和这个事务开启时看到的数据是统一的。在可反复读的隔离级别下，未提交的事务对其余事务也是不可见的。不存在脏读、不可反复读，然而可能会存在幻读问题。串行化(serializable)：存在读写锁抵触时，后拜访的事务会等前一个事务执行结束后，再继续执行。MySQL采纳了MVVC(多版本并发管制)解决读已提交、可反复读隔离问题。 执行一条SQL语句，都会保留两个暗藏的列。一个是保留创立工夫，一个保留过期工夫，贮存的零碎版本号。每次开启一个事务都会零碎会递增一个零碎版本号,作为事务的版本号。 select，查问早于以后事务的数据。insert增加版本号。delete为删除的行把版本号作为删除标识。update，先插入一条数据，保留以后零碎版本号。同时保留原来的行作为行删除标记。参考事务到底是隔离的还是不隔离的？ 高性能MySQL

NVIDIA InfiniBand是一种被宽泛应用的网络互联技术，基于IBTA(InfiniBand Trade Association)而定义的高带宽、低延时、低CPU占用率、大规模易扩大的通信技术，是世界领先的超级计算机的互连首选，为高性能计算、人工智能、云计算、存储等泛滥数据密集型利用提供了弱小的网络性能撑持。通过高速的InfiniBand技术，将业务负载由单机运行转化为基于多机合作的高性能计算集群，并使高性能集群的性能得以进一步开释与优化。 GreatSQL是由万里数据库保护的国内自主MySQL分支版本，专一于晋升MGR可靠性及性能，反对InnoDB并行查问个性，实用于金融级利用。 此次通过比照测试基于InfiniBand 的 NVMe SSD池化计划 及本地NVMe SSD的传统计划的性能体现，评估应用基于InfiniBand的存算拆散架构对分布式数据库性能的晋升水平及扩展性。 通过单方单干，通过大量数据分析，能够看出基于InfiniBand池化计划的存算拆散架构的性能更优、稳定性更强，为GreatSQL实现更高性能的分布式部署提供了无力的技术平台撑持。 1、NVIDIA InfiniBand 池化计划介绍 分布式数据库集群由两局部组成： 计算节点是无SSD盘的裸金属服务器，运行MySQL数据库服务程序；存储节点提供NVMe SSD资源池，通过软件聚合形式提供高性能Lun实现对于数据库的数据的存储服务；两局部服务器通过Quantum 平台的InfiniBand网络实现对计算节点和存储节点的无损连贯，联合NVMe-oF（NVMe over Fabric）高效的数据存储传输协定，将存储节点的Lun挂载到计算节点，实现结算节点本地高性能的数据存储能力。 测试环境为了能够偏心比照两种计划的优劣，两次测试均采纳同一台计算服务器进行测试，不同的是，本地计划存储由本地的PCIe4.0 NVMe SSD承载，InfiniBand 池化计划由100Gbps速率的HDR100网卡接入，通过雷同型号的NVMe SSD组成的全闪服务器借助NVMe-oF提供高性能虚构Lun实现数据拜访。 2.1 存储设备 本次测试次要采取两种存储计划： InfiniBand + NVMe SSD设施本机挂NVMe SSD设施 $ nvme listNode SN Model Namespace Usage Format FW Rev--------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------# InfiniBand + NVMe SSD设施/dev/nvme0n1 MNC12 Mellanox BlueField NVMe SNAP Controller 1 1.10 TB / 1.10 TB 512 B + 0 B 1.0# 本机挂载的两个NVMe SSD设施/dev/nvme2n1 S5L9NE0NA00144 SAMSUNG MZWLJ7T6HALA-0007C 1 7.68 TB / 7.68 TB 512 B + 0 B EPK99J5Q/dev/nvme3n1 S5L9NE0NA00091 SAMSUNG MZWLJ7T6HALA-0007C 2.2 CPU&内存 ...

前言在讲事务的隔离级别之前，先简略的温习下什么是事务？（理解的同学能够跳过） 在MySQL中只有应用了Innodb数据库引擎的数据库或表才反对事务。每执行一条增删改查的sql都是一次事务，只不过autocommit默认是开启的，所以主动提交了。 事务必须满足的4个条件： 原子性（或称不可分割性）：一个事务中的所有操作，要么全副实现，要么全副不实现，不会完结在两头某个环节。事务在执行过程中产生谬误，会被回滚到事务开始前的状态，就像这个事务素来没有执行过一样。 一致性：在事务开始之前和事务完结当前，数据库的完整性没有被毁坏。这示意写入的材料必须完全符合所有的预设规定，这蕴含材料的精确度、串联性以及后续数据库能够自发性地实现预约的工作。 隔离性（又称独立性）：数据库容许多个并发事务同时对其数据进行读写和批改的能力，隔离性能够避免多个事务并发执行时因为穿插执行而导致数据的不统一。事务隔离分为不同级别，包含读未提交（Read uncommitted）、读提交（read committed）、可反复读（repeatable read）和串行化（Serializable），这也是本文章要讲的内容。 持久性：事务处理完结后，对数据的批改就是永恒的，即使系统故障也不会失落。多事务并发的问题当有多个事务并发操作数据库表的时候，可能会呈现以下问题： 脏读（读取未提交的数据）：脏读又称有效数据的读出，是指在数据库拜访中，事务 A 对一个值做批改，事务 B 读取这个值，然而因为某种原因事务 A 回滚撤销了对这个值得批改，这就导致事务 B 读取到的值是有效数据。 工夫事务A事务Bt1开启事务开启事务t2查问张三账户余额为0 t3给张三转账1000 t4 查问张三账户余额为1000（脏读）t5发现转错，撤回1000 t6提交事务提交事务不可反复读（前后数据屡次读取，后果集内容不统一）：不可反复读即当事务 A 依照查问条件失去了一个后果集，这时事务 B 对事务 A 查问的后果集数据做了批改操作，之后事务 A 为了数据校验持续依照之前的查问条件失去的后果集与前一次查问不同，导致不可反复读取原始数据。 工夫事务A事务Bt1开启事务开启事务t2查问张三账户余额为0查问张三账户余额为0t3 给张三转账1000t4 提交事务t5查问张三账户余额为1000（不可反复读） t6提交事务 幻读（前后数据屡次读取，后果集数量不统一）：幻读是指当事务 A 依照查问条件失去了一个后果集，这时事务 B 对事务 A 查问的后果集数据做新增操作，之后事务 A 持续依照之前的查问条件失去的后果集平白无故多了几条数据。 工夫事务A事务Bt1开启事务开启事务t2查问张三账户交易次数，返回2次 t3 张三按摩生产888，交易次数+1t4 提交事务t5查问张三账户交易次数，返回3次（幻读） t6提交事务 很多人容易搞混不可反复读和幻读，的确这两者有些类似：一个是后果内容不同；一个是后果数量不同。但不可反复读重点在于update和delete，而幻读的重点在于insert，且两者的解决办法也大有不同。如果应用锁机制来解决问题，在可反复读中，update sql第一次读取到数据后，就将这些数据加行锁，其它事务无奈批改这些数据，就能够实现可反复读了。但这种办法却无奈锁住insert的数据，所以不能通过行锁来防止幻读，须要用到表锁或者间隙锁，但会极大的升高数据库的并发能力。 事务的隔离级别针对上述脏读、不可反复读和幻读三个问题，数据库大佬们提出了一个解决思路，也就是咱们本文的配角——事务隔离。 事务隔离由低到高分为四个级别： 读未提交（Read uncommitted）：读若不显式申明是不加锁的，能够读取到另一个事务未提交的数据批改，没有防止脏读、不可反复读、幻读。 读已提交（Read committed）：一个事务只能读取到另一个事务曾经提交的数据批改，这种隔离级别防止了脏读，然而可能会呈现不可反复读、幻读。 可反复读（Repeatable read）：保障了同一事务下屡次读取雷同的数据返回的后果集是一样的，这种隔离级别解决了脏读和不可反复读问题，然而仍有可能呈现幻读。 可串行化（Serializable）：对同一数据的读写全加锁，即对同一数据的读写全是互斥了，数据牢靠行很强，然而并发性能不忍直视。这种隔离级别尽管解决了上述三个问题，然而就义了性能。Innodb事务隔离的实现1. Innodb默认隔离级别在讲事务隔离的实现之前，咱们先来理解一下其默认的隔离级别是什么。 Innodb的默认隔离级别是可反复读，能够通过以下两种形式来变更隔离级别：全局批改，批改mysql.ini配置文件，在最初加上 #可选参数有：READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE.[mysqld]transaction-isolation = SERIALIZABLE也可通过执行语句扭转单个会话或全局的事务隔离级别 ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 MySQL 有一个参数叫 max_execution_time ，用来设置只读语句执行的超时工夫，然而仅对独自执行的 select 语句无效；对于非独自执行的 select 语句，比方蕴含在存储过程、触发器等内置事务块里则不失效。官网手册上对这个参数解释如下： max_execution_time applies as follows: The global max_execution_time value provides the default for the session value for new connections. The session value applies to SELECT executions executed within the session that include no MAX_EXECUTION_TIME(*N*) optimizer hint or for which N is 0.max_execution_time applies to read-only SELECT statements. Statements that are not read only are those that invoke a stored function that modifies data as a side effect.max_execution_time is ignored for SELECT statements in stored programs.那对这种非独自呈现的 select 语句，该如何管制超时工夫呢？ ...

背景日常施行中可能会呈现在部署mysql时未更改数据默认存储门路(默认:/var/lib/mysql)，然而个别调配服务器的人只会给零碎分区调配50G的空间，这导致后续空间不够用的状况，也就呈现了须要迁徙数据的问题 测试环境租的3A服务器，带宽高[root@wang] cat /etc/redhat-releaseCentOS Linux release 7.6.1810(AltArch)[root@wang] mysqladmin --versionmysqladmin Ver 8.42 Distrib 5.7.28, for Linux on aarch64迁徙步骤mysql默认的数据文件存储目录为/var/lib/mysql。如果要把目录移到/data/app/下须要进行以下几步： 1、创立目录mkdir -p /data/app2、进行mysql服务systemctl stop mysqld.service3、挪动数据默认文件夹到新地位mv /var/lib/mysql　/data/app/4、批改my.cnf配置文件编辑/etc/my.cnf文件，如果不存在改配置文件，到/usr/share/mysql/下找到*.cnf文件，拷贝其中一个到/etc/并改名为my.cnf)中后再批改。命令如下： cp /usr/share/mysql/my-medium.cnf　/etc/my.cnf在/etc/my.cnf文件中找到以下两行并将等号后的/var/lib/门路批改为新门路/data/app/ socket=/var/lib/mysql/mysql.socksocket=/data/app/mysql/mysql.sock datadir=/var/lib/mysqldatadir=/data/app/5、更改新目录的文件属主chown -R mysql:mysql /data/app/mysql6、启动mysql服务systemctl start mysqld.service

全文索引全文索引能够用来查找注释中的中文，只有在mysql 5.7.6之后，能力应用到检索性能，因为在mysql5.7.6之后，退出了中文分词器，比方“今天天气真好！”会被切割为“明天”，“天气”很多个词，而后会援用到全文索引搜寻。 创立表的全文索引 Create table fulltext_test( Id ==int(11) NOTNULLAUTO_INCREMENT,== contenttextNOTNULL, tagvarchar(255), PRIMARYKEY(id), FULLTEXTKEYcontent_tag_fulltext(content,tag) //创立联结全文索引列)ENGINE=MyISAMDEFAULTCHARSET=utf8; 在曾经有的表创立全文索引 Alter table fulltext_test add fulltext index content_tag_fulltext(content,tag);留神查问的精度问题，在mysql中，规定的最小长度为4，须要可批改。 show variables like '%ft%'; 能够看到这两个变量在 MyISAM 和 InnoDB 两种存储引擎下的变量名和默认值 //MyISAMft_min_word_len=4;ft_max_word_len=84;//InnoDBinnodb_ft_min_token_size=3;innodb_ft_max_token_size=84;批改mysql的/etc/my.cnf文件，在[mysqld]上面追加内容 [mysqld] innodb_ft_min_token_size = 1 ft_min_word_len = 1重启mysql，而后之前建的索引也要重建。 建索引之后的匹配形式： 自然语言全文索引Select * fromtest where match(content) against('aaaa');布尔全文索引Select * from test where match(content) against('a*'inbooleanmode);==+ 必须蕴含该词====- 必须不蕴含该词====> 进步该词的相关性，查问的后果靠前====< 升高该词的相关性，查问的后果靠后====(*)星号 通配符，只能接在词前面==其它罕用的符号能够查下手册。 欢送关注公证号：我只是个码字的，一起学习编程常识！

作者：王向 爱可生 DBA 团队成员，负责公司 DMP 产品的运维和客户 MySQL 问题的解决。善于数据库故障解决。对数据库技术和 python 有着浓重的趣味。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 目录mysqlreplicate介绍应用办法mysqlreplicate源码剖析 第一步：查看重要参数的唯一性 查看server_id唯一性查看uuid_id唯一性第二步：查看InnoDB兼容性第三步：查看存储引擎一致性第四步：查看master binary logging第五步：创立复制步骤梳理mysqlreplicate 介绍his utility permits an administrator to setup and start replication from one server (the master) to another (the slave). The user provides login information for the slave and connection information for connecting to the master. It is also possible to specify a database to be used to test replication. The utility reports conditions where the storage engines on the master and the slave differ for older versions of the server. It also reports a warning if the InnoDB storage engine type (plugin verus built-in) differs on the master and slave. For InnoDB to be the same, both servers must be running the same "type" of InnoDB (built-in or the InnoDB Plugin), and InnoDB on both servers must have the same major and minor version numbers and enabled state. ...

注：本文剖析内容基于 MySQL 8.0 版本文章开始前先温习一下官网文档对于 DECIMAL 类型的一些介绍： The declaration syntax for a DECIMAL column is DECIMAL(M,D). The ranges of values for the arguments are as follows: M is the maximum number of digits (the precision). It has a range of 1 to 65. D is the number of digits to the right of the decimal point (the scale). It has a range of 0 to 30 and must be no larger than M. ...

为什么MySQL数据库索引抉择应用B+树？为什么MySQL数据库索引抉择应用B+树？11

1、什么是游标（或光标） 尽管咱们也能够通过筛选条件 WHERE 和 HAVING，或者是限定返回记录的关键字 LIMIT 返回一条记录，然而，却无奈在后果集中像指针一样，向前定位一条记录、向后定位一条记录，或者是随便定位到某一条记录，并对记录的数据进行解决。这个时候，就能够用到游标。游标，提供了一种灵便的操作形式，让咱们可能对后果集中的每一条记录进行定位，并对指向的记录中的数据进行操作的数据结构。游标让 SQL 这种面向汇合的语言有了面向过程开发的能力。SQL 中，游标是一种长期的数据库对象，能够指向存储在数据库表中的数据行指针。这里游标充当了指针的作用，咱们能够通过操作游标来对数据行进行操作MySQL中游标能够在存储过程和函数中应用比方，咱们查问了 employees 数据表中工资高于15000的员工都有哪些： SELECT employee_id,last_name,salary FROM employeesWHERE salary > 15000;这里咱们就能够通过游标来操作数据行，如图所示此时游标所在的行是“108”的记录，咱们也能够在后果集上滚动游标，指向后果集中的任意一行。2、如何应用游标游标必须在申明处理程序之前被申明，并且变量和条件还必须在申明游标或处理程序之前被申明。1、申明游标语法格局：DECLARE 游标名 CURSOR FOR 查问语句; 要应用 SELECT 语句来获取数据后果集，而此时还没有开始遍历数据，这里 查问语句代表的是 SELECT 语句，返回一个用于创立游标的后果集举例： DECLARE emp_cur CURSOR FOR SELECT employee_id,salary FROM employees;2、关上游标语法格局：OPEN 游标名;当咱们定义好游标之后，如果想要应用游标，必须先关上游标。关上游标的时候 SELECT 语句的查问后果集就会送到游标工作区，为前面游标的逐条读取后果集中的记录做筹备。3、应用游标语法格局： FETCH 游标名 INTO var_name [, var_name] ...这句的作用是应用 游标名这个游标来读取以后行，并且将数据保留到 var_name 这个变量中，游标指针指到下一行。如果游标读取的数据行有多个列名，则在 INTO 关键字前面赋值给多个变量名即可。留神： var_name必须在申明游标之前就定义好。举例： FETCH　emp_cur INTO emp_id, emp_sal ;留神： 游标的查问后果集中的字段数，必须跟 INTO 前面的变量数统一4、敞开游标语法格局：CLOSE 游标名;当咱们应用完游标后须要敞开掉该游标。因为游标会占用系统资源，如果不及时敞开，游标会始终放弃到存储过程完结，影响零碎运行的效率。而敞开游标的操作，会开释游标占用的系统资源。敞开游标之后，咱们就不能再检索查问后果中的数据行，如果须要检索只能再次关上游标。3、代码举例#创立存储过程“get_count_by_limit_total_salary()”，申明IN参数 limit_total_salary，DOUBLE类型；申明OUT参数total_count，INT类型。函数的性能能够实现累加薪资最高的几个员工的薪资值，直到薪资总和达到limit_total_salary参数的值，返回累加的人数给total_count。 DELIMITER $CREATE PROCEDURE get_count_by_limit_total_salary(IN limit_total_salary DOUBLE,OUT total_count INT)BEGIN DECLARE count_emp INT DEFAULT 0; #用来记录人数，默认值是0 DECLARE sum_sal DOUBLE DEFAULT 0; #记录总薪资 DECLARE one_sal DOUBLE DEFAULT 0; #记录一个人的薪资 #申明游标，把查问到的工资后果集从高到低排序 DECLARE emp_cur CURSOR FOR SELECT salary FROM employees ORDER BY salary DESC; OPEN emp_cur; #关上游标 #用循环语句遍历，晓得总薪资满足题目要求 REPEAT #开始应用游标 FETCH emp_cur INTO one_sal; SET sum_sal = sum_sal + one_sal; SET count_emp = count_emp + 1; UNTIL sum_sal >= limit_total_salary END REPEAT; CLOSE emp_cur; #敞开游标 #把后果返回给total_count SELECT count_emp INTO total_count;END $DELIMITER ;CALL get_count_by_limit_total_salary(30000,@count);SELECT @count;思路剖析： 先创立存储过程，而后再依据理论状况declare本人须要的变量来满足题目的要求，游标要按步骤来：创立游标、关上游标、应用游标最初再敞开游标；其中要留神应用游标在循环中，能够进步代码的简洁度。4、小结游标是 MySQL 的一个重要的性能，为逐条读取后果集中的数据，提供了完满的解决方案。跟在利用层面实现雷同的性能相比，游标能够在存储程序中应用，效率高，程序也更加简洁。但同时也会带来一些性能问题，比方在应用游标的过程中，会对数据行进行加锁，这样在业务并发量大的时候，不仅会影响业务之间的效率，还会耗费系统资源，造成内存不足，这是因为游标是在内存中进行的解决。倡议： 养成用完之后就敞开的习惯，这样能力进步零碎的整体效率。感兴趣的敌人能够在3A云服务器上本人部署尝试一下 ...

我应用近程3A服务器进行操作 1.批改数据库配置文件, 使之登录不须要明码此操作须要具备服务器 root 账户权限 1.1切换Linux零碎的 root 用户 注：如果以后应用的是root账户，即不须要再切换 # su - 1.2定位配置文件地位 # locate my.cnf 3应用 vi 工具关上配置文件                # vi /etc/my.cnf                在文件内容 [mysqld] 下方增加“跳过明码登录”的代码skip-grant-tables ，保留后退出。 4确认配置文件内容曾经批改 通过cat命令查看my.cnf 配置文件内容。#cat /etc/my.cnf 2.重新启动Mysql服务 2.1在linux中，执行上面命令，重启mysql服务(服务名可能不一样会导致报错，按本人mysql服务名为主) # systemctl restart mysqld  2.2重启实现能够通过查看状态命令进行验证        # systemctl status mysqld 3.从新登录 MySQL 查看是否须要明码进行登录        3.1确认不须要明码能够登录 MySQL        在Linux中输出：         # mysql -uroot -p        -- 留神：此时不须要明码也能登录MySQL 数据库, 批改数据库账户明码 4.1更新明码 语法：update user set authentication_string=password('新密码') where user = '用户名'; mysql > update user set authentication_string=password('123456') where user = 'root'; 或者： mysql > SET PASSWORD FOR root@localhost = PASSWORD('123456'); 或者： mysql > SET PASSWORD = PASSWORD('123456'); 4.2刷新权限 mysql > flush privileges;5.还原配置文件设置, 使之登录须要明码 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。 一、Debezium介绍摘自官网: Debezium is a set of distributed services to capture changes in your databases so that your applications can see those changes and respond to them. Debezium records all row-level changes within each database table in a _change event stream_, and applications simply read these streams to see the change events in the same order in which they occurred.简略了解就是Debezium能够捕捉数据库中所有行级的数据变动并包装成事件流程序输入。 二、根本应用上面以MySQL为例介绍Debezium的根本应用。 1. MySQL的筹备工作筹备一个MySQL用户并且领有相应权限，像这样： CREATE USER 'dbz'@'%' IDENTIFIED BY 'dbzpwd';GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'dbz' IDENTIFIED BY 'dbzpwd';查看MySQL是否开启log-bin ...

1 前言 数据库为了获得更好的读写性能，InnoDB会将数据缓存在内存中（InnoDB Buffer Pool），对磁盘数据的批改也会落后于内存，这时如果过程或机器解体，会导致内存数据失落，为了保障数据库自身的一致性和持久性，InnoDB保护了REDO LOG。批改Page之前须要先将批改的内容记录到REDO中，并保障REDO LOG早于对应的Page落盘，也就是常说的WAL，Write Ahead Log。当故障产生导致内存数据失落后，InnoDB会在重启时，通过重放REDO，将Page复原到解体前的状态。 2 MYSQL更新语句的执行过程 2.1 MYSQL的体系结构大体来说，MySQL 能够分为 客户端、Server层和存储引擎层三大部分，如图所示。Server 层包含连接器、查问缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数外围服务性能，以及所有的内置函数（如日期、工夫、数学和加密函数等），所有跨存储引擎的性能都在这一层实现，比方存储过程、触发器、视图等。 存储引擎层负责数据的存储和提取。其架构模式是插件式的，反对 InnoDB、MyISAM、Memory 等多个存储引擎。当初最罕用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始成为了默认存储引擎。 2.2 更新SQL的执行 当咱们执行一条更新SQL时是如何执行的呢，上面执行一条简略的SQL更新语句(默认存储引擎InnoDB)update T set c=c+1 where ID=2; 第一步：连接器先通过连接器连贯到这个数据库上。连接器负责跟客户端建设连贯、校验用户名明码的正确性,同时获取该用户的权限放到缓存中、维持和治理连贯第二步：缓存连贯建设实现后，如果执行的是SELECT查问 语句会查问缓存中是否存在该SQL的后果集，如果存在后果则再校验用户表和数据的权限最终将查问到的后果返回。如果是UPDATE，DELETE等更新操作，那么跟这个表无关的查问缓存会置为生效，所以这条语句就会把表 T 上所有缓存后果都清空。第三步：分析器如果没有命中查问缓存，就要开始真正执行语句了。首先，MySQL 须要晓得你要做什么，因而须要对 SQL 语句做解析。分析器先会做“词法剖析”。你输出的是由多个字符串和空格组成的一条 SQL 语句，MySQL 须要辨认出外面的字符串别离是什么，代表什么。例如该语句中c列在表T中是否存在等。做完了这些辨认当前，就要做“语法分析”。依据词法剖析的后果，语法分析器会依据语法规定，判断你输出的这个 SQL 语句是否满足 MySQL 语法。该SQL语句中的update、where 等是否合乎SQL语法第四步：优化器通过了分析器，MySQL 就晓得你要做什么了。在开始执行之前，还要先通过优化器的解决。优化器是在表外面有多个索引的时候，决定应用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连贯程序；优化器决定要应用 ID 这个索引。指定索引也就指定了前面的执行器须要调用存储引擎的哪个接口进行执行。第五步：执行器MySQL 通过分析器晓得了你要做什么，通过优化器晓得了该怎么做，于是就进入了执行器阶段，开始执行语句。开始执行的时候，要先判断一下你对这个表 T 有没有执行查问的权限，如果没有，就会返回没有权限的谬误。执行器负责具体执行，找到这一行，而后更新。 2.3 InnoDB存储引擎引入REDOLOG Mysql自身有本人的日志记录binlog(归档日志:分为row，statement两种模式)，然而只依附binlog是没有crash-safe能力的，所以在存储引擎层InnoDB应用另外一套日志零碎redolog来实现crash-safe能力。同时为了获得更好的读写性能，InnoDB会将数据缓存在内存中（InnoDB Buffer Pool），对磁盘数据的批改也会落后于内存，这时如果过程或机器解体，会导致内存数据失落，从而保障数据库自身的一致性和持久性。批改Page之前须要先将批改的内容记录到REDO中，并保障REDO LOG早于对应的Page落盘，也就是常说的WAL，Write Ahead Log。当故障产生导致内存数据失落后，InnoDB会在重启时，通过重放REDO，将Page复原到解体前的状态。 那么咱们须要什么样的REDO呢？ 首先，REDO的保护减少了一份写盘数据，同时为了保证数据正确，事务只有在他的REDO全副落盘能力返回用户胜利，REDO的写盘工夫会间接影响零碎吞吐，不言而喻，REDO的数据量要尽量少。其次，零碎解体总是产生在始料未及的时候，当重启重放REDO时，零碎并不知道哪些REDO对应的Page曾经落盘，因而REDO的重放必须可重入，即REDO操作要保障幂等。最初，为了便于通过并发重放的形式放慢重启复原速度，REDO应该是基于Page的，即一个REDO只波及一个Page的批改。 数据量小是Logical Logging的长处，而幂等以及基于Page正是Physical Logging的长处。InnoDB采取了一种称为Physiological Logging的形式，来兼得二者的劣势。所谓Physiological Logging，就是以Page为单位，但在Page内以逻辑的形式记录。举个例子，一种作用于Page类型的REDOLOG中记录了对Page中一个Record的批改，办法如下：（Page ID，Record Offset，(Filed 1, Value 1) … (Filed i, Value i) … )其中，PageID指定要操作的Page页，Record Offset记录了Record在Page内的偏移地位，前面的Field数组，记录了须要批改的Field以及批改后的Value。 ...

MySQL Server以后反对如下3种正文格调： 以'# '结尾的单行正文以'-- '结尾的单行正文C语言格调的单行/多行正文如下sql脚本给出了3种正文格调的示例： /* 这是一个多行正文示例*/select 1 from dual;select 2 from dual; # 单行正文用例1select 3 from dual; -- 单行正文用例2可执行正文为了反对在不同数据库之间的可移植性，MySQL Server针对C格调的正文在解析上做了一些扩大，当正文满足如下格调时，MySQL Server将会解析并执行正文中的代码： /*! MySQL-specific code */通过比拟如下两个带正文的sql语句的执行后果能够比拟直观地看出可执行正文语句的行为： # 一般正文，'+1' 被疏忽mysql> select 1 /* +1 */;+---+| 1 |+---+| 1 |+---+# 可执行正文，'+1' 被当成语句的一部分mysql> select 1 /*! +1 */;+-------+| 1 +1 |+-------+| 2 |+-------+借助这一个性，咱们就有机会编写具备较好移植性的SQL语句, 在使MySQL独有个性的同时，保障了sql在其它数据库也可能胜利被执行： create table t1（col1 int） /*! engine=MyISAM */;select /*! STRAIGHT_JOIN */ col1 from t1;.../*!version-number SQL*/在日常应用中，咱们还会常常看到如下格局的正文语句： /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE *//*!80000 SET SESSION information_schema_stats_expiry=0 *//*!50013 DEFINER=`root`@`localhost` SQL SECURITY DEFINER *//*!跟的5位数字为版本指示器，其与数据库版本的对应规定为： ...

发现有MySQL锁超时的谬误日志。 不必想，必定有另一个事务正在批改这条订单，持有这条订单的锁。 导致以后事务获取不到锁，始终期待，直到超过锁超时工夫，而后报错。 既然问题曾经分明了，接下来就轮到怎么排查一下到底是哪个事务正在持有这条订单的锁。 好在MySQL提供了丰盛的工具，帮忙咱们排查锁竞争问题。 现场复现一个这个问题： 创立一张用户表，造点数据： CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键ID', `name` varchar(50) NOT NULL DEFAULT '' COMMENT '姓名', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;事务1，更新id=1的用户姓名，不提交事务： begin;update user set name='一灯' where id=1;事务2，删除id=1的数据，这时候会产生锁期待： begin;delete from user where id=1;接下来，咱们就通过MySQL提供的锁竞争统计表，排查一下锁期待问题： 先查一下锁期待状况： select * from information_schema.innodb_lock_waits;能够看到有一个锁期待的事务。 而后再查一下正在竞争的锁有哪些？ select * from information_schema.innodb_locks;能够看到，MySQL统计的十分具体： lock_trx_id 示意事务ID lock_mode 示意排它锁还是共享锁 lock_type 示意锁定的记录，还是范畴 lock_table 锁的表名 lock_index 锁定的是主键索引 再查一下正在执行的事务有哪些？ select * from information_schema.innodb_trx; 能够分明的看到正在执行的事务有两个，一个状态是锁期待（LOCK WAIT），正在执行的SQL也打印进去了： ...

作者：余振兴 爱可生 DBA 团队成员，热衷技术分享、编写技术文档。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 咱们都晓得应用 mysql 客户端去拜访 MySQL 数据库时，会以肯定的程序去读取不同地位的配置文件，但在一次做测试时，发现除了依照程序读取默认的配置文件门路外，mysql 还有额定的读取配置文件的行为，以下是在我本地测试环境做测试时遇到的一个有意思的小知识点一、场景景象在本地做测试时，发现一个奇怪的景象，当我应用 socket 打算登录数据库，发现不指定用户时，默认并不是用的 root 用户登录，而是被批改为了 zhenxing 用户 [root@10-186-61-162 ~]# mysql -S /data/mysql/3306/data/mysqld.sock -pEnter password:ERROR 1045 (28000): Access denied for user 'zhenxing'@'127.0.0.1' (using password: NO)通过观测以后mysql客户端的默认参数行为,能够看到与报错统一,默认用户的确是变为了zhenxing [root@10-186-61-162 ~]# mysql --help|egrep "user|host|port" -h, --host=name Connect to host. -P, --port=# Port number to use for connection or 0 for default to, in -u, --user=name User for login if not current user.host 127.0.0.1port 3306user zhenxing在这里作为 DBA ，咱们的第一反馈是必定是查看 /etc/my.cnf 文件中是否对默认用户做了配置，于是查看该配置文件的客户端配置参数，如下 ...

本文实用于SkyWalking v9.1.0。SkyWalking简介SkyWalking是一个分布式系统的应用程序性能监督（APM）工具，专为微服务、云原生架构和基于容器（K8s）架构而设计。以后版本具备了全门路跟踪、指标采集、日志记录等性能，并对多种编程语言及平台（Java/C/C++/Go/Rust/Node/PHP等）提了采集代理（agent），并对service mesh（stio + Envoy ）提供反对。 SkyWalking的比照其余罕用监控工具 Zabbix、Prometheus、ELK、Zipkin、Jaeger等有以下特点： 长处 1，一站式全功能的解决方案，反对全门路跟踪、指标采集和日志记录。以后版本仍需依赖内部存储组件（H2/MySQL/PostgreSQL/Elasticsearch）。我的项目自带的BanyanDB正在踊跃研发中，正式公布后可不再依赖内部存储。 2，非侵入式为主的指标采集形式，个别不须要代码级的调整，对几十种支流java组件都有官网插件反对。Java程序通过javaagent+bytebuddy实现动静生成监控插件，Native利用则通过ebpf实现相似性能。 3，标准协议的反对，反对OpenTelemetry、Kafka、estapi、Zabbix多种行业标准或者事实标准的接入，不便各种利用的对接。 4，微服务和云原生的反对，对基于容器（K8s+Java）的全链路监控，反对ebpf agent 通过sidecar注入。 毛病 1 agent不够欠缺，OpenTelemetry采集形式目前须要用Prometheus node expoter采集，再通过Opentelemetry collector转换后导出传导SkyWalking oap. 2 比Zabbix等传统监控工具短少主动探测和资产治理性能，减少自定义监控指标须要手工批改MAL配置文件，不能通过UI配置。 3 官网文档不欠缺，只是相当于参数手册加性能列表，但不足各种监控场景的配置指引。 4 ebpf agent尽管是亮点但实现很高级，最新公布版（0.2.0）只反对cpu profiling。git最新代码已减少network profiling。性能均为go和c混合的硬编实现，用户自行扩大不便。硬编码的ebpf代码也导致对linux内核的兼容性差。gcc4.5+在不同的优化级别（O？）产生的符号命名不一样，会导致ebpf启动失败。 MySQL的监控计划监控项类别监控项监控形式主机或vm的OS指标cpu 内存 磁盘Zabbix agent/Prometheus exporter + otl collectMySQL 日志日志文件Filebeat httpoutput + SkyWalking http json apiebpfcpu/network profile, sql query, fs profile（etx4/xfs）ebpf agent( skeywalking ravor), 除cpu profile外要自行扩大jdbc clientvirtual db,连接池状态等Java agent通过以上各种维度的监控能够全面把握MySQL的运行状态，并能在呈现性能问题时通过ebpf agent（Ravor）近程执行profiling剖析。基于ebpf的监控形式在DBaaS-MySQL容器化部署的形式下十分不便而且性能影响也最小。 限于篇幅起因，在后续的文章中会具体解说每种监控形式的配置和相干扩大代码。 Enjoy GreatSQL :) 文章举荐：乏味的SQL DIGEST ulimits不失效导致数据库启动失败和相干设置阐明MGR及GreatSQL资源汇总 GreatSQL MGR FAQ ...

mysql 的备份和复原创立备份管理员创立备份管理员，并授予管理员相应的权限备份所需权限：select,reload,lock tables,replication client,show view,event,process# 创立管理员create user 'backup'@'localhost' identified by '123456';# 给管理员受权grant select,reload,lock tables,replication client,show view,event,process on *.* to 'backup'@'localhost';sql 文件复原之全量复原只有将备份的 sql 文件间接导入数据库即可mysql -uroot -p 数据库 < sql文件sql 文件复原之基于工夫点的复原# 首先进行一次基于最近一次的全量备份的文件进行一次全量复原mysql -uroot -p 数据库 < sql文件# 而后查看备份的sql文件的 CHANGE MASTER 值，基于该值进行二进制日志的还原CHANGE MASTER TO MASTER_LOG_FILE='binlog.000007', MASTER_LOG_POS=154;# 查看二进制日志,依据工夫点找到误操作前一段时间的二进制日志cd /var/lib/mysqlmysqlbinlog --base64-output=decode-rows -vv --start-position=154 --database=数据库名 binlog.000008 | grep -B3 DELETE | more# 记录最早删除记录的节点值，执行日志导出mysqlbinlog --start-position=开始节点 --stop-position=完结节点 --database=数据库 二进制日志名 > 导出的sql文件名mysqlbinlog --start-position=154 --stop-position=26158 --database=laravel binlog.000007 > laravel.sql# 对导出的sql文件进行全量的还原mysql -uroot -p 数据库 < sql文件mysqldump逻辑备份指定数据库多个表进行备份：mysqldump [OPTIONS] database [table]指定多个数据库备份：mysqldump [OPTIONS] database [OPTIONS] DB1 DB2整个数据库实例进行备份：mysqldump [OPTIONS] --all-database [OPTIONS]参数 --single-transaction：开启事务保障备份数据的完整性，innodb 特有参数 -l或--lock-tables：顺次锁定备份数据库所有表保障备份数据的完整性参数 -x或--lock-all-table：一次性锁定整个数据库实例所有数据表保障数据完整性参数 --master-data=[1/2]：CHANGE MASTER TO 语句会被写成一个 sql 正文；1不会被写成正文，2写成正文，默认1参数 -R或--routines：备份数据库存储过程参数 --triggers：备份数据库触发器参数 -E或--events：备份数据库调度事件参数 --hex-blob：16进制导出bit列和blob列数据 防止数据文本不可见参数 --tab=path：指定门路下为每个数据库生成两个文件：数据结构、数据参数 -w或--where=过滤条件：过滤指定数据，仅反对单表导出留神：--single-transaction，--lock-tables 参数是互斥的，所以，如果同一个数据库下同时存在 innodb 表和myisam表只能应用 --lock-tables 来保障备份数据的一致性，然而 --lock-tables 只能保障某一备份数据库的完整性，不能保障整个实例备份的完整性mysqldump -ubackup -p --master-data=2 --single-transaction --routines --triggers --events 数据库 > 备份文件.sqlXtraBackup备份自定义下载地址：Percona 存储库命令下载：yum install http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm测试储存库装置是否胜利命令：yum list | grep percona# 下载 libev软件包yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm # 装置 libev软件包yum install percona-xtrabackup-24# 全量备份innobackupex --user=管理员账号 --password=明码 --parallel=2 备份门路innobackupex --user=backup --password=Gzjunyu19970925. --parallel=2 /home/db_backup/# 全量复原，倡议复原前进行mysql服务，且清空mysql数据文件innobackupex --datadir=mysql数据门路 --copy-back 备份门路innobackupex --datadir=/var/lib/mysql --copy-back /home/db_backup/2018-04-21_10-44-22/# 批改mysql数据门路的权限为777chmod -R 777 /var/lib/mysql mysql 的分辨别表查看是否反对分辨别表：show plugins;删除分区命令：ALTER TABLE 表名 DROP PARTITION 分表名称;分区分类：范畴分区、哈希分区、工夫分区 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。my2sql工具之疾速入门1.什么是my2sql2.如何疾速部署my2sql工具3.如何应用my2sql工具 3.1应用my2sql工具解析binglog文件3.2应用my2sql工具疾速闪回4.遇到的问题5.应用限度6.总结1. 什么是my2sql？my2sql是go版MySQL binlog解析工具，通过解析MySQL binlog ，能够生成原始SQL、回滚SQL、去除主键的INSERT SQL等，也能够生成DML统计信息。相似工具有binlog2sql、MyFlash、my2fback等，本工具基于my2fback、binlog_rollback工具二次开发而来。2. 如何疾速部署my2sql工具形式一 go编译git clone https://github.com/liuhr/my2sql.gitcd my2sql/go build .形式二 已编译好的二进制文件二进制文件下载地址https://github.com/liuhr/my2s...复制到我的docker中 #1、把my2sql 二进制文件复制到mysql8的容器中 docker cp /usr/local/bin/my2sql mysql8:/usr/local/bin#2、进入容器docker exec -it mysql8 bashchmod +x /usr/local/bin/my2sql3. 如何应用my2sql工具3.1 应用my2sql工具解析binglog文件step1：查问binglog文件mysql> show variables like 'binlog_format';+---------------+-------+| Variable_name | Value |+---------------+-------+| binlog_format | ROW |+---------------+-------+1 row in set (0.00 sec)mysql> show master status;+----------+----------+--------------+------------------+--------------------------------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |+----------+----------+--------------+------------------+----------------------------------------------+| 1.000001 | 1021 | | | ecd66956-f106-11ec-bb85-0242ac110005:1-19718 |+----------+----------+--------------+------------------+----------------------------------------------+1 row in set (0.00 sec)mysql> flush logs;Query OK, 0 rows affected (0.71 sec)mysql> show master status;+----------+----------+--------------+------------------+----------------------------------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |+----------+----------+--------------+------------------+----------------------------------------------+| 1.000002 | 193 | | | ecd66956-f106-11ec-bb85-0242ac110005:1-19718 |+----------+----------+--------------+------------------+----------------------------------------------+1 row in set (0.00 sec)mysql> show variables like 'innodb_log_group_home_dir';+---------------------------+-------+| Variable_name | Value |+---------------------------+-------+| innodb_log_group_home_dir | ./ |+---------------------------+-------+1 row in set (0.01 sec)mysql> show variables like '%datadir%';+---------------+-----------------+| Variable_name | Value |+---------------+-----------------+| datadir | /var/lib/mysql/ |+---------------+-----------------+1 row in set (0.00 sec)step2：查问测试表：-- 查看测试表构造mysql> show create table sbtest.sbtest1\G;*************************** 1. row *************************** Table: sbtest1Create Table: CREATE TABLE `sbtest1` ( `id` int NOT NULL AUTO_INCREMENT, `k` int NOT NULL DEFAULT '0', `c` char(120) COLLATE utf8mb4_0900_bin NOT NULL DEFAULT '', `pad` char(60) COLLATE utf8mb4_0900_bin NOT NULL DEFAULT '', PRIMARY KEY (`id`), KEY `k_1` (`k`)) ENGINE=InnoDB AUTO_INCREMENT=100001 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_bin1 row in set (0.00 sec)--查看测试表行数mysql> select count(*) from sbtest.sbtest1;+----------+| count(*) |+----------+| 100000 |+----------+1 row in set (0.00 sec)--查看测试表的测验值mysql> checksum table sbtest.sbtest1;+----------------+------------+| Table | Checksum |+----------------+------------+| sbtest.sbtest1 | 4167997150 |+----------------+------------+1 row in set (0.09 sec)-- 删除5万行数据mysql> delete from sbtest.sbtest1 where id<50000; 【这里删除了49999行数据】Query OK, 49999 rows affected (7.72 sec)--再次看测试表的测验值mysql> checksum table sbtest.sbtest1;+----------------+------------+| Table | Checksum |+----------------+------------+| sbtest.sbtest1 | 1629663751 |+----------------+------------+1 row in set (0.04 sec)step3：解析binglog文件#解析binglog文件root@29b86217f7d4:/tmp# my2sql -user root -password ****** -host 127.0.0.1 -port 3306 -databases sbtest -tables sbtest1 -mode repl -work-type 2sql -start-file 1.000002 -output-dir /tmp[2022/07/28 10:26:42] [info] binlogsyncer.go:144 create BinlogSyncer with config {1113306 mysql 127.0.0.1 3306 root utf8 false false <nil> false UTC false 0 0s 0s 0 false false 0}[2022/07/28 10:26:42] [info] events.go:60 start thread 1 to generate redo/rollback sql[2022/07/28 10:26:42] [info] binlogsyncer.go:360 begin to sync binlog from position (1.000002, 4)[2022/07/28 10:26:42] [info] stats_process.go:166 start thread to analyze statistics from binlog[2022/07/28 10:26:42] [info] events.go:210 start thread to write redo/rollback sql into file[2022/07/28 10:26:42] [info] events.go:60 start thread 2 to generate redo/rollback sql[2022/07/28 10:26:42] [info] repl.go:16 start to get binlog from mysql[2022/07/28 10:26:42] [info] binlogsyncer.go:777 rotate to (1.000002, 4)[2022/07/28 10:26:50] [info] repl.go:84 deadline exceeded.[2022/07/28 10:26:50] [info] repl.go:18 finish getting binlog from mysql[2022/07/28 10:26:50] [info] stats_process.go:266 exit thread to analyze statistics from binlog[2022/07/28 10:26:50] [info] events.go:185 exit thread 1 to generate redo/rollback sql[2022/07/28 10:26:50] [info] events.go:185 exit thread 2 to generate redo/rollback sql[2022/07/28 10:26:50] [info] events.go:274 finish writing redo/forward sql into file[2022/07/28 10:26:50] [info] events.go:277 exit thread to write redo/rollback sql into fileroot@29b86217f7d4:/tmp# ls -lrttotal 2392-rw-r--r-- 1 root root 261 Jul 28 10:26 biglong_trx.txt-rw-r--r-- 1 root root 2438845 Jul 28 10:26 forward.2.sql-rw-r--r-- 1 root root 288 Jul 28 10:26 binlog_status.txt step4：查看解析后的sql：--文件binlog_status.txt和biglong_trx.txt是事务的统计信息root@29b86217f7d4:/tmp# cat binlog_status.txt binlog starttime stoptime startpos stoppos inserts updates deletes database table 1.000002 2022-07-28_10:24:06 2022-07-28_10:24:06 341 9536267 0 0 49999 sbtest sbtest1 root@29b86217f7d4:/tmp# cat biglong_trx.txtbinlog starttime stoptime startpos stoppos rows duration tables1.000002 2022-07-28_10:24:06 2022-07-28_10:24:06 269 9536294 49999 0 [sbtest.sbtest1(inserts=0, updates=0, deletes=49999)]--文件forward.2.sql是binlog解析之后的sqlroot@29b86217f7d4:/tmp# more -10 forward.2.sql DELETE FROM `sbtest`.`sbtest1` WHERE `id`=1;DELETE FROM `sbtest`.`sbtest1` WHERE `id`=2;DELETE FROM `sbtest`.`sbtest1` WHERE `id`=3;DELETE FROM `sbtest`.`sbtest1` WHERE `id`=4;DELETE FROM `sbtest`.`sbtest1` WHERE `id`=5;DELETE FROM `sbtest`.`sbtest1` WHERE `id`=6;DELETE FROM `sbtest`.`sbtest1` WHERE `id`=7;DELETE FROM `sbtest`.`sbtest1` WHERE `id`=8;DELETE FROM `sbtest`.`sbtest1` WHERE `id`=9;DELETE FROM `sbtest`.`sbtest1` WHERE `id`=10;--More--(0%)3.2 应用my2sql工具疾速闪回step1：生成闪回sql文件root@29b86217f7d4:/tmp# my2sql -user root -password ****** -host 127.0.0.1 -port 3306 -databases sbtest -tables sbtest1 -mode repl -work-type rollback -start-file 1.000002 -output-dir /tmp/flashback/[2022/07/28 10:42:55] [info] events.go:60 start thread 1 to generate redo/rollback sql[2022/07/28 10:42:55] [info] events.go:210 start thread to write redo/rollback sql into file[2022/07/28 10:42:55] [info] binlogsyncer.go:144 create BinlogSyncer with config {1113306 mysql 127.0.0.1 3306 root utf8 false false <nil> false UTC false 0 0s 0s 0 false false 0}[2022/07/28 10:42:55] [info] events.go:60 start thread 2 to generate redo/rollback sql[2022/07/28 10:42:55] [info] stats_process.go:166 start thread to analyze statistics from binlog[2022/07/28 10:42:55] [info] binlogsyncer.go:360 begin to sync binlog from position (1.000002, 4)[2022/07/28 10:42:55] [info] repl.go:16 start to get binlog from mysql[2022/07/28 10:42:55] [info] binlogsyncer.go:777 rotate to (1.000002, 4)[2022/07/28 10:43:00] [info] repl.go:84 deadline exceeded.[2022/07/28 10:43:00] [info] repl.go:18 finish getting binlog from mysql[2022/07/28 10:43:00] [info] stats_process.go:266 exit thread to analyze statistics from binlog[2022/07/28 10:43:00] [info] events.go:185 exit thread 1 to generate redo/rollback sql[2022/07/28 10:43:00] [info] events.go:185 exit thread 2 to generate redo/rollback sql[2022/07/28 10:43:00] [info] events.go:259 finish writing rollback sql into tmp files, start to revert content order of tmp files[2022/07/28 10:43:00] [info] rollback_process.go:15 start thread 1 to revert rollback sql files[2022/07/28 10:43:00] [info] rollback_process.go:41 start to revert tmp file /tmp/flashback/.rollback.2.sql into /tmp/flashback/rollback.2.sql[2022/07/28 10:43:00] [info] rollback_process.go:156 finish reverting tmp file /tmp/flashback/.rollback.2.sql into /tmp/flashback/rollback.2.sql[2022/07/28 10:43:00] [info] rollback_process.go:25 exit thread 1 to revert rollback sql files[2022/07/28 10:43:00] [info] events.go:272 finish reverting content order of tmp files[2022/07/28 10:43:00] [info] events.go:277 exit thread to write redo/rollback sql into filestep2：查看生成的闪回文件：root@29b86217f7d4:/tmp/flashback# ls -lrttotal 12596-rw-r--r-- 1 root root 261 Jul 28 10:42 biglong_trx.txt-rw-r--r-- 1 root root 288 Jul 28 10:43 binlog_status.txt-rw-r--r-- 1 root root 12888636 Jul 28 10:43 rollback.2.sqlroot@29b86217f7d4:/tmp/flashback# cat biglong_trx.txtbinlog starttime stoptime startpos stoppos rows duration tables1.000002 2022-07-28_10:24:06 2022-07-28_10:24:06 269 9536294 49999 0 [sbtest.sbtest1(inserts=0, updates=0, deletes=49999)]root@29b86217f7d4:/tmp/flashback# cat binlog_status.txtbinlog starttime stoptime startpos stoppos inserts updates deletes database table 1.000002 2022-07-28_10:24:06 2022-07-28_10:24:06 341 9536267 0 0 49999 sbtest sbtest1 root@29b86217f7d4:/tmp/flashback# more -10 rollback.2.sqlINSERT INTO `sbtest`.`sbtest1` (`id`,`k`,`c`,`pad`) VALUES (49999,33022,'82276829554-28600016482-71437056503-67189283057-49828408020-97469013057-54486869404-00631592142-97314346455-10619483378','14496218158-82953408254-72982060504-31493955809-57788873512');INSERT INTO `sbtest`.`sbtest1` (`id`,`k`,`c`,`pad`) VALUES (49998,50244,'96937339387-30971064351-79066739653-24906328840-02614118448-07131634761-96921531810-30574594369-22852947139-53163560618','11061918782-99235282357-54725926348-09882016546-43656283296');INSERT INTO `sbtest`.`sbtest1` (`id`,`k`,`c`,`pad`) VALUES (49997,49958,'23875561992-79383179714-31844019265-78678195929-11039506986-44432953782-19018620372-45679869851-21838821757-54316746647','72021998255-21544610411-49097617755-83325624702-67496909817');INSERT INTO `sbtest`.`sbtest1` (`id`,`k`,`c`,`pad`) VALUES (49996,49784,'64121185719-74243968401-44193775190-53796401184-56297492349-79981936074-03057285270-03714583251-22209198873-10937378934','77159337465-83656217977-70877234699-71552982384-42185635425');INSERT INTO `sbtest`.`sbtest1` (`id`,`k`,`c`,`pad`) VALUES (49995,49750,'32364537835-96169411677-52025383891-99856461851-54876781624-38035712955-18254695168-34412213489-24174915574-41228645716','40846762001-49118260546-21871620253-63339659850-56585169893');--More--(0%)step3：利用rollback文件进行数据恢复mysql -uroot -p****** -P3306 -h127.0.0.1 sbtest < /tmp/flashback/rollback.2.sqlstep4：最初查看复原状况mysql> select count(*) from sbtest.sbtest1;+----------+| count(*) |+----------+| 100000 |+----------+1 row in set (0.01 sec)mysql> checksum table sbtest.sbtest1;+----------------+------------+| Table | Checksum |+----------------+------------+| sbtest.sbtest1 | 4167997150 |+----------------+------------+1 row in set (0.08 sec)4. 遇到的问题问题1：Connect mysql failed this authentication plugin is not supportedmy2sql -user greatsql -password ****** -host 127.0.0.1 -port 3306 -mode repl -work-type 2sql -start-file binlog.000001[2022/07/28 10:00:01] [fatal] context.go:575 Connect mysql failed this authentication plugin is not supported解决 ...

MyCAT+MySQL搭建高可用企业级数据库集群内附材料文档下载地址：百度网盘从零开始自己动手写自旋锁咱们在写并发程序的时候，一个非常常见的需要就是保障在某一个时刻只有一个线程执行某段代码，像这种代码叫做临界区，而通常保障一个时刻只有一个线程执行临界区的代码的方法就是锁。在本篇文章当中咱们将会认真分析和学习自旋锁，所谓自旋锁就是通过while循环实现的，让拿到锁的线程进入临界区执行代码，让没有拿到锁的线程一直进行while死循环，这其实就是线程自己“旋”在while循环了，因而这种锁就叫做自旋锁。原子性在谈自旋锁之前就不得不谈原子性了。所谓原子性简略说来就是一个一个操作要么不做要么全做，全做的意义就是在操作的过程当中不能够被中断，比方说对变量data进行加一操作，有以下三个步骤： 将data从内存加载到寄存器。将data这个值加一。将失去的后果写回内存。 原子性就示意一个线程在进行加一操作的时候，不能够被其余线程中断，只有这个线程执行完这三个过程的时候其余线程才能够操作数据data。咱们现在用代码体验一下，在Java当中咱们可能使用AtomicInteger进行对整型数据的原子操作：import java.util.concurrent.atomic.AtomicInteger; public class AtomicDemo { public static void main(String[] args) throws InterruptedException { AtomicInteger data = new AtomicInteger();data.set(0); // 将数据初始化位0Thread t1 = new Thread(() -> { for (int i = 0; i < 100000; i++) { data.addAndGet(1); // 对数据 data 进行原子加1操作 }});Thread t2 = new Thread(() -> { for (int i = 0; i < 100000; i++) { data.addAndGet(1);// 对数据 data 进行原子加1操作 }});// 启动两个线程t1.start();t2.start();// 等待两个线程执行实现t1.join();t2.join();// 打印最终的后果System.out.println(data); // 200000}} ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。前言在理论开发过程中，统计一个表的数据量是常常遇到的需要，用来统计数据库表的行数都会应用COUNT(*)，COUNT(1)或者COUNT(字段)，然而表中的记录越来越多，应用COUNT(*)也会变得越来越慢，明天咱们就来剖析一下COUNT(*)的性能到底如何。 1.COUNT(1)、COUNT(*)与COUNT(字段)哪个更快？执行成果： COUNT(*)MySQL 对count(*)进行了优化，count(*)间接扫描主键索引记录，并不会把全副字段取出来，间接按行累加。COUNT(1)InnoDB引擎遍历整张表，但不取值，server 层对于返回的每一行，放一个数字“1”进去，按行累加。COUNT(字段)如果这个“字段”是定义为NOT NULL，那么InnoDB 引擎会一行行地从记录外面读出这个字段，server 层判断不能为NULL，按行累加;如果这个“字段”定义容许为NULL，那么InnoDB 引擎会一行行地从记录外面读出这个字段，而后把值取出来再判断一下，不是 NULL才累加。试验剖析本文测试应用的环境：[root@zhyno1 ~]# cat /etc/system-releaseCentOS Linux release 7.9.2009 (Core)[root@zhyno1 ~]# uname -aLinux zhyno1 3.10.0-1160.62.1.el7.x86_64 #1 SMP Tue Apr 5 16:57:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux测试数据库采纳的是（存储引擎采纳InnoDB，其它参数默认）：(Mon Jul 25 09:41:39 2022)[root@GreatSQL][(none)]>select version();+-----------+| version() |+-----------+| 8.0.25-16 |+-----------+1 row in set (0.00 sec)试验开始： #首先咱们创立一个试验表CREATE TABLE test_count ( `id` int(10) NOT NULL AUTO_INCREMENT PRIMARY KEY, `name` varchar(20) NOT NULL, `salary` int(1) NOT NULL, KEY `idx_salary` (`salary`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;#插入1000W条数据DELIMITER //CREATE PROCEDURE insert_1000w()BEGIN DECLARE i INT; SET i=1; WHILE i<=10000000 DO INSERT INTO test_count(name,salary) VALUES('KAiTO',1); SET i=i+1; END WHILE;END//DELIMITER ;#执行存储过程call insert_1000w();接下来咱们别离来试验一下： ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。前言明天遇到一个很神奇的景象，在数据库中，雷同的执行打算，执行SQL所须要的工夫相差很大，执行快的SQL霎时出后果，执行慢的SQL要几十秒才出后果，一度让我狐疑是数据库抽风了，前面才发现是见识有余，又进入了常识空白区。 场景复现数据库版本应用的是8.0.23 MySQL Community Server - GPL 因为生产环境数据敏感，禁止随便折腾，我在本人的测试环境，通过如下步骤，结构了一批数据，勉强可能复现出雷同的场景来 应用sysbench结构一万张表，每张表10行记录即可。create table test.test_col as select * from information_schema.columns;create table test.test_tab as select * from information_schema.tables;create table test.test_tc as select * from information_schema.table_constraints;执行10次 insert into test.test_tab select * from test.test_tab;创立必要的索引alter table test_col add key(table_schema, table_name);alter table test_col add key(column_name);alter table test_tab add key(table_schema, table_name);alter table test_tc add key(table_name);最终我测试表的数据如下 mysql> select count(1) from test_col;+----------+| count(1) |+----------+| 1395616|+----------+1 row in set (3.29 sec)mysql> select count(1) from test_tab;+----------+| count(1) |+----------+| 10338 |+----------+1 row in set (0.12 sec)mysql> select count(1) from test_tc;+----------+| count(1) |+----------+| 10143 |+----------+1 row in set (0.06 sec)先看执行快的SQL和它的执行打算 ...

基于ubuntu20.04装置MySQL全过程记录 1.装置MySQLsudo apt-get update #获取最新的软件源sudo apt-get install mysql-server #装置mysql启动与敞开mysql service mysql start #启动MySQLservice mysql stop #敞开MySQL2.进行MySQL配置启动mysql service mysql start为避免下一步配置时呈现设置明码出错的bug，先将root明码进行设置（倡议执行，我集体每次间接执行下一步配置时都会在明码那里报错） sudo mysqlALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password';exit进行配置操作 sudo mysql_secure_installation执行后依照流程进行抉择即可，如果未对root进行明码设置，此过程第二步设置明码时可能呈现报错"Failed! Error: SET PASSWORD has no significance for user 'root'@'localhost' as the authentication method used doesn't store authentication data in the MySQL server...."，倡议先返回执行上一步内容。 后续就是跟着主动配置程序的问题进行yes or no的抉择。大略内容如下： #1.询问是否装置明码插件#2.为root用户设置明码 or 是否须要重置明码#3.是否删除匿名用户#4.是否禁止root管理员从近程登录#5.是否删除test数据库并勾销对它的拜访权限#6.是否刷新受权表，让初始化后的设定立刻失效都选完后显示All done 查看mysql运行状态 netstat -tap | grep mysql3.配置远程登陆（如果需要的话）此时mysql还不容许近程登录，如果通过navicat之类的工具从其余地址进行连贯时，会报错Host is not allowed to connect to this MySQL server，如果业务有需要的话，须要进行放开操作。 ...

各位社区的小伙伴们，StoneDB 第一季文档捉虫流动带着周边上线啦！！！ 6月29日 StoneDB 举办了线上发布会，正式发表开源。尽管开源前做足了筹备，bug 还是在劫难逃。在这一个多月里咱们收到了太多因为文档问题而产生的各类报错反馈，在为社区用户解答发问的同时，咱们也在第一工夫查看了相干的文档内容并做出修改。思考到这一次的修改未必能百分百的解决所有文档上的痛点，为了找出这些潜在的破绽，咱们决定举办这次的文档捉虫流动。正所谓人多力量大，为了给所有的社区用户一个更好的应用感触，咱们诚挚地邀请社区的搭档们使用火眼金睛，一起欠缺社区文档！共建属于大家的开源社区！ 参加 StoneDB 文档捉虫流动，提交无效 issue 或者 PR 取得对应积分，即可兑换社区的精美周边礼品，同时跟技术大佬们一起呈现在社区官网贡献者页面，让咱们期待您的参加！ 一、流动报名增加 StoneDB 小助手（ StoneDB_2022 ）为微信好友，发送您的“ GitHub 用户名+报名文档捉虫流动”并关注公众号，即报名胜利。流动工夫：8月9日至9月12日 二、参加流动1. 提 issue请先浏览 StoneDB 的文档，发现文档中存在的谬误，返回 StoneDB 的 文档仓库提 issue，提交前请先搜寻该问题是否已有记录。 2. 提 PR请确定须要解决的文档问题，须要有对应的 issue 。Fork StoneDB仓库并批改问题 ，而后提交 PR。除了本人提交的 issue ，其余尚未失去解决的 issue 也可认领并提交 PR 哦~ 3. 文档仓库地址中文文档地位：https://github.com/stoneatom/...英文文档地位：https://github.com/stoneatom/...注：本次文档捉虫限5.7版本。 三、积分规定1.低错类问题：每个 issue 1 分、每个 PR 2 分。错别字、拼写错误、链接谬误异样、文档格局错乱等表述不通顺，但不影响了解 2.易用性问题：每个 issue 3 分、每个 PR 5 分。关键步骤谬误或缺失，无奈领导用户实现工作短少必要的前提条件、注意事项等文档内代码谬误，例如少空格、少引号等 3.正确性问题：每个 issue 5 分、每个 PR 8 分。形容存在歧义，逻辑不清晰原理图、架构图、性能等存在谬误要害参数形容谬误，无奈领导用户实现工作 4.危险提醒类问题：每个 issue 8 分、每个 PR 12 分。对重要数据或零碎存在特地危险的操作，短少平安提醒 ...

如何在多表关联场景下正当利用分区表来晋升查问性能？基于前几篇对于分区表的介绍，想必大家对 MySQL 分区表的认知曾经十分全面：分区表存在的目标就是为了缩小每次检索的数据量从而晋升整体性能。 前几篇介绍了基于分区表的单表利用，那么分区表在多表关联时是否有必然的性能晋升？ 常常有人会问这样的一些问题：我用了分区表，然而查问一点也没有放慢，反而更慢了，是什么起因？是不是分区表自身有缺点？还是我没有了解分区表适宜的场景？对于这些个问题，我明天用几类典型的查问场景来举例说明。 第一种场景：两表关联，关联键是分区键，然而没有过滤条件。相似这样： select * from t1 inner join t2 using(id); 这类场景用分区表只会让查问性能更差，并不会减速查问性能。 不必分区表时，表关联数目只有两张；用了分区表，参加表关联的表数目就不仅仅是两张，还有泛滥表分区，分区数目越多，查问性能越差。 举个简略例子：表t1 为哈希分区表，有1000个分区，记录数50W行。 localhost:ytt>show create table t1\G*************************** 1. row *************************** Table: t1Create Table: CREATE TABLE `t1` ( `id` int DEFAULT NULL, `r1` int DEFAULT NULL, `r2` int DEFAULT NULL, `log_date` date DEFAULT NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 /*!50100 PARTITION BY HASH (`id`)PARTITIONS 1000 */1 row in set (0.00 sec)表 t1_no_pt 为一般表，为表t1的克隆，然而移除掉表分区，记录数也同样为50W条。 localhost:ytt>show create table t1_no_pt\G*************************** 1. row *************************** Table: t1_no_ptCreate Table: CREATE TABLE `t1_no_pt` ( `id` int DEFAULT NULL, `r1` int DEFAULT NULL, `r2` int DEFAULT NULL, `log_date` date DEFAULT NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 1 row in set (0.00 sec)这两张表在这种场景下的查问性能比照： 分区表和一般表关联查问，执行工夫为6.76秒。 ...

前言已知，在关系型数据库中的事务的ACID模型由原子性，一致性，隔离性和持久性组成，对于MySQL的InnoDB引擎，隔离性由基于乐观锁的加锁机制和基于无锁的多版本并发管制来反对，而原子性，则由在引擎层生成的undo log来保障，以及持久性，则是由在引擎层生成的redo log和在Service层生成的binlog来独特撑持，除此之外，在Service层生成的binlog还会用于MySQL的主从同步，所以MySQL中的redo log，binlog和undo log是非常重要的，本篇文章将对这三大日志进行学习。 MySQL版本：5.7 注释一. MySQL中的页在学习三大日志之前，先理解一下MySQL中的页的概念。因为InnoDB引擎中将数据存储在磁盘上，所以为了防止读取数据时与磁盘频繁产生IO，InnoDB引擎采纳页（Page）作为磁盘与内存交互的根本单位。每次会将一页数据加载到内存中，以晋升后续操作数据的效率。 InnoDB引擎，操作系统的文件管理系统，磁盘扇区三者之间的关系能够用下图进行示意。 注：后续称MySQL中的页为数据页。 二. Buffer Pool只管InnoDB每次读取数据都会将数据页加载到内存中，以缩小IO开销，然而如果每次都从磁盘读取数据页，效率也不会高，所以在InnoDB中退出了一个内存缓冲区，叫做Buffer Pool。 读取数据时，先判断数据所在数据页是否存在于Buffer Pool中，如果存在于Buffer Pool中，则读取Buffer Pool中的数据，如果不存在于Buffer Pool中，则从磁盘上读取数据页，并将读取到的数据页写入Buffer Pool。 批改数据时，也会先将批改写入到Buffer Pool，而不会间接写入磁盘，此时就会呈现Buffer Pool中的数据页内容和磁盘上的数据页的内容不统一的状况，此时称这样的数据页为脏页，因而InnoDB引擎提供了一个后盾线程每隔肯定工夫将Buffer Pool中的内容写入磁盘，这样的过程叫做刷脏，通过Buffer Pool + 刷脏，能够实现一次性将多个批改同步到磁盘，从而缩小IO次数，进步InnoDB引擎的读写效率。 批改数据时InnoDB引擎中基于Buffer Pool的交互流程图如下所示。 三. Redo LogInnoDB存储引擎为了进步读写效率，引入了Buffer Pool，当要操作的数据所在的数据页在Buffer Pool中不存在时，会先将数据页从磁盘加载到Buffer Pool中，而后对Buffer Pool中的数据进行操作，此时会呈现脏页，所以InnoDB引擎提供了一个后盾线程以肯定的周期执行刷脏操作。然而刷脏并不是实时的，当Buffer Pool中存在脏页，此时MySQL服务端产生故障而宕机或重启，此时Buffer Pool中脏页所对应的那一部分数据批改就失落了。 为了解决数据失落的问题，InnoDB引入了redo log（重做日志）来进行爱护。当对Buffer Pool中的数据进行批改后，还会将对数据所做的批改写入redo log中，如果呈现了因为MySQL服务端宕机或者重启而导致数据失落的状况，此时能够在MySQL服务端启动的时候，从redo log进行数据的复原。实际上redo log也有一个缓冲区，叫做redo log buffer，当要向redo log记录信息时，会先记录到redo log buffer中，而后在适当的机会（可配）把redo log buffer的内容写入到磁盘上的redo log中。那么批改数据时InnoDB引擎中基于Buffer Pool和redo log buffer的交互流程图如下所示。 那么当初对于redo log有如下几点须要进行阐明。 1. 刷盘机会注：上面提及的page cache能够了解为OS文件管理系统的缓冲区，在向磁盘写入数据时，会先写入到page cache中，而后再通过fsync函数将page cache中的内容刷到磁盘上。 InnoDB引擎中应用innodb_flush_log_at_trx_commit来设置redo log的刷盘机会策略，其能够设置反对三种策略。 innodb_flush_log_at_trx_commit为0，示意每次提交事务时不会刷盘；innodb_flush_log_at_trx_commit为1，示意每次提交事务时会刷盘，即先将redo log buffer内容写入page cache，而后调用fsync函数将page cache中的内容刷到磁盘上；innodb_flush_log_at_trx_commit为2，示意每次提交事务时，仅将redo log buffer内容写入page cache。同时，InnoDB引擎有一个后盾线程，其1秒执行一次，会将redo log buffer的内容写入page cache，而后再调用fsync函数将page cache中的内容写到磁盘的redo log文件中，所以innodb_flush_log_at_trx_commit的值无论设置为0，1或者2，最终都是能够将redo log buffer的内容写到磁盘的redo log文件中的。上面给出innodb_flush_log_at_trx_commit被设置为不同值时的刷盘示意图。 ...

作者：唐龙哲 爱可生交付服务团队上海DBA，负责 MySQL 数据库故障解决及日常保护。善于故障诊断 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 一、背景形容最近在客户环境遇到一个 sql_slave_skip_counter 应用不标准引起的主从故障问题。 咱们晓得 mysql 的主从复制是逻辑复制，所以 slave 在利用 relay log 的过程中，常常会遇到谬误，而参数 sql_slave_skip_counter 能够设置跳过多少个 event ，让从库 sql 持续回放。然而如果 sql_slave_skip_counter 使用不当，也会造成主从数据不统一。 以下为抓取的局部谬误日志截图：能够看到为了跳过报错的 SQL ，现场有手动设置过 SQL_SLAVE_SKIP_COUNTER=100000 ，示意跳过10万的 events ，而 binlog event 事件的多少，与事务表/非事务表、及 binlog 日志模式无关。 常见谬误阐明： write_rows ：Duplicate entry（1062谬误）主键抵触，次要体现为反复插入曾经存在的记录; update_rows ：Can't find record（1032谬误），无奈发现须要更新的行记录。 sql_slave_skip_counter 参数阐明：从官网解释晓得，sql_slave_skip_counter以event 为单位 skip ，直到 skip 完第N个 event 所在的 event group 才进行。对于事务表，一个 event group 对应一个事务; 对于非事务表，一个 event group 对应一条 SQL 语句。并且一个 event group 能够蕴含多个 event 事件。具体解释，能够参考官网文档： ...

在 MySQL 中，字符串和数字做比拟的话，是将字符串转换成数字。字符集 utf8mb4 是 utf8 的超集，所以当这两个类型的字符串在做比拟的时候，MySQL 外部的操作是，先把 utf8 字符串转成 utf8mb4 字符集，再做比拟。 select * from trade_detail where CONVERT(traideid USING utf8mb4)=$L2.tradeid.value;

mysql逻辑架构mysql数据库逻辑结构图如下：该图中次要模块和性能如下： 连接器用户客户端连贯解决，受权认证等。解析器/优化器/执行器该层涵盖了mysql外围性能：申请解析、优化、内置函数等。该层会解析查问，生成解析树并对其进行优化，蕴含重写查问、索引抉择、表读取程序调整等。存储引擎负责mysql数据的存储与提取。服务器通过接口api与存储引擎进行通信，这些接口屏蔽了不同存储引擎之间的差别。

作者：杨际宁 爱可生 DBA 团队成员，次要负责 MySQL 日常保护、故障解决和性能优化。对技术执着，为客户负责。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 一、背景阐明开发反馈连 router 报错：'ERROR 1040 (HY000): Too many connections to MySQL Router'， 而后端 mysqlserver 上的连贯却只有几个。经排查发现，当连接时间超过 wait_timeout 设定的值后，8.0.29 版本 router 的 TCP 连贯并不会开释，且 8.0.30 版本的 router 仍旧存在这个问题，因而采纳降级的形式进行解决。 二、问题复现mysqlserver 版本 mysql> select version();+-----------+| version() |+-----------+| 8.0.28 |+-----------+1 row in set (0.01 sec)router 版本 shell> ./mysqlrouter -VMySQL Router Ver 8.0.30 for Linux on x86_64 (MySQL Community - GPL)router 端口设置为 8030 和设置最大连接数 max_connections = 3 不便复现 ...

MySQL源码解析之执行打算MySQL执行打算介绍MySQL执行打算代码概览MySQL执行打算总结一、MySQL执行打算介绍在MySQL中，执行打算的实现是基于JOIN和QEP_TAB这两个对象。其中JOIN类示意一个查问语句块的优化和执行，每个select查问语句（即Query_block对象）在解决的时候，都会被当做JOIN对象，其定义在sql/sql_optimizer.h。 QEP_TAB是Query Execution Plan Table的缩写，这里的表Table对象次要蕴含物化表、长期表、派生表、常量表等。JOIN::optimize()是优化执行器的对立入口，在这里会把一个查问语句块Query_block最终优化成QEP_TAB。 在MySQL-8.0.22版本之后，又引入拜访形式AccessPath和执行迭代器Iterator对象，再联合JOIN和QEP_TAB对象，最终失去整个解析打算的执行门路。 二、MySQL执行打算代码概览本文次要基于MySQL-8.0.25版本，进行阐明。 优化器的入口函数：bool JOIN::optimize()，对应代码文件sql/sql_optimizer.cc。 // 次要性能是把一个查问块Query_block优化成一个QEP_TAB，失去AccessPathbool JOIN::optimize() { ... // 上面次要是为了能够借助INFORMATION_SCHEMA.OPTIMIZER_TRACE表，跟踪优化器的执行状态和执行步骤 Opt_trace_context *const trace = &thd->opt_trace; Opt_trace_object trace_wrapper(trace); Opt_trace_object trace_optimize(trace, "join_optimization"); trace_optimize.add_select_number(Query_block->select_number); Opt_trace_array trace_steps(trace, "steps"); ... // 窗口函数拆卸优化 if (has_windows && Window::setup_windows2(thd, m_windows)) ... // 拷贝Query_block上的条件正本到JOIN构造关联的成员对象，为后续优化做筹备 if (Query_block->get_optimizable_conditions(thd, &where_cond, &having_cond)) ... // 统计形象语法树中的叶节点表，其中leaf_tables是在Query_block::setup_tables中进行拆卸 tables_list = Query_block->leaf_tables; ... // 分区裁剪 if (Query_block->partitioned_table_count && prune_table_partitions()) { ... // 尝试把聚合函数COUNT()、MIN()、MAX()对应的值，替换成常量 if (optimize_aggregated_query(thd, Query_block, *fields, where_cond, &outcome)) { ... // 采纳超图算法生成执行打算，留神超图算法通过set optimizer_switch="hypergraph_optimizer=on"形式启用 if (thd->lex->using_hypergraph_optimizer) { FindBestQueryPlan(thd, Query_block, /*trace=*/nullptr); // 如果Join优化器是超图算法，解决完结间接返回 return false; } ...上面代码次要波及Join优化器连贯形式为左深树的状况，次要用到join_tab数组来进行组织关联 ...

为什么会产生这种的事变？InnoDB 存储引擎的默认事务隔离级别是「可反复读」，然而在这个隔离级别下，在多个事务并发的时候，会呈现幻读的问题，所谓的幻读是指在同一事务下，间断执行两次同样的查问语句，第二次的查问语句可能会返回之前不存在的行。 因而 InnoDB 存储引擎本人实现了行锁，通过 next-key 锁（记录锁和间隙锁的组合）来锁住记录自身和记录之间的“间隙”，避免其余事务在这个记录之间插入新的记录，从而防止了幻读景象。 当咱们执行 update 语句时，实际上是会对记录加独占锁（X 锁）的，如果其余事务对持有独占锁的记录进行批改时是会被阻塞的。另外，这个锁并不是执行完 update 语句就会开释的，而是会等事务完结时才会开释。 在 InnoDB 事务中，对记录加锁带根本单位是 next-key 锁，然而会因为一些条件会进化成间隙锁，或者记录锁。加锁的地位精确的说，锁是加在索引上的而非行上。 在 update 语句的 where 条件没有应用索引，就会全表扫描，于是就会对所有记录加上 next-key 锁（记录锁 + 间隙锁），相当于把整个表锁住了。 能够看到，这次事务 B 的 update 语句被阻塞了。这是因为事务 A的 update 语句中 where 条件没有索引列，所有记录都会被加锁，也就是这条 update 语句产生了 4 个记录锁和 5 个间隙锁，相当于锁住了全表。 该如何防止这种事变的产生？咱们能够将 MySQL 里的 sql_safe_updates 参数设置为 1，开启安全更新模式。大抵的意思是，当 sql_safe_updates 设置为 1 时。update 语句必须满足如下条件之一能力执行胜利：应用 where，并且 where 条件中必须有索引列；应用 limit；同时应用 where 和 limit，此时 where 条件中能够没有索引列； delete 语句必须满足以下条件能执行胜利：同时应用 where 和 limit，此时 where 条件中能够没有索引列；如果 where 条件带上了索引列，然而优化器最终扫描抉择的是全表，而不是索引的话，咱们能够应用 force index([index_name]) 能够通知优化器应用哪个索引，以此防止有几率锁全表带来的隐患。 ...

MySQL中默认采纳的是主动提交（autocommit）模式，在主动提交模式下，如果没有start transaction显式地开始一个事务，那么每个sql语句都会被当做一个事务执行提交操作。 一、ACID个性ACID是掂量事务的四个个性： 原子性（Atomicity，或称不可分割性）一致性（Consistency）隔离性（Isolation）持久性（Durability）二、原子性1、定义原子性是指一个事务是一个不可分割的工作单位，其中的操作要么都做，要么都不做；如果事务中一个sql语句执行失败，则已执行的语句也必须回滚，数据库退回到事务前的状态。 2、实现原理：undo log实现原子性的要害，是当事务回滚时可能撤销所有曾经胜利执行的sql语句。InnoDB实现回滚，靠的是undo log：当事务对数据库进行批改时，InnoDB会生成对应的undo log；如果事务执行失败或调用了rollback，导致事务须要回滚，便能够利用undo log中的信息将数据回滚到批改之前的样子。undo log属于逻辑日志，它记录的是sql执行相干的信息。当产生回滚时，InnoDB会依据undo log的内容做与之前相同的工作：对于每个insert，回滚时会执行delete；对于每个delete，回滚时会执行insert；对于每个update，回滚时会执行一个相同的update，把数据改回去。 三、持久性1、定义持久性是指事务一旦提交，它对数据库的扭转就应该是永久性的。接下来的其余操作或故障不应该对其有任何影响。 2、实现原理：redo log上面先聊一下redo log存在的背景。InnoDB作为MySQL的存储引擎，数据是寄存在磁盘中的，但如果每次读写数据都须要磁盘IO，效率会很低。为此，InnoDB提供了缓存(Buffer Pool)，Buffer Pool中蕴含了磁盘中局部数据页的映射，作为拜访数据库的缓冲：当从数据库读取数据时，会首先从Buffer Pool中读取，如果Buffer Pool中没有，则从磁盘读取后放入Buffer Pool；当向数据库写入数据时，会首先写入Buffer Pool，Buffer Pool中批改的数据会定期刷新到磁盘中 Buffer Pool的应用大大提高了读写数据的效率，然而也带了新的问题：如果MySQL宕机，而此时Buffer Pool中批改的数据还没有刷新到磁盘，就会导致数据的失落，事务的持久性无奈保障。 于是，redo log被引入来解决这个问题：当数据批改时，除了批改Buffer Pool中的数据，还会在redo log记录这次操作；当事务提交时，会调用fsync接口对redo log进行刷盘。 所有批改先写入日志redo log，再更新到Buffer Pool，如果MySQL宕机，重启时能够读取redo log中的数据，保障了数据不会因MySQL宕机而失落，从而满足了持久性要求。 既然redo log也须要在事务提交时将日志写入磁盘，为什么它比间接将Buffer Pool中批改的数据写入磁盘(即刷脏)要快呢？次要有以下两方面的起因：（1）刷脏是随机IO，因为每次批改的数据地位随机，但写redo log是追加操作，属于程序IO。（2）刷脏是以数据页（Page）为单位的，MySQL默认页大小是16KB，一个Page上一个小批改都要整页写入；而redo log中只蕴含真正须要写入的局部，有效IO大大减少。 3、redo log与binlog在MySQL中还存在binlog(二进制日志)也能够记录写操作并用于数据的复原，但二者是有着基本的不同的：（1）作用不同：redo log是用于crash recovery的，保障MySQL宕机也不会影响持久性；binlog是用于point-in-time recovery的，保障服务器能够基于工夫点复原数据，此外binlog还用于主从复制。（2）档次不同：redo log是InnoDB存储引擎实现的，而binlog是MySQL的服务器层（3）内容不同：redo log是物理日志，内容基于磁盘的Page；binlog是逻辑日志，内容是一条条sql。（4）写入机会不同：binlog在事务提交时写入；redo log的写入机会绝对多元 四、隔离性1、定义隔离性是指，事务外部的操作与其余事务是隔离的，并发执行的各个事务之间不能相互烦扰。隔离性的探讨，次要能够分为两个方面：(一个事务)写操作对(另一个事务)写操作的影响：锁机制保障隔离性(一个事务)写操作对(另一个事务)读操作的影响：MVCC保障隔离性 2、锁机制锁机制的基本原理能够概括为：事务在批改数据之前，须要先取得相应的锁；取得锁之后，事务便能够批改数据；该事务操作期间，这部分数据是锁定的，其余事务如果须要批改数据，须要期待以后事务提交或回滚后开释锁MySQL中不同的存储引擎反对的锁是不一样的，例如MyIsam只反对表锁，而InnoDB同时反对表锁和行锁，且出于性能思考，绝大多数状况下应用的都是行锁。 3、脏读、不可反复读和幻读首先来看并发状况下，读操作可能存在的三类问题：（1）脏读：以后事务(A)中能够读到其余事务(B)未提交的数据（脏数据），这种景象是脏读。（2）不可反复读：在事务A中先后两次读取同一个数据，两次读取的后果不一样，这种景象称为不可反复读。（3）幻读：在事务A中依照某个条件先后两次查询数据库，两次查问后果的条数不同，这种景象称为幻读。 4、事务隔离级别 5、MVCCMVCC的特点：在同一时刻，不同的事务读取到的数据可能是不同的(即多版本)MVCC最大的长处是读不加锁，因而读写不抵触，并发性能好。 InnoDB实现MVCC，多个版本的数据能够共存，次要是依附数据的暗藏列(也能够称之为标记位)和undo log。其中数据的暗藏列包含了该行数据的版本号、删除工夫、指向undo log的指针等等；当读取数据时，MySQL能够通过暗藏列判断是否须要回滚并找到回滚须要的undo log，从而实现MVCC； 五、一致性1、定义一致性是指事务执行完结后，数据库的完整性束缚没有被毁坏，事务执行的前后都是非法的数据状态。数据库的完整性束缚包含但不限于：实体完整性（如行的主键存在且惟一）、列完整性（如字段的类型、大小、长度要符合要求）、外键束缚、用户自定义完整性（如转账前后，两个账户余额的和应该不变）。 2、实现能够说，一致性是事务谋求的最终目标：后面提到的原子性、持久性和隔离性，都是为了保障数据库状态的一致性。此外，除了数据库层面的保障，一致性的实现也须要利用层面进行保障，例如如果转账操作只扣除转账者的余额，而没有减少接收者的余额，无论数据库实现的如许完满，也无奈保障状态的统一。 参考资料： https://cloud.tencent.com/dev...https://xiaolincoding.com/mys...

1. mysql建表test;2. 装置logstash（跟es版本统一）# 下载wget https://repo.huaweicloud.com/logstash/7.14.2/logstash-7.14.2-linux-x86_64.tar.gz# 解压tar -zxvf logstash-7.14.2-linux-x86_64.tar.gz# 须要mysql-connector-java-5.1.40.jar，轻易放到比方目录# /var/lib/hadoop-hdfs/logstash-7.14.2/lib/mysql-connector-java-5.1.40.jar3. 新建es索引testcurl -u elastic:changeme -X PUT http://192.168.20.130:9200/test -H 'Content-Type: application/json' -d'{ "settings" : { "number_of_shards" : 1, "number_of_replicas" : 1 }, "mappings" : { "properties": { "id": { "type" : "long" }, "type": { "type": "keyword" }, "keyword_1": { "type": "text", "analyzer" : "ik_smart" }, "keyword_2": { "type": "text", "analyzer" : "ik_smart" }, "keyword_3": { "type": "text", "analyzer" : "ik_smart" }, "data": { "type": "keyword" }, "created_at": { "type": "date", "format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd" }, "updated_at": { "type": "date", "format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd" } } }}'4. 编辑配置文件，vim ~/script/logstash/logstash_mysql2es.confinput { stdin{ } jdbc{ # 连贯的数据库地址和数据库，指定编码格局，禁用ssl协定，设定主动重连 # 此处10.112.103.2为MySQL所在IP地址，也是elastic search所在IP地址 jdbc_connection_string => "jdbc:mysql://192.168.13.28:3306/test?characterEncoding=UTF-8&useSSL=FALSE&autoReconnect=true" #数据库用户名 jdbc_user => "root" # 数据库用户名对应的明码 jdbc_password => "root" # jar包寄存地位 jdbc_driver_library => "/var/lib/hadoop-hdfs/logstash-7.14.2/lib/mysql-connector-java-5.1.40.jar" jdbc_driver_class => "com.mysql.jdbc.Driver" jdbc_default_timezone => "Asia/Shanghai" jdbc_paging_enabled => "true" jdbc_page_size => "320000" lowercase_column_names => false statement => "select id, type, tags, title from test" }}filter { # 移除无关的字段 mutate { remove_field => ["@version", "@timestamp"] }}output { elasticsearch { hosts => ["http://192.168.20.130:9200"] user => "elastic" password => "changeme" index => "test" document_type => "_doc" # 将字段type和id作为文档id document_id => "%{type}_%{id}" } stdout { codec => json_lines }}重要配置参数阐明： ...

MySQL次要是应用 MVCC（多版本并发管制）实现的可反复读。MVCC 实现的原理是，在数据的每行都会存在两个暗藏列，别离是创立工夫（版本）和删除工夫（版本），每次更新的时候都会加 1，事务启动时，读取数据会判断以后行的版本号是否小于等于事务启动时的版本号，版本号小于等于就可见，如果版本号大于就不可见，从而实现的可反复读。

大家好 这里是 《StarRocks 7 月社区动静》，SR 小编为你会集了过来一个月内社区里精彩的人、事、物。社区不止于代码，欢送你的踊跃参加！ 接下来，一起来看看 StarRocks 7 月里有哪些值得你关注的停顿吧！ 国内社区活跃度 Top 3从泛滥开源活跃度排行榜上都能够看到 StarRocks 在排行榜上名落孙山，社区能有如此问题要感激所有为 StarRocks 添砖加瓦的小伙伴！ （中国开源我的项目活跃度排行，起源：https://open-leaderboard.x-la...） （开源数据库 PR 数排行 & PR 合并速度，起源 OSSInsight） 想晓得你能如何退出社区吗？点击这里看攻略！ StarRocks 社区架构出炉，等你通关降级！ 产品动静2.3.0 最新版StarRocks 近期公布了 2.3 版本，外围更新有： 主键模型反对残缺的 DELETE WHERE 语句，异步执行 CTAS，资源组的大查问进攻，资源组的监控，JDBC 表面，数据目录 Catalog，集群部署与管理工具 StarGo 等。 如果你想理解更多对于新性能的讲解，请点 StarRocks 2.3 新版本个性介绍 Release note: StarRocks-2.3.0 Release Notes其余版本StarRocks v2.2.3StarRocks v2.1.11 （稳定版）StarRocks v2.0.8 （LTS, long-term support) 举荐浏览技术干货京东物流 × StarRocks : 打造服务剖析一体化平台 Udata松果出行 x StarRocks：实时数仓新范式的实际之路腾讯游戏 ：咱们如何基于 StarRocks 构建云原生数仓 ...

作者：杨奇龙 网名“北在北方”，资深 DBA，次要负责数据库架构设计和运维平台开发工作，善于数据库性能调优、故障诊断。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 一、前言作为 MySQL DBA ，置信大家都经验过在复制模式下，如果没有主键，遇到 load data ，大事务，ddl 等有大量表数据行扫描的行为时，会带来重大的主从提早，给数据库稳定性和数据一致性带来隐患。 MySQL 8.0.30 已于近日 GA ，新版本为咱们提供了一个令人惊喜的个性 -（Generated Invisible Primary Keys）简称 GIPK 。一句详情就是: 当开启GIPK模式后，MySQL 会在没有显示定义主键的InnoDB表上主动生成不可见的主键。 对于曾经应用云RDS的敌人，可能很早就享受到云 RDS MySQL 提供的隐式主键个性。然而对于自建数据库的企业，GIPK 仍然是一个比拟期待个性，（当然有和用起来是两码事！）长话短说，本文基于理论测试案例来学校 如何应用 GIPK 。 二、实际出真知2.1 开启GIPK 由参数sql_generate_invisible_primary_key 管制，默认敞开，示意禁用，如果须要应用该个性，则需显式开启。 master [localhost:22031]> show variables like 'sql_generate_invisible_primary_key';+------------------------------------+-------+| Variable_name | Value |+------------------------------------+-------+| sql_generate_invisible_primary_key | OFF |+------------------------------------+-------+1 row in set (0.00 sec)master [localhost:22031]> set sql_generate_invisible_primary_key=on;Query OK, 0 rows affected (0.00 sec)master [localhost:22031]> show variables like 'sql_generate_invisible_primary_key';+------------------------------------+-------+| Variable_name | Value |+------------------------------------+-------+| sql_generate_invisible_primary_key | ON |+------------------------------------+-------+1 row in set (0.00 sec)2.2 测试咱们别离在敞开和开启该个性下创立两个无主键表: ...

作者：刘开洋 爱可生交付服务团队北京 DBA，对数据库及周边技术有浓重的学习趣味，喜爱看书，谋求技术。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 在很多疑难问题的排查中，小编最近又遇到了一个 select 语句执行就会导致 MySQL 解体的问题，特来分享给大家。 先看下报错一般来讲，只有数据库崩了，那么谬误日志肯定会留下线索的，先来看下具体的报错： 06:08:23 UTC - mysqld got signal 11 ;Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.Thread pointer: 0x7f55ac0008c0Attempting backtrace. You can use the following information to find outwhere mysqld died. If you see no messages after this, something wentterribly wrong...stack_bottom = 7f56f4074d80 thread_stack 0x46000/usr/local/mysql/bin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x2e) [0x1f1b71e]/usr/local/mysql/bin/mysqld(handle_fatal_signal+0x323) [0xfcfac3]/lib64/libpthread.so.0(+0xf630) [0x7f5c28c85630]/usr/local/mysql/bin/mysqld(actual_key_parts(KEY const*)+0xa) [0xef55ca]/usr/local/mysql/bin/mysqld(calculate_key_len(TABLE*, unsigned int, unsigned long)+0x28) [0x10da428]/usr/local/mysql/bin/mysqld(handler::ha_index_read_map(unsigned char*, unsigned char const*, unsigned long, ha_rkey_function)+0x261) [0x10dac51]/usr/local/mysql/bin/mysqld(check_unique_constraint(TABLE*)+0xa3) [0xe620e3]/usr/local/mysql/bin/mysqld(do_sj_dups_weedout(THD*, SJ_TMP_TABLE*)+0x111) [0xe62361]/usr/local/mysql/bin/mysqld(WeedoutIterator::Read()+0xa9) [0x1084cd9]/usr/local/mysql/bin/mysqld(MaterializeIterator::MaterializeQueryBlock(MaterializeIterator::QueryBlock const&, unsigned long long*)+0x17c) [0x10898bc]/usr/local/mysql/bin/mysqld(MaterializeIterator::Init()+0x1e1) [0x108a021]/usr/local/mysql/bin/mysqld(SELECT_LEX_UNIT::ExecuteIteratorQuery(THD*)+0x251) [0xf5d241]/usr/local/mysql/bin/mysqld(SELECT_LEX_UNIT::execute(THD*)+0xf9) [0xf5f3f9]/usr/local/mysql/bin/mysqld(Sql_cmd_dml::execute_inner(THD*)+0x20b) [0xeedf8b]/usr/local/mysql/bin/mysqld(Sql_cmd_dml::execute(THD*)+0x3e8) [0xef7418]/usr/local/mysql/bin/mysqld(mysql_execute_command(THD*, bool)+0x39c9) [0xeab3a9]/usr/local/mysql/bin/mysqld(mysql_parse(THD*, Parser_state*)+0x31c) [0xead0cc]/usr/local/mysql/bin/mysqld(dispatch_command(THD*, COM_DATA const*, enum_server_command)+0x156b) [0xeaeb6b]/usr/local/mysql/bin/mysqld(do_command(THD*)+0x174) [0xeb0104]/usr/local/mysql/bin/mysqld() [0xfc1a08]/usr/local/mysql/bin/mysqld() [0x23ffdec]/lib64/libpthread.so.0(+0x7ea5) [0x7f5c28c7dea5]/lib64/libc.so.6(clone+0x6d) [0x7f5c26db9b0d] Trying to get some variables.Some pointers may be invalid and cause the dump to abort.Query (7f55ac0ca298): SELECT DISTINCT T.CUST_NO FROM testDB.TABLE_TRANSACTION T WHERE EXISTS (SELECT 1 FROM testDB.Table1 T1 WHERE T.CUST_NO = T1.CUST_NO ) AND T.AGENT_CERT_NO IS NOT NULLConnection ID (thread ID): 65Status: NOT_KILLED从上述谬误日志的输入中能够找到较为显著的几处信息： ...

作者：吴金玲 爱可生 dble 我的项目团队成员，次要负责 dble 相干的日常测试工作，善于对 dble 中呈现的问题进行排查。酷爱测试工作，余生欲将测试工作进行到底。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 本文谨献给 dble 的新粉。在首次应用 dble 的时候，老手们常常会遭逢 dble 启动失败的状况，而且启动失败个别都是因为配置不正确导致的。家喻户晓，dble 启动失败了，咱们能够去 wrapper.log 外面查找启动失败的起因，并且可喜的是个别都能从 wrapper.log 里很直观的找到启动失败的起因。但多数启动失败的起因就不是那么直观，要想疾速的定位及解决问题，那就须要咱们对dble启动时具体都做了些什么有所理解。本文以 3.22.01.0 版本为例，简略介绍一下 dble 在启动的时候是如何对配置文件的正确性进行校验的。 具体如何配置请参考 dble 的官网文档：https://actiontech.github.io/... 。 一、首先让咱们简略理解一下 dble 都有哪些配置文件，以及他们的次要作用是什么下载 3.22.01.0 版本的装置压缩包，解压后进入 dble 装置目录的根目录，外面有个 conf 的配置文件目录（罕用的配置文件外面都有模板文件），从配置文件目录可知，dble 次要分为4种类型的配置文件（.cnf、.xml、.properties、.txt），每个配置文件的次要作用如下表： 文件名次要作用留神点参考链接cluster.cnf集群参数配置文件批改此文件须要进行多个dble实例，从新初始化集群元数据，而后再一一启动dblehttps://actiontech.github.io/...bootstrap.cnfdble实例启动时加载的零碎参数配置文件文件分为两局部，第一部分为JVM启动参数，第二局部为dble零碎参数https://actiontech.github.io/...bootstrap.dynamic.cnf个别为能够通过治理命令热失效的零碎参数当dble重启时会替换bootstrap.cnf中对应的值来失效配置https://github.com/actiontech...user.xml登录用户配置文件（dble次要分四种用户）次要留神sql权限和ip白名单的配置https://actiontech.github.io/...db.xml后端数据库和组的配置文件为了dble能失常工作，后端MySQL用户需开启特定的权限https://actiontech.github.io/...sharding.xml虚构库、表、算法的配置文件留神全局序列的配置办法https://actiontech.github.io/...sequence_conf.propertie分布式offset-step形式的全局序列配置文件联合cluster.cnf配置，sequenceHandlerType=4https://actiontech.github.io/...sequence_db_conf.propertiesMySQL-offset-step形式的全局序列配置文件联合cluster.cnf配置，sequenceHandlerType=1https://actiontech.github.io/....txt文件不同分片算法对应的配置文件罕用，须要时可参照文档配置https://actiontech.github.io/...log4j2.xml日志归档规定及日志记录级别配置当出错时可将日志级别调整为debug来定位具体的错误信息https://actiontech.github.io/...cacheservice.propertiesdble的cache的总配置文件不罕用，须要时可自行参照文档配置https://actiontech.github.io/...ehcache.xmdble的缓存实现配置文件不罕用，须要时可自行参照文档配置https://actiontech.github.io/...$DBLE_HOME/lib目录下jar包自定义拆分算法文件不罕用，须要时可自行参照文档配置https://actiontech.github.io/...dble_alert.properties自定义告警配置文件不罕用，须要时可自行参照文档配置https://actiontech.github.io/...二、上面通过列举几个新粉常常遇到的 dble 启动失败的例子，来阐明 dble 在加载配置文件时做了哪些检测1.首先以以下 boostrap.cnf 配置为例启动 dble (其余配置文件请按需配置，此处省略)： 进入 dble 装置的根目录，执行 dble 启动命令 bin/dble start ，而后执行 bin/dble status 查看 dble 的状态，发现启动失败了： 进入 wrapper.log 中查看，发现报错如下： 从日志中能够看出，报错是因为22端口被占用。这是因为 dble 在启动的时候会初始化一个虚拟机，从 bootstrap.cnf 读取 JVM 参数。dble 启动过程中会占用三个端口：业务端口（默认8066），治理端口（默认9066），jvm 对外提供 jmx 服务端口，所以配置的时候这三个端口不能雷同，且不能被其余程序占用。具体参考：https://actiontech.github.io/... 。所以将端口改为未被占用的端口即可启动胜利。 ...

根底篇1、装置Mysql在windows上装置Mysqlzip包解压装置1.下载mysql压缩包 下载地址：https://dev.mysql.com/downloa... 2.解压下载的zip包 3.在解压后的根目录新建my.ini文件，批改文件内容 留神：目录名不要以t、s、n结尾，会被默认辨认为\t、\s、\n等，导致my.ini文件报错 文件内容： [mysqld]#设置时区为东八区，此项设置后，在连贯MySQL的时候能够不必每次都手动设置时区default-time-zone = '+8:00'# 设置3306端口port=3306# 设置mysql的装置目录，记得切换成本人的门路basedir=D:\Learn\Tools\mysql-8.0.29-winx64# 设置mysql数据库的数据的寄存目录datadir=D:\Learn\Tools\mysql-8.0.29-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=utf8 4.以管理员身份进入mysql的bin目录 形式一：win+r输出cmd，而后Ctrl+Shift+Enter即可用管理员权限运行。 形式二： 5.执行MySQL初始化命令 mysqld --initialize6.执行MySQL装置命令 mysqld --install mysql87.查看MySQL默认的明码 关上【mysql装置目录】\data*.err文件，找到 A temporary password is generated for root@localhost:【默认明码】 8.批改明码 应用默认明码登录mysql mysql -uroot -p请输出明码：【默认明码】执行 use mysql;ALTER USER 'root'@'localhost' IDENTIFIED BY '新密码';在Linux上装置Mysqlyum装置1.查看是否曾经装置了mysql [root@localhost ~]# rpm -qa|grep mysql #无输入阐明没有装置2.找到对应linux的版本 下载地址：https://dev.mysql.com/downloa... 3.装置mysql源 #下载查看操作系统版本[root@localhost ~] cat /etc/redhat-releaseCentOS Linux release 7.8.2003 (Core)#下载和装置mysql源[root@localhost ~] wget https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm#如果显示wget未找到命令，则须要先装置wget[root@localhost ~] yum -y install wget#装置mysql源[root@localhost ~]# sudo rpm -Uvh mysql80-community-release-el7-3.noarch.rpm查看是否装置胜利：执行胜利后会在/etc/yum.repos.d/目录下生成两个repo文件mysql-community.repo及 mysql-community-source.repo ...

锁机制的定义：计算机协调多个过程或线程并发拜访某一资源的机制。 加锁尽管能防止事务的抵触，然而加锁是耗费资源的，锁的各种操作，包含取得锁、检测锁是否已解除、开释锁等 ，都会减少零碎的开销。 MySQL的行锁和表锁表锁有读锁（共享锁）和写锁（独占锁），存储默认引擎为MyISAM，当一个线程取得对一个表的写锁后，只有持有锁线程能够对表进行更新操作。其余线程的读、写操作都会期待，直到锁被开释为止。 特点： 对整张表加锁开销小加锁快无死锁锁粒度大，产生锁抵触概率大，并发性低MyISAM的读写锁调度是写优先，这也是MyISAM不适宜做写为主表的引擎，因为写锁当前，其它线程不能做任何操作，大量的更新使查问很难失去锁，从而造成永远阻塞。 行锁默认引擎：InnoDB，留神：InnoDB反对事务，MyISAM不反对事务。 读锁、写锁、动向共享锁、动向排他锁 动向共享锁（IS）一个事务给一个数据行加共享锁时，必须先取得表的IS锁 动向排它锁（IX）一个事务给一个数据行加排他锁时，必须先取得该表的IX锁 特点： 对一行数据加锁开销大加锁慢会呈现死锁锁粒度小，产生锁抵触概率最低，并发性高事务并发的问题： 更新失落解决：让事务变成串行操作，而不是并发的操作，即对每个事务开始---对读取记录加排他锁脏读解决：隔离级别为Read uncommitted不可重读解决：应用Next-Key Lock算法来防止幻读解决：间隙锁（Gap Lock）页锁开销、加锁工夫和锁粒度介于表锁和行锁之间，会呈现死锁，并发解决能力个别（此锁不做多介绍） 隐式上锁select //表锁上读锁，行锁不上锁 insert、update、delete //上写锁 显式上锁lock table tableName read;//读锁lock table tableName write;//写锁 select * from tableName lock in share mode;//读锁select * from tableName for update;//写锁 死锁产生条件互斥条件：一个资源每次只能被一个过程应用申请与放弃条件：一个过程因申请资源而阻塞时，对已取得的资源放弃不放不剥夺条件：过程已取得的资源，在没有应用完之前，不能强行剥夺循环期待条件：多个过程之间造成的一种相互循环期待的资源的关系如何防止死锁（1）死锁预防：通过确保死锁的一个必要条件不会满足，保障不会产生死锁。 （2）死锁检测：设置检测算法。 （3）死锁防止：银行家算法分配资源。如果一个过程的申请会导致死锁，则不启动该过程。 （4）死锁解除：资源剥夺法、过程撤销法。

MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发，属于 Oracle 旗下产品。MySQL 是最风行的关系型数据库管理系统之一，在 WEB 利用方面，MySQL是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件之一。 上面应用centos7装置mysql 1、首先去官网下载安装包http://mirrors.sohu.com/mysql/ 2、yum装置环境 yum -y install \ncurses \ncurses-devel \bison \cmake3、添加程序用户useradd -s /sbin/nologin mysql 4、解压安装包tar xf mysql-boost-5.7.20.tar.gz 5、cd到mysql的配置目录中，而后编译装置cd mysql-5.7.20/ cmake \-DCMAKE_INSTALL_PREFIX=/usr/local/mysql \-DMYSQL_UNIX_ADDR=/usr/local/mysql/mysql.sock \-DSYSCONFDIR=/etc \-DSYSTEMD_PID_DIR=/usr/local/mysql \-DDEFAULT_CHARSET=utf8 \-DDEFAULT_COLLATION=utf8_general_ci \-DWITH_INNOBASE_STORAGE_ENGINE=1 \-DWITH_ARCHIVE_STORAGE_ENGINE=1 \-DWITH_BLACKHOLE_STORAGE_ENGINE=1 \-DWITH_PERFSCHEMA_STORAGE_ENGINE=1 \-DMYSQL_DATADIR=/usr/local/mysql/data \-DWITH_BOOST=boost \-DWITH_SYSTEMD=1 make && make install 这个过程十分十分慢，请急躁期待（取决于你的电脑性能） 6、加权限 chown -R mysql.mysql /usr/local/mysql/ 7、批改配置文件vi /etc/my.cnf \在开端增加 [client]port = 3306default-character-set=utf8socket = /usr/local/mysql/mysql.sock [mysql]port = 3306default-character-set=utf8socket = /usr/local/mysql/mysql.sock [mysqld]user = mysqlbasedir = /usr/local/mysqldatadir = /usr/local/mysql/dataport = 3306character_set_server=utf8pid-file = /usr/local/mysql/mysqld.pidsocket = /usr/local/mysql/mysql.sockserver-id = 1 ...

删除局部数据后，须要批改数据库中自增ID起始值。alter table users AUTO_INCREMENT=10000;

Think of a lockable object as a blackboard (lockable) in a class room containing a teacher (writer) and many students (readers). While a teacher is writing something (exclusive lock) on the board: Nobody can read it, because it's still being written, and she's blocking your view => If an object is exclusively locked, shared locks cannot be obtained. Other teachers won't come up and start writing either, or the board becomes unreadable, and confuses students => If an object is exclusively locked, other exclusive locks cannot be obtained. ...

1 背景 作为在后端圈开车的多年老司机，是不是常常听到过，“mysql 单表最好不要超过2000w”,“单表超过2000w 就要思考数据迁徙了”，“你这个表数据都马上要到2000w 了，难怪查问速度慢” 这些名言民语就和 “群里只探讨技术，不开车，开车速度不要超过120码，否则主动踢群”，只听过，没试过，哈哈。 上面咱们就把车速踩到底，干到180码试试……. 2 试验 试验一把看看…建一张表 插入一条数据 利用mysql伪列rownum 设置伪列起始点为1 运行上面的sql，间断执行20次，就是2的20次方约等于100w 的数据；执行23次就是2的23次方约等于800w ,如此上来即可实现千万测试数据的插入，如果不想翻倍翻倍的减少数据，而是想大量，大量的减少，有个技巧，就是在SQL 的前面减少where 条件，如id>某一个值去管制减少的数据量即可。 此处须要留神的是，兴许你在执行到近800w 或者1000w 数据的时候，会报错：The total number of locks exceeds the lock table size，这是因为你的长期表内存设置的不够大，只须要扩充一下设置参数即可。 先来看一组测试数据，这组数据是在mysql8.0 的版本，并且是在我本机上，因为本机还跑着idea ,浏览器等各种工具，所以并不是机器配置就是用于数据库配置，所以测试数据只限于参考。 看到这组数据仿佛如同真的和题目对应，当数据达到2000w 当前，查问时长急剧回升；难道这就是铁律吗？那上面咱们就来看看这个倡议值2kw 是怎么来的？ 3 单表数量限度 首先咱们先想想数据库单表行数最大多大？ 看看下面的建表sql，id 是主键，自身就是惟一的，也就是说主键的大小能够限度表的下限，如果主键申明int 大小，也就是32位，那么反对 2^32-1 ~~21亿；如果是bigint，那就是2^62-1 ？（36893488147419103232），难以想象这个的多大了，个别还没有到这个限度之前，可能数据库曾经爆满了！！ 有人统计过，如果建表的时候，自增字段抉择无符号的bigint ,那么自增长最大值是18446744073709551615，依照一秒新增一条记录的速度，大概什么时候能用完？ 4 表空间 上面咱们再来看看索引的构造，对了，咱们上面讲内容都是基于Innodb 引擎的，大家都晓得Innodb 的索引外部用的是B+ 树 这张表数据，在硬盘上存储也是相似如此的，它理论是放在一个叫person.ibd （innodb data）的文件中，也叫做表空间;尽管数据表中，他们看起来是一条连着一条，然而实际上在文件中它被分成很多小份的数据页，而且每一份都是16K。大略就像上面这样，当然这只是咱们形象进去的，在表空间中还有段、区、组等很多概念，然而咱们须要跳出来看。 5 页的数据结构 因为每个页只有16K的大小,然而如果数据很多，那一页必定就放不下这些数据，那数据必定就会被分到其余的页中，所以为了把这些页关联起来，必定就会有记录前后页地址，不便找到对应页；同时每页都是惟一的，那就会须要有一个惟一标记来标记页，就是页号；页中会记录数据所以会存在读写操作，读写操作会存在中断或者其余异样导致数据不全等，那就会须要有校验机制，所以外面还有会校验码，而读操作最重要的就是效率问题，如果依照记录一个个进行遍历，那必定是很吃力的，所以这外面还会为数据生成对应的页目录（Page Directory）;所以理论页的内部结构像是上面这样的。 从图中能够看出，一个InnoDB数据页的存储空间大抵被划分成了7个局部，有的局部占用的字节数是确定的，有的局部占用的字节数是不确定的。 ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 之前写过应用 MySQL Shell 的 DBA 组件来搭建、运维 MySQL InnoDB Cluster 。明天咱们来持续对 DBA 组件进行延长介绍，探讨如何用它定制化部署 MySQL 实例。 一、如何部署多个不同版本的 MySQL 实例：默认应用 DBA 组件部署多个实例时，应用零碎内置的 MySQL 版本，也就是在环境变量$PATH蕴含的门路里搜查 mysqld 来确认具体的实例版本。比方我机器上，默认 MySQL 版本为 8.0 ，所以间接部署后的实例版本也是8.0。 root@ytt-normal:~# mysqlsh --py MySQL Shell 8.0.29 ...MySQL Py > dba.deploy_sandbox_instance(3350);A new MySQL sandbox instance will be created on this host in /root/mysql-sandboxes/3350 ... Instance localhost:3350 successfully deployed and started.Use shell.connect('root@localhost:3350') to connect to the instance.例如以上端口为3350的实例在部署实现后，新建一个连贯，胜利后客户端就会收到具体版本：Server version: 8.0.29 MySQL Community Server - GPL。 ...

MySQL凭借开源、收费、低门槛、稳固等劣势，成为了以后最风行的关系型数据库之一。从1998年发行第一版以来，通过一直地更新迭代，MySQL被越来越多的公司应用，未然成为当下潮流。 为了帮忙大家更好地学习、运维MySQL，本文整顿了墨天轮社区上一些优质资源，涵盖MySQL软件装置、经典教程、具体学习笔记以及巡检手册、运维小妙招，还有实在场景的故障排查案例……适宜技术小白和各种运维/开发人员们学习交换。（须要的敌人能够点击下方文字查阅下载） 学习教程与笔记此局部内容会集了MySQL简介与经典教程，大家能够查阅理解数据库的基本操作与个性，此外也有专家视频带你梳理MySQL体系。此外也蕴含MySQL要害学习笔记，图文并茂，数据类型、基本操作、到语法、查问、索引……图文搭配代码明悉。 图解与教程MySQL经典教程 MySQL装置图解 MySQL性能优化教程 最须要把握的SQL教程 MySQL装置部署手册 Linux装置MySQL数据库 零碎学习笔记MySQL笔记-根底版 MySQL具体笔记 MySQL高级常识笔记 MySQL 增强笔记 数据库笔记与总结-苏青羽 日常运维技巧此局部为运维技巧相干资源合集，通过案例加持，帮忙大家剖析理论问题并把握解决问题的思路，倡议珍藏！ 文档手册MySQL 主从装置部署标准 MySQL数据库巡检手册 MySQL中的索引探索 从Oracle的SQL优化到MySQL的SQL优化-巩飞 MySQL的性能-徐轶韬 MySQL性能优化实战 MySQL性能优化教程 MySQL DBA运维笔记 MySQL InnoDB Cluster 高可用 MYSQL性能参数调优 MySQL+MGR 单主模式和多主模式的集群环境 MySQL备份复原工具及实用场景 MySQL 数据库最常见的 6 类故障的排除办法 MySQL问题剖析思路思维导图-崔虎龙（高清可放大） 视频实操（含PDF）MySQL的查问与优化-杨明翰视频：https://www.modb.pro/video/3542 文档：https://www.modb.pro/doc/21032MySQL故障诊断罕用办法手册-黄超视频：https://www.modb.pro/video/4948 文档：https://www.modb.pro/doc/42771MySQL罕用运维工具小妙招集锦-崔虎龙视频：https://www.modb.pro/video/4646 文档：https://www.modb.pro/doc/38657案例加持：一小时把握这套MySQL故障排查思路办法-崔虎龙视频：https://www.modb.pro/video/1499 文档：https://www.modb.pro/doc/4175实战案例腾讯游戏MySQL备份和复原优化实际-崔国斌 MySQL高可用架构演进及实际-叶金荣 基于网易互联网业务的MySQL内核优化之路-温正湖 AnalyticDB for MySQL PB级云数仓核心技术和场景解析-南仙 阿里云RDS For MySQL的个性Binlog In Redo-宋利兵 深刻内核源码，方能技术可控-基于MYSQL内核研发的所见与所悟-彭立勋 数据安全重于泰山——TencentDB for MySQL数据安全实际-杨杰 精品书籍举荐最初给大家举荐几本MySQL经典技术书籍，帮忙大家更好地学习、把握MySQL。 ● 《MySQL必知必会》 作者：Ben Forta 出版社：人民邮电出版社 本书紧贴实战须要，从数据检索开始逐渐深刻如联结的应用、子查问、正则表达式和基于全文本的搜寻、存储过程、游标等内容。同时采取了代码实例解说的形式，通过输出、输入和剖析谆谆告诫，疏导读者思考，以此强化知识点。内容叙述清晰、重点突出，适宜MySQL入门老手。 ● 《高性能MySQL（第3版）》 作者：Baron·Schwartz等 出版社：电子工业出版社 本书为MySQL畛域经典书籍，由Oracle公司MySQL外围开发团队技术骨干精心写就，蕴含存储引擎、分区数据库和视图等新个性以及高可用、集群、优化、备份和复原的策略等知识点。每一章都是绝对独立的主题，读者能够有选择性地独自浏览。 本书岂但适宜数据库管理员（DBA）浏览，也适宜开发人员参考学习。 ...

信息安全的外围是数据安全，而数据一旦泄露、失落、被盗取可能会引发难以想象的劫难，所以对数据的平安防护、对危险的预判防备就变得愈发重要。 近期数据安全事件频发，有许多敌人心愿咱们整顿出墨天轮社区上受欢迎的数据库安全相干材料来参考、学习，本文便对网站上受欢迎的Oracle、MySQL、PostgreSQL以及国产数据库等相干数据库、数据安全的学习材料进行整顿，蕴含平安危险认知判断、平安防护领导手册与实战操作案例等。 首先给大家举荐一份经典的《数据库运维平安治理标准》文档，云和恩墨出品，文中蕴含了数据库安全理念、技术抉择、布局流程等运维过程中可能波及的多个环节上的注意事项与教训，置信大家能从中有所播种。数据库安全领导手册&实战案例OracleOracle 数据库安全培训 Oracle 数据库安全配置标准 Oracle 数据库安全标准倡议 Oracle 数据库安全配置基线加固操作指导书 Oracle 数据库防火墙应用教训及数据库安全治理的思考-刘佳 后数字时代的数据库安全-王文娟 中兴通讯 某医院数据库安全降级实施方案-云和恩墨 Oracle 数据库安全加固计划 Oracle 多场景下比特币勒索的解密与复原实战) Oracle 账号平安和权限管制 Oracle 数据拜访平安最佳实际 《数据安全警示录》思维导图 MySQL、PostgreSQL开源数据库（MySQL）平安治理-崔虎龙 如何确保您的 MySQL 数据库安全 MySQL 数据库安全配置计划 MySQL 平安配置详解 MySQL 8.0 中平安增强 MySQL 平安优化 MySQL 的平安模式 PostgreSQL 最佳平安配置领导手册 PostgreSQL 存储平安和存储性能布局 SSL平安传输加密认证晋升PG安全等级 PostgreSQL 平安加固 PostgreSQL 用户明码安全策略治理 国产数据库及其他数据库[openGauss 数据库安全-轻松上手openGauss[DBA篇]](https://www.modb.pro/doc/4612...) openGauss 数据库安全个性和配置-田文罡 openGauss 数据库最大安全性架构-章明星 GBase 8s安全性综述 达梦8平安治理 优炫数据库 UXDB 平安版本用户手册 腾讯云原生数据安全解决方案-姬生利 TiDB Cloud 云原生平安架构实际-王鹏飞 TigerGraph图数据库安全性与管制-Dadong Wang Greenplum 备份、平安与高可用 《2022年7月中国数据库行业剖析报告-居安思危，平安后行》 ...

第一章：DDL和DML语言1.DDL：DDL：DDL是一种数据定义数据结构和批改的语言，也就是说查问表构造，他的全称为Data Definition Language 2.DDL-数据库操作1.DDL查问-- 查问所有数据库SHOW DATABASES -- 查问以后数据库的所有表SHOW DATABASES 数据库名-- 例：SHOW DATABASES jzlg2 .DDL创立-- 创立数据库CREATE DATABASE 数据库-- 例：CREATE DATABASE KJZZ3.DDL删除删除数据库DAOP DATA 数据库名；-- 例DAOP DATA hhhh;4.DDL 应用数据库-- 应用之前创立的数据库use 数据库3.DDL-表操作-查问(查问表构造)1.DDL查问-- 查问以后数据库的表SHOW TABLES;-- 例：show tables jzlg2..DDL查问表构造-- 查问表构造DESC 表名-- 例DESC user3.查问指定表的建表语句-- 查问指定表的建表语句SHOW CREATE TABLE 表名-- 例SHOW CREATE TABLE user4.DDL-表操作- 创立1.DDL表创立CREATE TABLE 表名(子段1 数据类型(COMMENT 字段1 正文)，字段2 数据类型(COMMENT 字段2 正文)，字段3 数据类型(COMMENT 字段3 正文)字段4 数据类型(COMMENT 字段4 正文)....)(COMMENT 表正文)-- 例CREATE TABLE user(id int(COMMENT 用户id)，name varchar(10)(COMMENT 用户名字)，gender varchar(10)(COMMENT 用户性别)avg data(COMMENT 年龄)....)(COMMENT 用户表)5.DDL-表操作-批改1.DDL增加字段-- 增加字段ALTER TABLE 表名 字段名 数据类型（长度） comment 正文 -- 案例 为user表增加一个新的昵称为nickname和数据类型为varchar(20)ALTER TABLE USER nickname varchar(20)2.DDL批改字段-- 批改数据类型ALTER TABLE 表名 字段名 新数据类型(长度) comment 正文-- 例:ALTER TABLE user nickname char(10) -- 批改字段名和字段类型ALTER TABLE 表名 CHANGE 旧字段名 新字段名 类型(长度) comment 正文-- 例ALTER TABLE user CHANGE nickname name varchar(20) 3.DDL删除字段-- 删除字段ALTER TABLE 表名 DROP 字段名-- 例ALTER TABLE user DROP name4.DDL批改表名-- 批改表名ALTER TABLE 表名 RENAME TO 新表名-- 例ALTER TABLE user RENAME TO user15.DDL删除表-- 删除表DROP TABLE [IF EXISTS] 表名例DRIP TABLE [IF EXISTS] user-- 删除指定表， 并从新创立表 TRUNCATE TABLE user`2.DML:DML:是用来对数据库中的表中的数据进行增删改查的，全称是“Data Manipulation Language" ...

移除权限REVOKE命令 只保留SELECT权限命令阐明： REVOKE [权限列表,] ON {库名}.{表明} FROM '{用户名}'@'{host}'REVOKE INSERT,UPDATE,DELETE,CREATE, DROP, REFERENCES, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON product.* FROM 'guest'@'localhost'刷新权限flush privileges; # 查看权限列表SHOW GRANTS FOR 'woo_product'@'%';GRANT USAGE ON *.* TO 'guest'@'%'GRANT SELECT ON `product`.* TO 'guest'@'%'

配置主服务器更改配置文件，首先查看你的主服务器上的my.cnf文件中是否曾经在[mysqld]模块下配置了log-bin和server-id[mysqld]log-bin=mysql-binserver-id=1留神下面的log-bin和server-id的值都是能够改为其余值的，如果没有下面的配置，首先敞开mysql服务器，而后增加下来，接着重启服务器 配置主从同步账户创立一个用户名为rep，明码为123456的账户，该账户能够被192.168.253网段下的所有ip地址应用，且该账户只能进行主从同步mysql > grant replication slave on *.* to 'rep'@'%' identified by '123456';mysql> FLUSH PRIVILEGES;获取二进制日志的信息并导出数据库：首先登陆数据库，而后刷新所有的表，同时给数据库加上一把锁，阻止对数据库进行任何的写操作mysql > flush tables with read lock;而后执行上面的语句获取二进制日志的信息mysql > show master status; mysql> show master status;+------------------+-----------+--------------+------------------+-------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |+------------------+-----------+--------------+------------------+-------------------+| mysql-bin.000124 | 159619068 | | | |+------------------+-----------+--------------+------------------+-------------------+1 row in set (0.04 sec)File的值是以后应用的二进制日志的文件名，Position是该日志外面的地位信息（不须要纠结这个到底代表什么），记住这两个值，会在上面配置从服务器时用到。 留神：如果之前的服务器并没有配置应用二进制日志，那么应用下面的sql语句会显示空，在锁表之后，再导出数据库里的数据（如果数据库里没有数据，能够疏忽这一步） mysqldump -uroot -p'123456' -S /tmp/mysql.sock --all-databases > /data/backup/mysql_bak.$(date +%F).sql# 如果数据量很大，能够在导出时就压缩为原来的大略三分之一mysqldump -uroot -p'123456' -S /tmp/mysql.sock --all-databases | gzip > /data/backup/mysql_bak.$(date +%F).sql.gz这时能够对数据库解锁，复原对主数据库的操作mysql > unlock tables; ...

两种解决办法：应用grep 'temporary password' /var/log/mysqld.log命令找回装置时的初始密码即可；批改配置文件“my.cnf”，免密登录mysql服务器，应用update命令设置新密码即可。办法一、找回装置时的初始密码：间接执行以下命令grep 'temporary password' /var/log/mysqld.log [root@www log]# grep 'temporary password' /var/log/mysqld.log2022-05-14T10:42:20.745694Z 1 [Note] A temporary password is generated for root@localhost: w?JBNq?,;1gaw?JBNq?,;1ga 就是root帐号的初始密码 办法二、配置my.cnf文件，免密登录mysql服务器，应用update命令设置新密码批改配置文件，免密登录mysql服务器 # windows下批改的是my.inivim /etc/my.cnf在[mysqld]前面任意一行增加 explicit_defaults_for_timestamp=trueskip-grant-tables保留并退出 重启MySQL: systemctl restart mysqld 间接登录MySQLmysql -uroot 2、批改明码 use mysqlupdate user set authentication_string=password('123123') where user='root';