Mysql

前言：MySql 中有三种 log 是非常中要的，因为MySql之所以能反对 事务（实现长久化、回滚等）、数据库解体复原、主从复制等，都是基于这三种日志的。至关重要的三种log：binlog 二进制日志redo log 重做日志undo log 回滚日志本文主线：简要介绍三种日志MySql事务处理中三种日志承当的角色简要介绍三种日志：1、binlog 二进制日志：binlog 二进制日志（归档日志），这个日志是由MySql的 server层 进行保护的；不论以后MySql应用的是什么存储引擎，binlog归档日志都是反对的；对MySql的server层不分明的大大们能够参考此文章：查问SQL的执行流程 作用： 用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步。数据恢复，用于数据库的基于工夫点的还原。 内容： 逻辑格局的日志，binlog是用于记录所有数据库表构造和表数据变更的二进制日志，比方insert、update、delete、create、truncate等等操作，不会记录select、show操作，因为它们没有对数据自身产生扭转。 常见格局： MySql的binlog的默认格局是应用 STATEMENT；须要记住的是应用此格局时，如果将事务隔离级别设置为 RC读已提交 时，在进行主从复制的时候会存在bug，导致复制后主从数据不统一； 具体存在什么样的bug能够参考此文章：互联网我的项目中mysql应该选什么事务隔离级别 留神： binlog二进制日志文件在默认状况下并没有启动，须要手动进行开启的；有人可能会质疑，开启此日志文件的话，对数据库的性能会产生什么样的影响？ 质疑是对的，的确开启此日志文件会影响到数据库的性能，然而这个影响是非常无限的，依据MySql的官网手册理解到，开启此日志会使性能降落1%左右，这个损失大体上是能够承受的。 2、redo log 重做日志：redo log重做日志，这个日志是由MySql的 innodb存储引擎 提供保护的，此日志文件只存在于innodb存储引擎下；作用： 确保事务的 持久性 。redo日志记录事务执行后的状态，用来复原未写入data file的已胜利事务更新的数据。避免在产生故障的工夫点，尚有脏页未写入磁盘，在重启mysql服务的时候，依据redo log进行重做，从而达到事务的持久性这一个性。 各位大大，如果下面这段话如果看的不是很明确，能够持续往下看看呀，通过下文中事务的例子能够很好了解； 内容： 物理格局的日志，记录的是物理数据页面的批改的信息，简略说就是记录着xxx页做了xxx批改； innodb 存储引擎提供了重做日志文件组（group），每个重做日志文件组蕴含着重做日志文件；默认是提供了一个重做日志文件组，文件组下蕴含两个大小雷同的重做日志文件； innodb存储引擎的重做日志文件写入流程：先写重做日志文件1，当文件1被程序写满时，会切换到重做日志文件2，再当重做日志文件2也被写满时，会再切换到重做日志文件1中，顺次循环； 所以说重做日志文件是 循环笼罩写入的 。 因为重做日志是循环笼罩写入的，所以不能应用其进行整个数据库的数据恢复，它只能保障数据库宕机时的事务的完整性数据；如果想要复原全副数据的话，只能应用 binlog 二进制日志（归档日志）进行复原。 留神：大家能够手动批改重做日志文件组下的文件数量，并能够指定每个重做日志文件的大小，通过上面的参数： innodb_log_file_size 指定重做日志文件的大小innodb_log_files_in_group 重做日志文件组下的文件数量扩大： 留神：重做日志文件的大小设置对于innodb存储引擎的性能有很大的影响。 重做日志文件不能设置的太大，也不能设置的太小；如果设置的太大，在数据库意外宕机后进行复原时会须要很长时间； 然而也不能设置的太小，因为设置的太小会导致一个事务的日志须要屡次切换重做日志文件进行写入，那么在笼罩掉之前的重做日志时，须要将要被笼罩的重做日志对应在内存中的脏页进行写盘（刷盘）； 因为不写盘的话，如果重做日志被笼罩掉了，而后数据库意外宕机了，那么之前没有写盘的数据将没法在数据库重启时进行复原了，并且如果频繁的进行重做日志的笼罩的话，那么就会频繁的进行脏页刷盘，进而导致数据库性能的抖动。 那重做日志应该设置多大呢？ 一般来说，redo log日志文件的全副大小，应该足够包容服务器一个小时的流动内容。 如果统计出一小时的重做日志写入量为 500M 的话，因为 redo log 日志文件默认有 2 个，所以须要设置 innodb_log_file_size=250M ； ...

一、MySQL数据类型1、整数类型：5种包含 TINYINT、SMALLINT、MEDIUMINT、INT（INTEGER）和 BIGINT须要思考存储空间和数据可靠性均衡的问题 2、浮点数和定点数类型浮点数类型包含FLOAT、DOUBLE、REAL，不准确； FLOAT 示意单精度浮点数；DOUBLE 示意双精度浮点数；REAL 默认就是 DOUBLE。如果你把 SQL 模式设定为启用“REAL_AS_FLOAT”，那么，MySQL 就认为 REAL 是 FLOAT。如果要启用“REAL_AS_FLOAT”，就能够通过以下 SQL 语句实现：SET sql_mode = “REAL_AS_FLOAT”;其中FLOAT占用字节数少，取值范畴小，DOUBLE占用字节多，取值范畴大； 定点数类型（DECIMAL），是准确的数据类型1.它是把十进制数的整数局部和小数局部拆开，别离转换成十六进制数，进行存储。这样，所有的数值，就都能够精准表白了，不会存在因为无奈表白而损失精度的问题。2.MySQL 用 DECIMAL（M,D）的形式示意高精度小数。其中，M 示意整数局部加小数局部，一共有多少位，M<=65。D 示意小数局部位数，D 简略小结浮点数和定点数的特点：浮点类型取值范畴大，然而不精准，实用于须要取值范畴大，又能够容忍渺小误差的科学计算场景（比方计算化学、分子建模、流体动力学等）；定点数类型取值范畴绝对小，然而精准，没有误差，适宜于对精度要求极高的场景（比方波及金额计算的场景）。 3、文本类型包含TEXT、CHAR、VARCHAR、ENUM、SET，区别如下： CHAR(M)：固定长度字符串。CHAR(M) 类型必须事后定义字符串长度。如果太短，数据可能会超出范围；如果太长，又节约存储空间；VARCHAR(M)： 可变长度字符串。VARCHAR(M) 也须要事后晓得字符串的最大长度，不过只有不超过这个最大长度，具体存储的时候，是依照理论字符串长度存储的；TEXT：字符串。零碎主动依照理论长度存储，不须要事后定义长度；ENUM： 枚举类型，取值必须是事后设定的一组字符串值范畴之内的一个，必须要晓得字符串所有可能的取值；SET：是一个字符串对象，取值必须是在事后设定的字符串值范畴之内的 0 个或多个，也必须晓得字符串所有可能的取值。其中TEXT 类型也有 4 种，它们的区别就是最大长度不同： TINYTEXT：255 字符（这里假如字符是 ASCII 码，一个字符占用一个字节，下同）；TEXT： 65535 字符；MEDIUMTEXT：16777215 字符；LONGTEXT： 4294967295 字符（相当于 4GB）。留神：1.TEXT 也有一个问题：因为理论存储的长度不确定，MySQL 不容许 TEXT 类型的字段做主键，遇到这种状况，你只能采纳 CHAR(M)，或者 VARCHAR(M)。2.在我的项目中，只有不是主键字段，就能够依照数据可能的最大长度，抉择这几种 TEXT 类型中的的一种，作为存储字符串的数据类型。 4、日期与工夫类型包含：YEAR、TIME、DATE、DATETIME、TIMESTAMP，1.用得最多的日期工夫类型是 DATETIME，因为尽管DATETIME 类型占用的存储空间最多，然而它表白的工夫最为残缺，取值范畴也最大。 对于MySQL定义表字段类型时的倡议： 整数：INT小数：DECIMAL字符串：TEXT日期与工夫：DATETIME不过，凡事都是有两面的，可靠性好，并不意味着高效，比方，TEXT 尽管使用方便，然而效率不如 CHAR(M) 和 VARCHAR(M)。

一、设置主键https://time.geekbang.org/column/article/3497251、主键能够保证数据的唯一性，而且能够缩小数据谬误，进步查问效率等；2、MySQL中的主键由一个字段或几个字段组合而成，它次要有3个特色： 必须惟一，不能反复；不能为空；必须能够惟一标识数据表中的数据。3、一个MySQL表中只容许有一个主键，尽管MySQL也容许创立没有主键的表；4、给一个没有主键的表减少一个主键列 ALTER TABLE demo.testADD COLUMN itemnumber int PRIMARY KEY AUTO_INCREMENT;ALTER TABLE：标识批改表；ADD COLUMN，示意减少一列；PRIMARY KEY，示意这一列是主键；AUTO_INCREMENT，示意每减少一条记录，这个值主动减少。5、插入一条数据 INSERT INTO demo.test(barcode,goodsname,price)VALUES ('0001','本',3);留神： 每次插入数据必须要写字段名称；主键能够不指定，因为设置主键列是自增。

Thresh概述索引能够晋升查问速度，会影响where查问，以及order by排序。 MySQL索引类型如下： 从索引存储构造划分：B Tree索引、Hash索引、FULLTEXT全文索引、R Tree索引从利用档次划分：一般索引、惟一索引、主键索引、复合索引从索引键值类型划分：主键索引、辅助索引（二级索引）从数据存储和索引键值逻辑关系划分：汇集索引（聚簇索引）、非汇集索引（非聚簇索引）一般索引最根本的索引类型，基于一般字段建设的索引，没有任何限度。 创立一般索引的办法如下： CREATE INDEX <索引的名字> ON tablename (字段名);ALTER TABLE tablename ADD INDEX [索引的名字] (字段名); 罕用CREATE TABLE tablename ( [...], INDEX [索引的名字] (字段名) );惟一索引与"一般索引"相似，不同的就是：索引字段的值必须惟一，但容许有空值。在创立或批改表时追加惟一束缚，就会主动创立对应的惟一索引。 创立惟一索引的办法如下： CREATE UNIQUE INDEX <索引的名字> ON tablename (字段名);ALTER TABLE tablename ADD UNIQUE INDEX [索引的名字] (字段名); 罕用CREATE TABLE tablename ( [...], UNIQUE [索引的名字] (字段名) ;主键索引它是一种非凡的惟一索引，不容许有空值。在创立或批改表时追加主键束缚即可，每个表只能有一个主键。 创立主键索引的办法如下： CREATE TABLE tablename ( [...], PRIMARY KEY (字段名) );ALTER TABLE tablename ADD PRIMARY KEY (字段名); 罕用复合索引用户能够在多个列上建设索引，这种索引叫做组复合索引（组合索引）。复合索引能够代替多个繁多索引，相比多个繁多索引复合索引所需的开销更小。 ...

-- 创立数据库CREATE DATABASE demo；-- 删除数据库DROP DATABASE demo；-- 查看数据库SHOW DATABASES;-- 创立数据表：CREATE TABLE demo.test( barcode text, goodsname text, price int); -- 查看表构造DESCRIBE demo.test;-- 查看所有表SHOW TABLES;-- 增加主键ALTER TABLE demo.testADD COLUMN itemnumber int PRIMARY KEY AUTO_INCREMENT;-- 向表中增加数据INSERT INTO demo.test(barcode,goodsname,price)VALUES ('0001','本',3);

一、设置主键https://time.geekbang.org/column/article/3497251、主键能够保证数据的唯一性，而且能够缩小数据谬误，进步查问效率等；2、MySQL中的主键由一个字段或几个字段组合而成，它次要有3个特色： 必须惟一，不能反复；不能为空；必须能够惟一标识数据表中的数据。3、一个MySQL表中只容许有一个主键，尽管MySQL也容许创立没有主键的表；4、给一个没有主键的表减少一个主键列 ALTER TABLE demo.testADD COLUMN itemnumber int PRIMARY KEY AUTO_INCREMENT;ALTER TABLE：标识批改表；ADD COLUMN，示意减少一列；PRIMARY KEY，示意这一列是主键；AUTO_INCREMENT，示意每减少一条记录，这个值主动减少。5、插入一条数据 INSERT INTO demo.test(barcode,goodsname,price)VALUES ('0001','本',3);留神： 每次插入数据必须要写字段名称；主键能够不指定，因为设置主键列是自增。

作者：余振兴爱可生 DBA 团队成员，相熟 Oracle、MySQL、MongoDB、Redis，最近在盘 TiDB，善于架构设计、故障诊断、数据迁徙、灾备构建等等。负责解决客户 MySQL 及我司自研 DMP 数据库治理平台日常运维中的问题。热衷技术分享、编写技术文档。 本文起源：原创投稿 * 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 本文目录 一、LOAD 根本背景 二、LOAD 根底参数 三、LOAD 示例数据及示例表构造 四、LOAD 场景示例 场景 1. LOAD 文件中的字段比数据表中的字段多场景 2. LOAD 文件中的字段比数据表中的字段少场景 3. LOAD 生成自定义字段数据场景 4. LOAD 定长数据五、LOAD 总结 LOAD 根本背景咱们在数据库运维过程中难免会波及到须要对文本数据进行解决，并导入到数据库中，本文整顿了一些导入导出时常见的场景进行示例演示。LOAD 根底参数文章后续示例均应用以下命令导出的 csv 格局样例数据(以 , 逗号做分隔符，以 " 双引号作为界定符)-- 导出根底参数select * into outfile '/data/mysql/3306/tmp/employees.txt'character set utf8mb4fields terminated by ','enclosed by '"'lines terminated by '\n'from employees.employees limit 10;-- 导入根底参数load data infile '/data/mysql/3306/tmp/employees.txt'replace into table demo.empcharacter set utf8mb4fields terminated by ','enclosed by '"'lines terminated by '\n'...LOAD 示例数据及示例表构造以下为示例数据，表构造及对应关系信息-- 导出的文件数据内容[root@10-186-61-162 tmp]# cat employees.txt"10001","1953-09-02","Georgi","Facello","M","1986-06-26""10002","1964-06-02","Bezalel","Simmel","F","1985-11-21""10003","1959-12-03","Parto","Bamford","M","1986-08-28""10004","1954-05-01","Chirstian","Koblick","M","1986-12-01""10005","1955-01-21","Kyoichi","Maliniak","M","1989-09-12""10006","1953-04-20","Anneke","Preusig","F","1989-06-02""10007","1957-05-23","Tzvetan","Zielinski","F","1989-02-10""10008","1958-02-19","Saniya","Kalloufi","M","1994-09-15""10009","1952-04-19","Sumant","Peac","F","1985-02-18""10010","1963-06-01","Duangkaew","Piveteau","F","1989-08-24"-- 示例表构造SQL > desc demo.emp;+-------------+---------------+------+-----+---------+-------+| Field | Type | Null | Key | Default | Extra |+-------------+---------------+------+-----+---------+-------+| emp_no | int | NO | PRI | NULL | || birth_date | date | NO | | NULL | || first_name | varchar(16) | NO | | NULL | || last_name | varchar(16) | NO | | NULL | || fullname | varchar(32) | YES | | NULL | | -- 表新增字段,导出数据文件中不存在| gender | enum('M','F') | NO | | NULL | || hire_date | date | NO | | NULL | || modify_date | datetime | YES | | NULL | | -- 表新增字段,导出数据文件中不存在| delete_flag | char(1) | YES | | NULL | | -- 表新增字段,导出数据文件中不存在+-------------+---------------+------+-----+---------+-------+-- 导出的数据与字段对应关系emp_no birth_date first_name last_name gender hire_date"10001" "1953-09-02" "Georgi" "Facello" "M" "1986-06-26""10002" "1964-06-02" "Bezalel" "Simmel" "F" "1985-11-21""10003" "1959-12-03" "Parto" "Bamford" "M" "1986-08-28""10004" "1954-05-01" "Chirstian" "Koblick" "M" "1986-12-01""10005" "1955-01-21" "Kyoichi" "Maliniak" "M" "1989-09-12""10006" "1953-04-20" "Anneke" "Preusig" "F" "1989-06-02""10007" "1957-05-23" "Tzvetan" "Zielinski" "F" "1989-02-10""10008" "1958-02-19" "Saniya" "Kalloufi" "M" "1994-09-15""10009" "1952-04-19" "Sumant" "Peac" "F" "1985-02-18""10010" "1963-06-01" "Duangkaew" "Piveteau" "F" "1989-08-24"LOAD 场景示例场景 1. LOAD 文件中的字段比数据表中的字段多只须要文本文件中局部数据导入到数据表中-- 长期创立2个字段的表构造SQL > create table emp_tmp select emp_no,hire_date from emp;SQL > desc emp_tmp;+-----------+------+------+-----+---------+-------+| Field | Type | Null | Key | Default | Extra |+-----------+------+------+-----+---------+-------+| emp_no | int | NO | | NULL | || hire_date | date | NO | | NULL | |+-----------+------+------+-----+---------+-------+-- 导入数据语句load data infile '/data/mysql/3306/tmp/employees.txt'replace into table demo.emp_tmpcharacter set utf8mb4fields terminated by ','enclosed by '"'lines terminated by '\n'(@C1,@C2,@C3,@C4,@C5,@C6) -- 该局部对应employees.txt文件中6列数据-- 只对导出数据中指定的2个列与表中字段做匹配,mapping关系指定的程序不影响导入后果set hire_date=@C6, emp_no=@C1; -- 导入数据后果示例SQL > select * from emp_tmp;+--------+------------+| emp_no | hire_date |+--------+------------+| 10001 | 1986-06-26 || 10002 | 1985-11-21 || 10003 | 1986-08-28 || 10004 | 1986-12-01 || 10005 | 1989-09-12 || 10006 | 1989-06-02 || 10007 | 1989-02-10 || 10008 | 1994-09-15 || 10009 | 1985-02-18 || 10010 | 1989-08-24 |+--------+------------+10 rows in set (0.0016 sec)场景 2. LOAD 文件中的字段比数据表中的字段少表字段不仅蕴含文本文件中所有数据,还蕴含了额定的字段-- 导入数据语句load data infile '/data/mysql/3306/tmp/employees.txt'replace into table demo.empcharacter set utf8mb4fields terminated by ','enclosed by '"'lines terminated by '\n'(@C1,@C2,@C3,@C4,@C5,@C6) -- 该局部对应employees.txt文件中6列数据-- 将文件中的字段与表中字段做mapping对应,表中多出的字段不做解决set emp_no=@C1, birth_date=@C2, first_name=@C3, last_name=@C4, gender=@C5, hire_date=@C6; ...

最近在做监控零碎选型，咱们将监控零碎分为两类：监控和追踪，本篇次要讲断电导致的服务器呈现的问题以及解决方案，对于监控零碎就不多做介绍了。市面上支流的监控零碎次要是zabbix、open-falcon、promethues，明天的配角是zabbix，也就是这次是在搭建zabbix并监控jvm以及服务器信息之后呈现的断电。问题1、服务器启动失败；2、mysql启动失败； 通过周五的时候搭建好了zabbix并且在继续运行，所有都失常，周日的时候忽然断电导致服务器关机了，本想着重启一下服务器，登上去之后重新启动所有利用即可，后果却连服务器零碎都进不去，间接提醒进入紧急模式（过后没有截图截图，只能自行脑补了。。），依据提醒输出journal查看到日志中提醒sda3磁盘分区挂了。 服务器启动失败解决晓得是磁盘分区挂了，就很容易想到是磁盘在继续写入的时候忽然断电导致的，那咱们要做的就是对磁盘分区进行修复。对于xsf文件系统的修复很简略，出错的时候linux也会提醒倡议计划，咱们只须要依据提醒进行修复即可：xfs_repair /dev/sda3 mysql启动失败零碎终于可能失常进入了，下一步就是启动利用了，对于zabbix，我装置的时候是基于mysql数据库去装置的，所以先启动mysql数据库，原本认为会一步到位，后果mysql又给了我当头一棒，间接启动失败，谬误如下：这个看不出来具体什么起因导致的，下一步去日志里看看，关上日志后果如下:从日志中能够看出，断电的时候因为数据还在继续写入，所以数据损坏了，日志里也提到了解决方案：于是关上该网址试试：加这一行即可，通过材料查到这个是要加在mysql启动的配置文件my.cnf中，然而我找遍了各种门路也找不到my.cnf文件(查看命令：mysqld --verbose --help |grep -A 1 'Default options')，找dba帮我建了一个在etc目录下，加了如下内容：通过搜寻发现mysql不必my.cnf也能启动，只是会用默认值进行启动，而如果你想要笼罩mysql的默认行为，则能够通过my.cnf进行配置。这里把innodb_force_recovery改为1之后还是启动不了，一直往上加，始终到3才终于启动胜利。然而这个参数可不是设置越大越好，他只是为了让你能先启动数据库，进行数据备份之类的操作，对于该参数的阐明，我也截了一张图：看到最初一行备注了吗，大于0的时候就无奈进行更改类操作了，所以相当于还是没有用。网上找了一圈，大体是无奈失常应用了，只能先进行数据备份，而后删除坏表或者重建数据库。在断电的时候，只有zabbix数据库是始终在应用的，所以第一个想到的是删除zabbix数据库（当然失常状况下咱们也能够应用check table tableName来查看坏表），这样就删除了坏表了。执行删除操作完了，删都删不掉，那只能采纳重建数据库的操作了。 重建数据库首先咱们须要将所有数据导出来，这里写了一个脚本不便导出： backupdir=/usr/local/mysql/dumpdircd ${backupdir}cur_date=`date '+%Y%m%d'`if [ ! -d ${cur_date} ];then mkdir ${cur_date}ficd ${cur_date}cur_time=`date '+%H%M%S'`db_names=(dbName1 dbName2 dbName3)for db_name in ${db_names[*]}do mkdir ${db_name} for table in `mysql -uroot -pyourpassword -e "show tables from ${db_name}" | sed '1d'` do mysqldump -uroot -pyourpassword ${db_name} ${table} >./"${db_name}"/${table}."${cur_time}".sql donedone通过运行以上shell脚本就能实现所有数据导出了。前面开始重建数据库：1、手动删除mysql的data目录；2、如果mysqld服务启着，则mysqld -remove MySQL进行移除；3、mysqld --initialize-insecure，这一步mysql会主动创立新的data目录；4、如果第二步移除掉，则这里须要再增加，mysqld --install；5、如果启动的时候提醒sock地址被占用，则先删除已存在的sock文件，比方我的sock文件是tmp/mysql.sock文件，当然把对应的sock.lock也一并删除了；以上几步全副做完之后，启动mysql就胜利了上面开始创立用户先用root用户间接登录（mysql -uroot），看一下目前的用户4个用户，mysql8对于明码的认证形式默认应用caching_sha2_password，给root创立一个近程登录权限（我本人用的就是root近程登录），mysql8的话创立用户时记得加with mysql_native_password，如果你的客户端用的是mysql5的驱动。ok，开始导入数据，同样也写了一个shell脚本进行导入。 for db in `ls /usr/local/dumpdir/20210324/`;do echo "source /usr/local/dumpdir/import/${db}.sql;" >> /usr/local/dumpdir/import.sql echo "CREATE DATABASE IF NOT EXISTS $db DEFAULT CHARSET utf8 COLLATE utf8_general_ci;" >> /usr/local/dumpdir/import/${db}.sql; echo "use ${db};" >> /usr/local/dumpdir/import/${db}.sql; for i in `ls /usr/local/dumpdir/20210324/${db}/` ; do echo "source /usr/local/dumpdir/20210324/${db}/$i;" >> /usr/local/dumpdir/import/${db}.sql; donedone登录mysql之后，运行以下命令执行导入操作：source /usr/local/dumpdir/import.sql ...

咱们曾经晓得数据页的格局是这样的：假如咱们要查问一个名字叫做张三的人，咱们是这样查的： 查找第一个数据页的第一条数据，依据形容数据的变长字段的长度列表和null值列表定位字段的值，进行匹配操作。依据形容数据的next_record找到第二条数据，同下面的匹配操作。以后数据页查找完了，依据数据页指向下一个数据页进行下面2个步骤操作。所以这周非索引的，就相当于全表扫描，他会一个个数据页的每行进行查找。如果咱们查找主键id为45的数据呢（假如每个数据页10条），咱们是这样查的： 通过索引找到数据页，此时数据页的id范畴为41-50。而后依据二分查找定位到id为45的数据。这个查找包含了两个货色，一个是主键，是递增的，所以咱们在定位到数据页的时候，能够用二分查找。另外一个就是索引，MySql的索引是B+树结构，索引又分为聚族索引跟非聚族索引。索引在磁盘中，也是通过数据页的模式，所以id=45查找的过程是这样的：在最顶层的数据页中查找，发现45比101还小，所以他就往左边的数据页查找。而后比照45和51，发现比51小，于是就定位数据页4。而后在数据页4中，通过二分查找到45的id。对于非聚族索引，查找的过程也是相似的，不同的他的叶子节点存储的是索引对应的列的值以及索引的值，所以他还要通过索引的值持续下面的操作，也就是回表。

ThreshBinlog 记录模式Redo Log 是属于InnoDB引擎所特有的日志，而MySQL Server也有本人的日志，即 Binary log（二进制日志），简称Binlog。 Binlog是记录所有数据库表构造变更以及表数据批改的二进制日志，不会记录SELECT和SHOW这类操作。 Binlog日志是以事件模式记录，还蕴含语句所执行的耗费工夫。 开启Binlog日志有以下两个最重要的应用场景。 主从复制：在主库中开启Binlog性能，这样主库就能够把Binlog传递给从库，从库拿到Binlog后实现数据恢复达到主从数据一致性。数据恢复：通过mysqlbinlog工具来复原数据。Binlog文件名默认为“主机名_binlog-序列号”格局，例如oak_binlog-000001，也能够在配置文件中指定名称。 文件记录模式有STATEMENT、ROW和MIXED三种，具体含意如下。 ROW（row-based replication, RBR）日志中会记录每一行数据被批改的状况，而后在slave端对雷同的数据进行批改。 长处：能分明记录每一个行数据的批改细节，能齐全实现主从数据同步和数据的复原。毛病：批量操作，会产生大量的日志，尤其是alter table会让日志暴涨。STATMENT（statement-based replication, SBR）每一条被批改数据的SQL都会记录到master的Binlog中，slave在复制的时候SQL过程会解析成和原来master端执行过的雷同的SQL再次执行。简称SQL语句复制。 长处：日志量小，缩小磁盘IO，晋升存储和复原速度毛病：在某些状况下会导致主从数据不统一，比方last_insert_id()、now()等函数。MIXED（mixed-based replication, MBR）以上两种模式的混合应用，个别会应用 STATEMENT 模式保留binlog，对于STATEMENT模式无奈复制的操作应用 ROW 模式保留binlog，MySQL会依据执行的SQL语句抉择写入模式。 Binlog 写入机制罕用的log event有：Query event、Row event、Xid event等。binlog文件的内容就是各种Log event的汇合。 依据记录模式和操作触发event事件生成log event（事件触发执行机制）将事务执行过程中产生log event写入缓冲区，每个事务线程都有一个缓冲区Log Event保留在一个binlog_cache_mngr数据结构中，在该构造中有两个缓冲区，一个是stmt_cache，用于寄存不反对事务的信息；另一个是trx_cache，用于寄存反对事务的信息。事务在提交阶段会将产生的log event写入到内部binlog文件中。不同事务以串行形式将log event写入binlog文件中，所以一个事务蕴含的log event信息在binlog文件中是间断的，两头不会插入其余事务的log event。Binlog 文件操作Binlog状态查看 show variables like 'log_bin';开启Binlog性能须要批改my.cnf或my.ini配置文件，在[mysqld]上面减少log_bin=mysql_bin_log，重启MySQL服务。 #log-bin=ON #log-bin-basename=mysqlbinlog binlog-format=ROW log-bin=mysqlbinlog执行开启语句 set global log_bin=mysqllogbin;应用show binlog events命令 show binary logs; //等价于show master logs; show master status; show binlog events; show binlog events in 'mysqlbinlog.000001'\G;后果: Log_name: mysql_bin.000001 //此条log存在那个文件中 Pos: 174 //log在bin-log中的开始地位 Event_type: Intvar //log的类型信息 Server_id: 1 //能够查看配置中的server_id,示意log是那个服务器产生 End_log_pos: 202 //log在bin-log中的完结地位 Info: INSERT_ID=2 //log的一些备注信息，能够直观的看出进行了什么操作 能够用mysql自带的工具mysqlbinlog ...

咱们曾经晓得了每一行的数据的格局，以及多行数据是紧凑的合并在一起。如果此时这个表的数据有一千万行，那咱们进行查问的时候，效率是很低的，所以mysql就会把这些数据通过数据页的模式宰割起来，相似于分组，查找的时候间接依据数据页的信息就晓得是否存在某些数据。每个数据页的大小是16kb，所以一个数据页能存多少行数据，取决于这个行数据占用多少容量，比方一行就占用1kb，那这个数据页就有16行，如果一行只有0.1kb，那这个数据页就有160行，如果一行是20kb，那边须要2个数据页来寄存。当然数据页不仅仅只有咱们的数据，还有其余信息。行通过数据头的next_record单向链表来指向下一个行的地位，数据页是保护一个双向链表来指向每个数据页的关系。除了这个，数据页还爱护文件头、文件尾、数据页目录等信息。咱们引入数据页就是为了分组，然而只有16kb的数据页，在大量数据背后，作用还是微不足道，所以每64个间断的数据页对应着一个数据区。每个数据区的大小就是64*16kb=1M。在数据区的下面，还有一个数据区组，每一个数据区组爱护了256个数据区，所以一个数据区组的大小是256M。多个数据区组的数据，就是咱们的ibd文件，比方咱们表名是test，那磁盘上就有一个test.ibd文件。

说到这儿，可能有的人会有些疑难： 多值索引不就是联结索引吗，还须要独自开一篇来讲？ 多值索引和基于多个字段的联结索引齐全不同，联结索引是基于多个一维字段，比方字段 r1 int, r2 int,r3 int，这三个字段的组合是联结索引。个别用于三个字段的联结查找，比方 r1 = 1 and r2 = 2 and r3 = 2 等等。 多值索引则不同，它是基于单个字段的，不同的是多值索引基于多维字段，比方数组：[1,2,3,4,5,6] ，基于这样的一个数组来建设索引，能够用来检索数组内任何一个元素值。比方我要查找元素 3 是不是在这个数组里等等。 多值索引是在 MySQL 8.0.17 后才推出的新性能，次要目标是冲破 MySQL 单张表索引的硬性限度（不能超过 64 个）。 上面来讲几个例子介绍下多值索引的大抵实用场景。先来看看对于多个字段都有可能参加的查问，基于这个条件，建设上面表 t1，蕴含主键 ID 以及残余 6 个字段， 表有 300W 行记录。 mysql> show create table t1\G*************************** 1. row *************************** Table: t1Create Table: CREATE TABLE `t1` ( `id` int NOT NULL AUTO_INCREMENT, `r1` int DEFAULT NULL, `r2` int DEFAULT NULL, `r3` int DEFAULT NULL, `r4` int DEFAULT NULL, `r5` int DEFAULT NULL, `r6` int DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci1 row in set (0.00 sec)mysql> select count(*) from t1;+----------+| count(*) |+----------+| 3087152 |+----------+1 row in set (1.03 sec)相干示例数据如下： ...

咱们晓得mysql插入语句后，都是寄存在磁盘文件的，如果是多条数据的话，也是紧凑的挨在一起，比方下图：然而实际上又有点不一样，因为咱们建表的时候，有些字段的长度是可变的，比方咱们定义了varcher(10)，可能就存了a，尽管能够通过补齐长度来实现每条数据的长度是一样的，但这样就节约了存储空间，所以多条数据可能是这样寄存的：如果数据长度不一样的话，那mysql读取某一行的数据的时候，就很麻烦了，他不晓得从哪里开始从哪里完结，所以每一条数据就包含两个局部的内容，一个是形容这条数据的信息，一个是理论的数据。形容数据有三个局部，别离是变长字段的长度列表、null值列表、数据头。理论数据就是每个字段的值紧凑的挨在一起。所以实际上每行数据的构造是这样的： 变长字段的长度列表咱们创立表的时候，就会指定字段的类型，比方column1是可变字段的，这个时候变长字段的长度列表会记录column1的长度，比方他的值是abc，那长度就是3，转十六进制的话就是0x03，他的存储是这样的：咱们读取数据的时候，就能够通过0x03晓得column1要取多少数据。如果column2也是可变字段，比方他的值是de，那他的存储是这样：这里须要留神的是，他的程序跟字段的程序是相同的。 null值列表变长字段是用来晓得咱们每个字段理论的占用长度，那null值字段其实就是表明哪些值是null的。因为某个字段是null的话，他实际上并不会存磁盘的，防止空间的占用。是否为空就两种状态，是或则不是，所以这里有二进制来示意，1示意null，0示意非null。每一个容许null的字段对应一位，位数是8的倍数，不够就补零，所以咱们三个字段也是0000 0000。跟变长字段的长度列表一样，他也是逆序的，即第一个字段在最初一位，所以咱们假如第一行的column3是null，那null值列表就是001，逆序就是100，补齐0就是0000 0100，那存储是这样的：通过变长字段的长度列表咱们晓得字段应该读取的长度，通过null值列表咱们晓得哪些字段应该疏忽读的。 数据头数据头有40位，后16位是next_record，他次要是记录下一行的数据指针。 理论数据咱们存到磁盘的时候，会通过肯定的字符集编码进行对数据进行编码，而后寄存。除了咱们定义的表字段外，他还有其余的暗藏字段，比方DB_ROW_ID、DB_TRX_ID、DB_ROLL_PTR。DB_ROW_ID是一行的惟一标识，如果没有指定主键，那他的值就是主键。DB_TRX_ID用于寄存事务的ID。DB_ROLL_PTR用于事务回滚。所以理论的存储如下（编码这里就略了）：

原文地址：blog.jcole.us/2013/01/03/…在数据存储模型中，通常有“空间”这个概念，在 MySQL 中被称为“表空间”，有时候在 InnoDB 中也被称为“文件空间”。一个空间可能由一个操作系统中的多个理论文件组成（例如 ibdata1, ibdata2 等等），实际上只是一个逻辑文件 - 多个文理文件被当做一个连贯在一起的文件解决。 InnoDB 中每个空间都被调配了一个 32 位的无符号整型空间 ID，这个 ID 被用来在不同的中央援用指向这个空间。InnoDB 总是有一个“零碎空间”，他的空间 ID 是 0。零碎空间用于保留 InnoDB 的一系列元数据的记录。通过 MySQL，InnoDB 目前只反对“一个表一个文件”空间模式的额定空间，这将为每一个 MySQL 表创立 .ibd 文件。从外部来看，这个 .ibd 文件理论是一个能够包容多个表的残缺的空间，然而在 MySQL 的实现中，它只能蕴含一个表。 页= 每个空间被切分成了页，个别每页 16 KiB（也能够通过在编译时指定 UNIV_PAGE_SIZE 批改，或者开启了 InnoDB 压缩）。空间中的页会被调配一个 32 位的页码，这个页码被称为偏移，其实这个页码就是从空间地址结尾的页偏移。所以，第 0 页位于文件偏移 0 的地位，第 1 页位于文件偏移 16384 的地位，以此类推。可能这里有些人会想起来，InnoDB 的数据大小限度是 64 TiB，这个其实是每个空间的大小限度。因为页码是一个 32 位的无符号整型，并且默认的页大小是 16 KiB，这样空间最大大小是 2^32 * 16 KiB = 64 TiB 页的构造如下： 每一页都有一个 38 字节的 FIL 头部和一个 FIL 尾部（FIL这个名字其实就是出自 “file”的简写）。头部蕴含一个示意页类型的字段，这个类型决定了页的剩下局部的构造。 FIL 头部和 FIL 尾部构造如下所示： ...

ThreshRedo顾名思义就是重做。以复原操作为目标，在数据库发生意外时重现操作。 Redo Log指事务中批改的任何数据，将最新的数据备份存储的地位（Redo Log），被称为重做日志。 Redo Log 的生成和开释随着事务操作的执行，就会生成Redo Log，在事务提交时会将产生Redo Log写入Log Buffer，并不是随着事务的提交就立即写入磁盘文件。等事务操作的脏页写入到磁盘之后，Redo Log 的使命也就实现了，Redo Log占用的空间就能够重用（被笼罩写入）。 Redo Log 工作原理Redo Log 是为了实现事务的持久性而呈现的产物。避免在产生故障的工夫点，尚有脏页未写入表的 ibd 文件中，在重启 MySQL 服务的时候，依据 Redo Log 进行重做，从而达到事务的未入磁盘数据进行长久化这一个性。 Redo Log 写入机制Redo Log 文件内容是以程序循环的形式写入文件，写满时则回溯到第一个文件，进行笼罩写 write pos 是以后记录的地位，一边写一边后移，写到最初一个文件开端后就回到 0 号文件结尾；checkpoint 是以后要擦除的地位，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件；write pos 和 checkpoint 之间还空着的局部，能够用来记录新的操作。如果 write pos 追上checkpoint，示意写满，这时候不能再执行新的更新，得停下来先擦掉一些记录，把checkpoint 推动一下。 Redo Log相干配置参数每个InnoDB存储引擎至多有1个重做日志文件组（group），每个文件组至多有2个重做日志文件，默认为ib_logfile0和ib_logfile1。能够通过上面一组参数管制Redo Log存储 show variables like '%innodb_log%';Redo Buffer 长久化到 Redo Log 的策略，可通过 Innodb_flush_log_at_trx_commit 设置(前几章提到过)： 0：每秒提交 Redo buffer ->OS cache -> flush cache to disk，可能失落一秒内的事务数据。由后盾Master线程每隔 1秒执行一次操作。1（默认值）：每次事务提交执行 Redo Buffer -> OS cache -> flush cache to disk，最平安，性能最差的形式。2：每次事务提交执行 Redo Buffer -> OS cache，而后由后盾Master线程再每隔1秒执行OS cache -> flush cache to disk 的操作。个别倡议抉择取值2，因为 MySQL 挂了数据没有损失，整个服务器挂了才会损失1秒的事务提交数据。 ...

ThreshUndo：意为撤销或勾销，以撤销操作为目标，返回指定某个状态的操作。 Undo Log数据库事务开始之前，会将要批改的记录寄存到 Undo 日志里，当事务回滚时或者数据库解体时，能够利用 Undo 日志，撤销未提交事务对数据库产生的影响。 Undo Log产生和销毁Undo Log在事务开始前产生；事务在提交时，并不会立即删除undo log，innodb会将该事务对应的undo log放入到删除列表中，前面会通过后盾线程purge thread进行回收解决。Undo Log属于逻辑日志，记录一个变动过程。例如执行一个delete，undolog会记录一个insert；执行一个update，undolog会记录一个相同的update。 Undo Log存储Undo log采纳段的形式治理和记录。在innodb数据文件中蕴含一种rollback segment回滚段，外部蕴含1024个undo log segment。能够通过上面一组参数来管制Undo log存储。 show variables like '%innodb_undo%'; Undo Log作用实现事务的原子性Undo Log 是为了实现事务的原子性而呈现的产物。事务处理过程中，如果呈现了谬误或者用户执行了 ROLLBACK 语句，MySQL 能够利用 Undo Log 中的备份将数据恢复到事务开始之前的状态。 实现多版本并发管制（MVCC）Undo Log 在 MySQL InnoDB 存储引擎中用来实现多版本并发管制。事务未提交之前，Undo Log保留了未提交之前的版本数据，Undo Log 中的数据可作为数据旧版本快照供其余并发事务进行快照读。 事务A手动开启事务，执行更新操作，首先会把更新命中的数据备份到 Undo Buffer中。事务B手动开启事务，执行查问操作，会读取 Undo 日志数据返回，进行快照读

Thresh Master ThreadMaster thread是InnoDB的主线程，负责调度其余各线程，优先级最高。 作用是将缓冲池中的数据异步刷新到磁盘 ，保证数据的一致性。蕴含：脏页的刷新（page cleaner thread）、undo页回收（purge thread）、redo日志刷新（log thread）、合并写缓冲等。外部有两个主解决，别离是每隔1秒和10秒解决。 每1秒的操作： 刷新日志缓冲区，刷到磁盘 合并写缓冲区数据，依据IO读写压力来决定是否操作 刷新脏页数据到磁盘，依据脏页比例达到75%才操作（innodb_max_dirty_pages_pct，innodb_io_capacity）每10秒的操作： 刷新脏页数据到磁盘 合并写缓冲区数据 刷新日志缓冲区 删除无用的undo页IO Thread在InnoDB中应用了大量的AIO（Async IO）来做读写解决，这样能够极大进步数据库的能。 在InnoDB1.0版本之前共有4个IO Thread，别离是write，read，insert buffer和log thread，起初版本将read thread和write thread别离增大到了4个，一共有10个了。 read thread： 负责读取操作，将数据从磁盘加载到缓存page页。write thread：负责写操作，将缓存脏页刷新到磁盘。log thread：负责将日志缓冲区内容刷新到磁盘。insert buffer thread ：负责将写缓冲内容刷新到磁盘。Purge Thread事务提交之后，其应用的undo日志将不再须要，因而须要Purge Thread回收曾经调配的undo页。 show variables like '%innodb_purge_threads%';Page Cleaner Thread作用是将脏数据刷新到磁盘，脏数据刷盘后相应的redo log也就能够笼罩，即能够同步数据，又能达到redo log循环应用的目标。会调用write thread线程解决。 show variables like '%innodb_page_cleaners%';

Thresh从MySQL 5.5版本开始默认应用InnoDB作为引擎，它善于处理事务，具备主动解体复原的个性。上面是官网的InnoDB引擎架构图，次要分为内存构造和磁盘构造两大部分。 InnoDB 内存构造内存构造次要包含Buffer Pool、Change Buffer、Adaptive Hash Index和Log Buffer四大组件。 Buffer Pool：缓冲池，简称BP。BP以Page页为单位，默认大小16K，BP的底层采纳链表数据结构治理Page。在InnoDB拜访表记录和索引时会在Page页中缓存，当前应用能够缩小磁盘IO操作，晋升效率。 Page管理机制 Page依据状态能够分为三种类型： free page ：闲暇page，未被应用 clean page：被应用page，数据没有被批改过 dirty page：脏页，被应用page，数据被批改过，页中数据和磁盘的数据产生了不统一针对上述三种page类型，InnoDB通过三种链表构造来保护和治理 free list ：示意闲暇缓冲区，治理free page flush list：示意须要刷新到磁盘的缓冲区，治理dirty page，外部page按批改工夫排序。 脏页即存在于flush链表，也在LRU链表中，然而两种互不影响 LRU链表负责管理page的可用性和开释，而flush链表负责管理脏页的刷盘操作。 lru list：示意正在应用的缓冲区，治理clean page和dirty page 缓冲区以midpoint为基点，后面链表称为new列表区 寄存常常拜访的数据，占63%；前面的链表称为old列表区，寄存应用较少数据，占37%。改进型LRU算法保护 一般LRU： 开端淘汰法，新数据从链表头部退出，开释空间时从开端淘汰改性LRU：链表分为new和old两个局部，退出元素时并不是从表头插入，而是从两头midpoint地位插入，如果数据很快被拜访，那么page就会向new列表头部挪动，如果数据没有被拜访，会逐渐向old尾部挪动，期待淘汰。每当有新的page数据读取到buffer pool时，InnoDb引擎会判断是否有闲暇页，是否足够，如果有就将free page从free list列表删除，放入到LRU列表中。没有闲暇页，就会依据LRU算法淘汰LRU链表默认的页，将内存空间开释调配给新的页。Buffer Pool配置参数 show variables like '%innodb_page_size%'; //查看page页大小show variables like '%innodb_old%'; //查看lru list中old列表参数show variables like '%innodb_buffer%'; //查看buffer pool参数倡议：将innodb_buffer_pool_size设置为总内存大小的60%-80%，innodb_buffer_pool_instances能够设置为多个，这样能够防止缓存抢夺。Change Buffer：写缓冲区，简称CB。在进行DML操作时，如果BP没有其相应的Page数据，并不会立即将磁盘页加载到缓冲池，而是在CB记录缓冲变更，等将来数据被读取时，再将数据合并复原到BP中。ChangeBuffer占用BufferPool空间，默认占25%，最大容许占50%，能够依据读写业务量来进行调整。 参数 innodb_change_buffer_max_size;当更新一条记录时，该记录在BufferPool存在，间接在BufferPool批改，一次内存操作。如果该记录在BufferPool不存在（没有命中），会间接在ChangeBuffer进行一次内存操作，不必再去磁盘查问数据，防止一次磁盘IO。当下次查问记录时，会先进性磁盘读取，而后再从ChangeBuffer中读取信息合并，最终载入BufferPool中。 写缓冲区，仅实用于非惟一一般索引页，为什么？ 如果在索引设置唯一性，在进行批改时，InnoDB必须要做唯一性校验，因而必须查问磁盘，做一次IO操作。会间接将记录查问到BufferPool中，而后在缓冲池批改，不会在ChangeBuffer操作。Adaptive Hash Index：自适应哈希索引，用于优化对BP数据的查问。InnoDB存储引擎会监控对表索引的查找，如果察看到建设哈希索引能够带来速度的晋升，则建设哈希索引，所以称之为自适应。InnoDB存储引擎会主动依据拜访的频率和模式来为某些页建设哈希索引。 Log Buffer：日志缓冲区用来保留要写入磁盘上log文件（Redo/Undo）的数据，日志缓冲区的内容定期刷新到磁盘log文件中。日志缓冲区满时会主动将其刷新到磁盘，当遇到 BLOB或多行更新的大事务操作时，减少日志缓冲区能够节俭磁盘I/O。LogBuffer次要是用于记录 InnoDB引擎日志，在 DML操作时会产生Redo和Undo日志。LogBuffer空间满了，会主动写入磁盘。能够通过将 innodb_log_buffer_size 参数调大，缩小磁盘IO频率innodb_flush_log_at_trx_commit参数管制日志刷新行为，默认为1 ...

Git 和 MySQL 的「孩子」，一个能够应用 Git 操作的数据库。近期间断在 GitHub 趋势榜霸榜，新增 4k+ Star。 简介Dolt 是一个 SQL 数据库，咱们能够应用 fork、clone、branch、merge、push、pull 等性能，就像在操作一个 git 仓库一样；同时，它也像 MySQL 一样，只有连贯上 Dolt，咱们就能够应用 SQL 语句进行数据的查问、更新等操作。应用命令行导入 CSV 文件，提交更改，将其推送到近程或合并团队成员的更改。 Git 的所有命令对于 Dolt 来说都是试用的，完全一致，Dolt 感觉就像是 Git 和 MySQL 的孩子一样。 Dolt 有以下命令： $ doltValid commands for dolt are init - 创立一个Dolt数据仓库. status - 查看工作空间状态. add - 增加批改到暂存区. reset - 移除暂存区的批改. commit - 提交提交到仓库. sql - 在仓库中运行某一个sql命令. sql-server - 启动MySQL兼容服务器. log - 查看提交日志. diff - 比拟表. blame - 查看表每行最初批改的用户及版本号e. merge - 合并分支. branch - 创立，查看，编辑或删除分支. tag - 创立，查看，编辑或删除标签. checkout - 切换某个分支或笼罩表. remote - 治理近程仓库. push - 推送到近程仓库. pull - 拉取近程仓库数据并合并. fetch - 从近程仓库更新数据. clone - clone近程仓库数据. creds - 身份凭证的治理. login - 登录近程Dolt主机. version - 查看Dolt版本. config - Dolt相干配置. ls - 查看工作区中的表. schema - 查看或导入表构造. table - 复制，重命名，删除或导出表. conflicts - 查看以及解决合并抵触. migrate - 执行存储库迁徙以更新为最新格局. read-tables - 将特定提交处的表提取到新的仓库中 gc - 从仓库中革除未援用的数据.我的项目地址：https://github.com/dolthub/dolt ...

Thresh存储引擎在MySQL的体系架构中位于第三层，负责MySQL中的数据的存储和提取，是与文件打交道的子系统，它是依据MySQL提供的文件拜访层形象接口定制的一种文件拜访机制，这种机制就叫作存储引擎。 应用show engines命令，就能够查看以后数据库反对的引擎信息。 在5.5版本之前默认采纳MyISAM存储引擎，从5.5开始采纳InnoDB存储引擎。 InnoDB：反对事务，具备提交，回滚和解体恢复能力，事务平安MyISAM：不反对事务和外键，访问速度快InnoDB和MyISAM比照InnoDB和MyISAM是应用MySQL时最罕用的两种引擎类型，咱们重点来看下两者区别。 事务和外键 InnoDB反对事务和外键，具备安全性和完整性，适宜大量insert或update操作 MyISAM不反对事务和外键，它提供高速存储和检索，适宜大量的select查问操作锁机制 InnoDB反对行级锁，锁定指定记录。基于索引来加锁实现。 MyISAM反对表级锁，锁定整张表。索引构造 InnoDB应用汇集索引（聚簇索引），索引和记录在一起存储，既缓存索引，也缓存记录。 MyISAM应用非汇集索引（非聚簇索引），索引和记录离开。并发解决能力 MyISAM应用表锁，会导致写操作并发率低，读之间并不阻塞，读写阻塞。 InnoDB读写阻塞能够与隔离级别无关，能够采纳多版本并发管制（MVCC）来反对高并发存储文件 InnoDB表对应两个文件，一个.frm表构造文件，一个.ibd数据文件。InnoDB表最大反对64TB； MyISAM表对应三个文件，一个.frm表构造文件，一个MYD表数据文件，一个.MYI索引文件。从MySQL5.0开始默认限度是256TB。实用场景 MyISAM 不须要事务反对（不反对） 并发绝对较低（锁定机制问题）数据批改绝对较少，以读为主 数据一致性要求不高 InnoDB 须要事务反对（具备较好的事务个性） 行级锁定对高并发有很好的适应能力 数据更新较为频繁的场景数据一致性 要求较高硬件设施内存较大，能够利用InnoDB较好的缓存能力来进步内存利用率，缩小磁盘IO总结 两种引擎该如何抉择？ 是否须要事务？有，InnoDB是否存在并发批改？有，InnoDB是否谋求疾速查问，且数据批改少？是，MyISAM在绝大多数状况下，举荐应用InnoDB

Thresh①建设连贯（Connectors&Connection Pool） 通过客户端/服务器通信协议与MySQL建设连贯。MySQL 客户端与服务端的通信形式是 “ 半双工 ”。对于每一个 MySQL 的连贯，时刻都有一个线程状态来标识这个连贯正在做什么。(半双工：指的某一时刻，要么发送数据，要么接收数据，不能同时。例如晚期对讲机)线程状态： show processlist; //查看用户正在运行的线程信息，root用户能查看所有线程，其余用户只能看本人的 id：线程ID，能够应用kill xx； user：启动这个线程的用户 Host：发送申请的客户端的IP和端口号 db：以后命令在哪个库执行 Command：该线程正在执行的操作命令 Create DB：正在创立库操作 Drop DB：正在删除库操作 Execute：正在执行一个PreparedStatement Close Stmt：正在敞开一个PreparedStatement Query：正在执行一个语句 Sleep：正在期待客户端发送语句 Quit：正在退出 Shutdown：正在敞开服务器 Time：示意该线程处于以后状态的工夫，单位是秒 State：线程状态 Updating：正在搜寻匹配记录，进行批改 Sleeping：正在期待客户端发送新申请 Starting：正在执行申请解决 Checking table：正在查看数据表 Closing table : 正在将表中数据刷新到磁盘中 Locked：被其余查问锁住了记录 Sending Data：正在解决Select查问，同时将后果发送给客户端 Info：个别记录线程执行的语句，默认显示前100个字符。想查看残缺的应用show full processlist;②查问缓存（Cache&Buffer）这是MySQL的一个可优化查问的中央，如果开启了查问缓存且在查问缓存过程中查问到完全相同的SQL语句，则将查问后果间接返回给客户端；如果没有开启查问缓存或者没有查问到完全相同的 SQL 语句则会由解析器进行语法语义解析，并生成“解析树”。 a. 缓存Select查问的后果和SQL语句b. 执行Select查问时，先查问缓存，判断是否存在可用的记录集，要求是否完全相同（包含参数值），这样才会匹配缓存数据命中。c. 即便开启查问缓存，以下SQL也不能缓存 查问语句应用SQL_NO_CACHE 查问的后果大于query_cache_limit设置 查问中有一些不确定的参数，比方now()d. show variables like '%query_cache%'; //查看查问缓存是否启用，空间大小，限度等e. show status like 'Qcache%'; //查看更具体的缓存参数，可用缓存空间，缓存块，缓存多少等③解析器（Parser）将客户端发送的SQL进行语法解析，生成"解析树"。预处理器依据一些MySQL规定进一步查看“解析树”是否非法，例如这里将查看数据表和数据列是否存在，还会解析名字和别名，看看它们是否有歧义，最初生成新的“解析树”。④查问优化器（Optimizer）依据“解析树”生成最优的执行打算。MySQL应用很多优化策略生成最优的执行打算，能够分为两类：动态优化（编译时优化）、动静优化（运行时优化）。 等价变换策略 5=5 and a>5 改成 a > 5 a < b and a=5 改成b>5 and a=5 基于联结索引，调整条件地位等优化count、min、max等函数 InnoDB引擎min函数只须要找索引最右边 InnoDB引擎max函数只须要找索引最左边 MyISAM引擎count(*)，不须要计算，间接返回提前终止查问 应用了limit查问，获取limit所需的数据，就不在持续遍历前面数据in的优化 MySQL对in查问，会先进行排序，再采纳二分法查找数据。比方where id in (2,1,3)，变成 in (1,2,3) ⑤查问执行引擎负责执行 SQL 语句，此时查问执行引擎会依据 SQL 语句中表的存储引擎类型，以及对应的API接口与底层存储引擎缓存或者物理文件的交互，失去查问后果并返回给客户端。若开启用查问缓存，这时会将SQL 语句和后果残缺地保留到查问缓存（Cache&Buffer）中，当前若有雷同的 SQL 语句执行则间接返回后果。 ...

ThreshMySQL Server架构自顶向下大抵能够分网络连接层、服务层、存储引擎层和系统文件层。 网络连接层客户端连接器（Client Connectors）：提供与MySQL服务器建设的反对。目前简直反对所有支流 的服务端编程技术，例如常见的 Java、C、Python、.NET等，它们通过各自API技术与MySQL建设连贯。 服务层（MySQL Server）服务层是MySQL Server的外围，次要蕴含系统管理和管制工具、连接池、SQL接口、解析器、查问优化器和缓存六个局部。 1. 连接池（Connection Pool）：负责存储和治理客户端与数据库的连贯，一个线程负责管理一个连贯。[官网性能测试报告:引入线程池,性能稳定性与性能会有很大得晋升,128并发,读写模式, mysql高出60倍,只读18倍,若不援用线程池,线程创立敞开性能耗费大] 2. 系统管理和管制工具（Management Services & Utilities）：例如备份复原、平安治理、集群治理等 3. SQL接口（SQL Interface）：用于承受客户端发送的各种SQL命令，并且返回用户须要查问的后果。比方DML、DDL、存储过程、视图、触发器等。 4. 解析器（Parser）：负责将申请的SQL解析生成一个"解析树"。而后依据一些MySQL规定进一步查看解析树是否非法。 5. 查问优化器（Optimizer）：当“解析树”通过解析器语法查看后，将交由优化器将其转化成执行打算，而后与存储引擎交互。 6. 缓存（Cache&Buffer）： 缓存机制是由一系列小缓存组成的。比方表缓存，记录缓存，权限缓 存，引擎缓存等。如果查问缓存有命中的查问后果，查问语句就能够间接去查问缓存中取数据。select uid,name from user where gender=1; 执行优化程序 1）select先依据where语句进行选取，并不是查问出全副数据再过滤 2）select查问依据uid和name进行属性投影，并不是取出所有字段 3）将后面选取和投影联接起来最终生成查问后果存储引擎层（Pluggable Storage Engines）存储引擎负责MySQL中数据的存储与提取，与底层系统文件进行交互。MySQL存储引擎是插件式的，服务器中的查问执行引擎通过接口与存储引擎进行通信，接口屏蔽了不同存储引擎之间的差别 。当初有很多种存储引擎，各有各的特点，最常见的是MyISAM和InnoDB。系统文件层（File System）该层负责将数据库的数据和日志存储在文件系统之上，并实现与存储引擎的交互，是文件的物理存储层。次要蕴含日志文件，数据文件，配置文件，pid 文件，socket 文件等。 1. 日志文件 a. 谬误日志（Error log） 默认开启，show variables like '%log_error%' b. 通用查问日志（General query log） 记录个别查问语句，show variables like '%general%'; c. 二进制日志（binary log） 记录了对MySQL数据库执行的更改操作，并且记录了语句的产生工夫、执行时长； 然而它不记录select、show等不批改数据库的SQL。 次要用于数据库复原和主从复制。 show variables like '%log_bin%'; //是否开启 show variables like '%binlog%'; //参数查看 show binary logs;//查看日志文件 d. 慢查问日志（Slow query log） 记录所有执行工夫超时的查问SQL，默认是10秒。 show variables like '%slow_query%'; //是否开启 show variables like '%long_query_time%'; //时长2. 配置文件 用于寄存MySQL所有的配置信息文件，比方my.cnf、my.ini等。3. 数据文件 a. db.opt 文件：记录这个库的默认应用的字符集和校验规定。 b. frm 文件：存储与表相干的元数据（meta）信息，包含表构造的定义信息等，每一张表都会有一个frm 文件。 c. MYD 文件：MyISAM 存储引擎专用，寄存 MyISAM 表的数据（data)，每一张表都会有一个.MYD 文件。 d. MYI 文件：MyISAM 存储引擎专用，寄存 MyISAM 表的索引相干信息，每一张 MyISAM 表对应一个 .MYI 文件。 e. ibd文件和 IBDATA 文件：寄存 InnoDB 的数据文件（包含索引）。 InnoDB 存储引擎有两种表空间形式：独享表空间和共享表空间。 1. 独享表空间应用 .ibd 文件来存放数据，且每一张InnoDB 表对应一个 .ibd 文件。 2. 共享表空间应用 .ibdata 文件，所有表独特应用一个（或多个，自行配置）.ibdata 文件。 f. ibdata1 文件：零碎表空间数据文件，存储表元数据、Undo日志等 。 g. ib_logfile0、ib_logfile1 文件：Redo log 日志文件。 4. pid 文件 pid 文件是 mysqld 应用程序在 Unix/Linux 环境下的一个过程文件，和许多其余 Unix/Linux 服务端程序一样，它寄存着本人的过程 id。 5. socket 文件 socket 文件也是在 Unix/Linux 环境下才有的，用户在 Unix/Linux 环境下客户端连贯能够不通过TCP/IP 网络而间接应用 Unix Socket 来连贯 MySQL。

Thresh本节了解MySQL利用架构在不同的并发拜访量级和数据量级下，架构的演变过程。 MySQL利用架构演变单机单库一个简略的小型网站或者利用背地的架构能够非常简单, 数据存储只须要一个MySQL Instance就能满足数据读取和写入需要（这里疏忽掉了数据备份的实例），处于这个的阶段零碎，个别会把所有的信息存到一个MySQL Instance外面。毛病: 1. 数据量太大，超出一台服务器接受 2. 读写操作量太大，超出一台服务器接受 3. 一台服务器挂了，利用也会挂掉（可用性差）主从架构次要解决单体架构下的高可用和读扩大问题，通过给Instance挂载从库解决读取的压力，主库宕机也能够通过主从切换保障高可用。在MySQL的场景下就是通过主从构造（双主构造也属于非凡的从），主库抗写压力，通过从库来分担读压力，对于写少读多的利用毛病: 1. 数据量太大，超出一台服务器接受 2. 写操作太大，超出一台主服务器接受分库分表遇到写入瓶颈和存储瓶颈时，能够通过程度拆分来解决，程度拆分和垂直拆分有较大区别，垂直拆分拆完的后果，每一个实例都是领有全副数据的，而程度拆分之后，任何实例都只有全量的1/n的数据。毛病: 1. 数据如何路由成为一个关键问题， 个别能够采纳范畴拆分，List拆分、Hash拆分等。 2. 如何保持数据的一致性也是个难题。云数据库云数据库（云计算）,对于数据存储的MySQL来说，如何让其成为一个saas（Software as a Service）是关键点。MySQL作为一个saas服务， 服务提供商负责解决可配置性，可扩展性，多用户存储结构设计等这些疑难问题。

细枝末节1. 内连贯的INNER和外连贯的OUTER能够省略2. 筛选条件放在WHERE后,连贯条件放在ON后,进步分离性,便于浏览3. 外连贯查问的后果集为主表中所有记录4. LEFT和RIGHT作用是指定主表5. 全连贯是将两表都作为主表6. 穿插连贯后果集是笛卡尔乘积格局SELECT 查问列表FROM 表1 别名 [连贯类型]JOIN 表2 别名ON 连贯条件[WHERE 筛选条件][GROUP BY 分组][HAVING 筛选条件][ORDER BY 排序列表]连贯类型:1. 内连贯: IINER2. 外连贯: 左外连贯: LEFT [OUTER] 右外连贯: RIGHT [OUTER] 全外连贯: FULL [OUTER]3. 穿插连贯: CROSS内连贯格局SELECT 查问列表FROM 表1 别名INNER JOIN 表2 别名ON 连贯条件分类1. 等值连贯2. 非等值连贯3. 内连贯等值连贯示例/* 查问员工名,部门名 */SELECT e.name, d.nameFROM emp eINNER JOIN dept dON e.dept_id = d.id/* 查问名字中蕴含e的员工名和工种名 */SELECT e.name, j.nameFROM emp eINNER JOIN job jON e.job_id = j.idWHERE e.name LIKE '%e%';/* 查问部门个数>3的城市名和部门个数 */SELECT city, COUNT(*)FROM location lINNER JOIN dept dON d.loc_id = l.idGROUP BY cityHAVING COUNT(*)>3/* 查问员工名,部门名,工种名,并按部门降序 */SELECT e.name, d.name, j.nameFROM emp eINNER JOIN dept d ON e.dept_id = d.idINNER JOIN job j ON e.job_id = j.idORDER BY d.name DESC;非等值连贯示例/* 查问员工的工资级别 */SELECT salry, gradeFROM emp eINNER JOIN salary_grade gON e.salary BETWEEN g.lowwest_sal AND g.highest_sal;自连贯示例/* 查问姓名中蕴含k的员工姓名及其下属姓名 */SELECT e.name, m.nameFROM emp eINNER JOIN emp mON e.mng_id = m.idWHERE e.name LIKE '%k%';外连贯示例/* 查问男朋友不在男生表的女生名 *//* 第一种形式:左外连贯 */SELECT w.name, m.*FROM womwn wLEFR OUTER JOIN man mON w.cp_id = m.idWHERE m.name IS NULL;/* 第二种形式:右外连贯 */SELECT w.name m.*FROM man mRIGHT OUTER JOIN woman wON w.cp_id = m.idWHERE m.nae IS NULL;

细枝末节1. 本节函数都疏忽NULL值，不计算2. sum()、avg()个别用于解决数值型3. max()、min()、count()能够解决任何类型4. 本节函数可与distinct搭配实现去重运算5. 和分组函数一起查问的字段要求是GROUP BY后的字段函数sum()作用对参数中的值求和示例/* 从mytable中查问所有salary的和 */SELECT sum(salary)FROM mytable;avg()作用对参数中的值求平均数示例/* 从mytable中查问所有用户salary的平均值 */SELECT avg(salary)FROM mytable;max()作用对参数中值求最大值示例/* 从mytable中查问最大的salary */SELECT max(salary)FROM mytable;min()作用对参数中的值求最小值示例/* 从mytable中查问最小的salary */SELECT min(salary)FROM mytable;count()作用计算参数中记录的个数示例/* 从mytable中计算出id总个数 */SELECT count(id)FROM mytable;备注1. count()疏忽NULL，个别应用count(*)计算所有记录数2. count(1)增加一个字段，所有值都是1，统计1的个数即统计所有记录3. 效率： MYISAM引擎：引擎中有外部计数器，能够间接返回个数，count(*)效率高 INNODB引擎：count(*)与count(1)效率相当，然而都比count(字段)高

细枝末节1. 函数能够嵌套应用2. MySQL中索引从1开始3. substr()中空格也算一个字符概念将一组逻辑语句封装在办法中,对外裸露办法名.长处1. 暗藏实现细节2. 进步代码可用性字符函数length()作用用于获取参数值的字节个数查问字符串"Mike"的字节数# 输入为4SELECT length('Mike');concat()作用拼接字符串示例# 输入为MikeJohnSELECT concat('Mike','John');upper()作用将参数值中的字母全副转换为大写示例# 输入为MIKESELECT upper('Mike');lowwer()作用将参数值中的字母全副转换为小写示例# 输入为mikeSELECT lowwer('Mike');substr(),substring()作用字符截取示例# 输入为e JognSELECT substr('Mike John', 4);# 输入为e JohSELECT substr('Mike John', 4, 5);instr()作用返回第二个参数在第一个参数中呈现的起始地位,找不到返回0示例# 输入为6SELECT instr('Mike John', 'Jo');# 输入为0SELECT instr('Mike John', 'coo');trim()作用去除参数字符串中的前后空格示例# 输入为4SELECT length(trim(' Mike '));# 输入为MikeSELECT trim('b' FROM 'bbbbbMikeb');lpad()作用用指定字符左填充字符串,使字符串长度为指定长度示例# 输入为aaaaaaMikeSELECT lpad('Mike', 10, 'a');# 输入为MiSELECT lpad('Mike', 2, 'c');rpad()作用用指定字符右填充字符串,使字符串长度为指定长度示例# 输入为MikeffffffSELECT rpad('Mike', 10, 'f');# 输入为MikSELECT rpad('Mike', 3, 'd');replace()作用在字符串中用指定字符串替换指定字符串示例# 输入为Mick Jogn JickSELECT replace('Mike John Jike', 'ke', 'ck');数学函数round()作用四舍五入示例# 输入为20SELECT round(19.5);# 输入为19SELECT round(19.4);# 输入为19.46SELECT round(19.4567, 2);ceil()作用向上取整示例# 输入为2SELECT ceil(1.01);# 输入为1SELECT ceil(1.00);# 输入为-1SELECT ceil(-1.01);floor()作用向下取整示例# 输入为1SELECT floor(1.99);# 输入为-2SELECT floor(-1.99);truncate()作用截断数字中小数点后指定位数示例# 输入为1.11SELECT truncate(1.111, 2);mod()作用取余示例# 输入为1SELECT mod(10, 3);# 输入为-1SELECT mod(-10, 3):# 输入为1SELECT mod(10, -3);日期函数now()作用返回以后日期+工夫示例# 输入为2021-03-22 16:20:03SELECT now();curdate()作用返回以后零碎日期示例# 输入为2021-03-22SELECT curdate();curtime()作用返回以后零碎工夫示例# 输入为16:25:20SELECT curtime();year(),month(),monthname()作用获取指定局部示例# 输入为2021SELECT year(now());# 输入为03SELECT month('1999-03-23');# 输入为FebruarySELECT monthname('2002-02-02');str_to_data()作用将字符串转换为日期示例# 输入为2020-01-11SELECT str_to_date('1-11-2020', '%m-%d-%Y');date_format()作用将日期转换为字符示例# 输入为2021年03月22日SELECT date_format(now(), '%y年%m月%d日');其余函数version()作用查看以后版本示例# 输入为8.0.21SELECT version();database()作用查看以后应用数据库的名称示例# 输入为mytableSELECT database();user()作用查看以后操作数据库的用户示例# 输入为root@localhostSELECT user();

细枝末节ASC示意升序,DESC示意降序,不写默认升序ORDER BY字句中能够是单个字段,多个字段,表达式,函数,别名除LIMIT外,ORDER BY语句个别放在SQL语句最初面格局# 从指定表中按指定条件查问指定字段,并按指定排序输入SELECT 字段名FROM 表名WHERE 筛选列表ORDER BY 排序列表 [DESC | ASC]执行程序FROM 表 ==> SELECT 字段 ==> WHERE 筛选列表 ==> ORDER BY 排序列表 [DESC | ASC]查问用户信息,要求按salary从高到低排序SELECT *FROM mytableORDER BY salary;查问用户信息,要求按salary降序排序,再按id升序排序SELECT *FROM mytableORDER BY salary DESC, id ASC;

细枝末节"_"示意任意一个字符"%"示意任意多个任意字符,蕴含0个"="不能够判断NULL值,"<=>"能够比拟NULL值"<>"不能够判断NULL值转义字符"\"能够在SQL中应用ESCAPE关键字能够指定转移字符BETWEEN AND蕴含两个临界值,且临界值不能颠倒IN列表中的值类型必须统一语法SELECT 字段名FROM 表名WHERE 条件执行程序FROM 表名 ----> WHERE 条件 ----> SELECT 字段名按条件表达式筛选简略条件运算符大于 &nbsp &nbsp &nbsp &nbsp &nbsp &nbsp &gt小于 &nbsp &nbsp &nbsp &nbsp &nbsp &nbsp <等于 &nbsp &nbsp &nbsp &nbsp &nbsp &nbsp = &nbsp &nbsp &nbsp &nbsp <=>不等于 &nbsp &nbsp &nbsp &nbsp <> &nbsp &nbsp &nbsp !=大于等于 &nbsp &nbsp &gt=小于等于 &nbsp &nbsp <=查问id大于10的用户名 ---> {">"}SELECT nameFROM mytableWHERE id > 10;查问age小于30的用户id ---> {"<"}SELECT idFROM mytableWHERE age < 30;查问name不等于Mike的用户age ---> {"<>"}SELECT ageFROM mytableWHERE name <> 'Mike';按逻辑表达式筛选逻辑运算符与 &nbsp &nbsp & &nbsp &nbsp and或 &nbsp &nbsp | &nbsp &nbsp or非 &nbsp &nbsp ! &nbsp &nbsp not查问age在18-30之间的用户的id和name ---> {"AND"}SELECT id, nameFROM mytableWHERE age >= 18AND age <= 30查问薪水不在6000-8000之间,或者薪水小于3000的用户id ---> {"OR","NOT"}# 第一种写法:SELECT idFROM mytableWHERE salary < 6000OR salary > 8000OR salary < 3000;# 第二种写法:SELECT idFROM mytableWHERE NOT(salary >= 6000 AND salary <= 8000)OR salary < 3000;含糊查问运算符LIKEBETWEEN ANDINIS NULLIS NOT NULL查问名字中蕴含字母a的用户信息 ---> {"LIKE","%"}SELECT *FROM mytableWHERE name LIKE '%a%';查问用户名第三个字符为c,第5个为d的用户id和age ---> {"_"}SELECT id, ageFROM mytableWHERE name LIKE '__c_d%';查问用户名第三个字符为"_"的用户id ---> {"\","ESCAPE"}# 第一种写法:SELECT idFROM mytableWHERE name LIKE '__\_%';# 第二种写法:SELECT idFROM mytableWHERE name LIKE '__$_%' ESCAPE '$';查问age在18-30之间的用户信息 ---> {"BETWEEN AND"}SELECT *FROM mytableWHERE age BETWEEN 18 AND 30;查问age为18和20的用户信息 ---> {"IN"}SELECT *FROM mytableWHERE age IN(18,20);查问没有奖金的用户信息 ---> {"IS NULL","<=>"}# 第一种写法:SELECT *FROM mytableWHERE commission IS NULL;# 第二种写法:SELECT *FROM mytableWHERE commission <=> NULL;

大抵报错MySQL 1022 can't write duplicate key in table 起因不同数据表所设置的外键名称反复了。  例子：myorder订单表和cart购物车表都有外键userId，关联user表中的主键userId。且二者外键名一样，则报错。 解决批改一下外键名称即可。（比方这里批改cart表的）    参考1022 can't write duplicate key in table #‘sql_XXXXX’

大抵报错内容MySQL 1091 can't drop check that columnkey exists背景形容在navicat中创立外键时报错（想为myorder表创立外键userId，关联user表的主键userId）  对于navicat创立外键具体步骤，参见此文：navicat 数据表增加外键 可能的起因（任意一个）1.myorder表没有创立字段userId2.myorder表刚创立完，尽管有字段userId，然而还没保留myorder表，就立马去设置外键。 解决创立完myorder表后（记得要先创立userId字段），保留好。再为myorder表增加外键。 参考[[Err] 1091](http://t.zoukankan.com/hzcya1...

大抵报错内容1452 - Cannot add or update a child row: a foreign key constraint fails 背景navicat创立外键时报错  对于navicat创立外键具体步骤，参见此文：navicat 数据表增加外键 起因两张表的数据不匹配（参见下图）  例子：myorder表中userId字段是外键，关联user表中的userId字段。 myorder表中userId字段的值是0，而user表中没有userId=0的，这样就呈现了数据不匹配的问题。如果ctrl+s保留myorder表就会报错。      解决批改myorder表中字段userId的值即可（与user表匹配） ctrl+s，不再报错    参考文章Mysql谬误1452 - Cannot add or update a child row: a foreign key constraint fails 起因及解决办法

数据库简介      数据表简介user表（用户表）寄存用户相干信息，字段阐明如下：惟一标识userId（主键）用户名username明码password    myorder表寄存用户订单信息，字段阐明如下：订单惟一标识orderId（主键）总价priceuserId是myorder表中的外键，关联的是user表中的主键userId  留神：1.myorder表中必须先新建userId字段，否则外键增加失败。2.myorder表中的userId字段的类型和长度必须与user表中userId字段的统一，否则外键增加失败。    数据表选项数据表的引擎为InnoDB，否则可能外键增加失败。查看办法如下      navicat中，数据表外键增加步骤在myorder表中进行如下操作：①单击“外键”tab②单击“增加外键”按钮③在绿框处依据须要进行设置   对于绿框局部的设置阐明，简要阐明如下简要阐明： 名，即外键名（轻易取）字段，如myorder表的字段userId参考模式，就是以后数据表所在的数据库参考表，比方user表参考字段，比方user表的字段useId删除时，指删除时做的操作。这里抉择CASCADE，示意当user表中某记录被删除，则myorder表的相应记录也被删除更新时，指更新时做的操作。这里抉择CASCADE，示意当user表中某记录被更新，则myorder表的相应记录也被更新  具体参见这两篇文章navicat给mysql增加外键演示在navicat中为mysql表增加外键     测试顺次向user表和myorder表插入数据（必须先向user表插入数据，而后再在myorder表中插入数据，如果程序反了会报错）   新建查问，执行以下语句 delete from user where userId=1;留神是删除user表的，不是删除myorder表，这样当user表中userId=1的记录被删除时，myorder表中userId=1的记录也会被级联删除。（如果反过来，则user表中userId=1的记录不会被删除） 发现删除胜利。至此，外键增加胜利。     参考navicat给mysql增加外键 演示在navicat中为mysql表增加外键

简介在某些状况下在服务器是不能连贯网络的，这时就无奈通过yum装置MySQL数据库，但好在国内国内的很多镜像站提供了包下载性能，能够把包下载到本地后通过U盘或者光驱进行装置。在些日子我就遇到了这种状况，先将整个装置过程记录如下。 具体操作装置依赖在无网环境下装置MySQL须要先装置所需的依赖包。下载胜利后，进入文件夹内执行rpm -ivh *.rpm --nodeps --force即可。 下载安装包从官方网站下载安装包太慢了，举荐应用国内的镜像源，例如：华为开源镜像站、清华大学开源软件镜像站等。以华为源为例： 抉择MySQL 下载并抉择对应的版本 抉择对应操作系统安装包（这里是针对Centos7） 装置确保曾经装置了相干依赖包解压文件至指定目录# 解压至/usr/local/tar -zxvf mysql-5.7.31-linux-glibc2.12-x86_64.tar.gz -C /usr/local/对文件进行重命名（非必选操作）mv mysql-5.7.31-linux-glibc2.12-x86_64 mysql 编辑配置文件默认状况下在/etc/目录下存在my.cnf文件（不存在手动创立即可），此文件是MySQL的配置文件，以此为参照 [mysqld]# 端口port=3306#数据保留门路datadir=/usr/local/mysql/data# sock文件socket=/usr/local/mysql/mysql.sock# 启动用户user=root# 最大连接数max_connections=151# Disabling symbolic-links is recommended to prevent assorted security riskssymbolic-links=0# 设置疏忽大小写lower_case_table_names = 1# 指定编码character-set-server=utf8collation-server=utf8_general_ci# 开启ip绑定bind-address = 0.0.0.0[mysqld_safe]# 日志门路log-error=/var/log/mysqld.log# 启动后的过程ID保留门路pid-file=/var/run/mysqld/mysqld.pid# 客户端相干[client]socket=/usr/local/mysql/mysql.sockdefault-character-set=utf8# 数据库降级5.7之后应用group by呈现问题的解决方案 https://blog.csdn.net/study_in/article/details/92625397[mysqld]sql_mode =STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION进入mysql装置目录执行装置# 进入目录cd /usr/local/mysql/# 指定启动用户、数据保留门路等./bin/mysqld --user=root --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data --initialize# 启动mysql 执行这个步骤后会呈现登录数据库的随机明码，留神保留./support-files/mysql.server start# 把mysql放入零碎服务中cp $m/support-files/mysql.server /etc/init.d/mysqld# 执行数据库重启service mysqld restart配置环境变量echo 'export PATH=$PATH:/usr/local/mysql/bin' >> /etc/profile# 从新加载source /etc/profile查看MySQL状态service mysqld status至此MySQL数据库已胜利装置，下一步须要登录数据库并重置明码，重置胜利后退出应用新密码登录 ...

作者：赵拂晓爱可生 MySQL DBA 团队成员，Oracle 10g OCM，MySQL 5.7 OCP，善于数据库性能问题诊断、事务与锁问题的剖析等，负责解决客户 MySQL 及我司自研 DMP 平台日常运维中的问题，对开源数据库相干技术十分感兴趣。 本文起源：原创投稿 * 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 背景该问题来自某客户，据形容，他们在部署 MySQL 主从复制时，有时候仅在主库上创立复制用户，有时候主从实例上都会去别离创立复制用户，发现这两种形式都能够胜利建设复制。针对这一景象，进行了一轮验证，来察看采纳不同形式创立复制用户对主从复制的影响。 通常来说，用得较多的形式是在搭建主从复制前，先在主库创立好复制用户，而后做一个 Xtrabackup 物理全备，再拿到从库上复原并搭建主从。除此以外，还有哪些形式呢？别离对主从复制有哪些影响？一起来看一下。 验证MySQL 版本为 5.7.32，主库：10.186.60.62，从库：10.186.60.68。为了演示不便，本次搭建主从复制时均采纳 mysqldump 进行逻辑备份。场景 1：仅在主库创立复制用户1.主库做一个备份并拷贝到从库 /usr/local/mysql5732/bin/mysqldump --single-transaction --master-data=2 -B zlm -S /tmp/mysql3332.sock -p > zlm.sqlscp zlm.sql root@10.186.60.68:~2.登陆从库执行导入 mysql> source zlm.sql因为没有应用参数 --set-gtid-purged=off，导出的语句中会带有 SET @@GLOBAL.GTID_PURGED='xxxx:1-xx' 并执行，导入前须要先在从库上执行 reset master。 3.主库创立复制用户 mysql> create user repl1 identified by 'repl1';4.从库配置主从复制并启动 mysql> change master to master_host='10.186.60.62',master_port=3332,master_user='repl1',master_password='repl1',master_auto_position=1;mysql> start slave; 启动复制后，报了 Error 1045 的谬误，此处并不是明码错，而是没有给复制用户配置 replication slave 权限，在主库上对 repl1 用户执行赋权后（grant replication slave on *.* to repl1;），再启动复制就失常了。 ...

场景： Master1Master2multi-slavehost:port192.168.9.78:4001testdba-mysql56.rdsm2wctkd8fa14.rds.bj.baidubce.com:3306192.168.9.144:5000uuidb3ac499d-6662-11e9-be7e-0050568776071e345bf9-32a4-11ea-b269-fa163ee300838ef26d45-82df-11ea-85b4-00505687de1b复制的dbSlavedb01dba_test01 问题1：跳过某个channel的报错1、gtid模式形式1：stop slave for channel 'master_mysql9784001'; set gtid_next='b3ac499d-6662-11e9-be7e-005056877607:10';begin;commit;set gtid_next='automatic';start slave for channel 'master_mysql9784001'; show slave status\G形式2：(代价太大，个别不采纳)(1) 查看报错的channel的已执行的地位点--查看报错的channel的已执行的地位点Retrieved_Gtid_Set: b3ac499d-6662-11e9-be7e-005056877607:2-9Executed_Gtid_Set: 1e345bf9-32a4-11ea-b269-fa163ee30083:1-2224,8ef26d45-82df-11ea-85b4-00505687de1b:1,b3ac499d-6662-11e9-be7e-005056877607:1-7(2) 进行所有的slave复制, 查看并纪录曾经执行的gtid的地位--进行所有的slave复制stop slave;--查看并纪录曾经执行的gtid的地位show master status; *************************** 1. row *************************** File: mysql-bin.000001 Position: 422144 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 1e345bf9-32a4-11ea-b269-fa163ee30083:1-2320,8ef26d45-82df-11ea-85b4-00505687de1b:1,b3ac499d-6662-11e9-be7e-005056877607:1-7(3) 从新设置gtid的点--从新设置gtid的点reset master;set @@GLOBAL.GTID_PURGED="1e345bf9-32a4-11ea-b269-fa163ee30083:1-2320,b3ac499d-6662-11e9-be7e-005056877607:1-8";(4) 开启复制start slave;show slave status; --报错的channel曾经恢复正常2、filepos模式：进行要跳过的channel，上面是不应用gtid模式的步奏 --步骤：1. mysql> stop slave for channel 'channel name';2. mysql> set global sql_slave_skip_counter=1;3. mysql> start slave for channel 'channel name';--如果进行start slave;则会报错:ERROR 3086 (HY000): When sql_slave_skip_counter> 0, it is not allowed to start more than one SQLthread by using 'START SLAVE [SQL_THREAD]'. Value ofsql_slave_skip_counter can only be used by one SQL thread at atime. Please use 'START SLAVE [SQL_THREAD] FOR CHANNEL' to startthe SQL thread which will use the value ofsql_slave_skip_counter.通过下面报错可知,每一个sql_slave_skip_counter 只能实用一个sqlthread 线程问题2：上游master2进行了主从切换1、gtid模式无需人为接入，同步不会报错，主动获取新的master的gtid ...

Linkis 1.0.0-RC1 是 Linkis 里程碑式的重大版本，提供了超 60 个新个性和性能加强， 标记着 Linkis 正式进入1.0版本时代。 Linkis 是什么？ Linkis 在下层利用和底层引擎之间构建了一层计算中间件，下层利用只需对接 Linkis 提供的 REST/WS/JDBC 等标准接口，就能连贯到 MySQL/Spark/Hive/Presto/Flink 等各种底层计算存储引擎，并实现下层利用间的互通。 Linkis1.0.0-RC1 带来了“计算治理”理念的全新架构实现，提供了全栈计算/存储引擎的架构反对，包含离线批量型、交互式型、实时流式型和存储型，并新增了多种新个性，向下兼容 Linkis0.X 版本的所有接口。 开源地址 https://github.com/WeBankFinT... https://gitee.com/WeBankFinTe... 新版简介 丰盛的底层计算存储引擎反对度已反对的计算存储引擎：Spark、Hive、Python、Presto、ElasticSearch、MLSQL、TiSpark、JDBC和Shell等；集成中的计算存储引擎：Flink、Impala和Clickhouse等；已反对的脚本语言：SparkSQL、Scala、Pyspark、R、Python、JDBC、HiveQL和Shell等。弱小的计算治理能力Linkis 1.0总体分为三大模块：公共加强服务、计算治理服务、微服务治理服务。三大模块简介如下： 公共加强服务为Linkis 0.X曾经提供的物料库服务、上下文服务、数据源服务和公共服务等；微服务治理服务为Linkis 0.X曾经提供Spring Cloud Gateway、Eureka和Open Feign，同时 Linkis1.0还会提供对Nacos的反对；计算治理服务是Linkis 1.0的外围重点，从 提交 —> 筹备 —> 执行三个阶段，来全面降级Linkis 对 用户工作的执行管控能力。全栈计算存储引擎架构反对作为计算中间件，将接管、执行和治理针对各种计算存储引擎的工作和申请，包含离线批量型、交互式型、实时流式型和存储型工作，并提供弱小的复用、预热、限流、切换、全生命周期治理等计算治理能力； 更弱小的资源管理能力ResourceManager不仅具备Linkis0.X对Yarn和Linkis EngineManager的资源管理能力，还将提供基于标签的多级资源分配和回收能力，让ResourceManager具备跨集群、跨计算资源类型的弱小资源管理能力； 全流程标签化基于多级组合标签，提供跨IDC、跨集群的计算工作路由管控能力，和EngineConnManager, EngineConn的多租户隔离能力； 对立上下文服务对立用户和系统资源文件（JAR、ZIP、Properties等），跨用户、零碎、计算引擎的参数和变量对立治理，一处设置，处处主动援用； 对立物料零碎和用户级物料治理，可分享和流转，跨用户、零碎共享物料，反对全生命周期主动治理。 全新个性 [Linkis-572] 在“Entrance”模块中新增了EngineConn治理插件。 [Linkis-576] 新增EngineConnPlugin模块，简化用户实现Linkis新计算存储引擎。 [Linkis-579] 新增EngineConn的交互式类型顶层设计，让用户实现交互式引擎更加简略容易。 [Linkis-584]新增LinkisManager Common模块，为LinkisManager提供常用工具类。 [Linkis-585]新增LinkisManager Monitor模块，用于LinkisManager实时监控EngineConn和EngineConnManager的衰弱状态。 [Linkis-587] 新增EngineConn Common模块，为EngineConn提供常用工具类。 [Linkis-590] 新增EngineConn的外围模块，提供了EngineConn外围接口的定义。 [Linkis-591] 新增Computation Governance Common模块，为计算治理的所有服务提供常用工具类。 ...

含糊查问LIKE 操作符用于在 WHERE 子句中搜寻列中的指定模式。 能够和通配符（%、_）配合应用，其中"%"示意0或多个任意的字符,"_"示意一个任意的字符。 语法：SELECT 列 | * FROM 表名 WHERE 列名 LIKE 值 示例： -- 25.查问emp表中姓名中以"刘"字结尾的员工，显示员工姓名。 -- 姓名中的第一个字必须是'刘',前面的都无所谓 select name from emp where name like '刘%';-- 26.查问emp表中姓名中蕴含"涛"字的员工，显示员工姓名。 -- '%涛%'蕴含: 以'涛'结尾,以'涛'结尾,或者'涛'在两头的某一个地位 select name from emp where name like '%涛%';-- 27.查问emp表中姓名以"刘"结尾，并且姓名为两个字的员工，显示员工姓名。 -- '刘_'示意以'刘'结尾,并且姓名长度为2 ```select name from emp where name like '刘_';`-- '刘__'示意以'刘'结尾,并且姓名长度为3 select name from emp where name like '刘__';多行函数查问多行函数也叫做聚合(汇集)函数，依据某一列或所有列进行统计。 常见的多行函数有： 多行函数 作用 COUNT( 列名 | * ) 统计后果集中指定列的记录的行数。 MAX( 列名 ) ...

咱们所有的查问语句，MySQL 都会为其抉择一个最合适的执行打算。这个执行打算就展现了接下来执行查问的具体形式。在日常工作中咱们能够在 SQL 语句后面加上 EXPLAIN 关键字来查看具体的执行打算。 举个例子： 这种就是咱们日常用到 EXPLAIN 看到的最间接后果，也是这个查问语句最终的执行打算。 执行打算输入中各列详解这个笔记就是用来解释这个执行打算中的各个列别离对应的是什么意思。不过在整顿具体之前，先简明扼要的说一下每个字段的具体含意： 列名形容备注id在一个大的查问中，每个 SELECT 对应一个惟一的 idid 小的先执行select\_typeSELECT 关键字对应的查问类型连贯查问和子查问的时候才有用partitions匹配的分区信息type针对单表的拜访形式咱们最罕用的字段possible\_Keys可能用到的索引key理论应用的索引key\_len理论应用的索引长度ref当应用索引列等值查问时，与索引列等值匹配的对象信息rows预估的须要读取的记录条数filtered针对预估的须要读取的记录，通过搜寻条件过滤后残余记录条数的百分比rows 和 filtered 在判断连贯查问的扇出的时候，是一个十分重要的判断指标。Extra一些额定的信息重点id 列通常来说一个查问语句都有一个或多个 SELECT ，在执行打算中每一个 SELECT 都会被独自调配一个 id。为不便了解，咱们举几个简略的例子： 这种单表等值查问，不言而喻的只有一个 SELECT 而且实际上也只拜访了一张表，所以上面的 id 只有一个是 1。这种状况下其实咱们是无奈判断这个 id 到底是因为 SELECT 关键字独自调配的，还是依据表独自调配的。所以这里，咱们须要再来看一个连贯的查问的状况。这里其实无论是内查问还是外查问都是一样的，我在这里举了一个外查问的例子。 从后果上咱们能够看到，这里有两个表别离是 s1 和 s2，然而他们还是只调配了同样的 id，这样就能够证实 id 列的值是依据 SELECT 调配的了吗？本着不试不爽的态度，咱们再来看一个 UNION 子句的状况。 从下面这三个例子中，咱们就能够证实执行打算中每一个 SELECT 都会被独自调配一个 id。置信在看 UNION 这个例子的执行打算中，你或者感到一点奇怪。为什么我这是两个表的查问后果的 UNION ，怎么在执行打算中呈现了第三行，而且这一行还这么奇怪，id 是 NULL？ 这个其实是一个外部的长期表，MySQL 为了让 id 为 1 和 2 的数据进行去重，他应用的是外部长期表，MySQL 在外部创立了一个名为 <union1,2> 的长期表。id 为 null 是示意这个表是长期的。 ...

上篇回顾继上两篇： MySQL慢查问（上）：你晓得为啥会慢么？MySQL慢查问（中）：正确的解决姿态，你get到了吗？在以上两篇内容中，咱们一起摸索了这些内容： SQL执行过程查问SQL为什么会慢如何定位查问问题几种实用解决方案介绍如果将MySQL慢查问作为一个问题来拆解剖析的话，之前上、中篇章算是问题剖析、问题定位和解决，那明天来跟大家收下尾，聊聊MySQL慢查问问题解决经验总结。 问题解决流程 废话不多说，间接开干~ 高性能查问难题优化总结咱们来总结一下，应该如何解决高性能查问难题？ 如果把高性能查问比作一个“难题”，它其实是包含多个子难题在内，独特作用的后果。 明天咱们来演绎总结下，次要包含以下几类： 1 数据结构优化良好的schema设计准则是广泛实用的，然而MySQL有他本人的实现细节要留神，详情来讲，尽可能放弃任何货色小而简略总是好的。 次要有以下简略的准则值得你去思考应用： 尽量避免适度设计应用小而简略的适合数据类型，尽可能防止应用null尽量应用雷同的数据类型存储类似或者相干的值留神可变长字符串，其在长期表和排序时可能按最大长度分配内存尽量应用整形定义标识符 2 索引设计优化常见的B-Tree索引，依照顺序存储数据，所以MySQL能够用来做ORDER BY 和 GROUP BY操作。因为数据是有序的，所以便于将相干的列值都存储在一起。因为索引中存储了理论的列值，所以一些查问只通过索引就可能实现查问（如：聚簇索引）。 依据索引的个性，总结索引的长处有如下几点： 缩小服务器须要扫描的数据量；帮忙服务器防止排序和长期表；将随机I/O变为程序I/O。编写查问语句时候应该留神尽可能抉择适合的索引，以防止单行查找，尽可能应用索引笼罩。 依据执行打算顺次扫描相干表中的行，不在数据缓冲区的走IO存储引擎扫描表的性能耗费参考上面的list，耗费从大到小： 全表扫描>全索引扫描>局部索引扫描>索引查找>惟一索引/主键查找>常量/null 利用查问优化是建设在良好的数据结构和正当的索引设计之上的。 它次要包含以下几种状况： 3.1 重构查问形式 优化慢查问时，指标应该是找到一个更优的计划来达到咱们获取后果数据的目标。其中能够存在多样的衡量计划： 1）从数据库中查问计算间接获取到后果数据； 2）拆分多条子查问来逐渐失去后果数据； 3）从数据库获取到根底数据，而后利用代码逻辑加工后取得后果数据。 3.2 让SQL尽量合乎查问优化器的执行要求 MySQL 查问优化器并不是对所有查问都实用的，咱们能够通过改写查问 SQL 来让数据库更高效地实现工作。 常见查问利用优化倡议汇总如下： 1）对于任何查问，应尽量避免全表扫描 首先应思考在 where 及 order by 波及的列上建设并利用索引； 2）尽量避免在 where 子句中进行操作 应用 or 来连贯条件、对字段进行 null 值判断、匹配查问 '%abc%'、!= 或 <> 操作符，否则将导致引擎放弃应用索引而进行全表扫描； 3）尽量利用索引 应用索引字段作为条件时，如果是复合索引，那么必须应用到该索引中的第一个字段作为条件时能力保证系统应用该索引，否则该索引将不会被应用，并且应尽可能的让字段程序与索引程序相一致； 4）索引字段要留神谨慎选取 索引尽量避开区分度不大的字段，如：sex、male、female 这种五五开的索引列有大量数据反复时，那么即便在 sex 上建了索引也对查问效率起不了作用。 5）一个表的索引数最好不要超过 6 个 索引并不是越多越好，索引诚然能够进步相应的 select 的效率，但同时也升高了 insert 及 update 的效率， 因为 insert 或 update 时有可能会重建索引，所以怎么建索引须要慎重考虑，视具体情况而定。 ...

上篇回顾继上篇：MySQL慢查问（上）：你晓得为啥会慢么？ 在上一篇内容中，咱们一起摸索了这些内容： SQL执行过程查问SQL为什么会慢通过梳理 MySQL中的 SQL执行过程咱们发现，任何流程的执行都存在其执行环境和规定，次要导致慢查问最基本的问题就是须要拜访的数据太多，导致查问不可避免的须要筛选大量的数据。 如果将MySQL慢查问作为一个问题来拆解剖析的话，上一篇算是问题剖析，那明天来跟大家聊聊问题定位和问题解决。 问题解决流程 本文次要内容包含： 1、如何定位问题呢？ 2、几种实用解决方案 废话不多说，间接开干~ 1、如何定位问题呢？发现了慢查问之后，对于如何定位问题产生起因，最罕用的办法就是利用EXPLAIN关键字模仿查问优化器执行查问SQL，从而晓得MySQL是如何解决你的查问SQL，通过执行打算来剖析性能瓶颈。 通常咱们应用EXPLAIN，会失去如下下的执行打算信息： 对于各字段含意，大家能够通过检索自行理解，在此就不再过多赘述。对于定位剖析问题，要害看如下几点： 1）select_type 示意查问类型，用于区别一般查问、联结查问、子查问等简单查问。 2）type 显示查问应用类型，从好到差顺次为：system > const > eq_ref > ref > range > index > all 3）possible_keys 和 key 别离指可能利用的索引和理论利用的索引。 留神：查问中若应用了笼罩索引（select 后要查问的字段刚好和创立的索引字段完全相同），则该索引仅呈现在key列表中。 4）rows 大抵估算出找到所需记录所须要读取的行数（从效率上来讲，数值越小越好） 5）Extra 重要的额定信息。蕴含MySQL解决查问的详细信息，也是要害参考项之一。 2、几种实用解决方案咱们通过EXPLAIN关键字模仿查问优化器执行查问SQL，发现了慢查问问题起因，那看看如何能力无效解决呢？ 举荐几种较为实用的解决方案给大家。 2.1 优化数据结构2.1.1 抉择索引的数据类型MySQL反对很多数据类型，抉择适合的数据类型存储数据对性能有很大的影响。 通常来说，能够遵循以下一些领导准则： (1)越小的数据类型通常更好：越小的数据类型通常在磁盘、内存和CPU缓存中都须要更少的空间，解决起来更快。 (2)简略的数据类型更好：整型数据比起字符，解决开销更小，因为字符串得比拟更简单。在MySQL中，应该用内置的日期和工夫数据类型，而不是用字符串来存储工夫；以及用整型数据类型存储IP地址。 (3)尽量避免NULL：应该指定列为NOT NULL，除非你想存储NULL。在MySQL中，含有空值的列很难进行查问优化，因为它们使得索引、索引的统计信息以及比拟运算更加简单。你应该用0、一个非凡的值或者一个空串代替空值。 2.1.2 范式与反范式范式化范式化模型要求满足上面三大范式： 1）数据库表中每个字段只蕴含最小的信息属性，不能再进行细化合成； 2）（在满足1的根底上）模型含有主键，非主键字段依赖主键； 比方用户这个模型，它的主键是用户ID，那么用户模型其它字段都应该依赖于用户ID如商品ID和用户没有间接关系，则这个属性不应该放到用户模型而应该放到“用户-商品”两头表。 3）（在满足2的根底上）模型非主键字段不能相互依赖。 订单表(订单编号，订购日期，顾客编号，顾客姓名，……)初看该表没有问题，满足第二范式，每列都和主键列”订单编号”相干。 再细看你会发现“顾客姓名”和“顾客编号”相干，“顾客编号”和“订单编号”又相干，最初通过传递依赖，“顾客姓名”也和“订单编号”相干。 为了满足第三范式，应去掉“顾客姓名”列，放入客户表中。 反范式化反范式化模型即不满足范式化的模型。次要是为了性能和效率的思考适当的违反范式化设计要求，容许存在大量的数据冗余，即以空间换工夫。 小结可见一个良好而实用的数据模型往往是依赖于具体的需要场景的，在设计数据模型之前，仔细分析需要场景，不仅能提高效率，也能无效躲避前期可能遇到的一些意外麻烦。 范式化设计和反范式化设计的优劣比照如下： 1、范式化能够尽量的缩小数据冗余 2、范式化的更新操作比反范式化更快 3、范式化的表通常比反范式化的表要小 4、反范式化缩小表的关联 5、反范式化相比范式化能够更好地对索引进行优化，例如应用笼罩索引。 ...

 大家好，我是为宽广程序员兄弟操碎了心的小编，每天举荐一个小工具/源码，装满你的收藏夹，每天分享一个小技巧，让你轻松节俭开发效率，实现不加班不熬夜不掉头发，是我的指标！ 明天小编举荐一款Mybatis加强工具包——mybatis-plus，在MyBatis的根底上只做加强不做扭转，为简化开发、提高效率而生。只有能应用mybatis进行crud，并且反对规范sql的数据库都能应用此工具。 开源协定 应用 Apache-2.0 开源许可协定 链接地址 公众号【Github导航站】回复关键词【myb】获取git地址 个性无侵入：只做加强不做扭转，引入它不会对现有工程产生影响，如丝般顺滑损耗小：启动即会主动注入根本 CURD，性能根本无损耗，间接面向对象操作弱小的 CRUD 操作：内置通用 Mapper、通用 Service，仅仅通过大量配置即可实现单表大部分 CRUD 操作，更有弱小的条件结构器，满足各类应用需要反对 Lambda 模式调用：通过 Lambda 表达式，不便的编写各类查问条件，无需再放心字段写错反对主键主动生成：反对多达 4 种主键策略（内含分布式惟一 ID 生成器 - Sequence），可自在配置，完满解决主键问题反对 ActiveRecord 模式：反对 ActiveRecord 模式调用，实体类只需继承 Model 类即可进行弱小的 CRUD 操作反对自定义全局通用操作：反对全局通用办法注入（ Write once, use anywhere ）内置代码生成器：采纳代码或者 Maven 插件可疾速生成 Mapper 、 Model 、 Service 、 Controller 层代码，反对模板引擎，更有超多自定义配置等您来应用内置分页插件：基于 MyBatis 物理分页，开发者无需关怀具体操作，配置好插件之后，写分页等同于一般 List 查问分页插件反对多种数据库：反对 MySQL、MariaDB、Oracle、DB2、H2、HSQL、SQLite、Postgre、SQLServer 等多种数据库内置性能剖析插件：可输入 Sql 语句以及其执行工夫，倡议开发测试时启用该性能，能疾速揪出慢查问内置全局拦挡插件：提供全表 delete 、 update 操作智能剖析阻断，也可自定义拦挡规定，预防误操作框架结构 结尾 本期就分享到这里，我是小编南风吹，专一分享好玩乏味、离奇、实用的开源我的项目及开发者工具、学习资源！心愿能与大家独特学习交换，欢送关注我的公众号【Github导航站】。

数据库概述什么是数据库？所谓的数据库就是指存储和治理数据的仓库 扩大内容1：数据库有哪些分类？(理解) 晚期: 档次式数据库、网络型数据库当初：关系型数据库、非关系型数据库 什么是关系型数据库？底层以二维表的模式保留数据的库就是关系型数据库 stu-学生表 扩大内容2：常见的关系型数据库有哪些？(理解) Sql Server：微软提供，免费，实用于一些中型或大型的我的项目中，在java中的应用占比不高（.NET中应用的较多）Oracle：甲骨文公司提供，免费，实用于一些大型或者超大型的我的项目中，在java中的应用占比十分高mysql：瑞典MySQLAB公司提供，收费开源，实用于一些小型或者中型的我的项目中，在Java中的应用占比拟高（玲珑轻量） mariadb其实就是MySQL的一个分支，用法和MySQL齐全一样。DB2：IBM公司提供，免费，在一些银行、金融等行业中应用较多。在java中的应用占比也不高。Sqlite：迷你数据库，嵌入式设施中（安卓、苹果手机、pad）...数据库相干概念1、什么是数据库服务器 数据库服务器就是一个软件（比方mysql软件）将数据库软件装置在电脑上，以后电脑就是一个数据库服务器。就能够对外提供存取数据的服务 在一个数据库服务器中能够创立多个数据库（dataBases），每一个数据库都是一个独自的仓库。 2、什么是数据库 数据库就是存储和治理数据的仓库，通常状况下，一个网站的中的所有数据会寄存在一个数据库中。例如： jd.com db_jd(数据库)taobao.com db_taobao(数据库)... 3、什么是表 一个数据库中能够创立多张表，每张表用于存储一类信息（数据库），例如： jd.com中的用户数据 tb_user(表) jd.com中的商品数据 tb_product(表) jd.com中的订单数据 tb_order(表) ... 4、什么表记录 一张表中能够蕴含多行表记录，每一行表记录用于存储某一个具体的数据 什么是SQL语言？SQL是一门用于操作关系型数据库的通用的语言（应用SQL能够操作所有的关系型数据库） 应用SQL能够操作数据库、表、表记录 (1)创立数据库、删除数据库、批改数据库、查询数据库 (2)创立表、删除表、批改表、查问表 (3)新增表记录、删除表记录、批改表记录、查问表记录 应用SQL也能够操作存储过程/视图/索引等。 提醒：SQL是一个规范通用的操作关系型数据库的语言（普通话），每个数据库厂商为了加强本人数据库的性能，都提供了反对本人数据库的语言，称之为数据库的方言。方言不通用！ 连贯mysql服务器通过命令行工具能够登录MySQL客户端，连贯MySQL服务器，从而拜访服务器中的数据。 1、连贯mysql服务器： mysql -uroot -p明码 -u：前面的root是用户名，这里应用的是超级管理员root； -p：(小写的p)前面的root是明码，这是在装置MySQL时就曾经指定的明码； 2、连贯mysql服务器并指定IP和端口: mysql -uroot -proot -h127.0.0.1 -P3306-h：前面给出的127.0.0.1是服务器主机名或ip地址，能够省略的，默认连贯本机； -P：(大写的P)前面的3306是连贯端口，能够省略，默认连贯3306端口； 3、退出客户端命令：quit或exit或 q4、FAQ：常见问题解决办法：复制mysql装置目录下的bin目录的门路，将bin目录的门路增加到path环境变量中!!能够在cmd中通过 echo %path% 查看path环境变量的值。扩大内容3： (1)在cmd中连贯mysql服务器之后，能够应用 #、/**/、-- 等符号增加正文，例如: (2)在cmd中连贯mysql服务器之后，在书写SQL语句时，能够通过 c 勾销以后语句的执行。例如： 数据库及表操作创立、删除、查看数据库提醒： (1)SQL语句对大小写不敏感。举荐关键字应用大写，自定义的名称（库名，表名，列名等）应用小写。 SHOW DATABASES; -- 查看以后数据库服务器中的所有库CREATE DATABASE mydb1; -- 创立mydb1库(2)并且在自定义名称时，针对多个单词不要应用驼峰命名，而是应用下划线连贯。(例如：tab_name，而不是 tabName ) ...

此文来自课程《MySQL外围问题32讲》，聚焦MySQL面试过程中的常见问题，由阿里资深P7工程师倾情研发。 导读首先，在设计用户核心零碎的数据库时，我先创立一张用户根底表user，如下： `CREATE TABLE user ( id int(11) unsigned NOT NULL AUTO_INCREMENT, user_id int(8) DEFAULT NULL COMMENT '用户id', user_name varchar(29) DEFAULT NULL COMMENT '用户名', user_introduction varchar(498) DEFAULT NULL COMMENT '用户介绍', sex tinyint(1) DEFAULT NULL COMMENT '性别', age int(3) DEFAULT NULL COMMENT '年龄', birthday date DEFAULT NULL COMMENT '生日', PRIMARY KEY (id)) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;`该表所有字段都加了备注阐明，大家应该能够分明地明确每个字段的含意。同时，我再插入8条记录，如下： INSERT INTO `user` (`id`, `user_id`, `user_name`, `user_introduction`, `sex`, `age`, `birthday`)VALUES (1, 10001, 'Jack', 'I'm Jack', 1, 25, '1998-01-02'), (2, 10002, 'Nancy', 'I'm Nancy', 0, 15, '2008-02-03'), (3, 10003, 'Bruce', 'I'm Bruce', 1, 17, '2006-03-03'), (4, 10004, 'John', 'I'm John', 1, 18, '2005-03-05'), (5, 10005, 'Amy', 'I'm Amy', 0, 15, '2008-02-06'), (6, 10006, 'Lucy', 'I'm Lucy', 0, 16, '2007-06-06'), (7, 10007, 'Mike', 'I'm Mike', 1, 17, '2006-07-01'), (8, 10008, 'Henry', 'I'm Henry', 1, 16, '2007-06-07');而后，我创立一个联结索引index_age_birth，如下： ...

背景随着互联网的疾速倒退，开发软件越来越考究效率，无论是各种跨端框架如：electron uni-app，还是近期比拟炽热服务端的serverless，都是随同着这个趋势而生。 疾速开发后盾事实上后盾在开发中存在大量的反复的工作，有些程序员甚至自嘲是crud(增删改查)开发者。cool团队原先在开发软件的时候也碰到了相似的问题。刚好随同着阿里巴巴团midway2.0的公布。它是一个既能够开发一般利用，又能够将利用公布打包公布部署为serverless。咱们在此基础上封装了一个疾速开发后盾的框架cool-admin。 疾速开发定义一个表/** * 商品 */@EntityModel('demo_app_goods')export class DemoAppGoodsEntity extends BaseEntity { @Column({ comment: '题目' }) title: string; @Column({ comment: '图片' }) pic: string; @Column({ comment: '价格', type: 'decimal', precision: 5, scale: 2 }) price: number;}编写接口import { Provide } from '@midwayjs/decorator';import { CoolController, BaseController } from 'midwayjs-cool-core';import { DemoAppGoodsEntity } from '../../entity/goods';/** * 商品 */@Provide()@CoolController({ api: ['add', 'delete', 'update', 'info', 'list', 'page'], entity: DemoAppGoodsEntity})export class DemoAppGoodsController extends BaseController { /** * 其余接口 */ @Get('/other') async other() { return this.ok('hello, cool-admin!!!'); }}这样咱们就实现了6个接口的编写，对应的接口如下： ...

登录（root用户，而后输出明码）： mysql -u root -p 显示所有数据库： show databases; 应用哪个数据库： use wordpress; 显示以后数据库下的所有表： show tables; 限度显示条数的查问： select * from wp_options limit 10; 条件查问： select * from wp_options where option_id = '1'; 含糊查问（必须联合%（任意字符），不然跟=成果一样）： select * from wp_options where option_value like 'http%'; 表字段查问： show columns from wp_postmeta;// ordescribe wp_postmeta;依据id查问某个表的某个字段：select post_title from wp_posts1 where id = 42; 更新： update wp_users SET user_email='xx@qq.com'; 替换更新：（批改user_email字段，把qq.com替换为weixin.com） update wp_users SET user_email=replace(user_email, 'qq.com', 'weixin.com'); 更新操作，肯定要谨慎。最好先备份再update。不然肯定要看清楚。另一个就是加上binlog，以便回滚。 备份：mysqldump -uroot -p -B wordpress > /var/www/mysqlbackup/xxx.sql ...

cool-admin(midway版)一个很酷的后盾权限管理系统，开源收费，模块化、插件化、极速开发CRUD，不便疾速构建迭代后盾管理系统，反对serverless、docker、一般服务器等多种形式部署 开源地址后端https://github.com/cool-team-... https://gitee.com/cool-team-o... 前端https://github.com/cool-team-... https://gitee.com/cool-team-o... 技术栈后端：node.js midway.js egg.js mysql typescript前端：vue.js element-ui jsx vuex vue-router如果你是前端，后端的这些技术选型对你是特地敌对的，前端开发者能够较疾速地上手。如果你是后端，Typescript的语法又跟java、php等特地相似，所有看起来也是那么得相熟。 演示https://show.cool-admin.com 账户：admin明码：123456 文档https://admin.cool-js.com 我的项目前端https://github.com/cool-team-official/cool-admin-vue QQ群2群：539478405 微信群 微信公众号 运行批改数据库配置，配置文件位于src/config/config.local.ts数据库为mysql(>=5.7版本)，首次启动会主动初始化并导入数据 config.orm = { type: 'mysql', host: '127.0.0.1', port: 3306, username: 'root', password: '', database: 'cool-admin', synchronize: true, logging: true,}装置依赖并运行$ npm i$ npm run dev$ open http://localhost:8001/注： 如果你的网络不佳能够尝试应用cnpm，或者切换您的镜像源 CURD(疾速增删改查)大部分的后盾管理系统，或者API服务都是对数据进行治理，所以能够看到大量的CRUD场景(增删改查)，cool-admin对此进行了大量地封装，让这块的编码量变得极其地少。 新建一个数据表src/modules/demo/entity/goods.ts，我的项目启动数据库会主动创立该表，无需手动创立 import { EntityModel } from '@midwayjs/orm';import { BaseEntity } from 'midwayjs-cool-core';import { Column } from 'typeorm';/** * 商品 */@EntityModel('demo_app_goods')export class DemoAppGoodsEntity extends BaseEntity { @Column({ comment: '题目' }) title: string; @Column({ comment: '图片' }) pic: string; @Column({ comment: '价格', type: 'decimal', precision: 5, scale: 2 }) price: number;}编写api接口src/modules/demo/controller/app/goods.ts，疾速编写6个api接口 ...

一、具体报错信息：mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table xxx at row: 258609 二、起因：网上看了下，大略说在mysqldump的时候，因为数据量太大，一次性接管不了那么多数据，所以server端发送过去的数据会积压在内存期待发送，这个等待时间就是net_write_timeout的工夫。当超过了该工夫，则会断开mysqldump的连贯，同时抛出谬误：error 2013: Lost connection。 三、解决形式：网上大部分说批改net_write_timeout工夫即可。比方改为1200。操作过程：1 先登录mysql：mysql -u root -p2 先查看默认工夫：show global variables like '%timeout%'3 批改工夫：set global net_write_timeout = 12004 能够再次查看下是否已扭转：show global variables like '%timeout%'5 退出mysql，再次执行mysqldump：mysqldump -uroot -p -B monitor> /var/www/mysqlbackup/db.xxx.sql 下面操作过程，不必重启mysql。可能是退出mysql后肯定工夫内，这个值不会被重置回默认值。切实不行，可重启试试：service mysqld restart 另外，这个net_write_timeout工夫，最好在操作完mysqldump后改回去默认值。

起因时区问题，MySQL驱动默认UTC时区。MySQL驱动中默认时区是UTC，与本地工夫（中国）相差八个小时，所以链接不上. 能够用两种办法解决，都是解决时区问题。 一、点开最右侧 Advanced，找到 serverTimezone，在右侧value处填写 GMT，保留即可！(或填写 Asia/Shanghai) 也能够在url后增加：?serverTimezone=GMT 备注：GMT（Greenwich Mean Time）：格林威治规范工夫UTC：世界规范工夫CST（China Standard Time）：中国规范工夫GMT + 8 = UTC + 8 = CST

应用 springboot 2.4.0，OpenJDK 11背景软删除机制软删除 是一种删除数据的做法，每当须要删除数据时，业务不调用 SQL 的 DELETE 语句，而是把 SQL 的某个 field 标记为已删除，如 is_deleted = 1 或 status = 'DELETED' 软删除的劣势是不是实在删除这条记录，便于当前审计或者复原这条数据等软删除也是有毛病的，其中一个就是导致某些字段不能应用 Unique Key 我的项目假如以后有我的项目【会籍治理】，其中包含 member_no 字段， 当 status != 'DELETED' 时, member_no 不能够反复；当 status == 'DELETED' 时, member_no 能够反复。 有缺点的计划假如 member_no 要设为 100并发极低的场景在我的项目晚期，咱们认为记录的并发量不高，所以在同一个事务中，先查看 member_no有没有被占用，如果没有，则执行插入或更新操作，SQL 如下： 建表： CREATE TABLE membership( id bigint auto_increment primary key, member_no int not null, status enum('NORMAL', 'DELETED') not null)查问、插入、更新、删除 SQL： SELECT COUNT(*) FROM membership WHERE member_no = 100UPDATE membership SET member_no=100 WHERE id = 1INSERT INTO membership (member_no, status) VALUES (100, 'NORMAL')UPDATE membership SET status='DELETED' WHERE id = 1然而因为 SELECT + UPDATE/INSERT 在高并发的场景下，有可能呈现 A1 B1 B2 A2 的状况，如下图，所以不是稳当的做法 ...

MySQL内建的复制性能是构建基于MySQL的大规模、高性能利用的根底，这类利用应用所谓的“程度扩大”的架构。咱们能够通过为服务器配置一个或多个备库的形式来进行数据同步。复制性能不仅有利于构建高性能的利用，同时也是高可用性、可扩展性、劫难复原、备份以及数据仓库等工作的根底。 概述复制解决的根本问题是让一台服务器的数据与其余服务器放弃同步。一台主库的数据能够同步到多台备库上，备库自身也能够被配置成另外一台服务器的主库。主库和备库之间能够有多种不同的组合形式。 实用场景横向扩大横向扩大是指在多个从库之间进行读负载平衡，以进步读性能。在此扩大计划中，所有数据变更在主库上执行，读负载能够摊派到一个或者多个从库上。 数据安全数据安全性在很大水平上须要靠数据副原本保障。在这里，正本能够了解为咱们通常所说的备份。 数据分析在主库上运行OLTP（联机事务处理）利用，而OLAP（联机剖析解决）利用能够在从库上运行，防止在主库上运行OLAP利用对主库性能造成影响。 近程数据散发能够应用复制个性为近程站点创立数据的本地正本，那些对数据实时性没有要求的利用能够拜访本地正本，剩下的一小部分对实时性有要求的利用拜访主库。近程站点既能够作为灾备核心，也能够用于实现跨地区拜访以摊派负载，以及实现就近拜访，放慢访问速度。 滚动降级应用一个更高版本的MySQL作为备库，保障在降级全副实例前，查问可能在备库依照预期执行。 高可用性和故障切换复制可能帮忙应用程序防止MySQL单点失败，一个蕴含复制的设计良好的故障切换零碎可能显著地缩短宕机工夫。 复制形式MySQL反对以下两种数据同步办法： 传统复制：也能够称为基于二进制日志文件和地位的复制，在从库中配置复制时，要求指定从主库中获取的二进制日志文件（binlog file）和地位（binlog position），以便从库中的复制线程启动时，可能以指定的二进制日志文件和地位为终点，继续读取主库中的二进制日志，并在从库中利用，从而达到数据同步的目标。基于GTID的复制：GTID（全局事务标识符）是新的事务性复制办法，利用GTID能够主动在主库中寻找须要复制的二进制日志记录，因而不须要关怀日志文件或地位，极大地简化了许多常见的复制工作。应用GTID复制可确保主库和从库之间的一致性。。同步类型MySQL反对如下4种不同类型的数据同步： 异步复制：最早呈现的复制技术，MySQL内置反对，不须要额定装置插件。其中，一个实例充当主库，一个或多个其余实例充当从库，与同步复制造成比照。半同步复制：从MySQL 5.5开始反对半同步复制。应用半同步复制时，主库的会话在提交事务之前，会期待至多一个从库返回收到二进制日志的ACK音讯（确认接管，并将事务的事件记录到从库的中继日志中）。提早复制：从MySQL 5.6开始反对，使得从库能够成心滞后于主库至多一段指定的工夫，以便在呈现误操作时，有工夫对误操作的数据进行补救。同步复制：指的是须要保障写操作齐全同步到其余数据节点，而不仅仅是二进制日志被其余节点接管。对于须要同步复制的场景，能够应用NDB Cluster，或者其余相似的开源解决方案（虚构同步，非齐全同步），例如Percona XtraDB Cluster（PXC）、MariaDB GaleraCluster（MGC）、MySQL Group Replication（MGR）。复制格局MySQL的复制格局（二进制日志格局）能够分为三种，由零碎变量binlog_format进行设置： 基于statement的复制（Statement Based Replication，SBR）：SBR复制的是整个SQL语句的原始文本，日志量较小，但容易呈现主从库数据不统一。对于SBR，当执行的某个语句被断定为不平安时，是否容许其执行还取决于事务的隔离级别。基于row的复制（Row Based Replication，RBR）：RBR复制的是产生更改的数据行的理论记录（原始语句会被转换为产生变更的行数据记录），日志量较大，但能够保障主从库数据的一致性。混合复制（Mixed Based Replication，MBR）：MBR实际上是由MySQL自行判断的，即在不影响数据一致性的状况下，应用SBR；如果可能影响数据一致性，则主动转换为RBR。复制的基本原理复制是基于主库（master）二进制日志中写入的对于该数据库的所有更改（更新、删除等）的日志记录来实现的。从库（slave）利用这些二进制日志中的事件记录进行回放来同步数据。 对于复制线程在主从之间新建设连贯或从新建设连贯的状况，从库会被动向主库申请所需的二进制日志（从库向主库注册连贯时，携带了从库本身所需二进制日志的地位信息）。如果复制线程曾经在主从之间建设连贯，而且从库曾经齐全接管建设连贯时申请的二进制日志内容，后续的增量二进制日志是由主库被动推送给从库的。 MySQL的复制性能用三个线程来实现：一个线程在主库上（Binlog Dump线程），两个线程在从库上（I/O线程和SQL线程）。如图所示： 复制的大抵步骤如下： 用户提交对数据的批改，而后主库把所有数据库变更写进二进制日志。从库会启动一个工作线程，称为I/O线程。而后在主库上启动一个非凡的Binlog Dump线程，这个线程会读取主库上二进制日志中的事件，它不会对事件进行轮询，如果该线程追赶上了主库，它将进入睡眠状态，直到主库发送信号量告诉其有新的事件产生时才会被唤醒。从库的I/O线程跟主库的Binlog Dump线程建设一个一般的客户端连贯，备库I/O线程将接管到的事件记录到中继日志中。从库SQL线程读取并解析中继日志中的内容，依照读取的程序进行回放。

mysql 作为一个关系型数据库，在国内应用应该是最宽泛的。兴许你司应用 Oracle、Pg 等等，然而大多数互联网公司，比方我司应用得最多的还是 Mysql，重要性显而易见。 事件是这样的，上一篇对于 MySQL 基础架构的文章收回当前，有小伙伴说能不能聊聊索引？日常工作中，咱们遇到 sql 执行慢的时候，常常会收到这样的倡议："加个索引呗"。索引到底是啥呢？它为啥能进步执行效率呢？这篇咱们来聊聊~ 01 索引是什么？索引是一种数据结构，它的呈现就是为了进步数据查问的效率，就像一本书的目录。想想一本书几百页，没有目录预计找得够呛的。举个艰深点的例子，我在知乎刷到的，比喻得很妙。 咱们从小就用的新华字典，外面的声母查问形式就是聚簇索引。 偏旁部首就是二级索引 偏旁部首 + 笔画就是联结索引。索引自身也是占用磁盘空间的（想想一本书中的目录也是占用页数的，你就晓得了），它次要以文件的模式存在于磁盘中。 1.1 索引的优缺点长处 进步查问语句的执行效率，缩小 IO 操作的次数创立唯一性索引，能够保障数据库表中每一行数据的唯一性加了索引的列会进行排序（一本书的章节程序不就是依照目录来排嘛），在应用分组和排序子句进行查问时，能够显著缩小查问中分组和排序的工夫毛病 索引须要占物理空间创立索引和保护索引要消耗工夫，这种工夫随着数据量的减少而减少当对表中的数据进行增删改查是，索引也要动静的保护，这样就升高了数据的更新效率1.2 索引的分类主键索引 一种非凡的惟一索引，不容许有空值。(主键束缚 = 惟一索引 + 非空值) 惟一索引 索引列中的值必须是惟一的，然而容许为空值。 一般索引 MySQL 中的加索引类型，没啥限度。容许空值和反复值，纯正为了进步查问效率而存在。 单列索引 没啥好说的，就是索引的列数量只有一个，每个表能够有多个单列索引。 组合索引 多列值组成一个索引，专门用于组合搜寻，其效率大于索引合并。留神，应用它的时候须要恪守最左匹配准则。多个列作为查问条件时，组合索引在工作中很罕用。 全文索引 只能在文本内容，也就是 TEXT、CHAR、VARCHAR 数据类型的列上建全文索引。有人说创立单列索引不就完了吗？思考一种状况：当这列的内容很长时，用 like 查问就会很慢，这是就适宜建全文索引。 前缀索引 还是只能作用于文本内容，也就是 TEXT、CHAR、VARCHAR 数据类型的列上建前缀索引，它能够指定索引列的长度，它是这样写的： // 在 x_test 的 x_name 列上创立一个长度为 4 的前缀索引alter table x_test add index(x_name(4));这个长度是依据理论状况来定的。长了太占用空间，短了不起成果。比方：我有个表的 x_name 的第一个字符简直都是一样的（假如都是1），如果创立索引的长度 = 1，执行以下查问的时候就可能比原来更糟。因为数据库外面太多第一个字符 = 1 的列了，所以选的时候尽量抉择数据开始有差异的长度。 SELECT * FROM x_test WHERE x_name = '1892008.205824857823401.800099203178258.8904820949682635656.62526521254';空间索引 ...

创立数据库：creat database 数据库名; （分号不能少）删除数据库：drop database 数据库名;抉择数据库：use 数据库名;创立数据表：create table table_name (column_name column_type); 例如： CREATE TABLE IF NOT EXISTS `runoob_tbl` ( `runoob_id` INT UNSIGNED AUTO_INCREMENT, `runoob_title` VARCHAR(100) NOT NULL, `runoob_author` VARCHAR(40) NOT NULL, `submission_date` DATE, PRIMARY KEY ( `runoob_id` ) )ENGINE=InnoDB DEFAULT CHARSET=utf8; **实例解析：**如果你不想字段为 NULL 能够设置字段的属性为 NOT NULL， 在操作数据库时如果输出该字段的数据为NULL ，就会报错。AUTO_INCREMENT定义列为自增的属性，个别用于主键，数值会主动加1。PRIMARY KEY关键字用于定义列为主键。 您能够应用多列来定义主键，列间以逗号分隔。ENGINE 设置存储引擎，CHARSET 设置编码。删除数据表：drop table table_name;插入数据：如果数据是字符型，必须应用单引号或者双引号，如："value"。 insert into table_name ( field1, field2,...fieldN ) value ( value1, value2,...valueN );查问数据： 1)查问整个表：select* from table_name; 2)查问指定字段并过滤雷同字段：select 字段名 from table_name distinct; 默认all，会保留反复地数据行。 3)条件,排序,分组查问：select 字段名 from table_name where 条件表达式 order by 字段名[asc/desc] *默认升序asc group by 字段名 having 筛选表达式8.聚合函数：实现数据统计。 ...

GTID通过sql_slave_skip_counter跳过事务和通过slave_skip_errors疏忽谬误的办法，尽管都最终能够建设从库B和新主库A’的主备关系，但这两种操作都很简单，而且容易出错。所以，MySQL 5.6版本引入了GTID，彻底解决了这个艰难。 那么，GTID到底是什么意思，又是如何解决找同步位点这个问题呢？当初，我就和你简略介绍一下。 GTID的全称是Global Transaction Identifier，也就是全局事务ID，是一个事务在提交的时候生成的，是这个事务的惟一标识。它由两局部组成，格局是： GTID=server_uuid:gno 其中： server_uuid是一个实例第一次启动时主动生成的，是一个全局惟一的值；gno是一个整数，初始值是1，每次提交事务的时候调配给这个事务，并加1。这里我须要和你阐明一下，在MySQL的官网文档里，GTID格局是这么定义的： GTID=source_id:transaction_id 这里的source_id就是server_uuid；而前面的这个transaction_id，我感觉容易造成误导，所以我改成了gno。为什么说应用transaction_id容易造成误会呢？ 因为，在MySQL外面咱们说transaction_id就是指事务id，事务id是在事务执行过程中调配的，如果这个事务回滚了，事务id也会递增，而gno是在事务提交的时候才会调配。 从成果上看，GTID往往是间断的，因而咱们用gno来示意更容易了解。 GTID模式的启动也很简略，咱们只须要在启动一个MySQL实例的时候，加上参数gtid_mode=on和enforce_gtid_consistency=on就能够了。 在GTID模式下，每个事务都会跟一个GTID一一对应。这个GTID有两种生成形式，而应用哪种形式取决于session变量gtid_next的值。 如果gtid_next=automatic，代表应用默认值。这时，MySQL就会把server_uuid:gno调配给这个事务。a. 记录binlog的时候，先记录一行 SET @@SESSION.GTID_NEXT=‘server_uuid:gno’;b. 把这个GTID退出本实例的GTID汇合。如果gtid_next是一个指定的GTID的值，比方通过set gtid_next='current_gtid’指定为current_gtid，那么就有两种可能：a. 如果current_gtid曾经存在于实例的GTID汇合中，接下来执行的这个事务会间接被零碎疏忽；b. 如果current_gtid没有存在于实例的GTID汇合中，就将这个current_gtid调配给接下来要执行的事务，也就是说零碎不须要给这个事务生成新的GTID，因而gno也不必加1。留神，一个current_gtid只能给一个事务应用。这个事务提交后，如果要执行下一个事务，就要执行set 命令，把gtid_next设置成另外一个gtid或者automatic。 这样，每个MySQL实例都保护了一个GTID汇合，用来对应“这个实例执行过的所有事务”。 这样看上去不太容易了解，接下来我就用一个简略的例子，来和你阐明GTID的根本用法。 咱们在实例X中创立一个表t。 CREATE TABLE `t` ( `id` int(11) NOT NULL, `c` int(11) DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB;insert into t values(1,1); 图4 初始化数据的binlog 能够看到，事务的BEGIN之前有一条SET @@SESSION.GTID_NEXT命令。这时，如果实例X有从库，那么将CREATE TABLE和insert语句的binlog同步过来执行的话，执行事务之前就会先执行这两个SET命令， 这样被退出从库的GTID汇合的，就是图中的这两个GTID。 假如，当初这个实例X是另外一个实例Y的从库，并且此时在实例Y上执行了上面这条插入语句： insert into t values(1,1); 并且，这条语句在实例Y上的GTID是 “aaaaaaaa-cccc-dddd-eeee-ffffffffffff:10”。 那么，实例X作为Y的从库，就要同步这个事务过去执行，显然会呈现主键抵触，导致实例X的同步线程进行。这时，咱们应该怎么解决呢？ 解决办法就是，你能够执行上面的这个语句序列： set gtid_next='aaaaaaaa-cccc-dddd-eeee-ffffffffffff:10';begin;commit;set gtid_next=automatic;start slave; 其中，前三条语句的作用，是通过提交一个空事务，把这个GTID加到实例X的GTID汇合中。如图5所示，就是执行完这个空事务之后的show master status的后果。 ...

MySQL 5.7.22的并行复制策略在2018年4月份公布的MySQL 5.7.22版本里，MySQL减少了一个新的并行复制策略，基于WRITESET的并行复制。 相应地，新增了一个参数binlog-transaction-dependency-tracking，用来管制是否启用这个新策略。这个参数的可选值有以下三种。 COMMIT_ORDER，示意的就是后面介绍的，依据同时进入prepare和commit来判断是否能够并行的策略。WRITESET，示意的是对于事务波及更新的每一行，计算出这一行的hash值，组成汇合writeset。如果两个事务没有操作雷同的行，也就是说它们的writeset没有交加，就能够并行。WRITESET_SESSION，是在WRITESET的根底上多了一个束缚，即在主库上同一个线程先后执行的两个事务，在备库执行的时候，要保障雷同的先后顺序。当然为了惟一标识，这个hash值是通过“库名+表名+索引名+值”计算出来的。如果一个表上除了有主键索引外，还有其余惟一索引，那么对于每个惟一索引，insert语句对应的writeset就要多减少一个hash值。 你可能看进去了，这跟咱们后面介绍的基于MySQL 5.5版本的按行散发的策略是差不多的。不过，MySQL官网的这个实现还是有很大的劣势： writeset是在主库生成后间接写入到binlog外面的，这样在备库执行的时候，不须要解析binlog内容（event里的行数据），节俭了很多计算量；不须要把整个事务的binlog都扫一遍能力决定散发到哪个worker，更省内存；因为备库的散发策略不依赖于binlog内容，所以binlog是statement格局也是能够的。因而，MySQL 5.7.22的并行复制策略在通用性上还是有保障的。 当然，对于“表上没主键”和“外键束缚”的场景，WRITESET策略也是没法并行的，也会临时进化为单线程模型。

数据库（Database）是依照数据结构来组织、存储和治理数据的仓库。每个数据库都有一个或多个不同的 API （利用程序接口）用于创立，拜访，治理，搜寻和复制所保留的数据。我 们也能够将数据存储在文件中，然而在文件中读写数据速度绝对较慢。 所以，当初咱们应用关系型数据库管理系统（RDBMS）来存储和治理大数据量。所谓的关系型数据库，是建设在关系模型根底上的数据库，借助于汇合代数等数学概念和办法来解决数据库中的数据。RDBMS 即关系数据库管理系统(Relational Database Management System)的特点： 1.数据以表格的模式呈现2.每行为各种记录名称3.每列为记录名称所对应的数据域4.许多的行和列组成一张表单5.若干的表单组成database2.RDBMS 术语 数据库: 数据库是一些关联表的汇合。数据表: 表是数据的矩阵。在一个数据库中的表看起来像一个简略的电子表格。列: 一列(数据元素) 蕴含了雷同类型的数据, 例如邮政编码的数据。行：一行（=元组，或记录）是一组相干的数据，例如一条用户订阅的数据。冗余：存储两倍数据，冗余升高了性能，但进步了数据的安全性。主键：主键是惟一的。一个数据表中只能蕴含一个主键。你能够应用主键来查问数据。外键：外键用于关联两个表。复合键：复合键（组合键）将多个列作为一个索引键，个别用于复合索引。索引：应用索引可快速访问数据库表中的特定信息。索引是对数据库表中一列或多列的值进行排序的一种构造。相似于书籍的目录。参照完整性: 参照的完整性要求关系中不容许援用不存在的实体。与实体完整性是关系模型必须满足的完整性约束条件，目标是保证数据的一致性。表头(header): 每一列的名称;~~~~列(col): 具备雷同数据类型的数据的汇合;行(row): 每一行用来形容某条记录的具体信息;值(value): 行的具体信息, 每个值必须与该列的数据类型雷同;键(key): 键的值在当前列中具备唯一性。

数据库分布式核心内容无非就是数据切分（Sharding）以及切分后对数据的定位、整合。数据切分就是将数据扩散存储到多个数据库中，使得繁多数据库中的数据质变小，通过裁减主机的数量缓解繁多数据库的性能问题，从而达到晋升数据库操作性能的目标。 数据切分依据其切分类型，能够分为两种形式：垂直（纵向）切分和程度（横向）切分。 1.垂直（纵向）切分垂直切分常见有垂直分库和垂直分表两种。 1.1 垂直分库 就是依据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大零碎拆分为多个小零碎相似，按业务分类进行独立划分。与"微服务治理"的做法类似，每个微服务应用独自的一个数据库。如图： 将不同模块的数据表分库存储。模块间不互相关联查问如果有，就须要通过数据冗余或者应层二次加工来解决。这种业务办法和数据结构最清晰。但若不能杜绝跨库关联查问，宣告此路不同1.2 垂直分表 是基于数据库中的"列"进行，某个表字段较多，能够新建一张扩大表，将不常常用或字段长度较大的字段拆分进来到扩大表中。在字段很多的状况下（例如一个大表有100多个字段），通过"大表拆小表"，更便于开发与保护，也能防止跨页问题，MySQL底层是通过数据页存储的，一条记录占用空间过大会导致跨页，造成额定的性能开销。另外数据库以行为单位将数据加载到内存中，这样表中字段长度较短且拜访频率较高，内存能加载更多的数据，命中率更高，缩小了磁盘IO，从而晋升了数据库性能。 解决业务零碎层面的耦合，业务清晰与微服务的治理相似，也能对不同业务的数据进行分级管理、保护、监控、扩大等高并发场景下，垂直切分肯定水平的晋升IO、数据库连接数、单机硬件资源的瓶颈毛病： 局部表无奈join，只能通过接口聚合形式解决，晋升了开发的复杂度分布式事务处理简单仍然存在单表数据量过大的问题（须要程度切分）2. 程度（横向）切分当一个利用难以再细粒度的垂直切分，或切分后数据量行数微小，存在单库读写、存储性能瓶颈，这时候就须要进行程度切分了。 程度切分分为库内分表和分库分表，是依据表内数据外在的逻辑关系，将同一个表按不同的条件扩散到多个数据库或多个表中，每个表中只蕴含一部分数据，从而使得单个表的数据质变小，达到分布式的成果。如图所示： 绝对纵向切分这一将表分类的做法，此法是按表内每个字段的某个规定来将数据扩散存储于不同的数据库(或不同的表)，也就是依照数行来进行切分数据。程度切分的长处： 不存在单库数据量过大、高并发的性能瓶颈，晋升零碎稳定性和负载能力利用端革新较小，不须要拆分业务模块毛病： 跨分片的事务一致性难以保障跨库的join关联查问性能较差数据屡次扩大难度和保护量极大程度切分后同一张表会呈现在多个数据库/表中，每个库/表的内容不同。几种典型的数据分片规定为： 2.1 依据数值范畴依照工夫区间或ID区间来切分。例如：按日期将不同月甚至是日的数据扩散到不同的库中；将userId为1~9999的记录分到第一个库，10000~20000的分到第二个库，以此类推。某种意义上，某些零碎中应用的"冷热数据拆散"，将一些应用较少的历史数据迁徙到其余库中，业务性能上只提供热点数据的查问，也是相似的实际。 这样的长处在于： 单表大小可控人造便于程度扩大，前期如果想对整个分片集群扩容时，只须要增加节点即可，无需对其余分片的数据进行迁徙应用分片字段进行范畴查找时，间断分片可疾速定位分片进行疾速查问，无效防止跨分片查问的问题。毛病： 热点数据成为性能瓶颈。间断分片可能存在数据热点，例如按工夫字段分片，有些分片存储最近时间段内的数据，可能会被频繁的读写，而有些分片存储的历史数据，则很少被查问 2.2 依据数值取模个别采纳hash取模mod的切分形式，例如：将 Customer 表依据 cusno 字段切分到4个库中，余数为0的放到第一个库，余数为1的放到第二个库，以此类推。这样同一个用户的数据会扩散到同一个库中，如果查问条件带有cusno字段，则可明确定位到相应库去查问。 长处： 数据分片绝对比拟平均，不容易呈现热点和并发拜访的瓶颈毛病： 前期分片集群扩容时，须要迁徙旧的数据（应用一致性hash算法能较好的防止这个问题）容易面临跨分片查问的简单问题。比方上例中，如果频繁用到的查问条件中不带cusno时，将会导致无奈定位数据库，从而须要同时向4个库发动查问，再在内存中合并数据，取最小集返回给利用，分库反而成为连累 往期举荐技术人具备“结构化思维”意味着什么？Gradle 比 Maven 好为什么用的人少？Kafka 提供哪些日志清理策略？为什么ConcurrentHashMap的读操作不须要加锁？Kafka 是怎么存储的？为什么速度那么快？

前言用过mybatis-plus的敌人可能会晓得，mybatis-plus提供了多租户插件的性能，这个性能能够让开发人员不必手动写租户语句，由该插件主动帮你加上租户语句。明天的素材起源就是取自业务开发人员应用多租户插件时，遇到的一个神奇的问题 问题重现业务开发人员要实现依据手机号码更新租户的明码性能，其代码形如下 for(Tenant t : tenantList){ ApplicationChainContext.getCurrentContext().put(ApplicationChainContext.TENANT_ID,t.getId()+""); Optional<SaasUser> user = this.findByUserPhone(req.getUserPhone()); user.ifPresent(u -> { count.getAndSet(count.get() + 1); LambdaUpdateWrapper<SaasUser> wrapper = new LambdaUpdateWrapper<>(); String md5Pwd = Md5Utils.hash(req.getNewUserPwd()); wrapper.eq(SaasUser::getId,user.get().getId()); wrapper.set(SaasUser::getUserPwd,md5Pwd); this.update(wrapper); }); }从代码上看起来没啥问题，因为应用了多租户插件，当咱们执行this.findByUserPhone(req.getUserPhone());就会主动带上租户的信息。但在执行的时候发现一个问题，如下图从图中咱们能够发现，当查问不到用户信息时，后续的查问操作，都没有sql语句呈现。这阐明2点，sql语句要么被零碎吃了，要么零碎没有执行sql 问题剖析后面说了sql语句没有打印进去，阐明sql要么没执行，要么就sql语句被零碎吃了。到底是哪种，与其猜想，倒不如去官网找找问题的答案，很遗憾在mybatis-plus官网或者issue上并没找到答案，于是只好跟踪源码进行剖析。最初发现mybatis-plus果然如他官网介绍的只做加强不做扭转，他最终调用查问的逻辑，走的是原生mybatis的查问逻辑。其查问的外围代码如下 public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException { ErrorContext.instance().resource(ms.getResource()).activity("executing a query").object(ms.getId()); if (this.closed) { throw new ExecutorException("Executor was closed."); } else { if (this.queryStack == 0 && ms.isFlushCacheRequired()) { this.clearLocalCache(); } List list; try { ++this.queryStack; list = resultHandler == null ? (List)this.localCache.getObject(key) : null; if (list != null) { this.handleLocallyCachedOutputParameters(ms, key, parameter, boundSql); } else { list = this.queryFromDatabase(ms, parameter, rowBounds, resultHandler, key, boundSql); } } finally { --this.queryStack; } if (this.queryStack == 0) { Iterator var8 = this.deferredLoads.iterator(); while(var8.hasNext()) { BaseExecutor.DeferredLoad deferredLoad = (BaseExecutor.DeferredLoad)var8.next(); deferredLoad.load(); } this.deferredLoads.clear(); if (this.configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) { this.clearLocalCache(); } } return list; } }从代码咱们能够得出一个重要的信息，如下 ...

1. 查看操作系统是否有自带的mysql相干包并卸载rpm -qa |grep mariadb||mysql||perconarpm -e mariadb-libs-5.5.68-1.el7.x86_64如果报错依赖其余的什么包，也应用 rpm -e 卸载掉 2. 获取mysql的软件包cd /opt; wget https://repo.huaweicloud.com/mysql/Downloads/MySQL-5.7/mysql-5.7.31-linux-glibc2.12-x86_64.tar.gz 3. 装置和初始化mysql# 解压并批改目录名称tar -zxvf mysql-5.7.31-linux-glibc2.12-x86_64.tar.gzmv mysql-5.7.31-linux-glibc2.12-x86_64 mysql# 创立用户及所属组groupadd mysql ; useradd -d /home/mysql -s /bin/bash -g mysql -m mysqlchown -R mysql:mysql /opt/mysql# 创立数据盘目录（有条件能够给/data01目录独自挂数据盘，没条件能够不挂）mkdir -p /data01/mysql-data/tmpmkdir -p /data01/mysql-data/logmkdir -p /data01/mysql-data/workdbschown -R mysql:mysql /data01/mysql-data/# 创立my.cnf文件，并输出以下内容：cd /opt/mysql;vim my.cnf### 以下为文件内容[mysqld]basedir = /opt/mysql/bind-address = 192.168.74.129datadir = /data01/mysql-data/workdbstmpdir = /data01/mysql-data/tmpport = 3306socket = /opt/mysql/lib/mysql.socklower_case_table_names = 1character-set-server = utf8 max_allowed_packet = 150Msql_mode = STRICT_ALL_TABLES,STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTIONlog-error = /data01/mysql-data/log/mysql-3306.logmax_connections = 1000event_scheduler = ON[mysql]default-character-set = utf8 socket = /opt/mysql/lib/mysql.sock# 批改文件权限chown mysql:mysql /opt/mysql/my.cnfcp -fr /opt/mysql/my.cnf /etc/my.cnf# 批改零碎配置文件,行尾申明path# vim /etc/profileexport PATH=$PATH:/opt/mysql/binexport PATH=$PATH:/etc/init.d# 加载环境变量source /etc/profile# 拷贝support文件cd /opt/mysql; cp -a ./support-files/mysql.server /etc/init.d/mysql.server# 初始化mysqlcd /opt/mysql; ./bin/mysqld --initialize --user=mysql --basedir=/opt/mysql --datadir=/data01/mysql-data/workdbs# 获取mysql初始密码相似于上面这样cat /data01/mysql-data/log/mysql-3306.log### 2021-03-04T02:13:45.980203Z 1 [Note] A temporary password is generated for root@localhost: gRaEoQl)z3eQ# 创立软连贯ln -s /opt/mysql /usr/local/mysqlln -s /opt/mysql/lib/mysql.sock /tmp/mysql.sock# 启动mysql服务systemctl enable mysql.servercd /opt/mysql/support-files ; mysql.server start; # 批改root用户名和明码mysql -uroot -pset password=password("123");grant all privileges on *.* to 'root'@'%' identified by '123' with grant option;flush privileges;use mysql;# 查看受权正确select host,user from user;exit以上装置结束 ...

 大家好，我是为宽广程序员兄弟操碎了心的小编，每天举荐一个小工具/源码，装满你的收藏夹，每天分享一个小技巧，让你轻松节俭开发效率，实现不加班不熬夜不掉头发，是我的指标！ 你是否懊恼过这些问题作为架构设计的你，想要解决数据库主键惟一的问题，特地是在分布式系统多数据库的时候。你心愿这个主键是用起码的存储空间，索引速度更快，Select、Insert 和 Update 更迅速。你要思考在分库分表（合库合表）的时候，主键值可间接应用，并能反映业务时序。如果这样的主键值太长，超过前端 JS Number 类型最大值，须把 Long 型转换为 String 型，你会感觉有点丧气。哪怕 Guid 能自增，但占用空间大，这也不是你想要的。你的利用实例可能超过50个，每个并发申请可能达10W/s。你心愿零碎能运行 100 年以上。 为了解决这个问题，明天小编举荐一种全新的雪花漂移算法——IdGenerator，让ID更短、生成速度更快。 外围在于缩短ID长度的同时，还能领有极高刹时并发处理量（50W/0.1s）。 顶尖优化，超强效力（位数更短，速度更快），全新 SnowFlake 算法，反对 C#/Java/Go/PHP 等语言。 开源协定 应用 MIT 开源许可协定 链接地址 公众号【Github导航站】回复关键词【idg】获取git地址 传统算法问题生成的ID太长。刹时并发量不够。不能解决工夫回拨问题。不反对后补生成前序ID。依赖内部存储系统。新算法特点整形数字，随工夫枯燥递增（不肯定间断），长度更短，用50年都不会超过 js Number类型最大值。（默认配置 WorkerId 是6bit，自增数是6bit）速度更快，是传统雪花算法的2-5倍，0.1秒可生成50万个。（i7笔记本，默认算法配置6bit+6bit）反对工夫回拨解决。比方服务器工夫回拨1秒，本算法能主动适应生成临界工夫的惟一ID。反对手工插入新ID。当业务须要在历史工夫生成新ID时，用本算法的预留位能生成5000个每秒。漂移时能外发告诉事件。让调用方确切晓得算法漂移记录，Log并发调用量。不依赖任何内部缓存和数据库。（但 WorkerId 必须由内部指定）性能数据(参数：10位自增序列，1000次漂移最大值) 成果js Number 类型最大数值：9007199254740992，本算法在放弃并发性能（5W+/0.01s）和最大64个 WorkerId（6bit）的同时，能用70年才到 js Number Max 值。减少WorkerId位数到8bit（256节点）时，15年达到 js Number Max 值。极致性能：500W/1s。所有测试数据均基于8代低压i7计算。“我”是什么本算法是一个类库，它基于 net standard2.0 根底库，不依赖任何第三方组件。本算法不依赖任何内部数据系统（除了要被指定 WorkerId 之外）。适用范围小型、中型、大型须要全局惟一Id（不必Guid）的我的项目。分布式我的项目。不想将 Long 型转 String 给前端用的我的项目。（若前端反对bigint，则可不转类型）如何解决工夫回拨当产生零碎工夫回拨时，算法采纳过来时序的预留序数生成新的ID。默认每秒生成100个（速度可调整）。回拨生成的ID序号，默认靠前，也能够调整为靠后。许工夫回拨至本算法预设基数（参数可调）。能用多久在默认配置下，ID可用 71000 年不反复。在反对 1024 个工作节点时，ID可用 4480 年不反复。在反对 4096 个工作节点时，ID可用 1120 年不反复。以上所有工作节点，均领有 50W/0.1s 刹时处理速度。结尾 本期就分享到这里，我是小编南风吹，专一分享好玩乏味、离奇、实用的开源我的项目及开发者工具、学习资源！心愿能与大家独特学习交换，欢送关注我的公众号【Github导航站】。 ...

11、讲怎么给字符串字段加索引 mysql> alter table SUser add index index1(email);或mysql> alter table SUser add index index2(email(6)); 1、创立的index1索引外面，蕴含了每个记录的整个字符串； 2、创立的index2索引外面，对于每个记录都是只取前6个字节 (前缀索引)        应用前缀索引就用不上笼罩索引对查问性能的优化了，这也是你在抉择是否应用前缀索引时须要思考的一个因素 3、其余形式      第一种形式是应用倒序存储。如果你存储身份证号的时候把它倒过去存 mysql> select field_list from t where id_card = reverse('input_id_card_string');     第二种形式是应用hash字段。你能够在表上再创立一个整数字段，来保留身份证的校验码，同时在这个字段上创立索引 mysql> alter table t add id_card_crc int unsigned, add index(id_card_crc);        首先，它们的相同点是，都不反对范畴查问。倒序存储的字段上创立的索引是依照倒序字符串的形式排序的，曾经没有方法利用索引形式查出身份证号码在[ID_X, ID_Y]的所有市民了。同样地，hash字段的形式也只能反对等值查问。 它们的区别，次要体现在以下三个方面：  从占用的额定空间来看，倒序存储形式在主键索引上，不会耗费额定的存储空间，而hash字段办法须要减少一个字段。当然，倒序存储形式应用4个字节的前缀长度应该是不够的，如果再长一点，这个耗费跟额定这个hash字段也差不多对消了。  在CPU耗费方面，倒序形式每次写和读的时候，都须要额定调用一次reverse函数，而hash字段的形式须要额定调用一次crc32()函数。如果只从这两个函数的计算复杂度来看的话，reverse函数额定耗费的CPU资源会更小些。  从查问效率上看，应用hash字段形式的查问性能绝对更稳固一些。因为crc32算进去的值尽管有抵触的概率，然而概率十分小，能够认为每次查问的均匀扫描行数靠近1。而倒序存储形式毕竟还是用的前缀索引的形式，也就是说还是会减少扫描行数。    # 小结    在明天这篇文章中，我跟你聊了聊字符串字段创立索引的场景。咱们来回顾一下，你能够应用的形式有：    1. 间接创立残缺索引，这样可能比拟占用空间；   2. 创立前缀索引，节俭空间，但会减少查问扫描次数，并且不能应用笼罩索引；   3. 倒序存储，再创立前缀索引，用于绕过字符串自身前缀的区分度不够的问题；   4. 创立hash字段索引，查问性能稳固，有额定的存储和计算耗费，跟第三种形式一样，都不反对范畴扫描。  12讲为什么我的MySQL会“抖”一下       我为你介绍了WAL机制。当初你晓得了，InnoDB在解决更新语句的时候，只做了写日志这一个磁盘操作。这个日志叫作redo log（重做日志），也就是《孔乙己》里咸亨酒店掌柜用来记账的粉板，在更新内存写完redo log后，就返回给客户端，本次更新胜利。  当内存数据页跟磁盘数据页内容不统一的时候，咱们称这个内存页为“脏页”。内存数据写入到磁盘后，内存和磁盘上的数据页的内容就统一了，称为“洁净页”  回到文章结尾的问题，你不难想象，平时执行很快的更新操作，其实就是在写内存和日志，而MySQL偶然“抖”一下的那个霎时，可能就是在刷脏页（flush）。 那么，什么状况会引发数据库的flush过程呢 咱们还是持续用咸亨酒店掌柜的这个例子，想一想：掌柜在什么状况下会把粉板上的赊账记录改到账本上？  第一种场景是，粉板满了，记不下了。这时候如果再有人来赊账，掌柜就只得放下手里的活儿，将粉板上的记录擦掉一些，留出空位以便持续记账。当然在擦掉之前，他必须先将正确的账目记录到账本中才行。  这个场景，对应的就是InnoDB的redo log写满了。这时候零碎会进行所有更新操作，把checkpoint往前推动，redo log留出空间能够持续写。我在第二讲画了一个redo log的示意图，这里我改成环形，便于大家了解。  图2 redo log状态图 checkpoint可不是轻易往前批改一下地位就能够的。比方图2中，把checkpoint地位从CP推动到CP’，就须要将两个点之间的日志（浅绿色局部），对应的所有脏页都flush到磁盘上。之后，图中从write pos到CP’之间就是能够再写入的redo log的区域。  ...

三年前，我大三上学期，守业失败，想转行做技术。那时候我对Java刚刚理解这几个英语单词。 本人买了本Java从入门到精通。认为能够很快地学完，非CS业余。当初我想说所有系列的从入门到精通都是垃圾，一年多来，我每天白天看视频，早晨敲代码到凌晨，我是一个很倔的人，我认为天下没有任何货色是人类学不会的，所以我就付出高三一样的工夫去学习。最开始学习Java SE，看着控制台打印出第一行Hello world的欣慰，到前面学习打印二维数组算法菱形的恐慌，再到前面学习Java Swing的乏味，再到前面本人开发几款小游戏。这其中有苦有累，总之就是很孤单，我从学校搬到了里面的小区，每天从事着本人喜爱的事件，始终到2018年1月3号，正式入职。是一个初创公司的后端次要负责人。一共收到4个offer。投了10多家。 这是这一年来我看的一些书籍。 刚开始的学习非常自觉，不晓得如何去学习，看到一个货色感觉乏味就去钻研，后果最初没有系统性的学习，还节约了大量的工夫。 当初我感觉如果你要学习Java技术能够先自学一段时间，看本人合不适合，然而肯定要保持，因为既然抉择了IT，就要养成终生学习的习惯。上面是我感觉你作为高级Java工程师应该把握的技术。 1.Java SE局部 高级语法，面向对象，异样，IO流，多线程，Java Swing，JDBC，泛型，注解，反射等。 2.数据库局部，根底的sql语句，sql语句调优，索引，数据库引擎，存储过程，触发器，事务等。 前端局部， HTML5 CSS3 JS(和Java一样简单，会应用就行)， HTML DOM Jquery BootStrap等。Java EE局部，Tomcat和Nginx服务器搭建，配置文件，Servlet，JSP，Filter，Listener，http协定，MVC等。框架局部，每个框架都能够离开学，再去学如何应用SSM 或者SSH框架，如何搭建，如何整合。开发中为什么会用框架，Rest是啥？Spring为啥经久不衰，底层如何实现等。6.23种设计模式，把握罕用的，比方单例模式的多种实现，责任链模式，工厂模式，装璜器模式等，理解罕用场景。 如果大家对于学习Java有任何的问题，对于如何晋升学习Java以及学习办法、学习技巧、疾速达到待业的技术水平，都能够随时来问我，这是我建设了5年的Java学习交换QQ群：796866257。有不懂的问题能够随时在外面问，须要Java各个阶段的学习材料也能够在外面进行下载。对于前端和Python的问题也能够问。根底算法和数据结构，八大排序算法，查找算法。(面试会问)(不做硬性要求) 纯熟应用maven等构建工具，git等版本控制工具，相熟罕用linux命令，log4j，dubug，junit单元测试，日志打印工具，Redis等NoSql。9，也是最重要的一条，看待Java要时刻充斥激情！

我的公众号：MarkerHub，网站：https://markerhub.com更多精选文章请点击：Java笔记大全.md 小Hub领读：针对mysql，说了很多优化的点，珍藏就好，哈哈哈哈~ wolearnjuejin.im/post/59b11ba151882538cb1ecbd0前言本文次要针对的是关系型数据数据库 MySql。键值类数据库能够参考： https://www.jianshu.com/p/098...先简略梳理下 Mysql 的基本概念，而后分创立时和查问时这两个阶段的优化开展。 1 基本概念简述1.1 逻辑架构 第一层：客户端通过连贯服务，将要执行的 sql 指令传输过去第二层：服务器解析并优化 sql，生成最终的执行打算并执行第三层：存储引擎，负责数据的贮存和提取1.2 锁数据库通过锁机制来解决并发场景 - 共享锁（读锁）和排他锁（写锁）。读锁是不阻塞的，多个客户端能够在同一时刻读取同一个资源。写锁是排他的，并且会阻塞其余的读锁和写锁。简略提下乐观锁和乐观锁。 乐观锁，通常用于数据竞争不强烈的场景，多读少写，通过版本号和工夫戳实现。乐观锁，通常用于数据竞争强烈的场景，每次操作都会锁定数据。要锁定数据须要肯定的锁策略来配合。 表锁，锁定整张表，开销最小，然而会加剧锁竞争。行锁，锁定行级别，开销最大，然而能够最大水平的反对并发。然而 MySql 的存储引擎的实在实现不是简略的行级锁，个别都是实现了多版本并发管制（MVCC）。MVCC 是行级锁的变种，少数状况下防止了加锁操作，开销更低。MVCC 是通过保留数据的某个工夫点快照实现的。 1.3 事务事务保障一组原子性的操作，要么全副胜利，要么全副失败。一旦失败，回滚之前的所有操作。MySql 采纳主动提交，如果不是显式的开启一个事务，则每个查问都作为一个事务。 隔离级别管制了一个事务中的批改，哪些在事务内和事务间是可见的。四种常见的隔离级别： 未提交读（Read UnCommitted），事务中的批改，即便没提交对其余事务也是可见的。事务可能读取未提交的数据，造成脏读。提交读（Read Committed），一个事务开始时，只能看见已提交的事务所做的批改。事务未提交之前，所做的批改对其余事务是不可见的。也叫不可反复读，同一个事务屡次读取同样记录可能不同。可反复读（RepeatTable Read），同一个事务中屡次读取同样的记录后果时后果雷同。可串行化（Serializable），最高隔离级别，强制事务串行执行。1.4 存储引擎InnoDB 引擎，最重要，应用最宽泛的存储引擎。被用来设计解决大量短期事务，具备高性能和主动解体复原的个性。 MyISAM 引擎，不反对事务和行级锁，解体后无奈平安复原。 2 创立时优化2.1 Schema 和数据类型优化整数 TinyInt,SmallInt,MediumInt,Int,BigInt 应用的存储 8,16,24,32,64 位存储空间。应用 Unsigned 示意不容许正数，能够使负数的上线进步一倍。 实数 Float,Double , 反对近似的浮点运算。Decimal，用于存储准确的小数。字符串 VarChar，存储变长的字符串。须要 1 或 2 个额定的字节记录字符串的长度。Char，定长，适宜存储固定长度的字符串，如 MD5 值。Blob，Text 为了存储很大的数据而设计的。别离采纳二进制和字符的形式。工夫类型 DateTime，保留大范畴的值，占 8 个字节。TimeStamp，举荐，与 UNIX 工夫戳雷同，占 4 个字节。优化倡议点 尽量应用对应的数据类型。比方，不要用字符串类型保留工夫，用整型保留 IP。抉择更小的数据类型。能用 TinyInt 不必 Int。标识列（identifier column），倡议应用整型，不举荐字符串类型，占用更多空间，而且计算速度比整型慢。不举荐 ORM 零碎主动生成的 Schema，通常具备不重视数据类型，应用很大的 VarChar 类型，索引利用不合理等问题。实在场景混用范式和反范式。冗余高查问效率高，插入更新效率低；冗余低插入更新效率高，查问效率低。创立齐全的独立的汇总表 \ 缓存表，定时生成数据，用于用户耗时工夫长的操作。对于精确度要求高的汇总操作，能够采纳 历史后果 + 最新记录的后果 来达到疾速查问的目标。数据迁徙，表降级的过程中能够应用影子表的形式，通过批改原表的表名，达到保留历史数据，同时不影响新表应用的目标。2.2 索引索引蕴含一个或多个列的值。MySql 只能高效的利用索引的最左前缀列。索引的劣势： ...

mysql在5.7版本之后勾销了user表中的password字段，password函数也改成了MD5; 明天在应用mysql 8.0.23版本的时候，初始化之后不小心敞开了命令行，只能跳过验证登录，而后批改明码。 从下载数据库开始，mysql下载地址，我下载的8.0.23版本。下载实现之后解压，我放在了D://gitee/MySQL目录下。在解压后的文件夹根目录创立my.ini配置文件。 [client]# 设置mysql客户端默认字符集default-character-set=utf8 [mysqld]# 设置3306端口port = 3306# 设置mysql的装置目录basedir=D:\\gitee\\MySQL\\mysql-8.0.23# 设置 mysql数据库的数据的寄存目录，MySQL 8+ 不须要以下配置，零碎本人生成即可，否则有可能报错# datadir=C:\\web\\sqldata# 容许最大连接数max_connections=20# 服务端应用的字符集默认为8比特编码的latin1字符集character-set-server=utf8# 创立新表时将应用的默认存储引擎default-storage-engine=INNODB应用管理员身份关上CMD命令行工具cd D://gitee/MySQL/mysql-8.0.23/bin 初始化数据库，执行实现后，会输入 root 用户的初始默认明码，不过我在用的时候初始密码也登录不下来mysqld --initialize --console ···2018-04-20T02:35:05.464644Z 5 [Note] [MY-010454] [Server] A temporary password is generated for root@localhost: APWCY5ws&hjQ···输出装置命令mysqld install 输出启动命令net start mysql 输出登录命令mysql -u root -p 回车确认，如果装置胜利会有以下提醒：Enter password: 此时输出方才生成的初始密码，如果登录胜利就没问题了，如果你忘了初始密码，心愿批改明码，接下来是8.0版本批改明码的步骤 敞开方才启动的mysqlnet stop mysql 应用如下命令启动，8.0版本必须带–shared-memory，否则报错，–skip-grant-tables示意跳过明码权限验证mysqld –shared-memory –skip-grant-tables 另关上一个终端，间接启动mysqlmysql 刷新执行指令“FLUSH PRIVILEGES;”，刷新权限FLUSH PRIVILEGES; 设置新密码：ALTER USER 'root'@'localhost' IDENTIFIED BY 'new_psd_123'; 设置实现后，敞开方才启动的跳过验证服务，失常启动MySQL服务net start mysql 应用新密码登录mysql -u root -pEnter password: ...

前言： 日常应用 MySQL 的过程中，咱们可能会常常应用可视化工具来连贯 MySQL ，其中比拟罕用的就是 Navicat 了。平时也会遇到某些同学问， Navicat 怎么装置，如何应用等问题。本篇文章笔者将联合集体教训，分享下 Navicat 操作 MySQL 繁难教程。 1.Navicat简介Navicat 是一款成熟牢靠的数据库管理工具，深受技术人员的青睐。它是以直觉化的图形用户界面而建的，让你能够以平安并且简略的形式创立、组织、拜访并共用信息。 Navicat 能够用来对本机或近程的 MySQL、SQL Server、SQLite、Oracle 及 PostgreSQL 数据库进行治理及开发。可运行在 Windows 、macOS、Linux 三种操作系统中，可提供数据传输、数据同步、构造同步、导入、导出、备份、还原、报表创立工具及打算以帮助治理数据等性能。 Navicat 目前在市场上有很多在用的版本，大体可分为可连贯多种数据源的 Navicat Premium 和用于单数据源的 Navicat for MySQL 等。不过不同版本之间差异并不大。 2.繁难教程分享首先阐明下，Navicat 正版是免费软件，这里不会解说装置及破解办法。 连贯治理 抉择新建连贯，填入 IP 、端口及账号密码即可新建数据库连贯。若想换个账号登录，能够点击复制连贯，则 IP 端口会主动填充，只需更改账号密码即可。对于连贯治理还是很容易上手的。 库表操作 选中相应的库表，点击右键即可抉择相应操作，和写 SQL 成果相似。不过也要留神不要误操作哦，特地是点击删除时肯定要看清楚。清空表的意思是 delete from ，截断表的意思是 truncate。 查问窗口 查问窗口常常用到，抉择相应库，点击新建查问即可关上查问窗口。在查问窗口中咱们能够执行咱们自定义的 SQL 语句，不过这里也揭示下，不要在一个查问窗口里放多条 SQL 哦，最好选中某条 SQL 再点击执行。 当 SQL 比拟长时，能够点击丑化 SQL 使得更具备可读性，点击解释按钮还能够展现该 SQL 的执行打算。 ...

本教程蕴含以下内容mysql8.0.23压缩包+环境变量配置+mysql配置+navicat装置以及破解 资源下载链接：链接：https://pan.baidu.com/s/1GJ__... 提取码：2cv1 复制这段内容后关上百度网盘手机App，操作更不便哦 下载mysql8.0.23有两种抉择， 一个是下载官网的装置器对应链接：https://dev.mysql.com/downloa... 二是下载官网的曾经编译后的二进制压缩包对应链接：https://dev.mysql.com/downloa... 意见：抉择二进制压缩包（就是第二个），因为更自在，更污浊，更简略 环境变量配置mysql配置参考链接：windows10 （64位）中MySQL8.0装置和配置 步骤一：主动生成root用户，能够不带明码：mysqld --initialize-insecure或者带随机明码：mysqld --initialize随机明码被保留在谬误日志里，位于（后面配置好的datadir）数据文件夹下，文件名为：主机名.err 步骤二：装置服务：mysqld -install启动服务：net start mysql进行服务：net stop mysql卸载服务：mysqld -remove 步骤三：无明码进入：mysql -u root有明码的进入形式：mysql -u root -p有明码的话进去就要求输出,随机明码的话地位下面提到过了 批改明码：ALTER USER 'root'@'localhost' IDENTIFIED BY 'password' PASSWORD EXPIRE NEVER; 更新明码：ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password'; 刷新权限：FLUSH PRIVILEGES; navicat装置以及破解对应链接https://www.ghpym.com/navicat...

数据库自增主键ID自增的主键的值是程序的，所以存储引擎（MyISAM、InnoDB）把每一条记录都存储在一条记录的前面。当达到页面的最大填充因子时候(innodb默认的最大填充因子是页大小的15/16，会留出1/16的空间留作当前的批改) 长处：下一条记录就会写入新的页中，一旦数据依照这种程序的形式加载，主键页就会近乎于程序的记录填满，晋升了页面的最大填充率，不会有页的节约；新插入的行肯定会在原有的最大数据行下一行，mysql定位和寻址很快，不会为计算新行的地位而做出额定的耗费；缩小了页决裂和碎片的产生。毛病：因为自增ID步进值是固定的，如果他人爬取数据库，会获取到业务增长信息，从而剖析出经营状况；如果在并发状况下写入，自增主键的上界会造成显著的锁挣用，并发插入会导致间隙锁竞争；Auto_Increment锁机制会造成自增锁的争夺，有肯定的性能损失。UUID的索引数据生成没有法则，无奈做到按顺序存储；写入的指标页很可能曾经刷新到磁盘上并且从缓存上移除，或者还没有被加载到缓存中，在插入之前存储引擎不得不先找到并从磁盘读取指标页到内存中，这将导致大量的随机IO；因为写入是乱序的，存储引擎不得不频繁的做页决裂操作，以便为新的行调配空间，页决裂导致挪动大量的数据，一次插入起码须要批改三个页以上；因为频繁的页决裂，页会变得稠密并被不规则的填充，最终会导致数据会有碎片

MySql的sql语句学习之instr()字符查找函数的应用： INSTR（str,substr） str：从哪个字符串中搜寻 substr:要搜寻的子字符串 instr()函数不辨别大小写instr(colName,string1)查问列名蕴含字符串1的后果，e.g,select userName from t_user_info where userName like concat("%",'江苏',"%"); 与select userName from t_user_info where instr(userName,'江苏');select userName from t_user_info where instr(userName,'江苏')>0;查问后果雷同SELECT INSTR(string1,string2)在string1中查找string2字符串并输入下标，e.g,https://www.cnblogs.com/mr-wuxiansheng/p/6531221.html

背景以后零碎数据量级别千万级或亿级，单表无奈撑持业务量，须要思考拆表或分表，且迁徙同时不能影响线上业务 详情千万或亿级数据量不能影响线上业务，零碎24小时运行，不可停机须要拆表迁徙数据计划思考到上述情况，在不影响线上业务的状况下，须要将业务数据同步至数据仓库，默认状况下每天凌晨同步前一天的增量&批改数据；再从数据仓库将数据迁徙至分表中，能够通过更新工夫的字段作为分界线，更新工夫小于选定值的数据为初始量，大于选定值得为增量；初始量同步实现后定期同步增量数据，直到写入新表的性能上线 数据同步至数仓选定字段宰割初始量、增量数据同步初始量数据定期同步增量数据零碎上线敞开数据同步下线旧表

 大家好，我是为宽广程序员兄弟操碎了心的小编，每天举荐一个小工具/源码，装满你的收藏夹，每天分享一个小技巧，让你轻松节俭开发效率，实现不加班不熬夜不掉头发，是我的指标！ 明天小编举荐一款建模工具——PDMan，是一款开源收费的数据库模型建模工具，反对Windows,Mac,Linux等操作系统，是PowerDesigner之外，更好的收费的代替计划。他具备颜值高，应用简略的特点。蕴含数据库建模，灵便主动的主动生成代码模板，主动生成文档等多种开发人员实用的性能。 开源协定 应用 MIT 开源许可协定 链接地址 公众号【Github导航站】回复关键词【pdman】获取git地址 PDMan介绍永远收费应用（ 敲黑板，重点 ），目前曾经应用MIT协定开源。性能简洁，去除艰涩难懂的设置，化繁为简，实用为上，上手非常容易。Windows，Mac，Linux三个平台均能够应用（ 敲黑板，重点 ）。自带参考案例，学习容易。新建一个我的项目，齐全不须要做任何配置。对开发极其敌对，可生成各种数据库以及编程语言的模型类。目前零碎默认实现了MySQL,Oracle,Java的代码主动生成，并且带正文。其余类型的数据库或语言，只须要增加相应的“数据库”并设置好相应的doT模板就能够了。一键主动生成MarkDown以及HTML格局的数据表构造文档，不便客户交付以及交换。数据库模型版本治理性能，在版本变动之后，可间接生成数据表构造的DDL语句。数据库模型设计间接同步至数据库。截图 主工作界面： 数据类型以及数据域： * 字段以及代码：* 生成文档: 结尾 本期就分享到这里，我是小编南风吹，专一分享好玩乏味、离奇、实用的开源我的项目及开发者工具、学习资源！心愿能与大家独特学习交换，欢送关注我的公众号【Github导航站】。

前言没有前言，废话不多说，间接开始面试面试开始面试官：什么是索引索引就是一种数据结构，进步检索效率的数据结构。比方B+树，哈希面试官：说说你对B+树的理解B+树是一颗均衡多叉树，绝对B树来说，B+树的数据只存在叶子节点。叶子节点组成链表，因而可反对范畴查问。B+树的查问效率为：O(logH),H为B+数的高度。面试官：为什么InnoDB应用B+树作为索引构造，而不必B树？首先B+树和B树比拟，B树因为非叶子节点也存储数据，因而非叶子能存储的内存页就少了。在雷同数据量时，B树的高度比B+树高，因而须要IO的次数更多，从而使得B树的总体效率慢于B+树。B树不反对范畴查问，因为B树的叶子节点没造成链表。B+树的数据都在叶子节点，查问性能更稳固。 面试官: 索引有哪些分类主键索引、非主键索引(一般索引、惟一索引、联结索引)面试官：主键索引和非主键索引有什么区别？在 InnoDB 里，主键索引也被称为聚簇索引，叶子节点存的是整行数据在 InnoDB 里，非主键索引也被称为二级索引，叶子节点内容是主键的值mysql> create table T(id int primary key, k int not null, name varchar(16),index (k))engine=InnoDB; 面试官：那你理解回表吗如果语句是 select * from T where ID=300，即主键查问形式，则只须要搜寻 ID 这棵 B+ 树；如果语句是 select * from T where k=3，即一般索引查问形式，则须要先搜寻 k 索引树，失去 ID 的值为 300，再到 ID 索引树搜寻一次。这个过程称为回表。也就是说，基于非主键索引的查问须要多扫描一棵索引树。因而，咱们在利用中应该尽量应用主键查问。面试官：命中索引的准则？只有满足”笼罩索引准则“或”最左前缀准则“中的任意一个，都可应用索引。详情见MySQL索引应用规定面试官：什么是笼罩索引？笼罩索引，就是指一个查问语句的执行只用从索引中就可能获得，不用从数据表中读取。也能够称之为实现了索引笼罩。面试官：最初一个问题，遇到慢查问时，如何解决？定位问题：首先通过查问慢日志，确定具体是哪条SQL语句呈现了慢查问剖析问题：接着，SQL慢的起因个别有2种，一是没用索引，二是用错索引解决问题：如果是没用索引，那咱们能够应用explain来剖析SQL语句，确定是否应用了索引。如果应用了索引，是否用对索引，如果用错索引了，就应用force index()来强制应用某个索引。如果面试官持续问你，为什么会用错索引？简略点说，InnoDB抉择应用哪个索引是依据一个值来确定的，而这个值是依据样本值算进去的，因为是样本，抽样就比拟随机，因而出错也不是不可能的。面试官：面试完结 祝贺进入下一轮面试总结其实，对于索引还有很多知识点的，这里不一一开展抉择什么字段做索引索引下推explain的字段的含意，如何依据字段来调优絮叨非常感谢你能看到这里，如果感觉文章写得不错 求关注 求点赞 求分享 (对我十分十分有用)。 如果你感觉文章有待进步，我非常期待你对我的倡议，求留言。 如果你心愿看到什么内容，我非常期待你的留言。 各位的捧场和反对，是我创作的最大能源！ 参考资料《高性能MySQL》《MYSQL实战45讲》

概述XtraBackup 是一款对于 MySQL 物理备份必不可少的工具，然而有时候在备份数据量级较大的数据库时，如果未做优化的话，还是有点慢，当然绝对于逻辑备份，未然是很快了，那到底还能不能再快一点呢，又是什么参数在影响着 XtrBackup 的备份速度呢？带着这个疑难咱们往下看。 首先咱们须要先理解 XtraBackup 的备份原理，话不多说间接看图。 如图所示： 1.当 innobackupex 命令开始备份的时候，首先会启动 xtrabackup 过程，xtrabackup 又分为两个线程，一个用于拷贝 ibd 文件，一个用于拷贝 redo 文件，redo 的拷贝线程只有一个，在 ibd 的拷贝线程启动前启动，在 ibd 的拷贝线程完结后完结。 2.xtrabackup 拷贝实现 idb 后，告诉 innobackupex（通过创立文件），同时本人进入期待（redo 线程依然持续拷贝） 3.innobackupex 收到 xtrabackup 告诉后，执行 FLUSH TABLES WITH READ LOCK (FTWRL)，获得一致性地位点，而后开始备份非 InnoDB 文件（包含 frm、MYD、MYI、CSV、opt、par 等）。拷贝非 InnoDB 文件过程中，因为数据库处于全局只读状态，非 InnoDB 表（次要 是MyISAM）如果比拟多的话整库只读工夫就会比拟长。 4.当 innobackupex 拷贝完所有非 InnoDB 表文件后，告诉 xtrabackup（通过删文件） ，同时本人进入期待（期待另一个文件被创立）； 5.xtrabackup 收到 innobackupex 备份完非 InnoDB 告诉后，就进行 redo 拷贝线程，而后告诉 innobackupex，redo log 拷贝实现（通过创立文件）； ...

近期，不少小伙伴在征询redash怎么连贯MySQL数据源，上面介绍两种常见环境下的配置办法，其余形式装置的也能够参考： Centos8连贯mysql数据源 1)、执行命令装置mysql: sudo yum install mysql 2)、验证是否装置胜利: which mysql which mysqldump 3)、登陆进入mysql数据库,创立近程登录用户并受权: 例子:(其中root是登陆的用户,123456是登陆密码) GRANT ALL PRIVILEGES ON . TO 'root'@'%' IDENTIFIED BY '123456' WITH GRANT OPTION; 4)、而后开启MySQL的近程登录账号: flush privileges; 5)、查看你的mysql服务器ip地址,获取到ip地址之后进入centos8下执行: (root代表mysql数据库登陆用户名,123456代表mysql数据库登陆密码,192.168.137.1代表mysql数据库ip地址,3306是端口,test是数据库) mysql -u root -p123456 -h 192.168.137.1 -P 3306 -D test 6)、装置mysql数据源在redash中能够连贯 1.在centos8命令行装置mysql-devel: sudo yum install mysql-devel 2.进入redash目录下执行: source venv/bin/activate pip3 install mysqlclient 运行实现即可登陆redash在新建数据源外面抉择mysql数据源填入相干参数即可 Docker环境配置MySQL数据源 1.通过docker image ls 找到原来的redash镜像id，这里假如为aaabbb 2.启动一个redash的docker环境 docker run -ti <redash镜像id> /bin/bash 示例：docker run -ti aaabbb /bin/bash ...

MySQL的根本架构示意图，从中你能够分明地看到SQL语句在MySQL的各个功能模块中的执行过程。 MySQL的逻辑架构图 大体来说，MySQL能够分为Server层和存储引擎层两局部。 Server层包含连接器、查问缓存、分析器、优化器、执行器等，涵盖MySQL的大多数外围服务性能，以及所有的内置函数（如日期、工夫、数学和加密函数等），所有跨存储引擎的性能都在这一层实现，比方存储过程、触发器、视图等。

序列号治理本文通过产品编码和订单流水号介绍一下序列号(Sequence)在crudapi中的利用。 概要序列号MySQL数据库没有独自的Sequence，只反对自增长(increment)主键，然而不能设置步长、开始索引、格局等，最重要的是一张表只能由一个字段应用自增，但有的时候咱们须要多个字段实现序列号性能或者须要反对简单格局，MySQL自身是实现不了的，所以crudapi封装了简单序列号，反对字符串和数字，自定义格局，也能够设置为工夫戳。能够用于产品编码、订单流水号等场景！ 配置序列号产品编码产品编码采纳字符串形式，格局为：PROD_%09d，示意长度为9，宽度有余用0补齐，最小值从1开始， 最大值为999999999，下一个值为1，步长为1。 销售订单流水号产品编码采纳工夫戳形式，格局为：'SO'yyyyMMddHHmmssSSS，SO示意前缀，准确到年月日时分秒毫秒 表定义配置序列号属性产品编码产品表配置序列号字段 销售订单流水号销售订单表配置序列号字段 验证序列号性能产品通过ui创立产品，因为编码字段设置了序列号，所以留空，这样后盾会主动生成编码，如果编码字段手工输出，就以手工输入地值为准。 生成的编码为PROD_000000001，和冀望的统一。 销售订单通过Postman创立销售订单 ui查看订单列表，流水号发现SO20210212110955912生成胜利 高级序列号API序列号提供了获取下一个值性能的API，适宜UI定制的场景，显式的把值显示在ui上，这样更加直观，然而如果用户不点保留或者保留失败的话，可能会节约值。查看swagger文档：https://demo.crudapi.cn/swagger-ui.html 验证通过Postman获取到下一个值为PROD_000000002 小结本文通过配置序列号的形式实现了特定字段的主动赋值性能，无需编码，并且反对二次开发。目前有点不欠缺的中央，产品和销售订单都是孤立的单表，后续会介绍如果配置表关系，实现一对多，一对一，多对多等奴才表。 附demo演示本零碎属于产品级的零代码平台，不同于主动代码生成器，不须要生成Controller、Service、Repository、Entity等业务代码，程序运行起来就能够应用，真正0代码，能够笼罩根本的和业务无关的CRUD RESTful API。 官网地址：https://crudapi.cn 测试地址：https://demo.crudapi.cn/crudapi/login

开源软件遇到问题该怎么发问能力解决？身为程序员，在这一行业都是从一个一个坑里爬出来的。 古人云：知之为知之，不知为不知，是知也。 所以嘛咱不懂就要问，但其实问问题也是有肯定的学识和技巧的。 一个刚入行的菜鸟遇到的问题可能90%在网络上都能搜失去，因为问题的造成过程就产生了很多答案围绕着它。当初这个网络发达的时代轻易搜寻下基本上都能找到前辈留下的填坑办法。 然而，比拟好受的是不乏有些同学喜爱认徒弟，当然这是坏事哈。但也不能凡是遇到问题就去找徒弟，徒弟也有本人的事件的对吧。如果你把遇到任何问题就找徒弟的形式看成和徒弟套近乎等等就大错特错了。 上面咱们以开源软件为例看看咱们遇到问题要怎么解决。 软件是什么：百度百科是这么定义的 维基百科是这么定义的 我上学的时候老师是这么定义的： 软件 [一个能够执行指令集的汇合工具]比拟侥幸的是当初开源代码很多，github gitee 领有大量优质开源我的项目，比方本人有需要但懒得写或者说造轮子，先去github 或者 码云上看看，用藏在眼镜片前面的火眼金睛来判断一个生疏的我的项目品质，你只能依据他的排名，star以及论坛炽热水平来判断。尽管这些不能齐全代表我的项目品质的优和差但方向总是对的。 然而逆向思维设想，可能有些我的项目刚起步排名低，然而品质并不比那些成千上万的star差，他差的仅仅是开源的工夫和宣传的力度。其实这个和现实生活中根本一样，你这家店开的早，知名度等等就比新店要高一点。 问题是怎么产生的？任何一个开源我的项目从你下载到本地，配置运行环境和各种环境变量，以及第三方服务，数据库，缓存框架，http服务等等都是个要仔细顺着官网的文档一步步来实现的。 这就像你从乐高玩具店买回来玩具一样的，你不能间接关上包装装置的吧，总的看看图纸，即便很相熟也得大略看下这个是玩具的大略设计之后能力以最快的速度拼装起来。当然你说我不看图纸也能装起来，我确定这种人必定有，但咱们明天就不叫这个真了哈。 什么欠缺的产品都有个阐明文档或者装置教程，咱们想要疾速的运行本人想要的我的项目就得依据文档来，什么长久服务，缓存服务依据软件设计须要配置即可，但这个过程中依据零碎差别会有不同。 以java环境为例，windows 和 Mac 环境好配置形式就不太一样，nginx等等都是大同小异，很多小白在开始可能就被这些差别搞得死去活来的，还别说因为平台差别导致代码运行时呈现的bug了，是不是想想脑袋都大了。 下面形容的还只是配置环境问题，软件个别可不止这么简略，还牵扯到第三方服务，比方和社交软件api对接，调用打印机，调用上下游api传递业务数据，很多时候可能因为一个配置的字符不对都运行不起来。软件开发毕竟是软件开发不是软件使用者哈，这就也体现出程序员就是把问题本人消化，输出优质软件供大家应用，这里给中国30万+的程序员点赞。 那么遇到问题该怎么办？首先还是的从官网文档或者教程中找，尤其是文档，可能因为本人的了解和书写人的思维有着差别，导致你须要的答案跟看见的目录不对应，这样你找本人的答案就比拟艰难了，然而当初但凡文档基本上都有搜寻性能，依据目录找不到就搜寻嘛，切实不行感觉他就在这个分类下 control + f 总能够的吧，针对线上线下的文档算是杀手锏了吧！ 所以依据官网文档看下来能看到最好，看不到就搜寻即可，什么搜不到？咱们持续往下看。 因为各种起因导致使用者找不到本人问题的解决方案怎么办？这时候能够百度，毕竟搜索引擎会帮咱们找到或者偏差本人想要找的答案，也要应用好问题的关键词，这样搜索引擎会更容易更精确的帮咱们找到对应问题的解决方案。 对于搜寻关键字搜搜咱们能够另外拿进去一篇文章讲讲 依据以上办法你可能就毁灭掉了百分十90%的问题了，开源软件也是应用编程语言编写的么，和本人做公司的我的项目仅仅是业务不同而已，所以问题的呈现基本上是通用的。 什么还有问题？ 这时候你遇到的问题可能就是开源软件本人的特殊化配置或者真的是坑了。 那么遇到了怎么办？开源软件也有本人的仓库，官网，交换群或者论坛等等，通过这些形式分割开发者总是能够解决的吧！ 如果真的是问题，给他的仓库提交pr也是一种解决形式对吧！ 看了半天你在教我怎么查问题吗？不我是在探讨怎么无效的提问题！来看看群里遇到了这个同学的发问，你感觉我该怎么答复。 第一：发问肯定要有前因后果，你间接截图一个谬误区域只是让对方猜你遇到了什么问题，个别人没有那么闲。第二：提问题肯定要图文汇合讲清楚，要是图文不对应对方也只会是一头雾水的吃瓜和傻笑第三：如果牵扯到新的只是区域，即便你焦急应用也至多得不求甚解的会用。而不是抛给对方你没用过不晓得，对，是的我当场气的吐血了。对于怎么发问其实这个话题很早就呈现了，也有很多大大牛回答的比我好比我更业余。这里我举荐大家浏览 How-To-Ask-Question-The-Smart-Way https://github.com/tvvocold/H... 结语：最初我廓清下哈，我也是从菜鸟过去的，我也晓得那种无助的感觉。尤其是在赶我的项目的时候遇到了本人的只是盲区或者技术难点。那种焦急我懂得。然而越是在那个时候就得月放弃沉着，既然有问题那么必定能解决。然而很多问题可能一时半会还真解决不了，那么咱们也能够想方法绕过去。总之必定能解决或者变相的解决 从业这么多年来很多时候提的问题被他人笑话过，也笑话过他人（狗头）但最终讲下来我还是比拟乐于答复问题的，因为帮忙别人解决问题之后的那种认同感是促成本人常识输出的能源 喜爱本文的敌人，欢送关注微信公众号 东南大粽子 每周继续更新1-2篇原创内容，在工作和生存的路上一起学习闹闹磕。码字不易点赞 再看 扩散我参加的一个电商开源我的项目，每月都会固定更新性能和bug优化。拜访戳这里

1.Lambda表达式简介 Lambda表达式是java 1.8才开始有的重要性能，应用Lambda表达式能够代替匿名外部类，代码简洁易懂，晋升工作效率。上代码： 2.函数式接口简介 有且只有一个形象办法（能够蕴含default或static办法，但Object类除外）的接口是函数式接口。@FunctionlInterface就是用来指定某个接口必须是函数式接口。@FunctionalInterface不是必须的，只是通知编译器查看这个接口，保障该接口只能蕴含一个形象办法，否则就会编译出错。@FunctionalInterface次要是帮忙程序员防止一些低级谬误，比方多个形象办法。 3.Java 1.8之前的函数式接口java.util.Comparator //排序接口java.lang.Runnable //线程无返回值接口java.util.concurrent.Callable<V> //线程有返回值接口java.lang.reflect.InvocationHandler //动静代理接口等等...... 4.罕用的函数式接口Java1.8函数式接口都在rt.jar的java.util.function包中，以下是常常用到的函数式接口（肯定要熟记，其余的函数式接口都是在这些函数式接口上的扩大）：~~~~ 自定义函数式接口① 定义一个无参无返回值的函数式接口 ② 定义蕴含default、static办法的无参有返回值的函数式接口 ③ 定义有一个参数，无返回值的函数式接口 6.自定义函数式接口测试 @Testpublic void testMyFuncationInterface() { // 1.无参无返回值 IBossService boss = () -> System.out.println(" invoke m3"); boss.m3(); // 2.无参有返回值 IBossService3<String> boss3 = () -> "m3"; boss3.m3(); // 3.有参无返回值 IBossService2<String> boss2 = e -> System.out.println("param:" + e); boss2.m3("lambda"); // 4.有参有返回值 IBossService4<String, Integer> boss4 = e -> 1; boss4.m3("lambda");}@FunctionalInterfaceinterface IBossService { static int m2() { return 2; } default void m1() { System.out.println("m1"); } void m3();}@FunctionalInterfaceinterface IBossService3<R> { static int m2() { return 2; } default void m1() { System.out.println("m1"); } R m3();}@FunctionalInterfaceinterface IBossService2<E> { static int m2() { return 2; } default void m1() { System.out.println("m1"); } void m3(E e);}@FunctionalInterfaceinterface IBossService4<T, R> { static int m2() { return 2; } default void m1() { System.out.println("m1"); } R m3(T t);}

索引的常见模型哈希表基于散列函数，不是有序的，而且散列抵触带来的链表构造等，会导致哈希索引做区间查问的速度很慢。因而这种构造实用于只有等值查问的场景，比方 Memcached 及其他一些 NoSQL 引擎。有序数组有序数组在等值查问和范畴查问场景中的性能就都十分优良,然而在须要增或删数据的时候就麻烦了，往两头插入一个记录就必须得移动前面所有的记录，老本太高。只实用于动态存储引擎搜寻树等值查问和范畴查问性能都很好，且增或删数据也很不便，被广泛应用在数据库引擎中。基于主键索引和一般索引的查问有什么区别？如果语句是 select * from T where ID=500，即主键查问形式，则只须要搜寻 ID 这棵 B+ 树；如果语句是 select * from T where k=5，即一般索引查问形式，则须要先搜寻 k 索引树，失去 ID 的值为 500，再到 ID 索引树搜寻一次。这个过程称为回表。也就是说，基于非主键索引的查问须要多扫描一棵索引树。因而，咱们在利用中应该尽量应用主键查问。 联结索引假如，咱们对(a,b)字段建设索引，那么入下图所示他们是依照a来进行排序，在a相等的状况下，才按b来排序。 因而，咱们能够看到a是有序的1，1，2，2，3，3。而b是一种全局无序，部分绝对有序状态! 什么意思呢？ 从全局来看，b的值为1，2，1，4，1，2，是无序的。 从部分来看，当a的值确定的时候，b是有序的。例如a = 1时，b值为1，2是有序的状态。当a=2时候，b的值为1,4也是有序状态。 最左前缀依据联结索引剖析，咱们能够晓得，联结索引跟程序无关。因而，当执行a = 1 and b = 2是a,b字段能用到索引的。而执行a > 1 and b = 2时，a字段能用到索引，b字段用不到索引。因为a的值此时是一个范畴，不是固定的，在这个范畴内b值不是有序的，因而b字段用不上索引。这就是最左匹配准则，在遇到范畴查问的时候，就会进行匹配。 以下是一些例子：例1:建设索引(a,b,c)、(b,a,c)、(c,a,b)都能够，因为无范畴查问，优化器会主动判断抉择索引 SELECT * FROM table WHERE a = 1 and b = 2 and c = 3;例2:建设索引(b,a) SELECT * FROM table WHERE a > 1 and b = 2;例3:(b,a)或者(b,c)都能够，要联合具体情况具体分析 ...

前言面试高频题，首先要了解ReadView，而后要区别可反复读和提交读ReadView的不同点 ReadViewm_ids：示意在生成READVIEW时以后零碎中沉闷的读写事务的事务id列表，沉闷的是指以后零碎中那些尚未提交的事务；min_trx_id：示意在生成READVIEW时以后零碎中沉闷的读写事务中最小的事务id，也就是m_ids中的最小值；max_trx_id：示意生成READVIEW时零碎中应该调配给下一个事务的事务id值，因为事务id个别是递增调配的，所以max_trx_id就是m_ids中最大的那个id再加上1；creator_trx_id：示意生成该READVIEW的事务id，因为只有在对表中记录做改变（增删改）时才会为事务调配事务id，所以在一个读取数据的事务中的事务id默认为0； 读取规定1、版本的trx_id==READVIEW中的creator_trx_id，示意以后读事务正在读取被本人批改过的记录，该版本能够被以后事务拜访；2、版本trx_id < min_trx_id，表明生成该版本的事务在以后事务生成READVIEW前曾经提交了，所以该版本能够被以后事务拜访；3、版本的trx_id > max_trx_id，表明生成该版本的事务在以后事务生成READVIEW后才开启的，该版本不可被以后事务拜访；4、版本的trx_id在READVIEW的min_trx_id和max_trx_id之间，那就须要判断一下trx_id属性值是不是在m_ids中。如果在这个范畴内，阐明创立READVIEW时该事务还处于沉闷状态，该版本不能够被以后事务拜访；如果不在，阐明创立READVIEW时生成该版本的事务曾经被提交，该版本能够被以后事务拜访； 原理基于ReadView机制能够实现RC隔离级别，即每次查问的时候都生成一个ReadView，这样的话，只有在这次查问之前有别的事务提交了（ m_ids 列表产生变换），那么别的事务更新的数据，是能够看到的。 那么如果是RR级别呢？RR级别下，这个事务读一条数据，无论读多少次，都是一个值，别的事务批改数据之后哪怕提交了，也是看不到人家批改的值的，这就防止了不可反复读的问题。同时如果别的事务插入了一些新的数据，也是读不到的，这样就能够防止幻读的问题。 例子首先假如有一条数据是事务id=50的一个事务插入的，同时此时有事务A和事务B同时在运行，事务A的id是60，事务B的id是70，如下图所示： 这个时候，事务A发动了一个查问，它就是第一次查问就会生成一个ReadView，此时ReadView里的creator_trx_id是60，min_trx_id是60，max_trx_id是71，m_ids是[60, 70]，此时ReadView如下图所示： 这个时候事务A基于这个ReadView去查这条数据，会发现这条数据的trx_id为50，是小于ReadView里的min_trx_id的，阐明它发动查问之前，早就有事务插入这条数据还提交了，所以此时能够查到这条原始值的，如下图： 接着就是事务B此时更新了这条数据的值为值B，此时会批改trx_id为70，同时生成一个undo log，而且要害是事务B此时它还提交了，也就是说此时事务B曾经完结了，如下图所示： 事务A去查问这条数据的值，会诧异的发现此时数据的trx_id是70了，因为在RR级别，ReadView不会扭转，依据ReadView的读取规定能够晓得事务A不能查到txr_id=70对应的数据，而是会顺着undo指针找到原始值，所以事务A在事务B批改数据的前后读取的数据是一样的。 参考：《2020最新Java根底精讲视频教程和学习路线！》链接：https://juejin.cn/post/693721...

读写拆散基于MySql本身提供的主从复制架构，写操作申请发往主库，读操作申请发往从库。一个主库能够挂多个从库。主库实现写操作后，将数据通过binlog形式同步给从库。 主从复制工作原理主库实现写操作后，将变更写入binlog日志，从库的IO线程从主库的binlog日志拉取拷贝数据变更日志，写入到relay中继日志，而后从库的SQL线程从relay日志中重放sql写操作，实现数据的同步。 主从复制延时较长解决方案因为从库从主库拷贝日志以及串行执行SQL的特点，在高并发状况下，从库与主库的数据同步是有延时的。换句话说，在主库刚写入的数据，在从库不肯定立马能读到。这就须要肯定的策略来解决这个问题。常见的解决方案有两种（均基于MySql提供的机制）：1.半同步复制：在主库写入数据时，强制串行同步到从库，期待至多一个从库的IO线程写入relay中继日志并回复ack报文后，才认为写操作实现。2.并行复制：从库开启多个SQL线程，并行执行relay日志的不同库的binlog变更操作，而后并行重放SQL变更操作，相比串行可能达到升高延时的目标。 另外，在应用程序和MySql架构层面，也有如下计划：1.设计多主构造，单个主库写压力过大导致的延时问题，摊派到多个主库，可能升高同步延时。2.刚写入的数据，如果想立马读出来，就不从从库读，改为强制从主库读取，防止延时导致的读取不到数据问题。3.重写代码，对于不要求立马读出来的业务场景，尽可能不立马读数据，等一会再读。

前言： 时常有听到各公司数据库故障的案例，比方数据库宕机了、误删数据了、歹意删库了等等。可能还有更多的故障没有披露进去。每次产生此类事件，都会在互联网圈引起热议，其实更应该留下的是警醒，咱们应该足够器重数据库安全问题，对数据库要有敬畏之心。 1.案列盘点咱们再来回顾下近几年互联网圈产生过的“删库事件”。 2018 年 9 月份，据网上信息披露，顺丰科技数据中心的一位邓某因误删生产数据库，导致某项服务无奈应用并继续 590 分钟，最终公司决定解雇工程师邓某，并在顺丰内网通报。 邓某错选了 RUSS 数据库，打算删除执行的 SQL。在选定删除时，因其操作不谨严，光标回跳到 RUSS 库的实例，在未看清所选内容的状况下，便通过 delete 执行删除，同时邓某疏忽了弹窗揭示，间接回车，导致 RUSS 生产数据库被删掉。因运维工作人员不谨严的操作，导致 OMCS 经营监控管控零碎产生故障，该零碎上长期线上发车性能无奈应用并继续了 590 分钟2020 年 2 月 23 日，微盟运维人员贺某因集体精力、生存等起因对微盟线上生产环境进行了歹意毁坏，间接导致公司 SaaS 业务忽然解体，基于微盟的商家小程序都处于宕机状态，300万家商户生意根本停摆，生意快做不上来了。同时，微盟本身也遭受巨大损失，短短几天公司市值就蒸发超过 20 亿港元。 事件产生后，微盟团队与腾讯云团队并肩作战，尽全力放松修复，直到 3 月 1 日早晨 8 点，数据终于全面找回，并于 3 月 3 日上午 9 点数据恢复正式上线。只管作恶的贺某在第一工夫被警方抓获，但并不足以补救给微盟、商家带来的损失。 2.教训与教训从以上案例咱们能够看到，一旦数据库产生重大故障，负面影响会十分大，对公司造成极大的损失。造成事件的次要人员也可能面临被解雇或负刑事责任的危险。 有人说了，为啥数据库故障这么难修复，不是都有备份的吗？其实还是想得太简略。真的产生此类故障，可能首先须要冷静下来制订复原策略，要思考最新的备份是什么时候的，是否可用，新产生的数据如何补齐，复原工夫预计多久，呈现数据抵触问题如何解决等等。 那么咱们从此类事件中能够失去哪些教训与教训呢？若想尽可能防止数据库故障，谈一谈笔者本人的认识。 公司制度方面： 通过堡垒机管制服务器权限，做好环境辨别，最好有运维审计零碎。有具体的数据库变更流程，并责任落实到岗到人。定期检查备份可用性，制订周期性演练打算。数据库方面： 极力欠缺数据库高可用架构，最好能够留个提早从库。数据库账号权限尽可能小，不容许集体应用程序账号。有残缺的周期性备份策略，最好减少异地备份。减少数据库审计，对数据库流量或日志审计，设定告警告诉机制。技术人员方面： 相熟你应用的可视化工具，SQL要看清楚再执行。生疏环境不要操作，特地是古老的环境。不做本人职责以外的操作。数据变更之前记得备份。高危操作要有 check 机制，请共事帮忙测验。不要在疲劳状态下操作数据库。要有责任心，记得本人操作了啥，出问题不要回避。总结： 写本篇文章的目标是为了告诫大家，对数据库要有敬畏之心，不要认为天经地义，可能一个很小的操作会导致很重大的结果。当然，人非圣贤孰能无过，兴许只有经验过一些事变能力更好的成长，咱们要做的就是尽可能减少事变产生。

前言：最近我的项目中的定时工作生产队列始终呈现一个反复的惟一主键谬误，是多个事务对同一行数据进行操作引起的。解决这个问题后，我便写了这篇博客的草稿，由ctx同学强势审核批改后，便有了这一版本的博客。场景复现出错办法： private void handleAccountRisk(String accountUuid, float risk, RiskConfEtcdVo riskConf, Long currentTimeSeconds) { // 分布式锁 String redisKey = RISK_UPDATE_LOCK_KEY.replace("${item}", accountUuid); String businessId = BusinessIdGeneratorUtil.businessId(); redissonLockUtil.lock(redisKey,businessId, () -> { AccountRiskEntity accountRisk = accountRiskTplDao.getAccountRiskByUuid(accountUuid); // 如果accountRisk不存在则新增 if (null == accountRisk) { // 实例化一个对象后填充... // insert accountRiskTplDao.save(target); // 如果存在则更新 } else { ... accountRiskTplDao.updateById(accountRisk); ... } });}报错信息： INSERT INTO account_risk ( create_time, update_time, risk, uuid ) VALUES ( ?, ?, ?,com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry 'dc57ktzmtiwp' for key 'uuid' 问题剖析从Duplicate entry推断出反复插入。具体起因为： ...

摘要：一篇文章带你彻底理解MySQL各种束缚MySQL束缚<1> 概念· 是一种限度，它是对表的行和列的数据做出束缚，确保表中数据的完整性和唯一性。 <2> 应用场景· 创立表的时候，增加束缚 <3> 分类· default: 默认束缚, 域完整性 · not null: 非空束缚，域完整性 · unique: 惟一束缚，实体完整性 · primary key: 主键束缚，实体完整性 · foreign key: 外键束缚，参照完整性 · check: 查看束缚（MySQL不反对），域完整性 · auto_increment: 自增长束缚 · unsigned: 无符号束缚 · zerofill: 零填充束缚 数据库中有三个完整性: 域、实体、参照完整性 · 域(列)完整性： o 域完整性是对数据表中字段属性的束缚 · 实体完整性在MySQL中实现： o 通过主键束缚和候选键束缚实现的 · 参照完整性： o 也就是说是MySQL的外键 1. default · 概念 o 指定某列的默认值，插入数据时候，此列没有值，则用default指定的值来填充 · 增加 o 在创立表的时候增加： create … default § create table t1(id int default 1,name varchar(20) default ‘老王’); ...

最近做了一个前后端拆散的商城我的项目来相熟开发的整个流程，最初心愿能有个正式的部署流程，于是试着把我的项目放在云服务器上，做了一下发现遇到了不少问题，借此记录一下整个部署的过程。 应用的技术栈如题目所说大体上是Vue+Spring boot，但还是要提一下具体的版本，因为在解决问题的过程中发现因为开发环境的不同会产生诸多影响，查找问题时如果没有版本作为前提常常会呈现很多不必要的误会，甚至是误操作，十分浪费时间。具体版本状况如下： Vue 2.6.11Vue-cli 4.5.0Spring boot 2.1.1MySQL 8.0.13 （尤其留神）Nginx1 上传工具部署的第一步要把文件上传至云服务器，并且后续还要在云服务器上进行操作，办法很多，我这里抉择了Xshell和Xftp这两个工具，均出自NETSARANG这家公司，须要留神的是在国内的官网上暗藏了收费家庭版的申请地址，能够通过间接拜访 Xshell、Xftp收费许可 进行下载，须要填写姓名和邮箱。 1.1 Xftp首先在Xftp中新建连贯，填写主机地址和用户名明码，连贯胜利就能够看到左侧选项卡为本地的文件目录，右侧为云服务器的文件目录，只有从左侧或右侧将文件拖动到另一边就能够实现相应文件的上传和下载，下方传输选项卡会显示具体进度，图形化的界面相当直观，不做过多的阐明了。 对于Linux的目录标准我没有查到太多须要的信息，所以我这里是在根目录新建了一个名为 app 的文件夹来寄存网站利用，对于网站的打包咱们在下一节阐明，这里咱们把握如何上传文件就能够。 1.2 XshellXshell的连贯建设办法与Xftp差不多，填写主机地址，连贯后再输出用户名明码，连贯后就能够在云服务器上进行操作了。 通过这两个工具与云服务器建立联系后咱们就能够开始着眼于网站利用本身的问题了。 2 前端相对来说前端的部署没有遇到太多问题，所以咱们先从前端开始 2.1 Vue因为我应用了Vue-cli，所以我的项目实现后通过执行命令 npm run build 程序就会主动打包到我的项目目录下的 dist 文件夹，打包后的目录构造如下： 之后通过Xftp将这个文件夹上传至云服务器上，之前我曾经新建了一个文件夹来寄存，因为咱们还可能有其余我的项目，并且后盾也须要一个文件夹，所以建设具体文件夹构造如下： 新建文件夹能够应用Xftp的图形界面疾速建设，也能够在Xshell中应用指令，看集体的爱好和习惯，如果须要常常应用Linux零碎，倡议应用指令多加练习。 在Windows端进行开发的时候，在控制台应用 npm run serve 指令就能够疾速启动一个本地网站，然而这样的网站只能在内网被拜访，必定是达不到咱们最后在外网拜访的目标，所以这里要借助反向代理服务器，我抉择的是被宽泛应用的Nginx。 2.2 Nginx选定装置目录cd /usr/local/src 在服务器上安装Nginx之前先装置若干依赖：yum install gccyum install pcre-develyum install zlib zlib-develyum install openssl openssl-devel这些依赖的作用能够参考这一篇 Linux上装置Nginx依赖环境和库、Nginx装置，Nginx服务命令，我没有逐个试过短少某个依赖会有什么问题，在装置Nginx之前就曾经装置好这些依赖了。 下载Nginx安装包并解压能够从官网抉择须要的版本。 wget http://nginx.org/download/nginx-1.13.7.tar.gz #下载tar -xvf nginx-1.13.7.tar.gz #解压执行配置并装置cd nginx-1.13.7 #切换目录./configure #执行配置make && make install #编译装置（默认装置在/usr/local/nginx）装置实现后查看版本无误启动/usr/local/nginx/sbin/nginx -v #查看版本cd /usr/local/nginx/sbin #cd到nginx的装置地位的sbin目录下./nginx #启动nginx 这里能够先拜访一下服务器的外网IP试试，呈现 Welcome to nginx 就阐明曾经启动胜利了。 ...

背景近期线上MySQL 5.7.20集群不定期（多则三周，短则一两天）呈现主库mysql crash、触发主从切换问题，堆栈信息如下； 从堆栈信息能够显著看出，在调用 try_acquire_lock_impl 时触发的crash。 剖析在官网Bug库未搜到相似问题，转而从代码库动手，搜到对应的BUG —— 8bc828b982f678d6b57c1853bbe78080c8f84e84： BUG#26502135: MYSQLD SEGFAULTS IN MDL_CONTEXT::TRY_ACQUIRE_LOCK_IMPLANALYSIS:=========Server sometimes exited when multiple threads tried toacquire and release metadata locks simultaneously (forexample, necessary to access a table). The same problemcould have occurred when new objects were registered/deregistered in Performance Schema.The problem was caused by a bug in LF_HASH - our lock freehash implementation which is used by metadata lockingsubsystem in 5.7 branch. In 5.5 and 5.6 we only use LF_HASHin Performance Schema Instrumentation implementation. Sofor these versions, the problem was limited to P_S.The problem was in my_lfind() function, which searches forthe specific hash element by going through the elementslist. During this search it loads information about elementchecked such as key pointer and hash value into localvariables. Then it confirms that they are not corrupted byconcurrent delete operation (which will set pointer to 0)by checking if element is still in the list. The lattercheck did not take into account that compiler (andprocessor) can reorder reads in such a way that load of keypointer will happen after it, making result of the checkinvalid.FIX:====This patch fixes the problem by ensuring that no suchreordering can take place. This is achieved by usingmy_atomic_loadptr() which contains compiler and processormemory barriers for the check mentioned above and othersimilar places.The default (for non-Windows systems) implementation ofmy_atomic*() relies on old __sync intrisics and implementsmy_atomic_loadptr() as read-modify operation. To avoidscalability/performance penalty associated with addition ofmy_atomic_loadptr()'s we change the my_atomic*() to usenewer __atomic intrisics when available. This new defaultimplementation doesn't have such a drawback.大体含意是： ...

前言查问优化、索引优化、库表构造优化须要齐头并进，一个不落。 最佳实际是否在检索大量的数据行大多数的慢查问都是因为检索了大量的数据行导致的。 每次看到select * 时都应该有狐疑扫视的眼光1.不必要的列可能导致过多的IO/CPU/内存耗费。2.无奈应用笼罩索引晋升性能。 不要反复执行雷同的查问例如用户头像URL，该当在首次查问后缓存起来。 查看3个指标响应工夫扫描的行数返回的行数响应工夫 = 服务工夫 + 排队工夫。服务工夫是指数据库解决查问时真正花了多少工夫，排队工夫是指服务器因为期待某个资源而没能真正执行查问的工夫，如期待IO实现，期待行锁等。 抉择一个简单查问还是多个简略查问 切分查问删除旧数据就是一个很好的例子。有时候，将多个join查问拆分成屡次单表查问更无效。 了解查问背地的工作原理

什么是索引？ 数据库索引是一种数据结构，它以额定的写入和存储空间为代价来进步数据库表上数据检索操作的速度。艰深来说，索引相似于书的目录，依据其中记录的页码能够疾速找到所需的内容。——维基百科常见索引有哪些？ 一般索引：最根本的索引，没有任何限度惟一索引：与”一般索引“相似，不同的就是：索引列的值必须是惟一，但容许有空值主键索引：它是一种非凡的索引，不容许有空值全文索引：仅可用于 MyISAM 表，针对较大的数据，生成全文索引很耗时占空间组合索引：为了进步多条件查问效率，可建设组合索引，遵循”最左前缀匹配准则“这里以绝对简单的组合为例，介绍如何优化。 最左前缀匹配准则首先咱们要晓得什么是最左前缀匹配准则。 最左前缀匹配准则是指在应用 B+Tree 联结索引进行数据检索时，MySQL 优化器会读取谓词（过滤条件）并依照联结索引字段创立程序始终向右匹配直到遇到范畴查问或非等值查问后进行匹配，此字段之后的索引列不会被应用，这时计算 key_len 能够剖析出联结索引理论应用了哪些索引列。 如何计算 key_len通过 key_len 计算也帮忙咱们理解索引的最左前缀匹配准则。 key_len 示意失去后果集所应用的抉择索引的长度[字节数]，不包含 order by，也就是说如果 order by 也应用了索引则 key_len 不计算在内。 在计算 key_len 之前，先来复习一下根本数据类型（以UTF8 编码为例）： 类型所占空间不容许为NULL额定占用char一个字符三个字节一个字节varchar一个字符三个字节一个字节int四个字节一个字节tinyint一个字节一个字节测试数据表如下： CREATE TABLE `test_table` ( `id` int(11) NOT NULL AUTO_INCREMENT, `a` int(11) DEFAULT NOT NULL, `b` int(11) DEFAULT NOT NULL, `c` int(11) DEFAULT NOT NULL, PRIMARY KEY (`id`), KEY `test_table_a_b_c_index` (`a`,`b`,`c`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;命中索引： mysql> explain select * from test_table where a = 1 and b = 2 and c = 3;+----+-------------+------------+------------+------+------------------------+------------------------+---------+-------------------+------+----------+-------------+| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |+----+-------------+------------+------------+------+------------------------+------------------------+---------+-------------------+------+----------+-------------+| 1 | SIMPLE | test_table | NULL | ref | test_table_a_b_c_index | test_table_a_b_c_index | 12 | const,const,const | 1 | 100.00 | Using index |+----+-------------+------------+------------+------+------------------------+------------------------+---------+-------------------+------+----------+-------------+能够看到 key_len = 12，这是如何计算的呢？因为字符集是 UTF8，一个字段占用四个字节，三个字段就是 4 * 3 = 12 字节。 ...

一、查看以后环境是否装置MySQL，如有装置MySQL或者Mariadb，能够卸载； rpm -qa | grep mysqlpm -qa |grep mariadbyum remove mariadb-libs-5.5.64-1.el7.x86_64二、下载并装置1、国内用户思考切换yum源为阿里云； wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repoyum makecacheyum update -y2、下载对应版本的MySQL RPM安装包，下载地址http://mirrors.ustc.edu.cn/mysql-ftp/Downloads # server包wget https://mirrors.ustc.edu.cn/mysql-ftp/Downloads/MySQL-5.7/mysql-community-server-5.7.31-1.el7.x86_64.rpm# client包wget http://mirrors.ustc.edu.cn/mysql-ftp/Downloads/MySQL-5.7/mysql-community-client-5.7.31-1.el7.x86_64.rpm# common包wget http://mirrors.ustc.edu.cn/mysql-ftp/Downloads/MySQL-5.7/mysql-community-common-5.7.31-1.el7.x86_64.rpm# lib包wget http://mirrors.ustc.edu.cn/mysql-ftp/Downloads/MySQL-5.7/mysql-community-libs-5.7.31-1.el7.x86_64.rpm3、装置依赖包 yum install -y perl libaio net-tools4、装置对应版本的MySQL（按程序） rpm -ivh mysql-community-common-5.7.31-1.el7.x86_64.rpm --force --nodepsrpm -ivh mysql-community-libs-5.7.31-1.el7.x86_64.rpm --force --nodepsrpm -ivh mysql-community-client-5.7.31-1.el7.x86_64.rpmrpm -ivh mysql-community-server-5.7.31-1.el7.x86_64.rpm5、启动MySQL systemctl start mysqld.servicesystemctl status mysqld.service6、登陆MySQL更新默认明码， # 获取默认root明码cat /var/log/mysqld.log | grep 'password'# 登陆mysql，更改默认明码mysql -u root -pset password=password('xxxxxx')# 开启近程连贯use mysql;update user set Host = '%' where Host = 'localhost' and User='root';flush privileges;

分库分表中间件：sharding-jdbc/cobar/mycat等中间件。分表维度：如用户ID/订单ID等。分表算法：取模/哈希/路由表等。分库分表具体技术不做具体介绍，本文次要想聊下数据异构问题。 数据异构分库分表尽管解决了超大数据量导致的性能瓶颈问题，但也带来了新的难题。比方，如何跨库join聚合查问？如何全局排序/分组？常见的解决办法是通过数据异构的伎俩。比方ES搜寻异构，缓存异构等。 正式介绍前，咱们来回顾下MySql主从复制的架构。 Canal中间件就相似于这里的slave角色，它能够订阅数据库的binlog日志，而后进行数据生产，比方数据镜像、数据异构、数据索引、缓存同步等。Canal架构：Canal利用场景：Canal代码示例（省略了配置）

前言索引对于良好的查问性能至关重要，尤其是当表的数据量越来越大时。数据量小时，还看不出来索引施展的重要作用。在理论开发时，千万不要鄙视和疏忽了索引的重要性。有时候，一个“最优”的索引甚至比一个“良好”的索引，查问性能要好两个数量级。 索引基础知识很多人都喜爱将索引比作字典的目录。咱们想要查某个字时，先在目录里查找这个字的页码（索引扫描），而后间接翻到那一页，就找到了那个字。没有目录（字典）时，咱们只能一页一页地翻（全表扫描），这样的话性能毋庸置疑地很慢。 索引能够蕴含一列或队列的值，即单值索引和复合索引。创立复合索引时，须要留神列的程序，因为MySql索引遵循左前缀匹配准则。另外须要留神的是，创立一个蕴含2列的复合索引和两个1列的索引，成果是不一样的。下文将会解释这点。 索引类型索引是在存储引擎层实现的，而不是服务器层。不同的存储引擎可能反对不同的索引类型。 B-Tree索引InnoDB引擎默认的索引数据结构。Hash索引MySql中Memory引擎反对。全文索引相似搜索引擎查找关键词干的事。 InnoDB能够有"伪哈希索引"，在B-Tree索引的根底上进行哈希查找，取代原先的按键值查找。比方URL很长，用作索引列会很慢，能够用CRC_URL(url)后的列值（整型）作为索引，能晋升性能。这里的CRC_URL()就相当于一个哈希函数。 高性能的索引策略1.独立的列所谓独立的列，指的是不要将索引列作为表达式的一部分或函数的参数。如下是两个谬误例子：select actorname from actor wher actorid + 1 = 5;select xxx from xxx where TO_DAYS(CURRENT_DATE) - TODATS(date_col) <= 7;下面actorid和date_col上建设的索引，将无奈被MySql自动识别并应用。因而咱们尽量不要这么做。 2.前缀索引和索引选择性有时候很长的列间接作为索引的话，性能会比较慢，这时咱们须要应用前缀索引，例如下面提到的CRC_URL。但这还不够，须要思考选择性。所谓选择性，指的是区分度。即应用索引查问时，可能过滤掉的行数。区分度越高，过滤掉的记录数越多，这样索引的成果才好。惟一索引领有最好的区分度，因为没有反复的列值。而像性别这种列，不适宜作为索引列，因为就2种值，男/女（maybe 还有人妖？），这样只能过滤一半记录。 3.复合索引留神，复合索引并不是在多个列上独自的建单列索引，因为这往往并不能很好地晋升性能。5.x版本的MySql会采纳索引合并策略，即上面的sql语句上，actorid和filmname列上各有一个单列索引。select xxx from actor where actorid = 1 or filmname = 'TiTanNic'mysql会将这2个索引合并，生成并应用这个新的索引idx_actorid_filmname。但这往往意味着咱们设计的索引并不优，可用思考合并成一个合乎索引key(actorid, filmname)。 4.建设适合程序的复合索引将区分度更高的列放在后面，这样通常是比拟好的准则，因为这样能过滤掉更多的列。换句话说，就是计算候选列的值散布，值散布数量越多，区分度也就越高，应该把它放在后面。能够用如下的sql计算各个列的区分度。select count(distinct col1)/count(*) as discrimination1,count(distinct col2)/count(*) as discrimination2,count(*) from A; 5.防备某些非凡值导致的索引列性能慢这里的非凡值，比方利用的管理员，游客用户，这些列值往往领有的记录数很大，从而区分度很小，应用索引查问时简直不能过滤掉行数。这种案例的解决办法，通常能够在应用程序端做非凡解决，辨别出这种非凡值，禁止这种非凡值直接参与查问。 汇集索引汇集索引实际上并不是一种索引类型，而是一种数据存储形式。汇集索引指的是数据行和索引键值严密地寄存在一起，索引键值的程序大小和数据行的程序大小统一。一个表只能有1个汇集索引，默认是主键列作为汇集索引。如果没有定义主键，InnoDB会抉择一个惟一的非空索引代替。如果也没有这样的索引，InnoDB会隐式地创立一个主键来作为汇集索引。汇集索引的长处：1.能够将相干数据保留在一起。比方电子邮箱的表，能够依据用户ID来汇集数据，这样只须要从磁盘读取少许的数据页就能获取某个用户的所有邮件。如果是非汇集索引，则每封邮件都可能导致一次磁盘I/O。2.访问速度更快。索引和数据保留在同一个B-Tree结点中，因而从汇集索引中获取数据比非汇集索引更快。 汇集索引示例图：一般索引实例图： 笼罩索引通常索引的工作形式时，先在索引上查找到指标数据的指针，再回表去查问指针指向的数据行。如果咱们要查问的列恰好在索引列中，即被索引列笼罩到了，那么就不须要回表操作了，间接返回索引中的数据即可，这样可能大大晋升性能。

下载mysql安装包：https://www.mysql.com/1、2、3、4、 1、解压2、以管理员形式运行cmd C:\Windows\System32\cmd.exe管理员形式运行3、进入安装包的bin目录4、装置mysql服务：mysqld --install5、初始化mysql：mysqld --initialize --console6、启动mysql：net start mysql7、敞开mysql：net stop mysql 验证是否登录胜利：mysql -u root -p my.ini文件内容： [mysql] #设置mysql客户端默认字符集 default-character-set=utf8 [mysqld] #设置3306端口 port = 3306 #设置mysql的装置目录 basedir=E:\MySQL\mysql-8.0.16-winx64 #设置mysql数据库的数据的寄存目录 datadir=E:\MySQL\mysql-8.0.16-winx64\data #容许最大连接数 max_connections=200 #服务端应用的字符集默认为8比特编码的latin1字符集 character-set-server=utf8 #创立新表时将应用的默认存储引擎 default-storage-engine=INNODBmysql从新设置明码1、以管理员权限进入cmd进入mysql的bin文件2、执行：mysqld --skip-grant-tables 3、从新关上一个输出：mysql 4、查看是否登录胜利：show databases; 5、登录胜利输出：use mysql;抉择应用mysql数据库 6、输出：show table; 查看表user 7、查看user输出：select user,host,password from user; 8、更改root明码，输出：update user set password=password('root') where user='root' and host='localhost';

在SpringMVC+Spring+MyBatis整合利用中拜访Mysql呈现以下报错具体报错： 19-Feb-2021 11:08:54.808 重大 [Druid-ConnectionPool-Create-1512829159] com.alibaba.druid.support.logging.JakartaCommonsLoggingImpl.error create connection SQLException, url: jdbc:mysql://localhost:3306/springdb, errorCode 0, state S1000 java.sql.SQLException: Unknown initial character set index '255' received from server. Initial client character set can be forced via the 'characterEncoding' property. at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:926) at com.mysql.jdbc.ConnectionImpl.configureClientCharacterSet(ConnectionImpl.java:1734) at com.mysql.jdbc.ConnectionImpl.initializePropsFromServer(ConnectionImpl.java:3539) at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2151) at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:776) at com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:46) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at com.mysql.jdbc.Util.handleNewInstance(Util.java:406) at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:352) at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:284) at com.alibaba.druid.pool.DruidAbstractDataSource.createPhysicalConnection(DruidAbstractDataSource.java:1570) at com.alibaba.druid.pool.DruidAbstractDataSource.createPhysicalConnection(DruidAbstractDataSource.java:1636) at com.alibaba.druid.pool.DruidDataSource$CreateConnectionThread.run(DruidDataSource.java:2505)查看，查问mysql的版本发现本地的是8.0.22，更改maven的pom.xml文件的mysql驱动版本为8.0.22，刷新pom.xml，重新启动利用即可 ...

一、MySQL逻辑架构图 1.客户端连贯管理层负责管理客户端的连贯/认证/受权等。 2.服务器层负责查问解析/优化重写/查问缓存等。 3.存储引擎层负责数据的存储和提取。 二、数据库死锁当事务1执行完第1个update时，锁定了stockid=4的行，筹备去update stockid=3的行；此时如果事务2页执行完第1个update，锁定了stockid=3的行,筹备去update stockid=4的行，这样就造成了死锁的四个必要条件。资源互斥、持有并申请新资源、资源不可剥夺、循环期待。解决办法：突破循环期待的条件，innodb为例，回滚持有行级锁起码记录的事务。使得某一个或局部事务回滚，开释行级锁，其余事务就能获取到被占有的行级锁，达到解决死锁的目标。因为死锁无奈防止，因而利用程序设计时必须思考死锁产生后的解决逻辑。最简略的方法是从新执行被数据库存储引擎回滚的那个事务即可。 三、多版本并发管制（MVCC）MVCC能够认为是行级锁的一个变种，然而它在很多状况下防止了加锁操作，因而开销更低。MVCC没有一个对立的规范，各个数据库如Mysql，Oracle，PostgreSQL等都有本人的实现形式。尽管实现机制不同，但大都实现了非阻塞的读操作，写操作也只锁定必要的行。实现原理：通过保留数据在某个工夫点的快照，使得每个事物看到的数据都是统一的。后面说到不同的数据库实现原理不同，典型的有乐观锁和乐观锁。上面以innodb的简化版行为来阐明MVCC是如何工作的。 InnoDB的MVCC，是通过在表的每行记录前面保留两个暗藏的列来实现的。这两个列的值，别离保留行的创立工夫和过期工夫（即删除工夫）。然而，它们存的并不是实在工夫戳，而是零碎版本号。每开始一个新的事务，这个零碎版本号都会主动递增。事务开始时的零碎版本号会作为事务版本号，用来和查问到的每行记录的版本号做比拟。上面看一下在REPEATABLE READ的隔离级别下，MVCC具体是怎么工作的。 1.SELECT操作 a.InnoDB只查找版本号小于或等于以后事务版本号的数据行，这样能够确保事务读取到的行，要么是事务开始前就存在的，或者是这个事务自身插入或批改的。 b.行的删除版本号要么未定义，要么大于以后事务版本号，这样能够确保事务读取到的行，在事务开始前没有被删除。 只有合乎a,b两个条件的记录行才会被查问到。2.INSERT操作 InnoDB为新插入的每一行保留以后零碎版本号作为行创立版本号。3.DELETE操作 InnoDB为删除的每一行保留以后零碎版本号作为行删除版本号。4.UPDATE操作 InnoDB为插入一行新记录，保留以后零碎版本号作为新创建行的创立版本号；同时以后零碎版本号作为原来行的行删除版本号。 留神，MVCC只在可反复读和读已提交的隔离级别下工作。因为读未提交总是会读取最新的数据，而不是合乎以后事务版本号要求的数据。而串行化会为所有的读操作加锁。

索引是SQL优化中最重要的伎俩之一，本文从根底到原理，带你深度把握索引。 一、索引根底1、什么是索引MySQL官网对索引的定义为：索引（Index）是帮忙MySQL高效获取数据的数据结构，索引对于良好的性能十分要害，尤其是当表中的数据量越来越大时，索引对于性能的影响愈发重要。索引优化应该是对查问性能优化最无效的伎俩了。索引可能轻易将查问性能进步好几个数量级。 艰深来讲，索引相似文章的目录，用来进步查问的效率。 2、索引分类常见的索引类型有：主键索引、惟一索引、一般索引、全文索引、组合索引 2.1、主键索引当一张表，把某个列设为主键的时候，则该列就是主键索引 create table a ( id int primary key auto_increment, name varchar(20) not null default '' ); 这里id就是表的主键，如果当创立表时没有指定主键索引，也能够在创立表之后增加： alter table table_name add primary key (column_name);1.2、一般索引用表中的一般列构建的索引，没有任何限度 create index 索引名 on table_name(column1);alter table table_name add index 索引名(column1);1.3、全文索引全文索引次要针对文本文件，比方文章，题目。在MySQL5.6之前，只有MyISAM存储引擎反对全文索引，MySQL5.6之后InnoDB存储引擎也反对全文索引。 create table c( id int primary key auto_increment , title varchar(20), content text, fulltext(title,content) ) engine=myisam charset utf8; insert into c(title,content) values ('MySQL Tutorial','DBMS stands for DataBase ...'), ('How To Use MySQL Well','After you went through a ...'), ('Optimizing MySQL','In this tutorial we will show ...'), ('1001 MySQL Tricks','1. Never run mysqld as root. 2. ...'), ('MySQL vs. YourSQL','In the following database comparison ...'), ('MySQL Security','When configured properly, MySQL ...'); 1.4、惟一索引见名知义，索引列中的值必须是惟一的，然而容许为空值。d表中name就是惟一索引，相比主键索引，主键字段不能为null，也不能反复 ...

一、筹备装置MySQL：MySQL装置装置所需Python库 pip install flaskpip install flask-sqlalchemypip install pymysql二、编写Python代码from flask import Flaskfrom flask_sqlalchemy import SQLAlchemyapp=Flask(__name__)app.config['SECRET_KEY']='2333' # 明码app.config['SQLALCHEMY_DATABASE_URI']='mysql+pymysql://root:2333@localhost:3306/runoob' # 协定：mysql+pymysql # 用户名：root # 明码：2333 # IP地址：localhost # 端口：3306 # 数据库名：runoob #这里的数据库须要提前建好app.config['SQLALCHEMY_COMMIT_ON_TEARDOWN']=Truedb=SQLAlchemy(app)# 新建表Roleclass Role(db.Model): __tablename__='roles' # 表名 id=db.Column(db.Integer, primary_key=True) # id字段，int类型，主键 name=db.Column(db.String(64), unique=True) # name字段，字符串类型，惟一 users=db.relationship('User', backref='Role', lazy='dynamic') # 外键关系，动静更新 def __repr__(self): return '<Role %r>' %self.nameclass User(db.Model): __tablename__='users' id=db.Column(db.Integer, primary_key=True) username=db.Column(db.String(64), unique=True, index=True) #索引 role_id=db.Column(db.Integer, db.ForeignKey(Role.id)) # 外键 def __repr__(self): #toString return '<User %r>' %self.usernameif __name__=='__main__': db.drop_all() # 删除存在表 db.create_all() # 创立这两个表 app.run()运行即可。运行胜利的后果如下： ...

随同着互联网、5G、大数据的蓬勃发展，数据俨然已成为企业不可或缺的重要资产，数据管理的意义愈发突出，但想要治理好数据却并不是一件容易事，为什么呢？ 首先看一下数据的定义：数据是指对主观事件进行记录并可甄别的符号，是对客观事物的性质、状态以及互相关系等进行记录的物理符号或这些物理符号的组合。它是可辨认的、形象的符号。——百度百科数据是通过观测失去的数字型的特色或信息。——维基百科 结合实际状况艰深来讲：数据是企业倒退或商业行为中获取、用于企业的发展壮大，带来丰盛物质收益的同时，也会帮忙企业不断进步的虚构资源。 其次，需明确数据管理的定义：数据管理，即对数据资源的治理。依照 DAMA 的定义：“数据资源管理，致力于倒退解决企业数据生命周期的适当的建构、策略、实际和程序”。这是一个高层而蕴含宽泛的定义，而并不一定间接波及数据管理的具体操作。——维基百科利用计算机硬件和软件技术对数据进行无效的收集、存储、解决和利用的过程。其目标在于充沛无效地施展数据的作用。实现数据无效治理的要害是数据组织。——百度百科 相比百科百度中偏差计算机领域的定义，维基百科更合乎古代企业数据管理的定义。 结合实际艰深来讲，就是企业倒退过程中数据量一直攀升，数据在帮忙企业倒退时，也带来诸多问题，因而，企业须要有一套整体齐备的理念、程序、架构治理数据，让数据更好的为企业所用。 为什么要治理数据？企业治理数据，与咱们普通人理财很类似。但一大重要不同点是：企业治理数据是心愿数据可能更高效且低成本运作以带来商业收益。但正如理财有危险一样，没想分明为什么要治理数据前，不要间接下马一个数据管理我的项目，也不要去洽购数据管理产品，首先须要搞清楚，数据管理的意义在哪里，能为企业带来什么价值？ 治理数据的实质企业心愿通过治理数据来低成本高效的实现特定目标。这句话有三个重要关键词，实现特定目标、低成本高效、通过治理数据的形式。咱们逐个剖析：首先治理数据是专业化的工作，因而人才是第一因素，正如战场上不能要求飞行员去拼刺刀一样；其次，低成本高效，即要明确各数据理论价值，排列数据优先级，及时淘汰无用数据；最初，实现特定目标，治理数据务必要有本人的目标，坚定不要为了治理而治理。 那么，怎么来治理数据呢？答案：用数据来治理数据。治理数据的前提是能把要做的事件量化，事件量化后也成了数据，并且咱们须要用数据进行工作决策和治理。其次，还须要有一套卓有成效的治理办法。 有了目标和办法后，就要开始制订数据标准制订数据管理标准时比拟难，需围绕指标边制订边实际，没有最好的制度，只有最适宜本人的。 上面做一个掂量数据管理能力的评估题目，一要量化，二要靠机器答复，三要半小时内答复。 是否间接给出每张表对于数据变现的价值？或如果这张表不出，会带来多少潜在损失？（虚构指标都能够）。是否间接给出每张表的运行品质报告？是否依据优先级给出运行优化的具体倡议？哪些表能间接下线？你会发现要答复这些问题，不仅是建个数据管理系统那么简略，须要制订相应的标准和规范。 如果须要晓得每张表对于数据变现的价值，必须有利用跟表的关系，因而，开发上线的时候必须制订标准，起码要提交映射关系，同时为了避免两张皮景象，必须依赖自动化的零碎。 如果须要晓得每张表的数据品质报告，必须制订相干的质量指标，并可能及时预警和解决，这个须要一套数据品质监控制度。 如果须要确定哪些表能间接下线，必须制订一套数据表生命周期管理制度，须要有表的比方血统和影响剖析，否则怎么晓得有多大影响？ 如果要让运维人员晓得这些表谁是谁，则必须有好的数据字典，明确表命名标准和口径定义，以升高治理老本。 如果…. 你看，所有的数据管理规章制度其实都是为了确保目标达成，由此会延长出一个宏大的数据管理体系，但还是要懂得能抓住实质。因为一开始，不可能想到这么多，能做这么多，需从根源开始思考从何动手。 说完制度，接下来就要提到数据管理工具。工欲善其事必先利其器。以后数据量愈发宏大，靠人肉难以保障稳固且风险性微小，因而数据管理工具在古代企业中越发重要。 之前微盟程序员删库跑路事件传遍全网，几行代码，让上市公司微盟的市值一天内蒸发超 10 亿，数百万用户受影响，间接间接的损失难以计量。这个“段子”一样的事件，无疑给各大公司敲响警钟，尤其是数据管理并不标准的中小公司，如果这样的删库跑路事件产生，产生的成果将无疑是毁灭性的。 能够看出，想要保障企业数据的稳固运行，数据的管控和审计无疑是十分重要的，对于数据管理者来讲尤其如此。企业中对不同层级的开发人员需制订具体的数据操作权限，哪些容许，哪些不容许，应明确指出。而且用户在权限内对数据做了哪些事件，尤其是高危事件，应要做到具体的审计剖析，这两点笔者认为是最必不可少的。 另外，数据管理的可视化也十分重要，有些公司的 ETL 工作多达成千盈百个，能疾速简略的判断工作是否运行胜利也很重要，它将间接决定到运维的工作量和难易水平。 以后数据管理的产品并不少，但要想面对复杂多变的企业环境，不同的数据库状况，不同用户的操作习惯等，往往能达到的成果无限。 怎么能力算是好的数据管理工具？首先，肯定是可能融入到企业的生产环境中去，这是大前提。 其次，以后企业要用到的数据库品种越来越多，如 NOSQL、NEWSQL、国产数据库等，所以要在一个平台内反对罕用的各类数据库，而不须要关上一大堆工具。 另外，以后云和 Web 的利用越发宽泛，对于企业团队而言，如果能在云端部署好一套零碎，不必每个人再去下载配置，对立部署，对立应用，加强团队之间的合作，那将会大大节俭团队工夫，提高效率。而且，数据操作体验和效率也不可漠视，平时工作中 DBA 和开发罕用到的性能应是标配。 最初便是最重要的数据安全。对于 DBA 而言，这里最根本的两项刚需性能可能是：权限管控和审计。 数据管理的一些思考数据管理是个系统性的工程，波及到企业很多流程的再造和新机制的建设，比方标准开发流程等，影响也是全方面的，也须要博得管理者的反对，不然也会举步维艰。 另外，数据管理是个专业化的工作，要有专业化的人全力来对应，其余例如工具等都是辅助，来到业余的人才，往往也不会达到很好的成果。 总结将来时代，数据将会愈发宏大，数据管理工作也将更加简单艰难，这既是给数据从业者的挑战，也是时代赋予的机会。 基于 Web 的对立数据管控工具 CloudQuery—— https://cloudquery.club/

docker中mysql的数据有的时候用起来可能不太不便，不直观，我想把数据库拷一份下来在本人电脑上用，当初记录一下过程。 一.在docker中导出数据1.导出整个数据库mysqldump -u 用户名 -p 数据库名 > 导出的文件名mysqldump -u dbuser -p dbname > dbname.sql2.导出一个表mysqldump -u 用户名 -p 数据库名 表名> 导出的文件名mysqldump -u dbuser -p dbname users> dbname_users.sql3.导出一个数据库构造mysqldump -u dbuser -p -d --add-drop-table dbname >d:/dbname_db.sql-d 没有数据 --add-drop-table 在每个create语句之前减少一个drop table4.导入数据库罕用source 命令进入mysql数据库控制台，如mysql -u root -pmysql>use 数据库而后应用source命令，前面参数为脚本文件(如这里用到的.sql)mysql>source d:/dbname.sql留神：可能会呈现permission denied谬误，这是权限问题，用root用户进入容器即可： docker exec -it -u root container——id bash导出的地位就在以后文件夹 二.从容器导出到本地计算机sudo docker cp 074af74c669d:/etc/bash.bashrc /tmp或者反过来sudo docker cp /tmp/index.html 074af74c669d:/etc/这样就能够了

不晓得你还记不记得《孔乙己》这篇文章，酒店掌柜有一个粉板，专门用来记录客人的赊账记录。如果赊账的人不多，那么他能够把顾客名和账目写在板上。但如果赊账的人多了，粉板总会有记不下的时候，这个时候掌柜肯定还有一个专门记录赊账的账本。 如果有人要赊账或者还账的话，掌柜个别有两种做法： 一种做法是间接把账本翻出来，把这次赊的账加上去或者扣除掉；另一种做法是先在粉板上记下这次的账，等打烊当前再把账本翻出来核算。同样，在MySQL里也有这个问题，如果每一次的更新操作都须要写进磁盘，而后磁盘也要找到对应的那条记录，而后再更新，整个过程IO老本、查找老本都很高。为了解决这个问题，MySQL的设计者就用了相似酒店掌柜粉板的思路来晋升更新效率。 而粉板和账本配合的整个过程，其实就是MySQL里常常说到的WAL技术，WAL的全称是Write-Ahead Logging，它的关键点就是先写日志，再写磁盘，也就是先写粉板，等不忙的时候再写账本。 具体来说，当有一条记录须要更新的时候，InnoDB引擎就会先把记录写到redo log（粉板）外面，并更新内存，这个时候更新就算实现了。同时，InnoDB引擎会在适当的时候，将这个操作记录更新到磁盘外面，而这个更新往往是在零碎比拟闲暇的时候做，这就像打烊当前掌柜做的事。 如果明天赊账的不多，掌柜能够等打烊后再整顿。但如果某天赊账的特地多，粉板写满了，又怎么办呢？这个时候掌柜只好放下手中的活儿，把粉板中的一部分赊账记录更新到账本中，而后把这些记录从粉板上擦掉，为记新账腾出空间。 与此相似，InnoDB的redo log是固定大小的，比方能够配置为一组4个文件，每个文件的大小是1GB，那么这块“粉板”总共就能够记录4GB的操作。从头开始写，写到开端就又回到结尾循环写，如上面这个图所示。 write pos是以后记录的地位，一边写一边后移，写到第3号文件开端后就回到0号文件结尾。checkpoint是以后要擦除的地位，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。 write pos和checkpoint之间的是“粉板”上还空着的局部，能够用来记录新的操作。如果write pos追上checkpoint，示意“粉板”满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把checkpoint推动一下。 有了redo log，InnoDB就能够保障即便数据库产生异样重启，之前提交的记录都不会失落，这个能力称为crash-safe。 要了解crash-safe这个概念，能够想想咱们后面赊账记录的例子。只有赊账记录记在了粉板上或写在了账本上，之后即便掌柜遗记了，比方忽然开业几天，复原生意后仍然能够通过账本和粉板上的数据明确赊账账目。

数据库设计陷阱1.数据库设计有哪些陷阱?如何解决?2.泛式的思考3.读写速度如何衡量?4.计数器表和缓存表注释:1.数据库设计有哪些陷阱?如何解决?太多的列数据库设计的时候不宜领有太多的列.sql中要在服务器层和存储引擎之间通过行缓冲格局拷贝成数据，而后在服务器层将缓冲内容编码成各个列，从行缓冲中将编码过的列转换成行数据结构的操作代价是十分高的。如果客户应用了数千个字段的表，这种转换的代价就会十分高 太多的关联mysql限定每个关联操作最多只能有61张表，如果咱们心愿查问执行地快且好，单个查问最好在12个表以内做关联。 非空非空能够让索引的建设更高效,然而也不要自觉应用非空,兴许能够应用0或者负值等来代替飞控,但如果应用一个不可能的值,可能会导致代码逻辑简单十分多,并且容易引入bug。解决null不容易，然而有时候比它的代替计划要好 2.泛式的思考咱们都学过第一范式，第二范式，第三范式，接下来我简略地概括一下泛式和反泛式的特点： 范式：每个数据在数据库里只会呈现一次反范式：每个数据在数据库里会呈现屡次 范式的长处因为每个数据在数据库里只呈现一次，范式化的更新操作通常比反范式快。当数据较好地范式化时，就只有很少或者没有反复数据，所以只须要批改很少的数据。范式化的表通常更小，能够放在内存里，所以执行操作更快。很少有多余的数据意味着检索列表数据时更少须要distinct或者group by 语句。 毛病须要关联，范式化可能将列寄存在不同的表中，而这些列如果在一个表中本能够属于同一个索引。 反范式的优缺点长处：所有数据都在一个表中，防止关联 毛病：一个数据呈现屡次，可能会呈现数据不统一的状况每次更新数据须要更新屡次 混用范式和反范式须要搞清楚select的频率和update的频率 如果select更多，就采取反泛式如果update更多，就采取泛式 3.读和写的速度如何衡量？一般来说，读和写的速度是抵触的。你想读地更快，势必要在多个容易读到的中央存储更多的数据，那么每次更新这个数据的时候都要写更多的中央。这就是时空对抗准则。（工夫和空间的非对称性） 更快地读，更慢地写为了晋升查问速度，常常须要建设一些额定索引，或者反泛式，但这样会减少写的累赘。尽管写操作变得更慢了，但显著地晋升了读操作然而写操作变慢可能不是惟一代价，还可能同时减少了读操作和写操作的开发难度。 4.计数器表和缓存表咱们先介绍一下计数器表和缓存表是干嘛的：计数器表：举个例子，比如说，有一个签到性能，这个签到性能在你签到后会提醒你是第几个签到的，这个时候如果咱们每次进行签到的时候进行count(*)的统计，会很慢，所以咱们应用缓存表，间接记录了明天曾经有多少人签到过了，而后在下面+1即可。缓存表：再举个例子，假如咱们有一个公众号发送关键字主动回复的表，一个关键字对应一个主动回复，这个时候咱们能够将罕用的10个甚至更多个关键字先提取进去，放在一个表里，能够先去这个表里查，能够大大减少检索的数据，放慢查问效率。总结：缓存表用来存储哪些每次获取速度比较慢的数据的表汇总表保留你的是应用groupby语句聚合数据的表

schema与数据类型优化整数类型：能够应用的几种整数类型：TINYINT，SMALLINT，MEDIUMINT，INT，BIGINT别离应用8，16，24，32，64位存储空间。尽量应用满足需要的最小数据类型。整型比字符操作代价更低，因为字符集和校对规定是字符比拟比整型比拟更简单。 字符和字符串类型char是定长，varchar是可变长度，varhcar尽管比char节俭空间，然而如果一个varchar列常常被批改，而且每次被批改的数据长度不同，会引起行迁徙景象，这会造成多余的I/O。所以varchar实用于存储长度稳定较大的数据，且很少更新的场景，char实用于长度不变，短且常常更新的字符串，如：MD5摘要。 应用mysql自建类型而不是字符串来存储日期和工夫应用枚举类型代替字符串有时能够应用枚举类代替罕用的字符串类型，mysql存储枚举类型会十分紧凑，会依据列表值的数据压缩到一个或两个字节中，mysql在外部会将每个值在列表中的地位保留为整数，并且在表的.frm文件中保留“数字-字符串”映射关系的查找表。 非凡类型数据应用整型存储IP地址，mysql给出了现成的转换函数：select INET_ATON("192.15.2.2")select INET_NTOA("3222209026") 适当拆分当咱们的表中存在相似于 TEXT 或者是很大的 VARCHAR类型的大字段的时候，如果咱们大部分拜访这张表的时候都不须要这个字段，咱们就该义无反顾的将其拆分到另外的独立表中，以缩小罕用数据所占用的存储空间。这样做的一个显著益处就是每个数据块中能够存储的数据条数能够大大增加。 正当应用范式和反范式被频繁援用且只能通过 Join 2张(或者更多)大表的形式能力失去的独立小字段。这样的场景因为每次Join仅仅只是为了获得某个小字段的值，Join到的记录又大，会造成大量不必要的 IO，齐全能够通过空间换取工夫的形式来优化。毛病是，冗余的同时须要确保数据的一致性，此字段如果要产生批改，要同时更新两张表。 索引索引生效的几种状况含糊查问时通配符放在最后面（like '%XX'或者like '%XX%'）索引不容许为null，所以where的判断条件如果对字段进行了null值判断，将导致数据库放弃索引而进行全表查问select id from t where num is null 能够在num上设置默认值0，确保表中num列没有null值，而后这样查问： select id from t where num=0a.索引是有序的。NULL值进入索引时，无奈确定其应该放在哪里。（将索引列值进行建树，其中必然波及到诸多的比拟操作，null 值是不确定值无奈比拟，无奈确定null呈现在索引树的叶子节点地位。） where前面的索引列应用了!= 或者 <> 操作符where前面的索引列进行了表达式或函数操作组合索引没有遵循最左匹配准则索引优化尽量利用笼罩索引机制，防止回表，缩小I/O次数尽量应用主键查问，防止回表，缩小I/O次数在须要索引很长的字符串的时候应用前缀索引前缀索引是一种能使索引更小更快的无效办法，然而毛病是：mysql无奈应用前缀索引作order by 和 group by 尽量应用索引来做排序更新非常频繁，数据区分度不高的字段不适宜建索引更新会变更B+树，更新频繁的字段倡议索引会大大降低数据库性能。相似于性别这类辨别不大的属性，建设索引是没有意义的，不能无效的过滤数据。 表连贯最好不要超过3张，join的字段，要放弃数据类型统一，保障join的字段有索引能应用limit的时候尽量应用limit组合索引的字段数不容许超过5个

前言： 在 MySQL 中，咱们能够为表字段设置默认值，在表中插入一条新记录时，如果没有为某个字段赋值，零碎就会主动为这个字段插入默认值。对于默认值，有些常识还是须要理解的，本篇文章咱们一起来学习下字段默认值相干常识。 1.默认值相干操作咱们能够用 DEFAULT 关键字来定义默认值，默认值通常用在非空列，这样可能避免数据表在录入数据时呈现谬误。 创立表时，咱们能够给某个列设置默认值，具体语法格局如下： # 格局模板<字段名> <数据类型> DEFAULT <默认值># 示例mysql> CREATE TABLE `test_tb` ( -> `id` int NOT NULL AUTO_INCREMENT, -> `col1` varchar(50) not null DEFAULT 'a', -> `col2` int not null DEFAULT 1, -> PRIMARY KEY (`id`) -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;Query OK, 0 rows affected (0.06 sec)mysql> desc test_tb;+-------+-------------+------+-----+---------+----------------+| Field | Type | Null | Key | Default | Extra |+-------+-------------+------+-----+---------+----------------+| id | int(11) | NO | PRI | NULL | auto_increment || col1 | varchar(50) | NO | | a | || col2 | int(11) | NO | | 1 | |+-------+-------------+------+-----+---------+----------------+3 rows in set (0.00 sec)mysql> insert into test_tb (col1) values ('fdg');Query OK, 1 row affected (0.01 sec)mysql> insert into test_tb (col2) values (2);Query OK, 1 row affected (0.03 sec)mysql> select * from test_tb;+----+------+------+| id | col1 | col2 |+----+------+------+| 1 | fdg | 1 || 2 | a | 2 |+----+------+------+2 rows in set (0.00 sec)通过以上试验能够看出，当该字段设置默认值后，插入数据时，若不指定该字段的值，则以默认值解决。 ...