Mysql

作者：胡呈清爱可生 DBA 团队成员，善于故障剖析、性能优化，集体博客：https://www.jianshu.com/u/a95...，欢送探讨。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 命令行模式mysql shell 如何实现相似 mysql -e "show processlist;" 的成果？即执行完就退出登录，不须要交互，咱们常常在脚本中这样应用。那么同样的，在保护 InnoDB Cluster 时，怎么在脚本中调用 mysql shell 查看 MGR 集群的状态或者对集群做操作呢？语法如下： mysqlsh [options] -- shell_object object_method [arguments]示例： mysqlsh -h172.16.22.1 -P3306 -uroot -p -- cluster status能够间接输入 cluster 状态信息，等同于： mysqlsh -h172.16.22.1 -P3306 -uroot -pvar cluster=dba.getCluster()cluster.status()配合上面介绍的明码保留办法，防止在脚本中裸露明码，也能够防止交互式输出明码，能够很不便的查问状态或者做一些保护操作，比方： 配置保留明码默认设置： JS > \option -l ... credentialStore.excludeFilters [] credentialStore.helper default credentialStore.savePasswords prompt ...credentialStore.helper默认状况下，此选项设置为非凡值 default。能够设置为 <disabled> 来禁用明码存储和检索性能，留神要用 setPersist 能力在退出 mysqlsh 后的下一次失效： shell.options.setPersist("credentialStore.helper", "<disabled>")若是显示为 “<invalid>”，则无奈应用明码存储和检索，通常是因为没有装置 mysql_config_editor，因为 mysql shell 的明码保留理论也是用 mysql_config_editor 实现的，上面会解释道具体用法。 ...

前言其实解决是否插入反复数据的问题，个别状况下是有两个思路，就像治水一样，第一个就是从源头，第二个就是在水流经的路上。咱们带着这两种思路持续往下看： 问题在咱们的mysql数据库中，常常会呈现一些反复的数据，有些状况咱们容许反复数据的存在，但有时候咱们也须要删除这些反复的数据。咱们如何去解决呢？ 办法一：防止出现反复数据也就是说咱们再设计表的时候，就应该对这些数据设置一个UNIQUE 索引，在插入的时候就能够保障其唯一性，也就不存在有反复的数据了。当然你也能够间接设置为PRIMARY KEY（主键）。成果也是一样的。咱们看一个案例：下表中无索引及主键，所以该表容许呈现多条重复记录。 CREATE TABLE student( first_name CHAR(20), last_name CHAR(20), sex CHAR(10));目前first_name，last_name是能够反复的，如果不想反复这里有两个解决办法： 1、设置双主键模式CREATE TABLE student( first_name CHAR(20) NOT NULL, last_name CHAR(20) NOT NULL, sex CHAR(10), PRIMARY KEY (last_name, first_name));当初就无奈插入反复数据了。 2、增加unique索引CREATE TABLE student( first_name CHAR(20) NOT NULL, last_name CHAR(20) NOT NULL, sex CHAR(10) UNIQUE (last_name, first_name));这两种看起来模式如同有一点区别，然而能起到雷同的作用。此时咱们能够插入两条反复的数据，会发现报错。当然咱们还能够在数据库中去验证一下： SELECT COUNT(*) as repetitions, last_name, first_name FROM student GROUP BY last_name, first_name HAVING repetitions > 1;在这里咱们统计的是 first_name 和 last_name的重复记录数，下面曾经用两种办法设置了，这里必定就是0了。 办法二：在插入时指定是否插入反复数据在这里咱们应用的是Insert ignore into 与Insert into指令。 ...

为什么要分表Mysql是以后互联网零碎中应用十分宽泛的关系数据库，具备ACID的个性。 然而mysql的单表性能会受到表中数据量的限度，次要起因是B+树索引过大导致查问时索引无奈全副加载到内存。读取磁盘的次数变多，而磁盘的每次读取对性能都有很大的影响。 这时一个简略可行的计划就是分表(当然土豪也能够堆硬件)，将一张数据量宏大的表的数据，拆分到多个表中，这同时也缩小了B+树索引的大小，缩小磁盘读取次数，进步性能。 两种根底分表逻辑说完了为什么要分表，上面聊聊业务开发中常见的两种根底的分表逻辑。 按日期分表这种形式通常会在表名的最初加上年月日，次要实用于按日期划分的统计数据或操作记录。在线实时展现的只有最近表中的数据，其余数据用于离线统计等。 按id取模分表这种形式须要一个id生成器，例如snowflake id或分布式id服务。它保障了雷同id的数据都在一张表中，次要实用于保留用户根底信息，零碎中的资源信息，购买记录等。当然这种分表形式扩展性较差，前期数据继续增多后须要按id大小分库再分表处理。 上面看下这两种分表逻辑在mybatis-plus中的实现。 Mybatis-plus中的分表实现说到java的分表中间件，可能有人会想到sharding-jdbc，作为应用很宽泛的一个分表中间件，性能也比较完善，然而应用它须要引入额定的jar包和减少学习老本。 实际上mybatis-plus自身就提供了一个分表的解决方案，配置应用都很简略，适宜疾速开发零碎。 动静表名处理器没错，mybatis-plus提供了动静表名处理器接口TableNameHandler，只须要在零碎中实现该接口，并作为插件加载到mybatis-plus中就能够应用，上面来看下具体的步骤。 3.4版本之前的动静表名接口是ITableNameHandler，须要和分页插件配合应用。3.4版本新增了TableNameHandler，在办法参数上勾销了MetaObject。这里用最新的版本为例，应用形式差异不大。 假如咱们的零碎中有两种分表形式，按日期分表和按id取模分表。通过四个步骤来看下具体的应用示例。 1.创立日期表名处理器先来看下日期解决的表名处理器，实现TableNameHandler接口后，在dynamicTableName办法中实现动静生成表名的逻辑，办法的返回值就是查问时要应用的表名。 /** * 按天分表解析 */public class DaysTableNameParser implements TableNameHandler { @Override public String dynamicTableName(String sql, String tableName) { String dateDay = LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyyMMdd")); return tableName + "_" + dateDay; }}2.创立id取模表名处理器再来看下按id取模表名处理器的实现，这个处理器绝对日期解决就要简单一些，次要起因为须要动静传入用于分表的id值。 在之前的版本中能够在办法中通过解析MetaObject中带有的sql查问信息，获取分表应用的值。然而这种形式比较复杂，对于不同的QueryMapper剖析的形式不同，比拟容易出错。新版本中的办法勾销了MetaObject参数，须要应用其余形式传入。 须要留神的是，表名处理器是作为mybatis-plus的插件，在我的项目启动时实例化的。这意味着，在运行过程中只有一个对象，多线程处理过程中，一个线程对参数的批改，会影响到其余线程。为了解决这个问题，能够应用ThreadLocal来定义参数。 因为当初的框架中大部分会应用线程池，例如springboot web我的项目中的tomcat。所以在每次应用后，须要手动革除本次数据，避免线程复用时的影响。 具体实现如下: /** * 按id取模分表处理器 */public class IdModTableNameParser implements TableNameHandler { private Integer mod; //应用ThreadLocal避免多线程相互影响 private static ThreadLocal<Integer> id = new ThreadLocal<Integer>(); public static void setId(Integer idValue) { id.set(idValue); } IdModTableNameParser(Integer modValue) { mod = modValue; } @Override public String dynamicTableName(String sql, String tableName) { Integer idValue = id.get(); if (idValue == null) { throw new RuntimeException("请设置id值"); } else { String suffix = String.valueOf(idValue % mod); //这里革除ThreadLocal的值，避免线程复用呈现问题 id.set(null); return tableName + "_" + suffix; } }}3.加载表名处理器表名处理器理论是mybatis-plus的插件，须要在初始化时创立实例并加载。因为零碎中存在两种分表类型，在初始化时能够指定每张表应用的表名处理器。具体实现如下： ...

(1)先敞开mysql服务, sudo service mysql stop(2)找到mysql的配置文件my.cnf（装置形式不同目录可能不同，我的在/usr/my.cnf），增加如下配置：character_set_server = utf8init_connect='SET NAMES utf8'(3)重启mysql服务，查看编码show variables like '%char%';

引子尝试应用 Node 连贯 MySql 数据库。 OriginMy GitHub装置零碎：macOS Catalina 10.15.7 MySql应用工具 Homebrew # 搜寻看下有没有brew search mysql# 查看下相干信息，是不是想要的brew info mysql# 装置brew install mysql 这个时候要留神装置之后的提示信息： 版本 8.0.22 。装置的 MySql ，没有设置明码，要想更平安，运行命令：mysql_secure_installation 。MySql 默认配置只容许从本地连接。想要连贯，运行命令： mysql -uroot 。启动命令： brew services start mysql ，如果不想要后盾运行服务，运行命令： mysql.server start 。执行 mysql_secure_installation 会提醒各种相干的设置，比方明码，是否禁止近程 root 登录，移除测试表等等。 执行 mysql -uroot 时，呈现上面的提醒： ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)依照官网上输出的指令 mysql -u root -p ，提醒输出明码，输出 123456 就进入了，网上看有些状况下须要重置明码。 其它命令 查看运行状态： mysql.server status;敞开： mysql.server stopMySQL Workbench官网提供了可视化工具，能够在这里下载，本次应用的版本是 mysql-workbench-community-8.0.22-macos-x86_64 。 ...

EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card=book.card; 在左表建设索引 ALTER TABLE `class` ADD INDEX Y(`card`); LEFT JOIN 条件用于确定如何从右表中查找匹配行，左表的数据会全副显示。 在右表建设索引 DROP INDEX Y ON class;ALTER TABLE `book` ADD INDEX Y(`card`); LEFT JOIN 索引建设在右表，有助于利用索引从右表中查找匹配行。相同，如果是 RIGHT JOIN，索引应该建设在左表。

上一篇讲了假设检验，这一篇讲讲方差分析。 1.背景：如果你们当初针对用户提出了三种进步客单价的策略A、B、C，当初想看一下这三种策略最初对进步客单价的成果有什么不同，那咱们怎么能力晓得这三种策略成果有什么不同？最简略的办法就是做一个试验，咱们能够随机筛选一部分用户，而后把这些用户分成三组A、B、C组，A组用户应用A策略、B组用户应用B策略、C组用户应用C策略，等策略施行一段时间当前，咱们来看一下这三组别离的客单价是什么程度？哪组均匀客单价高，就阐明哪组策略有成果。真的能够得出这的论断吗？是能够，然而不够谨严。 为什么说不够谨严呢？是因为咱们用来做试验的用户是随机筛选的，有可能客单价高的那局部用户(比方高价值用户)自身就要比其余用户群体的客单价高，那为了防止这种可能是因为随机抽样造成的后果不统一问题，咱们就须要去证实下，到底是不是因为随机筛选的起因，如果不是，咱们就能够去比拟各组的均匀客单价，哪组客单价较高，就阐明哪组策略更有成果。 咱们的最终目标其实就是为了比拟各组的均匀客单价，然而在比拟均值之前，咱们须要先证实下各组之间的后果不同是因为策略的起因还是随机筛选的起因，咱们把这个过程叫做方差分析。 2.三个假如：方差分析有三个假如： 1.每组样本数据对应的总体应该遵从正态分布；2.每组样本数据对应的总体方差要相等，方差相等又叫方差齐性；3.每组之间的值是互相独立的，就是A、B、C组的值不会相互影响。正态测验次要有两种大的办法，一种是统计测验的办法：次要有基于峰度和偏度的SW测验、基于拟合度的KS、CVM、AD测验；另一种是用形容的办法：Q-Q图和P-P图、茎叶图，利用四分位数间距和标准差来判断。 方差齐性的次要判断办法有：方差比、Hartley测验、Levene测验、BF法。 因为篇幅问题，对于下面波及到的办法当前专门来讲，有趣味的同学能够先自行查阅。 3.方差分析流程3.1建设假如H0：各组的客单价均值相等；H1：各组的客单价均值不相等或不全等。 测验水准为0.05。 3.2计算测验统计量F值F值 = 组间方差/组内方差。咱们次要是通过比拟F值的大小来判断各组之间是否存在显著差别。 所谓的组间方差就是用来反映组与组之间的差别水平，组内方差就是用来反映各组外部数据的差别水平。 如果各组之间的客单价相等，即假如H0成立，也就意味着各组之间是没啥区别的，也就是组间方差会很小甚至为0，与之对应的方差很大的概率会很低，所以如果F值越大，表明在假如H0成立的前提下呈现呈现这一后果的概率越小，相当于咱们后面提到的小概率事件，如果一旦小概率事件产生了，咱们就有理由去回绝原假如。 要来计算方差，咱们须要先计算平方和。为了让大家可能更加了解，咱们来举个例子来解说各个指标怎么计算。 当初有两组数据： 第一组：80、85、96第二组：110、125、130、145、160 第一组和第二组的总算术平均值为：(80+85+96+110+125+130+145+160)/8 = 116.375。 第一组的算术平均值：(80+85+96)/3 = 87 第二组的算术平均值： (110+125+130+145+160)/5 = 134 组间平方和(SSA)：= 第一组平均值与总体平均值的平方和×第一组样本数+第二组平均值与总体平均值的平方和×第二组样本数= (87-116.375)^2×3 + (134-116.375)^2×5 = 4141.875 组内平方和(SSE)：= 第一组平方和 + 第二组平方和=(80-87)^2+(85-87)^2+(96-87)^2 +(110-134)^2+(125-134)^2+(130-134)^2 +(145-134)^2+(160-134)^2=134+1470=1604 总体平方和(SST)：=所有样本数据与总体平均值之间的平方和=(80-116.375)^2+(85-116.375)^2+(96-116.375)^2 +(110-116.375)^2+(125-116.375)^2+(130-116.375)^2 +(145-116.375)^2+(160-116.375)^2=5745.875 通过以上数据，咱们能够看出 SST = SSA + SSE。 总平方和会有一个问题，就是随着数据量越大，这个值会越大，所以咱们引入另外一个概念：均方。均方=平方和/自由度，其中自由度是样本数-1。 组间均方(MSA) = SSA/自由度 = 4141.875/(2-1) = 4141.875组内均方(MSE) = SSE/自由度 = 1604/(8-2) = 267.333 MSA又称为组间方差，MSE称为组内方差。 F = MSA/MSE = 4141.875/267.333 = 15.4933 ...

这一篇咱们讲讲统计中的最小样本量计算。大家先想想为什么叫最小样本量，而不是最大或者间接叫样本量计算呢？ 这是因为最小样本量这个概念次要用在抽样统计中，抽样统计为了钻研某一事物的状况而从整体中抽取局部样本来进行钻研，并用抽取的样本来代替整体的状况。比方要钻研中学生的均匀身高，你不太可能把全国的中学生身高都量一遍，而后求出一个平均值。比较简单的办法就是从全国中学生群体中抽取一部分，而后用这一部分同学的均匀身高代替全国中学生的均匀身高。 既然是用抽样样本的均匀身高代替整体的均匀身高，咱们就须要思考一个问题，就是抽出来的样本能不能代表整体。假如全国有1000万名中学生，你只抽了100个同学，想用这100位同学的均匀身高代替这1000万同学的均匀身高，很显著是不太正当的。那咱们应该起码抽取多少样本才可能代表整体呢？这个起码抽取样本就是最小样本量，示意起码须要这么多样本量，当然也能够比这多，抽样样本越多后果越具备代表性。然而因为事实中尽可能多的样本很难获取，又为了保障抽样后果足够具备代表性，所以咱们个别抉择最小样本量。那这个最小样本量怎么确定呢？就是咱们这一篇重点要讲的内容。 在讲最小样本量之前，咱们先讲一下另一个概念，统计效用，即power值。这个在之前的文章中也提过，咱们再提一下。 在假设检验中如果计算出来的P值小于等于显著性程度，则回绝零假如，否则承受原假如。在这个决策的过程中容易犯两种谬误：第一类谬误(I型谬误)叫做弃真谬误，艰深一点就是漏诊，就是原本是生病了(假如是正确的)，然而你没有检测进去，所以给回绝掉了；第二类谬误(II型谬误)是取伪谬误，艰深一点就是误诊，就是原本没病(假如是谬误的)，后果你诊断说生病了(假如是正确的)，所以就把假如给承受了。 下图中右边的分布图为H0对应的散布，左边的分布图为H1对应的散布，为一型谬误值，为二型谬误值。I型谬误的值个别为0.05，II型谬误的值个别为0.1或0.2，而power = 1 - ，示意H1散布下判断正确的把握是多少，即你有多大把握可能正确的回绝掉H0假如。 上图中H1散布下对应的整体面积减去图中紫色局部的面积就是power的大小，具体计算公式如下： 示意求z值对应的累计概率，即正态分布中的面积，是两组样本均值之差， 为各组样本标准差，n为样本数。 在个别AB试验中，咱们假如AB两组是同质的，且样本量是统一的，所以有1 = 2，n1 = n2，将下面的power公式进行转换最初能够失去如下对于样本量公式： 须要留神的是不同测验满足的散布是不一样的，对应的power公式也是不一样，而最小样本量公式也是从power来的，所以不同测验形式对应的最小样本量公式也是不一样的。咱们本篇是以满足正态分布的Z测验为例。

上次写了统计学外面的置信度与置信区间当前，文章反应还不错，这次再来试着写写统计学外面的假设检验。 假设检验的外围其实就是反证法。反证法是数学中的一个概念，就是你要证实一个论断是正确的，那么先假如这个论断是谬误的，而后以这个论断是谬误的为前提条件进行推理，推理进去的后果与假如条件矛盾，这个时候就阐明这个假如是谬误的，也就是这个论断是正确的。以上就是反证法的一个简略思路。 理解完反证法当前，咱们开始正式的假设检验，这里还是援用一个大家都很相熟的一个例子『女士品茶』。 女士品茶是一个很长远的故事，讲述了在很久很久以前的一个下午，有一群人在那品茶，这个时候有位女士提出了一个乏味的点，就是把茶加到奶里和把奶加到茶外面最初失去的『奶茶』的滋味是不一样的。大部分人都感觉这位女士在瞎说，只有其中一位男士提出了要用迷信的办法去证实到底一样不一样(牛人想问题角度永远都是那么独特，多想想他人为什么那么说，而不是一上来就不经思考的回绝)。 接下来，咱们具体看一下这一位男士是怎么去证实的。首先他假如了把茶加到奶里和把奶加到茶外面得进去的『奶茶』滋味是一样的。而后随机把这两种『奶茶』端给女士，让女士品，是先加的奶还是先加的茶，如果女士都能品对，阐明的确有差别，如果要是品不对，阐明是没差别的。这外面就波及到一个问题，让女士品多少杯呢，品一杯必定是不行的，因为任意一杯猜对(瞎蒙)的概率都有50%。上面是不同杯数对应的猜对的概率(留神，这里是猜对而不是品对)。 通过上表咱们能够看出，间断4杯都猜对的概率有余0.1，间断10杯都猜对的概率有余0.001。如果把奶加到茶里和把茶加到奶外面失去的『奶茶』真没有差异，也就是女士要想品对，根本全靠猜，然而10杯全副猜对的概率有余0.001，咱们把这种概率很小很小(这里须要定义一下，具体多小算小概率事件)的事件称为小概率事件。咱们认为小概率事件个别是不会产生的，如果产生了，阐明咱们的认知就是谬误的，也就是说女士品茶不是靠猜的，也就是把奶加到茶里和把茶加到奶外面失去的『奶茶』确实是有差异的。 咱们把下面这个过程就叫做假设检验。 理解完假设检验的思维当前，咱们来看一下具体步骤： step1：提出零假如和备择假如；零假如(H0)个别是咱们要颠覆的论点，备择假如(H1)则是咱们要证实的论点。拿下面的女士品茶例子来讲。 H0：把茶加到奶里和把奶加到茶外面失去的『奶茶』是一样的。H0：把茶加到奶里和把奶加到茶外面失去的『奶茶』是不一样的。 step2：结构测验统计量，并找出在H0假如成立的前提下，该统计量所遵从的散布；测验统计量是依据样本观测后果计算失去的样本统计量，并以此对零假如和备择假如做出决策。 下面图片中是三种不同的统计量以及其对应的散布，别离叫做Z测验、T测验、卡方测验。 Z测验：个别用于大样本（即样本容量大于30）平均值差异性测验的办法。它是用规范正态分布的实践来推断差别产生的概率，从而比拟两个平均数的差别是否显著。在国内也被称作u测验。T测验：次要用于样本含量较小（例如n < 30），总体标准差未知的正态分布。T测验是用t散布实践来推论差别产生的概率，从而比拟两个平均数的差别是否显著。卡方测验：卡方测验是统计样本的理论观测值与实践推断值之间的偏离水平，理论观测值与实践推断值之间的偏离水平就决定卡方值的大小，如果卡方值越大，二者偏差水平越大；反之，二者偏差越小；若两个值齐全相等时，卡方值就为0，表明理论值完全符合。上面为三种测验对应的分布图： 依据不同测验的特色，咱们能够依据下图来进行抉择适合的测验形式： step3：依据要求的显著性程度，求临界值和拒绝域 还记得咱们在后面提到的小概率事件吗？如果小概率事件产生了，就示意咱们的零假如是谬误的，可是具体多小的概率才算是小概率呢？个别这个概率为0.05，也就是5%，如果一件事件产生的概率小于等于5%，咱们就认为这是一个小概率事件，0.05就是显著性程度，用示意。显著性程度把概率分布分为两个区间：回绝区间和承受区间，最初计算出来的后果落在回绝区间，咱们就能够回绝零假如；如果落在了承受区间，咱们就须要承受零假如。1-称为置信水平(置信度)。 当初咱们晓得了显著性程度了，而后就能够依据显著性程度求得临界值和拒绝域了。那具体怎么求呢？这里的临界值就是z值(正太散布用z值)或t值(t散布用t值)，以临界值为端点的区间称为拒绝域。z值和t值间接依据显著性程度而后到对应的z值表和t值表中查问即可。 下图为双侧测验和单侧测验对应的、1-、临界值、拒绝域、承受域的状况，其中是示意暗影局部的面积，而不是x轴的值。 到这里显著性程度对应的临界值和拒绝域就算进去了。 step4：计算测验统计量依据咱们在后面抉择测验统计量类型，计算对应的测验统计量的值。除此之外咱们还能够依据样本量得出P值，P值就是理论样本中小概率事件的具体概率值。 step5：决策比拟计算出来的测验统计量与临界值和拒绝域，如果值落在了拒绝域内，那咱们就要回绝零假如，否则承受零假如。 比拟计算出来的P值和显著性程度值，如果P值小于等于，则回绝零假如，否则承受原假如。 下面两种办法别离叫做统计量测验和P值测验。 以上就是假设检验的个别流程。除此之外，假设检验外面还有两种谬误，第一类谬误叫做弃真谬误，艰深一点就是漏诊，就是原本是生病了(假如是正确的)，然而你没有检测进去，所以给回绝掉了；第二类谬误是取伪谬误，艰深一点就是误诊，就是原本没病(假如是谬误的)，后果你诊断说生病了(假如是正确的)，所以就把假如给承受了。 I型谬误的值个别为0.05，II型谬误的值个别为0.1或0.2，除此之外还有一个指标叫做效用(power)，power = 1 - II型谬误的值，power 示意你有多大把握可能正确的回绝你的零假如H0。 对于假设检验咱们就讲到这里，前面会分享统计学外面的其余常识，如果有想看的内容，能够评论区留言。

当初有一个需要，利用启动时须要初始化一些数据，为了保障高可用，会启动多正本（replicas >= 3），如何保证数据不会反复？ 计划一：数据带上主键最简略的办法，初始化数据都带上主键，这样主键抵触就会报错。然而这么做咱们须要对抵触的谬误进行额定解决，因为插入咱们个别会复用已写好的 DAO 层代码。 另外，初始化数据的主键可能是动静生成的，并不想把主键写死。所以上面来介绍此次的配角：基于 MySQL 的分布式锁的解决方案。 计划二：基于 MySQL 的分布式锁多正本分布式应用，在这种 n 选 1 竞争某个资源或执行权的场景，个别都会用到分布式锁。分布式有很多种实现形式，如基于 redis，etcd，zookeeper，file 等零碎。实质上，就是找个多个节点都认可的中央保留数据，通过数据竞态来实现锁，当然这个依赖最好是高可用，否则会引发单点故障。 多个正本都应用同一个 MySQL，所以咱们能够很不便的基于 MySQL 实现一个分布式锁。原理很简略，利用惟一索引保障只有一个副本能插入某条数据，插入胜利则示意取锁胜利，执行结束则删除该条数据开释锁。 建一个表用来寄存锁数据，将 Action 设为惟一索引，示意对某个动作加锁，如：init 初始化，cronjob 定时工作等不同动作之间加锁互不影响。 type lock struct { Id string `gorm:"primary_key"` CreatedAt time.Time UpdatedAt time.Time ExpiredAt time.Time // 锁过期工夫 Action string `gorm:"unique;not null"` Holder string // 持锁人信息，能够应用 hostname}既然有过期工夫，那么持锁工夫设为多长适合呢？设置太短可能逻辑还没执行完锁就过期了；设置太长如果程序中途挂了没有开释锁，那么这段时间所有节点都拿不到锁。 要解决这个问题咱们能够应用租约机制（lease），设置较短的持锁工夫，而后在持锁周期内，一直缩短持锁工夫，直到被动开释。这样即便程序解体没有 UnLock，锁也会因为没有刷新租约很快过期，不影响其余节点获取锁。 Lock 时启动一个 goroutine 刷新租约，Unlock 时通过 stopCh 将其进行。 另外，MySQL 中并没有线程去解决过期的记录，所以咱们在调用 Lock 时先尝试将过期记录删掉。 外围代码： func NewLockDb(action, holder string, lease time.Duration) *lockDb { return &lockDb{ db: GetDB(context.Background()), stopCh: make(chan struct{}), action: action, holder: holder, leaseAge: lease, }}func (s *lockDb) Lock() (bool, error) { err := s.cleanExpired() if err != nil { return false, errx.WithStackOnce(err) } err = s.db.Create(&lock{ ExpiredAt: time.Now().Add(s.leaseAge), Action: s.action, Holder: s.holder, }).Error if err != nil { // Duplicate entry '<action_val>' for key 'action' if strings.Contains(err.Error(), "Duplicate entry") { return false, nil } return false, errx.WithStackOnce(err) } s.startLease() log.Debugf("%s get lock", s.holder) return true, nil}func (s *lockDb) UnLock() error { s.stopLease() var err error defer func() { err = s.db. Where("action = ? and holder = ?", s.action, s.holder). Delete(&lock{}). Error }() return err}func (s *lockDb) cleanExpired() error { err := s.db. Where("expired_at < ?", time.Now()). Delete(&lock{}). Error return err}func (s *lockDb) startLease() { go func() { // 残余 1/4 时刷新租约 ticker := time.NewTicker(s.leaseAge * 3 / 4) for { select { case <-ticker.C: err := s.refreshLease() if err != nil { log.Errorf("refreash lease err: %s", err) } else { log.Debug("lease refreshed") } case <-s.stopCh: log.Debug("lease stopped") return } } }()}func (s *lockDb) stopLease() { close(s.stopCh)}func (s *lockDb) refreshLease() error { err := s.db.Model(&lock{}). Where("action = ? and holder = ?", s.action, s.holder). Update("expired_at", time.Now().Add(s.leaseAge)). Error return err}应用及测试： ...

一、背景随着公司业务的倒退，商品库存从商品核心独立进去成为一个独立的零碎，承接主站商品库存校验、订单库存扣减、售后库存开释等业务。在上线之前咱们对于外围接口进行了压测，压测过程中呈现了 MySQL 5.6.35 死锁景象，通过日志发现引发死锁的只是一条简略的sql，死锁是怎么产生的？发挥技术人员刨根问底的优良传统，对于这次死锁起因进行了粗疏的排查和总结。本文既是此次过程的一个记录。 在深刻探索问题之前，咱们先理解一下 MySQL 的加锁机制。 二、MySQL 加锁机制首先要明确的一点是 MySQL 加锁实际上是给索引加锁，而非给数据加锁。咱们先看下MySQL 索引的构造。 MySQL 索引分为主键索引(或聚簇索引)和二级索引(或非主键索引、非聚簇索引、辅助索引，包含各种主键索引外的其余所有索引)。不同存储引擎对于数据的组织形式略有不同。 对InnoDB而言，主键索引和数据是寄存在一起的，形成一颗B+树(称为索引组织表)，主键位于非叶子节点，数据寄存于叶子节点。示意图如下： 而MyISAM是堆组织表，主键索引和数据离开寄存，叶子节点保留的只是数据的物理地址，示意图如下： 二级索引的组织形式对于InnoDB和MyISAM是一样的，保留了二级索引和主键索引的对应关系，二级索引列位于非叶子节点，主键值位于叶子节点，示意图如下： 那么在MySQL 的这种索引构造下，咱们怎么找到须要的数据呢？ 以select * from t where name='aaa'为例，MySQL Server对sql进行解析后发现name字段有索引可用，于是先在二级索引(图2-2)上依据name='aaa'找到主键id=17，而后依据主键17到主键索引上(图2-1)上找到须要的记录。 理解 MySQL 利用索引对数据进行组织和检索的原理后，接下来看下MySQL 如何给索引桎梏。 须要理解的是索引如何加锁和索引类型(主键、惟一、非惟一、没有索引)以及隔离级别(RC、RR等)无关。本例中限定隔离级别为RC，RR状况下和RC加锁基本一致，不同的是RC为了避免幻读会额定加上间隙锁。 2.1  依据主键进行更新update t set name='xxx' where id=29；只须要将主键上id=29的记录加上X锁即可(X锁称为互斥锁，加锁后本事务能够读和写，其余事务读和写会被阻塞)。如下： 2.2  依据惟一索引进行更新update t set name='xxx' where name='ddd';这里假如name是惟一的。InnoDB当初name索引上找到name='ddd'的索引项(id=29)并加上加上X锁，而后依据id=29再到主键索引上找到对应的叶子节点并加上X锁。 一共两把锁，一把加在惟一索引上，一把加在主键索引上。这里须要阐明的是加锁是一步步加的，不会同时给惟一索引和主键索引加锁。这种分步加锁的机制实际上也是导致死锁的诱因之一。示意如下： 2.3 依据非惟一索引进行更新update t set name='xxx' where name='ddd';这里假如name不惟一，即依据name能够查到多条记录(id不同)。和下面惟一索引加锁相似，不同的是会给所有符合条件的索引项加锁。示意如下： 这里一共四把锁，加锁步骤如下： 在非惟一索引(name)上找到(ddd,29)的索引项，加上X锁；依据(ddd,29)找到主键索引的(29,ddd)记录，加X锁；在非惟一索引(name)上找到(ddd,37)的索引项，加上X锁；依据(ddd,29)找到主键索引的(37,ddd)记录，加X锁；从下面步骤能够看出，InnoDB对于每个符合条件的记录是分步加锁的，即先加二级索引再加主键索引；其次是按记录逐条加锁的，即加完一条记录后，再加另外一条记录，直到所有符合条件的记录都加完锁。那么锁什么时候开释呢？答案是事务完结时会开释所有的锁。 小结：MySQL 加锁和索引类型无关，加锁是按记录逐条加，另外加锁也和隔离级别无关。 三、死锁景象及排查理解MySQL 如何给索引加锁后，上面步入正题，看看理论场景下的死锁景象及其成因剖析。 本次产生死锁的是库存扣减接口，该接口的次要逻辑是用户下单后，扣减订单商品在某个仓库的库存量。比方用户一个在vivo官网下单买了1台X50手机和1台X30耳机，那么下单后，首先依据用户收货地址确定发货仓库，而后从该仓库外面别离减去一个X50库存和一个X30库存。剖析死锁sql之前，先看下商品库存表的定义(为不便了解，只保留次要字段)： CREATE TABLE `store` ( `id` int(10) AUTO_INCREMENT COMMENT '主键', `sku_code` varchar(45) COMMENT '商品编码', `ws_code` varchar(32) COMMENT '仓库编码', `store` int(10) COMMENT '库存量', PRIMARY KEY (`id`), KEY `idx_skucode` (`sku_code`), KEY `idx_wscode` (`ws_code`) ) ENGINE=InnoDB COMMENT='商品库存表'留神这里别离给sku_code和ws_code两个字段独自定义了索引：idx_skucode, idx_wscode。这样做的起因次要是业务上有依据单个字段查问的要求。 ...

前言： 在各类技术岗位面试中，仿佛 MySQL 相干问题常常被问到。无论你面试开发岗位或运维岗位，总会问几道数据库问题。常常有小伙伴私信我，询问如何应答 MySQL 面试题。其实很多面试题都是大同小异的，提前做筹备还是很有必要的。本篇文章简略说下几个常见的面试题，一起来学习下吧。 1.什么是关系型数据库？谈谈你对 MySQL 的意识。这是一道根底题，考查面试者对数据库的理解水平，个别能够简略讲下本人的认知，有条理即可。比方： 关系型数据库是指采纳了关系模型来组织数据的数据库，其以行和列的模式存储数据。关系型数据库最大的特点是反对事务。常见的关系型数据库有 MySQL、Oracle、SQLServer 等。MySQL 是当下最风行的开源数据库。因为其体积小、速度快、总体领有成本低，尤其是开放源码这一特点，使得很多公司都采纳 MySQL 数据库以降低成本，目前被宽泛地利用在 Internet 上的中小型网站中，尤其实用于 OLTP 畛域。 2.MySQL 常见的存储引擎有哪些，有什么区别？这个问题也常常被问到，和『InnoDB 与 MyISAM 引擎的区别』问题类似。 常见的几种存储引擎： InnoDB: MySQL 默认的存储引擎，反对事务、MVCC、外键、行级锁和自增列。MyISAM: 反对全文索引、压缩、空间函数、表级锁，不反对事务，插入速度快。Memory: 数据都在内存中，数据的处理速度快，然而安全性不高。ARCHIVE: 罕用于历史归档表，占用空间小，数据不能更新删除。InnoDB 与 MyISAM 引擎的几点区别： InnoDB 反对事务，MyISAM 不反对事务。InnoDB 反对外键，而 MyISAM 不反对。InnoDB 不反对全文索引，而 MyISAM 反对。InnoDB 是聚簇索引，MyISAM 是非聚簇索引。InnoDB 不保留表的具体行数，而 MyISAM 用一个变量保留了整个表的行数。InnoDB 最小的锁粒度是行锁，MyISAM 最小的锁粒度是表锁。存储构造不同，MyISAM 表分为 frm MYD MYI 三个，InnoDB 个别分为 frm ibd 两个。3.形容下 MySQL 基础架构。这个问题考查面试者对 MySQL 架构的理解，和『一条 select 语句执行流程』问题类似。 MySQL的逻辑架构图(起源:《MySQL实战45讲》) MySQL的逻辑架构次要分为3层： 第一层：对客户端的连贯解决、平安认证、受权等，每个客户端连贯都会在服务端领有一个线程，每个连贯发动的查问都会在对应的独自线程中执行。第二层：MySQL的外围服务性能层，包含查问解析、剖析、查问缓存、内置函数、存储过程、触发器、视图等，select操作会先查看是否命中查问缓存，命中则间接返回缓存数据，否则解析查问并创立对应的解析树。第三层：存储引擎，负责数据的存储和提取，MySQL服务器通过API与存储引擎通信，屏蔽了各种引擎之间的差别，常见的存储引擎有：InnoDB、MyISAM。一条 select 语句执行流程： ...

应该创立索引的场景主键应该创立主键索引。频繁作为查问条件的字段应该创立索引。查问中须要与其余表进行关联的字段应该创立索引。须要排序的字段应该创立索引。须要统计或分组的字段应该创立索引。优先思考创立复合索引。不适宜创立索引的场景频繁更新的字段不适宜创立索引。查问条件中用不到的字段不适宜创立索引。不应创立索引的场景数据记录较少的表。常常须要增删改操作的字段。数据记录反复较多且散布均匀的字段（如性别、状态等）。索引的选择性是指索引列中不同值的数目与表中记录总数的比。索引的选择性越靠近于1，创立索引的价值就越高。反之就越低。MySQL 常见的性能瓶颈CPU：通常产生在数据载入内存或从磁盘上读取数据时。IO：通常产生在载入数据远大于内存容量时。服务器硬件：通过top，free，iostat，vmstat等命令查看零碎的性能情况。

索引分类单列索引：一个索引只蕴含一个列。 ALTER TABLE table_name ADD INDEX index_name (col);复合索引：一个索引蕴含多个列。 ALTER TABLE table_name ADD INDEX index_name (col1, col2);索引类型主键索引： ALTER TABLE table_name ADD PRIMARY KEY (col);惟一索引： 索引列的值必须是惟一的，但容许 NULL 值。 ALTER TABLE table_name ADD UNIQUE index_name (col);一般索引： ALTER TABLE table_name ADD INDEX index_name (column_list);全文索引： ALTER TABLE table_name ADD FULLTEXT index_name (column_list);索引构造BTree索引 Hash索引 哈希索引（hash index）基于哈希表实现，只有准确匹配索引所有列的查问才无效。对于每一行数据，存储引擎都会对所有的索引列计算一个哈希码（hash code），哈希码是一个较小的值，并且不同键值的行计算出来的哈希码也不一样。哈希索引将所有的哈希码存储在索引中，同时在哈希表中保留指向每个数据行所在的物理地址的指针。 索引的操作创立索引： ALTER TABLE table_name ADD INDEX index_name (column_list);删除索引： DROP INDEX index_name ON table_name;查看索引： SHOW INDEX FROM table_name\G

1.情景再现某年某月某日 下午安心工作中 运维：在吗？方才工具扫出来线上有一批 Mysql 表不合乎新标准，你看一下！ 我：好的，我看一下。 心田 OS：什么鬼？还能不能好好撸代码了？ 通过一阵排查中，根本都是局部 Mysql 表无主键，很简略嘛，加个数据 id 就完事了！ 什么鬼，这个表怎么两千万数据了，印象里不应该有这麽多数据啊，代码复查一把，果然又是祖传遗产的锅，这个删除逻辑齐全没用。 问题来了，两千万的 Mysql 表，以目前线上机器的性能，很放心一把操作就挂了。 接下来就是搜索引擎的天下了，搜寻中... 咦，这个 MysqlTools 是啥？说这是运维工具，但看起来批量删除历史数据也挺好用的。 2.工具介绍MysqlTools-Python 是一监控项采集、备份、巡检、日志剖析、主动故障解决于一身的工具包。 工具列表工具名性能阐明mtls-monitor监控项采集mtls-backup自动化备份数据库mtls-delete-rows分批(温和)删除大表中的行mtls-file-truncate分批(温和)的截断物理文件mtls-big-files查问出给定目录下的大文件名mtls-httptcp(http)端口连通性测试mtls-log慢查问日志切片mtls-perf-bench数据库跑分工具(开发中)mtls-kill-all-connections杀死所有的客户端连贯mtls-sql-distribution统计慢查问文件中的SQL类型与热点表mtls-file-stat表的最晚更新工夫统计mtls-expired-tables找出长时间没有应用过的表3.Linux 环境装置步骤3.1 环境依赖MySqlTools-Python 工具反对 Python-3.x 下的所有版本，可间接通过 pip 装置。 3.2 Python 装置在Linux零碎中，零碎自带的 Python 环境根本是 2.x 版本，须要重新安装 Python 3 环境。 留神：无非凡起因不删除零碎自带的 Python 2 环境，防止依赖 Python 2 的工具呈现问题。Python 各版本下载地址：https://www.python.org/ftp/py... 下载安装包 wget https://www.python.org/ftp/python/3.9.1/Python-3.9.1.tgz解压安装包到当前目录 tar -xvf Python-3.9.1.tgz装置依赖 依赖包装置量间接影响到 Python 解释器所反对的性能，以下依赖包根本可笼罩性能反对。 yum -y install gcc gcc-c++ libffi libyaml-devel libffi-devel zlib zlib-devel openssl shadow-utils net-tools openssl-devel libyaml sqlite-devel libxml2 libxslt-devel libxml2-devel wget vim mysql-devel留神：如果因为环境问题 mysql-devel 装置报错，可不进行装置。新建Python 3目录 ...

需要剖析任何一个电商零碎中都有一个商品子系统，而与商品相关联的都会有一个品牌信息管理子系统，在以后也为设计中咱们就是要对商品品牌信息进行治理。 业务架构在品牌（brand）治理中就是要实现对商品品牌信息的增加、批改、查问、删除等业务，如图所示： 原型设计基于业务形容，对品牌模块的业务原型进行剖析和设计，如图所示： 品牌列表页面 品牌编辑页面 技术架构在品牌治理模块实现过程中，咱们采纳典型的c/s（client/service）架构进行实现。客户端咱们基于浏览器(web)进行实现，服务端采纳Tomcat，数据库应用mysql，具体应用层基于MVC分层架构进行实现。 技术栈选型客户端技术：html、css、JavaScript、bootstrap（框架） 服务端技术：spring、mybatis、springboot、thymeleaf 数据库技术：MySQL（数据库）、SQL（编程语言） 开发工具集:jdk1.8,maven3.6.3，idea2020.2 我的项目环境初始化1）JDK 1.82）Maven 3.6.33）Idea 2020.24）MySQL 5.7以上版本 初始化数据库如果数据库已存在,则先删除数据库,代码如下: drop database if exists dbbrand;创立新的数据库,代码如下: create database dbbrand default character set utf8;设计并创立品牌(Brand)表关上数据库，语句如下： use dbbrand;在dbbrand数据库中创立品牌表. create table tb_brand( id bigint primary key auto_increment, name varchar(100) not null, remark text, createdTime datetime not null)engine=InnoDB;基于SQL脚本执行数据库初始化drop database if exists dbbrand;create database dbbrand default character set utf8;use dbbrand;create table tb_brand( id bigint primary key auto_increment, name varchar(100) not null, remark text, createdTime datetime not null)engine=InnoDB;将以上数据库设计脚本写到brand.sql中,而后按如下步骤执行: ...

索引简介索引是帮忙 MySQL 高效获取数据的数据结构。 索引的目标在于进步查问效率，与字典相似，能够了解为“排好序的疾速查找数据结构”。 数据库除数据自身之外，还维护者一个满足特定查问算法的数据结构，这些数据结构以某种形式指向数据，这样就能够在这些数据机构的根底上实现高级查找算法，这种数据结构就是索引。 咱们平时所说的索引，个别是指B+树（多路搜寻树）构造组织的索引。 索引构造示例 上图中，为了放慢 Col2 的查找，能够保护一个右图所示的二叉树，每个节点别离蕴含索引键值和指向对应数据记录物理地址的指针，这样就能够通过二叉查找疾速获取数据记录的物理地址，从而找到相应的数据。 索引的长处进步数据查找效率，升高数据库的IO老本。 晋升数据排序效率，升高数据库的CPU耗费。 索引的毛病索引实际上也是数据表，过多的索引会占用更多的磁盘空间。 索引会升高增删改的速度，因为每次操作数据都须要对索引文件进行保护。

一、数据库连贯const mysqlDb = require("mysql");const config = require("./dbconfig");let options = { host: config.config.db_host, --主机名 user: config.config.db_user, --用户名 password: config.config.db_passwd, --用户明码 database: config.config.db_name, --数据库名 multipleStatements: true, --启用多线池}; var pool = mysqlDb.createPool(options); exports.query = function (sql, values) { return new Promise((resolve, reject) => { pool.getConnection(function (err, connection) { if (err) { reject(err) //console.log(err, "数据库连贯失败"); resolve({ status: 500, }); } else { //console.log("数据库连贯胜利"); connection.query(sql, values, (err, results) => { if (err) { reject(err); resolve({ status: 400 }); } else { connection.release(); resolve({ status: 200, results, }); //resolve(rows) } //connection.release() // 开释连接池 }); } }) }) }二、数据库操作--user 数据库表名1.数据库查问精准查问select * from user where title --查问一title查问所有数据select * from user where title='今日新闻' --查问title为今日新闻的一条数据多条件查问select * from user where title='今日新闻' and age='28'select * from user where title='今日新闻' or age='28'含糊查问select * from user where title like '%龙%' --查问出所有含有“龙”的记录select * from user where realname like '%文%' and realname like '%龙%' --所查问字段 + like '%龙%' and 所查问字段 + like '%文%' 2、具体数据库查问 let ctx_query = ctx.request.body; --承受post取值 let pageSize = ctx_query.size-1; --每页显示的条数 let page = ctx_query.page ? (ctx_query.page - 1) * pageSize : 0; --页数 //查询数据库 let sql = "select * from list"; --不带分页的查问 let total = await db.query(sql); --总页数 if (ctx_query.country==''&& ctx_query.title) { sql += ` where title like '%${ctx_query.title}%' limit ${page},${pageSize}`; }else if (ctx_query.country && ctx_query.title=='') { sql += ` where country like '%${ctx_query.country}%' limit ${page},${pageSize}`; }else if (ctx_query.country == "" && ctx_query.title=="") { sql += ` limit ${page},${pageSize}`; } else { sql += ` where title like '%${ctx_query.title}%' and country like'%${ctx_query.country}%' limit ${page},${pageSize}`; } console.log('sql',sql) const result = await db.query(sql);3.数据库插入数据INSERT INTO users ( id, user,passwd) VALUES (12,'zhaofang','111111' );let query = ctx.request.body; --承受post传值let sql = "INSERT INTO list"; --list为表名sql += ` (title, date,content,name,country,city) VALUES ('${query.title}','${query.date}','${query.content}','${query.name}','${query.country}','${query.city}' )`;const results = await db.query(sql) --连贯数据库操作4.数据库批改数据let query = ctx.request.body; --承受post传值let sql = "UPDATE list SET";sql += ` title='${query.title}',date='${query.date}',content='${query.content}',name='${query.name}',country='${query.country}',city='${query.city}' where id='${query.id}'`;const results = await db.query(sql) --连贯数据库操作5.数据库删除let query = ctx.query; --承受del传值let sql = `DELETE FROM list where id='${query.id}'`;const results = await db.query(sql);假如主键或者惟一索引为 good_id收到客户端{pageNo:5,pagesize:10}select from table where good_id > (pageNo-1)pageSize limit pageSize;–返回good_id为40到50之间的数据 ...

SELECT TABLE_NAME "表名", COLUMN_NAME "字段名称", COLUMN_TYPE "字段类型长度",IF ( EXTRA = "auto_increment", CONCAT( COLUMN_KEY, "(", IF ( EXTRA = "auto_increment", "自增长", EXTRA ), ")" ), COLUMN_KEY ) "主外键", IS_NULLABLE "空标识", COLUMN_COMMENT "字段阐明" FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'gzh-test-sn';SELECT TABLE_NAME "表名", TABLE_COMMENT "正文" FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'gzh-test-sn';

我在mysql官网上下载了mysql-8.0.23-macos10.15-x86_64.dmg的软件包,一路点next应用的都是默认的选项，设置我的mysql明码的时候抉择的也是默认的Use Strong Password Encryption,一路装置实现后，在命令面板里通过命令创立数据库、表、字段都是失常的，当应用可视化软件连贯数据库的时候却连贯失败，百度了很多解决办法输出各种命令都没有用，直到看到了一位网友的文章才豁然开朗MySQL said: Authentication plugin 'caching_sha2_password' cannot be loaded: dlopen(/usr/local/lib/plugin/caching_sha2_password.so, 2): image not found 原来最后抉择明码的加密类型选错了，于是删除了/usr/local/里的mysql目录,重新安装换成了Use Legacy Password Encryption的加密，设置明码，装置胜利后再次连贯本地数据库就胜利了

在 spring boot 我的项目中配置多个数据源的情景在开发中常常会遇见，本文以 Spring Boot + MyBatis 的形式实现 mysql + Postgresql 双数据源我的项目搭建，具体具体代码请参考： https://gitee.com/senn-wen/my...一、依赖配置在 pom.xml 文件中引入 postgresql 和 mysql 的驱动文件。 <dependency> <groupId>org.postgresql</groupId> <artifactId>postgresql</artifactId> <scope>runtime</scope></dependency><!-- https://mvnrepository.com/artifact/mysql/mysql-connector-java --><dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope></dependency>二、Spring boot 配置2.1 application.yml 配置配置须要连贯的数据库连贯参数，上面的样例配置了 postgresql 和 mysql ，因为我抉择了hikariCP 作为连接池，因而在上面配置了下 hikari，如果是线上的服务倡议依据理论的服务器性能大小设置好该参数。记住你连贯参数的配置门路，后续要应用到。 spring: datasource: postgresql: driver-class-name: org.postgresql.Driver url: jdbc:postgresql://url:port/database username: postGIS password: postGIS mysql: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://url:port/database username: root password: root hikari: maximum-pool-size: 3 connection-timeout: 5002.2 排除Spring datasource 自动化配置依赖因为 Spring Boot 会进行主动拆卸你的配置，为了使你自定义配置失效，需要在@SpringBootApplication 中排除掉和 datasoure 相干的配置。次要有三个： ...

摘要： MySQL到ClickHouse数据同步原理及实际引言相熟MySQL的敌人应该都晓得，MySQL集群主从间数据同步机制非常欠缺。令人惊喜的是，ClickHouse作为近年来煊赫一时的大数据分析引擎也能够挂载为MySQL的从库，作为MySQL的 "协处理器" 面向OLAP场景提供高效数据分析能力。新近的计划比拟含糊其辞，通过第三方插件将所有MySQL上执行的操作进行转化，而后在ClickHouse端逐个回放达到数据同步。终于在2020年下半年，Yandex 公司在 ClickHouse 社区公布了MaterializeMySQL引擎，反对从MySQL全量及增量实时数据同步。MaterializeMySQL引擎目前反对 MySQL 5.6/5.7/8.0 版本，兼容 Delete/Update 语句，及大部分罕用的 DDL 操作。 根底概念MySQL & ClickHouseMySQL个别特指残缺的MySQL RDBMS，是开源的关系型数据库管理系统，目前属于Oracle公司。MySQL凭借不断完善的性能以及沉闷的开源社区，吸引了越来越多的企业和个人用户。 ClickHouse是由Yandex公司开源的面向OLAP场景的分布式列式数据库。ClickHouse具备实时查问，残缺的DBMS及高效数据压缩，反对批量更新及高可用。此外，ClickHouse还较好地兼容SQL语法并领有开箱即用等诸多长处。 Row Store & Column StoreMySQL存储采纳的是Row Store，表中数据依照 Row 为逻辑存储单元在存储介质中间断存储。这种存储形式适宜随机的增删改查操作，对于按行查问较为敌对。但如果抉择查问的指标只波及一行中少数几个属性，Row 存储形式也不得不将所有行全副遍历再筛选出指标属性，当表属性较多时查问效率通常较低。只管索引以及缓存等优化计划在 OLTP 场景中可能晋升肯定的效率，但在面对海量数据背景的 OLAP 场景就显得有些力不从心了。 ClickHouse 则采纳的是 Column Store，表中数据依照Column为逻辑存储单元在存储介质中间断存储。这种存储形式适宜采纳 SIMD (Single Instruction Multiple Data) 并发解决数据，尤其在表属性较多时查问效率显著晋升。列存形式中物理相邻的数据类型通常雷同，因而人造适宜数据压缩从而达到极致的数据压缩比。 应用办法部署Master-MySQL开启BinLog性能：ROW模式开启GTID模式：解决位点同步时MySQL主从切换问题（BinLog reset导致位点生效） 部署Slave-ClickHouse获取 ClickHouse/Master 代码编译装置举荐应用GCC-10.2.0，CMake 3.15，ninja1.9.0及以上 创立Master-MySQL中database及table 创立 Slave-ClickHouse 中 MaterializeMySQL database 此时能够看到ClickHouse中曾经有从MySQL中同步的数据了： 工作原理BinLog EventMySQL中BinLog Event次要蕴含以下几类： 事务提交后，MySQL 将执行过的 SQL 解决 BinLog Event，并长久化到 BinLog 文件 ...

什么是RBACRBAC 是基于角色的访问控制（Role-Based Access Control ）在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而失去这些角色的权限。这就极大地简化了权限的治理。这样治理都是层级相互依赖的，权限赋予给角色，而把角色又赋予用户，这样的权限设计很分明，治理起来很不便。参考：https://shuwoom.com/?p=3041 这边管理系统只用最简略的RBAC0模型 表设计sys_user表CREATE TABLE `sys_user` ( `id` varchar(32) NOT NULL, `username` varchar(32) NOT NULL COMMENT '用户名', `password` varchar(64) NOT NULL COMMENT '明码', `sex` char(1) DEFAULT NULL COMMENT '性别 0 女| 1 男', `locked` char(1) DEFAULT NULL COMMENT '是否锁住 0 否 | 1 是', `create_time` datetime DEFAULT NULL COMMENT '创立工夫', `create_by` varchar(32) DEFAULT NULL COMMENT '创建者', `update_time` datetime DEFAULT NULL COMMENT '更新工夫', `update_by` varchar(32) DEFAULT NULL COMMENT '更新者', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;sys_role表CREATE TABLE `sys_role` ( `id` varchar(32) NOT NULL COMMENT 'ID', `code` varchar(32) NOT NULL COMMENT '角色编码', `name` varchar(32) DEFAULT NULL COMMENT '角色名称', `forbidden` varchar(1) DEFAULT NULL COMMENT '是否禁用 0：失常 | 1：禁用', `create_by` varchar(32) DEFAULT NULL COMMENT '创建人', `create_time` datetime DEFAULT NULL COMMENT '创立工夫', `update_by` varchar(32) DEFAULT NULL COMMENT '更新人', `update_time` datetime DEFAULT NULL COMMENT '更新工夫', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='角色表';sys_menu表CREATE TABLE `sys_menu` ( `id` varchar(32) NOT NULL COMMENT 'ID', `parent_id` varchar(32) DEFAULT '0' COMMENT '父级菜单ID', `code` varchar(32) NOT NULL COMMENT '菜单编码', `name` varchar(32) NOT NULL COMMENT '菜单名称', `type` char(1) DEFAULT NULL COMMENT '菜单类型 0：菜单 | 1：按钮（权限）', `permission` varchar(32) DEFAULT NULL COMMENT '权限标识', `icon` varchar(32) DEFAULT NULL COMMENT '图标', `path` varchar(32) DEFAULT NULL COMMENT '路由地址', `component` varchar(32) DEFAULT NULL COMMENT '组件门路', `sort` varchar(32) DEFAULT NULL COMMENT '排序', `forbidden` varchar(1) DEFAULT NULL COMMENT '是否禁用 0：失常 | 1：禁用', `create_by` varchar(32) DEFAULT NULL COMMENT '创建人', `create_time` datetime DEFAULT NULL COMMENT '创立工夫', `update_by` varchar(32) DEFAULT NULL COMMENT '更新人', `update_time` datetime DEFAULT NULL COMMENT '更新工夫', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='菜单表';sys_user_role表CREATE TABLE `sys_user_role` ( `id` varchar(32) NOT NULL COMMENT 'ID', `user_id` varchar(32) NOT NULL COMMENT '用户ID', `role_id` varchar(32) NOT NULL COMMENT '角色ID', `create_by` varchar(32) DEFAULT NULL COMMENT '创建人', `create_time` datetime DEFAULT NULL COMMENT '创立工夫', `update_by` varchar(32) DEFAULT NULL COMMENT '更新人', `update_time` datetime DEFAULT NULL COMMENT '更新工夫', PRIMARY KEY (`id`), UNIQUE KEY `uk_user_role` (`user_id`,`role_id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户角色关系表';sys_role_menu表CREATE TABLE `sys_role_menu` ( `id` varchar(32) NOT NULL COMMENT 'ID', `role_id` varchar(32) NOT NULL COMMENT '角色ID', `menu_id` varchar(32) NOT NULL COMMENT '菜单ID', `create_by` varchar(32) DEFAULT NULL COMMENT '创建人', `create_time` datetime DEFAULT NULL COMMENT '创立工夫', `update_by` varchar(32) DEFAULT NULL COMMENT '更新人', `update_time` datetime DEFAULT NULL COMMENT '更新工夫', PRIMARY KEY (`id`), UNIQUE KEY `uk_role_menu` (`role_id`,`menu_id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='角色菜单关系表';再来一个代码生成配置表，前面的业务代码对立由这个表配置生成 ...

本文章是依据B站UP主尚硅谷周阳老师教学视频进行练习，会继续更新视频链接:https://www.bilibili.com/vide...SpringCloud=散布式微服务架构的一站式解决方案，是多种微服务架构落地技术的集合体，俗称微服务全家桶 SpringBoot是一种服务开发技术 服务注册与发现：EUREKA 服务负载平衡与调用：NETFLIX OSS RIBBON 服务负载与调用：NETTFLIX 服务熔断降级：HYSTRIX 服务网关：Zuul 服务分布式配置：SpringCloud Config 服务开发：SpingBoot 1、新建Maven我的项目，删除Src文件，此我的项目作为聚合工程的父工程应用POM文件 <?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/m...d"> <modelVersion>4.0.0</modelVersion> <groupId>com.springcloud</groupId> <artifactId>cloud2021</artifactId> <version>1.0-SNAPSHOT</version> <packaging>pom</packaging> <name>Maven</name> <!-- FIXME change it to the project's website --> <url>http://maven.apache.org/</url> <inceptionYear>2001</inceptionYear> <distributionManagement> <site> <id>website</id> <url>scp://webhost.company.com/www/website</url> </site> </distributionManagement> <!--对立治理jar包版本--> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> <junit.version>4.12</junit.version> <log4j.version>1.2.17</log4j.version> <lombok.version>1.16.18</lombok.version> <mysql.version>5.1.47</mysql.version> <druid.version>1.1.16</druid.version> <mybatis.spring.boot.version>1.3.0</mybatis.spring.boot.version> </properties> <!--子模块继承之后，提供作用：锁定版本+子module不必groupId和version--> <dependencyManagement> <dependencies> <!--spring boot 2.2.2--> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> <version>2.2.2.RELEASE</version> <type>pom</type> <scope>import</scope> </dependency> <!--spring cloud Hoxton.SR1--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>Hoxton.SR1</version> <type>pom</type> <scope>import</scope> </dependency> <!--spring cloud alibaba 2.1.0.RELEASE--> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-alibaba-dependencies</artifactId> <version>2.1.0.RELEASE</version> <type>pom</type> <scope>import</scope> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>${mysql.version}</version> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>druid</artifactId> <version>${druid.version}</version> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>${mybatis.spring.boot.version}</version> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>${junit.version}</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>${lombok.version}</version> <optional>true</optional> </dependency> </dependencies> </dependencyManagement> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <fork>true</fork> <addResources>true</addResources> </configuration> </plugin> </plugins> </build></project>2、数据库建表 ...

摘要：MySQL 提供了多种存储引擎来反对事务。MySQL 提供了多种存储引擎来反对事务。反对事务的存储引擎有 InnoDB 和 BDB，其中，InnoDB 存储引擎事务次要通过 UNDO 日志和 REDO 日志实现，MyISAM 存储引擎不反对事务。 拓展：任何一种数据库，都会领有各种各样的日志，用来记录数据库的运行状况、日常操作、错误信息等，MySQL 也不例外。例如，当用户 root 登录到 MySQL 服务器，就会在日志文件里记录该用户的登录工夫、执行操作等。 为了保护 MySQL 服务器，常常须要在 MySQL 数据库中进行日志操作： UNDO 日志：复制事务执行前的数据，用于在事务产生异样时回滚数据。REDO 日志：记录在事务执行中，每条对数据进行更新的操作，当事务提交时，该内容将被刷新到磁盘。默认设置下，每条 SQL 语句就是一个事务，即执行 SQL 语句后主动提交。为了达到将几个操作做为一个整体的目标，须要应用 BEGIN 或 START TRANSACTION 开启一个事务，或者禁止以后会话的主动提交。 执行事务的语法和流程SQL 应用下列语句来治理事务。 1) 开始事务BEGIN; 或 START TRANSACTION; 这个语句显式地标记一个事务的起始点。 2) 提交事务MySQL 应用上面的语句来提交事务： COMMIT; COMMIT 示意提交事务，即提交事务的所有操作，具体地说，就是将事务中所有对数据库的更新都写到磁盘上的物理数据库中，事务失常完结。 提交事务，意味着将事务开始以来所执行的所有数据都批改成为数据库的永恒局部，因而也标记着一个事务的完结。一旦执行了该命令，将不能回滚事务。只有在所有批改都筹备好提交给数据库时，才执行这一操作。 3) 回滚（撤销）事务MySQL 应用以下语句回滚事务： ROLLBACK; ROLLBACK 示意撤销事务，即在事务运行的过程中产生了某种故障，事务不能继续执行，零碎将事务中对数据库的所有已实现的操作全副撤销，回滚到事务开始时的状态。这里的操作指对数据库的更新操作。 当事务执行过程中遇到谬误时，应用 ROLLBACK 语句使事务回滚到终点或指定的放弃点处。同时，零碎将革除自事务终点或到某个保留点所做的所有的数据批改，并且开释由事务管制的资源。因而，这条语句也标记着事务的完结。 总结BEGIN 或 START TRANSACTION 语句前面的 SQL 语句对数据库数据的更新操作都将记录在事务日志中，直至遇到 ROLLBACK 语句或 COMMIT 语句。如果事务中某一操作失败且执行了 ROLLBACK 语句，那么在开启事务语句之后所有更新的数据都能回滚到事务开始前的状态。如果事务中的所有操作都全副正确实现，并且应用了 COMMIT 语句向数据库提交更新数据，则此时的数据又处在新的统一状态。 ...

从Apache Kafka的传统公布订阅零碎，到相干的流解决框架，例如Apache Samza，Apache Storm，Apache Flink，都实用于大多数工作在根本决策能力、运行效率、撑持的数据规模和稳定性方面的需要。 然而，Apache这类开源我的项目，并不可能满足于大多数的行业需要，比方在金融、广告技术、医疗物联、电信等行业。 那应用内存NewSQL数据平台来解决实时数据流有哪些益处呢？ 1、简单的机器学习运算 对于古代程序来说，领有一个具备实时决策能力的引擎至关重要。尽管传统的流数据处理平台领有一些根本的机器学习和模式识别能力，但还是不足一些重要的场景个性： 以毫秒为单位来实时决策简单的、有大量参数变量和上下文状态的场景从历史数据和实时数据流中，动静训练和更新机器学习模型的场景基于内存的NewSQL关系数据库管理系统，简称（RDBMS），是为了疾速解决简单的数据而建设。 RDBMS的外围性能，比方：用户自定义函数和存储过程等，可用来用作自定义的机器学习模型，不便嵌入到数据库系统中，进行数据流的实时决策。PMML模型会被主动转化成UDF并使用于生产。 只有基于内存的NewSQL RDBMS能够为古代大规模利用提供可执行的简单决策+低提早+高效率等一系列组合需要。 2、目前SQL还是王道SQL是一个具备悠久历史并被公认的数据查问规范，所有尝试代替SQL的工具最初都以失败告终，其中也包含了像是Apache Hadoop框架下的MapReduce和其余少数NoSQL工具。 带有讥刺的是目前少数NoSQL把重心放在增加SQL或是SQL相似的查询语言。就连Apache Kafka也在适应SQL的时代，并为了流解决而退出KSQL。 然而，目前KSQL规范离SQL还是相差甚远。 在另一方面，作为一个参照与NewSQL RDBMS而创建的零碎，VoltDB在流数据上提供了全面的ANSI实用型SQL，实现更广的查问和操作简单的事件处理。 此外，ANSI实用型SQL也能给开发者们提供对于疾速流解决所须要的相熟度，灵便度和标准化。NewSQL在给HTAP提供雷同的NoSQL可扩展性平台的同时，也不会影响到ACID语义保障。 3、ACID保障很重要一个优良的NewSQL RDBMS不仅仅是一个疾速、可扩大、容易部署的零碎，在简化开发和部署的同时，它还须要提供ACID保障。 从开发者的角度，ACID可了解为： 简化的查问过程。把简单的单个数据表查问语句简化成多个查问语句，通过引入事务的概念确保他们有雷同的执行后果，严格的ACID要求确保了这些查问语句是能够独立执行的。更容易的数据测试。对于数据库的数据变更，都能够通过事务操作来实现，在实现数据测试之前回滚事务状态即可。隔离性确保了多个数据测试能够并行执行，不会导致数据在不确定状态下被批改。更快的并发。ACID保障每个事务的隔离性前提下，并发的程序能够运行地更放慢，也不须要开发者们在本人应用逻辑中思考不同事务操作的并发时序。简略来说，传统的流解决技术曾经不可能像NewSQL RDBMS一样合乎ACID保障。它们最多只能蕴含能提供最终一致性的NoSQL数据库。 对于企业来说，数据的准确性和一致性是至关重要的。不残缺的材料不仅仅会让企业损失惨重，还会重大影响到企业品牌形象。更多对于NewSQL流解决信息，请参考以下文件： 或复制下方链接下载???? https://www.slidestalk.com/VoltDB/Whitepaper_VoltDBt_Streaming_Processing_ArchitectureF74054

[TOC] 一. 索引与优化本篇内容次要来自极客工夫《MySQL实战45讲》中的: 04 - 深入浅出索引(上)05 - 深入浅出索引(下)根本数据存储模型有序数组哈希表搜寻树跳表 Redis 的有序汇合应用的就是这个构造LSM树 等有序数组:长处: 查找很快, 反对范畴查问 毛病: 插入代价高, 必须逻辑上挪动后续的所有记录 搜寻树:二叉搜寻树搜寻效率最高, 但理论并不采纳, 因为索引是存在磁盘的. 假如一棵树高为20, 一次搜寻就须要20个数据块, 对应磁盘就是20次随机查找. 对于一般硬盘来说, 一次寻址约 10ms, 则一次搜寻就须要 20x10ms = 200ms.如果要让一个查问尽量少读磁盘, 那就必须尽量少地查问数据块, 应该应用上面的多叉树. 多叉树 为了缩小磁盘拜访次数, 能够应用 "N叉"树, 这里的 N 取决于数据块的大小. 以 InnoDB 中 一个整数字段为例, 这个N差不多是1200. 计算方法: 补充!!如果树高为4, 则能够存储 1200^3 个值, 思考树根数据块根本都在内存中, 因而一次搜寻只须要3次磁盘查找, 思考到第2层数据块也有很大概率在内存中, 那么拜访磁盘次数就更少了. 引申: InnoDB 里N叉树中的N如何调整N = 页page的大小 / 每个索引项大小 N叉树中非叶子节点寄存的是索引信息, 每个索引项蕴含Key和Point指针及其他辅助数据, 其中Point指针固定大小6字节, 默认索引页的大小是16KB. 因而主键为int时, int占用4个字节, 加上辅助数据差不多每个索引项占用13字节, 因而非叶子节点大概能够存储 16k/13 ≈ 1260 个左右.N的大小大抵是根据上述式子决定的, 因而若要调整N, 则有2个防线: ...

表数据类型数值tinyint 非常小的数据 1个字节smalint 较小的数据 2个字节mediumint 中等大小的数据 3个字节int 规范的整数 4个字节（罕用）bigint 较大的数据 8个字节float 浮点数 4个字节double 浮点数 8个字节（存在精度问题）decimal 字符串模式的浮点数 金融计算的时候，个别是应用decimal 字符串char 字符串固定大小的 0~255varchar 可变字符串 0~65535 罕用的Stringtintext 微型文本 2^8-1text 文本串 2^16-1 保留大文本 工夫日期java.util.Date->date YYYY-MM-DD，日期工夫->time HH: mm: ss 工夫格局->datetime YYYY-MM-DD HH: mm: ss 最罕用的工夫格局->timestamp 工夫戳， 1970.1.1 到当初的毫秒数->year 年份示意 null->没有值，未知->留神，不要应用NULL进行运算，后果为NULL. 字段属性Unsigned->无符号的整数->申明了该列不能申明为正数 zerofill->0填充->有余的位数，应用0来填充， int (3) , 5--005 自增->通常了解为自增，主动在上一条记录的根底上+1（默认）->通常用来设计惟一的主键~index, 必须是整数类型->能够自定义设计主键自增的起始值和步长. 非空 NULL not null->假如设置为 not null，如果不给它赋值，就会报错.->NULL, 如果不填写值，默认就是null 默认->设置默认的值.->sex, 默认值为 男， 如果不指定该列的值，则会有默认的值. 乐观锁version 伪删除（逻辑删除）is_delete 创立工夫gmt_create 批改工夫gmt_update

通常咱们保留一个实体，这个实体可能有多个属性或者特色，比方咱们在应用搜寻性能的时候，会有一些关键词或者特色，随着咱们抉择的关键词越多，后果集会越来越少，如果存储的是这个一个简略模型（失常理论构造要比这个简单很多，这里只是为了阐明需要） 元素（item）属性（attr）1a2a3a1b2b1c3c我想查问同时领有属性a b的元素冀望失去如下的后果 item12能够应用having关键字select item [table_name] where attr in (a,b) group by item having count(item) =2 如果要查问同时领有a b c 属性的元素冀望失去的后果是 item1同理sql是select item [table_name] where attr in (a,b,c) group by item having count(item) =3 如果心愿查问至多领有a b c三个属性中的两个冀望失去的后果是 item123sql如下select item [table_name] where attr in (a,b,c) group by item having count(item) >=2 注: HAVING 子句能够让咱们筛选分组后的各组数据

后面介绍了如何设计最优的库表构造、如何建设最好的索引，这些对于高性能来说是必不可少的。但这些还不够——还须要正当的设计查问。如果查问写得很蹩脚，即便库表构造再正当、索引再适合，也无奈实现高性能。 分析单条查问的性能比拟罕用的形式有： 慢查问日志EXPLAIN命令SHOW PROFILE命令慢查问起因是否申请了不须要的数据有些查问会申请超过理论须要的数据，而后这些多余的数据会被应用程序抛弃。这会给MySQL服务器带来额定的累赘，并减少网络开销，另外也会耗费应用服务器的CPU和内存资源。一些典型案例如下： 查问不须要的记录一个常见的谬误是经常会误以为MySQL会只返回须要的数据，实际上MySQL却是先返回全副后果集再进行计算。开发者先应用SELECT语句查问大量的后果，而后获取后面的N行后敞开后果集。他们认为MySQL会执行查问，并只返回他们须要的10条数据，而后进行查问。理论状况是MySQL会查问出全副的后果集，客户端的应用程序会接管全副的后果集数据，而后摈弃其中大部分数据。最简略无效的解决办法就是在这样的查问前面加上LIMIT。 总是取出全部列每次看到SELECT *的时候都须要用狐疑的眼光扫视，是不是真的须要返回全副的列？很可能不是必须的。取出全部列，会让优化器无奈实现索引笼罩扫描这类优化，还会为服务器带来额定的I/O、内存和CPU的耗费。 当然，查问返回超过须要的数据也不总是好事。很多时候这种有点节约数据库资源的形式能够简化开发，因为能进步雷同代码片段的复用性；如果应用了缓存机制，查问全部列并缓存，能够让更多的无关查问间接命中缓存，这显然是查问局部列很难做到的。 是否扫描了额定的记录在EXPLAIN语句中的type列反馈了拜访类型。拜访类型有很多种，从全表扫描到索引扫描、范畴扫描、惟一索引查问、常数援用等。这里列的这些，速度是从慢到快，扫描的行数也是从小到大。如果查问没有方法找到适合的拜访类型，那么解决的最好方法通常就是减少一个适合的索引。 如果发现查问须要扫描大量的数据但只返回多数的行，那么通常能够尝试上面的技巧去优化它： 应用索引笼罩扫描，把所有须要用的列都放到索引中，这样存储引擎毋庸回表获取对应行就能够返回后果了。扭转库表构造。例如应用独自的汇总表。重写查问语句，让MySQL优化器可能以更优化的形式执行这个查问。重构查问的形式在优化有问题的查问时，指标应该是找到一个更优的办法取得理论须要的后果——而不肯定总是须要从MySQL获取截然不同的后果集。有时候，能够将查问转换一种写法让其返回一样的后果，然而性能更好。但也能够通过批改利用代码，用另一种形式实现查问，最终达到一样的目标。 一个简单查问还是多个简略查问设计查问的时候一个须要思考的重要问题是，是否须要将一个简单的查问分成多个简略的查问。在传统实现中，总是强调须要数据库层实现尽可能多的工作，这样做的逻辑在于以前总是认为网络通信、查问解析和优化是一件代价很高的事件。 然而这样的想法对于MySQL并不实用，MySQL从设计上让连贯和断开连接都很轻量级，在返回一个小的查问后果方面很高效。古代的网络速度比以前要快很多，无论是带宽还是提早。所以运行多个小查问当初曾经不是大问题了。 有时候，将一个大查问合成为多个小查问是很有必要的。别胆怯这样做，好好掂量一下这样做是不是会缩小工作量。不过，在利用设计的时候，如果一个查问可能胜任时还写成多个独立查问是不明智的。 切分查问有时候对于一个大查问咱们须要“分而治之”，将大查问切分成小查问，每个查问性能齐全一样，只实现一小部分，每次只返回一小部分查问后果。 删除旧的数据就是一个很好的例子。定期地革除大量数据时，如果用一个大的语句一次性实现的话，则可能须要一次锁住很多数据、占满整个事务日志、耗尽系统资源、阻塞很多小的但重要的查问。将一个大的DELETE语句切分成多个较小的查问能够尽可能小地影响MySQL性能，同时还能够缩小MySQL复制的提早。 合成关联查问很多高性能的利用都会对关联查问进行合成。简略地，能够对每一个表进行一次单表查问，而后将后果在应用程序中进行关联。乍一看，这样做并没有什么益处，本来一条查问，这里却变成多条查问，返回的后果又是截然不同的。事实上，用合成关联查问的形式重构查问有如下的劣势： 让缓存的效率更高。许多应用程序能够不便地缓存单表查问对应的后果对象。另外，对MySQL的查问缓存来说，如果关联中的某个表产生了变动，那么就无奈应用查问缓存了，而拆分后，如果某个表很少扭转，那么基于该表的查问就能够反复利用查问缓存后果了。将查问合成后，执行单个查问能够缩小锁的竞争。在应用层做关联，能够更容易对数据库进行拆分，更容易做到高性能和可扩大。查问自身效率也可能会有所晋升。应用IN()代替关联查问，能够让MySQL依照ID程序进行查问，这可能比随机的关联要更高效。能够缩小冗余记录的查问。在应用层做关联查问，意味着对于某条记录利用只须要查问一次，而在数据库中做关联查问，则可能须要反复地拜访一部分数据。从这点看，这样的重构还可能会缩小网络和内存的耗费。更进一步，这样做相当于在利用中实现了哈希关联，而不是应用MySQL的嵌套循环关联。某些场景哈希关联的效率要高很多。查问执行根底当心愿MySQL可能以更高的性能运行查问时，最好的方法就是弄清楚MySQL是如何优化和执行查问的。一旦了解这一点，很多查问优化工作实际上就是遵循一些准则让优化器可能依照料想的正当的形式运行。 参照下图，咱们能够看到当向MySQL发送一个申请的时候，MySQL到底做了些什么： 客户端发送一条查问给服务器。服务器先查看查问缓存，如果命中了缓存，则立即返回存储在缓存中的后果。否则进入下一阶段。服务器端进行SQL解析、预处理，再由优化器生成对应的执行打算。MySQL依据优化器生成的执行打算，调用存储引擎的API来执行查问。将后果返回给客户端。MySQL客户端/服务器通信协议MySQL客户端和服务器之间的通信协议是“半双工”的，这意味着，在任何一个时刻，要么是由服务器向客户端发送数据，要么是由客户端向服务器发送数据，这两个动作不能同时产生。所以，咱们无奈也毋庸将一个音讯切成小块独立来发送。 这种协定让MySQL通信简略疾速，然而也从很多中央限度了MySQL。一个显著的限度是，这意味着没法进行流量管制。一旦一端开始产生音讯，另一端要接管残缺个音讯能力响应它。 查问状态对于一个MySQL连贯，或者说一个线程，任何时刻都有一个状态，该状态示意了MySQL以后正在做什么。有很多种形式能查看以后的状态，最简略的是应用SHOW FULL PROCESSLIST命令（该命令返回后果中的Command列就示意以后的状态）。在一个查问的生命周期中，状态会变动很屡次。MySQL官网手册中对这些状态值的含意有最权威的解释，上面将这些状态列出来，并做一个简略的解释。 Sleep线程正在期待客户端发送新的申请。 Query线程正在执行查问或者正在将后果发送给客户端。 Locked在MySQL服务器层，该线程正在期待表锁。在存储引擎级别实现的锁，例如InnoDB的行锁，并不会体现在线程状态中。对于MyISAM来说这是一个比拟典型的状态，但在其余没有行锁的引擎中也常常会呈现。 Analyzing and statistics线程正在收集存储引擎的统计信息，并生成查问的执行打算。 Copying to tmp table [on disk]线程正在执行查问，并且将其后果集都复制到一个长期表中，这种状态个别要么是在做GROUP BY操作，要么是文件排序操作，或者是UNION操作。如果这个状态前面还有“on disk”标记，那示意MySQL正在将一个内存长期表放到磁盘上。 Sorting result线程正在对后果集进行排序。 Sending data这示意多种状况：线程可能在多个状态之间传送数据，或者在生成后果集，或者在向客户端返回数据。 查问缓存在解析一个查问语句之前，如果查问缓存是关上的，那么MySQL会优先查看这个查问是否命中查问缓存中的数据。这个查看是通过一个对大小写敏感的哈希查找实现的。查问和缓存中的查问即便只有一个字节不同，那也不会匹配缓存后果，这种状况下查问就会进入下一阶段的解决。须要留神的是，在MySQL 8中，查问缓存曾经废除。 生成执行打算语法解析器和预处理首先，MySQL通过关键字将SQL语句进行解析，并生成一棵对应的“解析树”。MySQL解析器将应用MySQL语法规定验证和解析查问，预处理器则依据一些MySQL规定进一步查看解析树是否非法，下一步预处理器会验证权限。 查问优化器一条查问能够有很多种执行形式，最初都返回雷同的后果。优化器的作用就是找到这其中最好的执行打算。 MySQL应用基于老本的优化器，它将尝试预测一个查问应用某种执行打算时的老本，并抉择其中老本最小的一个。最后，老本的最小单位是随机读取一个4K数据页的老本，起初（老本计算公式）变得更加简单，并且引入了一些“因子”来估算某些操作的代价，如当执行一次WHERE条件比拟的老本。能够通过查问以后会话的Last_query_cost的值来得悉MySQL计算的以后查问的老本。 这个后果示意MySQL的优化器认为大略须要做1040个数据页的随机查找能力实现下面的查问。这是依据一系列的统计信息计算得来的：每个表或者索引的页面个数、索引的基数（索引中不同值的数量）、索引和数据行的长度、索引散布状况。优化器在评估老本的时候并不思考任何层面的缓存，它假如读取任何数据都须要一次磁盘I/O。 有很多种起因会导致MySQL优化器抉择谬误的执行打算，如下所示： 统计信息不精确。InnoDB因为其MVCC的架构，并不能保护一个数据表的行数的准确统计信息。执行打算中的老本估算不等同于理论执行的老本。所以即便统计信息精准，优化器给出的执行打算也可能不是最优的。例如有时候某个执行打算尽管须要读取更多的页面，然而它的老本却更小。因为如果这些页面都是程序读或者这些页面都曾经在内存中的话，那么它的拜访老本将很小。MySQL层面并不知道哪些页面在内存中、哪些在磁盘上，所以查问理论执行过程中到底须要多少次物理I/O是无奈得悉的。MySQL的最优可能和你想的最优不一样。你可能心愿执行工夫尽可能的短，然而 MySQL只是基于其老本模型抉择最优的执行打算，而有些时候这并不是最快的执行形式。MySQL从不思考其余并发执行的查问，这可能会影响到以后查问的速度。MySQL不会思考不受其管制的操作的老本，例如执行存储过程或者用户自定义函数的老本。前面咱们还会看到，优化器有时候无奈去估算所有可能的执行打算，所以它可能错过实际上最优的执行打算。MySQL的查问优化器是一个非常复杂的部件，它应用了很多优化策略来生成一个最优的执行打算。上面是一些MySQL可能解决的优化类型： 从新定义关联表的程序。将外连贯转化成内连贯。应用等价变换规定。MySQL能够应用一些等价变换来简化并标准表达式。它能够合并和缩小一些比拟，还能够移除一些恒成立和一些恒不成立的判断。优化COUNT()、MIN()和MAX()。预估并转化为常数表达式。当MySQL检测到一个表达式能够转化为常数的时候，就会始终把该表达式作为常数进行优化解决。笼罩索引扫描。子查问优化。提前终止查问。等值流传。列表IN()的比拟。在很多数据库系统中，IN()齐全等同于多个OR条件的子句，因为这两者是齐全等价的。在MySQL中这点是不成立的，MySQL将IN()列表中的数据先进行排序，而后通过二分查找的形式来确定列表中的值是否满足条件，这是一个O（log n）复杂度的操作，等价地转换成OR查问的复杂度为O（n），对于IN()列表中有大量取值的时候，MySQL的处理速度将会更快。下面列举的远不是MySQL优化器的全副，MySQL还会做大量其余的优化。“不要自认为比优化器更聪慧”，让优化器依照它的形式工作就能够了。 当然，尽管优化器曾经很智能了，然而有时候也无奈给出最优的后果。如果可能确认优化器给出的不是最佳抉择，并且分明背地的原理，那么也能够帮忙优化器做进一步的优化。例如，能够在查问中增加hint提醒，也能够重写查问，或者从新设计更优的库表构造，或者增加更适合的索引。 查问执行引擎在解析和优化阶段，MySQL将生成查问对应的执行打算，MySQL的查问执行引擎则依据这个执行打算来实现整个查问。这里执行打算是一个数据结构，而不是和很多其余的关系型数据库那样会生成对应的字节码。 返回后果给客户端查问执行的最初一个阶段是将后果返回给客户端。即便查问不须要返回后果集给客户端，MySQL依然会返回这个查问的一些信息，如该查问影响到的行数。 MySQL将后果集返回客户端是一个增量、逐渐返回的过程。例如，对于关联操作，一旦服务器解决完最初一个关联表，开始生成第一条后果时，MySQL就能够开始向客户端逐渐返回后果集了。 MySQL查问优化器的局限性关联子查问MySQL的子查问实现得十分蹩脚。最蹩脚的一类查问是WHERE条件中蕴含IN()的子查问语句，MySQL会将相干的外层表压到子查问中，它认为这样能够更高效率地查找到数据行，也即它会将IN型子查问改写成EXISTS型关联子查问。如果外层的表是一个十分大的表，那么这个查问的性能会十分蹩脚。 对于IN型子查问，咱们能够应用联接和索引来优化。还能够应用函数GROUP_CONCAT()在IN()中结构一个由逗号分隔的列表来优化，当IN()列表中的数据量比拟小的时候，性能会比联接更好。 不过，关联子查问也有适宜的场景。对于那些“反向”查问，即某些“没有”、“不存在”的问题，因为关联子查问只有匹配到内层查问就会立即进行并进行下一次的外层循环，所以往往它的效率相比其余类型的查问来说要好。 查问优化器的提醒如果对优化器抉择的执行打算不称心，能够应用优化器提供的几个提醒（hint）来管制最终的执行打算。上面将列举一些常见的提醒，并简略地给出什么时候应用该提醒。通过在查问中退出相应的提醒，就能够管制该查问的执行打算。 STRAIGHT_JOIN这个提醒能够搁置在SELECT语句的SELECT关键字之后，也能够搁置在任何两个关联表的名字之间。第一个用法是让查问中所有的表依照在语句中呈现的程序进行关联。第二个用法令是固定其前后两个表的关联程序。 当MySQL没能抉择正确的关联程序的时候，或者因为可能的程序太多导致MySQL无奈评估所有的关联程序的时候，STRAIGHT_JOIN都会很有用。在前面这种状况，MySQL可能会破费大量工夫在“statistics”状态，加上这个提醒则会大大减少优化器的搜寻空间。 SQL_SMALL_RESULT和SQL_BIG_RESULT这两个提醒只对SELECT语句无效。它们通知优化器对GROUP BY或者DISTINCT查问如何应用长期表及排序。SQL_SMALL_RESULT通知优化器后果集会很小，能够将后果集放在内存中的索引长期表，以防止排序操作。如果是SQL_BIG_RESULT，则通知优化器后果集可能会十分大，倡议应用磁盘长期表做排序操作。 USE INDEX、IGNORE INDEX和FORCE INDEX这几个提醒会通知优化器应用或者不应用哪些索引来查问记录（例如，在决定关联程序的时候应用哪个索引）。在MyQL 5.1和之后的版本能够通过新增选项FOR ORDER BY和FOR GROUP BY来指定是否对排序和分组无效。 ...

索引对于良好的性能十分要害。尤其是当表中的数据量越来越大时，索引对性能的影响愈发重要。在数据量较小且负载较低时，不失当的索引对性能的影响可能还不显著，但当数据量逐步增大时，性能则会急剧下降。 索引类型B-Tree索引当人们议论索引的时候，如果没有特地指明类型，那多半说的是B-Tree索引。不过，底层的存储引擎也可能应用不同的存储构造，InnoDB则应用的是B+Tree。B-Tree通常意味着所有的值都是按顺序存储的，并且每一个叶子页到根的间隔雷同。下图展现了B-Tree索引的形象示意，大抵反映了InnoDB索引是如何工作的。 B-Tree索引可能放慢拜访数据的速度，因为存储引擎不再须要进行全表扫描来获取须要的数据，取而代之的是从索引的根节点（图示并未画出）开始进行搜寻。根节点的槽中寄存了指向子节点的指针，存储引擎依据这些指针向上层查找。通过比拟节点页的值和要查找的值能够找到适合的指针进入上层子节点，这些指针实际上定义了子节点页中值的下限和上限。最终存储引擎要么是找到对应的值，要么该记录不存在。 叶子节点比拟特地，它们的指针指向的是被索引的数据，而不是其余的节点页。其实在根节点和叶子节点之间可能有很多层节点页，树的深度和表的大小间接相干。 B-Tree对索引列是程序组织存储的，所以很适宜查找范畴数据。例如，在一个基于文本域的索引树上，按字母程序传递间断的值进行查找是十分适合的，所以像“找出所有以I到K结尾的名字”这样的查找效率会十分高。 假如有如下数据表： CREATE TABLE people ( last_name varchar(50) not null, first_name varchar(50) not null, dob date not null, gender enum('m', 'f') not null, key(last_name, first_name, dob));对于表中的每一行数据，索引中蕴含了last_name、frst_name和dob列的值，下图显示了该索引是如何组织数据的存储的。 延长浏览：均衡二叉树、B树、B+树、B*树 了解其中一种你就都明确了MySQL中B+Tree索引原理 能够应用B-Tree索引的查问类型全值匹配全值匹配指的是和索引中的所有列进行匹配，例如后面提到的索引可用于查找姓名为Cuba Allen、出生于1960-01-01的人。 匹配最左前缀后面提到的索引可用于查找所有姓为Allen的人，即只应用索引的第一列。 匹配列前缀也能够只匹配某一列的值的结尾局部。例如后面提到的索引可用于查找所有以J结尾的姓的人。这里也只应用了索引的第一列。 匹配范畴值例如后面提到的索引可用于查找姓在Allen和Barrymore之间的人。这里也只应用了索引的第一列。 准确匹配某一列并范畴匹配另外一列后面提到的索引也可用于查找所有姓为Allen，并且名字是字母K结尾（比方Kim、Karl等）的人。即第一列last_name全匹配，第二列frst_name范畴匹配。 只拜访索引的查问B-Tree通常能够反对“只拜访索引的查问”，即查问只须要拜访索引，而无须拜访数据行。 因为索引树中的节点是有序的，所以除了按值查找之外，索引还能够用于查问中的ORDER BY操作（按程序查找）。一般来说，如果B-Tree能够依照某种形式查找到值，那么也能够依照这种形式用于排序。所以，如果ORDER BY子句满足后面列出的几种查问类型，则这个索引也能够满足对应的排序需要。 B-Tree索引的限度如果不是依照索引的最左列开始查找，则无奈应用索引例如下面例子中的索引无奈用于查找名字为Bill的人，也无奈查找某个特定生日的人，因为这两列都不是最左数据列。相似地，也无奈查找姓氏以某个字母结尾的人。 不能跳过索引中的列后面所述的索引无奈用于查找姓为Smith并且在某个特定日期出世的人。如果不指定名（first_name），则MySQL只能应用索引的第一列。 如果查问中有某个列的范畴查问，则其左边所有列都无奈应用索引优化查找例如有查问WHERElast_name='Smith' AND frst_name LIKE 'J％' AND dob='1976-12-23'，这个查问只能应用索引的前两列，因为这里LIKE是一个范畴条件（然而服务器能够把其余列用于其余目标）。如果范畴查问列值的数量无限，那么能够通过应用多个等于条件来代替范畴条件。 索引列的程序很重要：这些限度都和索引列的程序无关。在优化性能的时候，可能须要应用雷同的列但程序不同的索引来满足不同类型的查问需要。 哈希索引哈希索引（hash index）基于哈希表实现，只有准确匹配索引所有列的查问才无效。对于每一行数据，存储引擎都会对所有的索引列计算一个哈希码（hash code），哈希码是一个较小的值，并且不同键值的行计算出来的哈希码也不一样。哈希索引将所有的哈希码存储在索引中，同时在哈希表中保留指向每个数据行的指针。 在MySQL中，只有Memory引擎显式反对哈希索引。这也是Memory引擎表的默认索引类型，Memory引擎同时也反对B-Tree索引。值得一提的是，Memory引擎是反对非惟一哈希索引的，这在数据库世界外面是比拟不同凡响的。如果多个列的哈希值雷同，索引会以链表的形式寄存多个记录指针到同一个哈希条目中。 因为索引本身只需存储对应的哈希值，所以索引的构造非常紧凑，这也让哈希索引查找的速度十分快。然而，哈希索引也有它的限度： 哈希索引只蕴含哈希值和行指针，而不存储字段值，所以不能应用索引中的值来防止读取行。不过，拜访内存中的行的速度很快，所以大部分状况下这一点对性能的影响并不显著。哈希索引数据并不是依照索引值顺序存储的，所以也就无奈用于排序。哈希索引也不反对局部索引列匹配查找，因为哈希索引始终是应用索引列的全部内容来计算哈希值的。例如，在数据列（A,B）上建设哈希索引，如果查问只有数据列A，则无奈应用该索引。哈希索引只反对等值比拟查问，包含=、IN()、<=>（留神<>和<=>是不同的操作）。也不反对任何范畴查问，例如WHERE price>100。拜访哈希索引的数据十分快，除非有很多哈希抵触（不同的索引列值却有雷同的哈希值）。当呈现哈希抵触的时候，存储引擎必须遍历链表中所有的行指针，逐行进行比拟，直到找到所有符合条件的行。如果哈希抵触很多的话，一些索引保护操作的代价也会很高。例如，如果在某个选择性很低（哈希抵触很多）的列上建设哈希索引，那么当从表中删除一行时，存储引擎须要遍历对应哈希值的链表中的每一行，找到并删除对应行的援用，抵触越多，代价越大。索引的长处总结下来索引有如下三个长处： 索引大大减少了服务器须要扫描的数据量。索引能够帮忙服务器防止排序和长期表。索引能够将随机I/O变为程序I/O。索引的评级： 索引将相干的记录放到一起则取得一星；如果索引中的数据程序和查找中的排列程序统一则取得二星；如果索引中的列蕴含了查问中须要的全部列则取得三星。高性能的索引策略独立的列索引列不能是表达式的一部分，也不能是函数的参数。例如...where act_id + 1 = 5或...where to_days(current_date) - to_days(date_col) < 10。应该始终将索引列独自放在比拟符号的一侧。 ...

最近老友线上一个不太重要的数据库被本人误删了,于是找到小猪本猪我复原数据,早已把"教训大于所有"思维贯彻全身的小猪必定是不会放过这次机会滴,滴,滴,滴,滴. 开始干燥的复原环节复原计划抉择老友平时备份都是手动备份,这样子如同也只能抉择旧备份数据+binlog来复原了. 爱护现场敞开服务器,禁止数据持续写入因为我要应用的是binlog办法复原,所以要在数据库执行一段 flush logs示意开启新的一段binlog本地数据库版本老友服务器上的mysql版本是5.6我本地5.7重新安装数据库太麻烦了,docker装置也麻烦.而后开始找有5.6版本的一键环境... PhpStudy没WampServer太粉(通过截图看如同也没有5.6)APMServ没phpenv有....找啊找啊终于找到一个说的清清楚楚反对mysql5.6一键环境,而后就是下载安装巴拉巴拉的5.6环境搭建好了. 本地mysql版本开启binlog能够看到我本地未开启binlog, no:开启 off:未开启 关上my.ini# mysqld配置下减少以下内容# binlog文件前缀,配置好这个就示意开启了binlog-bin = mysql-bin或者log_bin=ONlog_bin_basename=/var/lib/mysql/mysql-binlog_bin_index=/var/lib/mysql/mysql-bin.index### 以下配置看你须要,不过只复原数据的话上面不必管# 前缀log_bin_basename# 设置此参数是指定二进制索引文件的门路与名称log_bin_index# 此参数示意只记录指定数据库的二进制日志# 这个参数的应用办法有点坑.不是通过,分隔的哦具体百度一下binlog_do_db# 此参数示意不记录指定的数据库的二进制日志.不是通过,分隔的哦具体百度一下binlog_ignore_db# 此参数示意binlog应用的内存最大的尺寸max_binlog_cache_size# 此参数示意binlog应用的内存大小，能够通过状态变量binlog_cache_use和binlog_cache_disk_use来帮忙测试。binlog_cache_size# 应用二进制日志缓存的事务数量binlog_cache_use# 应用二进制日志缓存但超过binlog_cache_disk_use# 值并应用临时文件来保留事务中的语句的事务数量binlog_cache_size# 最大值，最大和默认值是1GB，该设置并不能严格控制Binlog的大小，尤其是Binlog比拟凑近最大值而又遇到一个比拟大事务时，为了保障事务的完整性，不可能做切换日志的动作，只能将该事务的所有SQL都记录进以后日志，直到事务完结max_binlog_sizeBinlog应用mysqlbinlog.exe复原#目录切换到mysql/bin上面# 执行.\mysqlbinlog.exe --database test(要复原的数据库) -s ../data/mysql-bin.000707 > sqls-x\000707-all.txt# 以上命令的意思是# 提取mysql-bin.000707文件中的test数据库的语句(只显示日志中蕴含的语句，不显示其它信息。)mysqlbinlog.exe其余指令中文翻译 复原了几个文件之后发现太大啦！！！于是想着先复原几个较为重要的表数据,发现mysql提供的工具并不反对复原到某个表或语句,而后各种搜索引擎发现了几个开源我的项目binlog2sql、mysqlbinlog_flashback 应用binlog2sql复原binlog2sql这二款工具里就它star最多,毫无疑问就是它了. 装置# 克隆我的项目git clone https://github.com/danfengcao/binlog2sql.git && cd binlog2sql# 装置依赖pip install -r requirements.txt环境装置和mysql配置装置python2.7,3.4+ python的装置教程网上有十分多批改本地mysql配置server_id = 1# 这个的值不肯定非要一样log_bin = /var/log/mysql/mysql-bin.logmax_binlog_size = 1Gbinlog_format = rowbinlog_row_image = full 设置mysql权限GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'root'@'127.0.0.1'; 应用# 切换到我的项目目录1. cd 我的项目目录/binlog2sql/2. 执行命令 python binlog2sql.py -h127.0.0.1 -P3306 -uroot -proot -dtest -t wp_userinfo wp_balance --sql-type INSERT DELETE --start-file=mysql-bin.000715 --stop-file=mysql-bin.000726 > C:\phpEnv\server\mysql\mysql-5.6\bin\sqls-x\all.sql3. 期待执行结束即可4. 将这些语句导入到数据库就ok啦-h127.0.0.1(数据库链接)-P3306(数据库端口)-uroot(数据库账号)-proot(数据库明码)-dtest(要复原的数据库)-t wp_userinfo wp_balance(导出的指定表)--sql-type INSERT DELETE(要导出的指定语句)\--start-file=mysql-bin.000715 --stop-file=mysql-bin.000726(开始binlog到完结binlog)C:\phpEnv\server\mysql\mysql-5.6\bin\sqls-x\all.sql(将打印内容输入大指定文件)成绩 ...

从对数据操作的粒度分 ： 1） 表锁：操作时，会锁定整个表。 2） 行锁：操作时，会锁定以后操作行。 从对数据操作的类型分： 1） 读锁（共享锁）：针对同一份数据，多个读操作能够同时进行而不会相互影响。 2） 写锁（排它锁）：以后操作没有实现之前，它会阻断其余写锁和读锁。 表级 锁更适宜于以查问为主，只有大量按索引条件更新数据的利用，如Web 利用；而行级锁则更适宜于有大量按索引 条件并发更新大量不同数据，同时又有并查问的利用，如一些在线事务处理（OLTP）零碎。 1） 对MyISAM 表的读操作，不会阻塞其余用户对同一表的读申请，但会阻塞对同一表的写申请； 2） 对MyISAM 表的写操作，则会阻塞其余用户对同一表的读和写操作； 简而言之，就是读锁会阻塞写，然而不会阻塞读。而写锁，则既会阻塞读，又会阻塞写。 此外，MyISAM 的读写锁调度是写优先，这也是MyISAM不适宜做写为主的表的存储引擎的起因。因为写锁后，其余线程不能做任何操作，大量的更新会使查问很难失去锁，从而造成永远阻塞。 行锁介绍 行锁特点 ：偏差InnoDB 存储引擎，开销大，加锁慢；会呈现死锁；锁定粒度最小，产生锁抵触的概率最低,并发度 也最高。 InnoDB 与 MyISAM 的最大不同有两点：一是反对事务；二是 采纳了行级锁。 InnoDB 实现了以下两种类型的行锁。 共享锁（S）：又称为读锁，简称S锁，共享锁就是多个事务对于同一数据能够共享一把锁，都能拜访到数 据，然而只能读不能批改。 排他锁（X）：又称为写锁，简称X锁，排他锁就是不能与其余锁并存，如一个事务获取了一个数据行的排他 锁，其余事务就不能再获取该行的其余锁，包含共享锁和排他锁，然而获取排他锁的事务是能够对数据就行 读取和批改。 对于UPDATE、DELETE和INSERT语句，InnoDB会主动给波及数据集加排他锁（X)； 对于一般SELECT语句，InnoDB不会加任何锁； 如果不通过索引条件检索数据，那么InnoDB将对表中的所有记录加锁，实际效果跟表锁一样。 优化倡议： 尽可能让所有数据检索都能通过索引来实现，防止无索引行锁降级为表锁。 正当设计索引，尽量放大锁的范畴 尽可能减少索引条件，及索引范畴，防止间隙锁 尽量管制事务大小，缩小锁定资源量和工夫长度 尽可应用低级别事务隔离（然而须要业务层面满足需要） mysql执行程序 FROM ON JOIN WHERE GROUP BY HAVING SELECT DISTINCT ORDER BY LIMIT

前言： 久闻 ClickHouse 小名，始终没有去具体理解。近期看了下 ClickHouse 相干文档，决定装置体验下。想理解 ClickHouse 的小伙伴能够一起跟着学习哦。本篇文章次要介绍 ClickHouse 装置办法及基础知识。 1. ClickHouse 简介ClickHouse 是一个用于联机剖析 (OLAP) 的列式数据库管理系统 (DBMS). 由俄罗斯搜索引擎巨头 Yandex 开源. 次要用于数据分析畛域, 目前国内社区炽热, 各个大厂纷纷跟进大规模用于 OLAP 畛域。 一起来看下 ClickHouse 官网怎么介绍它的一些个性: 疾速：ClickHouse会充分利用所有可用的硬件，以尽可能快地解决每个查问。单个查问的峰值解决性能超过每秒 2 TB（解压缩后，仅应用的列）。在分布式设置中，读取是在衰弱正本之间主动均衡的，以防止减少提早。容错：ClickHouse反对多主机异步复制，并且能够跨多个数据中心进行部署。所有节点都相等，这能够避免出现单点故障。单个节点或整个数据中心的停机工夫不会影响零碎的读写可用性。可伸缩：ClickHouse能够在垂直和程度方向上很好地缩放。 ClickHouse易于调整以在具备数百或数千个节点的群集上或在单个服务器上，甚至在小型虚拟机上执行。以后，每个单节点装置的数据量超过数万亿行或数百兆兆字节。易用：ClickHouse简略易用，开箱即用。它简化了所有数据处理：将所有结构化数据排汇到零碎中，并且立刻可用于构建报告。 SQL容许表白冀望的后果，而无需波及某些DBMS中能够找到的任何自定义非标准API。2. ClickHouse 装置教程ClickHouse 能够在任何具备 x86_64 ，AArch64 或 PowerPC64LE CPU 架构的 Linux ，FreeBSD 或 Mac OS X 上运行。貌似不能在 Windows 零碎下装置，不过 ClickHouse 同样反对 Docker 部署，Windows 零碎能够在 Docker 下装置 ClickHouse 。 依据官网文档举荐：Debian 或 Ubuntu 零碎能够应用官网预编译的 deb 软件包来装置，CentOS 、RedHat 等Linux发行版能够应用官网预编译的 rpm 包 来装置，如果您的操作系统不反对装置 deb 或 rpm 包，也能够应用 tgz 软件包或间接源码编译装置。上面咱们以 CentOS 零碎为例，以 rpm 形式来装置下 ClickHouse。 ...

明天来聊一下多PROCESS同时更新一条数据记录时解决形式。 咱们先来给明天的问题拆成两个子问题： 1. 只有一台主数据库时多个解决（PROCESS）更新同一条记录。2. 多主架构时不同的节点上的多个解决（PROCESS）更新同一条记录。先说第一个问题，这个其实是一个常见的问题，解决办法也是基本相同的，就是给记录加锁，先拿到锁的解决先执行，实现后开释锁，后边的解决再拿锁。 然而具体的处理过程就很有考究了，因为“锁”分为“乐观锁”和“乐观锁”。 什么是“乐观锁”（Pessimistic Lock）呢？ 当要对数据库中的一条数据进行批改的时候，为了防止同时被其他人批改，最好的方法就是间接对该数据进行加锁以避免并发。 这种借助数据库锁机制，在批改数据之前先锁定，再批改的形式被称之为乐观并发管制【Pessimistic Concurrency Control，缩写“PCC”，又名“乐观锁”】。 乐观锁，正如其名，具备强烈的独占和排他个性。它指的是对数据被外界(包含本零碎以后的其余事务，以及来自内部零碎的事务处理)批改持激进态度。 因而，在整个数据处理过程中，将数据处于锁定状态。乐观锁的实现，往往依附数据库提供的锁机制。 之所以叫做乐观锁，是因为这是一种对数据的批改持有乐观态度的并发管制形式。总是假如最坏的状况，每次读取数据的时候都默认其余线程会更改数据，因而须要进行加锁操作，当其余线程想要拜访数据时，都须要阻塞挂起。 那什么又是“乐观锁”（Optimistic Locking）呢？ 乐观锁是绝对乐观锁而言的，乐观锁假如数据个别状况下不会造成抵触，所以在数据进行提交更新的时候，才会正式对数据的抵触与否进行检测，如果发现抵触了，则返回给用户谬误的信息，让用户决定如何去做。乐观锁实用于读操作多的场景，这样能够进步程序的吞吐量。 乐观锁机制采取了更加宽松的加锁机制。乐观锁是绝对乐观锁而言，也是为了防止数据库幻读、业务解决工夫过长等起因引起数据处理谬误的一种机制，但乐观锁不会刻意应用数据库自身的锁机制，而是根据数据自身来保证数据的正确性。 从下面的阐明咱们能够明确了，乐观并发管制实际上是“先取锁再拜访”的激进策略，为数据处理的平安提供了保障。然而在效率方面，解决加锁的机制会让数据库产生额定的开销，还有减少产生死锁的机会。另外还会升高并行性，一个事务如果锁定了某行数据，其余事务就必须期待该事务处理完才能够解决那行数据。而乐观并发管制置信事务之间的数据竞争(data race)的概率是比拟小的，因而尽可能间接做上来，直到提交的时候才去锁定，所以不会产生任何锁和死锁。 在明确了下面针对一台主数据库时多个解决（PROCESS）更新同一条记录的解决形式之后，咱们把问题再向深推动一下。 当一个零碎的并发解决进一步提高，一台主数据库不足以满足要求的时候，就须要对数据库进行横向拓展了。 上面咱们用例子阐明一下解决这个问题的几个方向。 1. 数据库实例和存储离开，多个实例共用一个存储。2. 数据库实例和存储不离开，每个数据库实例写本人的存储，而后进行实例间同步。在第一个方向上做的最胜利的就是ORACLE数据库的RAC架构。 ORACLE数据库的RAC架构引入了“内存交融”（Cache Fusion）的概念，简略来说就是在多个数据库实例之间搭建一个高速局域网，用几个特定的PROCESS同步各自的SGA。当然具体的实现形式要简单得多，能够专门写几篇文章来详述了。 第二个方向上实现的比拟好的有两个产品：ORACLE GoldenGate 和 Mysql的双主架构。 先说ORACLE GoldenGate。 GoldenGate最开始并不是ORACLE的产品，而是一个1995年成立在美国旧金山的专门开发计算机容错零碎的公司，名字也是来源于旧金山驰名的金门大桥。GoldenGate公司于2009年9 月被Oracle收买， 纳入交融中间件（ Fusion Middleware ）产品线中，作为ORALCE数据库（或其余数据库）的容灾、复制的解决方案。 下面是从网上找来的介绍GoldenGate的yizhang简略的图片，大家能够先看一下，当前有机会的话咱们再写一篇文章来专门聊一下。 而后咱们来说一下Mysql的双主架构。 MySQL最早来源于MySQL AB公司前身的ISAM与mSQL我的项目， 2008年1月，MySQL AB公司被Sun公司以10亿美金收买。 2009年4月，Oracle公司以74亿美元收买Sun公司，自此MySQL数据库进入Oracle时代。MySQL最胜利的中央是SQL实现层和存储引擎离开以及Binlog。 SQL实现层和存储引擎离开的设计使得Mysql能够兼容各种其余公司开发的存储引擎，能够满足各种场景的不同须要。 而Binlog以及传递和复制机制则能够使Mysql设计出各种各样的高可用架构。 下面就是一个最简略的Mysql主从架构。通过这个图片咱们能够理解Binlog是如何工作的。 当初咱们下面的主从地位颠倒过去再做一遍，即两ge数据库互为主从，就实现了最简略的双主架构。 当然下面的双主架构在自增主键和批改同一记录的更新上还须要一些Application和数据库设计上的反对。具体如何实现我也不是这方面的专家，大家能够多上网学习一下，呵呵。 本文援用了日常更新针对锁的阐明和图片，特此感激！https://www.jianshu.com/p/d2ac26ca6525

我的项目介绍本零碎应用Struts2+Spring+Hibernate架构，数据库应用MySQL,连接池应用c3p0。宽泛用于驾校治理，蕴含学员治理、车辆管理、教练员工治理、用车治理、考试治理、问题缴费治理等性能，除了管理员能管制批改这些信息以外，教练也可对其下学员的约车信息和考试治理信息进行增删改查。我的项目适用人群正在做毕设的学生，或者须要我的项目实战练习的Java学习者 开发环境jdk 8intellij ideatomcat 8.5.40mysql 5.7所用技术Struts2+Spring+Hibernatejs+ajaxjsp我的项目架构 我的项目截图登录 学员列表 教练列表 新增缴费信息 教练后盾-考试治理 教练后盾-约车治理 数据库配置<bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean"> <property name="hibernateProperties"> <props> <prop key="hibernate.dialect">org.hibernate.dialect.MySQLDialect</prop> <prop key="hibernate.show_sql">false</prop> <prop key="hibernate.format_sql">false</prop> <prop key="hibernate.connection.provider_class">com.jolbox.bonecp.provider.BoneCPConnectionProvider</prop> <prop key="hibernate.connection.driver_class">com.mysql.jdbc.Driver</prop> <prop key="hibernate.connection.url"> <![CDATA[jdbc:mysql://localhost:3306/driverschool?useUnicode=true&characterEncoding=utf8]]></prop> <prop key="hibernate.connection.username">root</prop> <prop key="hibernate.connection.password">root123</prop> <prop key="bonecp.partitionCount">1</prop> <prop key="bonecp.maxConnectionsPerPartition">10</prop> <prop key="bonecp.minConnectionsPerPartition">5</prop> <prop key="bonecp.acquireIncrement">1</prop><!-- #每次新增连贯的数量 --> <prop key="bonecp.connectionTimeout">3000</prop><!-- #连贯超时工夫阀值，获取连贯时，超出阀值工夫，则获取失败，毫秒为单位 --> <prop key="bonecp.poolAvailabilityThreshold">20</prop><!-- #连接池阀值，当 可用连贯/最大连贯 < 连贯阀值 时，创立新的连贯 --> <prop key="bonecp.idleConnectionTestPeriod">30</prop><!-- 测试连贯有效性的间隔时间，单位分钟 --> <prop key="bonecp.idleMaxAge">240</prop><!-- 连贯的闲暇存活工夫，当连贯闲暇工夫大于该阀值时，革除该连贯 --> <prop key="bonecp.statementsCacheSize">5</prop><!-- 语句缓存个数 --> <prop key="hibernate.query.factory_class">org.hibernate.hql.classic.ClassicQueryTranslatorFactory</prop> <prop key="hibernate.connection.release_mode">auto</prop> <prop key="hibernate.autoReconnect">true</prop> <prop key="hibernate.connection.autocommit">true</prop> <prop key="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</prop> <prop key="hibernate.cache.use_query_cache">true</prop> <prop key="hibernate.cache.use_second_level_cache">true</prop> </props> </property> <property name="mappingResources"> <list> <value>com/driverSchool/entity/Bookcar.hbm.xml</value> <value>com/driverSchool/entity/Car.hbm.xml</value> <value>com/driverSchool/entity/Pay.hbm.xml</value> <value>com/driverSchool/entity/Student.hbm.xml</value> <value>com/driverSchool/entity/Test.hbm.xml</value> <value>com/driverSchool/entity/User.hbm.xml</value> </list> </property></bean>struts.xml 配置<struts> <constant name="struts.i18n.encoding" value="UTF-8" /> <constant name="struts.locale" value="zh_CN" /> <constant name="struts.objectFactory" value="spring" /> <package name="default" extends="struts-default"> <interceptors> <!-- 平安信息过滤，用户session为空则强制退出 --> <interceptor name="sessionCheck" class="com.driverSchool.util.SessionCheck"> <!-- 不须要拦挡的办法 --> <param name="excludeMethods"> login </param> </interceptor> <!-- 拦截器栈，蕴含SESSION拦挡和默认拦截器 --> <interceptor-stack name="authInterceptor1"> <interceptor-ref name="sessionCheck" /> <interceptor-ref name="defaultStack" /> </interceptor-stack> </interceptors> <default-interceptor-ref name="authInterceptor1"></default-interceptor-ref> <!-- 留神global-results必须在global-exception-mappings后面 --> <global-results> <result name="reLogin">/login.jsp</result> <result name="to_index">/index.jsp</result> </global-results> <global-exception-mappings> <!-- 此处定义的result对应于下面的global-results内 捕捉所有异样 --> <exception-mapping result="error" exception="java.lang.Exception"> </exception-mapping> <exception-mapping result="errorSql" exception="java.sql.SQLException"> </exception-mapping> </global-exception-mappings> <action name="userAction_*" class="userAction" method="{1}"> <result name="to_info">/info.jsp</result> <result name="to_user_list">/user_list.jsp</result> <result name="to_addOrEditUser">/user_addAndEdit.jsp</result> <result name="to_user_listAction" type="redirectAction">userAction_findUserAll</result> </action> <action name="bookcarAction_*" class="bookcarAction" method="{1}"> <result name="to_bookcar_list">/bookcar_list.jsp</result> <result name="to_addOrEditBookcar">/bookcar_addAndEdit.jsp</result> <result name="to_bookcar_listAction" type="redirectAction">bookcarAction_findBookcarAll</result> </action> <action name="carAction_*" class="carAction" method="{1}"> <result name="to_car_list">/car_list.jsp</result> <result name="to_addOrEditCar">/car_addAndEdit.jsp</result> <result name="to_car_listAction" type="redirectAction">carAction_findCarAll</result> </action> <action name="payAction_*" class="payAction" method="{1}"> <result name="to_pay_list">/pay_list.jsp</result> <result name="to_addOrEditPay">/pay_addAndEdit.jsp</result> <result name="to_pay_listAction" type="redirectAction">payAction_findPayAll</result> </action> <action name="studentAction_*" class="studentAction" method="{1}"> <result name="to_student_list">/student_list.jsp</result> <result name="to_addOrEditStudent">/student_addAndEdit.jsp</result> <result name="to_student_listAction" type="redirectAction">studentAction_findStudentAll</result> </action> <action name="testAction_*" class="testAction" method="{1}"> <result name="to_test_list">/test_list.jsp</result> <result name="to_addOrEditTest">/test_addAndEdit.jsp</result> <result name="to_test_listAction" type="redirectAction">testAction_findTestAll</result> </action> </package></struts> applicationContext.xml<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd"> <import resource="datebase.xml" /> <bean id="userDao" class="com.driverSchool.dao.UserDao"> <property name="ht" ref="hibernatetemplate"></property> </bean> <bean id="userService" class="com.driverSchool.service.impl.UserServiceImpl"> <property name="dao" ref="userDao"></property> </bean> <bean id="userAction" class="com.driverSchool.action.UserAction"> <property name="biz" ref="userService"></property> </bean> <bean id="bookcarDao" class="com.driverSchool.dao.BookcarDao"> <property name="ht" ref="hibernatetemplate"></property> </bean> <bean id="bookcarService" class="com.driverSchool.service.impl.BookcarServiceImpl"> <property name="dao" ref="bookcarDao"></property> </bean> <bean id="bookcarAction" class="com.driverSchool.action.BookcarAction"> <property name="biz" ref="bookcarService"></property> <property name="sbiz" ref="studentService"></property> <property name="cbiz" ref="carService"></property> </bean> <bean id="carDao" class="com.driverSchool.dao.CarDao"> <property name="ht" ref="hibernatetemplate"></property> </bean> <bean id="carService" class="com.driverSchool.service.impl.CarServiceImpl"> <property name="dao" ref="carDao"></property> </bean> <bean id="carAction" class="com.driverSchool.action.CarAction"> <property name="biz" ref="carService"></property> </bean> <bean id="payDao" class="com.driverSchool.dao.PayDao"> <property name="ht" ref="hibernatetemplate"></property> </bean> <bean id="payService" class="com.driverSchool.service.impl.PayServiceImpl"> <property name="dao" ref="payDao"></property> </bean> <bean id="payAction" class="com.driverSchool.action.PayAction"> <property name="biz" ref="payService"></property> <property name="sbiz" ref="studentService"></property> </bean> <bean id="studentDao" class="com.driverSchool.dao.StudentDao"> <property name="ht" ref="hibernatetemplate"></property> </bean> <bean id="studentService" class="com.driverSchool.service.impl.StudentServiceImpl"> <property name="dao" ref="studentDao"></property> </bean> <bean id="studentAction" class="com.driverSchool.action.StudentAction"> <property name="biz" ref="studentService"></property> </bean> <bean id="testDao" class="com.driverSchool.dao.TestDao"> <property name="ht" ref="hibernatetemplate"></property> </bean> <bean id="testService" class="com.driverSchool.service.impl.TestServiceImpl"> <property name="dao" ref="testDao"></property> </bean> <bean id="testAction" class="com.driverSchool.action.TestAction"> <property name="biz" ref="testService"></property> <property name="sbiz" ref="studentService"></property> </bean></beans>登录//controllerpublic String login() { User user = biz.findUserByUsernameAndPwd(username, pwd); if (user == null) { ActionContext.getContext().put("msg", "该用户不存在，请从新登录！"); return "reLogin"; } else { ActionContext.getContext().getSession().put("user", user); ActionContext.getContext().getSession().put("uname", username); ActionContext.getContext().getSession().put("uid", user.getId()); ActionContext.getContext().getSession().put("role", user.getRole()); ActionContext.getContext().put("msg", ""); return "to_index"; }}//jsp<div class="container"> <div class="line bouncein"> <div class="xs6 xm4 xs3-move xm4-move"> <div style="height:150px;"></div> <div class="media media-y margin-big-bottom"></div> <form action="<%=basePath%>userAction_login.action" method="post"> <div class="panel loginbox"> <div class="text-center margin-big padding-big-top"> <h1>驾校信息管理平台</h1> </div> <div class="panel-body" style="padding:30px; padding-bottom:10px; padding-top:10px;"> <div class="form-group"> <div class="field field-icon-right"> <input type="text" class="input input-big" name="username" placeholder="登录账号" data-validate="required:请填写账号" /> <span class="icon icon-user margin-small"></span> </div> </div> <div class="form-group"> <div class="field field-icon-right"> <input type="password" class="input input-big" name="pwd" placeholder="登录明码" data-validate="required:请填写明码" /> <span class="icon icon-key margin-small"></span> </div> </div> </div> <div style="padding:30px;"> <input type="submit" class="button button-block bg-main text-big input-big" value="登录"> </div> </div> </form> </div> </div></div>程序有问题分割程序帮 ...

前言很多人喜爱应用JPA的快捷开发，集体喜爱mybatis能够本人写sql。而mybaits plus能够很好的联合两者的有点，有根底的CRUD接口，还能够自定义mapper写sql,比拟灵便。get it ! 筹备工作既然要引入mybatis plus，那么久须要引入数据库相干依赖，还有一些工具包。这边还应用了lombok缩小代码量，这个看状况引入，毕竟不便是不便，侵入性强一些，须要装置插件。而后结尾先弄个mybatis plus代码生成器,毕竟本人手动建文件还是很累的。。。 引入maven依赖残缺的的pom.xml <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!--mysql驱动--> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.22</version> </dependency> <!--druid数据源--> <dependency> <groupId>com.alibaba</groupId> <artifactId>druid-spring-boot-starter</artifactId> <version>1.2.4</version> </dependency> <!-- mybatis-plus 相干--> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.4.1</version> </dependency> <!-- 代码生成器 --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-generator</artifactId> <version>3.4.1</version> </dependency> <!-- 模板引擎 --> <dependency> <groupId>org.apache.velocity</groupId> <artifactId>velocity-engine-core</artifactId> <version>2.2</version> </dependency> <!-- mybatis-plus 完结--> <!--以下是工具包--> <dependency> <groupId>cn.hutool</groupId> <artifactId>hutool-all</artifactId> <version>5.5.7</version> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>fastjson</artifactId> <version>1.2.75</version> </dependency> <!-- lombok --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.18.12</version> <scope>provided</scope> </dependency></dependencies>新建user表CREATE TABLE `user` ( `id` varchar(32) NOT NULL, `username` varchar(32) NOT NULL COMMENT '用户名', `password` varchar(64) NOT NULL COMMENT '明码', `sex` char(1) DEFAULT NULL COMMENT '性别 0 女| 1 男', `locked` char(1) DEFAULT NULL COMMENT '是否锁住 0 否 | 1 是', `create_time` datetime DEFAULT NULL COMMENT '创立工夫', `create_by` varchar(32) DEFAULT NULL COMMENT '创建者', `update_time` datetime DEFAULT NULL COMMENT '更新工夫', `update_by` varchar(32) DEFAULT NULL COMMENT '更新者', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;配置代码生成器新建一个CodeGenerator.java ...

作者：宓祥康爱可生交付服务部团队 DBA 善于日志剖析、问题排查等；次要负责解决 MySQL 与我司自研数据库自动化治理平台 DMP 的日常运维问题，对数据库及周边技术有浓重的学习趣味。本文起源：原创投稿 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。引言什么是 Slow Query Log？该如何应用它？它的存在对运维数据库有什么帮忙呢？一、 简介慢查问日志，开启它咱们能够通过参数来管制其记录执行或查问工夫长的 SQL、全表扫描的 SQL、没有应用索引的 SQL。没错，它的作用就是记录哪些蹩脚的、让数据库变慢的 SQL，把它们揪出来。 咱们个别通过如下参数来管制 slow 的开启与记录：slow_query_log、slow_query_log_file、long_query_time、min_examined_row_limit、log_output、log_queries_not_using_indexes、log_throttle_queries_not_using_indexes。 slow_query_log：管制 slow_query_log 是否开启，参数 ON|OFFslow_query_log_file：管制文件的写入地位，参数为文件的具体位置，如：/data/slow.loglong_query_time：设置 SQL 执行工夫大于等于多少秒（可准确到微秒）时记录到日志中min_examined_row_limit：设置查看的行数大于等于多少行时记录到日志中log_output：设置慢查问记录到哪里，参数 FILE|TABLElog_queries_not_using_indexes：管制查问过程中未应用索引或全表扫描的 SQL 是否记录到日志中log_throttle_queries_not_using_indexes：开启 log_queries_not_using_indexes 后，此参数会限度每分钟能够写入慢速查问日志的此类查问的数量，参数设置 0 为不限度二、查看形式与内容分析慢日志剖析的形式有两种，因为慢日志文件个别较小，所以一种形式为在慢日志文件中间接应用 less 或 more 命令来查看。第二种形式则是利用 MySQL 官网提供给咱们的程序：mysqldumpslow 来疾速查看 slowlog 日志中记录的慢 SQL。 对于咱们具体来剖析 SQL 的话，个别采纳第一种形式，查找到对应工夫点的对应 SQL 来进行剖析。 show master status;# Time: 2020-11-16T08:27:16.777259+08:00# User@Host: root[root] @ [127.0.0.1] Id: 248# Query_time: 15.293745 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0SET timestamp=1605486436;那么如何读懂慢日志外面对这些信息呢？ show master status #慢 SQLTime #呈现该慢 SQL 的工夫query_time # SQL 语句的查问工夫(在 MySQL 中所有类型的 SQL 语句执行的工夫都叫做 query_time,而在 Oracle 中则仅指 select)lock_time: #锁的工夫rows_sent: #返回了多少行,如果做了聚合就不精确了rows_examined: #执行这条 SQL 解决了多少行数据SET timestamp #工夫戳通过这些咱们就能够来明确的晓得一条 SQL 到底执行了多长时间的查问，有没有产生锁期待，此查问理论在数据库中读取了多少行数据了。 ...

最近写作生涯遭逢了滑铁卢，写了两篇文章浏览量都不怎么样，但还是要持续分享所学，服务端的菜鸡不能输，要从新称霸中原，233333当然这是很难的，后端优良作者切实太多了，还得持续加油。回归主题，最近又在重新学习MySQL，想起了阿里开发手册禁用select * 查问语句，这是为什么呢引言阿里巴巴开发手册中指出： 【强制】在表查问中，一律不要应用 * 作为查问的字段列表，须要哪些字段必须明确写明 阐明： 减少查问分析器解析老本增减字段容易与 resultMap 配置不统一无用字段减少网络 耗费，尤其是 text 类型的字段文章将从这几个方面开展阐明 减少查问分析器解析老本首先介绍一下MySQL根本架构，根本构造如下图： MySQL 根本架构能够分为 Server 层和存储引擎层两局部。Server 层包含连接器、查问缓存、分析器、优化器、执行器等。存储引擎层负责数据的存储和提取，其架构模式是插件式的，反对 InnoDB、MyISAM、Memory 等多个存储引擎 当咱们执行一条查问语句：select * from t where id = 1，在MySQL中执行过程如下： 在真正执行select * from t where id = 1时首先须要输出命令mysql -uroot -p，通过连接器将客户端和服务层建设起连贯建设起连贯当前输出select * from t where id = 1这条SQL首先查找查问缓存中是否曾经执行过该条语句若未命中查问缓存，则执行select * from t where id = 1这条SQL，分析器会对这条SQL进行词法剖析。MySQL 从输出的select这个关键字辨认进去这是一个查问语句。把字符串t辨认成表名t，把字符串id辨认成列id判断输出的这个 SQL 语句是否满足 MySQL 语法如果应用select 来查问语句，分析器须要对进行额定的解析，如果间接指定成列名，则不须要进行额定的解析，间接辨认成列名 失去MySQL优化器“笼罩索引”策略优化的可能性假如有一条sql语句为select * from t where name = "何甜甜"，其中id为主键，name为索引，而实际上这么写的目标只是想查问指定name的id 在innodb存储引擎中，索引能够分为非主键索引和主键索引，主键索引和主键的区别在于叶子节点存放数据的不同。主键索引中叶子节点寄存的是整行数据，而非主键索引中叶子节点寄存的是主键的值。当初咱们来看select * from t where name = "何甜甜"这条语句是如何执行的 ...

查看时区：show variables like '%time_zone%'; 设置全局：set global time_zone='+8:00'; 设置以后会话：set time_zone='+8:00'; 立刻失效：flush privileges; 查看操作系统时区：timedatectl

上面是将 MySQL 的某个字段增加自增属性的命令。 alter table table_name modify id int auto_increment

良好的逻辑设计和物理设计是高性能的基石，应该依据零碎将要执行的查问语句来设计schema，这往往须要衡量各种因素。例如，反范式的设计能够放慢某些类型的查问，但同时可能使另一些类型的查问变慢。比方增加计数表和汇总表是一种很好的优化查问的形式，但这些表的保护老本可能会很高。MySQL独有的个性和实现细节对性能的影响也很大。 抉择优化的数据类型MySQL反对的数据类型十分多，抉择正确的数据类型对于取得高性能至关重要。不论存储哪种类型的数据，上面几个简略的准则都有助于做出更好的抉择。 更小的通常更好个别状况下，应该尽量应用能够正确存储数据的最小数据类型。更小的数据类型通常更快，因为它们占用更少的磁盘、内存和CPU缓存，并且解决时须要的CPU周期也更少。 简略就好简略数据类型的操作通常须要更少的CPU周期。例如，整型比字符操作代价更低，因为字符集和校对规定（排序规定）使字符比拟比整型比拟更简单。这里有两个例子：一个是应该应用MySQL内建的类型而不是字符串来存储日期和工夫，另外一个是应该用整型存储IP地址。 尽量避免NULL如果查问中蕴含可为NULL的列，对MySQL来说更难优化，不应用NULL的理由有： 所有应用NULL值的状况，都能够通过一个有意义的值的示意，这样有利于代码的可读性和可维护性，并能从束缚上加强业务数据的规范性。NULL值到非NULL的更新无奈做到原地更新，更容易产生索引决裂，从而影响性能。(null -> not null性能晋升很小，除非确定它带来了问题，否则不要当成优先的优化措施)NULL值在timestamp类型下容易出问题，特地是没有启用参数explicit_defaults_for_timestamp。NOT IN、!= 等负向条件查问在有 NULL 值的状况下返回永远为空后果，查问容易出错。NULL会使索引、索引统计和值比拟都更加简单，并且在MyISIM中须要额定一个字节的存储空间。在为列抉择数据类型时，第一步须要确定适合的大类型：数字、字符串、工夫等，下一步是抉择具体类型。很多MySQL的数据类型能够存储雷同类型的数据，只是存储的长度和范畴不一样、容许的精度不同，或者须要的物理空间（磁盘和内存空间）不同。雷同大类型的不同子类型数据有时也有一些非凡的行为和属性。 整数类型如果存储整数，能够应用这几种整数类型：TINYINT，SMALLINT，MEDIUMINT，INT，BIGINT。别离应用8，16，24，32，64位存储空间。它们能够存储的值的范畴从−2（N−1）到2（N−1）−1，其中N是存储空间的位数。 整数类型有可选的UNSIGNED属性，示意不容许负值，这大抵能够使负数的下限进步一倍。例如TINYINT UNSIGNED能够存储的范畴是0～255，而TINYINT的存储范畴是−128～127。有符号和无符号类型应用雷同的存储空间，并具备雷同的性能，因而能够依据理论状况抉择适合的类型。 注：IP地址实际上是32位无符号整数，应该用INT存储，MySQL提供INETATON和INETNTOA两个转换IP地址的函数。 实数类型实数是带有小数局部的数字。然而，它们不只是为了存储小数局部，也能够应用DECIMAL存储比BIGINT还大的整数。MySQL既反对准确类型，也反对不准确类型。FLOAT和DOUBLE类型反对应用规范的浮点运算进行近似计算，如果须要晓得浮点运算是怎么计算的，则须要研究所应用的平台的浮点数的具体实现。DECIMAL类型用于存储准确的小数，在MySQL 5.0和更高版本，DECIMAL类型反对准确计算。 浮点和DECIMAL类型都能够指定精度。对于DECIMAL列，能够指定小数点前后所容许的最大位数，这会影响列的空间耗费，MySQL 5.0和更高版本将数字打包保留到一个二进制字符串中（每4个字节存9个数字）。例如，DECIMAL（18,9）小数点两边将各存储9个数字，一共应用9个字节：小数点前的数字用4个字节，小数点后的数字用4个字节，小数点自身占1个字节。 浮点类型在存储同样范畴的值时，通常比DECIMAL应用更少的空间。FLOAT应用4个字节存储。DOUBLE占用8个字节，相比FLOAT有更高的精度和更大的范畴。 因为须要额定的空间和计算开销，所以应该尽量只在对小数进行准确计算时才应用DECIMAL——例如存储财务数据。但在数据量比拟大的时候，能够思考应用BIGINT代替DECIMAL，将须要存储的货币单位依据小数的位数乘以相应的倍数即可，这样能够同时防止浮点存储计算不准确和DECIMAL准确计算代价高的问题。 字符串类型VARCHAR和CHAR类型因为当初基本上所有的MySQL数据库应用的都是InnoDB存储引擎，而且应用的字符集都是utf8或者utf8mb4这样的多字节字符集。在这种状况下，varchar和char类型都须要应用1~2个额定字节去存储字符串的长度，此时char相比varchar曾经不具备任何的劣势，所以举荐所有的字符串类型都应用varchar。 BLOB和TEXT类型BLOB和TEXT都是为存储很大的数据而设计的字符串数据类型，别离采纳二进制和字符形式存储。 MySQL对BLOB和TEXT列进行排序与其余类型是不同的：它只对每个列的最前max_sort_length字节而不是整个字符串做排序。如果只须要排序后面一小部分字符，则能够减小max_sort_length的配置，或者应用ORDER BY SUSTRING（column，length）。 MySQL不能将BLOB和TEXT列全副长度的字符串进行索引，也不能应用这些索引打消排序。同时因为Memory引擎不反对BLOB和TEXT类型，所以，如果查问应用了BLOB或TEXT列并且须要应用隐式长期表，将不得不应用磁盘长期表。 最好的解决方案是尽量避免应用BLOB和TEXT类型。如果切实无奈防止，有一个技巧是在所有用到BLOB字段的中央都应用SUBSTRING（column，length）将列值转换为字符串（在ORDER BY子句中也实用），这样就能够应用内存长期表了。然而要确保截取的子字符串足够短，不会使长期表的大小超过max_heap_table_size或tmp_table_size，超过当前MySQL会将内存长期表转换为MyISAM磁盘长期表。 日期和工夫类型DATETIME类型能保留1001年到9999年范畴的值，精度为秒，与时区无关，应用8个字节的存储空间。TIMESTAAMP类型保留了格林尼治规范工夫以来的秒数，只能示意1970年到2038年范畴的值，显示的值依赖时区，应用4个字节的存储空间。 通常应该尽量应用TIMESTAMP，因为它比DATETIME空间效率更高。 注：MySQL5.6.4版本开始反对比秒更小的存储粒度，格局为 工夫类型（如timestamp）（n），n最大为6。 标识列数据类型抉择整数通常是标识列最好的抉择，因为它们很快并且能够应用AUTO_INCREMENT。 如果可能，应该防止应用字符串类型作为标识列，例如MD5()、SHA1()或者UUID()产生的字符串。因为它们很耗费空间，并且通常比数字类型慢。这些函数生成的新值会任意散布在很大的空间内，这会导致INSERT以及一些SELECT语句变得很慢： 因为插入值会随机地写到索引的不同地位，所以使得INSERT语句更慢。这会导致页决裂、磁盘随机拜访，以及对于聚簇存储引擎产生聚簇索引碎片。SELECT语句会变得更慢，因为逻辑上相邻的行会散布在磁盘和内存的不同中央。随机值导致缓存对所有类型的查问语句成果都很差，因为会使得缓存赖以工作的拜访局部性原理生效。如果整个数据集都一样的“热”，那么缓存任何一部分特定数据到内存都没有益处；如果工作集比内存大，缓存将会有很多刷新和不命中。不好的Schema设计实际过多的列MySQL的存储引擎API工作时须要在服务器层和存储引擎层之间通过行缓冲格局拷贝数据，而后在服务器层将缓冲内容解码成各个列。从行缓冲中将编码过的列转换成行数据结构的操作代价是十分高的，转换的代价依赖于列的数量。 过多的关联如果查问中存在过多的关联，那么解析和优化查问的代价会成为MySQL的问题。一个粗略的教训法令，如果心愿查问执行得疾速且并发性好，单个查问最好在12个表以内做关联。 适度应用ENUM如果列的值可能会在当前裁减，那么就应该防止应用ENUM类型。在MySQL 5.1和更新版本中，如果不是在列表的开端增加值会须要ALTER TABLE，对于大表来说会导致重大的性能问题。 范式和反范式范式的长处： 范式化的更新操作通常比反范式化要快。当数据较好地范式化时，就只有很少或者没有反复数据，所以只须要批改更少的数据。范式化的表通常更小，能够更好地放在内存里，所以执行操作会更快。很少有多余的数据意味着检索列表数据时更少须要DISTINCT或者GROUP BY语句。范式的毛病： 通常须要关联。范式化可能将列寄存在不同的表中，这样会使某些索引生效。混用范式化和反范式化范式化和反范式化的schema各有优劣，怎么抉择最佳的设计？事实是，在理论利用中常常须要混用，可能应用局部范式化的schema、缓存表，以及其余技巧。最常见的反范式化数据的办法是复制或者缓存，在不同的表中存储雷同的特定列。 在某些须要特定的查问条件和排序的状况下，能够在父表中冗余一些字段到子表。例如有user表和message表，要查问付费用户最近10条数据，齐全范式化查问的效率较低下，能够在message表中冗余账户类型的字段并建设好索引，这将十分高效。不过更新账户类型的时候须要更新两张表。这时须要思考更新的频率及时长，来和查问的频率作比拟，而后做出取舍。 缓存衍生值也是有用的。如果须要显示每个用户发了多少音讯（像很多论坛做的），能够每次执行一个低廉的子查问来计算并显示它，也能够在user表中建一个num_messages列，每当用户发新音讯时更新这个值。 延长浏览：对关系型数据库五个范式的了解如何了解关系型数据库的常见设计范式？ 缓存表和汇总表有时晋升性能最好的办法是在同一张表中保留衍生的冗余数据。然而，有时也须要创立一张齐全独立的汇总表或缓存表（特地是为满足检索的需要时）。如果能答应大量的脏数据，这是十分好的办法，然而有时的确没有抉择的余地（例如，须要防止简单、低廉的实时更新操作）。 术语“缓存表”和“汇总表”没有规范的含意。咱们用术语“缓存表”来示意存储那些能够比较简单地从schema其余表获取（然而每次获取的速度比较慢）数据的表（例如，逻辑上冗余的数据）。而术语“汇总表”时，则保留的是应用GROUP BY语句聚合数据的表（例如，数据不是逻辑上冗余的）。也有人应用术语“累积表（Roll-Up Table）”称说这些表。因为这些数据被“累积”了。 以网站为例，假如须要计算之前24小时内发送的音讯数。在一个很忙碌的网站不可能保护一个实时准确的计数器。作为代替计划，能够每小时生成一张汇总表。这样兴许一条简略的查问就能够做到，并且比实时保护计数器要高效得多。毛病是计数器并不是100％准确。 如果必须取得过来24小时精确的音讯发送数量（没有脱漏），有另外一种抉择。以每小时汇总表为根底，把前23个残缺的小时的统计表中的计数全副加起来，最初再加上开始阶段和完结阶段不残缺的小时内的计数。 当然，更好的办法是应用内存数据库来实现这个计数器，例如Redis。

1.查看sql的执行频率         MySQL 客户端连贯胜利后，通过 show [session|global] status 命令能够提供服务器状态信息。show [session|global] status 能够依据须要加上参数“session”或者“global”来显示 session 级（以后连贯）的计后果和 global 级（自数据库上次启动至今）的统计后果。如果不写，默认应用参数是“session”。 2.定位效率底下的sql 能够通过以下两种形式定位执行效率较低的 SQL 语句。 慢查问日志 : 通过慢查问日志定位那些执行效率较低的 SQL 语句，用--log-slow-queries[=file_name]选项启 动时，mysqld 写一个蕴含所有执行工夫超过 long_query_time 秒的 SQL 语句的日志文件。具体能够查看本 书第 26 章中日志治理的相干局部。 show processlist : 慢查问日志在查问完结当前才纪录，所以在利用反映执行效率呈现问题的时候查问慢查问 日志并不能定位问题，能够应用show processlist命令查看以后MySQL在进行的线程，包含线程的状态、是否 锁表等，能够实时地查看 SQL 的执行状况，同时对一些锁表操作进行优化。 3.explain剖析执行打算 type 显示的是拜访类型，是较为重要的一个指标，可取值为： 一般来说， 咱们须要保障查问至多达到 range 级别， 最好达到ref 。 Mysql从5.0.37版本开始减少了对 show profiles 和 show profile 语句的反对。show profiles 可能在做SQL优化时 帮忙咱们理解工夫都消耗到哪里去了。 4.索引的应用 如果索引了多列，要恪守最左前缀法令。指的是查问从索引的最左前列开始，并且不跳过索引中的列。 匹配最左前缀法令，走索引。 不要在索引列上进行运算操作， 索引将生效。  ...

欢送微信关注「SH的全栈笔记」0. 主从复制首先主从复制是什么？简略来说是让一台MySQL服务器去复制另一台MySQL的数据，使两个服务器的数据保持一致。 这种形式与Redis的主从复制的思路没有太大的出入。如果你对Redis的主从复制感兴趣能够去看看《Redis的主从复制》。那既然Redis和MySQL都采纳了复制这种形式，主从复制所带来的意义是什么呢？ 通过复制性能，构建一个或者多个从库，能够进步数据库的高可用性、可扩展性，同时实现负载平衡。当主库产生故障时，能够疾速的切到其某一个从库，并将该从库晋升为主库，因为数据都一样，所以不会影响零碎的运行；当MySQL服务器须要扛住更多的读申请时，能够把读申请的流量分流到各个从库下来，写申请则转发给主库，造成读写拆散的架构，来提供更好的读扩大和申请的负载平衡。 读写拆散的架构利用的其实十分宽泛，就比方MySQL，还有Redis，以及咱们相熟的Zookeeper，Zookeeper的Follower收到读申请不会本人解决，而是会将读申请转发给Leader，感兴趣的能够本人下来理解一下，这里就不偏题了。 1. 复制原理MySQL的主从复制反对两种形式： 基于行基于语句基于语句的复制在MySQL3.23中就曾经有了，而基于语句的形式则在5.1中才实现。其本质都是基于主库的binlog来实现的，主库记录binlog，而后从库将binlog在本人的服务器上重放，从而保障了主、从的数据一致性。 1.1 binlogMySQL中日志分为两个维度，一个是MySQL服务器的，一个是底层存储引擎的。而上文提到的binlog就是属于MySQL服务器的日志，binlog也叫二进制日志，记录了所有对MySQL所做的更改。 基于行、语句的复制形式跟binlog的存储形式有关系。 binlog有三种存储格局，别离是Statement、Row和Mixed。 Statement 基于语句，只记录对数据做了批改的SQL语句，可能无效的缩小binlog的数据量，进步读取、基于binlog重放的性能Row 只记录被批改的行，所以Row记录的binlog日志量一般来说会比Statement格局要多。基于Row的binlog日志十分残缺、清晰，记录了所有数据的变动，然而毛病是可能会十分多，例如一条update语句，有可能是所有的数据都有批改；再例如alter table之类的，批改了某个字段，同样的每条记录都有改变。Mixed Statement和Row的联合，怎么个结合法呢。例如像update或者alter table之类的语句批改，采纳Statement格局。其余的对数据的批改例如update和delete采纳Row格局进行记录。为什么会有这么多形式呢？因为Statement只会记录SQL语句，然而并不能保障所有状况下这些语句在从库上可能正确的被重放进去。因为可能程序不对。 MySQL什么时候会记录binlog呢？是在事务提交的时候，并不是依照语句的执行程序来记录，当记录完binlog之后，就会告诉底层的存储引擎提交事务，所以有可能因为语句程序谬误导致语句出错。 1.2 查看binlog这里拿MySQL 5.6举例子，binlog默认是处于敞开状态的。咱们能够通过命令show variables like '%log_bin%' 来查看对于binlog的配置。 log_bin代表是否开启了binlog，其默认值为OFF。 log_bin 代表是否开启了binlog，其默认值为OFFlog_bin_basename binlog存储文件的残缺名称，会在默认的文件名前面增加上递增的序号，就例如mysql-bin.000001log_bin_index binlog索引文件名称，例如mysql-bin.indexsql_log_bin 在binlog开启的时候，能够禁用以后session的binlog你能够在MySQL中通过命令show binary logs查看所有的binlog文件 晓得了有哪些文件之后咱们能够来看看binlog文件中的内容，能够在MySQL通过show binlog events命令来查看。 show binglog events 查看第一个binlog文件，咱们也能够通过in参数来指定，假如咱们想看的文件名是mysql-bin.000001，那么能够应用命令show binlog events in 'mysql-bin.000001'来查看指定的binlog文件 接下来咱们来看看咱们在MySQL中的操作所对应的binlog内容别离是什么。 初始化咱们下面提到过，binlog是由一个一个的event组成的。从MySQL 5.0开始，binlog的第一个event都为Format_desc，位于图中的Event_type那一列。能够看到内容为Server ver;5.6.50-log, Binlog ver: 4，阐明以后应用的MySQL版本为5.6.50，Binlog的版本是V4。 创立数据库而后我创立了一个名为student的DB，其Event_type是Query，这个event的内容为CREATE DATABASE student DEFAULT CHARACTER SET = utf8mb4，一个建库语句。 新建表而后我创立了一个名为student的表，Event_type也是Query，内容为use student; CREATE TABLE student (id INT(11) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT)，一个建表语句。 ...

当咱们的利用降级时往往会随同着数据库表构造的降级，此时就须要迁徙数据库的表构造。个别咱们会应用工具或者脚本来实现，手动操作毕竟有肯定危险，要是能在利用启动时主动降级数据库表构造就好了！Flyway正是这么一款工具，通过Flyway和SpringBoot联合应用，在利用启动时就能够主动降级数据库表构造，十分不便，举荐给大家！SpringBoot实战电商我的项目mall（40k+star）地址：https://github.com/macrozheng/mall Flyway简介Flyway是一款数据库迁徙工具，它让数据库迁徙变得更加简略。它能像Git一样对数据库进行版本控制，反对命令行工具、Maven插件、第三方工具（比方SpringBoot）等多种应用形式。 Flyway具备如下特点： 简略：应用和学习简略，通过不同版本的SQL脚本实现数据库迁徙。业余：专一于数据库迁徙性能，你无需放心有任何问题。功能强大：反对多种数据库，领有大量的第三方工具，反对CI/DI。相干概念工作原理应用Flyway时咱们须要编写好数据库迁徙的SQL脚本，比方 V1__Initial_Setup.sql中初始化了三种表，V2__First_Changes.sql中又新增了两种表。Flyway会创立flyway_schema_history表，用于存储这些SQL脚本的执行状况，从而对数据库进行版本控制。当咱们应用Flyway进行数据库迁徙时，Flyway会依据flyway_schema_history表中的记录，自行决定须要执行哪些SQL脚本，从而实现数据库迁徙。 脚本命名标准在创立Flyway的SQL脚本时，有些命名标准须要恪守，这些命名标准决定了Flyway执行脚本的程序和形式，能够先参考上面的示意图。 为了能被Flyway正确执行，SQL迁徙脚本须要遵循如下标准： Prefix（前缀）：V示意有版本号的数据库迁徙，U示意一些数据库版本的回滚，R示意可反复执行的数据库迁徙；Version（版本号）：Flyway会依照版本号的大小程序来执行数据库迁徙脚本；Separator（分隔符）：命名时应用双下划线分隔符；Description（形容）：用于形容该迁徙脚本的具体操作阐明；Suffix（后缀）：示意.sql文件。相干命令migrate：数据库迁徙命令，会依据设置好的SQL脚本间接将数据库表降级至最新版本。clean：删除数据库中所有的表，千万别在生产环境上应用。info：打印所有对于数据库迁徙的详细信息和状态信息。validate：验证数据库迁徙是否可用。undo：对数据库迁徙进行回滚操作。baseline：以现有数据库为基准，创立flyway_schema_history表，大于基准版本的数据库迁徙才会被利用。repair：修复flyway_schema_history表。命令行工具应用Flyway实现数据迁徙有多种形式，咱们先通过命令行工具的办法来体验下Flyway的应用。首先须要下载Flyway的命令行工具，下载社区版即可，下载地址：https://flywaydb.org/download 下载实现后进行解压，解压实现后目录构造如下； 批改Flyway的配置文件/conf/flyway.conf，批改下数据库配置即可；flyway.url=jdbc:mysql://localhost:3306/flyway?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai flyway.user=rootflyway.password=root在/sql目录下增加SQL执行脚本，这里增加创立ums_admin表的执行脚本V1.0.1__Create_ums_admin_table.sql；CREATE TABLE `ums_admin`( `id` bigint(20) NOT NULL AUTO_INCREMENT, `username` varchar(64) DEFAULT NULL, `password` varchar(64) DEFAULT NULL, `icon` varchar(500) DEFAULT NULL COMMENT '头像', `email` varchar(100) DEFAULT NULL COMMENT '邮箱', `nick_name` varchar(200) DEFAULT NULL COMMENT '昵称', `note` varchar(500) DEFAULT NULL COMMENT '备注信息', `create_time` datetime DEFAULT NULL COMMENT '创立工夫', `login_time` datetime DEFAULT NULL COMMENT '最初登录工夫', `status` int(1) DEFAULT '1' COMMENT '帐号启用状态：0->禁用；1->启用', PRIMARY KEY (`id`)) ENGINE = InnoDB AUTO_INCREMENT = 8 DEFAULT CHARSET = utf8 COMMENT ='后盾用户表';应用flyway migrate命令进行数据迁徙，此时咱们会发现须要先应用flyway baseline命令创立保留迁徙记录的表flyway_schema_history才行； ...

优化慢SQL技巧 浏览大略3分钟 [toc] 前言不再须要放心数据库性能优化的日子曾经一去不复返了。 随着时代的倒退，每个新企业家都心愿建设下一个Facebook，并联合收集每个可能的数据点以提供更好的机器学习预测的心态，作为开发人员，咱们须要比以往更好地筹备咱们的API，以提供牢靠，高效的端点，应该可能毫不费力地浏览大量数据。 如果您曾经进行了一段时间的后端或数据库体系结构，则可能曾经实现了分页查问，如下所示： 然而，如果你的确建设了这样的分页，很遗憾地说，这样做是错的。 你不以为然？没关系。Slack、Shopify 和 Mixmax 这些公司都在用咱们明天将要探讨的形式进行分页。 我想你很难找出一个不应用 OFFSET 和 LIMIT 进行数据库分页的人。对于简略的小型应用程序和数据量不是很大的场景，这种形式还是可能“应酬”的。 如果你想从头开始构建一个牢靠且高效的零碎，在一开始就要把它做好。 明天咱们将探讨曾经被宽泛应用的分页形式存在的问题，以及如何实现高性能分页。 1. OFFSET和LIMIT有什么问题正如咱们在上几段中简要探讨的那样，OFFSET和LIMIT十分实用于数据使用量很少的我的项目。 然而，当数据库里的数据量超过服务器内存可能存储的能力，并且须要对所有数据进行分页，问题就会呈现。 为了实现分页，每次收到分页申请时，数据库都须要进行低效的全表扫描。 全表扫描 什么是全表扫描？全表扫描（也称为程序扫描）是在数据库中进行的扫描，其中程序读取表中的每一行，而后查看遇到的列是否符合条件。因为从磁盘进行大量的 I/O 读取（包含屡次搜查）以及低廉的磁盘到内存传输，这种类型的扫描被认为是最慢的。这意味着，如果你有 1 亿个用户，OFFSET 是 5 千万，那么它须要获取所有这些记录 (包含那么多基本不须要的数据)，将它们放入内存，而后获取 LIMIT 指定的 20 条后果。 也就是说，为了获取一页的数据： 10万行中的第5万行到第5万零20行须要先获取 5 万行。这么做是如许低效？ 如果你不置信，能够看看这个例子： https://www.db-fiddle.com/f/3... 在左侧面板中，您有一个根本架构，该架构将为咱们的测试插入100.000行，而在右侧，则是有问题的查问和咱们的解决方案。只需单击顶部的“运行”，而后比拟每个执行工夫。第一个查问：1秒；（问题查问）至多须要30秒钟的工夫能力运行。 数据越多，状况就越糟。看看我对 10 万行数据进行的 PoC。 https://github.com/IvoPereira... 当初你应该晓得这背地都产生了什么：OFFSET 越高，查问工夫就越长。 2. 有什么解决方案这是你应该应用的： 这是基于游标的分页。 你应该存储最初收到的主键（通常是一个ID）和LIMIT，而不是在本地存储以后的OFFSET和LIMIT并随每个申请传递它，因而查问最终可能与此相似。 为什么？因为通过显式传递最新的读取行，你能够依据无效的索引键通知数据库确切从哪里开始搜寻，而不用思考该范畴之外的任何行。 以上面的比拟为例： 针对咱们的优化版本： 接管到的记录完全相同，然而第一个查问破费了12.80秒，第二个查问破费了0.01秒。你能领会到差别吗？ 要应用这种基于游标的分页，须要有一个惟一的序列字段 (或多个)，比方惟一的整数 ID 或工夫戳，然而在某些特定状况下，这可能不合乎咱们的需要。 我的倡议是始终思考每种表体系结构的优缺点以及在每种表体系结构中须要执行哪种查问。 如果您须要在查问中解决大量相干数据，Rick James 的文章提供了更深刻的领导。http://mysql.rjweb.org/doc.ph... ...

InnoDB存储引擎是Mysql的默认存储引擎。InnoDB存储引擎提供了具备提交、回滚、解体恢复能力的事务平安。然而比照MyISAM的存储引擎，InnoDB写的解决效率差一些，并且会占用更多的磁盘空间以保留数据和索引。InnoDB存储引擎不同于其余存储引擎的特点 ：反对事务和外键束缚MySQL反对外键的存储引擎只有InnoDB ，在创立外键的时候，要求父表必须有对应的索引，子表在创立外键的时候，也会主动的创立对应的索引。InnoDB 存储表和索引有以下两种形式 ：①. 应用共享表空间存储， 这种形式创立的表的表构造保留在.frm文件中， 数据和索引保留在innodb_data_home_dir 和 innodb_data_file_path定义的表空间中，能够是多个文件。②. 应用多表空间存储， 这种形式创立的表的表构造依然存在 .frm 文件中，然而每个表的数据和索引独自保留在.ibd 中。MyISAM 不反对事务、也不反对外键，其劣势是拜访的速度快，对事务的完整性没有要求或者以SELECT、INSERT为主的利用基本上都能够应用这个引擎来创立表 。每个MyISAM在磁盘上存储成3个文件，其文件名都和表名雷同，但拓展名别离是 ：.frm (存储表定义)；.MYD(MYData , 存储数据)；.MYI(MYIndex , 存储索引)； 存储引擎的抉择InnoDB : 是Mysql的默认存储引擎，用于事务处理应用程序，反对外键。如果利用对事务的完整性有比拟高的要求，在并发条件下要求数据的一致性，数据操作除了插入和查问意外，还蕴含很多的更新、删除操作，那么InnoDB存储引擎是比拟适合的抉择。InnoDB存储引擎除了无效的升高因为删除和更新导致的锁定， 还能够确保事务的残缺提交和回滚，对于相似于计费零碎或者财务零碎等对数据准确性要求比拟高的零碎，InnoDB是最合适的抉择。MyISAM ： 如果利用是以读操作和插入操作为主，只有很少的更新和删除操作，并且对事务的完整性、并发性要求不是很高，那么抉择这个存储引擎是十分适合的。MEMORY：将所有数据保留在RAM中，在须要疾速定位记录和其余相似数据环境下，能够提供几块的拜访。MEMORY的缺点就是对表的大小有限度，太大的表无奈缓存在内存中，其次是要确保表的数据能够复原，数据库异样终止后表中的数据是能够复原的。MEMORY表通常用于更新不太频繁的小表，用以疾速失去拜访后果。MERGE：用于将一系列等同的MyISAM表以逻辑形式组合在一起，并作为一个对象援用他们。MERGE表的长处在于能够冲破对单个MyISAM表的大小限度，并且通过将不同的表散布在多个磁盘上，能够无效的改善MERGE表的拜访效率。这对于存储诸如数据仓储等VLDB环境非常适合。

Python中MySQL用法一、注意事项查看零碎版本： arch命令，查看零碎是64位还是32位应用cat /etc/system-release查看内核版本留神装置MySQL的版本 企业版：付费社区版：收费MariaDB留神装置之后防止yum自动更新版本留神数据库的安全性二、字符集设置及mysql命令(一)、字符集设置字符集分类： ASCII：占用一个字节LATIN：对ASCII做了扩大GBK：占用一个或两个字节，windows默认的字符集utf8：占用3个字节，像emoje等占用四个字节的数据无奈存储UTF-8：占用四个字节，在mysql中写法位utf8mb4查看字符集：show variables like ‘%character%’;mysql> show variables like '%character%';+--------------------------+----------------------------+| Variable_name | Value |+--------------------------+----------------------------+| character_set_client | utf8mb4 || character_set_connection | utf8mb4 || character_set_database | utf8mb4 || character_set_filesystem | binary || character_set_results | utf8mb4 || character_set_server | utf8mb4 || character_set_system | utf8 || character_sets_dir | /usr/share/mysql/charsets/ |+--------------------------+----------------------------+查看校对规定：show variables like ‘collation_%’;mysql> show variables like 'collation_%';+----------------------+--------------------+| Variable_name | Value |+----------------------+--------------------+| collation_connection | utf8mb4_0900_ai_ci || collation_database | utf8mb4_0900_ai_ci || collation_server | utf8mb4_0900_ai_ci |+----------------------+--------------------+3 rows in set (0.01 sec)_ci示意大小写不敏感，_cs示意大小写敏感配置文件批改mysql字符集 ...

mysql导入数据库失败#1046 - No database selected这种状况个别是因为你在数据库中没有这个数据库，你新建一个你要导入的数据库名字的数据库，而后选中该数据库，再进行导入基本上就能够了!

背景上周公司培训了MySQL replication, 这个周末打算用所学来实际操作一下。 Master server：MySQL container mysql_master on NAS NAS server IP: 192.168.1.108mysql_master inner ip: 172.17.0.6Slave server: MySQK container mysql_slave on Mac mini Mac mini docker host IP: 192.168.1.139mysql_slave inner ip: 172.17.0.2筹备MySQL container筹备mysql_master1 创立两个目录用来寄存MySQL文件 mkdir -p /mnt/md1/disk4/mysqlmkdir -p /mnt/md1/disk4/mysql-files2 创立用于测试的master mysql node [root@TNAS-2664 disk4]# docker run -d -p 3307:3306 -e MYSQL_ROOT_PASSWORD=123456 --name mysql_master -v /mnt/md1/disk4/mysql:/var/lib/mysql -v /mnt/md1/disk4/mysql-files:/var/lib/mysql-files mysql3bebf0e21df6d9034ce8275b14ebb1616e11f5e2678b1e084d03c087ed91a72a3 查看以后NAS上运行的mysql的container ID [root@TNAS-2664 ~]# docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES40db0be51460 mysql "docker-entrypoint..." 44 seconds ago Up 29 seconds 33060/tcp, 0.0.0.0:3307->3306/tcp mysql_masterdb5f6a287a21 mautic/mautic "/entrypoint.sh ap..." 2 weeks ago Up 11 days 0.0.0.0:8082->80/tcp mauticdc1eac509c70 qianliu/mediawikiwithcomposer "docker-php-entryp..." 2 weeks ago Up 11 days 0.0.0.0:8086->80/tcp sarawikib5c0a00f5f42 mysql "docker-entrypoint..." 2 weeks ago Up 11 days 0.0.0.0:3306->3306/tcp, 33060/tcp mysql2911c0a8987ba qianliu/mediawikiwithcomposer "docker-php-entryp..." 2 weeks ago Up 11 days 0.0.0.0:8083->80/tcp qianliuwiki4 应用docker cp命令将my.cnf复制到host机器上进行更改docker cp 40db0be51460:/etc/mysql/my.cnf . ...

两年前在我的项目上施行oracle etl同步时，客户就提出cdc（Change Data Capture）增量同步的需要，并且明确要求基于日志来捕捉数据变动。过后对于这方面的常识储备不够，只感觉这样的需要太刻薄。到了起初我施行分布式架构的计划越来越多，常常会思考如何保障数据的一致性，也让我回过头来，从新思考当年客户的需要。 本文的配角是canal，罕用来保障mysql到redis、elasticsearch等产品数据的增量同步。下文先讲canal的装置配置，再联合具体的代码，实现mysql到redis的实时同步。 1. 简介1.1. 背景分布式架构近些年很受推崇，咱们的零碎开发不再局限于一台mysql数据库，能够为了缓存而引入redis，为了搜寻而引入elasticsearch，等等，这些是分布式架构给咱们带来的便利性。 但带来的挑战也加大了，比方：微服务治理、分布式事务，明天还会讲到数据同步。以前对于关系型数据库的数据同步，曾经诞生了不少 ETL工具，比方咱们相熟的 oracle ODI。然而以当初微服务开发而论，还是不够灵便，咱们须要能够自在的将mysql数据同步到redis、elasticsearch等中央。这里就能够用到本文的配角 -- canal。 1.2. canalcanal [k'næl]，译意为水道/管道/沟渠，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和生产。晚期阿里巴巴因为杭州和美国双机房部署，存在跨机房同步的业务需要，实现形式次要是基于业务 trigger 获取增量变更。从 2010 年开始，业务逐渐尝试数据库日志解析获取增量变更进行同步，由此衍生出了大量的数据库增量订阅和生产业务。 基于日志增量订阅和生产的业务包含： 数据库镜像数据库实时备份索引构建和实时保护(拆分异构索引、倒排索引等)业务 cache 刷新带业务逻辑的增量数据处理以后的 canal 反对源端 mysql 版本包含 5.1.x , 5.5.x , 5.6.x , 5.7.x , 8.0.x 。 1.3. 工作原理MySQL主备复制原理MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件binary log events，能够通过 show binlog events 进行查看) MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log) MySQL slave 重放 relay log 中事件，将数据变更反映它本人的数据 ...

前言： 年底了，你的数据库是不是该巡检了？个别巡检都会关怀明码平安问题，比方明码复杂度设置，是否有定期批改等。特地是进行等保评测时，评测机构会要求具备明码安全策略。其实 MySQL 零碎自身能够设置明码复杂度及主动过期策略的，可能比拟少用，大多数同学并未具体去理解。本篇文章咱们一起来学习下如何设置数据库账号密码复杂度及主动过期策略。 1.明码复杂度策略设置MySQL 零碎自带有 validate_password 插件，此插件能够验证明码强度，未达到规定强度的明码则不容许被设置。MySQL 5.7 及 8.0 版本默认状况下貌似都不启用该插件，这也使得咱们能够随便设置明码，比方设置为 123、123456等。如果咱们想从本源上标准明码强度，能够启用该插件，上面一起来看下如何通过此插件来设置明码复杂度策略。 1）查看是否已装置此插件 进入 MySQL 命令行，通过 show plugins 或者查看 validate_password 相干参数能够判断是否已装置此插件。若没有相干参数则代表未装置此插件 # 装置前查看 为空则阐明未装置此插件mysql> show variables like 'validate%';Empty set (0.00 sec)2）装置 validate_password 插件 # 通过 INSTALL PLUGIN 命令可装置此插件# 每个平台的文件名后缀都不同 对于 Unix 和类 Unix 零碎，为.so，对于 Windows 为.dllmysql> INSTALL PLUGIN validate_password SONAME 'validate_password.so';Query OK, 0 rows affected, 1 warning (0.28 sec)# 查看 validate_password 相干参数mysql> show variables like 'validate%';+--------------------------------------+--------+| Variable_name | Value |+--------------------------------------+--------+| validate_password_check_user_name | ON || validate_password_dictionary_file | || validate_password_length | 8 || validate_password_mixed_case_count | 1 || validate_password_number_count | 1 || validate_password_policy | MEDIUM || validate_password_special_char_count | 1 |+--------------------------------------+--------+7 rows in set (0.00 sec)3）明码强度相干参数解释 ...

建设有实用意义的网站,必然须要有很多服务器,比方如网站服务器、数据库服务器,如果是服务器集群,那么就会波及到更多服务器。如何治理好这些服务器,关系到各种网站的稳固运行,这对建立公司、单位的形象,保障电子商务业务的稳固,以及媒体新闻的精确及时都有很重要的意义。为了确保这些网站的稳固运行,势必须要做好对网站服务器的监控。做好对服务器运行的各类异样、服务的运行状态进行及时的监控预警工作,能够帮忙网站管理员及时修复一些服务器潜在异样状态,及时处理和修复服务器问题。　IIS7网站监控能够及时防控网站危险，疾速精确监控网站是否受到各种劫持攻打，网站在全国是否能失常关上（查看域名是否被墙），精准的DNS净化检测，具备网站关上速度检测性能，第一工夫晓得网站是否被黑、被入侵、被改题目、被挂黑链。精益求精的产品，缺点为零数据提供！ 它能够做到以下性能：1、检测网站是否被黑2、检测网站是否被劫持3、检测域名是否被墙4、检测DNS是否被净化5、网站实在的齐全关上工夫（独家） 6、领有独立监控后盾，24小时定时监控域名官网图：官网地址：IIS7网站监控 以后市场上曾经有不少服务器监督的软件,然而这类软件或多或少都有不足之处。一般来说,这类软件都只对系统的特定畛域的运行状况进行监控,一款软件监控CPU运行状态,另外一款软件监控内存或者硬盘的运行状况。网络管理员为了监控好一台服务器的运行状况往往须要装置各种不同的软件,这些软件对系统配置都有不同要求,间或多或少还会存在一些抵触。另外,当网络管理员须要监控不止一台服务器时,如何有对立的中央让管理员监控所有服务器,不须要管理员登录到不同服务器下来查看各个服务器的运行状态,也将会给管理员带来极大的不便,然而这样的软件基本上找不到。　建设这样一款为服务器管理员量身定制的网站监控软件。微软.Net的WMI(WindowsManagementInstrumentation)为服务器前各类服务的监控提了十分糨大的性能;基于SOA的架构形式,使得网站管理员可能有可能在一个中央来监控所有治理的服务器;.Net的反射机制,使得依据理论状况,灵便地定制监控性能成为可能。　论文的钻研将基于Microsoft.Net技术,探讨实现多服务器的网络监控软件,文中会引入目前.Net以及Web利用中风行的、先进的概念,为网站的服务器保护人员提供便捷的服务器监控零碎。

摘要本文依据 2020 年 DTCC 数据库大会分享内容整顿而成。工商银行在 2014 年就开始推广应用 MySQL。时至今日，生产环境的 MySQL 节点数量曾经倒退到近万个；利用场景也从外围低等级利用，推广到外围高等级利用。此次与大家分享，为承接外围业务数据存储的重任，工商银行在 MySQL 利用治理方面的思路和计划演讲者介绍：林镇熙，工商银行小兵一枚，2014 年开始接触 MySQL，将 MySQL 5.5、5.7 版本引入工行。负责 MySQL 架构设计，开发标准，以及相干技术培训工作。 工商银行在外围利用 MySQL 的治理，次要分为三个方面：目前面临的状况和挑战、为了解决这些问题的思路和具体的计划，最初是后续晋升的思路。  一、 现状与挑战1.1、现状这是行内 MySQL 的部署节点数倒退状况，从 2019 年 6 月开始到当初，在短短的两年期间，MySQL 节点规模上涨得十分厉害，翻了几番。绿色局部是目前这些节点当中的外围利用节点数的状况。外围利用占的比例其实是比拟大的，有两个方面的因素：一方面是行内在数据库应用的策略上，对于新增的数据库节点，如果没有特地要求的话都会应用 MySQL 数据库；另一方面是与行业内业务倒退状况相干，行内对于高容量、高并发、弹性扩大的业务需要十分旺盛，这种状况下对于分布式架构的数据库要求越来越多，所以对于分布式内容的利用规模也会比拟宏大。行内将利用分为 ABCD 四个等级，最高等级为 A 类利用，外围利用就是指最高等级的 A 类利用。 1.2、面对的挑战行内对高容量、高并发、弹性扩大的业务需要比拟多。目前根本实现了分布式体系的建设，满足业务的需要，MySQL 也是分布式数据库体系的一部分，除了数据库之外也实现了分布式服务、软负载、分布式事务、分布式音讯、批量、缓存、对象存储、文件存储，加上数据库等，共有九大运行撑持平台。通过这些平台的组合，造成了残缺的分布式解决方案，满足业务的要求。 对于运维方面的压力，当初 MySQL 节点数量十分宏大，对于生产运维来说，为了可能撑持这么大的体量，运维的压力十分大，包含监控告警、故障复原等。如果没有借助自动化、智能化的伎俩是很难满足运维的要求。这里咱们是与第三方公司一起单干研发 MySQL 的治理平台，具体的是爱可生公司。咱们也经验了很长的一段单干工夫，可能把这套货色打磨进去，根本笼罩了残缺的运维流程，特地是对故障的诊断和自动化的切换，成果也是十分好的。在这么多节点的大基数状况下，产生故障的总体概率会绝对较高，但都能够很好地应答，在故障时迅速切换，根本不会对业务造成影响。 当初这么大的体量，如果依照传统物理机的部署模式，资源节约会比拟大，特地是在 CPU 方面。因为 MySQL 失常应用的话，CPU 资源个别都会比拟低。这个问题行内看得比拟远，资源布局方面曾经实现了 90% 的容器化部署，目前大部分 MySQL 曾经运行在容器下面，成果也非常明显，使用率可能晋升 4-5 倍的水平。 本次我想重点介绍的内容是，当初外围利用接入到 MySQL，怎样才能保障生产运行的过程中，升高问题的数量和影响的水平？能够分为几个方面来讲：事先，咱们心愿可能在研发阶段尽快发现一些问题；事中，升高问题的影响；预先，心愿疾速定位到问题，迅速地予以解决。 二、 治理思路与计划 这些就是对治理思路的总结。首先是根底标准的管理工作。对于咱们所须要做的工作，所有要求都是应该落在标准下面，心愿做到有理有据，对于前面问题的定位和责任的划分都会十分有帮忙。在此基础上，咱们进行三个方面的治理工作，包含事先、事中和预先。 2.1、标准起到的三个作用首先标准可能制订操作的规范，例如建表的时候该怎么，每张表必须要有主键，建库建表甚至设计字段的时候不容许在 SQL 当中增加字符集和排序规定的属性，默认实例的属性就能够。 ...

23年企业服务马拉松发明客户价值推动人生决策 汪忠田在企业服务赛道曾经短跑了23年，“从客户角度思考问题”“以解决客户问题为指标决策行为”这些大道理，早已成为他的一日三餐、人生日常。 1997年，明基（BenQ）正式在中国市场开疆拓土，同年5月，武汉大学计算机专业毕业生汪忠田入职明基。仅仅两年之后，1999年3月，汪忠田便正式到任明基中国信息技术部经理，“从这份工作开始，本人不仅要关怀技术，更要关怀如何帮忙企业疾速成长”。 又过两年，基于明基团体倒退过程中积淀的供应链、制作、人力资本治理等方面的教训与信息系统，定位于管理软件与咨询服务的明基逐鹿正式挂牌经营，汪忠田接手供应链（SCM）事业部。在他的率领之下，明基逐鹿成为全程供应链解决方案的无力竞争者，从签下第一家客户惠而浦到供应链平台自动化交易规模冲破150亿美元，只用了3年工夫。 在明基逐鹿飞速发展的夺目战绩背地，嗅觉敏锐的汪忠田察觉到了一丝同样，“明基做全程供应链，从需要端到生产端到供给端都要买通，CRM、MES、SRM都要做，可越做心里越没底，200人的团队只能勉强保障框架的完整性，做不到精密、粗劣”。随着教训的累积、眼界的开辟，汪忠田心田的呐喊声量渐涨：“企业服务的外围是为客户发明价值，以此为规范，大而全的时代将一去不返，市场肯定会呈现越来越多的专业化产品，在某个畛域、行业内可能为客户发明更大价值。” 价值观与口号的区别，就在于对人生决策的指引力，2008年，汪忠田带着一众弟兄到职明基、独立守业，定位聚焦于CRM赛道，“任何企业都是以客户为核心，经营模式会从供给推动模式走向需要拉动模式，所以咱们抉择做需要端的企业服务产品，全力以赴做好CRM”。 值得一提的是，汪忠田并没有将瑞泰定义为“通用CRM解决方案供应商”，而是在CRM的细分畛域中再切一刀，定位高端市场的行业化解决方案供应商，“抉择高端市场因为CRM和企业的经营模式紧密结合、行业性很强，且须要基于企业营销模式进行个性化配置和开发，大型企业能力真正深刻利用”。 瑞泰的市场体现印证了汪忠田的精确判断，12年以来，瑞泰曾经成为国内CRM畛域的一流企业，服务客户中不乏徐工、传化、OPPO、TCL、A.O.Smith、小米、泰康、王老吉等行业头部企业。售后畛域激变从老本转向利润，从服务转向产品 面对一连串夺目的战绩，汪忠田又一次陷入长考。这12年间CRM曾经从一个绝对生疏的概念，逐步成长为中国To B服务行业最热赛道，然而汪忠田的关注点却并不是竞争带来的生存压力，“竞争强烈意味着行业能力晋升、客户服务品质也会水涨船高，这是坏事”，他的眼帘投向了2014年前后倒退步调逐步提速的SaaS服务，“10几年来咱们积攒了大量客户的成功经验，包含业务逻辑、服务模式以及对应的技术解决方案。我在意的是，这些价值是否通过SaaS模式，为更多的企业提供服务，在更大范畴内晋升中国制作的市场竞争力？” 2016年，汪忠田力主之下，瑞云信息成立，全力以赴攻坚一款全新产品瑞云服务云——一款聚焦于售后服务畛域的SaaS产品。 策略转型基于对市场变量的正确把握，聚焦售后服务畛域，并非汪忠田灵机一动，他察看到了售后板块正在产生着源自底层的激烈变动：“要感激咱们的客户，这10多年间咱们服务了很多头部客户，他们总能最先把握市场变动。我关注到了两个大变量：第一，对于家电、家居、汽车、机械设备等行业，售后服务是企业的外围竞争力，只有服务让客户称心能力带来复购和客户举荐，比方：FUNAC（发那科）的经营理念是‘Service First’，徐工强调全生命周期、全价值链服务，这些企业都十分重视服务体系和数字化平台建设；第二，这几年流量老本剧增，企业越来越重视客户经营，售后服务是连贯客户、晋升客户体验的最重要触点，所以售后服务不仅要做好被动服务，更要重视晋升被动服务的品质，并从老本核心转向利润核心。” 另一个考量点是SaaS的推广难度，“基于咱们的多年教训，同一行业、不同企业的销售业务差别度可能会达到30%~50%，而售后服务的业务差别度个别不超过30%，更稳固的业务逻辑使其人造适宜于SaaS模式，更容易积淀行业教训，且定制老本绝对较低。” -- 广告--图片 布局售后大市场死守交付、平安底线 放弃业务、技术当先 科创人：创立瑞云服务云是基于“售后服务将成为新兴市场”的判断，瑞云敢于率先开拓新战场，咱们领有哪些先发劣势？汪忠田：市场的造成是基于企业对售后服务定位的三大转变，第一是服务模式从传统的被动服务转向被动服务，第二是客户满意度转向NPS（净推荐值），第三是售后服务由以往的老本核心转向了利润核心。应答这种扭转，服务数字化平台建设必须跟上。瑞云的当先劣势能够说是全方位的，咱们过来10余年积攒了多个行业头部客户的售后服务成功经验，在模式、产品、技术以及海量细节方面，是否为客户提供残缺解决方案，或者深度赋能，客户常常对咱们说“就这么干吧”（笑）。科创人：作为服务于售后服务市场的服务商，瑞云本身在售后服务方面有哪些竞争劣势？汪忠田：稳固、有保障的交付能力，以及在此基础上为客户继续发明价值的能力。咱们的外围价值观就是帮忙客户胜利，从2008年瑞泰公司诞生那天起，不仅12年间交付成功率100%，更让我自豪的是，瑞泰50%以上的订单来自二次订单，这侧面证实客户认可咱们的长期价值，置信咱们能帮忙他继续胜利、为他继续解决问题。瑞云服务云不仅关注我的项目交付和售后反对服务，还十分重视帮忙客户继续晋升服务效率和客户体验，违心为此竭尽所能地提供反对。例如咱们有一个做净水产品的家电企业客户，净水机十分重视装置和定期颐养（滤芯更换），服务次要由经销商、受权服务网点来提供，随着业务量的增长开始导入一些第三方服务平台以晋升服务网络覆盖，第三方服务平台个别都有本人的服务零碎且每家的零碎都不一样，为了反对新的服务模式，咱们的客户胜利经理要第一工夫响应，与客户及第三方服务平台充沛探讨对接形式以确保新服务模式的疾速落地。科创人：您后面提到，很多客户购买瑞云，实质是购买行业成功经验，但购买行为产生后，客户将行业治理教训积淀进其组织外部，瑞云怎样才能继续为客户发明价值、保障本身长期被须要？汪忠田：还是说这家净水器客户，实现了零碎对接的简单工作之后，最近咱们在探讨的是“如何基于客户数据、颐养打算，更加有针对性的发展滤芯营销”。总之，客户胜利经理要随时响应客户业务的变动并提供倡议，而不是仅仅提供技术支持，只有这样能力给客户继续发明价值。对于企业业务而言，没有一劳永逸，只有不停迭代倒退，A行业的成功经验兴许对B行业也无效，甲公司的技术解决方案兴许能够将乙公司的业务流程颠覆性重构，只有瑞云服务云聚焦于售后服务这一畛域，咱们就能采集、发明更多的高价值解决方案。 此外，瑞云团队也非常重视产品和技术创新，我跟咱们的产品经理说，你每个季度起码让我看到三个亮点，这三个亮点要可能让客户感觉对他的帮忙十分大，只有做到这个水平，咱们能力与客户长期单干上来。 科创人：瑞云如何满足客户对平安的需要？汪忠田：这的确是大部分客户最关怀的问题。尽管说以现在的技术解决方案来看，对绝大部分企业来说，上云的安全性远超本地，但平安不是一个概率问题，而是一个生死问题，瑞云平安相干的动作就太多了，不一一阐明，能够概括一下：交付是瑞云最外围的价值，产品翻新是最底层的倒退能源，但平安才是真正的生死线，极尽全力、不容有失，就是咱们看待平安问题的态度。

Docker 运行 Mysql 在 Mysql workbench 无奈连贯 docker run --name mysql-server -p 3306:3306 -v /usr/local/mysql/data:/var/lib/mysql -v /usr/local/mysql/conf.d:/etc/mysql/conf.d -e MYSQL_ROOT_PASSWORD=bei!123 -d mysql Docker MySql Error:Access denied for user 'root'@'localhost' (using password: YES) 解决方案: sudo mkdir /usr/local/mysqlsudo mkdir /usr/local/mysql/datasudo mkdir /usr/local/mysql/conf.ddocker run --name mysql-server -p 3306:3306 -v /usr/local/mysql/data:/var/lib/mysql -v /usr/local/mysql/conf.d:/etc/mysql/conf.d -e MYSQL_ROOT_PASSWORD=bei!123 -d mysqltouch /usr/local/mysql/conf.d/my.cnfsudo gedit /usr/local/mysql/conf.d/my.cnf, and type in below: [mysqld]skip-grant-tablesdocker restart [mysql container id]docker exec -it [mysql container id] bashmysql -uroot -pgrant all privileges on . to 'root'@'%' identified by 'bei!123';select user,authentication_string,host from user;update user set authentication_string='' where user='root';flush privileges;quit mysql ctrl d dsudo gedit /usr/local/mysql/conf.d/my.cnfdelete 'skip-grant-tables'docker restart [mysql container id]docker exec -it [mysql container id] bashmysql -uroot -p (明码是回车)use mysql;alter user 'root'@'localhost' IDENTIFIED BY 'bei!123';alter user 'root'@'%' IDENTIFIED BY 'beya!123';flush privileges;GRANT all ON . TO 'root'@'%' IDENTIFIED BY 'bei!123';flush privileges;尝试过，可行。 ...

ERROR 1449 (HY000): The user specified as a definer ('mysql.infoschema'@'localhost') does not exist先上论断：是mysql.infoschema有问题了，解决方案天然也简略，根本就是或者重建增加账户或者解决登陆失败的起因比方笔者所犯的强行批改账户mysql.infoschema加密办法导致的谬误。而该账户作用是它提供了拜访数据库元数据的形式的一个账户，如果如果该账户有问题了执行show tables，show databases命令天然会失败报错。当然具体起因能够查阅mysql log /var/log/mysql/error.log。 笔者尝试本地装置mysql时候遇到了该问题，通过屡次调试以及网上查阅解决了该问题。然而发现有很多网上答案根本都是浅尝辄止。停留在mysql降级导致的阶段，不能说有问题只能说有待深挖所以提供的解决方案根本也停留在头痛医头脚痛医脚的阶段天然不具备普世性。降级之所以会导致这个问题是因为降级后该账户的加密办法变了，最终根本原因还是账户有问题了。

当初越来越多的利用正在迁徙到“云”上，当企业心愿将其全副或局部经营的工作负载转移到云平台中时，必然会遇到安全性问题。据国家互联网应急核心抽样统计，峰值超过 10Gbps的 DDoS 攻打每个月 4300 多起。刷不开页面，打不开性能，搜不到信息等等这类攻打导致的让用户烦躁不爽的应用妨碍困扰着宽广企业，电商企业甚至还须要放心是否有歹意来获取非法利益。那么，什么是云平安?云平安就是基于云计算商业模式的安全软件、硬件、用户、机构平安云平台的总称。它通过对网络软件的行为进行监测，获取互联网中木马、恶意程序的最新信息，并发送到服务端进行主动剖析和解决，再把病毒和木马的解决方案散发到每一个客户端。对于“云平安”的定义，咱们很难明确形容。米米从云平安钻研方向、云平安有什么益处？与你独特探讨云平安。 （中小企业上云，就找云来米！能够搜小程序【云来米】理解详情，登录输出邀请码：8KY4FQ4） 云平安三大钻研方向 云计算平安云计算是一种基于互联网的计算形式，通过这种形式，共享的软硬件资源和信息能够按需要提供给计算机各种终端和其余设施。 图源：维基百科 次要钻研如何保障云本身及云上各种利用的平安，包含云计算机系统平安、用户数据的平安存储与隔离、用户接入认证、信息传输平安、网络攻击防护、合规审计等。2. 平安基础设施的云化次要钻研如何采纳云计算新建与整合平安基础设施资源，优化平安防护机制，包含通过云计算技术构建超大规模安全事件、信息采集与解决平台，实现对海量信息的采集与关联剖析，晋升全网安全事件把控能力及危险控制能力。3. 云平安服务次要钻研各种基于云计算平台为用户提供的平安服务，如防病毒服务等。 云平安有什么益处？ 1.便捷对于整个互联网的平安环境而言，在大数据的帮忙下，一些原先无奈被发现的破绽能够更容易被找到和解决，应用的用户越多就越平安。2.便宜对于用户而言，原先只能依附本地软硬件解决的问题，当初能够取得整个“云”所有数据的反对了，应答问题更加全面，进攻更加无死角，当然也更省钱。3.疾速对于平安服务商而言，能够疾速无效爱护用户数据，做好大数据服务。咱们须要遵循事先预防、事中进攻、预先解决，别离对应着不同级别的攻打事件和平安需要。 中小企业上云，就找云来米！能够搜小程序【云来米】理解详情，登录输出邀请码：8KY4FQ4

1.InnoDB的锁定机制InnoDB存储引擎反对行级锁，反对事务处理，事务是有一组SQL语句组成的逻辑处理单元，他的ACID个性如下： 原子性(Atomicity): 事务具备原子不可分割的个性，要么一起执行，要么都不执行。一致性(Consistency): 在事务开始和事务完结时，数据都保持一致状态。隔离性(Isolation): 在事务开始和完结过程中，事务放弃着肯定的隔离个性，保障事务不受内部并发数据操作的影响。持久性(Durability): 在事务实现后，数据将会被长久化到数据库中。并发事务能进步数据库资源的利用率，进步了数据库的事务吞吐量，但并发事务也存在一些问题，次要包含： 更新失落(Lost Update): 两个事务更新同一条数据，但第二个事务中途失败退出，导致两个批改都生效了；因为此时数据库没有执行任何锁操作，并发事务并没有被隔离。(古代数据库曾经不存在这种问题)脏读(Dirty Reads): 一个事务读了某行数据，然而另一个事务曾经更新了这行数据，这是十分危险的，很可能导致所有的操作被回滚。不可反复读: 一个事务对一行数据反复读取两次(屡次)，可是失去了不同的后果,在两次读取过程中，有可能存在另一个事务对数据进行了批改。幻读:事务在操作过程中进行两次查问，第二次查问后果蕴含了第一次没有呈现的数据。呈现幻读的次要起因是两次查问过程中另一个事务插入新的数据。数据库并发中的“更新失落”通常应该是完全避免的，但避免更新失落数据，并不能单靠数据库事务管制来解决，须要应用程序对要更新的数据加必要的锁来解决，而以上呈现的数据库问题都必要由数据库提供肯定的事务隔离机制来解决。为了防止数据库事务并发带来的问题，在规范SQL标准中定义了4个事务的隔离级别，不同的隔离级别对事务处理不一样。 数据库隔离级别的比拟隔离级别读数据一致性脏读不可反复读幻读未提交读(Read uncommitted)最低级别，只能保障不读取物理上损坏的数据是是是已提交读(Read committed)语句级否是是可反复读(Repeatable read)事务级否否是可序列化(Serializable)最高级别，事务级否否否InnoDB存储引擎实现了4中行锁，别离时共享锁(S)、排他锁(X)、动向共享锁(IS)、动向排他锁(IX)。 共享锁：大家都能读，然而不能改，只有其中一个独占共享锁时候能力改；排它锁：我要改，你们都不能改，也不能读(但能够MVCC快照读)了解意向锁意向锁不会和行级的S和X锁抵触，只会和表级的S和X锁抵触意向锁是为了防止遍历全副行锁 思考这个例子：事务A锁住了表中的一行，让这一行只能读，不能写。之后，事务B申请整个表的写锁。 如果事务B申请胜利，那么实践上它就能批改表中的任意一行，这与A持有的行锁是抵触的。 数据库须要防止这种抵触，就是说要让B的申请被阻塞，直到A开释了行锁。数据库要怎么判断这个抵触呢？step1：判断表是否已被其余事务用表锁锁表step2：判断表中的每一行是否已被行锁锁住。留神step2，这样的判断办法效率切实不高，因为须要遍历整个表。 于是就有了意向锁。在意向锁存在的状况下，事务A必须先申请表的动向共享锁，胜利后再申请一行的行锁。在意向锁存在的状况下，下面的判断能够改成step1：不变step2：发现表上有动向共享锁，阐明表中有些行被共享行锁锁住了，因而，事务B申请表的写锁会被阻塞。 1.1通过索引检索数据，上共享锁，行锁(如果不通过索引，会应用表锁)1.1通过索引检索数据，上共享锁，行锁SessionA SessionBmysql> set autocommit=0; mysql> set autocommit=0;Query OK, 0 rows affected (0.02 sec) Query OK, 0 rows affected (0.02 sec)mysql> select * from test; mysql> select * from test;--------------------------------------------------------------------------------+----+-------+-------+-------+ +----+-------+-------+-------+ | id | name | money | level | | id | name | money | level |+----+-------+-------+-------+ +----+-------+-------+-------+| 1 | tom | 100 | 1 | | 1 | tom | 100 | 1 || 2 | jack | 200 | 2 | | 2 | jack | 200 | 2 || 3 | lucas | 300 | 3 | | 3 | lucas | 300 | 3 |+----+-------+-------+-------+ +----+-------+-------+-------+3 rows in set (0.00 sec) 3 rows in set (0.00 sec)--------------------------------------------------------------------------------对主键索引上共享锁,其余事务也能获取到共享锁mysql> select * from test where id=1 lock in share mode;+----+------+-------+-------+| id | name | money | level |+----+------+-------+-------+| 1 | tom | 100 | 1 |+----+------+-------+-------+1 row in set (0.01 sec)-------------------------------------------------------------------------------- 事务B也能持续加共享锁 mysql> select * from test where id=1 lock in share mode; +----+------+-------+-------+ | id | name | money | level | +----+------+-------+-------+ | 1 | tom | 100 | 1 | +----+------+-------+-------+ 1 row in set (0.01 sec) 但无奈更新，因为事务A也加了共享锁 mysql> update test set level=11 where id=1; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction MORE: 无奈加排它锁 select *from test where id=1 for update; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction 能够更新未加锁的，比方 mysql> update test set level=11 where id=2; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0--------------------------------------------------------------------------------事务A也无奈更新，因为事务B加了共享锁mysql> update test set level=11 where id=1;ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction-------------------------------------------------------------------------------- 任意一个开释共享锁，则独占共享锁的事务能够更新 mysql> commit; Query OK, 0 rows affected (0.00 sec)--------------------------------------------------------------------------------事务B开释锁，事务A独占，能够更新了mysql> update test set level=11 where id=1;Query OK, 1 row affected (0.00 sec)Rows matched: 1 Changed: 1 Warnings: 01.2通过索引检索数据，上排他锁，行锁1.2通过索引检索数据，上排他锁，行锁SessionA SessionBmysql> set autocommit=0; mysql> set autocommit=0;Query OK, 0 rows affected (0.02 sec) Query OK, 0 rows affected (0.02 sec)mysql> select * from test; mysql> select * from test;--------------------------------------------------------------------------------+----+-------+-------+-------+ +----+-------+-------+-------+ | id | name | money | level | | id | name | money | level |+----+-------+-------+-------+ +----+-------+-------+-------+| 1 | tom | 100 | 1 | | 1 | tom | 100 | 1 || 2 | jack | 200 | 2 | | 2 | jack | 200 | 2 || 3 | lucas | 300 | 3 | | 3 | lucas | 300 | 3 |+----+-------+-------+-------+ +----+-------+-------+-------+3 rows in set (0.00 sec) 3 rows in set (0.00 sec)--------------------------------------------------------------------------------对主键索引上排他锁,其余事务也能获取到共享锁mysql> select *from test whereid=1 for update;+----+------+-------+-------+| id | name | money | level |+----+------+-------+-------+| 1 | tom | 100 | 1 |+----+------+-------+-------+1 row in set (0.01 sec)-------------------------------------------------------------------------------- 事务B则不能持续上排它锁，会产生期待 mysql> select *from test where id=1 for update; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction MORE: 也不能更新，因为更新也是上排它锁 mysql> update test set level=2 where id=1; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction 也不能上共享锁 mysql> select * from test where level=1 lock in share mode; ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction--------------------------------------------------------------------------------事务A能够更新mysql> update test set level=11 where id=1;Query OK, 1 row affected (0.08 sec)Rows matched: 1 Changed: 1 Warnings: 0--------------------------------------------------------------------------------开释排它锁mysql> commit;Query OK, 0 rows affected (0.00 sec)-------------------------------------------------------------------------------- 事务A开释锁，事务B就能够加排它锁了 mysql> select * from test where id=1 for update; +----+------+-------+-------+ | id | name | money | level | +----+------+-------+-------+ | 1 | tom | 100 | 1 | +----+------+-------+-------+ 1 row in set (0.00 sec)1.3通过索引更新数据，也是上排他锁，行锁对于update,insert,delete语句会主动加排它锁 ...

MYSQL查看数据库show databases;抉择数据库use 数据库名;查看数据库表格show tables;创立数据库create database 数据库名;删除数据库drop database 数据库名;删除数据库表drop table 表名;插入数据insert into 表名(字段)values(数据);查问数据select * from 表名;select * from 表名 where 字段='条件';更新数据update 表名 set 字段='批改的数据' where 字段='抉择的字段';删除数据delete from 表名 where 字段='抉择的字段';注意事项：如果没有where，MySQL会删除所有数据。LIKE（含糊查问）select * from 表名 where name LIKE 'java%';（查问以Java结尾的信息）select * from 表名 where name LIKE '%java';（查问以Java结尾的信息）select * from 表名 where name LIKE '%java%';（查问蕴含Java的信息）索引：%结尾的含糊查问会令索引生效。%：代表多个字符。_：代表单个字符。UNION（select连贯）select 字段 from 表名1 union(distinct | all) select 字段 from 表名2;DISTINCT：删除后果集中反复的数据。默认状况下 UNION 操作符曾经删除了反复数据。ALL：返回所有后果集，蕴含反复数据。ORDER BY（排序）select * from 表名 order by 字段 ASC;（依据升序字段排序）select * from 表名 order by 字段 desc;（依据字段倒序排序）默认状况下升序排序，所以ASC能够省略。GROUP BY（分组）select 字段1,字段2 from 表名 group by 字段1;select 字段1,字段2 from 表名 group by 字段1 WITH ROLLUP;WITH ROLLUP：以null进行汇总。DISTINCT（去反复）select 表连贯INNER JOIN（内连贯或等值连贯）：获取两个表中字段匹配关系的记录。LEFT JOIN（左连贯）：获取左表所有记录，即便右表没有对应匹配的记录。RIGHT JOIN（右连贯）：获取右表所有记录，即便左表没有对应匹配的记录。select * from 表名1 a INNER JOIN 表名2 b on a.字段1=b.字段2;select * from 表名1 a LEFT JOIN 表名2 b on a.字段1=b.字段2;select * from 表名1 a RIGHT JOIN 表名2 b on a.字段1=b.字段2;INNER JOIN（内连贯）：取两表中的交加LEFT JOIN（左连贯）：取左表和两表的交加RIGHT JOIN（右连贯）：取右表和两表的交加多表查问：select * from 表1 a inner join 表2 b on a.字段=b.字段 left join 表3 c on b.字段=c.字段;内连贯左连贯右连贯数据库类型数值类型类型大小用处TINYINT1byte小整型值SMALLINT2byte大整型值MEDIUMINT3byte大整型值INT或INTEGER4byte大整型值BIGINT8byte极大整型值FLOAT4byte单精度浮点数值DOUBLE8byte双精度浮点数值DECIMAL对DECIMAL(M,D) ，如果M>D，为M+2否则为D+2小数值日期类型类型大小(byte)格局用处DATE3YYYY-MM-DD日期值TIME3HH:MM:SS时分秒YEAR1YYYY年份值DATETIME8YYYY-MM-DD HH:MM:SS日期工夫TIMESTAMP4YYYYMMDD HHMMSS日期工夫字符串类型类型大小用处CHAR0-255 bytes定长字符串VARCHAR0-65535 bytes变长字符串MYSQL事务1、mysql中只有应用innodb数据库引擎的数据库或表才反对事务。2、mysql中的myisam数据库引擎不反对事务。3、事务处理能够用来保护数据库的完整性，保障成批的SQL语句要么全副执行，要么全副不执行。4、事务用来治理insert、update、delete事务是必须满足4个条件(ACID)： ...

MySQL order by 简略解析1. 语句SELECT distinct first_letterFROM tb_customerWHERE (deleted = 0) ORDER BY first_letter = '#' asc,first_letter;2. 集体了解order by first_letter = '#' 相当于做了一个判断 first_letter == "#" ? 1 : 0; 3. SQL残缺写法SELECT distinct first_letterFROM tb_customerWHERE (deleted = 0) ORDER BY if(first_letter = '#',1,0) asc,first_letter asc;4. 后果ABCDEFGHIJKLMNOP

索引 一、什么是索引？ 索引是一种非凡的文件(InnoDB数据表上的索引是表空间的一个组成部分)，它们蕴含着对数据表里所有记录的援用指针。 索引是一种数据结构。数据库索引，是数据库管理系统中一个排序的数据结构，以帮助疾速查问、更新数据库表中数据。索引的实现通常应用B树及其变种B+树。 更艰深的说，索引就相当于目录。为了不便查找书中的内容，通过对内容建设索引造成目录。索引是一个文件，它是要占据物理空间的。 二、索引有哪些优缺点？ 1.索引的长处 能够大大放慢数据的检索速度，这也是创立索引的最次要的起因。 通过应用索引，能够在查问的过程中，应用优化暗藏器，进步零碎的性能。 2.索引的毛病 工夫方面：创立索引和保护索引要消耗工夫，具体地，当对表中的数据进行减少、删除和批改的时候，索引也要动静的保护，会升高增/改/删的执行效率； 空间方面：索引须要占物理空间。 三、索引应用场景（重点） 1.where 上图中，依据id查问记录，因为id字段仅建设了主键索引，因而此SQL执行可选的索引只有主键索引，如果有多个，最终会选一个较优的作为检索的根据。 -- 减少一个没有建设索引的字段altertableinnodb1addsexchar(1);-- 按sex检索时可选的索引为nullEXPLAINSELECT*frominnodb1wheresex='男'; 能够尝试在一个字段未建设索引时，依据该字段查问的效率，而后对该字段建设索引（alter table 表名 add index(字段名)），同样的SQL执行的效率，你会发现查问效率会有显著的晋升（数据量越大越显著）。 2.order by 当咱们应用order by将查问后果依照某个字段排序时，如果该字段没有建设索引，那么执行打算会将查问出的所有数据应用内部排序（将数据从硬盘分批读取到内存应用外部排序，最初合并排序后果），这个操作是很影响性能的，因为须要将查问波及到的所有数据从磁盘中读到内存（如果单条数据过大或者数据量过多都会升高效率），更无论读到内存之后的排序了。 然而如果咱们对该字段建设索引alter table 表名 add index(字段名)，那么因为索引自身是有序的，因而间接依照索引的程序和映射关系逐条取出数据即可。而且如果分页的，那么只用取出索引表某个范畴内的索引对应的数据，而不必像上述那取出所有数据进行排序再返回某个范畴内的数据。（从磁盘取数据是最影响性能的） 3.join 对join语句匹配关系（on）波及的字段建设索引可能提高效率 4.索引笼罩 如果要查问的字段都建设过索引，那么引擎会间接在索引表中查问而不会拜访原始数据（否则只有有一个字段没有建设索引就会做全表扫描），这叫索引笼罩。因而咱们须要尽可能的在select后只写必要的查问字段，以减少索引笼罩的几率。 这里值得注意的是不要想着为每个字段建设索引，因为优先应用索引的劣势就在于其体积小。 四、索引有哪几种类型？ 1.主键索引:数据列不容许反复，不容许为NULL，一个表只能有一个主键。 2.惟一索引: 数据列不容许反复，容许为NULL值，一个表容许多个列创立惟一索引。 能够通过 ALTER TABLE table_name ADD UNIQUE (column); 创立惟一索引 能够通过 ALTER TABLE table_name ADD UNIQUE (column1,column2); 创立惟一组合索引 3.一般索引: 根本的索引类型，没有唯一性的限度，容许为NULL值。 能够通过ALTER TABLE table_name ADD INDEX index_name (column);创立一般索引 ...

脏读:事务A读到了事务B已更新但未提交的数据； 事务A事务BSET autocommit = 0;SET autocommit = 0;select money From test where id=1;Res: 100select money From test where id=1;Res: 100 update test set money=666 where id=1;Res: Query OK, 1 row affected (0.00 sec)select money From test where id=1;Res: 666commit; Query OK, 0 rows affected (0.00 sec)

一、用户操作相干1.创立用户命令： CREATE USER 'username'@'host' IDENTIFIED BY 'password';阐明： username: 你将创立的用户名host: 指定该用户在哪个主机上能够登陆，如果是本地用户可用localhost，如果想让该用户能够从任意近程主机登陆，能够应用通配符%password：该用户的登陆密码，明码能够为空，如果为空则该用户能够不须要明码登陆服务器2.受权命令： GRANT privileges ON databasename.tablename TO 'username'@'host'阐明： privileges：用户的操作权限，如SELECT，INSERT，UPDATE等，如果要授予所的权限则应用ALLdatabasename：数据库名tablename：表名，如果要授予该用户对所有数据库和表的相应操作权限则可用*示意，如*.*例子： GRANT SELECT, INSERT ON test.user TO 'pig'@'%';GRANT ALL ON *.* TO 'pig'@'%';留神：用以上的命令受权的用户不能给其余的用户受权，如果想让该用户能够受权，用以下命令： GRANT privileges ON databasename.tablename TO 'username'@'host' WITH GRANT OPTION;3.设置与更改用户明码命令： SET PASSWORD FOR 'username'@'host' = PASSWORD('newpassword');如果是以后登陆用户用: SET PASSWORD = PASSWORD("newpassword");例子： SET PASSWORD FOR 'pig'@'%' = PASSWORD("123456");4.撤销用户权限命令： REVOKE privilege ON databasename.tablename FROM 'username'@'host';阐明：privilege, databasename, tablename：同受权局部 例子： REVOKE SELECT ON *.* FROM 'pig'@'%';留神：如果你在给用户'pig'@'%'受权的时候是这样的（或相似的）：GRANT SELECT ON test.user TO 'pig'@'%'，则在应用REVOKE SELECT ON *.* FROM 'pig'@'%';命令并不能撤销该用户对test数据库中user表的SELECT 操作。相同，如果受权应用的是GRANT SELECT ON *.* TO 'pig'@'%';则REVOKE SELECT ON test.user FROM 'pig'@'%';命令也不能撤销该用户对test数据库中user表的Select权限。 ...

因为当初 ORM 框架的成熟使用，很多小伙伴对于 JDBC 的概念有些单薄，ORM 框架底层其实是通过 JDBC 操作的 DB JDBC（JavaDataBase Connectivity）是 Java 数据库连贯, 说的直白点就是应用 Java 语言操作数据库 由 SUN 公司提供出一套拜访数据库的标准 API， 并提供绝对应的连贯数据库协定规范， 而后 各厂商依据标准提供一套拜访自家数据库的 API 接口 文章大数据量操作外围围绕 JDBC 开展，目录构造如下： MySQL JDBC 大数据量操作 惯例查问流式查问游标查问JDBC RowDataJDBC 通信原理流式游标内存剖析 单次调用内存应用并发调用内存应用MyBatis 如何应用流式查问结言MySql JDBC 大数据量操作整篇文章以大数据量操作为议题，通过开发过程中的需要引出相干知识点 迁徙数据导出数据批量解决数据一般而言笔者认为在 Java Web 程序里，可能被称为大数据量的，几十万到千万不等，再高的话 Java（WEB 利用）解决就不怎么适合了 举个例子，当初业务零碎须要从 MySQL 数据库里读取 500w 数据行进行解决，应该怎么做 惯例查问，一次性读取 500w 数据到 JVM 内存中，或者分页读取流式查问，建设长连贯，利用服务端游标，每次读取一条加载到 JVM 内存游标查问，和流式一样，通过 fetchSize 参数，管制一次读取多少条数据文章首发自公众号：源码趣味圈，专一分享高并发、分布式、框架底层源码等常识惯例查问默认状况下，残缺的检索后果集会将其存储在内存中。在大多数状况下，这是最无效的操作形式，并且因为 MySQL 网络协议的设计，因而更易于实现 假如单表 500w 数据量，没有人会一次性加载到内存中，个别会采纳分页的形式 @SneakyThrows@Overridepublic void pageQuery() { @Cleanup Connection conn = dataSource.getConnection(); @Cleanup Statement stmt = conn.createStatement(); long start = System.currentTimeMillis(); long offset = 0; int size = 100; while (true) { String sql = String.format("SELECT COLUMN_A, COLUMN_B, COLUMN_C FROM YOU_TABLE LIMIT %s, %s", offset, size); @Cleanup ResultSet rs = stmt.executeQuery(sql); long count = loopResultSet(rs); if (count == 0) break; offset += size; } log.info(" ???????????? 分页查问耗时 :: {} ", System.currentTimeMillis() - start);}上述形式比较简单，然而在不思考 LIMIT 深分页优化状况下，线上数据库服务器就凉了，亦或者你能等个几天工夫检索数据 ...

在正式开始之前，咱们先来看下 MySQL 服务器的配置和版本号信息，如下图所示：“兵马未动粮草先行”，看完了相干的配置之后，咱们先来创立一张测试表和一些测试数据。 -- 如果存在 person 表先删除DROP TABLE IF EXISTS person; -- 创立 person 表，其中 username 字段可为空，并为其设置一般索引CREATE TABLE person ( id INT PRIMARY KEY auto_increment, name VARCHAR(20), mobile VARCHAR(13), index(name)) ENGINE='innodb';-- person 表增加测试数据insert into person(name,mobile) values('Java','13333333330'), ('MySQL','13333333331'), ('Redis','13333333332'), ('Kafka','13333333333'), ('Spring','13333333334'), ('MyBatis','13333333335'), ('RabbitMQ','13333333336'), ('Golang','13333333337'), (NULL,'13333333338'), (NULL,'13333333339'); select * from person;构建的测试数据，如下图所示：有了数据之后，咱们就来看当列中存在 NULL 值时，到底会导致哪些问题？ 1.count 数据失落当某列存在 NULL 值时，再应用 count 查问该列，就会呈现数据“失落”问题，如下 SQL 所示： select count(*),count(name) from person;查问执行后果如下：从上述后果能够看出，当应用的是 count(name) 查问时，就失落了两条值为 NULL 的数据失落。 解决方案如果某列存在 NULL 值时，就是用 count(*) 进行数据统计。 扩大常识：不要应用 count(常量)阿里巴巴《Java开发手册》强制规定：不要应用 count(列名) 或 count(常量) 来代替 count()，count() 是 SQL92 定义的规范统计行数的语法，跟数据库无关，跟 NULL 和非 NULL 无关。阐明：count(*) 会统计值为 NULL 的行，而 count(列名) 不会统计此列为 NULL 值的行。 ...

Maxwell （mysql-to-json）初体验本篇次要解说一下 Maxwell ， Maxwell 是一个读取 MySQL binlogs 日志而后转换成json 输入到 Kafka ，Redis ，RabbitMQ 等等 中间件中前言以前写过一篇对于 阿里的 canal ，它也是通过监听 mysql 的 binlogs 日志的工具，本公司目前就是应用这个，而我明天要说的是 maxwell 它是在外部本人转换为 json 格局 输入到 其余中间件 1.下载和装置Maxwell间接下载 官网地址: http://maxwells-daemon.io/ 或者 Docker 下载 我这里抉择的是应用Docker的形式进行装置 docker pull zendesk/maxwell 2.配置 Mysql 开起binlogs配置 my.cnf我的门路在 /etc/my.cnf $ vi my.cnf[mysqld]server_id=1log-bin=master binlog_format=row或者间接运行如下指令： mysql> set global binlog_format=ROW;mysql> set global binlog_row_image=FULL;须要给 maxwell 用户 肯定的权限 mysql> CREATE USER 'maxwell'@'%' IDENTIFIED BY 'XXXXXX';mysql> GRANT ALL ON maxwell.* TO 'maxwell'@'%';mysql> GRANT SELECT, REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'maxwell'@'%';# or for running maxwell locally:mysql> CREATE USER 'maxwell'@'localhost' IDENTIFIED BY 'XXXXXX';mysql> GRANT ALL ON maxwell.* TO 'maxwell'@'localhost';mysql> GRANT SELECT, REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'maxwell'@'localhost';3. Maxwell 输入到 stdout 规范输入模式启在保障 mysql 能够拜访 并且失常启动的状况下 输出以下命令： ...

最近有个新我的项目刚过完需要，正式进入数据库表构造设计阶段，公司规定对立用数据建模工具 PowerDesigner。但我并不是太爱用这个工具，因为它的性能切实是太多了，显得很臃肿，而平时设计表用的也就那么几个性能。 这里找到一个好用的工具，快马加鞭的分享给大家，PDMan 一款国产开源的数据库模型建模工具，它的性能PowerDesigner 均曾经实现，但相比于轻便的PowerDesigner来说。PDMan 专门用于数据表的设计，界面更加清新丑陋，性能也非常简洁，没多余的设置很容易上手，还提供了 Windows，Mac，Linux 三个平台版本。 PDMan保留的是一个JSON文件，应用前得先做点筹备工作，配置一下 JDK 和 MySQL 连贯，后边的性能会用到。 下边咱们来逐个过下PDMan 的性能点。 生成数据库文档PDMan 反对一键导出数据表构造的DDL执行脚本，JSON格局数据，还有数据库表构造文档，其中数据库文档又能够生成 html 、word、markdown 三种格局，文档内容包含各个表的字段属性，数据表间的关系图。 html 格局 word 格局 markdown 格局 数据库逆向解析前边咱们曾经配置了数据库信息，这里间接将已有数据库中的数据表，逆向生成表构造，和数据表间的关系图。 版本控制PDMan 能够管制每次批改的版本，对任意版本间的批改进行比对，和Git的版本控制相似。 全局配置设置表构造的全局通用字段属性，通常在建表的时候，每个表都会有像创立工夫 create_time、更新工夫update_time、删除标记delete_flag、乐观锁revision这类字段，这样设置完当前在建表时会主动生成。 还能够自定义数据类型，比方：字符型能够自定义 varchar(10)、varchar(20)、varchar(30)，建字段时间接抉择对应数据类型即可，一劳永逸。 PDMan整体性能十分的简洁，不过也足以应答日常开发中数据库设计需要了。 下载地址：http://www.pdman.cn/整顿了几百本各类技术电子书，有须要的同学能够，关注公众号 [ 程序员内点事 ] 回复 [ 666 ] 自取。还有想要加技术群的同学能够加我好友，和大佬侃技术、不定期内推，程序员的内点事这都有。

谬误起因：高版本数据库（8.0）转存sql文件 并导入低版本数据库（5.7） 解决办法： 计划一：降级mysql至高版本 计划二：将须要导入的sql文件，把其中的 utf8mb4_0900_ai_ci 全副替换为 utf8_general_ci utf8mb4 替换为 utf8 从新执行sql文件

想将MySQL5.5为5.7，上网搜了一波后，联合了本人的理论状况，记录下操作过程；首先感激 https://segmentfault.com/a/1190000016783066 的作者，参照了这个的内容实现了“phpstudy2018降级MySQL5.5为5.7”的目标； 以下是我整个操作过程： 一、MySQL官网下载MySQL5.7版本，我这里下载的是MySQL5.7.32。有须要的小伙伴能够参照这个教程噢：https://www.jianshu.com/p/55f... 二、找到phpStudyPHPTutorial目录，我的目录是D:\willen\phpStudyNew\PHPTutorial，将之前的MySQL文件夹重命名为MySQL_bak【弄个备份，怕出问题】，把下载好的MySQL5.7.32版本解压并批改为MySQL,而后在MySQL目录下创立my.ini文件并退出以下内容：[mysqld]port=3306basedir="D:/willen/phpStudyNew/PHPTutorial/MySQL/"datadir="D:/willen/phpStudyNew/PHPTutorial/MySQL/data/"留神噢，须要将D:/willen/phpStudyNew/PHPTutorial/改为本人对应的目录噢 三、装置数据库因为5.7版本没有data文件夹，咱们须要初始化，管理员权限执行如下命令mysqld --initialize-insecure --user=mysql能够用命令行，抉择管理员运行，而后切换到这个D:/willen/phpStudyNew/PHPTutorial/MySQL/bin目录下运行下面的指令即可 如果运行完mysqld --initialize-insecure --user=mysql这个指令后，（1）如果报这个谬误： 这种谬误是因为未装置 vcredist 引起的 下载 vcredist 地址：https://www.microsoft.com/zh-CN/download/details.aspx?id=40784 装置方才下载的那个软件，地位默认即可，装置胜利 而后从新进行装置，胜利解决这个问题！ （2）如果没有报错，则能够看到目录下就会创立好data目录 2.装置MySQL5.7.32，执行 mysqld --install mysql --default-file=D:\willen\phpStudyNew\PHPTutorial\MySQL\my.ini留神D:\willen\phpStudyNew\PHPTutorial\MySQL\my.ini要替换成你的my.ini的地位 创立胜利然而当初还是没法启动，关上phpstudy2018也启动后也会进行 ，咱们要在Phpstudy创立一个服务，如下： 右键我的电脑，抉择治理，在弹出的计算机管理窗口中双击服务和应用程序，在子菜单中选择服务，在右侧窗口中能够看到零碎中的服务信息，查看服务有mysql、MySQLa两个服务，mysql是方才装置MySQL创立扔，5.7.32MySQLa的服务是phpstudy创立的(不晓得什么起因phpstudy2018默认装置好没有mysql服务) 而后，咱们在服务外面启动MySQLa服务，而后去看phpstudy，数据库服务也启动了，然而如果咱们重启或者说敞开了再启动还是启动不起来，这是因为有2个服务占用了，起抵触,须要删除一个。 3、删除mysql服务(因为这个不是Phpstudy创立的服务，所以删除，不能删除MySQLa服务) sc delete mysql 而后再试试，重启一下phpstudy，发现重启胜利了 四、登录数据库首次登录是没有明码的，若须要批改明码，能够执行以下指令： update mysql.user set authentication_string=password('root') where user='root';留神，这里要将password('root') 里的root替换成你想要的明码 还有，须要留神，批改完明码后，须要要刷新下权限，不然是新的明码是不失效的 刷新权限指令 flush privileges;以上是整个phpstudy2018降级MySQL5.5为5.7过程，心愿对大家有肯定的帮忙。 再次感激https://segmentfault.com/a/1190000016783066的作者的分享

Query Profiler通过Query Profiler来定位一条 Query 的性能瓶颈，这里咱们再具体介绍一下 Profiling 的用处及应用办法。开启 Profiling 参数 set profiling = 1;查看开启后 SQL 语句的执行工夫 show profiles;查看某条语句每个过程的具体工夫，如果不加 Query_ID 则默认查看最新执行的语句。 show profile [type] for query n;（Query_ID）序号剖析类型：type形容1all显示所有性能信息2block io显示块io（块的输入输出）的次数3context swithches上下文切换开销，被动和被动4cpu显示用户和零碎的cpu应用状况5ipc显示发送和承受的信息数量6memory还未实现7page faults显示次要的和主要的页面故障8source显示源代码的函数名称与地位9swaps显示替换次数相干的开销信息

前言首先思考一个问题:在高并发的场景中,对于数据库都有哪些优化的伎俩？罕用的有以下的实现办法:读写拆散、加缓存、主从架构集群、分库分表等，在互联网利用中,大部分都是读多写少的场景,设置两个库,主库和读库。 主库的职能是负责写,从库次要是负责读,能够建设读库集群,通过读写职能在数据源上的隔离达到缩小读写抵触、 释压数据库负载、爱护数据库的目标。在理论的应用中,但凡波及到写的局部间接切换到主库，读的局部间接切换到读库，这就是典型的读写拆散技术。本篇博文将聚焦读写拆散,探讨如何实现它。 目录一: 主从数据源的配置二: 数据源路由的配置三：数据源上下文环境四：切换注解和 Aop 配置五：用法以及测试六：总结 主从同步的局限性：这里分为主数据库和从数据库,主数据库和从数据库放弃数据库构造的统一,主库负责写,当写入数据的时候,会主动同步数据到从数据库；从数据库负责读,当读申请来的时候,间接从读库读取数据,主数据库会主动进行数据复制到从数据库中。不过本篇博客不介绍这部分配置的常识,因为它更偏运维工作一点。 这里波及到一个问题:主从复制的提早问题,当写入到主数据库的过程中,忽然来了一个读申请,而此时数据还没有齐全同步,就会呈现读申请的数据读不到或者读出的数据比原始值少的状况。具体的解决办法最简略的就是将读申请临时指向主库,然而同时也失去了主从拆散的局部意义。也就是说在严格意义上的数据一致性场景中,读写拆散并非是齐全适宜的,留神更新的时效性是读写拆散应用的毛病。 好了,这部分只是理解,接下来咱们看下具体如何通过 java 代码来实现读写拆散: 该我的项目须要引入如下依赖：springBoot、spring-aop、spring-jdbc、aspectjweaver 等 一: 主从数据源的配置咱们须要配置主从数据库,主从数据库的配置个别都是写在配置文件外面。通过@ConfigurationProperties 注解,能够将配置文件(个别命名为:application.Properties)里的属性映射到具体的类属性上,从而读取到写入的值注入到具体的代码配置中,依照习惯大于约定的准则,主库咱们都是注为 master,从库注为 slave。 本我的项目采纳了阿里的 druid 数据库连接池,应用 build 建造者模式创立 DataSource 对象,DataSource 就是代码层面形象进去的数据源,接着须要配置 sessionFactory、sqlTemplate、事务管理器等 /** * 主从配置 * * @author wyq */@Configuration@MapperScan(basePackages = "com.wyq.mysqlreadwriteseparate.mapper", sqlSessionTemplateRef = "sqlTemplate")public class DataSourceConfig { /** * 主库 */ @Bean @ConfigurationProperties(prefix = "spring.datasource.master") public DataSource master() { return DruidDataSourceBuilder.create().build(); } /** * 从库 */ @Bean @ConfigurationProperties(prefix = "spring.datasource.slave") public DataSource slaver() { return DruidDataSourceBuilder.create().build(); } /** * 实例化数据源路由 */ @Bean public DataSourceRouter dynamicDB(@Qualifier("master") DataSource masterDataSource, @Autowired(required = false) @Qualifier("slaver") DataSource slaveDataSource) { DataSourceRouter dynamicDataSource = new DataSourceRouter(); Map<Object, Object> targetDataSources = new HashMap<>(); targetDataSources.put(DataSourceEnum.MASTER.getDataSourceName(), masterDataSource); if (slaveDataSource != null) { targetDataSources.put(DataSourceEnum.SLAVE.getDataSourceName(), slaveDataSource); } dynamicDataSource.setTargetDataSources(targetDataSources); dynamicDataSource.setDefaultTargetDataSource(masterDataSource); return dynamicDataSource; } /** * 配置sessionFactory * @param dynamicDataSource * @return * @throws Exception */ @Bean public SqlSessionFactory sessionFactory(@Qualifier("dynamicDB") DataSource dynamicDataSource) throws Exception { SqlSessionFactoryBean bean = new SqlSessionFactoryBean(); bean.setMapperLocations( new PathMatchingResourcePatternResolver().getResources("classpath*:mapper/*Mapper.xml")); bean.setDataSource(dynamicDataSource); return bean.getObject(); } /** * 创立sqlTemplate * @param sqlSessionFactory * @return */ @Bean public SqlSessionTemplate sqlTemplate(@Qualifier("sessionFactory") SqlSessionFactory sqlSessionFactory) { return new SqlSessionTemplate(sqlSessionFactory); } /** * 事务配置 * * @param dynamicDataSource * @return */ @Bean(name = "dataSourceTx") public DataSourceTransactionManager dataSourceTransactionManager(@Qualifier("dynamicDB") DataSource dynamicDataSource) { DataSourceTransactionManager dataSourceTransactionManager = new DataSourceTransactionManager(); dataSourceTransactionManager.setDataSource(dynamicDataSource); return dataSourceTransactionManager; }}二: 数据源路由的配置路由在主从拆散是十分重要的,根本是读写切换的外围。Spring 提供了 AbstractRoutingDataSource 依据用户定义的规定抉择以后的数据源，作用就是在执行查问之前，设置应用的数据源,实现动静路由的数据源，在每次数据库查问操作前执行它的形象办法 determineCurrentLookupKey() 决定应用哪个数据源。 ...

P6Spy简介 P6Spy是一个能够用来在应用程序中拦挡和批改数据操作语句的开源框架。通过P6Spy咱们能够对SQL语句进行拦挡，相当于一个SQL语句的记录器，这样咱们能够用它来作相干的剖析，比方性能剖析。 P6SPY提供了如下几个性能： \1. 记录SQL语句的执行工夫戳。 \2. 记录SQL语句类型。 \3. 记录SQL填入参数的和没有填入参数的SQL语句。 \4. 依据配置的工夫管制SQL语句的执行工夫，对超出工夫的SQL语句输入到日志文件中。 <!--more--> 配置步骤： <dependency> <groupId>p6spy</groupId> <artifactId>p6spy</artifactId> <version>3.9.1</version></dependency>01.将你的JDBC驱动替换为 # 批改 JDBC 驱动为如下 P6SpyDriver 配置# 之前为：# spring.datasource.driver-class-name=com.mysql.jdbc.Driverspring.datasource.driver-class-name=com.p6spy.engine.spy.P6SpyDriver02.批改spring.datasource.url # 留神是 jdbc:p6spy:mysqlspring.datasource.url=jdbc:p6spy:mysql://127.0.0.1:3306/test?useUnicode=true&characterEncoding=UTF-803.增加配置文件 spy.properties module.log=com.p6spy.engine.logging.P6LogFactory,com.p6spy.engine.outage.P6OutageFactory# 自定义日志打印,改成你自定义配置类的全类名logMessageFormat=com.kangqing.platform.aop.P6SpyLogger# 应用日志零碎记录sqlappender=com.p6spy.engine.spy.appender.Slf4JLogger## 配置记录Log例外excludecategories=info,debug,result,batc,resultset# 设置应用p6spy driver来做代理deregisterdrivers=true# 日期格局dateformat=yyyy-MM-dd HH:mm:ss# 理论驱动driverlist=com.mysql.jdbc.Driver# 是否开启慢SQL记录#outagedetection=true# 慢SQL记录规范 秒#outagedetectioninterval=204.自定义日志打印 （我喜爱这个性能）能够把 mybatis 占位符填进去，输出残缺的sql日志 /** * 自定义日志 * 默认com.p6spy.engine.spy.appender.SingleLineFormat * @author kangqing * @date 2020/9/7 10:58 */public class P6SpyLogger implements MessageFormattingStrategy { /** * 日志格局 * @param connectionId 连贯id * @param now 以后工夫 * @param elapsed 耗时多久 * @param category 类别 * @param prepared mybatis带占位符的sql * @param sql 占位符换成参数的sql * @param url sql连贯的 url * @return 自定义格局日志 */ @Override public String formatMessage(int connectionId, String now, long elapsed, String category, String prepared, String sql, String url) { return !"".equals(sql.trim()) ? "P6SpyLogger " + LocalDateTime.now() + " | elapsed " + elapsed + "ms | category " + category + " | connection " + connectionId + " | url " + url + " | sql \n" + sql : ""; }}附 ...

MySQL免装置配置下载安装包解压到工作目录 官网下载地址配置环境变量新建mysql配置文件ini [mysqld]#留神更改门路basedir="E:\mysql"datadir="E:\mysql\Data\"port=3306#跳过明码验证skip-grant-tables管理员模式下运行cmd命令，并将目录切换到mysql下的bin目录，而后输出mysqld -install（装置mysql）再输出mysqld --initialize-insecure --user=mysql初始化数据文件而后再次启动mysql服务，启动命令net start mysql，而后用命令mysql -u root -p进入mysql治理界面，明码可为空进入界面后更新明码，最初执行flush privileges刷新权限; --更新明码update mysql.user set authentication_string=password('123456') where user='root' and Host='localhost';--刷新权限flush privileges;批改明码胜利后删除my.ini文件中的跳过明码验证skip-grant-tables重启mysql #进行mysql服务net stop mysql#启动mysql服务net start mysql#清空MySQL服务命令，重装mysql执行sc delete mysql连贯胜利

下载yum repository wget https://dev.mysql.com/get/mysql57-community-release-el7-11.noarch.rpm装置yum repository yum -y localinstall mysql57-community-release-el7-11.noarch.rpm在线装置mysql yum -y install mysql-community-server批改配置 #cat /etc/my.cnf[mysqld]user=mysqlport=3306log-error=/var/log/mysqld.logpid-file=/var/run/mysqld/mysqld.pid#数据目录basedir=/data/mysqldatadir=/data/mysql/datasocket=/data/mysql/lib/mysql.sock#符号链接symbolic-links=0#设置最大连接数max_connections=1000#skip-grant-tablessql_mode =STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION#设置mysql默认字符集character-set-server=utf8collation-server=utf8_general_ci##开启binlog日志性能server-id=1log_bin=my-binbinlog_format = row##开启慢查问slow_query_log=ONslow_query_log_file=/var/lib/mysql/slow.loglong_query_time=1#敞开明码复杂度#validate_password=off #default_password_lifetime=0#表名不辨别大小写lower_case_table_names=1innodb_buffer_pool_instances=4#长期表大小tmp_table_size = 256Mmax_heap_table_size = 256M[client]socket=/data/mysql/lib/mysql.sock配置开机自启 systemctl start mysqld.servicesystemctl enable mysqld.service查看root用户默认生成的长期明码 grep "password" /var/log/mysqld.log应用默认明码登录mysql mysql -u root -p批改root明码 ALTER USER 'root'@'localhost' IDENTIFIED BY 'newpassword';flush privileges;附1：常用命令--创立用户CREATE USER 'username'@'host' IDENTIFIED BY 'password';--删除用户DROP USER 'username'@'host';--创立数据库CREATE DATABASE databasename;--删除数据库DROP DATABASE databasename;--用户受权GRANT privileges ON databasename.tablename TO 'username'@'host';--撤销用户权限REVOKE privilege ON databasename.tablename FROM 'username'@'host';#导出数据库mysqldump -u root -p --databases databasename >/root/databasename.sql#数据库单项同步（笼罩）mysqldump --host=sdbip --port=3306 -uroot -ppassword --set-gtid-purged=off --opt databasename | mysql --host=ddbip --port=3306 -uroot -ppassword -C databasename附2：重置明码进行服务 ...

常见相干问题数据库事务（ACID）原子性：事务是最小的执行单位，不容许宰割。事务的原子性确保动作要么全副实现，要么齐全不起作用； 一致性： 执行事务前后，数据保持一致，多个事务对同一个数据读取的后果是雷同的； 隔离性： 并发拜访数据库时，一个用户的事务不被其余事务所烦扰，各并发事务之间数据库是独立的； 持久性： 一个事务被提交之后。它对数据库中数据的扭转是长久的，即便数据库产生故障也不应该对其有任何影响。 什么是脏读？幻读？不可反复读？脏读(Drity Read)： 某个事务已更新一份数据，另一个事务在此时读取了同一份数据，因为某些起因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。 不可反复读(Non-repeatable read): 在一个事务的两次查问之中数据不统一，这可能是两次查问过程两头插入了一个事务更新的原有的数据。 幻读(Phantom Read): 在一个事务的两次查问中数据不统一，例如有一个事务查问了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查问中，就会发现有几列数据是它先前所没有的。 什么是事务的隔离级别？MySQL的默认隔离级别是什么？由低到高顺次为Read uncommitted、Read committed、Repeatable read、Serializable，这四个级别能够一一解决脏读、不可反复读、幻读这几类问题。 SQL 规范定义了四个隔离级别： · READ-UNCOMMITTED(读取未提交)： 最低的隔离级别，容许读取尚未提交的数据变更，可能会导致脏读、幻读或不可反复读。 · READ-COMMITTED(读取已提交)： 容许读取并发事务曾经提交的数据，能够阻止脏读，然而幻读或不可反复读仍有可能产生。 · REPEATABLE-READ(可反复读)： 对同一字段的屡次读取后果都是统一的，除非数据是被自身事务本人所批改，能够阻止脏读和不可反复读，但幻读仍有可能产生。 · SERIALIZABLE(可串行化)： 最高的隔离级别，齐全遵从ACID的隔离级别。所有的事务顺次一一执行，这样事务之间就齐全不可能产生烦扰，也就是说，该级别能够避免脏读、不可反复读以及幻读。 Mysql 默认采纳的 REPEATABLE_READ隔离级别 Oracle 默认采纳的 READ_COMMITTED隔离级别 数据库为什么应用B+树而不是B树· B树只适宜随机检索，而B+树同时反对随机检索和程序检索； · B+树空间利用率更高，可缩小I/O次数，磁盘读写代价更低。一般来说，索引自身也很大，不可能全副存储在内存中，因而索引往往以索引文件的模式存储的磁盘上。这样的话，索引查找过程中就要产生磁盘I/O耗费。B+树的外部结点并没有指向关键字具体信息的指针，只是作为索引应用，其外部结点比B树小，盘块能包容的结点中关键字数量更多，一次性读入内存中能够查找的关键字也就越多，绝对的，IO读写次数也就升高了。而IO读写次数是影响索引检索效率的最大因素； · B+树的查问效率更加稳固。B树搜寻有可能会在非叶子结点完结，越凑近根节点的记录查找时间越短，只有找到关键字即可确定记录的存在，其性能等价于在关键字选集内做一次二分查找。而在B+树中，程序检索比拟显著，随机检索时，任何关键字的查找都必须走一条从根节点到叶节点的路，所有关键字的查找门路长度雷同，导致每一个关键字的查问效率相当。 · B-树在进步了磁盘IO性能的同时并没有解决元素遍历的效率低下的问题。B+树的叶子节点应用指针程序连贯在一起，只有遍历叶子节点就能够实现整棵树的遍历。而且在数据库中基于范畴的查问是十分频繁的，而B树不反对这样的操作。 · 增删文件（节点）时，效率更高。因为B+树的叶子节点蕴含所有关键字，并以有序的链表构造存储，这样可很好进步增删效率。 B+树在满足聚簇索引和笼罩索引的时候不须要回表查问数据，在B+树的索引中，叶子节点可能存储了以后的key值，也可能存储了以后的key值以及整行的数据，这就是聚簇索引和非聚簇索引。 在InnoDB中，只有主键索引是聚簇索引，如果没有主键，则筛选一个惟一键建设聚簇索引。如果没有惟一键，则隐式的生成一个键来建设聚簇索引。 当查问应用聚簇索引时，在对应的叶子节点，能够获取到整行数据，因而不必再次进行回表查问。 什么是聚簇索引？何时应用聚簇索引与非聚簇索引· 聚簇索引：将数据存储与索引放到了一块，找到索引也就找到了数据 · 非聚簇索引：将数据存储于索引离开构造，索引构造的叶子节点指向了数据的对应行，myisam通过key_buffer把索引先缓存到内存中，当须要拜访数据时（通过索引拜访数据），在内存中间接搜寻索引，而后通过索引找到磁盘相应数据，这也就是为什么索引不在key buffer命中时，速度慢的起因

MySQL 的惟一索引(unique index)很好了解,就是这个索引的值是惟一的.惟一索引的相干文档和概念不多,只有记住"惟一"这个外围概念就行 这是MySQL Unique Indexes的官网原文 Unique IndexesA UNIQUE index creates a constraint such that all values in the index must be distinct. An error occurs if you try to add a new row with a key value that matches an existing row. If you specify a prefix value for a column in a UNIQUE index, the column values must be unique within the prefix length. A UNIQUE index permits multiple NULL values for columns that can contain NULL. ...

索引是利用程序设计和开发的一个重要方面。若索引太多，应用程序的性能可能会受到影响。而索引太少，对查问性能又会产生影响。要找到一个适合的平衡点，这对应用程序的性能至关重要。 B+树索引是InnoDB存储引擎传统意义上的索引，这是目前关系型数据库系统中查找最为罕用和最为无效的索引。B+树索引的结构相似于二叉树，依据键值（Key Value）疾速找到数据。 须要留神的是：B+树索引并不能找到一个给定键值的具体行，B+树索引能找到的只是被查找数据行所在的页。而后数据库通过把页读入到内存，再在内存中进行查找，最初失去要查找的数据。 B+树B+树是为磁盘或其余直接存取辅助设备设计的一种均衡查找树。在B+树中，所有记录节点都是按键值的大小程序寄存在同一层的叶子节点上，由各叶子节点指针进行连贯。先来看一个B+树，其高度为2，每页可寄存4条记录，扇出（fan out）为5，如图所示。 所有记录都在叶子节点上，并且是程序寄存的，如果用户从最右边的叶子节点开始程序遍历，能够失去所有键值的程序排序。 B+树的插入操作B+树的插入必须保障插入后叶子节点中的记录仍然排序，同时须要思考插入到B+树的三种状况，每种状况都可能会导致不同的插入算法。如表所示。 为了保持平衡对于新插入的键值可能须要做大量的拆分页（split）操作。因为B+树结构次要用于磁盘，页的拆分意味着磁盘的操作，所以应该在可能的状况下尽量减少页的拆分操作。因而，B+树同样提供了相似于均衡二叉树的旋转（Rotation）性能。 旋转产生在Leaf Page曾经满，然而其的左右兄弟节点没有满的状况下。这时B+树并不会急于去做拆分页的操作，而是将记录移到所在页的兄弟节点上。在通常状况下，左兄弟会被首先查看用来做旋转操作。 B+树的删除操作B+树应用填充因子（fill factor）来管制树的删除变动，50%是填充因子可设的最小值。B+树的删除操作同样必须保障删除后叶子节点中的记录仍然排序，同插入一样，B+树的删除操作同样须要思考以下表中的三种状况，与插入不同的是，删除依据填充因子的变动来掂量。 B+树索引B+树索引的实质就是B+树在数据库中的实现，B+索引在数据库中有一个特点是高扇出性。因而在数据库中，B+树的高度个别都在2～4层，这也就是说查找某一键值的行记录时最多只须要2到4次IO。因为以后个别的机械磁盘每秒至多能够做100次IO，2～4次的IO意味着查问工夫只需0.02～0.04秒。 数据库中的B+树索引能够分为汇集索引（clustered inex）和辅助索引（secondary index），然而不论是汇集还是辅助的索引，其外部都是B+树的，即高度均衡的，叶子节点寄存着所有的数据。汇集索引与辅助索引不同的是，叶子节点寄存的是否是一整行的信息。 汇集索引汇集索引（clustered index）就是依照每张表的主键结构一棵B+树，同时叶子节点中寄存的即为整张表的行记录数据，也将汇集索引的叶子节点称为数据页。 因为理论的数据页只能依照一棵B+树进行排序，因而每张表只能领有一个汇集索引。在少数状况下，查问优化器偏向于采纳汇集索引。因为汇集索引可能在B+树索引的叶子节点上间接找到数据。此外，因为定义了数据的逻辑程序，汇集索引可能特地快地拜访针对范畴值的查问。查问优化器可能疾速发现某一段范畴的数据页须要扫描。 汇集索引的存储并不是物理上间断的，而是逻辑上间断的。这其中有两点：一是后面说过的页通过双向链表链接，页依照主键的程序排序；另一点是每个页中的记录也是通过双向链表进行保护的，物理存储上能够同样不依照主键存储。 汇集索引的另一个益处是，它对于主键的排序查找和范畴查找速度十分快。叶子节点的数据就是用户所要查问的数据。 辅助索引对于辅助索引（Secondary Index，也称非汇集索引），叶子节点并不蕴含行记录的全副数据。叶子节点除了蕴含键值以外，每个叶子节点中的索引行中还蕴含了一个书签（bookmark）。该书签用来通知InnoDB存储引擎哪里能够找到与索引绝对应的行数据。因为InnoDB存储引擎表是索引组织表，因而InnoDB存储引擎的辅助索引的书签就是相应行数据的汇集索引键。 B+树索引的治理索引治理索引的创立和删除能够通过两种办法，一种是ALTER TABLE，另一种是CREATE/DROP INDEX。通过ALTER TABLE创立索引的语法为： ALTER TABLE tbl_name ADD {INDEX|KEY} [index_name] [index_type] (index_col_name,...) [index_option] ...ALTER TABLE tbl_name DROP PRIMARY KEY | DROP {INDEX|KEY} index_nameCREATE/DROP INDEX的语法同样很简略： CREATE [UNIQUE] INDEX index_name [index_type] ON tbl_name (index_col_name,...)DROP INDEX index_name ON tbl_name用户能够设置对整个列的数据进行索引，也能够只索引一个列的结尾局部数据。 若用户想要查看表中索引的信息，能够应用命令SHOW INDEX，命令SHOW INDEX后果中每列的含意如下： ...

参数文件当MySQL实例启动时，数据库会先去读一个配置参数文件，用来寻找数据库的各种文件所在位置以及指定某些初始化参数，这些参数通常定义了某种内存构造有多大等。在默认状况下，MySQL实例会依照肯定的程序在指定的地位进行读取，用户只需通过命令mysql --help | grep my.cnf来寻找即可。 简略地说，能够把数据库参数看成一个键/值（key/value）对。能够通过命令SHOWVARIABLES查看数据库中的所有参数，也能够通过LIKE来过滤参数名。从MySQL5.1版本开始，还能够通过information_schema架构下的GLOBAL_VARIABLES视图来进行查找。 MySQL数据库中的参数能够分为两类：动静（dynamic）参数和动态（static）参数。动静参数意味着能够在MySQL实例运行中进行更改，动态参数阐明在整个实例生命周期内都不得进行更改，就如同是只读（read only）的。 能够通过SET命令对动静的参数值进行批改，global和session关键字表明该参数的批改是基于以后会话还是整个实例的生命周期。有些动静参数只能在会话中进行批改，如autocommit；而有些参数批改完后，在整个实例生命周期中都会失效，如binlog_cache_size；而有些参数既能够在会话中又能够在整个实例的生命周期内失效，如read_buffer_size。 须要留神的是，对变量的全局值进行了批改，在这次的实例生命周期内都无效，但MySQL实例自身并不会对参数文件中的该值进行批改。也就是说，在下次启动时MySQL实例还是会读取参数文件。若想在数据库实例下一次启动时该参数还是保留为以后批改的值，那么用户必须去批改参数文件。要想晓得MySQL所有动静变量的可批改范畴，能够参考MySQL官网手册的DynamicSystem Variables的相干内容。 注：在mysql8中，能够通过set persist命令来长久化对全局变量的批改。 日志文件谬误日志谬误日志文件对MySQL的启动、运行、敞开过程进行了记录。MySQL DBA在遇到问题时应该首先查看该文件以便定位问题。该文件不仅记录了所有的错误信息，也记录一些正告信息或正确的信息。用户能够通过命令SHOW VARIABLES LIKE'log_error'来定位该文件。 慢查问日志慢查问日志（slow log）可帮忙DBA定位可能存在问题的SQL语句，从而进行SQL语句层面的优化。例如，能够在MySQL启动时设一个阈值，将运行工夫超过该值的所有SQL语句都记录到慢查问日志文件中。DBA每天或每过一段时间对其进行查看，确认是否有SQL语句须要进行优化。 无关慢查问的一些配置项如下： slow_query_log：指定是否开启慢查问日志log_slow_queries：指定是否开启慢查问日志(该参数要被slow_query_log取代，做兼容性保留)long_query_time：设定慢查问的阈值，超出次设定值的SQL即被记录到慢查问日志，缺省值为10s（从MySQL 5.1开始，long_query_time开始以微秒记录SQL语句运行的工夫）slow_query_log_file：指定慢日志文件寄存地位，能够为空，零碎会给一个缺省的文件host_name-slow.logmin_examined_row_limit：查问查看返回少于该参数指定行的SQL不被记录到慢查问日志log_queries_not_using_indexes: 不应用索引的查问是否记录到慢查问日志log_throttle_queries_not_using_indexes: 每分钟记录到日志的未应用索引的语句数目，超过这个数目后只记录语句数量和破费的总工夫log_output: 慢查问日志的存储形式，默认值是'FILE'，设为'TABLE'示意将日志存入数据库，这样日志信息就会被写入到mysql.slow_log表中查问日志查问日志记录了所有对MySQL数据库申请的信息，无论这些申请是否失去了正确的执行。默认文件名为：主机名.log，从MySQL 5.1开始，能够将查问日志的记录放入mysql架构下的general_log表中。 二进制日志二进制日志（binary log）记录了对MySQL数据库执行更改的所有操作，然而不包含SELECT和SHOW这类操作，因为这类操作对数据自身并没有批改。 如果用户想记录SELECT和SHOW操作，那只能应用查问日志，而不是二进制日志。此外，二进制日志还包含了执行数据库更改操作的工夫等其余额定信息。总的来说，二进制日志次要有以下几种作用： 复原（recovery）：某些数据的复原须要二进制日志，例如，在一个数据库全备文件复原后，用户能够通过二进制日志进行point-in-time的复原。复制（replication）：其原理与复原相似，通过复制和执行二进制日志使一台近程的MySQL数据库（个别称为slave或standby）与一台MySQL数据库（个别称为master或primary）进行实时同步。审计（audit）：用户能够通过二进制日志中的信息来进行审计，判断是否有对数据库进行注入的攻打。通过配置参数log-bin[=name]能够启动二进制日志。如果不指定name，则默认二进制日志文件名为主机名，后缀名为二进制日志的序列号，所在门路为数据库所在目录（datadir）。 以下配置文件参数影响着二进制日志记录的信息和行为： max_binlog_sizebinlog_cache_sizesync_binlogbinlog-do-dbbinlog-ignore-dblog-slave-updatebinlog_format参数max_binlog_size指定了单个二进制日志文件的最大值，如果超过该值，则产生新的二进制日志文件，后缀名+1，并记录到.index文件。 当应用事务的表存储引擎（如InnoDB存储引擎）时，所有未提交（uncommitted）的二进制日志会被记录到一个缓存中去，等该事务提交（committed）时间接将缓冲中的二进制日志写入二进制日志文件，而该缓冲的大小由binlog_cache_size决定，默认大小为32K。此外，binlog_cache_size是基于会话（session）的，也就是说，当一个线程开始一个事务时，MySQL会主动调配一个大小为binlog_cache_size的缓存，因而该值的设置须要相当小心，不能设置过大。当一个事务的记录大于设定的binlog_cache_size时，MySQL会把缓冲中的日志写入一个临时文件中，因而该值又不能设得太小。通过SHOW GLOBALSTATUS命令查看binlog_cache_use、binlog_cache_disk_use的状态，能够判断以后binlog_cache_size的设置是否适合。binlog_cache_use记录了应用缓冲写二进制日志的次数，binlog_cache_disk_use记录了应用临时文件写二进制日志的次数。 在默认状况下，二进制日志并不是在每次写的时候同步到磁盘（用户能够了解为缓冲写）。因而，当数据库所在操作系统产生宕机时，可能会有最初一部分数据没有写入二进制日志文件中，这会给复原和复制带来问题。参数sync_binlog=[N]示意每写缓冲多少次就同步到磁盘。如果将N设为1，即sync_binlog=1示意采纳同步写磁盘的形式来写二进制日志，这时写操作不应用操作系统的缓冲来写二进制日志。sync_binlog的默认值为0，如果应用InnoDB存储引擎进行复制，并且想得到最大的高可用性，倡议将该值设为ON。 然而，即便将sync_binlog设为1，还是会有一种状况导致问题的产生。当应用InnoDB存储引擎时，在一个事务收回COMMIT动作之前，因为sync_binlog为1，因而会将二进制日志立刻写入磁盘。如果这时曾经写入了二进制日志，然而提交还没有产生，并且此时产生了宕机，那么在MySQL数据库下次启动时，因为COMMIT操作并没有产生，这个事务会被回滚掉。然而二进制日志曾经记录了该事务信息，不能被回滚。这个问题能够通过将参数innodb_support_xa设为1来解决，尽管innodb_support_xa与XA事务无关，但它同时也确保了二进制日志和InnoDB存储引擎数据文件的同步。 注：二进制日志的写入机会是事务语句实现的时候，此时还未真正执行commit和开释锁。 Binary logging is done immediately after a statement or transaction completes but before any locks are released or any commit is done. This ensures that the log is logged in commit order.参数binlog-do-db和binlog-ignore-db示意须要写入或疏忽写入哪些库的日志。默认为空，示意须要同步所有库的日志到二进制日志。 ...

Redo log（Innodb存储引擎的日志文件）redo log通常是物理日志，记录的是数据页的物理批改，用来复原提交后的数据页，且只能复原到最初一次提交的地位，即前滚。redo log保障了Mysql的持久性（Durability）。 Redo log的运行原理redo log分为两局部，一是内存中的缓冲日志（redo log buffer），该局部是易失性的，二是磁盘上的重做日志（redo log file），该局部是长久的。 当事务提交的时候，Innodb存储引擎会先把日志写入内存中缓冲区(redo log buffer),而后写入到OS Buffer，此时事务就算是完结了，而后Innodb会在适合的机会将日志同步（fsync）到磁盘中的redo log file中，这时，就算数据库产生异样重启，Mysql也会从redo log file中将数据恢复，保障了事务的Durability。ps：redo log file是固定大小的， 是一个循环写的过程 Mysql提供了三种形式将redo log buffer中日志刷到redo log file，能够通过设置innodb_flush_log_at_trx_commit来决定当设置为0时，事务提交时不会将log buffer中的日志写入到os buffer，而是每秒写入os buffer并调用fsync()同步到log file中。如果零碎解体，会失落1秒钟的数据。当设置为1时，事务提交时会间接将log buffer中的日志写入到os buffer，同时调用fsync()同步到log file中。这种形式，即便零碎解体，也不会产生数据失落，然而IO性能较差。当设置为2时，事务提交时会间接将log buffer中的日志写入到os buffer，而后每秒调用一次fsync()同步到log file中。如果零碎解体，也会失落1秒钟的数据。

连接器连接器负责跟客户端建设连贯，获取权限，维持和治理连贯1.用户明码验证2.查问权限信息，调配相应权限3.能够应用show processlist查看当初的连贯4.如果太长时间没有应用，就会主动断开，通过wait_timeout管制，默认8小时 连贯能够分为长连贯和短连贯查问缓存当执行查问语句的时候，会先去查问缓存中查看后果，之前执行过的sql语句及其后果以key-value的模式存储在缓存中，如果能找到则间接返回，如果找不到，就继续执行后续的阶段 然而不举荐应用查问缓存1.查问缓存的生效比拟频繁，只有表更新，缓存就会清空2.缓存对应更新的数据命中率比拟低 分析器1.词法剖析：Mysql须要把输出的字符串进行辨认每个局部代表什么意思。比方：把字符串T辨认为表名T，把字符串ID辨认为列名ID。2.语法分析：依据语法规定这条sql是否满足Mysql语法，如果不合乎就会报错。 优化器1.在具体执行sql语句之前，要先进行优化器的解决，比方：当表中有多个索引的时候，决定用哪个索引，当sql语句须要做多表关联时，决定表的链接程序。2.不同的执行形式对sql语句的执行效率影响很大RBO：基于规定的优化CBO：基于老本的优化 执行器操作引擎，返回后果 存储引擎存储数据，提供读写接口

前言： 在 MySQL 中，零碎反对诸多字符集，不同字符集之间也略有区别。目前最罕用的字符集应该是 utf8 和 utf8mb4 了，相比于 utf8 ，utf8mb4 反对存储 emoji 表情，应用范畴更广。本篇文章将会介绍 utf8 批改成 utf8mb4 字符集的办法。 1. utf8 和 utf8mb4 字符集介绍字符（Character）是各种文字和符号的总称，包含各国家文字、标点符号、图形符号、数字等。字符集（Character set）是多个字符的汇合。 MySQL 中字符集能够作用于四个级别，别离是：服务器级别、数据库级别、表级别、列级别。服务器级别的比拟规定由 character_set_server 参数管制，如果创立数据库、表、列时没有显式的指定字符集，则会继承上一级的字符集。 MySQL 5.7 及之前版本默认的字符集是 latin1 ，MySQL 8.0 版本默认的字符集是 utf8mb4 。不过应用 latin1 容易导致乱码，所以还是 utf8 和 utf8mb4 用处最宽泛。utf8 其实是 utf8mb3 的别名，只应用 1～3 个字节示意字符。utf8mb4 应用 1～4 个字节示意字符，可能存储更多的 emoji 表情及任何新增的 Unicode 字符。utf8mb4 兼容 utf8 ，且比 utf8 能示意更多的字符，是 utf8 字符集的超集。所以当初一些新的业务倡议将数据库的字符集设置为 utf8mb4 ，特地是有表情存储需要时。 2. 批改字符集办法目前的互联网业务对 emoji 表情存储的需要越来越多，比方昵称、评论内容等都要反对表情符号，这个时候如果数据库字段用的是 utf8 字符集，则会报如下谬误：java.sql.SQLException: Incorrect string value: '\xF0\x9F\x92\x95\xF0\x9F...' for column………… ...

在Web应用程序体系架构中，数据长久层（通常是一个关系数据库）是要害的外围局部，它对系统的性能有十分重要的影响。 MySQL是目前应用最多的开源数据库，然而MySQL数据库的默认设置性能十分的差，仅仅是一个玩具数据库。因而在产品中应用MySQL数据库必须进行必要的优化。 优化是一个简单的工作，包含MySQL相干的数据库设计和查问优化、服务器端优化、存储引擎优化等等方面。 最近很多小伙伴问我要一些 mysql 相干的材料，于是我翻箱倒柜，找到了这本十分经典的电子书——《高性能MySQL》。 材料介绍《高性能MySQL》内容涵盖MySQL架构和历史，基准测试和性能分析，数据库软硬件性能优化，复制、备份和复原，高可用与高可扩展性，以及云端的MySQL和MySQL相干工具等方面的内容。每一章都是绝对独立的主题，读者能够有选择性地独自浏览。本书岂但适宜数据库管理员浏览，也适宜开发人员参考学习。不论是数据库老手还是专家，置信都能从中有所播种。 如何获取？1.辨认二维码并关注公众号「Java后端技术全栈」； 2.在公众号后盾回复关键字「939」。

MariaDB ColumnStore专为大数据扩大而设计，可解决PB级数据，线性可伸缩性和杰出的性能，并能对剖析查问进行实时响应。 它利用列式存储，压缩，即时投影以及程度和垂直分区的I / O劣势在剖析大型数据集时提供了杰出的性能。（这是官网的介绍，https://mariadb.com/kb/en/mariadb-columnstore/） 自己自研发了一个mysql -> mariadb columnStore同步工具，同时反对全量同步和增量同步模式，github地址：https://github.com/yutianyong125/mcs_etl 接下来演示一下同步过程 下载该我的项目 git clone https://github.com/yutianyong125/mcs_etl.gitcd mcs_etl启动mysql，不便起见，这里应用docker，仅测试，不思考数据挂载问题，这里我把secure-file-priv配置的目录挂载进去，是为了导入数据的时候用到，另须要指定应用自定义的mysql配置文件 vim /tmp/conf.d/my.cnf# 保留为以下配置[mysqld]log_bin = mysql_bin # 开启binlog日志并指定binlog日志命名前缀binlog_format=ROW # 指定binlog格局server_id = 1 # 指定master server_idsecure_file_priv=/tmp/mysql-files # SELECT INTO OUTFILE 语句须要开启这个配置mkdir /tmp/mysql-files # 先创立好寄存导出数据的文件夹docker run --rm -d --name mysql -v /tmp/conf.d:/etc/mysql/conf.d -v /tmp/mysql-files:/tmp/mysql-files -e MYSQL_ROOT_PASSWORD=123456 -p 3306:3306 mysql:5.7 --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci --secure-file-priv=/tmp/mysql-files应用存储过程增加测试数据 -- 创立test库create database test;use test;-- 创立user表CREATE TABLE user( id INT NOT NULL AUTO_INCREMENT, uname VARCHAR(20) NOT NULL, sex VARCHAR(5) NOT NULL, score INT NOT NULL, copy_id INT NOT NULL, PRIMARY KEY (`id`)) ENGINE=INNODB CHARSET=utf8;-- 存储过程插入10万条数据DROP PROCEDURE IF EXISTS add_user; DELIMITER // create PROCEDURE add_user(in num INT) BEGIN DECLARE rowid INT DEFAULT 0; DECLARE firstname CHAR(1); DECLARE name1 CHAR(1); DECLARE name2 CHAR(1); DECLARE sex CHAR(1); DECLARE score CHAR(2); DECLARE uname CHAR(3); WHILE rowid < num DO SET firstname = SUBSTRING('赵钱孙李周吴郑王林杨柳刘孙陈江阮侯邹高彭徐',FLOOR(1+21*RAND()),1); SET name1 = SUBSTRING('一二三四五六七八九十甲乙丙丁静景京晶名明铭敏闵民军君俊骏天田甜兲恬益依成城诚立莉力黎励',ROUND(1+43*RAND()),1); SET name2 = SUBSTRING('一二三四五六七八九十甲乙丙丁静景京晶名明铭敏闵民军君俊骏天田甜兲恬益依成城诚立莉力黎励',ROUND(1+43*RAND()),1); SET sex=FLOOR(0 + (RAND() * 2)); SET score= FLOOR(40 + (RAND() *60)); SET rowid = rowid + 1; SET uname = CONCAT(firstname,name1,name2); insert INTO user (uname,sex,score,copy_id) VALUES (uname,sex,score,rowid); END WHILE; END //DELIMITER ;call add_user(100000);-- 创立test1库create database test1;use test1;-- 创立表t1CREATE TABLE `t` ( `id` int(11) NOT NULL, `a` int(11) DEFAULT NULL, `b` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `a` (`a`), KEY `b` (`b`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;-- 存储过程插入数据delimiter //create procedure idata()begin declare i int; set i=1; while(i<=100000)do insert into t values(i, i, i); set i=i+1; end while;end //delimiter ;call idata();启动mariadb columnStore ...

P.S. 基于mysql 5.6，数据库引擎是 InnoDB 解决方案：1 、应用INSERT ... ON DUPLICATE KEY UPDATE Statement 语法；官网手册地址2、 应用REPLACE statement 官网手册地址3、逻辑层解决，先判断是否存在记录，有则批改数据而后提交（删除而后插入），否则直接插入 计划一详解1、语法 INSERT ... ON DUPLICATE KEY UPDATE ...2、例子 INSERT INTO t1 (a,b,c) VALUES (1,2,3) ON DUPLICATE KEY UPDATE c=c+1;3、阐明 如果数据库表t1的字段a 为主键(Primary key)或者惟一索引(Unique Index)，则下面的操作在遇到数据库曾经存在a=1的状况下，则会进行c自增1的成果，否则就是插入一条记录。如果是插入一条新记录，则影响的行记录数量是1；如果是更新，则返回的是2；没有变动则返回0。如果a的属性是AUTO INCREMENT，则LAST_INSERT_ID()办法获取到的是自增值（AUTO_INCREMENT VALUE），而不是影响的行数。UPDATE 前面可更新多个字段，他们用英文逗号宰割。UPDATE 前面的赋值表达式，能够应用values(col_name)函数获取到INSERT字段插入的值：INSERT INTO t1 (a,b,c) VALUES (1,6,3) ON DUPLICATE KEY UPDATE c=VALUES(a)+VALUES(b);如果，数据库中曾经存在a=1的记录，那么c=1+6，用values(col_name)获取col_name字段欲被调配的值，从而防止duplicate-key conflict。 DELAYED选项在这个语句中有效。计划二详解1、语法 REPLACE [LOW_PRIORITY | DELAYED] [INTO] tbl_name [PARTITION (partition_name [, partition_name] ...)] [(col_name [, col_name] ...)] {VALUES | VALUE} (value_list) [, (value_list)] ...REPLACE [LOW_PRIORITY | DELAYED] [INTO] tbl_name [PARTITION (partition_name [, partition_name] ...)] SET assignment_listREPLACE [LOW_PRIORITY | DELAYED] [INTO] tbl_name [PARTITION (partition_name [, partition_name] ...)] [(col_name [, col_name] ...)] SELECT ...value: {expr | DEFAULT}value_list: value [, value] ...assignment: col_name = valueassignment_list: assignment [, assignment] ...2、例子 ...

接着上篇文章Mysql InnoDB&MyISAM 反对Hash么,咱们晓得InnoDB是不反对HASH的,然而有个Adaptive Hash的概念让InnoDB在 原文如下adaptive hash index: adaptive hash indexAn optimization for InnoDB tables that can speed up lookups using = and IN operators, by constructing a hash index in memory. MySQL monitors index searches for InnoDB tables, and if queries could benefit from a hash index, it builds one automatically for index pages that are frequently accessed. In a sense, the adaptive hash index configures MySQL at runtime to take advantage of ample main memory, coming closer to the architecture of main-memory databases. This feature is controlled by the innodb_adaptive_hash_index configuration option. Because this feature benefits some workloads and not others, and the memory used for the hash index is reserved in the buffer pool, typically you should benchmark with this feature both enabled and disabled. ...

MySQL InnoDB&MyISAM 反对Hash么咱们在应用MySQL的时候,对于索引的数据类型,应用的最多的就是HASH和BTREE. 很多开发人员很有教训的会在创立某些字段的索引的时候通知MySQL的存储引擎:应用HASH !. 我一段时间也是这样胸有成竹的依照这个实践抉择索引类型的: 如果是准确的equals比拟查问,那么就应用HASH,如果应用范畴查问和大小比拟查问那么最好应用BTREE. 因为以前的开发经验就是性能开发为主,对具体的细节不是很在意,个别MySQL也能满足需要,所以我天真的认为既然建表语句能够指定HASH而且没有报正告和谬误,那么这个索引的底层数据结构必定是HASH,而后我就释怀的应用equals准确查问数据了.直到有一天我看到MySQL的官网文档,才对这个产生粗浅的反思. 原文如下: Most MySQL indexes (PRIMARY KEY, UNIQUE, INDEX, and FULLTEXT) are stored in B-trees. Exceptions: Indexes on spatial data types use R-trees; MEMORY tables also support hash indexes; InnoDB uses inverted lists for FULLTEXT indexes.什么? 绝大多少MySQL index是BTREE?除了空间地位数据应用了RTREE以及MEMORY TABLE以及应用倒排列表的FULLTEXT indexes? InnoDB 官网解读而后我马上查看了InnoDB的文档: 发现InnoDB其实是不反对HASH索引的,然而它能够应用称为Adaptive Hash的技术来在表象上反对HASH. 这也就是我为什么以前应用InnoDB引擎并指定index类型为HASH的来建表并执行SQL的时候,性能仍然看起来失常的实质起因. MyISAM 官网解读我持续查看了MyISAM的文档: 那么很遗憾,MyISAM也是不反对Hash的.而且MyISAM也不反对相似InnoDB的Adaptive Hash的技术来在表象上反对HASH. 所以咱们得出结论: MyISAM和InnoDB 不反对HASHInnoDB能够应用Adaptive Hash来间接反对HASHMEMOEY能力同时反对HASH和BTREE咱们在建表时给某些字段增加hash索引,或者前期为某表增加hash索引时,如果他们的存储引擎为InnoDB或MyISAM,则sql脚本自身是不会报错的,然而咱们会发现,该hash索引字段的index_type依然为BTREE.这其实是MySQL为了关照应用习惯而做到一些非凡解决,其实底层会疏忽你指定索引为HASH的逻辑,仍然应用BTREE 理论验证本次我应用MySQL8作为测试环境,通过理论的代码操作做理论的论证. InnDB验证CREATE TABLE index_type_test ( `id` INT NOT NULL AUTO_INCREMENT, `name` VARCHAR(32) NULL, PRIMARY KEY (`id`), UNIQUE INDEX `name_UNIQUE` using hash(name)) ENGINE = InnoDB;而后咱们查问这个表的索引类型: ...

恐怖于一眼到底的人生放弃教职退出微软2005年，谢映莲实现卡内基梅隆计算机专业的博士学位，开始纠结于将来抉择。 卡内基梅隆位于美国匹兹堡，是计算机工业最后的推动者之一，计算机专业排名高居全美第二。有别于硅谷“技术创新+商业模式+金融资本”形成的自在气氛，匹兹堡的空气中弥漫着Old-School的激进醇香，“留在学界取得教职是更被尊敬的抉择，不能留在学校的人才会思考进入工业界。谷歌最晚期的员工中有一位就是我导师带过的学生，他在商业畛域获得了巨大成就，但导师始终很遗憾没能留住他任教”。在这样的气氛陶冶之下，谢映莲也拿到了一些大学的教职录取资格，但她迟迟没有下定决心：“一方面，我心愿做学术研究，学院体系外部有着低劣的学术环境；可另一方面，教职这条路一眼看失去头，做钻研、发paper、拿到一生教职、做一辈子钻研、发一辈子paper……一毕业就能看到本人退休的样子，这让我有些胆怯。” 最终，谢映莲做出了一个绝对折衷的抉择：在泛滥邀请中抉择退出位于硅谷的微软研究院，“做学术研究、技术钻研的同时，也能近距离察看工业界的运行模式。” “稳固”与“可能性”，每个人成长过程中都要面临的选择题，谢映莲抉择了后者。这份发自心底的自信与好奇心，注定她日后会走上守业之路。但在当年走进微软研究院的她，对本人的定位还是一位学术研究者，在那里，她的30多位共事无一不是计算机某一畛域内的顶级大牛，仅图灵奖得主就有三人。 让人意想不到的是，大牛、巨佬环伺之下，这位被共事视作初丁的年轻人，迅速折腾出了一份微小的声浪。 遇见世界上另一个本人微软经验奠定守业坚实基础谢映莲对微软研究院有两个粗浅的第一印象，“一是拿着螺丝刀给你装机器的人，是整个团队的director；二是他不负责指派工作，要自力更生，每个人都要找到本人感兴趣的我的项目去做”。 进入微软的第一个月，谢映莲先是尝试与团队的多位前辈大牛进行沟通，发现他们正在进行的我的项目并非本人志趣所在。也正是在这段时间里，她意外播种了本人的灵魂伴侣、至交好友，也是日后的守业搭档，同样来自江苏的俞舫。二人趣味、背景靠近，略一商议，决定单干创建一个网络信息安全我的项目。 这一决定最后并不被团队内的前辈与共事看好，大家很友善地揭示她们，团队里有很多位资格极深、位置极高的巨咖，能够学习一下再思考独立，但谢俞二人情意已决，我的项目旋即启动。 出乎众人预料，仅仅半年之后，她们单干的论文便以极高的初审分数、“没有通过强烈的答辩探讨”便被寰球顶级会议SIGCOMM收录，谢俞搭档在短短工夫内获得了显著成绩令共事们另眼相看，“对于新退出的共事，大家本能地会察看一段时间，但只有你能展现出足够的能力，大家便会发自内心的恭喜并尊重你”。 接下来7年，谢俞团队将大数据与大规模并行计算算法相结合，围绕“新的并行计算算法为平安反欺诈畛域带来的变革”这一命题发表了大量论文，逐步打造出了一套兼具技术外围竞争力和利用场景价值的数据智能体系。 除了在学术畛域一直精进，在这7年工夫里，谢映莲和俞舫还锤炼出了相当不俗的沟通、推广等能力，“我的项目做大了，要寻找可能解决理论问题、有意义的课题，须要跟微软外部不同产品部门的共事打交道，要本人招实习生、创立和高校的单干……微软每年还有一个展会，研究院的各个项目组要向微软的工业体系介绍本人的我的项目，实质上是一次市场推广。当初想起来，在微软研究院这7年中造就了本人多方面的能力，比方沟通能力、单干能力、技术与商业价值场景联合的思维能力等等。” 强劲地向上成长，同时也一直刺激着外在自我认知的沉睡，谢映莲越来越分明地意识到，钻研畛域与工业畛域在很多中央存在显著脱节，她的趣味逐步从学术我的项目转向思考科技如何为工业界产生价值，怎样才能缩短工业界落地产品与最顶尖科技之间的间隔、让技术落地。 显然，实现这一愿景不能只靠发论文、做我的项目，谢映莲不得不正视一个事实：微软研究院体系曾经无奈承载本人的幻想。在研究院的最初两年中，一面是难以施展抱负的冤屈，一面是外界一直抛来的橄榄枝，许多公司找到谢俞团队——包含Yelp，询问“把数据给你们，心愿你们帮忙剖析”的可能性。 “持续从事科研，无非是一年再发几篇paper，这对咱们的吸引力曾经没有那么强了，我置信咱们能够做更大的事件，这种想法，促使咱们彻底迈出守业这一步。” 2013年感恩节，谢映莲、俞舫辞别微软研究院。 没有投资、没有产品、没有团队，甚至没有一份成型的商业计划书——彻底到不能再彻底的裸辞。 守业第一个冬天被跳闸暖气冻伤的激情2013年，DataVisor创立，次年成为陌陌的网络安全服务商。 2015年9月，DataVisor实现一轮来自金沙江创投和恩颐投资（NEA）的融资。 2016年，滴滴投资人彭志坚定定投资DataVisor，谢映莲第一反馈“咱们不须要融钱”……随后被压服，并决定正式进军中国市场。 2016年底，DataVisor分公司在北京成立，不到一年工夫内先后与安全银行、京东、财付通、公众点评、阿里巴巴、陌陌等企业达成服务协定。 2018年，华尔街评比寰球25家最具后劲初创，DataVisor 赫然在列。 2019年，DataVisor在2019网络安全卓越大奖斩获六项大奖，谢映莲被评为网络安全北美“年度女性”金奖。 看着这条大跨步向前的倒退工夫线，让人不免好奇：2013年的那个冬天到底产生了什么事，让DataVisor可能从没钱、没人、没产品的三无状态迅速启动？ 大洋彼岸的痛快笑声自听筒传来：“其实咱们那个冬天过得并不容易，守业是一件庄重的事件，守业起步还是十分艰辛的一个过程。” 谢俞二人的守业构想之简略，能够用“天真”来形容：“找一个能静下心思考事件的办公室，偏一点也好。不焦急招很大的团队，先找客户，有客户明确动向买单了再思考融资和下一步。尽管对守业没有特地具体的构想，但就是想做这件事件，之前也有一些表白过动向的客户，还有口头打招呼想投资的敌人，让咱们对这件事件多少有些信念。” 2013年冬天，旧金山多雨。在研究院那些年里，谢俞出差常去西雅图，对通往旧金山的路线并不相熟，偶然出行也以火车为交通工具。可独立守业之后，为了尽量多的面见客户，二人不得不一次次顶风冒雨驱车返回，“把咱们累得够呛。” 遗憾的是，客户反馈与她们的期待落差甚大，“即使之前示意过趣味，可一看你们就两个人、什么都没有，大家难免会放心，其实能够了解。那时算是真正领会到了，事业起步阶段客户这一关真的不容易过。” “在见客户的同时，有一位在一家大企业供职的敌人说比拟看好咱们的货色，没准他的公司能够把咱们收买了。我和俞舫一核计，两个人从微软研究院进去是为了做一番事业，不是为了马上再去另一个大公司，这条路咱们不思考。” 屋漏偏逢连夜雨，便宜租来的办公室也跟着添乱，暖气、电脑一起用肯定跳闸，要工作就不能开暖气，要温暖就得关电脑……两位习惯了微软研究院舒服环境的IT巾帼豪杰，面对守业之初的艰辛与挫折，动摇推动着幻想。在旧金山冬雨的午后，她们搓着手、哈着气写下代码、构建模式，微笑着彼此激励，乐观拥抱所有的不顺遂、不尽意，不为外界的烦扰所波动。 生存总是处分自信的强人。2014年初，旧金山一家咖啡店，谢映莲俞舫见到了陌陌创始人唐岩夫妇。对于这次见面她起初并没有抱太大心愿，可唐岩夫妇却展现出了莫大的诚意与激情。彼时的陌陌曾经呈现成规模的欺诈景象，用户的迅猛增长使陌陌变成了被守法份子攻打的优选对象，而陌陌技术团队的注意力聚焦应答产品迅猛增长之上，没有余力解决平安问题。DataVisor利用无监督学习技术辨认用户行为、预防欺诈等无害行为产生的技术计划，恰好与陌陌的需要完满符合。 客户到位的同时，融资与团队招募也获得了重大进展。谢俞二人的声名与学术成就吸引来了不少投资商， 同时随着数位技术大牛加盟团队，DataVisor冲破了初创阶段，进入倒退快车道。 DataVisor的工作并非微软期间钻研的连续，但“推动科技进步”的使命感与翻新精力一脉相承，这种翻新精力七年间继续鼓励谢、俞二人在钻研畛域实现重大突破，并被她们带入到DataVisor，继续推动团队放弃科技前沿程度。 继续翻新的同时，DataVisor也非常重视工业界影响力，重视造就将新技术工业化并带向市场的转化能力。 “DataVisor团队的使命就是要把最前沿的科技带到工业界，这也是DataVisor和其余公司的区别之处——继续翻新。比方特斯拉，也是在翻新的同时又实实在在为工业界作出价值”。

复制概述Mysql内建的复制性能是构建大型，高性能应用程序的根底。将Mysql的数据分布到多个零碎下来，这种散布的机制，是通过将Mysql的某一台主机的数据复制到其它主机（slaves）上，并从新执行一遍来实现的。复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并保护文件的一个索引以跟踪日志循环。这些日志能够记录发送到从服务器的更新。当一个从服务器连贯主服务器时，它告诉主服务器从服务器在日志中读取的最初一次胜利更新的地位。从服务器接管从那时起产生的任何更新，而后封闭并期待主服务器告诉新的更新。 请留神当你进行复制时，所有对复制中的表的更新必须在主服务器上进行。否则，你必须要小心，以防止用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的抵触。 mysql反对的复制类型： 基于语句的复制：在主服务器上执行的SQL语句，在从服务器上执行同样的语句。MySQL默认采纳基于语句的复制，效率比拟高。一旦发现没法准确复制时，   会主动选着基于行的复制。基于行的复制：把扭转的内容复制过来，而不是把命令在从服务器上执行一遍. 从mysql5.0开始反对混合类型的复制: 默认采纳基于语句的复制，一旦发现基于语句的无奈准确的复制时，就会采纳基于行的复制。复制解决的问题 MySQL复制技术有以下一些特点： 数据分布 (Data distribution )负载平衡(load balancing)备份(Backups)高可用性和容错行 High availability and failover复制如何工作 整体上来说，复制有3个步骤： master将扭转记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）；slave将master的binary log events拷贝到它的中继日志(relay log)；slave重做中继日志中的事件，将扭转反映它本人的数据。下图形容了复制的过程： 该过程的第一局部就是master记录二进制日志。在每个事务更新数据实现之前，master在二日志记录这些扭转。MySQL将事务串行的写入二进制日志，即便事务中的语句都是穿插执行的。在事件写入二进制日志实现后，master告诉存储引擎提交事务。下一步就是slave将master的binary log拷贝到它本人的中继日志。首先，slave开始一个工作线程——I/O线程。I/O线程在master上关上一个一般的连贯，而后开始binlog dump process。Binlog dump process从master的二进制日志中读取事件，如果曾经跟上master，它会睡眠并期待master产生新的事件。I/O线程将这些事件写入中继日志。SQL slave thread（SQL从线程）解决该过程的最初一步。SQL线程从中继日志读取事件，并重放其中的事件而更新slave的数据，使其与master中的数据统一。只有该线程与I/O线程保持一致，中继日志通常会位于OS的缓存中，所以中继日志的开销很小。此外，在master中也有一个工作线程：和其它MySQL的连贯一样，slave在master中关上一个连贯也会使得master开始一个线程。复制过程有一个很重要的限度——复制在slave上是串行化的，也就是说master上的并行更新操作不能在slave上并行操作。主从复制配置有两台MySQL数据库服务器Master和slave，Master为主服务器，slave为从服务器，初始状态时，Master和slave中的数据信息雷同，当Master中的数据发生变化时，slave也跟着产生相应的变动，使得master和slave的数据信息同步，达到备份的目标。 要点：负责在主、从服务器传输各种批改动作的媒介是主服务器的二进制变更日志，这个日志记录着须要传输给从服务器的各种批改动作。因而，主服务器必须激活二进制日志性能。从服务器必须具备足以让它连贯主服务器并申请主服务器把二进制变更日志传输给它的权限。 环境： Master和slave的MySQL数据库版本同为5.0.18IP地址：10.100.0.100创立复制帐号 1、在Master的数据库中建设一个备份帐户：每个slave应用规范的MySQL用户名和明码连贯master。进行复制操作的用户会授予REPLICATION SLAVE权限。用户名的明码都会存储在文本文件master.info中 命令如下： mysql > GRANT REPLICATION SLAVE,RELOAD,SUPER ON *.* TO backup@’10.100.0.200’ IDENTIFIED BY ‘1234’;建设一个帐户backup，并且只能容许从10.100.0.200这个地址上来登陆，明码是1234。 如果因为mysql版本新旧明码算法不同，能够设置： set password for 'backup'@'10.100.0.200'=old_password('1234')拷贝数据:（如果是你齐全新装置mysql主从服务器，这个一步就不须要。因为新装置的master和slave有雷同的数据） 关停Master服务器，将Master中的数据拷贝到B服务器中，使得Master和slave中的数据同步，并且确保在全副设置操作完结前，禁止在Master和slave服务器中进行写操作，使得两数据库中的数据肯定要雷同！ 配置master 接下来对master进行配置，包含关上二进制日志，指定惟一的servr ID。例如，在配置文件退出如下值： server-id=1log-bin=mysql-binserver-id：为主服务器A的ID值log-bin：二进制变更日值重启master，运行SHOW MASTER STATUS，输入如下： 配置slave Slave的配置与master相似，你同样须要重启slave的MySQL。如下： log_bin           = mysql-binserver_id         = 2relay_log         = mysql-relay-binlog_slave_updates = 1read_only         = 1#server_id：是必须的，而且惟一。log_bin：slave没有必要开启二进制日志bin_log，然而在一些状况下，必须设置，例如，如果slave为其它slave的master，必须设置bin_log。在这里，咱们开启了二进制日志，而且显示的命名(默认名称为hostname，然而，如果hostname扭转则会呈现问题)。 relay_log：配置中继日志，log_slave_updates示意slave将复制事件写进本人的二进制日志(前面会看到它的用途)。有些人开启了slave的二进制日志，却没有设置log_slave_updates，而后查看slave的数据是否扭转，这是一种谬误的配置。 read_only：尽量应用read_only，它避免扭转数据(除了非凡的线程)。然而，read_only并是很实用，特地是那些须要在slave上创立表的利用。 启动slave 接下来就是让slave连贯master，并开始重做master二进制日志中的事件。你不应该用配置文件进行该操作，而应该应用CHANGE MASTER TO语句，该语句能够齐全取代对配置文件的批改，而且它能够为slave指定不同的master，而不须要进行服务器。如下： mysql> CHANGE MASTER TO MASTER_HOST='server1',-> MASTER_USER='repl',-> MASTER_PASSWORD='p4ssword',-> MASTER_LOG_FILE='mysql-bin.000001',-> MASTER_LOG_POS=0;MASTER_LOG_POS的值为0，因为它是日志的开始地位。 你能够用SHOW SLAVE STATUS语句查看slave的设置是否正确： mysql> SHOW SLAVE STATUSG*************************** 1. row ***************************Slave_IO_State:Master_Host: server1Master_User: replMaster_Port: 3306Connect_Retry: 60Master_Log_File: mysql-bin.000001Read_Master_Log_Pos: 4Relay_Log_File: mysql-relay-bin.000001Relay_Log_Pos: 4Relay_Master_Log_File: mysql-bin.000001Slave_IO_Running: NoSlave_SQL_Running: No...omitted...Seconds_Behind_Master: NULLSlave_IO_State, Slave_IO_Running, 和Slave_SQL_Running是No，表明slave还没有开始复制过程。日志的地位为4而不是0，这是因为0只是日志文件的开始地位，并不是日志地位。实际上，MySQL晓得的第一个事件的地位是4。 ...

微信搜寻【阿丸笔记】，关注Java/MySQL/中间件各系列原创实战笔记，干货满满。分库分表的文章网上十分多，然而大多内容比拟零散，以解说知识点为主，没有残缺地阐明一个大表的切分、新架构设计、上线的残缺过程。 因而，我联合去年做的一个大型分库分表我的项目，来复盘一下残缺的分库分表从架构设计 到 公布上线的实战总结。 1.前言为什么须要做分库分表。这个置信大家多少都有所理解。 海量数据的存储和拜访成为了MySQL数据库的瓶颈问题，日益增长的业务数据，无疑对MySQL数据库造成了相当大的负载，同时对于零碎的稳定性和扩展性提出很高的要求。 而且单台服务器的资源（CPU、磁盘、内存等）总是无限的，最终数据库所能承载的数据量、数据处理能力都将遭逢瓶颈。 目前来说个别有两种计划。 一种是更换存储，不应用MySQL，比方能够应用HBase、polarDB、TiDB等分布式存储。 如果出于各种起因思考，还是想持续应用MySQL，个别会采纳第二种形式，那就是分库分表。 文章结尾就说了，网上分库分表文章很多，对知识点解说比拟多，因而，本文将不再过多赘述分库分表计划的范式解决。 而是专一于梳理分库分表从架构设计 到 公布上线的残缺过程，同时总结其中的注意事项和最佳实际。包含： 业务重构技术架构设计革新和上线稳定性保障项目管理尤其是各个阶段的最佳实际，都是血与泪凝聚的经验教训。 2.第一阶段：业务重构（可选）对于微服务划分比拟正当的分库分表行为，个别只须要关注存储架构的变动，或者只须要在个别利用上进行业务革新即可，个别不须要着重思考“业务重构” 这一阶段，因而，这一阶段属于“可选”。本次我的项目的第一大难点，在于业务重构。 而本次拆分我的项目波及到的两张大表A和B，单表将近八千万的数据，是从单体利用时代遗留下来的，从一开始就没有很好的畛域驱动/MSA架构设计，逻辑发散十分重大，到当初曾经波及50+个在线服务和20+个离线业务的的间接读写。 因而，如何保障业务革新的彻底性、全面性是重中之重，不能呈现有脱漏的状况。 另外，表A 和 表B 各自有二、三十个字段，两表的主键存在一一对应关系，因而，本次分库分表我的项目中，还须要将两个表进行重构交融，将多余/无用的字段剔除。 2.1 查问统计在线业务通过分布式链路追踪零碎进行查问，依照表名作为查问条件，而后依照服务维度进行聚合，找到所有相干服务，写一个文档记录相干团队和服务。 这里特地留神下，很多表不是只有在线利用在应用，很多离线算法和数据分析的业务也在应用，这里须要一并的梳理好，做好线下跨团队的沟通和调研工作，免得切换后影响失常的数据分析。 2.2 查问拆分与迁徙创立一个jar包，依据2.1的统计后果，与服务owner单干将服务中的相干查问都迁徙到这个jar包中（本我的项目的jar包叫projected），此处为1.0.0-SNAPSHOT版本。 而后将本来服务内的xxxMapper.xxxMethod( ) 全副改成projectdb.xxxMethod( )进行调用。 这样做有两个益处： 不便做后续的查问拆分剖析。不便后续间接将jar包中的查问替换为革新后 中台服务 的rpc调用，业务方只需降级jar包版本，即可疾速从sql调用改为rpc查问。这一步花了几个月的理论，务必梳理各个服务做全面的迁徙，不能脱漏，否则可能会导致拆分剖析不全面，脱漏了相干字段。 查问的迁徙次要因为本次拆分我的项目波及到的服务太多，须要收拢到一个jar包，更不便前期的革新。如果理论分库分表我的项目中仅仅波及一两个服务的，这一步是能够不做的。2.3 联结查问的拆分剖析依据2.2收拢的jar包中的查问，结合实际状况将查问进行分类和判断，把一些历史遗留的问题，和曾经废除的字段做一些整顿。 以下举一些思考点。 1）哪些查问是无奈拆分的？例如分页（尽可能地革新，切实改不了只能以冗余列的模式） 2）哪些查问是能够业务上join拆分的？ 3）哪些表/字段是能够交融的？ 4）哪些字段须要冗余？ 5）哪些字段能够间接废除了？ 6）依据业务具体场景和sql整体统计，辨认要害的分表键。其余查问走搜寻平台。 思考后失去一个查问革新总体思路和计划。 同时在本我的项目中须要将两张表交融为一张表，废除冗余字段和有效字段。 2.4 新表设计这一步基于2.3对于查问的拆分剖析，得出旧表交融、冗余、废除字段的后果，设计新表的字段。 产出新表设计构造后，必须发给各个相干业务方进行review，并保障所有业务方都通过该表的设计。有必要的话能够进行一次线下review。 如果新表的过程中，对局部字段进行了废除，必须告诉所有业务方进行确认。 对于新表的设计，除了字段的梳理，也须要依据具体查问，从新设计、优化索引。 2.5 第一次降级新表设计实现后，先做一次jar包内sql查问的革新，将旧的字段全副更新为新表的字段。 此处为2.0.0-SNAPSHOT版本。 而后让所有服务降级jar包版本，以此来保障这些废除字段的确是不应用了，新的表构造字段可能齐全笼罩过来的业务场景。 特地留神的是，因为波及服务泛滥，能够将服务依照 非核心 与 外围 辨别，而后分批次上线，避免出现问题导致重大故障或者大范畴回滚。 2.5 最佳实际2.6.1 尽量不扭转原表的字段名称在做新表交融的时候，一开始只是简略归并表A 和 表B的表，因而很多字段名雷同的字段做了重命名。 ...

前言对于互联网公司来说，随着用户量和数据量的一直减少，慢查问是无奈防止的问题。个别状况下如果呈现慢查问，意味着接口响应慢、接口超时等问题。如果是高并发的场景，可能会呈现数据库连贯被占满的状况，间接导致服务不可用。 慢查问确实会导致很多问题，咱们要如何优化慢查问呢？ 次要解决办法有： 监控sql执行状况，发邮件、短信报警，便于疾速辨认慢查问sql关上数据库慢查问日志性能简化业务逻辑代码重构、优化异步解决sql优化索引优化其余的方法先不说，前面有机会再独自介绍。明天我重点说说索引优化，因为它是解决慢查问sql问题最无效的伎俩。 如何查看某条sql的索引执行状况呢？ 没错，在sql后面加上explain关键字，就可能看到它的执行打算，通过执行打算，咱们能够分明的看到表和索引执行的状况，索引有没有执行、索引执行程序和索引的类型等。 索引优化的步骤是： 应用explain查看sql执行打算判断哪些索引使用不当优化sql，sql可能须要屡次优化能力达到索引应用的最优值既然索引优化的第一步是应用explain，咱们先全面的理解一下它。 explain介绍先看看mysql的官网文档是怎么形容explain的： EXPLAIN能够应用于 SELECT， DELETE， INSERT， REPLACE，和 UPDATE语句。当EXPLAIN与可解释的语句一起应用时，MySQL将显示来自优化器的无关语句执行打算的信息。也就是说，MySQL解释了它将如何解决该语句，包含无关如何连贯表以及以何种程序连贯表的信息。当EXPLAIN与非可解释的语句一起应用时，它将显示在命名连贯中执行的语句的执行打算。对于SELECT语句， EXPLAIN能够显示的其余执行打算的正告信息。explain详解explain的语法： `{EXPLAIN | DESCRIBE | DESC}` `tbl_name [col_name | wild]``{EXPLAIN | DESCRIBE | DESC}` `[explain_type]` `{explainable_stmt | FORCONNECTION connection_id}``explain_type: {` `EXTENDED` `| PARTITIONS` `| FORMAT = format_name``}``format_name: {` `TRADITIONAL` `| JSON``}``explainable_stmt: {` `SELECTstatement` `| DELETEstatement` `| INSERTstatement` `| REPLACEstatement` `| UPDATEstatement``}`用一条简略的sql看看应用explain关键字的成果： explain select * from test1;执行后果： 从上图中看到执行后果中会显示12列信息，每列具体信息如下： 说白了，咱们要搞懂这些列的具体含意能力失常判断索引的应用状况。 话不多说，间接开始介绍吧。 ...

好久不见！ 自 CloudQuery v1.2.1 公布至今，已有月余，在此期间咱们收到了很多敌人对 CloudQuery 的反馈和倡议，很多敌人表白了对 v1.3.0 的期待，非常感谢。 CloudQuery 新版本原打算 12 月 10 号上线，因为咱们对 v1.3.0 提出了更多要求和更高标准，因而提早到明天公布。 本次性能降级较多，请各位做好筹备！ 一、语句珍藏性能1、反对 SQL 语句珍藏，反对对珍藏语句的自定义命名。 2、可在珍藏治理中查看执行语句、语句别名、更新工夫和应用次数；反对针对语句或别名的搜寻。 二、新增 PostgreSQL 数据源1、反对 PostgreSQL 数据源 10 和 11 版本。 2、PostgreSQL 数据源菜单和后果集编辑性能 ① 数据源菜单性能蕴含：关上表、删除表、截断表、清空表、模式、视图、函数、转储 SQL 文件等。② 反对 PostgreSQL 数据源的后果集编辑与导出性能。 3、反对 PostgreSQL 数据源利用账号的受权治理和利用剖析。 4、反对 PostgreSQL 数据源的终端连贯。 三、新增达梦数据源1、反对达梦数据源 7.6 版本和 8.0 版本。 2、反对达梦数据源菜单和后果集编辑性能。① 数据源菜单性能蕴含：关上表、删除表、截断表、清空表、模式、视图、函数、转储 SQL 文件等。② 反对达梦数据源的后果集编辑与导出性能。 3、反对达梦数据源的利用账号的受权治理和利用剖析。 4、反对达梦数据源的终端连接功能。 四、权限治理性能全面降级1、新增菜单权限治理性能，蕴含：增加连贯、审计剖析、零碎设置。权责明显，没有取得受权的用户将无奈在界面上看到相干按钮。 2、新增数据操作权限治理性能。可具体到具体数据库中某一表、视图，函数组、存储过程，并可对用户的指定操作进行受权，例如查看、DML、DDL 等，反对对指定数据库元素的权限束缚。 3、新增权限集性能，管理员能够通过设置权限集，高效不便的授予或发出用户权限。 新增最小权限集性能，最小权限集是随同连贯而主动生成、随同连贯删除主动删除、具备最根本角色的最小公共权限。最小权限集能够帮忙管理者疾速赋予用户权限。 五、审计剖析性能全新改版1、反对对语句类型、执行后果等条件的审计过滤。 2、反对审计导出性能，可将审计明细数据导出为 Excel 表格。 ...

有情怀，有干货，微信搜寻【三太子敖丙】关注这个不一样的程序员。本文 GitHub https://github.com/JavaFamily 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。 前言咱们晓得，缓存的设计思维在RDBMS数据库中无处不在，就拿号称2500w行代码，bug堆积如山的Oracle数据库来说，SQL的执行打算能够缓存在library cache中防止再次执行雷同SQL产生硬解析（语法分析->语义剖析->生成执行打算），SQL执行后果缓存在RESULT CACHE内存组件中，无效的将物理IO转化成逻辑IO，进步SQL执行效率。 MySQL的QueryCache跟Oracle相似，缓存的是SQL语句文本以及对应的后果集，看起来是一个很棒的Idea，那为什么从MySQL 4.0推出之后，5.6中默认禁用，5.7中被deprecated（废除）以及8.0版本被Removed，明天就聊聊MySQL QueryCache的前世今生。 QueryCache介绍MySQL查问缓（QC：QueryCache）在MySQL 4.0.1中引入，查问缓存存储SELECT语句的文本以及发送给客户机的后果集，如果再次执行雷同的SQL，Server端将从查问缓存中检索后果返回给客户端，而不是再次解析执行SQL，查问缓存在session之间共享，因而，一个客户端生成的缓存后果集，能够响应另一个客户端执行同样的SQL。 回到结尾的问题，如何判断SQL是否共享？ 通过SQL文本是否完全一致来判断，包含大小写，空格等所有字符齐全截然不同才能够共享，共享益处是能够防止硬解析，间接从QC获取后果返回给客户端，上面的两个SQL是不共享滴，因为一个是from，另一个是From。 --SQL 1select id, balance from account where id = 121;--SQL 2select id, balance From account where id = 121;上面是Oracle数据库通过SQL_TEXT生成sql_id的算法，如果sql_id不一样阐明就不是同一个SQL，就不共享，就会产生硬解析。 #!/usr/bin/perl -wuse Digest::MD5 qw(md5 md5_hex md5_base64);use Math::BigInt;my $stmt = "select id, balance from account where id = 121\0"; my $hash = md5 $stmt; my($a,$b,$msb,$lsb) = unpack("V*",$hash);my $sqln = $msb*(2**32)+$lsb;my $stop = log($sqln) / log(32) + 1;my $sqlid = '';my $charbase32 = '0123456789abcdfghjkmnpqrstuvwxyz';my @chars = split '', $charbase32;for($i=0; $i < $stop-1; $i++){ my $x = Math::BigInt->new($sqln); my $seq = $x->bdiv(32**$i)->bmod(32); $sqlid = $chars[$seq].$sqlid;}print "SQL is:\n $stmt \nSQL_ID is\n $sqlid\n";大家能够发现SQL 1和SQL 2通过代码生成的sql_id值是不一样，所以不共享。 ...

如何保障查问的字段与条件里字段程序一样呢？有如下数据表 customer_idcert_no65776 78666 23322 87889 须要依据会员号补充对应的证件号，sql很简略： select x.customer_id,x.cer_no from customer x where x.customer_id in('65776','78666','23322','87889');咱们晓得mysql并不会保障查问的后果与条件in里保持一致而是按值的字典程序进行排列，如果值不多手动匹配倒也不妨，如果数据很多的时候如何做到统一呢，能够应用order by field,也就是这样： select x.customer_id,x.cer_no from customer x where x.customer_id in('65776','78666','23322','87889') order by field("customer_id",'65776','78666','23322','87889');这样查问后果里的customer_id的值就会与条件in里的值统一了。

解读 MySQL Client/Server Protocol: Connection & ReplicationMySQL 客户端与服务器之间的通信基于特定的 TCP 协定，本文将会详解其中的 Connection 和 Replication 局部，这两个局部别离对应的是客户端与服务器建设连贯、实现认证鉴权，以及客户端注册成为一个 slave 并获取 master 的 binlog 日志。 Connetcion PhaseMySQL 客户端想要与服务器进行通信，第一步就是须要胜利建设连贯，整个过程如下图所示： client 发动一个 TCP 连贯。server 响应一个 Initial Handshake Packet（初始化握手包），内容会蕴含一个默认的认证形式。这一步是可选的，单方建设 SSL 加密连贯。client 回应 Handshake Response Packet，内容须要包含用户名和依照指定形式进行加密后的明码数据。server 响应 OK_Packet 确认认证胜利，或者 ERR_Packet 示意认证失败并敞开连贯。Packet一个 Packet 其实就是一个 TCP 包，所有包都有一个最根本的构造： 如上图所示，所有包都能够看作由 header 和 body 两局部形成：第一局部 header 总共有 4 个字节，3 个字节用来标识 body 即 payload 的大小，1 个字节记录 sequence ID；第二局部 body 就是 payload 理论的负载数据。 ...

Mysql数据库面试问题系列继续更新，想追更欢送关注微信公众号：pipi的奇思妙想原文链接 你可能曾经晓得B+树被用于Mysql的索引底层实现，那么，为什么是B+树呢？本文由浅及深，带你摸索数据库索引底层实现。 由一个例子总结索引的特点加索引是数据库减速查问的一种形式，那么为什么用索引能够放慢查问呢？ 讲到索引，其实咱们常常会听到一个图书馆的例子，图书馆里的书目繁冗，咱们如何从若干本书外面找到一本咱们想要的书呢？ 咱们依据图书馆零碎检索，能够找到某本书对应的图书编号。 在基于书籍依照肯定规定排列的前提下，咱们能够依据图书编号找到这本书。 例如，假如图书编号依据： 第几个书架 - 书架上第几个格子 - 从左到右数第几个地位 这样的规定编排， 咱们就能够轻松的获取到咱们想要的书籍。 你兴许发现了，这个例子中，藏着两个信息： 依照肯定的规定排列有序依照肯定的规定，建设肯定的映射关系，这让你联想到了什么？ 没错，就是哈希表。 基于哈希表实现的哈希索引在Mysql的InnoDB引擎中，自适应哈希索引就是用哈希表实现的。 哈希索引是数据库本身创立并应用的，DBA自身不能对其进行干涉，然而能够通过参数来禁止或者启用此个性。 显然用哈希表实现索引的益处是非常明显的，查找单个指定数据只须要O(1)的工夫复杂度。 例如上面的sql语句： select id from tablename where id == 1;然而对于这种查找指定范畴的sql语句，哈希索引就无能为力了。 select id from tablename where id BETWEEN 20 AND 23;阐明：因为哈希表自身是无序的，所以不利于范畴查问 再次思考到这里咱们遇到了一个问题，就是哈希表尽管从查找效率上满足了咱们查找单个数据的要求，然而显然，当遇到范畴查问时，因为哈希表自身的无序性，不利于指定范畴查找。 也就是说，咱们的需要减少了，咱们心愿数据的组织形式，既要有肯定规定，又要有序。 在引出这种数据结构之前，咱们首先来看一种查找形式：二分查找。 高效的查找形式：二分查找二分查找的核心思想是给定一个有序的数组，在查找过程中采纳跳跃式的形式查找，即先以有序数列的中点地位为比拟对象，如果要查找的元素小于中点元素，则将待查序列放大为左半局部，否则为右半局部。通过每次比拟，将查找区间缩小一半，直到找到所需元素。 比方要从以下序列中查找到数字4 [1,3,4,5,6,7,8]须要通过上面的查找步骤： 取核心地位对应元素，显然5大于4，在右边区间[1,3,4]进行查找持续取核心地位对应元素3，显然3大于4,在左边区间[4]进行查找4等于4，所以咱们查找胜利。能够看到二分查找的效率是O(log n)。 因为有序数组本身的有序性，所以范畴查问仍然能够通过二分查找的形式查找区间的边界来实现。 这样看来，如果单从查问效率上来说，有序的数组是一种很好的抉择。 然而显然有序数组对于插入和删除并不敌对，假如咱们要插入元素或者删除元素，都须要把局部元素全副向后或者向前挪动，最蹩脚的工夫复杂度是O(n)。 有没有这样一种数据结构，既有肯定程序，又不便插入和删除呢？事实上，基于二分查找的思维，诞生了这样一种数据结构：二分查找树。 基于二分查找思维的二叉查找树二叉查找树（Binary Search Tree）即BST树是这样的一种数据结构,如下图： 在二叉搜寻树中： 1).若任意结点的左子树不空，则左子树上所有结点的值均不大于它的根结点的值。 2).若任意结点的右子树不空，则右子树上所有结点的值均不小于它的根结点的值。 3).任意结点的左、右子树也别离为二叉搜寻树。 这样的构造非常适合用二分查找的思维查找元素。 比方咱们须要查找键值为8的记录： 先从根找起，找到6；显然8>6，所以接着找到6的右子树，找到7；显然8>7, 所以找7的右子树，找到了8，查找完结。这样一棵子树高度差不大于1的二叉查找树的查找效率靠近与O(log n); 然而当二叉树的结构变成这样时, ...

联接查问联接查问是一种常见的数据库操作，即在两张表（或更多表）中进行行匹配的操作。个别称之为程度操作，这是因为对几张表进行联接操作所产生的后果集能够蕴含这几张表中所有的列。 CROSS JOINCROSS JOIN对两个表执行笛卡儿积，返回两个表中所有列的组合。若左表有m行数据，右表有n行数据，则CROSS JOIN将返回m*n行的表。 CROSS JOIN的一个用途是疾速生成反复测试数据，因为通过它能够很快地结构m*n*o行的数据。 CROSS JOIN的另一个用途是能够作为返回后果集的行号，例如： SELECT emp_no, dept_no, @a:=@a+1 AS row_num FROM dept_emp, (SELECT @a:=0 ) t;INNER JOIN通过INNER JOIN用户能够依据一些过滤条件来匹配表之间的数据。在逻辑查问的前三个解决阶段中，INNER JOIN利用前两个阶段，即首先产生笛卡儿积的虚构表，再依照ON过滤条件来进行数据的匹配操作。 INNER关键字可省略。因为不会增加内部行，INNER JOIN中WHERE的过滤条件能够写在ON子句中。在MySQL数据库中，如果INNER JOIN后不跟ON子句，这时INNER JOIN等于CROSS JOIN。此外，如果ON子句中的列具备雷同的名称，能够应用USING子句来进行简化。 OUTER JOIN通过OUTER JOIN用户能够依照一些过滤条件来匹配表之间的数据。与INNER JOIN不同的是，在通过OUTER JOIN增加的保留表中存在未找到的匹配数据。 NATURAL JOINANSI SQL还反对NATURAL JOIN，即天然联接。NATURAL JOIN等同于INNTER JOIN与USING的组合，它隐含的作用是将两个表中具备雷同名称的列进行匹配。 NONEQUI JOINNONEQUI JOIN的联接条件蕴含“等于”运算符之外的运算符。例如，有一张部门经理表dept_manager，要生成表中所有两个不同经理的组合。这里先假如以后表中仅蕴含员工号A、B、C，执行CROSS JOIN后将生成上面九对：（A，A）、（A，B）、（A，C）、（B，A）、（B，B）、（B，C）、（C，A）、（C，B）、（C，C）。 显然，（A，A）、（B，B）和（C，C）蕴含雷同的员工号，不是无效的员工组合。而（A， B）、（B，A）又示意同样的组合。要解决这个问题，能够指定一个右边值小于左边值的联接条件，这样能够移除上述两种状况。该问题的解决方案为： SELECT a.emp_no,b.emp_no FROM dept_manager a INNER JOIN dept_manager b ON a.emp_no < b.emp_no;联接算法联接算法是MySQL数据库用于解决联接的物理策略。旧版本的MySQL数据库仅反对Nested-Loops Join算法，自8.0.18版本开始反对Hash Join算法。 当联接的表上有索引时，Nested-Loops Join是十分高效的算法。依据B+树的个性，其联接的工夫复杂度为O（N），若没有索引，则可视为最坏的状况，工夫复杂度为O（N2）。MySQL数据库依据不同的应用场合，反对两种Nested-Loops Join算法，一种是Simple Nested-LoopsJoin（NLJ）算法，另一种是Block Nested-Loops Join（BNL）算法。 ...

索引是帮忙数据库高效获取数据的数据结构索引的数据结构