Mysql

1. 概述：每当一个MySQLserver新退出或者重新加入一个MGR集群时，它都必须追平集群内相差的事务，保障这个节点的数据和集群内最新的数据是同步的。这个新退出集群的节点在追平集群中的数据或者重新加入集群的节点追评它脱离集群后到当初这段时间内相差的事务数据的过程称为分布式复原。 申请加入集群的节点首先查看groupreplicationapplier通道中的中继日志，查看该节点目前尚未从集群中同步过去的事务数据。如果是重新加入集群的节点，则该节点会找到在来到集群后到当初和集群最新数据中未回放的事务数据，在这种状况下，该节点首先会利用这些未同步的事务。对于新退出集群的节点，间接从一个疏导节点上进行全量数据恢复即可。 尔后，新退出的节点和集群中现有的online状态的节点（疏导节点）建设连贯进行状态转移。新退出的节点从集群中的疏导节点中同步退出集群之前或者来到集群后到当初未同步过去的数据，这些相差的事务由集群中的疏导节点提供。接下来，新退出的节点利用从集群中的疏导节点同步过去的未进行利用的事务。此时申请加入集群的节点将利用在状态传输过程中集群内新事务写入的数据。（此时集群内新事物写入的数据临时寄存在缓存队列中，并未将数据写入磁盘中）实现此过程后，新退出的节点的数据和整个集群的数据相比，处于一个追平的状态，并且该节点设置为online状态。 留神：新退出集群的节点，不论是之前有没有在此集群中，都会先随机选一个online节点先同步该节点和集群相差的事务。 组复制在分布式复原期间用下述办法实现状态传输： 应用克隆插件的性能进行近程克隆操作，该插件可从MySQL 8.0.17开始反对。要应用这种办法，必须在疏导节点和新退出的节点上提前装置克隆插件。组复制会主动配置所需的克隆插件设置，并治理近程克隆操作。 从疏导节点的二进制日志复制数据并在新退出的节点上利用这些事务。此办法须要在疏导节点和退出节点之间建设的名为groupreplicationrecovery的规范异步复制通道。 在退出节点上执行STARTGROUP_REPLICATION后，组复制会主动抉择上述办法的最佳组合进行状态转移。为此，组复制将会查看集群中哪些现有节点适宜用作疏导节点，退出节点须要疏导节点传输多少事务，以及是否有事务不再存在于集群中任意节点的二进制日志文件中。如果退出节点与疏导节点之间的事务差距很大，或者如果某些要求的事务不在疏导节点的二进制日志文件中，则组复制将通过近程克隆操作开始分布式复原。如果没有较大的事务间隙，或者未装置克隆插件，则组复制将间接从疏导节点的二进制日志进行状态转移。 在近程克隆操作期间，将删除退出节点上的现有数据，并用疏导节点数据的正本替换。当近程克隆操作实现并且新退出节点已重新启动时，将继续执行来自疏导节点二进制日志来进行状态转移，以获取在进行近程克隆操作时集群所写入的增量数据。 在从疏导节点的二进制日志进行状态转移期间，新退出节点从疏导节点的二进制日志中复制并利用所需的事务，并在收到事务时利用事务，直到二进制日志记录新退出节点退出了集群。（当退出节点胜利退出集群时，二进制日志中会记录对应的视图更改event）在此过程中，退出节点将缓冲该集群利用的新事务数据。从二进制日志的状态传输实现后，新退出节点将利用缓冲的事务。 当退出节点与该集群的所有事务放弃最新时，该节点将在设置为online状态并能够作为一般节点退出集群，并且分布式复原已实现。 ps：从二进制日志进行状态转移是组复制进行分布式复原的根本机制，并且如果未将复制组中的疏导节点和退出节点设置为反对克隆。因为从二进制日志进行状态转移是基于经典的异步复制，因而，如果退出该集群的MySQL server基本没有该集群的数据，或者从十分旧的备份中获取了数据，则可能要花费很长时间来复原最新数据。因而，在这种状况下，倡议在将MySQL server增加到集群之前，则应通过传输集群中已有节点的相当近期的快照来应用集群的数据对其进行设置。这能够最大水平地缩小分布式复原所需的工夫，并缩小对疏导节点的影响，因为疏导节点必须保留和传输较少的二进制日志文件。 2. 分布式复原的连贯：当退出节点连贯到现有节点中的疏导节点进行分布式复原期间的状态转移时，退出节点充当客户端，而疏导节点充当服务端。当通过此连贯（应用异步复制通道groupreplicationrecovery）从疏导节点的二进制日志进行状态转移时，退出节点充当正本，疏导节点充当源端。通过此连贯进行近程克隆操作时，新退出节点充当全量数据接收者，疏导节点充当全量数据提供者。利用于组复制上下文之外的角色的配置设置也能够利用于组复制，除非它们被特定于组复制的配置设置或行为所笼罩。 现有节点提供给新退出节点以进行分布式复原的连贯与组复制用于集群内节点之间的通信的连贯是不同的。 组通信引擎用于组复制（XCom，Paxos变体），用于近程XCom实例之间的TCP通信的连贯由groupreplicationlocal_address零碎变量指定。此连贯用于集群内online节点之间的TCP / IP消息传递。与本地实例的通信是通过应用内存内共享的传输通道进行的。 对于分布式复原，直到MySQL8.0.20为止，集群内的节点都将其规范SQL客户端连贯提供给退出节点，这由MySQL Server的主机名和端口零碎变量指定。如果report_port零碎变量指定了备用端口号，则改用该端口号。 从MySQL 8.0.21开始，组成员能够将分布式复原端点的代替列表作为加入成员的专用客户端连贯，从而使得独立于成员的惯例客户端用户的连贯能够用来管制分布式复原。能够应用groupreplicationadvertiserecoveryendpoints零碎变量来指定此列表，并且成员在退出组时将其分布式复原端点的列表传输到该组。默认值为成员持续提供与晚期版本雷同的规范SQL客户端连贯。 PS： 如果退出节点无奈应用MySQLServer的零碎变量定义的主机名正确辨认其余节点，则分布式复原可能会失败。倡议运行MySQL的操作系统应用DNS或本地设置具备正确配置的惟一主机名。能够在“performanceschema”库下的Replicationgroupmembers表的Memberhost列中验证server用于SQL客户端连贯的主机名。如果多个组成员将操作系统设置的默认主机名内部化，则退出节点有可能无奈将其解析为正确的地址，并且无奈连贯以进行分布式复原。在这种状况下，能够应用MySQL Server的report_host零碎变量来配置由每个server内部化的惟一主机名。 退出节点为分布式复原建设连贯的步骤如下： 当节点退出集群时，它会应用groupreplicationgroupseeds零碎变量中列表中蕴含的一个种子节点进行连贯，最后应用该列表中指定的groupreplicationlocaladdress连贯。种子节点可能是集群数据的子集。 通过此连贯，种子节点应用组复制的成员资格服务以视图的模式向退出的节点提供集群中所有online节点的列表。成员资格信息包含每个成员为分布式复原提供的分布式复原端点或规范SQL客户端连贯的详细信息。 退出节点从此列表中抉择适合的online节点作为其疏导节点进行分布式复原 退出节点尝试应用疏导节点的分布式复原端点来连贯到疏导节点，并按列表中指定的程序顺次尝试连贯每个端点。如果疏导节点没有提供端点，则退出节点将尝试应用疏导节点的规范SQL客户端连贯进行连贯。连贯的SSL要求由groupreplicationrecoveryssl *选项指定。 如果退出节点无奈连贯到指定的疏导节点，则它将与其余适合的疏导节点重试连贯。如果退出节点在没有建设连贯的状况下耗尽了端点的播送列表，则它不会回退到疏导节点的规范SQL客户端连贯，而是切换到另一个疏导节点尝试从新建设连贯。 退出节点与疏导节点建设分布式复原连贯时，它将应用该连贯进行状态转移，退出节点的日志中显示了所应用的连贯的主机和端口。如果应用近程克隆操作，则在操作完结时重新启动退出节点时，它将与新的疏导节点建设连贯，从疏导节点的二进制日志进行状态转移。这可能是与用于近程克隆操作的疏导节点不同的连贯，也可能是与疏导节点建设雷同的连贯。无论如何，分布式复原将以雷同的形式与疏导节点建设连贯。 2.1分布式复原端地址的查找：groupreplicationadvertiserecoveryendpoints零碎变量作为分布式复原端提供的IP地址，不用为MySQL Server配置（也就是说，不用由adminaddress零碎变量或在bindaddress零碎变量的列表中指定）。 为MySQL Server配置为分布式复原端提供的端口，必须由port，reportport或adminport零碎变量指定。必须在这些端口上侦听TCP / IP连贯。如果指定adminport，则用于分布式复原的复制用户须要SERVICECONNECTIONADMIN权限能力连贯。抉择adminport可使分布式复原连贯与惯例MySQL客户端连贯离开。 退出节点按列表中指定的程序顺次尝试每个端点。如果将groupreplicationadvertiserecoveryendpoints设置为DEFAULT而不是端点列表，则将提供规范SQL客户端连贯。规范SQL客户端连贯不会主动蕴含在分布式复原端点列表中，并且如果疏导节点的端点列表在没有连贯的状况下被用尽，则不会将其作为备用。如果要提供规范SQL客户端连贯作为多个分布式复原端点之一，则必须将其显式包含在groupreplicationadvertiseadvertiserecovery_endpoints指定的列表中。能够将其放在最初，以便作为连贯的最初伎俩。 无需将组成员的分布式复原起点（或规范SQL客户端连贯，如果未提供起点）增加到groupreplicationipallowlist（来自MySQL 8.0.22）或groupreplicationipwhitelist零碎变量指定的组复制容许列表中。许可列表仅实用于由groupreplicationlocal_address为每个节点指定的地址。退出节点必须具备与容许列表容许的集群的初始连贯，以便检索一个或多个地址进行分布式复原。 设置零碎变量和执行STARTGROUP_REPLICATION语句后，将验证列出的分布式复原端点。如果无奈正确解析列表，或者因为服务未在侦听列表而无奈在主机上拜访任何端点，则组复制将记录谬误并且无奈启动。 2.2分布式复原压缩在MySQL 8.0.18中，能够抉择应用疏导节点二进制日志中的状态转移办法为分布式复原配置压缩。在网络带宽无限的状况下，压缩能够使分布式复原受害，而疏导节点必须将许多事务传输给退出节点。groupreplicationrecoverycompressionalgorithm和groupreplicationrecoveryzstdcompression_level零碎变量配置容许的压缩算法以及zstd压缩级别，这些级别用于从疏导节点的二进制日志执行状态转移时应用。 这些压缩设置不适用于近程克隆操作。当近程克隆操作用于分布式复原时，将利用克隆插件的cloneenablecompression设置。 2.3分布式复原的用户分布式复原须要具备正确权限的复制用户，以便组复制能够建设间接的节点到节点的复制通道。复制用户还必须具备正确的权限，如果该复制用户还同充当近程克隆操作中的克隆用户，则在疏导节点中该复制用户还必须具备近程克隆相干的权限（BACKUP_ADMIN权限）能力充当疏导节点上的克隆用户以进行近程克隆操作。除此之外，必须将同一复制用户用于集群内每个节点上的分布式复原。 2.4分布式复原和SSL认证用于分布式复原的SSL与用于一般组通信的SSL离开配置，这由server的SSL设置和groupreplicationssl_mode零碎变量确定。对于分布式复原连贯，能够应用专用的组复制分布式复原SSL零碎变量来配置专门用于分布式复原的证书和密钥的应用。 默认状况下，SSL不用于分布式复原连贯。设置groupreplicationrecoveryusessl= ON启用，而后配置组复制分布式复原SSL零碎变量，将复制用户设置为应用SSL。 将分布式复原配置为应用SSL时，组复制会将此设置利用于近程克隆操作以及从疏导节点的二进制日志进行状态转移。组复制会主动配置克隆SSL选项（clonesslca，clonesslcert和clonesslkey），以匹配相应组复制分布式复原选项（groupreplicationrecoverysslca，groupreplicationrecoverysslcert和groupreplicationrecoverysslkey）的设置。 如果未应用SSL进行分布式复原（groupreplicationrecoveryusessl设置为OFF），并且组复制的复制用户帐户应用cachingsha2password插件（MySQL 8.0中的默认设置）或sha256password插件进行身份验证，则RSA密钥对为用于明码替换。在这种状况下，应用groupreplicationrecoverypublickeypath零碎变量指定RSA公共密钥文件，或者应用groupreplicationrecoverygetpublic_key零碎变量申请公共密钥。否则整个分布式回复会因为报错导致复原失败。 3. 利用克隆插件进行分布式复原：MySQLServer的克隆插件可从MySQL8.0.17取得。如果要将近程克隆操作用于集群中的分布式复原，则必须事后设置现有节点和退出节点能力反对此性能。如果不想在集群中应用此性能，请不要进行设置，在这种状况下，组复制仅应用二进制日志中的状态传输。 要应用克隆插件，必须事后设置至多一个现有的集群节点和退出节点反对近程克隆操作。至多，必须在疏导节点和退出节点上装置克隆插件，将BACKUPADMIN权限授予复制用户以进行分布式复原，并将groupreplicationclonethreshold零碎变量设置为适当的级别。（默认状况下为GTID序列容许的最大值，示意失常状况下，始终优先应用基于二进制日志的状态传输，除非joiner节点所申请的事务在组中任意成员中都不存在，这个时候，如果设置好了克隆性能，则无论该零碎变量的值设置为多少，都会触发通过克隆的形式进行分布式复原，例如：全新初始化的Server申请加入组时。如果不心愿应用克隆性能，则不要对其进行装置与配置）为了确保疏导节点的最大可用性，倡议设置所有以后和未来的集群节点反对近程克隆操作。以便后续有Server退出集群时可能应用近程克隆操作来疾速追赶集群中的最新数据。 在从疏导节点向退出节点传输数据之前，近程克隆操作会删除退出节点中用户创立的表空间和数据。如果在中途意外终止操作，则退出节点可能只剩下局部数据或没有数据。能够通过从新执行组复制主动执行的近程克隆操作来修复此问题。 这里次要针对近程克隆时应用DATADIRECTORY子选项指定了一个数据保留门路的状况，指定门路时，数据会保留在指定的目录下，即克隆之后的数据与操作克隆的实例没有关联，须要手动启动实例并指定datadir到保留克隆数据的目录进行启动，当然，MGR插件能够主动执行近程克隆的重试操作（须要保障克隆操作不指定DATA DIRECTORY子选项，在这种状况下，近程克隆数据会笼罩掉操作近程克隆的Server数据，实现近程克隆操之后，操作近程克隆的Server会基于克隆数据主动重新启动）。另外，克隆插件尽管与组复制配合应用对组复制的治理保护来说更加自动化，然而，克隆插件不要求必须在集群中运行（但MGR插件必须要装置）。 3.1克隆的根本条件对于组复制，应用克隆插件进行分布式复原须要留神以下要点和区别： 现有集群节点和退出节点必须已装置克隆插件并处于激活状态。 疏导节点和退出节点必须在雷同的操作系统上运行，并且必须具备雷同的MySQL Server版本（必须为MySQL 8.0.17或更高版本能力反对克隆插件）。因而，克隆不适用于成员运行不同MySQL版本的集群。 ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 之前我写过一篇文章：《ProxySQL 搭配 MySQL HA（下）》。文章里介绍了 ProxySQL 后端主机元数据表 mysql_server 每个字段的含意，其中有一个字段名为 gtid_port 。此字段是 ProxySQL Binlog Reader （目前还不反对 MySQL 8.0 版本）组件须要监听的端口， ProxySQL 须要连贯这个端口来判断主从GTID事务号是否统一，明天我来简略介绍下这个组件。 能够把 ProxySQL Binlog Reader 组件看成一个轻量级的 MySQL 客户端，应用它来实时探测 MySQL 主从复制架构中各个从实例的 GTID 回放后果。ProxySQL Binlog Reader 、ProxySQL 、MySQL 三者之间的关系如下图：ProxySQL 读取 ProxySQL Binlog Reader 输入的 GTID 来判断 MySQL 主库和从库数据是否统一。 ProxySQL Binlog Reader 组件诞生的背景如下：1.前端利用申请进入 MySQL 之前须要读写拆散。2.读写拆散的逻辑如何保障？ 大抵有三种策略：(1).申请对立下发到主 (2).以事务块为粒度下发到主 (3).读申请对立下发到从 对于这三种策略，特地是最初一种，从库有可能读到过期的数据。MySQL 主从复制从数据传输原理上来讲，从库防止不了数据回放的提早，咱们定制的各种优化策略无非是想方法缩小这部分提早的工夫，保障时效性。 MySQL 自从公布 GTID 性能后，对于此类问题，解决办法就变得容易许多。 ...

一、视图1.1、什么是视图？虚构存在的表，也有行&列形成，但并不理论存在于数据库中，数据库中只寄存视图的的定义，并没有寄存视图的数据，数据寄存在视图的实在表中。实在表中的数据=》视图中的数据1.2、视图和数据表的区别视图不是数据库中实在的表，而是一张虚构表，其构造和数据是建设在对数据中实在表的查问根底上的存储在数据库中的查问操作 SQL 语句定义了视图的内容，列数据和行数据来自于视图查问所援用的理论表，援用视图时动静生成这些数据视图没有理论的物理记录，不是以数据集的模式存储在数据库中的，所对应的数据来自于实在表视图的建设和删除只影响视图自身，不影响对应的根本表1.3、视图的长处定制用户数据，聚焦特定的数据简化数据操作进步数据的安全性共享所需数据更改数据格式重用 SQL 语句二、视图操作2.1、创立视图create view 视图名 as select语句留神：select 语句限度： 用户除了领有 create view 权限外，还具备操作中波及的根底表和其余视图的相干权限 select 语句不能引用零碎或用户变量 select 语句不能蕴含 FROM 子句中的子查问 select 语句不能引用预处理语句参数2.2、查看视图2.2.1 查看视图的字段信息desc 视图名;2.2.2 查看指定视图的详细信息show create view 视图名;2.2.3 查看数据库中所有定义的视图show table status where comment='view' \Gshow full tables where table_type='view';2.3、批改视图2.3.1 根底语法alter view 视图名 as select 语句2.3.2 批改视图内容能够应用 UPDATE、DELETE 或 INSERT 等语句更新根本表的内容不可更新的状态： 聚合函数 SUM()、MIN()、MAX()、COUNT() 等。 DISTINCT 关键字。 GROUP BY 子句。 HAVING 子句。 UNION 或 UNION ALL 运算符。 位于抉择列表中的子查问。 FROM 子句中的不可更新视图或蕴含多个表。 WHERE 子句中的子查问，援用 FROM 子句中的表。 ALGORITHM 选项为 TEMPTABLE（应用长期表总会使视图成为不可更新的）的时候。 eg: alter view view_students_info as select id,name.score from studentinfo; update view_students_info set score=90.00 where id=2; insert into view_students_info vlaues(3,'tom',33.00); delete from view_studentss_info wher id=3;2.4、删除视图2.4.1 根底语法drop view 视图1,视图2,...,视图n;2.4.1 删除视图drop view if exists 视图名;二、索引2.1、what?索引是一种非凡的数据库构造，由数据表中的一列或多列组合而成，能够用来疾速查问数据表中有某一特定值的记录2.2、优缺点长处： 通过创立惟一索引能够保障数据库表中每一行数据的唯一性。 能够给所有的 MySQL 列类型设置索引。 能够大大放慢数据的查问速度，这是应用索引最次要的起因。 在实现数据的参考完整性方面能够减速表与表之间的连贯。 在应用分组和排序子句进行数据查问时也能够显著缩小查问中分组和排序的工夫毛病： 创立和保护索引组要消耗工夫，并且随着数据量的减少所消耗的工夫也会减少。 索引须要占磁盘空间，除了数据表占数据空间以外，每一个索引还要占肯定的物理空间。 如果有大量的索引，索引文件可能比数据文件更快达到最大文件尺寸。 当对表中的数据进行减少、删除和批改的时候，索引也要动静保护，这样就升高了数据的保护速度。2.3、索引分类2.3.1 存储形式分B-树索引哈希索引2.3.2 逻辑辨别一般索引(index/key) ...

1.首先去MySQL的官网下载安装包 2.其余下载须要登录，抉择上面的间接装置 3.而后解压到文件夹中，我应用的server环境是租的VPS服务器（本文解压C:\mysql-8.0.29-winx64），并配置初始化的mi.ini文件（创立my.ini文件并把以下内容粘贴进去，记得先在解压门路下创立data文件夹哦），文件创建好后放到解压门路：C:\mysql-8.0.29-winx64 下 文件内容：[mysql]# 设置mysql客户端默认字符集default-character-set=utf8[mysqld]#设置3306端口port = 3306# 设置mysql的装置目录basedir=C:\mysql-8.0.29-winx64# 设置mysql数据库的数据的寄存目录datadir=C:\mysql-8.0.29-winx64\data# 容许最大连接数max_connections=200# 服务端应用的字符集默认为8比特编码的latin1字符集character-set-server=utf8# 创立新表时将应用的默认存储引擎default-storage-engine=INNODB4.装置MySQL，管理员权限应用cmd命令进入命令窗口，且cd到装置门路的bin目录下，mysql—install（装置）胜利的话如下图所示： mysqld --initialize （初始化）net start mysql（运行） 5.批改明码在data目录外面，找到“.err”结尾的文件，以记事本形式关上，找到“root@localhost”，前面就是明码  胜利登录进去，批改MySQL的root用户明码格局：mysqladmin -u用户名 -p旧明码； password 新密码

MySQL是计算机程序罕用的开源数据库管理系统，MySQL技能始终是面试中高频率命中考题，上面一起简略复盘下MySQL基础知识：MySQL是个反对插拔式的数据库治理系统软件，从存储引擎到解析器都能够被替换，上面以Innodb存储引擎为例进行剖析。MySQL对内存的治理以页为单位（16k）从磁盘读取到内存的Buffer Pool中，当查问数据时命中数据连同数据搭档一起读到Buffer Pool中，当写数据时，会写到Buffer Pool中和Redo log中，Redo log是顺序存储，存储引擎是随机存储，Redo log被当作数据恢复日志应用，用来记录数据库宕机、失落后数据恢复为主（先预写日志Redo Buffer，再进行刷盘操作），因而Redo log能保证数据的不失落。Undo log是撑持事务回滚操作的文件系统，当批改数据并且进行刷盘后，回复刷盘前的数据靠Undo log进行记录复原。Binlog和Redo log有着相似之处，记录批改后的数据，Binlog侧重于逻辑日志，记录对数据内存页地位进行批改，属于Server层，Redo log偏重理论的写数据，属于存储引擎层。MySQL的集群高可用次要靠Binlog日志进行实现。

7月10日，由星策社区主办的第三期「MLOps Meetup」于线上发展，本次流动由51CTO、开源中国、CSDN、思否、示说网、云原生社区同步直播，累计观看人次1.5w+ 。 流动围绕“如何应用 SQL 实现工业级机器学习全流程”，星策社区发起人—谭中意，为本次流动进行收场，同时介绍了“ SQL boy 也能够做AI ”的流动背景；开源我的项目OpenMLDB PMC、第四范式平台架构师—陈迪豪，介绍如何用 SQL 实现特色工程；百度飞桨、EDL、SQLFlow、Couler 外围开发者贡献者—武毅，分享如何用 SQL 做模型训练与预测；Byzer社区PMC、Kyligence技术合伙人—祝海林，介绍如何用 SQL 实现端到端机器学习流程。 本文依据四位老师分享的重点内容整顿而成，视频回顾见文章开端，PPT获取请关注公众号「星策开源」并回复「0710」 Part1：SQL Boy 也能够做 AI —谭中意 为什么 SQL 现在仍在风行？ SQL 从1978年倒退至今仍在业界十分风行，起因有以下几点：首先，SQL 是一种申明式编程语言，它只需表白想要失去的后果，而不必关怀具体实现的过程。其次，SQL 是标准化的，只有是符合标准（ANSI等）的SQL，在不同的机器与环境下都能够运行，并失去同样的后果。最初，SQL 最大的长处就是简略，工程师能够很容易学习和应用。 SQL 的用处 SQL 的用处很广，比方在传统的企业业务零碎里，用MySQL数据库或微软 SQL 数据库等做CRUD的利用。大数据的数据分析畛域，有 Spark SQL 、HiveSQL 等。除此之外，SQL 的利用也能波及机器学习畛域，它能够实现特色工程、模型训练，甚至能够做端到端的机器学习。本次 Meetup 就将介绍如何用 SQL 实现这些。 Part2：OpenMLDB—以SQL为外围的线上线下一致性特色平台—陈迪豪 人工智能工程化落地的数据和特色挑战 依据 Gartner 的考察统计，现在人工智能畛域中95%的工夫精力都破费在数据上，如何正确、高效的 AI 数据和特色供应成为数据侧的新挑战。机器学习利用从开发到上线的全流程（MLOps）能够分成离线开发与线上服务两个过程，这两个过程别离蕴含：DataOps、FeatureOps、ModelOps三个步骤。其中特色问题尤为辣手，如 FeatureOps（特色工程）中线上线下一致性校验带来的昂扬工程化落地老本问题。为了解决这一问题：1%的头部企业抉择消耗上千小时自研构建平台，非头部企业有的则会洽购低廉的 SaaS 工具和服务，而OpenMLDB 提供了另一种解决方案，它以 SQL 为外围，提供了低成本、高效的线上线下一致性生产级特色计算平台。 OpenMLDB 用 SQL 实现开发即上线 OpenMLDB是一个开源机器学习数据库，提供了线上线下统一的特色平台，他的整体架构如下图所示，与 AI 利用落地所须要的工具链一样，整体框架分为离线与在线两局部，别离提供了基于Spark++ 的批处理 SQL 引擎与基于自研时序数据库的实时SQL引擎，中间层提供了基于 SQL 的一致性执行打算生成器。总结来看，通过 OpenMLDB 开发者只有会写 SQL，只需三步，即可实现开发即上线的过程。 ...

01 多主模式 在多主模式下（group_replication_single_primary_mode = OFF），所有成员不会辨别primary和standby角色。退出该组时，与其余组成员兼容的任何成员都被设置为读写模式，并且能够解决写事务，即便它们是并发执行的。 如果组复制中的某个成员进行承受写事务，例如，在某个节点意外宕机的状况下，能够将与其连贯的客户端重定向或故障转移到处于读写模式的任何其余衰弱的成员。组复制自身不解决客户端故障转移，因而须要应用中间件框架（例如MySQL Router 8.0，代理，连接器或应用程序自身）来实现。下图阐明了MGR集群的多主模式下故障转移的实现： 组复制在集群内保障了零碎的最终一致性。一旦入栈流量缩小，所有组成员将具备雷同的数据内容。当流量在集群外部下发时，事务能够在某些成员之间先进行长久化，特地是如果某些成员的写入吞吐量小于其余成员的状况下，则可能导致性能差的节点上读取到旧数据。在多主模式下，写入速度较慢的成员还可能积压过多的事务，从而导致更大的抵触和认证失败危险。为了防止这些问题，能够针对不同的业务场景应用组复制自带的流控机制，以最大水平地缩小不同成员之间的事务差别。对于MGR的流控机制，咱们在前面进行具体探讨。 从MySQL 8.0.14开始，如果要为集群中的每个事务都领有一个事务一致性保障，则能够应用group_replication_consistency零碎变量来做到这一点。能够抉择适宜集群工作负载和数据读写优先级的设置，同时思考到进步一致性整个集群对性能的影响。还能够为单个会话设置该零碎变量，用来爱护特地是对并发敏感的事务。无关事务一致性的更多信息，咱们在前面的章节详细描述。 02 事务形容 当MGR集群是以多主的模式在线上运行时，集群通过以下两条准则对不同成员之间的事务进行严格的一致性检测，以保障这些事务能够在集群内提交胜利： 1.如果在SERIALIZABLE隔离级别下执行事务，则在集群中同步数据时，该事务将提交失败。 2.如果事务是针对具备具备级联束缚的外键的表执行的，则在集群中同步数据时，该事务将提交失败。 group_replication_enforce_update_everywhere_checks零碎变量管制上述行为。在多主模式下，通常应将零碎变量设置为ON，然而能够抉择将零碎变量设置为OFF来禁用查看。在单主模式下部署时，必须将零碎变量设置为OFF。 03 在多主模式的复制拓补中，执行DDL须要分外小心MySQL 8.0引入了对原子数据定义语言（DDL）语句的反对，其中残缺的DDL语句作为单个原子事务被提交或回滚。然而，DDL语句隐式完结以后会话中处于活动状态的事务，就如同在执行该语句之前执行了COMMIT一样。这意味着DDL语句不能在另一个事务中执行，例如在事务管制语句（START TRANSACTION ... COMMIT）中执行，也不能与同一事务中的其余语句组合。 如果对同一对象进行更改（应用DDL）并更改对象蕴含的数据（应用DML），则须要通过同一个节点解决更改，而DDL操作尚未实现并在各处复制。否则，当操作中断或仅局部实现时，可能导致数据不统一。如果集群以单主服务器模式部署，则不会产生此问题，因为所有数据更改都是通过同一个节点（主节点）执行的。 04 版本兼容性为了获得最佳的兼容性和性能，集群中的所有成员应运行雷同版本的MySQL Server，因而应运行雷同版本的组复制。在多主模式下，这更为重要，因为所有成员通常都将以读写模式退出该集群。如果集群中蕴含运行多个MySQL Server版本的成员，则某些成员可能与其余成员不兼容，因为它们反对其余成员不具备的性能或短少其余成员具备的性能。为了避免这种状况，当新成员退出（包含以前已降级并重新启动的成员）时，该成员将对组的其余成员执行兼容性查看。 这些兼容性查看的后果在多主模式下尤其重要。如果新加入成员所运行的MySQL Server版本高于现有组成员所运行的最低版本，则它将退出该组，但放弃只读模式。（在以单主模式运行的集群中，无论如何，新增加的成员在任何状况下均默认为只读。）运行MySQL 8.0.17或更高版本的成员在查看其兼容性时会思考该发行版的补丁程序版本。运行MySQL 8.0.16或更低版本或MySQL 5.7的成员仅思考次要版本。 在具备应用不同MySQL Server版本的成员的多主模式下运行的集群中，组复制会主动治理运行在MySQL 8.0.17或更高版本的成员的读写状态和只读状态。如果成员来到集群，则运行以后最低版本的成员将主动设置为读写模式。当应用group_replication_switch_to_multi_primary_mode自定义函数时，将以单主模式运行的组更改为以多主模式运行时，组复制会主动将成员设置为正确的模式。如果新增成员运行的MySQL版本高于组中存在的最低版本的成员，则该成员将主动置于只读模式，而运行最低版本的成员将处于读写模式。 05 MGR服务5.1成员资格：复制组由一组MySQL Server形成。集群具备一个惟一的名称，名称模式为UUID字符串。集群内的成员是动静的，成员能够随时脱离集群，也能够随时退出集群。每当有Server退出或脱离集群时，集群的相干信息都会进行主动调整。 如果一个Server退出了集群，则它会从集群的现有成员中主动获取本身缺失的数据状态以便和集群保持数据同步。如果一个成员脱离了集群，其余的成员会发现该成员脱离了集群，并主动重新配置集群。 组复制定义了集群内哪些成员在线且是沉闷成员。在线成员列表被称为组视图。集群中的每个成员都具备一个统一的视图，即示意在给定的时刻集群中哪些成员是沉闷成员。 组成员不仅在事务提交时必须达成统一，对于组视图的变更也必须达成统一。如果现有成员批准新的Server退出集群，则集群将被重新配置，以便将新节点集成到集群中，这将触发组视图的变更。如果组成员脱离集群，该集群将动静地重新配置，并触发组视图的变更。 在成员被迫脱离集群的状况下，它首先启动动静组重新配置，在此期间，所有组成员必须就新的组视图达成统一。然而，如果某个组成员是非自愿地脱离了集群，例如：因为意外宕机了或网络连接中断了，那么脱离集群的成员就不能启动动静重新配置。在这种状况下，组复制的故障检测机制会在短时间内辨认出该成员曾经脱离了集群，并倡议将已脱离组成员排除在外并进行动静重新配置组。重新配置组须要失去组中大多数组成员的批准。然而，如果此时集群内不能达成统一，例如：因为集群内沉闷节点数量少于节点总数量的半数时，零碎就不能动静重新配置集群，这种状况下集群会阻塞写访问以防止出现脑裂的状况。直到人工染指解决。 在故障检测机制检测到其故障之前，或在重新配置集群以删除该故障成员之前，容许组成员短暂离线，而后尝试重新加入集群。在这种状况下，重新加入的成员可能会失落它以前的事务数据，如果此时其余成员向它发送了蕴含该成员解体前的状态的音讯，则这就可能会导致一些问题（例如：可能导致数据不统一。） 为了解决这个问题，从MySQL 5.7.22及其之后的版本中，当Server退出一个集群时，会被赋予一个惟一的标识符。这使组复制可能察觉到同一Server的新化身（尽管具备雷同的地址，但不同的化身具备不同的标识符）试图退出组时，而其旧化身依然会作为成员列出。在通过重新配置组并删除旧的化身之前，将阻止新的化身退出组。如果通过零碎变量group_replication_member_expel_timeout的设置减少了疑似故障的成员在被驱赶出集群之前容许返回集群的等待时间，则只有疑似故障的成员不是真的故障了，那么被狐疑的那个成员在这个等待时间内就能够尝试重新加入集群。如果在被狐疑出故障的成员上执行了重启组复制，则该成员将成为新的化身，在狐疑超时之前（狐疑期工夫内）不能重新加入组。 5.2故障检测：组复制反对一种故障检测机制，该机制可能发现和列出哪些组成员是静默的，并假设静默的组成员曾经挂机。总体上讲，故障检测器是一种分布式服务，它提供对于哪些组成员可能死机的信息。当组成员静默时就会引发狐疑。当组成员A在给定的时间段内没有接管来自组成员B的音讯时，将产生音讯超时并引发狐疑。稍后，如果组内其余所有的成员通过协商之后，都批准对该成员的狐疑可能是实在的（少数节点断定的后果），则集群就会断定被狐疑的成员的确产生了故障。这意味着组中其余成员可能通过采取协调一致的决策来将故障成员驱赶出组（被断定为产生故障的成员）。 如果某个组成员与组中的其余成员产生了网络隔离，那么它会狐疑集群中其余所有成员都产生故障了。因为无奈与组内的其余成员进行协商（因为仲裁成员数有余），它的狐疑有效。此时，它也无奈执行任何本地事务（只读事务能够执行）。 5.3容错性：组复制建设在Paxos分布式算法的实现之上，以提供组成员之间的分布式协调。因而，它须要大多数组成员处于沉闷状态能力达到仲裁成员数，才可能做出决策。该要求会间接影响到零碎在不影响本身和整体可用性的状况下可能容忍产生故障的成员数量。能够容忍产生故障的成员数量（假如为f个）和要求组内总成员数量（假如为n个）之间的关系为：n = 2 x f + 1。 如果要容忍至多一个组成员产生故障，那么，组内的总成员数量至多须要3个。因而，当一个组成员产生故障时，依然有2个组成员是沉闷成员，即沉闷成员占多数（三分之二），此时，集群内可通过仲裁机制主动驱赶故障成员并容许零碎持续对外提供服务。然而，如果第二个组成员再产生故障（非被迫脱离组），则该集群（剩下一个成员）会产生阻塞，因为短少少数成员来做出正当的决策，所以无奈主动复原到能对外提供服务的状态，此时须要人工染指解决。 通常，基于性能和保护老本的思考，组内的成员总数量不倡议超过7个，最大只能9个。 5.4可察看性：尽管MGR插件内置了很多自动化性能。但有时可能须要理解幕后产生了什么。如果有须要，能够通过performance_schema下的表查问集群的整个状态(包含视图、抵触统计信息和服务状态等)。复制协定的分布式个性、以及组成员在事务和元数据上的一致性，要求组内的一些元数据和状态信息在组内所有成员间互相同步，这就使得检查组的状态等信息变得更加简略。你只须要连贯到集群内的任意一个成员中，并通过performance_schema下的相干复制状态信息表执行select语句进行查问，就能够获取到组相干的本地和全局信息。无关更多信息，咱们放在MGR状态监控中会具体探讨。 06 MGR插件架构MGR的总体架构图如下： MGR 插件蕴含一组用于捕捉，利用和生命循环的API，这些API管制着MGR插件如何与MySQL Server交互。这些接口是搁置在事务执行管道中的一些钩子（它们将MySQL Server的外围与MGR插件隔离开来），逻辑上将MySQL Server内核与MGR插件隔离开来。其中有一些接口提供把通信信息从Server发送给MGR插件（例如：Server启动、复原、承受连贯以及Server行将提交事务的事件告诉），有一些接口提供把通信信息从MGR插件发送给MySQL Server（例如：MGR插件命令MySQL Server提交、终止一个正在执行的事务，或者让该事务写入relay log中排队等待解决）。 ...

记录一次 Online DDL 操作为反对用户账号删除性能，须要在 user 表上加一个字段 deleted。一、环境数据库：Mysql5.6 被操作表 user：数量级为100w，外键200多个 操作：alter table user add deleted boolean NOT NULL default false comment '用户登记标识' , algorithm=inplace, lock=none; 二、执行过程剖析在Mysql5.6之后，mysql反对 Online DDL 操作。 Online DDL Support for Column Operations OperationIn PlaceRebuilds TablePermits Concurrent DMLOnly Modifies MetadataAdding a columnYesYesYes*NoDropping a columnYesYesYesNoRenaming a columnYesNoYes*YesReordering columnsYesYesYesNoSetting a column default valueYesNoYesYesChanging the column data typeNoYesNoNoDropping the column default valueYesNoYesYesChanging the auto-increment valueYesNoYesNo*Making a column NULLYesYes*YesNoMaking a column NOT NULLYes*Yes*YesNoModifying the definition of an ENUM or SET columnYesNoYesYes如图所示，所执行的增加列操作整个过程为： ...

作者：胡呈清 爱可生 DBA 团队成员，善于故障剖析、性能优化，集体博客：https://www.jianshu.com/u/a95...，欢送探讨。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 max_allowed_packet 示意 MySQL Server 或者客户端接管的 packet 的最大大小，packet 即数据包，MySQL Server 和客户端上都有这个限度。 数据包每个数据包，都由包头、包体两局部组成，包头由 3 字节的包体长度、1 字节的包编号组成。3 字节最多可能示意 2 ^ 24 = 16777216 字节（16 M），也就是说，一个数据包的包体长度必须小于等于 16M 。 如果要发送超过 16M 的数据怎么办？ 当要发送大于 16M 的数据时，会把数据拆分成多个 16M 的数据包，除最初一个数据包之外，其它数据包大小都是 16M。而 MySQL Server 收到这样的包后，如果发现包体长度等于 16M ，它就晓得本次接管的数据由多个数据包组成，会先把以后数据包的内容写入缓冲区，而后接着读取下一个数据包，并把下一个数据包的内容追加到缓冲区，直到读到完结数据包，就接管到客户端发送的残缺数据了。 那怎么算一个数据包？ 一个 SQL 是一个数据包返回查问后果时，一行数据算一个数据包解析的 binlog ，如果用 mysql 客户端导入，一个 SQL 算一个数据包在复制中，一个 event 算一个数据包上面咱们通过测试来探讨 max_allowed_packet 的理论影响。 导入 SQL 文件受 max_allowed_packet 限度吗？如果 SQL 文件中有单个 SQL 大小超过 max_allowed_packet ，会报错： ##导出时设置 mysqldump --net-buffer-length=16M，这样保障导出的sql文件中单个 multiple-row INSERT 大小为 16Mmysqldump -h127.0.0.1 -P13306 -uroot -proot --net-buffer-length=16M \--set-gtid-purged=off sbtest sbtest1 > /data/backup/sbtest1.sql##设置max_allowed_packet=1M##导入报错[root@localhost data]# mysql -h127.0.0.1 -P13306 -uroot -proot db3 < /data/backup/sbtest1.sqlmysql: [Warning] Using a password on the command line interface can be insecure.ERROR 1153 (08S01) at line 41: Got a packet bigger than 'max_allowed_packet' bytes导入解析后的 binlog 受 max_allowed_packet 限度吗？row 格局的 binlog，单个SQL批改的数据产生的 binlog 如果超过 max_allowed_packet，也会报错。 ...

前言在咱们日常开发过程中，有时候因为对索引列进行函数调用，导致索引生效。举个例子，比方咱们要按月查问记录，而当咱们 表中只存工夫，如果咱们应用如下语句，其中create_time为索引列 select count(*) from user where MONTH(create_time) = 5尽管可能查到正确的后果，但通过explain咱们会发现没走索引。因而咱们为了能确保应用索引，咱们可能会改成 select count(*) from user where create_time BETWEEN '2022-05-01' AND '2022-06-01';或者罗唆在数据库表中冗余一个月份的列字段，并对这个月份创立索引。如果咱们应用的mysql是5.7版本，咱们则能够应用mysql5.7版本提供的一个新个性--虚构列来达到上述成果 虚构列在mysql5.7反对2种虚构列virtual columns 和 stored columns 。两者的区别是virtual 只是在读行的时候计算结果，但在物理上是不存储，因而不占存储空间，且仅在InnoDB引擎上建二级索引，而stored 则是当行数据进行插入或更新时计算并存储的，是须要占用物理空间的，反对在MyISAM和InnoDB引擎创立索引 mysql5.7 默认的虚构列类型为virtual columns 1、创立虚构列语法ALTER TABLE 表名称 add column 虚构列名称 虚构列类型 [GENERATED ALWAYS] as (表达式) [VIRTUAL | STORED];2、应用虚构列注意事项a、衍生列的定义能够批改，但virtual和stored之间不能互相转换，必要时须要删除重建 b、虚构列字段只读，不反对 INSRET 和 UPDATE c、只能援用本表的非 generated column 字段，不能够援用其它表的字段 d、应用的表达式和操作符必须是 Immutable 属性，比方不能应用 CONNECTION_ID(), CURRENT_USER(), NOW() e、能够将已存在的一般列转化为stored类型的衍生列，但virtual类型不行；同样的，能够将stored类型的衍生列转化为一般列，但virtual类型的不行 f、虚构列定义不容许应用自增 (AUTO_INCREMENT)，也不容许应用自增基列 g、虚构列容许批改表达式，但不容许批改存储形式（只能通过删除从新创立来批改） h、如果虚构列用作索引，会有一个毛病值会存储两次。一次用作虚构列的值，一次用作索引中的值 3、虚构列的应用场景a、虚构列能够简化和对立查问，将简单条件定义为生成的列，能够在查问时间接应用虚构列（代替视图） b、存储虚构列能够用作实例化缓存，以用于动静计算成本昂扬的简单条件 c、虚构列能够模仿性能索引，并且能够应用索引，这对与无奈间接应用索引的列（JSON 列）十分有用。 示例因为mysql5.7也反对json列，因而本示例就以json和虚构列为例子演示一下示例 ...

曾几何时，“并发高就分库，数据大就分表”曾经成了解决 MySQL 数据增长问题的圣经。 面试官喜爱问，博主喜爱写，候选人也喜爱背，仿佛曾经造成了一个闭环。 但你有没有思考过，_分库分表真的适宜你的零碎吗？_ 分表在业务刚刚倒退起来的时候，流量全部打到了一个 MySQL 上，用户信息全落到了 user 表。 起初，user 表的数据量越来越大了。 于是，你做了一次垂直拆分，将原来的 user 表拆分成了新的 user 表和 user\_details 表。 这样一拆之后，用户的信息扩散到两个表，user 表的数据量一下就变小了，user 表数据量过大的问题临时就解决了。 但随着业务的倒退，线上的流量越来越大，单个 MySQL 曾经扛不住流量的压力了。 单个库承受不住压力的时候，就须要分库了。 分库顾名思义，分库就是将一个库拆成多个库，让多个库分担流量的压力。 拆成多个库也意味着进行了分表，也就是说分库肯定分表，分表不肯定分库。 咱们能够依据_偏利用_还是_偏 DB_，将分库分表的实现形式分成三种类型： JDBC 代理模式DB 代理模式Sharding On MySQL 的 DB 模式JDBC 代理模式JDBC 代理模式是一种无中心化的架构模式。ShardingSphere-JDBC 就是 JDBC 代理模式的典型实现。 通常以 jar 包模式提供服务，让客户端直连数据库，这种模式无需额定部署和依赖，可了解为增强版的 JDBC 驱动。 JDBC 代理模式尽管简略，但违反了 DB 通明的准则，侵入性比拟高，须要针对不同的语言编写不同的 Driver。 美团的 Zebra、MTDDL，阿里 TDDL 都是基于这种模式的实现。 DB 代理模式DB 代理模式是中心化的架构模式。ShardingSphere-Proxy 就是 DB 代理模式的经典实现。 这种模式旨在实现透明化的数据库代理端，并独立于利用部署，因为独立部署，所以对异构语言没有限度，不会对利用造成侵入。 ...

昆仑数据库的计算节点基于 PostgreSQL 研发，因此间接能够反对PostgreSQL 的连贯协定，所以应用 JDBC、ODBC 等通用的数据库连贯协定以及应用各类编程语言的 PostgreSQL 专有的连贯库的软件都能够连贯到昆仑数据库集群并且失常工作。 为了让本来应用 MySQL 的应用程序能够不须要批改也不须要从新编译就能连贯并且失常应用昆仑数据库，咱们开发了昆仑数据库的 MySQL 连贯协定，本文对此协定实现做一个简介。 总的来说，对于 KunlunBase 来说，连贯协定就是客户端与 KunlunBase 服务器通信的管道，MySQL 和 PostgreSQL 协定就是两种形态不同的管道，而其中传输的 SQL 语句和查问后果则实质上是雷同的。 也就是说 KunlunBase 反对的任何 SQL 语法和性能都能够在 MySQL 和PostgreSQL 这两种连贯协定中的任何一种连贯中传输到服务器集群中失常执行并收到其后果。 例如能够在 MySQL 连贯中发送 PostgreSQL 公有语法 SQL 或者规范 SQL 语句，包含 prepared statement 语法、存储过程语法、DDL语法等，并且失去遵循MySQL协定的后果，从而能够应用 MySQL 客户端库实现后果读取；也能够 在PostgreSQL 连贯中发送 KunlunBase 反对的任何 MySQL 公有语法（例如prepared statement、DML等）的 SQL语句或者规范 SQL 语句，并且失去遵循 PostgreSQL 的后果，从而能够应用 PostgreSQL 客户端库实现后果读取。 昆仑数据库MySQL协定反对的性能昆仑数据库MySQL协定反对所有罕用性能，包含文本和二进制协定，连贯验证（只反对mysql_native_password），数据压缩，prepared statement，字符集，错误处理，SSL连贯等。 一个Kunlun-server（计算节点）同时监听2个TCP端口 --- PostgreSQL协定的端口（默认5432）和MySQL协定的端口（默认5306），都能够通过配置文件自定义配置。 MySQL 和 PostgreSQL 客户端应用对立的用户名和明码连贯 Kunlun-server，不管应用哪一种连贯协定，Kunlun-server收到TCP连贯申请后，会启动本端口的服务端协定（即 PostgreSQL 或者 MySQL）解决模块，实现连贯验证，建设起无效的数据库连贯。 ...

KunlunBase 数据库集群在数据库外部反对读写拆散，并且对利用通明，用户应用程序不须要做任何批改就能够应用数据库的读写拆散性能，从而进步整个零碎性能及投资回报率。 一、产品架构KunlunBase 的整体架构次要由计算层和存储层形成，计算层负责 SQL 响应、解释、执行等，存储层负责数据的存储管理，存储层的数据采纳多正本存储机制，备机（从正本）通过强同步技术保持数据与主节点一致性。 备机的存储节点的硬件配置与主节点统一，在个别的生产应用过程中，备机节点的次要目标是作为主机呈现故障后的替换节点，不承受应用程序的间接数据处理申请，因而，在非故障切换的状况下，备机的存储节点资源利用率绝对较低。 KunlunBase 的读写拆散计划是通过路由只读操作到备节点，从而能够缩小计算节点的资源竞争，升高主节点负载。 二、实现原理KunlunBase 的读写拆散在计算层的近程查问优化器内实现的，当用户的SQL同时满足如下条件： 以后SQL类型为select；SQL中不蕴含用户自定义函数（即create function语句创立的函数）,除非以后事务为只读事务；如果不在事务中（autocommit=on），则容许读写拆散；如果语句在显示事务中，则要满足： 如果在只读事务中，则容许读写拆散；如果在读写事务中，则该事务尚未更新过任何数据；近程查问优化器就会将相应的SQL 执行打算下发到从备机的节点上执行 KunlunServer 会依据以下规定抉择发送select语句到指标存储集群的哪个备机节点： 依据节点权重值抉择 （ro_weight)依据网络提早(ping)依据主从正本的数据一致性提早（latency)三、配置施行场景阐明：某 OLTP 业务零碎有大量的查问操作，在业务高峰期数据库响应速度变慢，导致了业务的性能问题。经查看发现存储节点主节点的存储节点的 IO 资源利用达到瓶颈，但备机节点的 IO 资源利用率低。 以上场景能够通过读写拆散计划解决零碎性能问题，不须要批改利用， 不须要减少硬件配置，通过读写拆散的施行，能够解决性能问题。 施行步骤：第一步：设置参数，启用读写拆散。（依据状况选一种级别） 设置 enable_replica_read = on (on 开启读写， off 敞开）。 用户级别开启：(用户登录后失效） alter user abc setenable_replica_read = true;Session 级别开启：（以后 session 失效） set enable_replica_read=on;数据库级别开启：（对该计算节点的所有session无效） 在 pg_hba.conf 文件中设置 enable_replica_read=on;第二步：登录数据库，配置读写拆散策略。 设置如下参数，启动读写拆散策略： replica_read_ping_threshold，计算节点到备节点的ping提早阈值，0示意不关怀；replica_read_latency_threshold，主备同步提早的阈值，0示意不关系；replica_read_order，抉择备机优先级：0，按权重；1、按ping提早；2、按主备同步提早；replica_read_fallback，备机抉择的回退策略(如果备机不能拜访）；replica_read_fallback=0，间接报错，replica_read_fallback=1，任意抉择一个备机进行拜访，replica_read_fallback=2，抉择主机进行拜访。 第三步：查看&设置权重（可选）。 在演示的环境中 ，数据集群由两个 shard 组成（shard1 , shard2) ,shard1 的shard_id=1, shard1 蕴含3个正本（id 为1，2， 3，id为1的是主节点，id为2和3的是备机。 通过配置， 能够设置只读操作的首先备机 ...

随着监控助理忽然提醒很多数据库连贯谬误： 排查数据库谬误便随之提上了日程。 重启大法不得不说，有时候重启大法还是挺好使的。所以咱们上来也尝试重启mysql $ /usr/local/etc/rc.d/mysql-server stop$ /usr/local/etc/rc.d/mysql-server start再次连贯，数据数据间接就连不上了。此时便须要来到正确的轨迹上：看报错内容，依据报错内容来排查起因，解决问题。 谬误日志很遗憾的是，mysql在启动过程中，即便启动失败，也不会报什么的错误信息。咱们查看mysql是否胜利启动则须要应用mysql-server status命令： root@YunzhiTest:/usr/home/panjie # /usr/local/etc/rc.d/mysql-server statusmysql is not running.而是否打印日志，以及日志的地位放在哪，则须要咱们进行手动配置。在mysql服务胜利启动的前提下，咱们其实是能够应用mysql的相干命令来查看以后的配置文件地位的，无奈以后mysql并没有胜利启动，所以此时则须要借助一些查问软件或是当初装置mysql应用的工具（比方FreeBSD的ports)来查找mysql的配置文件地位了。在FreeBSD中，mysql的配置文件位于/usr/local/etc/mysql中： root@YunzhiTest:/usr/home/panjie # cd /usr/local/etc/mysql/root@YunzhiTest:/usr/local/etc/mysql # lskeyring my.cnf my.cnf.sample而后咱们备份一个配置文件cp my.cnf my.cnf.bak后再对其进行编辑： [mysqld]log = /var/log/mysql/mysqld.loglog-error = /var/log/mysql/error.loguser = mysqlport = 3306在 mysqld 下减少两项：log及log-error，别离存个别日志及谬误日志。同时因为以后mysql启动的用户是mysql，还须要保障mysql用户对相干日志门路领有相对权限： $ mdkir /usr/log/mysql$ chown mysql:mysql /usr/log/mysql查看日志此时咱们再次启动mysql 服务，则能够查看在/var/log/mysql/下生成的error.log文件了： $ /usr/local/etc/rc.d/mysql-server start其比拟重要的错误信息如下： 2022-07-11T14:22:25.946391Z 0 [Note] InnoDB: Rollback of non-prepared transactions completed2022-07-11T14:22:25.946435Z 0 [Note] InnoDB: Setting file '/var/db/mysql/ibtmp1' size to 128 MB. Physically writing the file full; Please wait ...2022-07-11T14:22:25.947132Z 0 [Note] InnoDB: Progress in MB: 1002022-07-11T14:22:26.085805Z 0 [Warning] InnoDB: Retry attempts for writing partial data failed.2022-07-11T14:22:26.085855Z 0 [ERROR] InnoDB: Write to file /var/db/mysql/ibtmp1failed at offset 133169152, 1048576 bytes should have been written, only 0 were written. Operating system error number 28. Check that your OS and file system support files of this size. Check also that the disk is not full or a disk quota exceeded.2022-07-11T14:22:26.085940Z 0 [ERROR] InnoDB: Error number 28 means 'No space left on device'2022-07-11T14:22:26.085951Z 0 [Note] InnoDB: Some operating system error numbers are described at http://dev.mysql.com/doc/refman/5.7/en/operating-system-error-codes.html2022-07-11T14:22:26.085968Z 0 [ERROR] InnoDB: Could not set the file size of '/var/db/mysql/ibtmp1'. Probably out of disk space上述谬误大略就是在说一个问题：磁盘空间满了，此问题导致mysql无奈启动。 ...

原文地址: 【MySQL 源码】UNION 比 UNION ALL 的性能差很多吗? 欢送拜访我的集体博客: http://blog.duhbb.com/ 引言本文从源码角度剖析了一下 MySQL 中 union 和 union all 的区别;得出了以下论断: union 和 union all 都会创立长期表, 然而又不太一样; 二者的查问打算不一样;union 默认会创立一个以返回列作为 key 的长期表, 所谓过滤就是将数据插入这个长期表; 长期表装数据的容器实际上是一个 unordered_set; 有一种存储引擎叫做长期表; union all 则是间接读取表的数据并返回给客户端, 不走长期表; union all 和 union 的场景还是得依据须要来判断, 如果没有 distinct 的需要话, 数据又不多, 能够思考应用 union all. Union 和 Union All 的区别Union 和 Union All 之间的惟一区别是 Union All 不会删除反复的行或记录, 而是从所有表中抉择满足您的具体查问条件的所有行并将它们组合到后果表中. UNION 不适用于具备文本数据类型的列. 而 UNION ALL 实用于所有数据类型列. MySQL 官网介绍MySQL 官网文档在介绍 12.5 Non-Subquery UNION Execution 是这么说的: ...

1、redo log是MySQLEngine层，InnoDB存储引擎特有的日志。又称重做日志。 2、redo log是物理日志。能够了解为一个具备固定空间大小的队列，将被循环复制。 实例 root@test:/var/lib/mysql# pwd/var/lib/mysqlroot@test:/var/lib/mysql# ls -lstr ib_logfile*49152 -rw-r----- 1 mysql mysql 50331648 Dec 28 15:45 ib_logfile149152 -rw-r----- 1 mysql mysql 50331648 Jan 3 12:53 ib_logfile0root@test:/var/lib/mysql# du -sh ib_logfile*48M ib_logfile048M ib_logfile1root@test:/var/lib/mysql#以上就是mysql中redo log的介绍，心愿对大家有所帮忙。

1、标识列不肯定要和主键搭配，但要求是key。 2、一个表最多有一个标识列。 3、标识列的类型只能是数值型。 通过SET auto_increment_increment=3，标识列能够设置步长。 4、起始值可通过手动插入设置。 实例 DROP TABLE IF EXISTS tab_id; CREATE TABLE tab_id(id INT PRIMARY KEY AUTO_INCREMENT,NAME VARCHAR(20)); INSERT INTO tab_id VALUES(NULL,'john');#可反复执行插入INSERT INTO tab_id(NAME) VALUES('lucy');SELECT * FROM tab_id; #自增步长SET auto_increment_increment=3;以上就是mysql标识列的特点，心愿对大家有所帮忙。

1、mysql的事务分为显式事务和隐式事务。默认的事务是隐式事务，变量autocommit在操作时会主动关上、提交和回滚。 2、显式事务由咱们本人管制事务的开启，提交，回滚等操作。 实例 -- 看下以后autocommit的状态是，默认是on状态mysql> show variables like 'autocommit';+---------------+-------+| Variable_name | Value |+---------------+-------+| autocommit | ON |+---------------+-------+1 row in set (0.01 sec) -- 插入一条数据mysql> insert into ajisun values(1,'阿纪');Query OK, 1 row affected (0.00 sec)mysql> rollback; -- 执行rollback 也是没有成果的，还是可能查问到插入的数据（不须要咱们手动管制commit）mysql> select * from ajisun;+------+--------+| id | name |+------+--------+| 1 | 阿纪 |+------+--------+1 row in set (0.00 sec)以上就是mysql两种事务类型，心愿对大家有所帮忙。

1、读写拆散，缓解数据库压力(主数据库用于数据写入，数据库用于数据读取)。 2、一主多从，零碎可扩展性和可用性高。 3、数据备份容灾，异地双活，保障主库异样随时切换，进步零碎容错能力。 实例 从上执行mysql -uroot show slave stauts\G 看是否有 Slave_IO_Running: Yes Slave_SQL_Running: Yes 还需关注 Seconds_Behind_Master: 0 //为主从提早的工夫 Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error:主服务器上 binlog-do-db= //仅同步指定的库 binlog-ignore-db= //疏忽指定库 从服务器上 replicate_do_db= //仅同步指定的库 replicate_ignore_db= //疏忽指定库 replicate_do_table= replicate_ignore_table= replicate_wild_do_table= //如aming.%, 反对通配符% replicate_wild_ignore_table= 主上 mysql -uroot aming select count(*) from db; truncate table db; 到从上 mysql -uroot aming select count(*) from db; 主上持续drop table db; 从上查看db表以上就是mysql两种事务类型，心愿对大家有所帮忙。

1、用于主从复制。在主从构造中，binlog作为操作记录从master发送到slave，slave服务器从master收到的日志保留在relaylog中。 2、用于数据备份。数据库备份文件生成后，binlog保留了数据库备份后的详细信息，以便下一次备份能够从备份点开始。 实例 # at 154 #170708 9:24:02 server id 12345 end_log_pos 219 CRC32 0x30763ffe Anonymous_GTID last_committed=0 sequence_number=1 SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/; # at 219 #170708 9:24:02 server id 12345 end_log_pos 313 CRC32 0x4d0140b3 Query thread_id=5 exec_time=0 error_code=0 SET TIMESTAMP=1499477042/*!*/; SET @@session.pseudo_thread_id=5/*!*/; SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/; SET @@session.sql_mode=1436549152/*!*/; SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\C utf8 *//*!*/; SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/; SET @@session.lc_time_names=0/*!*/; SET @@session.collation_database=DEFAULT/*!*/; create database test /*!*/; SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/; DELIMITER ; # End of log file /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;以上就是mysql中binlog的应用场景，心愿对大家有所帮忙。 ...

索引的原理是将无序的数据转化为有序的查问。 1、排序创立索引列的内容。 2、生产排序后果的倒排表。 3、在倒排表内容上拼上数据地址链。 4、查问赎回时，先取倒排内容，再取出数据地址链，从而取出具体数据。 实例 CREATE TABLE articles ( id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY, title VARCHAR(200), body TEXT, FULLTEXT (title,body) )engine=myisam charset utf8; INSERT INTO articles (title,body) VALUES ('MySQL Tutorial','DBMS stands for DataBase ...'), ('How To Use MySQL Well','After you went through a ...'), ('Optimizing MySQL','In this tutorial we will show ...'), ('1001 MySQL Tricks','1. Never run mysqld as root. 2. ...'), ('MySQL vs. YourSQL','In the following database comparison ...'), ('MySQL Security','When configured properly, MySQL ...');以上就是mysql索引的基本原理，心愿对大家有所帮忙。 ...

1、又称连贯查问，连贯多个表中的数据，取得后果集。当一个表不能满足查问后果时，须要应用联结查问。 2、前提，联结表之间必须有逻辑相关性。 实例 -- 示例：select orders.order_id, orders.amt, customer.cust_name, customer.tel_nofrom orders, customerwhere orders.cust_id = customer.cust_id; -- 起别名select a.order_id, a.amt, b.cust_name, b.tel_nofrom orders a, customer bwhere a.cust_id = b.cust_id;以上就是mysql联结查问的介绍，心愿对大家有所帮忙。

1、数据库事务会升高数据库的性能。为了保证数据的一致性和隔离性，事务须要锁定事务。 2、如果其余事务须要操作这部分数据，必须期待最初一个事务完结(提交，回滚)。 实例 create table acct( acct_no varchar(32), acct_name varchar(32), balance decimal(16,2)); insert into acct values ('0001','Jerry', 1000), ('0002','Tom', 2000); start transaction; -- 启动事务update acct set balance = balance - 100 where acct_no = '0001'; -- 模仿扣款人update acct set balance = balance + 100 where acct_no = '0002'; -- 模仿收款人commit; -- 事务提交rollback; -- 事务回滚以上就是mysql事务对效率的影响，心愿对大家有所帮忙。

1、InoDB必须用于表存储引擎。 2、表格字符集默认应用utf8，必要时应用utf8mb4。 3、禁止应用存储过程、视图、触发器和event。 4、禁止在数据库中存储大文件。 如照片，能够将大文件存储在对象存储系统和数据库中。 禁止在线环境进行数据库压力测试。 测试、开发、在线数据库环境必须隔离。 实例 阐明：1）通用，无乱码危险，汉字3字节，英文1字节2）`utf8mb4` 是 `utf8` 的超集，有存储 4 字节例如表情符号时，应用它以上就是mysql应用的根底标准，心愿对大家有所帮忙。

1、单实例表的数量必须管制在2000个以内。 2、表分表的数量必须管制在1024个以内。 3、表必须有主键，倡议应用UNSIGNED整数作为主键。 潜在坑:删除无主键表，如果是row模式的主从架构，会挂在库里。 4、禁止应用外键。如果要保障完整性，应该通过应用程序来实现。 实例 create table class( major varchar(16) comment '业余', name char(8) comment '班级名', nums int comment '人数');以上就是mysql表的设计规范，心愿对大家有所帮忙。

1、decimal类型为小数，禁止应用float和double。 float和double存在存储时精度损失的问题，在比拟值时很可能会失去不正确的后果。 2、如果存储的数据范畴超过decimal的范畴，倡议将数据拆分成整数和小数离开存储。 3、按业务辨别应用tinyint/int/bigint，别离占1/4/8字节。 char/varchar按业务辨别应用。 实例 Demo:mysql> use school; #抉择数据库schoolmysql> create table class6(class_id integer(5) zerofill, class_name varchar(128), class_teacher varchar(64) ); #创立表class6 mysql> insert into class0 values(1,'三年级六班','张老师'); mysql> select * from class0 ;+-------+------------+---------+| id | name | teacher |+-------+------------+---------+| 00001 | 三年级六班 | 张老师 |+-------+------------+---------+1 row in set (0.00 sec)以上就是mysql列的应用标准，心愿对大家有所帮忙。

作者：王祥 爱可生 DBA 团队成员，次要负责 MySQL 故障解决和性能优化。对技术执着，为客户负责。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 -- 背景信息业务监控发现交易的均匀响应工夫比之前慢了近一倍，须要排查一下数据库是不是响应慢了。生产MySQL版本为8.0.18，一主3从半同步复制。 故障剖析首先比照查看了交易失常时段与出现异常的时段各项监控指标（cpu、qps、tps、磁盘IO等）都未发现显著的变动。接下来查看slow log发现了较多的慢SQL，而且是一般的insert语句，执行时长超过1秒。进一步察看比照发现，每次insert慢都是呈现在同一秒，insert慢语句条数根本在30条左右，而且呈现的距离都是两分钟或两分钟的倍数。依据这个法则第一感觉是不是定时工作引起的问题。通过对定时工作的排查最终定位到监控脚本，监控脚本为两分钟执行一次。接下来须要排查一下，具体是哪局部导致insert慢。为了疾速复现问题，间接在一个从库上应用mysqlslap进行压测。从业务那得悉问题insert语句每秒会有60-80次的写入量，压测语句如下： mysqlslap -h127.0.0.1 -uroot -p --concurrency=80 --iterations=10 --create-schema=userdb --query=/root/test.sql --engine=innodb --number-of-queries=50000#test.sqlinsert into userdb.ps (clo1, clo2, clo3, clo4, clo4, clo5, clo6) values (substring(MD5(RAND()),1,20), 'fffffdddddddddd', '0', '', 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaddddddddd', '2022-06-17 16:00:38.145', 34);在压测期间执行监控脚本，一边查看slow log，能稳固复现生产的景象。通过排除法，最终定位到几个应用information_schema.processlist表的语句导致了insert慢。那information_schema.processlist为什么会导致insert慢呢？带着这个问题去查看一下官网对information_schema.processlist的形容。 The default SHOW PROCESSLIST implementation iterates across active threads from within the thread manager while holding a global mutex. This has negative performance consequences, particularly on busy systems. The alternative SHOW PROCESSLIST implementation is based on the Performance Schema processlist table. This implementation queries active thread data from the Performance Schema rather than the thread manager and does not require a mutex.依据官网的阐明：在应用默认的show processlist会持有全局互斥锁，在业务忙碌的零碎上会导致性能问题。同时也给出了解决办法，应用Performance Schema中的processlist代替，此形式不会产生全局互斥锁。 ...

曾几何时，“并发高就分库，数据大就分表”曾经成了解决 MySQL 数据增长问题的圣经。 面试官喜爱问，博主喜爱写，候选人也喜爱背，仿佛曾经造成了一个闭环。 但你有没有思考过，分库分表真的适宜你的零碎吗？ 分表在业务刚刚倒退起来的时候，流量全副达到了一个 MySQL 上，用户信息全落到了 user 表。 起初，user 表的数据量越来越大了。 于是，你做了一次垂直拆分，将原来的 user 表拆分成了新的 user 表和 user_details 表。 这样一拆之后，用户的信息扩散到两个表，user 外表的数据量一下就变小了，user 外表数据量过大的问题临时就解决了。 但随着业务的倒退，线上的流量越来越大，单个 MySQL 曾经扛不住流量的压力了。 当个库承受不住压力的时候，就须要分库了。 分库顾名思义，分库就是将一个库拆成多个库，让多个库分担流量的压力。 拆成多个库也意味着进行了分表，也就是说分库肯定分表，分表不肯定分库。 咱们能够依据偏利用还是偏 DB，将分库分表的实现形式分成三种类型： JDBC 代理模式DB 代理模式Sharding On MySQL 的 DB 模式JDBC 代理模式JDBC 代理模式是一种无中心化的架构模式。ShardingSphere-JDBC 就是 JDBC 代理模式的典型实现。 通常以 jar 包含提供服务，让客户端直连数据库，这种模式无需额定部署和依赖，可了解为增强版的 JDBC 驱动。 JDBC 代理模式尽管简略，但违反了 DB 通明的准则，侵入性比拟高，须要针对不同的语言编写不同的 Driver。 美团的 Zebra、MTDDL，阿里 TDDL 都是基于这种模式的实现。 DB 代理模式DB 代理模式是中心化的架构模式。ShardingSphere-Proxy 就是 DB 代理模式的经典实现。 这种模式旨在实现透明化的数据库代理端，并独立于利用部署，因为独立部署，所以对异构语言没有限度，不会对利用造成侵入。 ...

**force index本周理解到MySQL索引优化器有时候并不会用到最优的索引，当然这时候大多数时候是因为你索引创立的不合理，导致mysql没有找到最有索引，最优解是优化索引，其次能够应用force index强制以后查问语句应用指定索引 **using filesortexplain时在Extra中发现有using filesort，查问效率必然不会太好。这就意味着无奈应用索引排序，升高了查问效率。 本周只是理解到了MySQL的这两个知识点，并未深刻学习，留坑待填。

1、倡议将单张表索引数管制在5个以内。 2、组合索引字段数不倡议超过5个。 3、join禁止超过三个表。 须要join的字段，数据类型必须相对统一。 4、严禁左含糊或全含糊，如须要用搜索引擎解决。 5、如果有orderby场景，请留神索引的有序性。 实例 1）consts 单表中最多只有一个匹配行（主键或者惟一索引），在优化阶段即可读取到数据。2）ref 指的是应用一般的索引（normal index）。3）range 对索引进行范畴检索。反例：explain 表的后果，type=index，索引物理文件全扫描，速度十分慢，这个 index 级别比拟 range 还低，与全表扫描是小巫见大巫。以上就是mysql索引标准的整顿，心愿对大家有所帮忙。更多mysql学习指路：Mysql

1、禁止应用select*，只获取必要的字段。 2、insert必须指定字段，禁止应用insert into T values()。 3、不要用count(列名)或count(常量)代替count(*)。 4、不得应用外键和级联，所有外键概念必须在应用层解决。 实例 阐明：`NULL` 与任何值的间接比拟都为 `NULL`。1） `NULL<>NULL` 的返回后果是 `NULL`，而不是 `false`。2） `NULL=NULL` 的返回后果是 `NULL`，而不是 `true`。3） `NULL<>1` 的返回后果是 `NULL`，而不是 `true`。以上就是mysql中SQL语句的应用留神，心愿对大家有所帮忙。更多mysql学习指路：Mysql

1、join将合乎on条件的数据连贯到一个新的表中。 2、where首先通过笛卡尔积将两个表连贯到一个新的表中，而后判断条件，并将符合条件的数据行成一个表。 实例 select m.menu_id,m.sort_id,s.sort_id,s.sort_name from menu m join sort s on m.sort_id=s.sort_id and m.sort_id=2;select m.menu_id,m.sort_id,s.sort_id,s.sort_name from menu m join sort s on m.sort_id=s.sort_id where m.sort_id=2;select m.menu_id,m.sort_id,s.sort_id,s.sort_name from menu m inner join sort s on m.sort_id=s.sort_id and m.sort_id=2;select m.menu_id,m.sort_id,s.sort_id,s.sort_name from menu m inner join sort s on m.sort_id=s.sort_id where m.sort_id=2;以上就是mysql中join和where的区别，心愿对大家有所帮忙。更多mysql学习指路：Mysql

1、有些视图是不可更新的，因为这些视图的更新不能惟一有意义地转换为相应的根本表。 2、一般来说，能够更新行列子集视图。除列子集视图外，实践上还能够更新一些视图。 实例 -- 创立视图 ldq_t1CREATE VIEW ldq_t1 ASSELECT *FROM t3WHERE id1 > 10 WITH CHECK OPTION ;-- 查问ldq_t1中的所有后果SELECT * FROM ldq_t1; -- 创立视图 ldq_t2CREATE VIEW ldq_t2 ASSELECT *FROM ldq_t1WHERE id1 < 30 WITH LOCAL CHECK OPTION ; -- 创立视图 ldq_t3CREATE VIEW ldq_t3 ASSELECT *FROM ldq_t1WHERE id1 < 30 WITH CHECK OPTION ; -- 更新视图ldq_t2（只有ldq_t2中存在的数据都能够更新）SELECT * FROM ldq_t2; -- 查看ldq_t2以后记录UPDATE ldq_t2 SET id1=5 WHERE id2=22; -- 能够执行胜利UPDATE ldq_t2 SET id1=35 WHERE id2=22; -- 将会报错CHECK OPTION failed(因为执行该语句之后，id2=22记录将从ldq_t2隐没)UPDATE ldq_t2 SET id1=28 WHERE id2=22; -- 能够执行胜利 -- 更新ldq_t3SELECT * FROM ldq_t3;UPDATE ldq_t3 SET id1=5 WHERE id2=22; -- 将会报错CHECK OPTION failed（因为数据更新之后，必须还要保障其依然在ldq_t3和ldq_t1之中,该语句执行后id2=22记录将从ldq_t1隐没）UPDATE ldq_t3 SET id1=15 WHERE id2=22; -- 可能执行胜利UPDATE ldq_t3 SET id1=35 WHERE id2=22; -- 将会报错CHECK OPTION failed（因为执行该语句之后，id2=22记录将从ldq_t3隐没）DELETE FROM ldq_t3 WHERE id2=22; -- 执行胜利以上就是mysql更新视图的限度，心愿对大家有所帮忙。更多mysql学习指路：Mysql ...

1、应用tar包装文件夹备份。数据库能够间接保留data文件夹，然而占用空间大，能够用tar包装压缩保留。 [root@localhost ~]# systemctl stop mysqld[root@localhost ~]# tar Jcvf /opt/mysql-$(date +%F).tar.xz /usr/local/mysql/data/[root@localhost ~]# ls /opt/mysql-2021-10-25.tar.xz[root@localhost ~]# systemctl start mysqld2、应用mysqldump工具备份，更灵便地管制备份内容，例如，能够独自备份几个表或库。 [root@localhost ~]# mysqldump -u root -p123456 --databases info > /opt/info.sql #对info库进行备份[root@localhost ~]# ls /opt/info.sql以上就是mysql常见的备份办法，心愿对大家有所帮忙。更多mysql学习指路：Mysql

1、尽量抉择区分度高的列来建设索引。 2、频繁查问列适宜建设索引。 3、遇到联结索引时，想想最右边的匹配准则。 4、like含糊查问时，%在后面时才会应用索引，另外两种状况都会使索引生效。 实例 select * from USER us where name l like ‘公众号程序员fly%’ //name上有索引的话会应用到name上的索引select * from USER us where name l like ‘%公众号程序员fly’ //name上有索引的话索引会生效转为全表扫描select * from USER us where name l like ‘%公众号程序员fly%’ //name上有索引的话索引会生效转为全表扫描以上就是mysql索引建设的准则，心愿对大家有所帮忙。更多mysql学习指路：Mysql

1、Memory表的每个表能够有多达32个索引。 每个索引16列，以及500字节的键长度。 2、存储引擎执行HASH和BTREE缩影。 3、表中能够有非惟一的键值。 4、表采纳固定的记录长度格局。 5、不反对BLOB或TEXT列。 实例 mysql> CREATE TABLE lookup (id INT, INDEX USING HASH (id)) ENGINE = MEMORY; mysql> CREATE TABLE lookup (id INT, INDEX USING BTREE (id)) ENGINE = MEMORY;以上就是mysql中Memory存储引擎的个性，心愿对大家有所帮忙。更多mysql学习指路：Mysql

1、查问语句中所需的列在索引中，这样查问后果就能够在索引的数据结构中找到。 2、因为笼罩索引能够缩小树木的搜寻次数，显著进步查问性能，因而应用笼罩索引是一种罕用的性能优化办法。 实例 +----+-------------+------------+------+-----------------------+--------------+---------+-------+------+-------------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+------------+------+-----------------------+--------------+---------+-------+------+-------------+| 1 | SIMPLE | user_group | ref | group_id,group_id_uid | group_id_uid | 4 | const | 5378 | Using index |+----+-------------+------------+------+-----------------------+--------------+---------+-------+------+-------------+以上就是mysql笼罩索引的了解，心愿对大家有所帮忙。更多mysql学习指路：Mysql

1、是开源数据库，应用C和C++编写。 2、可能在许多不同的平台上工作。 3、为C、C++、Python、Java、Perl、PHP、Ruby提供多种语言的API。 4、存储构造低劣，运行速度快。 5、性能全面丰盛。 实例 CHANGE MASTER TOMASTER_HOST='ip',MASTER_USER='repl',MASTER_PASSWORD='repl',MASTER_LOG_FILE='binlog.000002',MASTER_LOG_POS=1024;以上就是mysql数据库的特点，心愿对大家有所帮忙。更多mysql学习指路：Mysql

原文地址: 【MySQL 文档翻译】了解查问打算 欢送拜访我的博客: http://blog.duhbb.com/ 官网文档MySQL 官网文档地址: 8.8 Understanding the Query Execution Plan 引言MySQL 优化器会依据 SQL 语句中的表, 列, 索引和 WHERE 子句中的条件的详细信息, 应用许多技术来无效地执行 SQL 查问. 能够在不读取所有行的状况下对一个微小的表执行查问; 能够在不比拟每个行组合的状况下执行波及多个表的连贯. 优化器抉择执行最无效查问的一组操作称为 查问执行打算 (query execution plan), 也称为 EXPLAIN plan. 你的指标是意识到 EXPLAIN 打算表明查问已优化好, 如果发现一些低效的操作, 能够通过学习 SQL 语法和索引技术来改良查问打算. 应用 EXPLAIN 优化查问EXPLAIN 语句提供无关 MySQL 如何执行指标语句的信息: EXPLAIN 能够与 SELECT, DELETE, INSERT, REPLACE 和 UPDATE 语句一起应用.当 EXPLAIN 与可解释语句 (explainable statement) 一起应用时, MySQL 会显示来自优化器的无关语句执行打算的信息. 也就是说, MySQL 解释了它将如何解决该语句, 包含无关表 如何连贯 以及以 何种程序 连贯的信息. 无关应用 EXPLAIN 获取执行打算信息的信息, 请参阅第 8.8.2 节 EXPLAIN 输入格局.当 EXPLAIN 与 FOR CONNECTION connection_id 而不是可解释的语句一起应用时, 它显示在命名连贯中执行的语句的执行打算. 请参阅第 8.8.4 节 获取命名连贯的执行打算信息.对于 SELECT 语句, 应用 SHOW WARNINGS 可是使 EXPLAIN 生成并显示的附加执行打算信息. 请参阅第 8.8.3 节 扩大 EXPLAIN 输入格局.EXPLAIN 对于查看波及分区表的查问很有用. 请参阅第 24.3.5 节 获取无关分区的信息.FORMAT 选项可用于抉择输入格局. TRADITIONAL 以表格格局显示输入. 如果没有 FORMAT 选项, 这是默认设置. 当 FORMAT 的选项值为 JSON 能够显示 JSON 格局的信息.在 EXPLAIN 的帮忙下, 能够查看应该在哪里为表增加索引, 以便通过应用索引查找行来更快地执行语句. 您还能够应用 EXPLAIN 查看优化器是否以最佳程序连贯表. 要提醒优化器应用与语句中表命名程序绝对应的连贯程序, 请以 SELECT STRAIGHT_JOIN 语句结尾, 而不是 SELECT. (请参阅 第 13.2.10 节 SELECT 语句.) 然而, STRAIGHT_JOIN 可能会阻止应用索引, 因为它禁用了 半连贯转换. 看第 8.2.2.1 节 应用半连贯转换优化 IN 和 EXISTS 子查问谓词. ...

问题背景咱们在开启多线程对数据库进行操作的时候，先批量对数据进行删除，而后再新增，原本想着是思考到不走更新，性能会晋升，然而执行的时候发现报错，执行的sql期待超时，阻塞了过程，dbcp连接池被打满，数据库表拜访不可用。针对这个问题，咱们进行了深刻的开掘，逐步解开了问题的假相。 看下具体的业务实现细节 表定义当初导⼊⼀批数据A的汇合,A的定义如下所示:接下来复现问题操作 依据t1的值查问表a中有没有对应的记录如果有值，则更新t2的值如果没查到后果，则执行insert插入操作这里批量操作咱们采纳了多线程的形式来执行 问题复现step1 - ⾸先插⼊测试数据step2 - 咱们开启两个窗⼝去模仿死锁。Session1:Session2:此时,Session 1和Session 2都会对区间(20, ⽆穷⼤)加锁, 因为间隙锁只是⽤来防⽌其余事务在区间中插⼊数据。step3 - Session1持续插⼊操作:此时Session1阻塞（因为Session2持有间隙锁）。 step4- 紧接着Session2持续插⼊操作:此时Session2死锁，因为Session1持有间隙锁。⽽咱们的代码⾥⾯，因为波及到多线程在事务⾥进⾏先删除后插⼊的操作，就会发⽣死锁。 不走更新操作，先删除，后插入，保障只有2次数据库操作。 问题起因查问相干材料得悉，引起死锁的起因是MYSQL的间隙锁。间隙锁 间隙锁（Gap Lock）是Innodb在可反复读提交下为了解决幻读问题时引⼊的锁机制，幻读的问题存在是因为新增或者更新操作，这时如果进⾏范畴查问的时候（加锁查问），会呈现不⼀致的问题，这时使⽤不同的⾏锁曾经没有方法满⾜要求，须要对⼀定范畴内的数据进⾏加锁，间隙锁就是解决这类问题的。在可反复读隔离级别下，数据库是通过⾏锁和间隙锁独特组成的（next-key lock）来实现的。⾏锁和间隙锁的定义如下所示： record lock：⾏锁，也就是仅仅锁着独自的⼀⾏。gap lock：间隙锁，仅仅锁住⼀个区间（留神这⾥的区间都是开区间，也就是不包含边界值)。next-key lock：record lock+gap lock，所以next-key lock也就半开半闭区间，且是下界开，上界闭。加锁规定个性加锁规定有⼀些个性，其中咱们须要关注的有： 加锁的根本单位是（next-key lock）,他是前开后闭准则查找过程中拜访的对象会减少锁间隙锁仅阻⽌其余事务插⼊间隙。在删除数据的时候，会去加间隙锁，然而多个事务是能够同时对⼀个间隙去加锁的，⽽如果须要对该间隙进⾏插⼊，则须要期待锁开释。解决形式1、将事务隔离级别将为read commit. 间隙锁只存在于可反复读的隔离级别下，因为要防⽌幻读。这个⽅法不事实，不可能为了这个问题 把整个线上数据库隔离级别给改掉。2、防止先删除后插⼊的操作. 批改代码，防止先删除后插⼊的操作。就义性能，在业务中，先依据唯⼀索引查出存在的记录，而后对存在的记录进⾏依据主键Id在循环中更新，对于不存在的记录进⾏批量插⼊。

https://zhuanlan.zhihu.com/p/...

https://blog.51cto.com/u_1505...

https://segmentfault.com/a/11...

介绍worm是一款不便易用的Go语言ORM库，worm具备应用简略，运行性能高，功能强大的特点。具体特色如下： 通过Struct的Tag与数据库字段进行映射，让您免于常常拼写SQL的麻烦。反对Struct映射、原生SQL以及SQLBuilder三种模式来操作数据库，并且Struct映射、原生SQL以及SQLBuilder可混合应用。Struct映射、SQL builder反对链式API，可应用Where, And, Or, ID, In, Limit, GroupBy, OrderBy, Having等函数结构查问条件。可通过Join、LeftJoin、RightJoin来进行数据库表之间的关联查问。反对事务反对，可在会话中开启事务，在事务中能够混用Struct映射、原生SQL以及SQL builder来操作数据库。反对预编译模式拜访数据库，会话开启预编译模式后，任何SQL都会应用缓存的Statement，能够晋升数据库拜访效率。反对应用数据库的读写拆散模式来拜访一组数据库。反对在Insert，Update，Delete，Get, Find操作中应用钩子办法。反对SQL日志的输入，并且可通过日志钩子自定义SQL日志的输入，日志钩子反对Context。可依据数据库主动生成库表对应的Model构造体。目前worm反对的数据库有：mysql、postgres、sqlite、sqlserver。 代码获取go get github.com/haming123/wego/worm 应用select办法指定字段应用worm.Model().Update()办法来更新数据库时，则worm缺省会更新实体类对应的全副字段。若只心愿更新指定的字段，能够应用若Select办法指定须要更新的字段： func demoModelUpdate() { var user = User{Name:"name1", Age: 21, Created: time.Now()} _, err := worm.Model(&user).Select("name", "age").ID(1).Update() if err != nil{ log.Println(err) return }}//update users set name=?,age=? where id=?基于编辑状态来更新数据库Select办法尽管可能做到按需更新，然而若库表的字段比拟多，这种办法应用起来则比拟麻烦，也容易引起谬误（更新了不该更新的字段）。worm提供了一种基于编辑状态来更新数据库的办法： 首先创立实体类接着Model对象，并将实体类指针传递给Model而后应用SetValue办法一一给字段赋值最初调用Update()办法更新数据库 func demoModelUpdateX() { var user = User{} md := worm.Model(&user) md.SetValue(&user.Name, "name2") md.SetValue(&user.Age, 22) _, err := md.ID(1).Update() if err != nil{ log.Println(err) return }}//update users set name=?,age=? where id=?阐明： ...

篇幅所限本文只写了12道经典MySQL面试题，像其余的Redis，SSM框架，算法，计网等技术栈的面试题前面会继续更新，集体整顿的1000余道面试八股文会放在文末给大家白嫖，最近有面试须要刷题的同学能够间接翻到文末支付。 1. 能说下myisam 和 innodb的区别吗？myisam引擎是5.1版本之前的默认引擎，反对全文检索、压缩、空间函数等，然而不反对事务和行级锁，所以个别用于有大量查问大量插入的场景来应用，而且myisam不反对外键，并且索引和数据是离开存储的。 innodb是基于聚簇索引建设的，和myisam相同它反对事务、外键，并且通过MVCC来反对高并发，索引和数据存储在一起。 2. 说下mysql的索引有哪些吧，聚簇和非聚簇索引又是什么？索引依照数据结构来说次要蕴含B+树和Hash索引。 假如咱们有张表，构造如下： create table user( id int(11) not null, age int(11) not null, primary key(id), key(age));B+树是左小右大的顺序存储构造，节点只蕴含id索引列，而叶子节点蕴含索引列和数据，这种数据和索引在一起存储的索引形式叫做聚簇索引，一张表只能有一个聚簇索引。假如没有定义主键，InnoDB会抉择一个惟一的非空索引代替，如果没有的话则会隐式定义一个主键作为聚簇索引。 这是主键聚簇索引存储的构造，那么非聚簇索引的构造是什么样子呢？非聚簇索引(二级索引)保留的是主键id值，这一点和myisam保留的是数据地址是不同的。 最终，咱们一张图看看InnoDB和Myisam聚簇和非聚簇索引的区别 3. 那你晓得什么是笼罩索引和回表吗？笼罩索引指的是在一次查问中，如果一个索引蕴含或者说笼罩所有须要查问的字段的值，咱们就称之为笼罩索引，而不再须要回表查问。 而要确定一个查问是否是笼罩索引，咱们只须要explain sql语句看Extra的后果是否是“Using index”即可。 以下面的user表来举例，咱们再减少一个name字段，而后做一些查问试试。 explain select * from user where age=1; //查问的name无奈从索引数据获取explain select id,age from user where age=1; //能够间接从索引获取4. 锁的类型有哪些呢mysql锁分为共享锁和排他锁，也叫做读锁和写锁。 读锁是共享的，能够通过lock in share mode实现，这时候只能读不能写。 写锁是排他的，它会阻塞其余的写锁和读锁。从颗粒度来辨别，能够分为表锁和行锁两种。 表锁会锁定整张表并且阻塞其余用户对该表的所有读写操作，比方alter批改表构造的时候会锁表。 行锁又能够分为乐观锁和乐观锁，乐观锁能够通过for update实现，乐观锁则通过版本号实现。 5. 你能说下事务的根本个性和隔离级别吗？事务根本个性ACID别离是： 原子性指的是一个事务中的操作要么全副胜利，要么全副失败。 一致性指的是数据库总是从一个一致性的状态转换到另外一个一致性的状态。比方A转账给B100块钱，假如两头sql执行过程中零碎解体A也不会损失100块，因为事务没有提交，批改也就不会保留到数据库。 隔离性指的是一个事务的批改在最终提交前，对其余事务是不可见的。 持久性指的是一旦事务提交，所做的批改就会永恒保留到数据库中。 而隔离性有4个隔离级别，别离是： read uncommit 读未提交，可能会读到其余事务未提交的数据，也叫做脏读。 用户原本应该读取到id=1的用户age应该是10，后果读取到了其余事务还没有提交的事务，后果读取后果age=20，这就是脏读。 ...

体验简介场景将提供一台配置了CentOS 8.5操作系统和装置部署PolarDB-X集群的ECS实例（云服务器）。通过本教程的操作，带您体验如何应用PolarDB-X搭建一个高可用零碎，通过间接kill容器模仿节点故障，以察看PolarDB-X 的主动复原状况。立刻返回 试验筹备1. 创立试验资源 开始试验之前，您须要先创立ECS实例资源。 在实验室页面，单击创立资源。（可选）在实验室页面左侧导航栏中，单击云产品资源列表，可查看本次试验资源相干信息（例如IP地址、用户信息等）。阐明：资源创立过程须要1~3分钟。 2. 装置环境 本步骤将领导您如何装置Docker、kubectl、minikube和Helm3。 装置Docker。a.执行如下命令，装置Docker。 curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyunb.执行如下命令，启动Docker。 systemctl start docker装置kubectl。a.执行如下命令，下载kubectl文件。 curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectlb.执行如下命令，赋予可执行权限。 chmod +x ./kubectlc.执行如下命令，挪动到系统目录。 mv ./kubectl /usr/local/bin/kubectl装置minikube。执行如下命令，下载并装置minikube。 curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64sudo install minikube-linux-amd64 /usr/local/bin/minikube装置Helm3。a.执行如下命令，下载Helm3。 wget https://labfileapp.oss-cn-hangzhou.aliyuncs.com/helm-v3.9.0-linux-amd64.tar.gzb.执行如下命令，解压Helm3。 tar -zxvf helm-v3.9.0-linux-amd64.tar.gzc.执行如下命令，挪动到系统目录。 mv linux-amd64/helm /usr/local/bin/helm5.装置MySQL。 yum install mysql -y3. 应用PolarDB-X Operator装置PolarDB-X 本步骤将领导您如何创立一个简略的Kubernetes集群并部署PolarDB-X Operator ，应用Operator部署一个残缺的PolarDB-X集群，具体文档请参考通过Kubernetes装置PolarDB-X。 应用minikube创立Kubernetes集群。minikube是由社区保护的用于疾速创立Kubernetes测试集群的工具，适宜测试和学习Kubernetes。应用minikube创立的Kubernetes集群能够运行在容器或是虚拟机中，本试验场景以CentOS 8.5上创立Kubernetes为例。 阐明：如果您应用其余操作系统部署minikube，例如macOS或Windows，局部步骤可能略有不同。 a.执行如下命令，新建账号galaxykube，并将galaxykube退出docker组中。minikube要求应用非root账号进行部署，所有您须要新建一个账号。 useradd -ms /bin/bash galaxykubeusermod -aG docker galaxykubeb.执行如下命令，切换到账号galaxykube。 su galaxykubec.执行如下命令，进入到home/galaxykube目录。 ...

近年来，随着数字经济的倒退，作为大数据底层撑持的数据库管理系统在企业数字化转型中正处于前所未有的重要地位。简直所有的企业级数据、终端数据和边缘设施数据，都须要通过数据库系统的治理和剖析才可能赋能下层利用或企业决策，施展其最大的价值。 面对日益减少的数据规模和数据类型多元化的发展趋势，企业数据分析复杂度一直晋升，传统MPP数据仓库平台，在资源弹性、老本等方面曾经很难适应企业业务需要。 近日，HashData解决方案架构师吴昊通过在线直播的形式，与网友分享了大数据时代数据库技术的倒退和改革。 吴昊介绍，数据库技术的倒退始终随着企业业务需要的变动而演进。以后，随着云计算技术的遍及，云原生数据库应运而生，基于云原生架构的数据仓库正成为越来越多企业的抉择。 以下为直播文字实录摘选，与大家共飨：HashData数据仓库采纳以Snowflake、Databricks和Google BigQuery为代表的业界当先的云原生大数据系统设计理念，围绕着对象存储和形象服务构建，通过元数据、计算和存储三者拆散、多集群共享对立数据存储层的架构，最大限度施展云计算劣势，利用云平台的弹性+分布式的特点，实现疾速部署、按需伸缩、不停机交付等，大幅升高企业进行大数据分析的门槛。 作为一款企业级云端数据仓库，HashData交融了MPP数据库的高性能和丰盛剖析性能、大数据平台的扩展性和灵活性，以及云计算的弹性和敏捷性，提供了传统解决方案无法比拟的高并发、易用性、高可用性、高性能和扩展性。HashData的元数据服务通过寰球可拜访的分布式系统提供，负责数据长久化的对象存储通过RESTFUL接口提供数据拜访能力，两头的计算层则实现了齐全无状态化。HashData与传统MPP数据库比拟与传统MPP架构数据库相比，HashData具备以下劣势和特点：1.秒级的扩缩容能力传统的 MPP 采纳紧耦合设计，在扩容时，须要对磁盘内全副数据进行读写，操作繁琐，对系统IO耗费大，扩容周期长，对业务影响较大。 HashData得益于存算拆散的架构，通过一致性哈希来防止数据从新逻辑分组，通过共享存储防止数据从新物理散布，能够实现集群的秒级扩缩容。 2.打消数据“孤岛”和冗余传统MPP在应用过程中，随着数据量的增长，每个集群的数据都保留在计算节点本地磁盘，集群之间的数据无奈做到无效共享，造成“数据孤岛”景象。同时，大量数据拷贝操作，造成数据重大冗余。 为避免出现“数据孤岛”和冗余，HashData采纳共享存储架构，任何一个计算集群都能够去拜访同一份数据，所有集群共享同一份元数据，彻底消除“数据孤岛”和冗余，确保数据的实时性、一致性。 3.高度弹性的并发能力传统MPP数据库的每个计算节点都会参加到每条查问的执行中，零碎反对的并发查问数量由单个计算节点的硬件资源决定。实践上来讲，能够通过减少集群规模晋升并发查问的数量。但在理论应用过程中，扩充集群规模只是升高了单条查问的延时，不能进步并发查问数量（有时候因为调度的开销，甚至可能比原来慢），成果微不足道。依照咱们的教训，传统MPP架构的并发量其实十分无限。 HashData因为采纳云原生架构，多个集群共享对立的元数据、对立的数据存储，集群间不竞争CPU、内存和IO资源，能够依据业务需要有限地创立集群。为了进步并发数量，只须要减少计算集群，来满足弹性、高并发的要求，代价显著升高。 4.具备自愈性能的高可用传统MPP架构数据库次要通过正本的形式，来保证系统的可用性。这样做的代价是，一旦其中一个节点呈现故障，工作会调度到Mirror节点，对系统性能造成影响。同时，新节点代替失败节点，数据须要从Mirror节点同步到新节点，导致Mirror节点负载减少，成为零碎瓶颈；此外，新节点的数据恢复窗口很长，运维压力十分大。 HashData云数仓将数据存储在共享存储下面，计算节点与数据块的对应关系能够动静调整。不存在所谓的Mirror节点，因此可能实现分钟级新节点复原，整个过程不须要任何的人工干预。 5.灵便的利用反对能力传统MPP架构数据库产品，每个集群运行作业根本固定，无奈动静调整。HashData 云数仓能够依照业务需要动静调整集群规模，防止数据冗余和资源节约，灵便撑持业务倒退。 6.高效应对各种数据库运维难题传统 MPP 架构的数据库，动辄几百台甚至上千台服务器的规模，零碎运维工作量大。 HashData能够依据业务需要，动静地对数据仓库集群进行纵向伸缩和横向伸缩。同时，因为是齐全托管的云服务, HashData数据仓库承当了所有的集群资源配置、数据库治理、继续监控、健康检查、谬误复原、高可用和降级等纷繁复杂、极易出错的运维工作，让用户安心专一于业务剖析下面。

前言： 数据库审计性能次要将用户对数据库的各类操作行为记录审计日志，以便日后进行跟踪、查问、剖析，以实现对用户操作的监控和审计。审计是一项十分重要的工作，也是企业数据安全体系的重要组成部分，等保评测中也要求有审计日志。对于 DBA 而言，数据库审计也极其重要，特地是产生人为事变后，审计日志便于咱们进行责任追溯，问题查找。 1. MySQL 社区版审计日志现状如果你用的是 MySQL 社区版的话，你会发现 MySQL 官网并没有提供严格意义上的审计日志。尽管 MySQL 提供有 binlog 及 general log ，这二者尽管具备局部审计性能，但个别不当做审计日志来对待。 binlog 即二进制日志文件，它记录了数据库所有执行的 DDL 和 DML 语句（除了数据查问语句select、show等），以事件模式记录并保留在二进制文件中。尽管能查到具体 SQL 的执行记录，但其作用次要是主从复制，并不能当做是审计日志。 general log 是全量日志，开启后将会记录所有达到 MySQL Server 的SQL语句。个别不会开启此日志，因为 log 的量会十分宏大，对数据库性能有影响，并且 general log 会记录大量无用信息，当做审计日志的话，前期筛选有难度。 那么 MySQL 社区版应该怎么进行审计呢？查阅材料咱们发现通过装置审计插件可实现 MySQL 的审计性能，常见的审计插件有 MariaDB Audit Plugin、Percona Audit Log Plugin、McAfee MySQL Audit Plugin 三种，MariaDB 自带的审计插件比拟适宜用于 MySQL 社区版，上面咱们来学习下如何应用审计插件来实现审计性能。 2. 审计插件应用教程首先咱们要做的是从 MariaDB 安装包中拷贝进去审计插件，须要留神的是操作系统要抉择统一，比如说你的 MySQL 装置在 CentOS 零碎中，那就要下载 CentOS 零碎的 MariaDB 安装包并从中拷贝，Windows 零碎则须要下载对应零碎的审计插件。 MariaDB 审计插件的名称是 server_audit.so（Windows零碎下是 server_audit.dll ），要留神的是，审计插件始终在更新，不同版本的审计插件性能也不同，举荐应用 >= 1.4.4 版本的插件，新版本的插件能够排除掉 select 语句。不同版本的审计插件反对的审计事件如下图： ...

作者：胡呈清 爱可生 DBA 团队成员，善于故障剖析、性能优化，集体博客：https://www.jianshu.com/u/a95...，欢送探讨。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 复制异样在复制过程中，主库产生故障或者网络中断，都会造成 slave io thread 中断，就有可能呈现从库只复制了半个事务的状况。比方主库执行的事务如下： begin;insert 1;insert 2;commit;从库接管的 binlog 可能只蕴含事务的一部分，比方： 状况1：只蕴含 begin;状况2：只蕴含 begin;insert 1;状况3：只蕴含 begin;insert 1;insert 2;从库的 slave sql thread 回放完这部分 binlog 后，会期待 slave io thread 从主库读取残余的 binlog，而在此之前 sql 线程回放这半个事务，就和咱们手工执行半个事务一样，不会提交也不会回滚。 咱们应该如何应答这种异样呢？ 当 slave io thread 复原，应该做什么？当 slave io thread 无奈复原，应该做什么？试验过程测试方法： ##1. 在从库上用 tc 模仿网络提早，意在使读取 binlog 的速度变慢tc qdisc add dev eth0 root netem delay 3000ms 3000ms 100%##2. 在主库执行一个多语句事务begin;update t2 set pad='4' where id < 40;update t2 set pad='5' where id < 50;update t2 set pad='6' where id < 60;commit;##3. 在主库执行 commit 胜利后，立即用 iptables 切断主从之间的网络iptables -A OUTPUT -d 172.16.21.4 -j DROPiptables -A INPUT -s 172.16.21.4 -j DROP这样咱们能够在从库上察看到的景象为： ...

连接器简略总结一下：与客户端进行 TCP 三次握手建设连贯；校验客户端的用户名和明码，如果用户名或明码不对，则会报错；如果用户名和明码都对了，会读取该用户的权限，而后前面的权限逻辑判断都基于此时读取到的权限 解析器词法剖析，语法分析 执行 SQL每条SELECT 查问语句流程次要能够分为上面这三个阶段：prepare 阶段，也就是预处理阶段；optimize 阶段，也就是优化阶段；execute 阶段，也就是执行阶段； 预处理器 优化器通过预处理阶段后，还须要为 SQL 查问语句先制订一个执行打算，这个工作交由「优化器」来实现的。优化器次要负责将 SQL 查问语句的执行计划确定下来 要想晓得优化器抉择了哪个索引，咱们能够在查问语句最后面加个 explain 命令，这样就会输入这条 SQL 语句的执行打算 笼罩索引执行器经验完优化器后，就确定了执行计划，接下来 MySQL 就真正开始执行语句了， 最初总结：连接器：建设连贯，治理连贯、校验用户身份；查问缓存：查问语句如果命中查问缓存则间接返回，否则持续往下执行。MySQL 8.0 已删除该模块；解析 SQL，通过解析器对 SQL 查问语句进行词法剖析、语法分析，而后构建语法树，不便后续模块读取表名、字段、语句类型；执行 SQL：执行 SQL 共有三个阶段：预处理阶段：检查表或字段是否存在；将 select 中的 符号扩大为表上的所有列。优化阶段：基于查问老本的思考， 抉择查问老本最小的执行打算；执行阶段：依据执行打算执行 SQL 查问语句，从存储引擎读取记录，返回给客户端；

节选自 《MySQL 常见知识点&面试题总结》表级锁和行级锁理解吗？有什么区别？MyISAM 仅仅反对表级锁(table-level locking)，一锁就锁整张表，这在并发写的状况下性十分差。 InnoDB 不光反对表级锁(table-level locking)，还反对行级锁(row-level locking)，默认为行级锁。行级锁的粒度更小，仅对相干的记录上锁即可（对一行或者多行记录加锁），所以对于并发写入操作来说， InnoDB 的性能更高。 表级锁和行级锁比照 ： 表级锁： MySQL 中锁定粒度最大的一种锁，是针对非索引字段加的锁，对以后操作的整张表加锁，实现简略，资源耗费也比拟少，加锁快，不会呈现死锁。其锁定粒度最大，触发锁抵触的概率最高，并发度最低，MyISAM 和 InnoDB 引擎都反对表级锁。行级锁： MySQL 中锁定粒度最小的一种锁，是针对索引字段加的锁，只针对以后操作的记录进行加锁。 行级锁能大大减少数据库操作的抵触。其加锁粒度最小，并发度高，但加锁的开销也最大，加锁慢，会呈现死锁。行级锁的应用有什么注意事项？InnoDB 的行锁是针对索引字段加的锁，表级锁是针对非索引字段加的锁。当咱们执行 UPDATE、DELETE 语句时，如果 WHERE条件中字段没有命中索引或者索引生效的话，就会导致扫描全表对表中的所有记录进行加锁。这个在咱们日常工作开发中常常会遇到，肯定要多多留神！！！ 不过，很多时候即应用了索引也有可能会走全表扫描，这是因为 MySQL 优化器的起因。 共享锁和排他锁呢？不论是表级锁还是行级锁，都存在共享锁（Share Lock，S 锁）和排他锁（Exclusive Lock，X 锁）这两类： 共享锁（S 锁） ：又称读锁，事务在读取记录的时候获取共享锁，容许多个事务同时获取（锁兼容）。排他锁（X 锁） ：又称写锁/独占锁，事务在批改记录的时候获取排他锁，不容许多个事务同时获取。如果一个记录曾经被加了排他锁，那其余事务不能再对这条事务加任何类型的锁（锁不兼容）。排他锁与任何的锁都不兼容，共享锁仅和共享锁兼容。 S 锁X 锁S 锁不抵触抵触X 锁抵触抵触因为 MVCC 的存在，对于个别的 SELECT 语句，InnoDB 不会加任何锁。不过， 你能够通过以下语句显式加共享锁或排他锁。 # 共享锁SELECT ... LOCK IN SHARE MODE;# 排他锁SELECT ... FOR UPDATE;意向锁有什么作用？如果须要用到表锁的话，如何判断表中的记录没有行锁呢？一行一行遍历必定是不行，性能太差。咱们须要用到一个叫做意向锁的东东来疾速判断是否能够对某个表应用表锁。 意向锁是表级锁，共有两种： 动向共享锁（Intention Shared Lock，IS 锁）：事务有动向对表中的某些加共享锁（S 锁），加共享锁前必须先获得该表的 IS 锁。动向排他锁（Intention Exclusive Lock，IX 锁）：事务有动向对表中的某些记录加排他锁（X 锁），加排他锁之前必须先获得该表的 IX 锁。意向锁是有数据引擎本人保护的，用户无奈手动操作意向锁，在为数据行加共享 / 排他锁之前，InooDB 会先获取该数据行所在在数据表的对应意向锁。 ...

引言本文整顿了 MySQL 流式查问一些原理和用法, 包含 MySQL 官网文档对于 ResultSet 流式查问的阐明以及很多网友对于 MySQL 散失查问踩坑的阐明. 最初给出了解决流式查问的 connection 在未查问完后果集的数据之前又被其余中央应用导致报错的解决办法, 心愿能对读者有所帮忙. 原文地址: No statements may be issued when any streaming result sets are open and in use on a given connection 欢送拜访我的博客: http://blog.duhbb.com/ 报错日志org.springframework.dao.DataAccessResourceFailureException: PreparedStatementCallback; SQL []; Could not create connection to database server. Attempted reconnect 3 times. Giving up.; nested exception is java.sql.SQLNonTransientConnectionException: Could not create connection to database server. Attempted reconnect 3 times. Giving up. at org.springframework.jdbc.support.SQLExceptionSubclassTranslator.doTranslate(SQLExceptionSubclassTranslator.java:81) at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:72) at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:81) at org.springframework.jdbc.core.JdbcTemplate.translateException(JdbcTemplate.java:1443) at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:633) at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:669) at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:700) at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:712) at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:763) at org.springframework.jdbc.core.JdbcTemplate.queryForList(JdbcTemplate.java:829) at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218) at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:779) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163) at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:750) at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:367) at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:118) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:175) at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:750) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:95) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186) at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:750) at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:692) at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218) at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:779) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163) at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:750) at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:367) at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:118) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:175) at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:750) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:95) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186) at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:750) at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:692) at org.springframework.jdbc.core.JdbcTemplate$RowCallbackHandlerResultSetExtractor.extractData(JdbcTemplate.java:1607) at org.springframework.jdbc.core.JdbcTemplate$1.doInPreparedStatement(JdbcTemplate.java:679) at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:617) at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:669) at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:694) at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:723) at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218) at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:779) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163) at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:750) at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:367) at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:118) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:175) at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:750) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:95) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186) at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:750) at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:692) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)Caused by: java.sql.SQLNonTransientConnectionException: Could not create connection to database server. Attempted reconnect 3 times. Giving up. at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:110) at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97) at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:89) at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:63) at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:73) at com.mysql.cj.jdbc.ConnectionImpl.connectWithRetries(ConnectionImpl.java:903) at com.mysql.cj.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:828) at com.mysql.cj.jdbc.ConnectionImpl.handleReconnect(ConnectionImpl.java:2694) at com.mysql.cj.NativeSession.invokeReconnectListeners(NativeSession.java:1215) at com.mysql.cj.NativeSession.execSQL(NativeSession.java:1067) at com.mysql.cj.jdbc.ClientPreparedStatement.executeInternal(ClientPreparedStatement.java:930) at com.mysql.cj.jdbc.ClientPreparedStatement.executeQuery(ClientPreparedStatement.java:1003) at com.zaxxer.hikari.pool.ProxyPreparedStatement.executeQuery(ProxyPreparedStatement.java:52) at com.zaxxer.hikari.pool.HikariProxyPreparedStatement.executeQuery(HikariProxyPreparedStatement.java) at org.springframework.jdbc.core.JdbcTemplate$1.doInPreparedStatement(JdbcTemplate.java:678) at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:617) ... 69 common frames omittedCaused by: java.sql.SQLException: Streaming result set com.mysql.cj.protocol.a.result.ResultsetRowsStreaming@5869a708 is still active. No statements may be issued when any streaming result sets are open and in use on a given connection. Ensure that you have called .close() on any active streaming result sets before attempting more queries. at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:129) at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:122) at com.mysql.cj.jdbc.ConnectionImpl.pingInternal(ConnectionImpl.java:1524) at com.mysql.cj.jdbc.ConnectionImpl.connectWithRetries(ConnectionImpl.java:848) ... 79 common frames omittedMySQL 后果集官网解释原文地址: 6.4 JDBC API Implementation Notes ...

之前的篇章咱们探讨的都是基于单列的分区表，那有无必要建设基于多列的分区表？这种分区表数据分布是否平均？有无非凡的利用场景？有无非凡的优化策略？本篇基于这些问题来进行重点解读。 MySQL 不仅反对基于单列分区，也反对基于多列分区。比方基于字段（f1,f2,f3)来建设分区表，应用办法和应用场景都有些相似于联结索引。比方上面查问语句，同时对列(f1,f2,f3) 进行过滤。 select * from p1 where f1 = 2 and f2 = 2 and f3 = 2;多列分区表的前提是参加分区的列检索频率均等，如果不均等，就没有必要应用多列分区。 咱们还是以具体实例来验证下多列分区的优缺点以及实用场景，这样了解起来更加透彻。 建设一张表p1，字段r1,r2,r3别离取值为1-8，1-5，1-5. create table p1(r1 int,r2 int,r3 int,log_date datetime);依照字段(r1,r2,r3) 的散布范畴，我来写个存储过程解决下表p1，变为分区表。存储过程代码如下： DELIMITER $$USE `ytt_new`$$DROP PROCEDURE IF EXISTS `sp_add_partition_ytt_new_p1`$$CREATE DEFINER=`root`@`%` PROCEDURE `sp_add_partition_ytt_new_p1`()BEGIN DECLARE i,j,k INT UNSIGNED DEFAULT 1; SET @stmt = ''; SET @stmt_begin = 'ALTER TABLE p1 PARTITION BY RANGE COLUMNS (r1,r2,r3)('; WHILE i <= 8 DO set j = 1; while j <= 5 do set k = 1; while k <= 5 do SET @stmt = CONCAT(@stmt,' PARTITION p',i,j,k,' VALUES LESS THAN (',i,',',j,',',k,'),'); set k = k + 1; end while; set j = j + 1; end while; SET i = i + 1; END WHILE; SET @stmt_end = 'PARTITION p_max VALUES LESS THAN (maxvalue,maxvalue,maxvalue))'; SET @stmt = CONCAT(@stmt_begin,@stmt,@stmt_end); PREPARE s1 FROM @stmt; EXECUTE s1; DROP PREPARE s1; SET @stmt = NULL; SET @stmt_begin = NULL; SET @stmt_end = NULL; END$$DELIMITER ;调用存储过程，变更表p1为多列分区表，此时表p1有201个分区，记录数为500W条。 ...

指标Databend 是一个十分先进的基于对象存储云原生数仓1能够提弱小的计算剖析及存储能力。让 MySQL DBA 十分眼馋。明天想把 MySQL 的 wubx 库从 MySQL 全量迁徙到 Databend 中。借助工具： dumpling2 Dumpling 介绍Dumpling3 是反对以 SQL 文本或者 CSV 格局将 MySQL/TiDB 数据导出的工具。设计初衷是为了代替Mydumper4, 所以根本用法能够参考 Mydumper, 当然在实现中没有齐全照搬 Mydumper, 因而存在与 Mydumper 不同的用法。更多帮忙：https://github.com/pingcap/ti... 遗憾的 TiDB 没有提供 dumpling 的独自下载，只提供了大的 package：https://pingcap.com/zh/produc... 内含：dumpling 二进制包，下载安装就省略了。 环境阐明当初 MySQL 中 wubx 库是 sysbench 生成的数据，10 个表，每个表 1000 万数据。迁徙指标：DatabendDatabend 装置部署参考：https://databend.rs/doc/deploy 应用 dumpling 备份现有数据库dumpling -uwubx -pwubxwubx -P3306 -h 192.168.2.10 --filetype csv -t 8 -o ./ -F 256M -B wubx命令阐明： -u   mysql 用户名 -p   mysql 明码 -P   mysql 端口 -h   mysql 机器 ip --filetype csv  指定应用 CSV 格局导出（十分重要） -t  8  应用 8 过程导出 -o  ./ 指定导出来的文件寄存地位 -F 导出文件的大小 -B  wubx  指定导出的数据库 命令运行后导出来文件如下： ...

如何查找反复行 第一步是定义什么样的行才是反复行。少数状况下很简略：它们某一列具备雷同的值。本文采纳这一定义，或者你对“反复”的定义比这简单，你须要对sql做些批改。本文要用到的数据样本： create table test(id int not null primary key, day date not null);insert into test(id, day) values(1, '2006-10-08');insert into test(id, day) values(2, '2006-10-08');insert into test(id, day) values(3, '2006-10-09');select * from test;+----+------------+| id | day |+----+------------+| 1 | 2006-10-08 || 2 | 2006-10-08 || 3 | 2006-10-09 |+----+------------+后面两行在day字段具备雷同的值，因而如何我将他们当做反复行，这里有一查问语句能够查找。查问语句应用GROUP BY子句把具备雷同字段值的行归为一组，而后计算组的大小。 select day, count(*) from test GROUP BY day;+------------+----------+| day | count(*) |+------------+----------+| 2006-10-08 | 2 || 2006-10-09 | 1 |+------------+----------+反复行的组大小大于1。如何心愿只显示反复行，必须应用HAVING子句，比方 ...

本文来自于轻量应用服务器征文活动用户投稿，已取得作者（昵称黄家臣）受权公布。 轻量应用服务器 ，是可疾速搭建且易于治理的轻量级云服务器；提供基于单台服务器的利用部署，平安治理，运维监控等服务，一站式晋升您的服务器应用体验和效率。我购买这台轻量应用服务器的目标是搭建一个博客环境，记录本人的学习心得和技术分享。目前没有思考经营，我选的是低配的那款，配置依据集体理论需要进行抉择即可。对于服务器，我重点关注的是“可疾速搭建”且“易于治理”，通过本人的实际的确证实了产品的这两个特点。 一、购买服务器因为本人之前用过Linux操作系统，所以购买服务器的时候，操作系统我就抉择了CentOS；如果用不惯，前面还能够重置零碎，在这点上还是很不便的。下图中的选项就不作过多介绍了，按本人的需要进行选配，而后下一步确认服务器配置，最初确认领取就行。购买实现后，进入控制台就能够查看你的这台服务器的相干信息。 二、配置服务器刚购买的服务器须要设置用户明码，用户名默认就是root，明码须要本人手动设置，之后在通过SSH近程连贯服务器的时候须要输出这个明码（Linux零碎中，输出明码的时候是暗藏的）。 目前我的项目须要的服务器环境次要是MySQL、Node及Nginx。上面是具体的步骤及命令代码展现。 1、装置Node下载文件： [root@localhost ~]$ mkdir -p /usr/local/nodejs[root@localhost nodejs]$ cd /usr/local/nodejs/[root@localhost nodejs]$ wget https://npm.taobao.org/mirrors/node/v12.12.0/node-v12.12.0-linux-x64.tar.gz解压： [root@localhost nodejs]$ tar -xvf node-v12.12.0-linux-x64.tar.gz配置环境变量： [root@localhost nodejs]$ vim /etc/profile增加上面内容： export NODE_HOME=/usr/local/nodejs/node-v12.12.0-linux-x64export PATH=$NODE_HOME/bin:$PATH留神：NODE_HOME 前面的值是本人解压后的目录，保留后退出；装置目录能够通过 whereis node进行查看。 更新环境变量： [root@localhost nodejs]$ source /etc/profile查看装置版本： [root@localhost nodejs]$ node -v[root@localhost nodejs]$ npm -v能够显示版本信息则表明装置胜利。 2、装置MySQL创立文件夹并设置权限： [root@localhost nodejs]$ cd /home/admin[root@localhost admin]$ mkdir downloads[root@localhost admin]$ chmod 777 downloads[root@localhost admin]$ cd downloads/导入RPM源： [root@localhost downloads]$ wget https://dev.mysql.com/get/mysql80-community-release-el8-1.noarch.rpm[root@localhost downloads]$ sudo rpm -ivh mysql80-community-release-el8-1.noarch.rpm开始装置： ...

总述需要背景用户心愿在写代码时，可能定义一些公共变量而后执行的时候进行替换，比方用户每天都会批量跑同一段sql，须要指定上一天的分区工夫，如果基于sql去写会比较复杂如果零碎提供一个run_date的变量将会十分方便使用。指标反对工作代码的变量替换反对自定义变量，反对用户在脚本和提交给Linkis的工作参数定义自定义变量，反对简略的+，-等计算预设置零碎变量：run_date,run_month，run_today等零碎变量 总体设计在Linkis工作执行过程中自定义变量在Entrance进行，次要通过Entrance在工作提交执行前的拦截器进行拦挡替换实现，通过正则表达式获取到工作代码中应用到的变量和定义的变量，并通过工作传入的自定义变量初始值实现代码的替换，变成最终能够执行的代码。2.1 技术架构自定义变量整体架构如下，用于工作提交过去后，会通过变量替换拦截器。首先会解析出所有代码中用到的变量和表达式，而后通过和零碎以及用户自定义的变量初始值进行替换，最终将解析后的代码提交给EngineConn执行。所以到底层引擎曾经是替换好的代码。图片 性能介绍Linkis反对的变量类型分为自定义变量和零碎内置变量，外部变量是Linkis事后定义好的，能够间接进行应用。而后不同的变量类型反对不同的计算格局：String反对+、整数小数反对+-*/,日期反对+-。3.1 内置变量目前已反对的内置变量如下：图片 具体细节：1、run_date为外围自带日期变量，反对用户自定义日期，如果不指定默认为以后零碎工夫的前一天。2、其余衍生内置日期变量定义：其余日期内置变量都是绝对run_date计算出来的，一旦run_date变动，其余变量值也会主动跟着变动，其余日期变量不反对设置初始值，只能通过批改run_date进行批改。3、内置变量反对更加丰盛的应用场景：${run_date-1}为run_data的前一天；${run_month_begin-1}为run_month_begin的上个月的第一天，这里的-1示意减一个月。 3.2 自定义变量什么是自定义变量？先定义，后应用的用户变量。用户自定义变量临时反对字符串，整数，浮点数变量的定义，其中字符串反对+法，整数和浮点数反对+-*/办法。用户自定义变量与SparkSQL和HQL自身反对的set变量语法不抵触，然而不容许同名。如何定义和应用自定义变量？如下： 代码中定义，在工作代码前进行指定sql类型定义形式： --@set f=20.1 python/Shell类型定义如下： @set f=20.1留神：只反对一行定义一个变量 应用都是间接在代码中应用通过 {varName表达式},如${f*2} 3.3 变量作用域在linkis中自定义变量也有作用域，优先级为脚本中定义的变量大于在工作参数中定义的Variable，大于内置的run_date变量。工作参数中定义如下： restful{ "executionContent":{"code":"select \"${f-1}\";","runType":"sql"}, "params":{ "variable":{f:"20.1"}, "configuration":{ "runtime":{ "linkis.openlookeng.url":"http://127.0.0.1:9090" } } }, "source":{"scriptPath":"file:///mnt/bdp/hadoop/1.sql"}, "labels":{ "engineType":"spark-2.4.3", "userCreator":"hadoop-IDE" } } java SDKJobSubmitAction.builder .addExecuteCode(code) .setStartupParams(startupMap) .setUser(user)//submit user .addExecuteUser(user)//execute user .setLabels(labels) .setVariableMap(varMap)//setVar .build 最初社区以后正在举办征文大赛，最高处分可得 “1000元京东卡+500元社区礼品”哦，戳https://mp.weixin.qq.com/s/Kn... 理解

原文地址: MySQL IN 和 NOT IN () 空列表报错 欢送拜访我的博客: http://blog.duhbb.com/ 如果你被动在 SQL 语句中写 IN (), 则会报错;常见于 MyBatis 或者本人拼写的 SQL 语句中, 如果应用字面量肯定要留神这一点;如果你是 IN (SELECT xxx FROM xxx) 这种的话, 即便 SELECT xxx FROM xxx 为空也不会报错.比拟好奇的是, 感觉这个挺简略的, 为啥 MySQL 就不解决一下呢? 要是我读懂了 MySQL 的源码, 我就把这个个性加上去, 嘿嘿!

在MySQL数据库中，如果在insert语句前面带上ON DUPLICATE KEY UPDATE 子句，而要插入的行与表中现有记录的惟一索引或主键中产生反复值，那么就会产生旧行的更新；如果插入的行数据与现有表中记录的惟一索引或者主键不反复，则执行新纪录插入操作。另外，ON DUPLICATE KEY UPDATE不能写where条件。 create table kid_score(id tinyint unsigned not null,birth_day date not null,score int unsigned not null,primary key(id, birth_day) --惟一索引是由 id + birth_day 两个字段组成) engine = InnoDB;--初始化数据insert into kid_score(id, birth_day, score) values (1,'2019-01-15',10),(2,'2019-01-16',20);insert into kid_score(id, birth_day, score) values (1,'2019-01-15',30) ON DUPLICATE KEY UPDATE score = score + 50;分惟一索引反复、惟一索引不反复的状况。惟一索引反复，那就是更新操作。惟一索引不反复，就是插入操作。 须要留神的是：如果行作为新记录被插入，则受影响行的值为1；如果原有的记录被更新，则受影响行的值为2，如果更新的数据和已有的数据截然不同，则受影响的行数是0。 mysql> select * from kid_score;+----+------------+-------+| id | birth_day | score |+----+------------+-------+| 1 | 2019-01-15 | 10 || 2 | 2019-01-16 | 20 |+----+------------+-------+2 rows in set-- 惟一索引反复，执行更新mysql> insert into kid_score(id, birth_day, score) values (1,'2019-01-15',30) ON DUPLICATE KEY UPDATE score = score + 50;Query OK, 2 rows affectedmysql> select * from kid_score;+----+------------+-------+| id | birth_day | score |+----+------------+-------+| 1 | 2019-01-15 | 60 || 2 | 2019-01-16 | 20 |+----+------------+-------+2 rows in set-- 惟一索引不反复，执行插入mysql> insert into kid_score(id, birth_day, score) values (2,'2019-01-15',30) ON DUPLICATE KEY UPDATE score = score + 50;Query OK, 1 row affectedmysql> select * from kid_score;+----+------------+-------+| id | birth_day | score |+----+------------+-------+| 1 | 2019-01-15 | 60 || 2 | 2019-01-15 | 30 || 2 | 2019-01-16 | 20 |+----+------------+-------+3 rows in set-- 惟一索引反复，应该执行更新，但更新值与原值雷同mysql> insert into kid_score(id, birth_day, score) values (2,'2019-01-16',20) ON DUPLICATE KEY UPDATE score = 20;Query OK, 0 rows affectedmysql> select * from kid_score;+----+------------+-------+| id | birth_day | score |+----+------------+-------+| 1 | 2019-01-15 | 60 || 2 | 2019-01-15 | 30 || 2 | 2019-01-16 | 20 |+----+------------+-------+3 rows in set最常见的形式就是为字段设置主键或惟一索引，当插入反复数据时，抛出谬误，程序终止，但这会给后续解决带来麻烦，因而须要对插入语句做非凡解决，尽量避开或疏忽异样，上面我简略介绍一下，感兴趣的敌人能够尝试一下： ...

待更新待更新待更新待更新待更新待更新待更新

逻辑备份:mysqldumpmysqldump是MySQL官网提供的一款逻辑备份的工具，其备份原理是生成一组能够导入数据库中以重现原始数据库中的数据和数据库对象的SQL语句，而后用SQL语句对数据库进行复原，因而称它为逻辑备份，另外它还反对生成CSV格局或者XML格局的文件。 应用mysqldump进行备份时是须要肯定的权限的，备份表数据须要对表的SELECT权限，导出视图须要SHOW VIEW权限，导出触发器须要TRIGGER权限，在不应用--single-transaction选项进行锁表时须要LOCK TABLES权限。如果应用更多的选项，可能就须要有更多的权限。 另外，如果咱们须要用备份文件进行复原时，则必须具备执行这个文件中所有语句的权限，例如执行CREATE语句就须要有相应对象的CREATE权限，执行LOCK TABLES语句时须要有LOCK TABLES权限。 上面咱们演示一下mysqldump的用法。 mysqldump是MySQL的原生命令，个别咱们装置完MySQL后，mysqldump命令就能够间接应用了。 [root@dk-14 ~]# mysqldump --version mysqldump  Ver 10.13 Distrib 5.7.21, for linux-glibc2.12 (x86_64) 首先进行一下全库备份的演示，首先咱们在将要备份的库上制作一些测试数据。 mysql> SHOW DATABASES; | Database           | | information_schema | | mysql              | | performance_schema | | sys                | 4 rows in set (0.00 sec) mysql> CREATE DATABASE aa; Query OK, 1 row affected (0.04 sec) mysql> USE aa Database changed mysql> CREATE TABLE t1(id INT PRIMARY KEY,name VARCHAR(20)); Query OK, 0 rows affected (0.12 sec) ...

mysql查问为什么会慢，对于这个问题，在理论开发常常会遇到，而面试中，也是个高频题。 遇到这种问题，咱们个别也会想到是因为索引。 那除开索引之外，还有哪些因素会导致数据库查问变慢呢？ 有哪些操作，能够晋升mysql的查问能力呢？ 明天这篇文章，咱们就来聊聊会导致数据库查问变慢的场景有哪些，并给出起因和解决方案。 数据库查问流程咱们先来看下，一条查问语句下来，会经验哪些流程。 比方咱们有一张数据库表 CREATE TABLE `user` (  `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',  `name` varchar(100) NOT NULL DEFAULT '' COMMENT '名字',  `age` int(11) NOT NULL DEFAULT '0' COMMENT '年龄',  `gender` int(8) NOT NULL DEFAULT '0' COMMENT '性别',  PRIMARY KEY (`id`),  KEY `idx_age` (`age`),  KEY `idx_gender` (`gender`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;咱们平时写的利用代码（go或C++之类的），这时候就叫客户端了。 客户端底层会带着账号密码，尝试向mysql建设一条TCP长链接。 mysql的连贯治理模块会对这条连贯进行治理。 建设连贯后，客户端执行一条查问sql语句。比方： select * from user where gender = 1 and age = 100;客户端会将sql语句通过网络连接给mysql。 mysql收到sql语句后，会在分析器中先判断下SQL语句有没有语法错误，比方select，如果少打一个l，写成slect，则会报错You have an error in your SQL syntax;。这个报错对于我这样的手残党来说能够说是很相熟了。 接下来是优化器，在这里会依据肯定的规定抉择该用什么索引。 之后，才是通过执行器去调用存储引擎的接口函数。 存储引擎相似于一个个组件，它们才是mysql真正获取一行行数据并返回数据的中央，存储引擎是能够替换更改的，既能够用不反对事务的MyISAM，也能够替换成反对事务的Innodb。这个能够在建表的时候指定。比方 CREATE TABLE `user` (  ...) ENGINE=InnoDB;当初最罕用的是InnoDB。 咱们就重点说这个。 InnoDB中，因为间接操作磁盘会比较慢，所以加了一层内存提提速，叫buffer pool，这外面，放了很多内存页，每一页16KB，有些内存页放的是数据库表里看到的那种一行行的数据，有些则是放的索引信息。 查问SQL到了InnoDB中。会依据后面优化器里计算失去的索引，去查问相应的索引页，如果不在buffer pool里则从磁盘里加载索引页。再通过索引页减速查问，失去数据页的具体位置。如果这些数据页不在buffer pool中，则从磁盘里加载进来。 这样咱们就失去了咱们想要的一行行数据。 最初将失去的数据后果返回给客户端。 慢查问剖析如果下面的流程比较慢的话，咱们能够通过开启profiling看到流程慢在哪。 mysql> set profiling=ON;Query OK, 0 rows affected, 1 warning (0.00 sec)mysql> show variables like 'profiling';+---------------+-------+| Variable_name | Value |+---------------+-------+| profiling     | ON    |+---------------+-------+1 row in set (0.00 sec)而后失常执行sql语句。 这些SQL语句的执行工夫都会被记录下来，此时你想查看有哪些语句被记录下来了，能够执行 show profiles; mysql> show profiles;+----------+------------+---------------------------------------------------+| Query_ID | Duration   | Query                                             |+----------+------------+---------------------------------------------------+|        1 | 0.06811025 | select * from user where age>=60                  ||        2 | 0.00151375 | select * from user where gender = 2 and age = 80  ||        3 | 0.00230425 | select * from user where gender = 2 and age = 60  ||        4 | 0.00070400 | select * from user where gender = 2 and age = 100 ||        5 | 0.07797650 | select * from user where age!=60                  |+----------+------------+---------------------------------------------------+5 rows in set, 1 warning (0.00 sec)关注下下面的query_id，比方select * from user where age>=60对应的query_id是1，如果你想查看这条SQL语句的具体耗时，那么能够执行以下的命令。 mysql> show profile for query 1;+----------------------+----------+| Status               | Duration |+----------------------+----------+| starting             | 0.000074 || checking permissions | 0.000010 || Opening tables       | 0.000034 || init                 | 0.000032 || System lock          | 0.000027 || optimizing           | 0.000020 || statistics           | 0.000058 || preparing            | 0.000018 || executing            | 0.000013 || Sending data         | 0.067701 || end                  | 0.000021 || query end            | 0.000015 || closing tables       | 0.000014 || freeing items        | 0.000047 || cleaning up          | 0.000027 |+----------------------+----------+15 rows in set, 1 warning (0.00 sec)通过下面的各个项，大家就能够看到具体耗时在哪。比方从下面能够看出Sending data的耗时最大，这个是指执行器开始查问数据并将数据发送给客户端的耗时，因为我的这张表符合条件的数据有好几万条，所以这块耗时最大，也合乎预期。 个别状况下，咱们开发过程中，耗时大部分时候都在Sending data阶段，而这一阶段里如果慢的话，最容易想到的还是索引相干的起因。 索引相干起因索引相干的问题，个别能用explain命令帮忙剖析。通过它能看到用了哪些索引，大略会扫描多少行之类的信息。 mysql会在优化器阶段里看下抉择哪个索引，查问速度会更快。 个别次要思考几个因素，比方： 抉择这个索引大略要扫描多少行（rows）为了把这些行取出来，须要读多少个16kb的页走一般索引须要回表，主键索引则不须要，回表老本大不大？回到show profile中提到的sql语句，咱们应用explain select * from user where age>=60 剖析一下。 下面的这条语句，应用的type为ALL，意味着是全表扫描，possible_keys是指可能用失去的索引，这里可能应用到的索引是为age建的一般索引，但实际上数据库应用的索引是在key那一列，是NULL。也就是说这句sql不走索引，全表扫描。 这个是因为数据表里，符合条件的数据行数（rows）太多，如果应用age索引，那么须要将它们从age索引中读出来，并且age索引是一般索引，还须要回表找到对应的主键能力找到对应的数据页。算下来还不如间接走主键划算。于是最终抉择了全表扫描。 当然下面只是举了个例子，实际上，mysql执行sql时，不必索引或者用的索引不合乎咱们预期这件事常常产生，索引生效的场景有很多，比方用了不等号，隐式转换等，这个置信大家背八股文的时候也背过不少了，我也不再赘述。 聊两个生产中容易遇到的问题吧。 索引不合乎预期理论开发中有些状况比拟非凡，比方有些数据库表一开始数据量小，索引少，执行sql时，的确应用了合乎你预期的索引。但随时工夫边长，开发的人变多了，数据量也变大了，甚至还可能会退出一些其余反复多余的索引，就有可能呈现用着用着，用到了不合乎你预期的其余索引了。从而导致查问忽然变慢。 这种问题，也好解决，能够通过force index指定索引。比方 ...

作者：杨奇龙 网名“北在北方”，资深 DBA，次要负责数据库架构设计和运维平台开发工作，善于数据库性能调优、故障诊断。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 一 前言某个客户反馈查询数据库发现 information_schema.tables 的 data_free 值突发异样，达到 13G 左右。如图： 须要排查什么起因导致的，本文梳理排查的过程和和解决问题的办法。 二 排查2.1 剖析首先 data_free 的含意是 表空间 ibd 文件通过写入和删除之后，留下的没有回收的碎片空间大小。 让现场的同学同时查看主备库，比照有没有文件大小和配置上的差别。 发现主库的data_free 值是 13G 左右， 备库失常。 看后果猜想和主库上的某些申请动作无关，空洞是 MySQL 因为 sql 写入而申请调配的空间没有主动回收的后果。基于火线给的信息，没有其余思路，再看火线发的截图: 意外从 截图的 ibtmp1 文件大小找到一些线索，截图显示 ibtmp1 文件大小也是 13G ，备库则是初始值大小。 疏忽红色的箭头，查看 ibtmp1 文件大小为 13G ，仿佛有些脉络，data_free 是否和 ibtmp1 无关。2.2 验证猜测应用 sysbench 创立测试表 sbtest1 ，结构2w条记录，而后创立 sbtest2 ，将 sbtest1 的数据 导入到 sbtest2 。为何这么操作，前面会阐明。 mysql > show variables like 'innodb_temp_data_file_path';+----------------------------+-----------------------+| Variable_name | Value |+----------------------------+-----------------------+| innodb_temp_data_file_path | ibtmp1:12M:autoextend |+----------------------------+-----------------------+1 row in set (0.00 sec)查看物理ibtmp1 文件大小: ...

明天分享一个开源文档在线预览我的项目解决方案kkFileView作者发现的最新发现。 如题目，最终查明问题是因为 mysql-connector-java:8.0.28 的一个 bug 导致的。然而在假相未浮出之前，整个问题堪称错综复杂，博主良久没有排查过如此得劲的 bug ，随着一层层的 debug 深刻，假相也随之浮出水面。这个问题属于底层 jdbc 驱动的问题，具备普遍性，可能人不知;鬼不觉中，你的利用也在线上蒙受这个 bug 的残害，所以，请急躁听我讲完这个故事，而后回去查看下你的利用状态，是否也踩坑了。喜爱的能够间接拉到文末结语看后果。 背景讲故事个别先介绍人物、背景。这里也不列外，先把相干方介绍下。通常，故事情节越丰盛越精彩，然而这里博主会思考篇幅 (不讲废话) 会把一些与后果无关的细节疏忽掉，力求叙述残缺就好。 commons-db : 咱们外部保护的，是一个采纳注解驱动的 Spring 生态下的大多数资源管理组件。组件给每个 DataSource 预设了些性能优化的默认值，没有全副列出，不过蕴含了影响问题走向的属性（useLocalSessionState），如下：Properties defaultProperties = new Properties();defaultProperties.put("prepStmtCacheSize", 300);defaultProperties.put("prepStmtCacheSqlLimit", 2048);defaultProperties.put("useLocalSessionState", true);defaultProperties.put("cacheResultSetMetadata", true);defaultProperties.put("elideSetAutoCommits", true);java-project : 用来测试组件性能的我的项目，会作为和呈现问题的我的项目做行为测试比照。spring-boot:2.5.4、mysql-connector-java:8.0.26store：游戏库我的项目，正是这个我的项目发现了问题。spring-boot:2.6.6 、mysql-connector-java:8.0.28阿里云 RDS (MySQL): 阿里云 MySQL 默认的隔离级别为 READ_COMMITTED，而 MySQL 默认的隔离级别为 REPEATABLE_READ阐明：java-project 和 store 的 commons-db 版本其实不一样，因为不会影响后果。这里与他们版本统一。 问题一天，开发反馈，在 store 我的项目里应用 commons-db 组件时，呈现了事务回滚不失效的问题。如下图代码所示： @Transactional@DataSource(type = Type.MASTER,value = "developer")public void addUser(ApolloUser user){ userRepository.save(user); int i = 1/0; //抛异样}具体表现为：执行 addUser 办法，当 1/0 抛出 RuntimeException 类型异样时，user 对象还是增加胜利了。一句话总结就是，【事务回滚不失效了】。假如假如 1：曾假如过是不是 @Transactional 的 aop 没失效，导致并未开启显式事务。假如 1 不成立，因为在开启了 debug 日志模式后，清晰地输入了事务每个阶段的行为日志，如：假如 2：思考到应用了 commons-db , 如果框架层连贯治理问题，导致了事务的开启、事务回滚时获取到的连贯不统一，也有可能导致这个问题。假如 2 不成立：马上就否了，因为从下面日志上能够看到连贯是同一个连贯。而且不同连贯执行非预期的开启、回滚事务操作应该会有异样才是。那么到这里，问题就陷入了僵局。不禁深思，一个看上去人畜有害的代码，一个看上去逻辑清晰的事务日志，为什么会事务回滚生效呢？？？？？ ...

问题： 应用命令发现磁盘使用率为100%了，还剩几十兆。 一系列神操作 备份数据库，删除实例、删除数据库表、重启mysql服务，后果磁盘空间均没有开释。 怎么办 网上查了很多资源，说要进行磁盘碎片化整顿。起因是datafree占据的空间太多啦。具体能够通过这个sql查看。 SELECT CONCAT(TRUNCATE(SUM(data_length)/1024/1024,2),'MB') AS data_size,CONCAT(TRUNCATE(SUM(max_data_length)/1024/1024,2),'MB') AS max_data_size,CONCAT(TRUNCATE(SUM(data_free)/1024/1024,2),'MB') AS data_free,CONCAT(TRUNCATE(SUM(index_length)/1024/1024,2),'MB') AS index_sizeFROM information_schema.tables WHERE TABLE_NAME = 'datainfo';这个是起初的图了，之前的图没有留，过后显示一张表里的data_free都达到了20个G。网上举荐的做法如下所示，对表格进行碎片化整顿。 ALTER TABLE datainfo ENGINE=InnoDB;ANALYZE TABLE datainfo;optimize table datainfo;僵局： 查看数据库版本为5.562不反对inodb，要么抉择降级数据库。正在这时，有个不好的音讯产生了，那张表格给删掉了，然而磁盘空间还是没有开释啊。所以对表进行碎片化整顿的路也走不通了，因为表没了。。。 起初的神操作 1、应用命令查看mysql装置的地位和配置文件所在的中央 mysql 1118 945 0 14:28 ? 00:00:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock2、敞开mysql service mysql stop3、删除datadir目录下的ibdata1、ib_logfile0 ib_logfile1这些文件4、 挪动mysql的启动参数 mv /etc/my.cnf ./abc5、重新启动mysql 发现磁盘空间开释了 service mysql start 磁盘空间终于开释了 下一步数据库还原 1、采纳navicate备份工具，进行数据库备份备份胜利后生成了，生成psc文件。200409141055.psc 2、新建一个数据库实例，设置数据库名和字符集3、而后对备份数据库进行还原，点击还原4、开始进行还原 第一次还原后发现还原后数据库表建胜利了，然而表外面没有数据。 起初网上查找材料发现是，遇到谬误就进行了。所以更改了还原的配置，再次进行还原。之前是这样设置的还原时当成一个事务进行了，遇到谬误就进行了。更改配置从新进行还原，数据库里的数据有了，并且验证没有问题。 问题解决 mysql碎片化产生的起因 （1）表的存储会呈现碎片化，每当删除了一行内容，该段空间就会变为被留空，而在一段时间内的大量删除操作，会使这种留空的空间变得比存储列表内容所应用的空间更大； （2）当执行插入操作时，MySQL会尝试应用空白空间，但如果某个空白空间始终没有被大小适合的数据占用，依然无奈将其彻底占用，就造成了碎片； （3）当MySQL对数据进行扫描时，它扫描的对象理论是列表的容量需要下限，也就是数据被写入的区域中处于峰值地位的局部； ...

文章不易，请关注公众号 毛毛虫的小小蜡笔，多多反对，谢谢 问题在应用mysqldump的时候，报错了，具体报错信息如下所示：mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table xxx at row: 258609 剖析查问了相干文章，大略起因是在执行mysqldump的时候，数据量太大了，一次性接管不了那么多数据。所以server端发送过去的数据会积压在内存期待发送，这个等待时间就是net_write_timeout的工夫。 详情 请查看：毛毛虫的小小蜡笔

咱们平时建表的时候，个别会像上面这样。 CREATE TABLE user ( id int NOT NULL AUTO_INCREMENT COMMENT '主键', name char(10) NOT NULL DEFAULT '' COMMENT '名字', PRIMARY KEY (id)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;出于习惯，咱们个别会加一列 id 作为主键，而这个主键个别边上都有个 AUTO_INCREMENT, 意思是这个主键是自增的。自增就是 i++，也就是每次都加 1。 但问题来了。 主键 id 不自增行不行？ 为什么要用自增 id 做主键？ 离谱点，没有主键能够吗？ 什么状况下不应该自增？ 被这么一波诘问，念头都不通达了？ 这篇文章，我会尝试答复这几个问题。 主键不自增行不行当然是能够的。比方咱们能够把建表 sql 里的 AUTO_INCREMENT 去掉。 CREATE TABLE user ( id int NOT NULL COMMENT '主键', name char(10) NOT NULL DEFAULT '' COMMENT '名字', PRIMARY KEY (id)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;而后执行 ...

作者：胡呈清 爱可生 DBA 团队成员，善于故障剖析、性能优化，集体博客：https://www.jianshu.com/u/a95...，欢送探讨。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 一个报错在应用客户端登录MySQL8.0时，咱们常常会遇到上面这个报错： ERROR 2061 (HY000): Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection. 网络上很多帖子教咱们将用户认证插件批改成 mysql_native_password 来解决，那么事实上这是怎么一回事呢？本文就来探讨一二。 caching_sha2_password 简介caching_sha2_password 是 MySQL 8.0.4 引入的一个新的身份验证插件，它的特点从其命名就能够窥探出一二： sha2_password：其实就是 sha256_password，这是 MySQL5.6 就引入的身份验证插件，其长处是对加盐明码进行多轮 SHA256 哈希，以确保哈希转换更平安。其毛病为它要求应用平安连贯或应用 RSA 密钥对进行明码替换的未加密连贯，因而其身份验证的效率较低。caching：在 sha256_password 的根底上减少缓存，有缓存的状况下不须要加密连贯或 RSA 密钥对，已达到平安和效率并存。其实下面这个介绍不太容易懂，上面咱们以问答形式来揭开 caching_sha2_password 的面纱。 Q：要求应用平安连贯或应用 RSA 密钥对进行明码替换的未加密连贯是什么意思？ caching_sha2_password 对明码安全性要求更高，要求用户认证过程中在网络传输的明码是加密的： 如果是 SSL 加密连贯，则应用 SSL 证书和密钥对来实现 "对称加密密钥对（在TSL握手中生成）" 的替换，后续应用“对称加密密钥对” 加密明码和数据。具体见：MySQL:SSL 连贯浅析；如果是非 SSL 加密连贯，则在连贯建设时客户端应用 MySQL Server 端的 RSA 公钥加密用户明码，Server 端应用 RSA 私钥解密验证明码的正确性，能够避免明码在网络传输时被窥探。tips：SSL 加密连贯会不止会加密用户明码，还会加密数据（SQL 申请、返回的后果）；非加密连贯只应用 RSA 密钥对进行用户明码的加密。 ...

视频链接[https://www.bilibili.com/vide...] 从DB-Engines寰球数据库管理系统排名来看，开源DBMA风行水平逐年回升，2021年1月首次超过商业数据库，正式成为技术与市场改革的新引擎。开源数据库也曾经成为国产数据库实现解围的次要路径。 去年3月，开源还被正式列入“十四五”布局倒退大纲当中，这彰显着将来开源将成为数字翻新技术和数字经济的重要撑持力量，国产开源数据库又将迎来一个新春天！ 2022年6月8日下午14点，瀚高IvorySQL受邀加入墨天轮国产数据库沙龙第七期【开原生态专场】直播流动。瀚高IvorySQL产品经理王志斌分享《IvorySQL--一个基于PostgreSQL的兼容Oracle的开源数据库》为主题的直播交换。 本次直播次要介绍的内容： 介绍瀚高公司瀚高在PostgreSQL畛域做了哪些工作IvorySQL产生的背景、兼容个性、我的项目历程、团队组成、版本介绍、奉献路径、倒退及愿景“关注公众号，增加小助理微信即可取得PPT资料”

对于一个 comment 的表 有如下需要： 查问某个工夫以来，每个用户各发了几条评论 能够应用如下的 SQL 进行查问： select user_id, count(*)from commentwhere created_at > '2022-06-20'group by user_id;又有一个新的需要： 查问某个工夫以来，一共有几个用户发了评论 select count(*)from ( select user_id from comment where created_at > '2022-06-20' group by user_id ) as user_id_group_by

鄙人心愿能写一些对萌新有所帮忙的文章，若有舛误，还望不吝赐教。在 MySQL 中，当咱们将隔离等级明确为可反复读*（实际上是 MySQL 的默认事务隔离级别），接着运行一个事务，再开启另一个事务： A 事务首次查问；B 事务接着新增；A 事务随后蕴含 B 事务的新行进行更新，并再次查问；后果呈现变动，这仿佛没有防止直觉上的幻读。 既然如此，本篇文章就是来探索 MySQL 可反复读时，可解决的幻读到底是怎么的幻读？ 申明：任何 SQL 零碎中，可反复读的隔离级别都不要求解决幻读。咱们只是在探寻：MySQL 为了在这个层级解决幻读*（或局部幻读），做了哪些工作。 什么是幻读首先是直觉定义：当某个事务未实现前，只管可能有其余事务在执行，但我在本事务每次读取的后果，该当是统一的。 但随后咱们浏览 Wikipedia 的定义：当读取的 WHERE 条件并未加范畴锁时，因为另一事务对该范畴的数据进行增删改操作，导致本事务在两次读取时，后果不统一的状况。 会发现一个显著的差别：当 WHERE 没有加范畴锁，这句话意味着什么： 如果要躲避幻读，则必须加范畴锁——锁死本事务用到的所有数据——升高性能瓶颈；有没有加范畴锁或通过相似机制来保障本事务的相干数据一致性，成为幻读的一大判断根据。理清了定义，咱们来看看 MySQL 做了哪些工作。 MySQL 的一些机制首先，MySQL 在执行读取时，会产生两种读取形式。 快照读（一致性的非锁定读取）依据 MySQL 的定义，在咱们进行查问时，由 InnoDB 向查问出现数据库某个工夫点的快照，从而达成 一致性的非锁定读取机制。 而当隔离级别升格到可反复读时（MySQL 的事务默认隔离级别），整个事务过程中，都以事务开始时所用的快照为准。 试试 MySQL 官网给的栗子： # 事件ASET autocommit=0;# 事件BSET autocommit=0;# 事件ASELECT * FROM t;# 空后果# 事件BINSERT INTO t VALUES (1, 2);# 事件ASELECT * FROM t;# 空后果# 事件BINSERT INTO t VALUES (1, 2);# 事件ASELECT * FROM t;# 空后果# 事件BCOMMIT;# 事件ASELECT * FROM t;# 空后果COMMIT;SELECT * FROM t;# 有后果听起来一口气就解决了幻读问题，但咱们持续浏览更多信息： ...

一.请简述MySQL配置文件的加载程序？二.MySQL启动时如果找不到配置(参数)文件，会报错还是启动？三.如何查看MySQL参数？四.如何批改MySQL参数?五：MySQL有哪些类型表空间，简述各自作用？六：请简述MySQL redo log和binlog区别？ 一.请简述MySQL配置文件的加载程序？ MySQL读取配置文件的程序 读取程序：/etc/mysql/my.cnf>/etc/my.cnf>~/.my.cnf 命令验证： 办法1： [mysql@mysql01 bin]$ mysql --help|grep my.cnf/etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf order of preference, my.cnf, $MYSQL_TCP_PORT,[mysql@mysql01 bin]$ mysql --verbose --help | grep my.cnf/etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf order of preference, my.cnf, $MYSQL_TCP_PORT,办法2： [mysql@mysql01 bin]$ my_print_defaults --help|grep -A2 -B2 my.cnfDefault options are read from the following files in the given order:/etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf Variables (--variable-name=value)二.MySQL启动时如果找不到参数文件，会报错还是启动？ MySQL数据库参数文件的作用和Oracle数据库的参数文件极其相似，不同的是，Oracle实例在启动时若找不到参数文件，是不能进行装载（mount）操作。 MySQL略微有所不同，MySQL实例能够不须要参数文件，这时所有的参数值取决于编译MySQL时指定的默认值和源代码中指定参数的默认值。 如果MySQL实例在默认的数据库目录下找不到mysql架构，则启动同样会失败。 三.如何查看MySQL参数？ 能够把数据库参数看成一个键/值（key/value）对。 能够通过命令SHOW VARIABLES查看数据库中的所有参数，也能够通过LIKE来过滤参数名。 从MySQL 5.1版本开始，还能够通过information_schema架构下的GLOBAL_VARIABLES视图来进行查找。 show variables like '%timeout%';mysql> SHOW [{GLOBAL|SESSION}] VARIABLES [LIKE ''];mysql> SELECT @@{GLOBAL|SESSION}.VARIABLE_NAME;mysql> SELECT * FROM INFORMATION_SCHEMA.GLOBAL_VARIABLES WHERE VARIABLE_NAME='VARIABLE_NAME';mysql> SELECT * FROM INFORMATION_SCHEMA.SESSION_VARIABLES WHERE VARIABLE_NAME='VARIABLE_NAME';通过配置文件查看参数 ...

MySQL 归档服务需要剖析MySQL 罕用 OLTP 业务环境，个别会应用比拟好的硬件资源来提供对外服务。当初 MySQL 数据对外提供的数据动不动好几个 T 也是失常的。在很多业务中，数据有较强的生命周期，在线一段时间后，可能就是失去业务意义，如： 某个业务下线业务数据超过服务周期，例如某个业务只须要近 3 个月的数据业务操作的日志类型的数据进行归档分库分表的数据库须要合并到同一个中央，提供统计查问及剖析能力定期的备份归档，提供审计工作进行查问应用这类工作是 DBA 提出归档计划，由开发人员提出对哪些数据能够归档，标准后能够借助于自动化的执行实现。 常见 MySQL 归档解决的形式当初常见的归档形式个别分成两大类：MySQL & MariaDB，外围工具是：pt-archive 或是解析 binlog 获取归档的数据。 首先说第一类应用 MySQL 存储归档这类计划中，个别是通过购买 PC 机，通常是大容量（50T左右），大内存机型，能够跑实例，来对线上的生产库进行归档。甚至是备份同步。这种场景是最常见的。甚至见到在线下建一个主从，对 PolarDB 进行归档对外提供线下内网查问。 该形式的长处： 基于 MySQL 环境，大家都相熟好治理和线上环境根本能放弃同一个版本及高度的兼容归档环境能够应用大容量便宜的磁盘构建当然这种归档服务也有以下的毛病： 这种架构通常为了老本，归档节点通常没开启 Binlog，真正的备份还会放到对象存储中一份，也没有从库，如果产生数据损坏，或是硬盘损坏，数据恢复周期长。计算能力不够，根本没有能力对计算节点扩大，如果须要计算，通常须要把数据抽出来放到大数据环境中计算。这种架构存在大量的 CPU 和 RAM 资源的闲置第二类：应用 MariaDB 归档MariaDB 推出一个试验个性：S3 engine 该引擎有较高的较压缩能力，根本也放弃了 MySQL 的应用习惯。归档流程：先写 InnoDB，而后 alter table tb_name engine=s3; 该计划的长处： 根本放弃了 MySQL 兼容能力存储上反对 s3 类对象存储反对高压缩存储该计划的毛病： s3 引擎只能读，不能写不反对减少写入，如需扭转还须要转成 InnoDB 表每次 InnoDB 到 s3 引擎的转换须要十分长的工夫，减少了复杂度那么当初有没有更完满的计划呢？这里给大家给举荐云原生数仓 Databend Databend 能够提供的归档形式Databend  架构及介绍 ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 有客户在编写后期数据库安全标准时，就如何更平安的在 Linux Shell 端操作 MySQL 这一块，让咱们帮忙出一份详尽的阐明文档。其中有一项内容就是如何在 Linux Shell 下调用 MySQL 各种命令行工具时屏蔽掉烦人的告警信息输入，诸如上面这样： root@ytt-ubuntu18:/home/ytt# mysql -uytt -proot -e "select version()"mysql: [Warning] Using a password on the command line interface can be insecure.+-----------+| version() |+-----------+| 8.0.29 |+-----------+其实这是一个十分古老的问题！百度轻易一搜，各种解决办法都有，但都写的不是很欠缺。 这样的告警信息对命令执行后果的输入十分不敌对，那么咱们如何屏蔽掉它？上面我来列举下几种我能想到的办法，以供参考。 1、给用户空明码（不举荐）给用户赋予空明码尽管能够屏蔽掉正告信息，然而极不平安，相似于 MySQL 服务初始化时的 --initialize-insecure 选项。 root@ytt-ubuntu18:/home/ytt# mysql -u ytt_no_pass -e "select user()"+-----------------------+| user() |+-----------------------+| ytt_no_pass@localhost |+-----------------------+2、配置文件不同块退出用户名明码（不举荐）MySQL 的配置文件有 my.cnf、mysql.cnf、mysqld.cnf 等等，只有在这些配置文件里的不同块下增加对应的用户名和明码即可。 root@ytt-ubuntu18:/home/ytt# cat /etc/mysql/conf.d/mysql.cnf[mysql]prompt=mysql:\d:\v>user=yttpassword=rootport=3340[mysqldump]user=yttpassword=rootport=3340 [mysqladmin]user=yttpassword=rootport=3340以上[mysql]块下的内容示意对 mysql 命令行失效，[mysqldump]块下的内容示意对 mysqldump 工具失效，[mysqladmin]块下的内容示意对 mysqladmin 工具失效。 ...

在 InnoDB 引擎中，每张表都会有一个非凡的索引“聚簇索引”，也被称之为汇集索引，它是用来存储行数据的。个别状况下，聚簇索引等同于主键索引，但这里有一个前提条件，那就是这张表须要有主键，只有有了主键，它能力有主键索引，有主键索引能力等于聚簇索引。 所以看到这里，咱们应该明确一个情理：聚簇索引并不齐全等于主键索引，因为一张表从构造上来讲，能够没有主键（索引），如果没有主键（索引），那么聚簇索引就不再是主键索引了。那 InnoDB 中的聚簇索引到底是啥？ 聚簇索引诞生过程在 InnoDB 引擎下，聚簇索引的诞生过程如下： 当你为一张表创立主键时，也就是定义 PRIMARY KEY 时，此时这张表的聚簇索引就是主键索引。通常状况下，咱们应该为一张表设置一个主键，如果没有适合的列作为主键列，咱们能够定义一个主动递增的惟一列为主键，并且在插入数据时是主动填充此列。然而，如果一张表中没有设置主键，那么 InnoDB 会应用第一个惟一索引（unique），且此惟一索引设置了非空束缚（not null），咱们就应用它作为聚簇索引。如果一张表既没有主键索引，又没有符合条件的惟一索引，那么 InnoDB 会生成一个名为 GEN_CLUST_INDEX 的暗藏聚簇索引，这个暗藏的索引为 6 字节的长整数类型。总结在 InnoDB 引擎中，每张表都会有一个非凡的索引“聚簇索引”，个别状况下聚簇索引等于主键索引，但聚簇索引又不齐全等于主键索引，因为一张表中没有主键索引，那么聚簇索引会应用第一个惟一索引（此列必须为 not null），如果以上状况都不满足，那么 InnoDB 会生成一个暗藏的聚簇索引。 参考 & 鸣谢dev.mysql.com/doc/refman/5.7/en/innodb-index-types.html 是非审之于己，毁誉听之于人，得失安之于数。 公众号：Java面试真题解析 面试合集：https://gitee.com/mydb/interview

去重（过滤反复数据）在 MySQL 中应用 SELECT 语句执行简略的数据查问时，返回的是所有匹配的记录。如果表中的某些字段没有唯一性束缚，那么这些字段就可能存在反复值。为了实现查问不反复的数据，MySQL 提供了 DISTINCT 关键字。DISTINCT 关键字的次要作用就是对数据表中一个或多个字段反复的数据进行过滤，只返回其中的一条数据给用户。应用 DISTINCT 关键字时须要留神以下几点：DISTINCT 关键字只能在 SELECT 语句中应用。在对一个或多个字段去重时，DISTINCT 关键字必须在所有字段的最后面。如果 DISTINCT 关键字后有多个字段，则会对多个字段进行组合去重，也就是说，只有多个字段组合起来齐全是一样的状况下才会被去重。 # 对history表的value字段去重select distinct history.value from zabbix.hosts,zabbix.items,zabbix.history where hosts.name="zbxproxy03" and items.name="Context switches per second" and items.itemid=history.itemid;# 对history表的clock和value字段去重select distinct history.clock,history.value from zabbix.hosts,zabbix.items,zabbix.history where hosts.name="zbxproxy03" and items.name="Context switches per second" and items.itemid=history.itemid;# 查问去重之后的记录的条数select count(distinct history.clock,history.value) from zabbix.hosts,zabbix.items,zabbix.history where hosts.name="zbxproxy03" and items.name="Context switches per second" and items.itemid=history.itemid;别名为了查问不便，MySQL 提供了 AS 关键字来为表和字段指定别名当表名很长或者执行一些非凡查问的时候，为了不便操作，能够为表指定一个别名，用这个别名代替表原来的名称。表的别名不能与该数据库的其它表同名。字段的别名不能与该表的其它字段同名。在条件表达式中不能应用字段的别名表别名只在执行查问时应用，并不在返回后果中显示。而字段定义别名之后，会返回给客户端显示，显示的字段为字段的别名。表别名 # 上面为 zabbix 库中的 hosts 表指定别名 hselect h.name,h.host from zabbix.hosts as h where status=0;字段别名 ...

简介： 2003 年淘宝网成立之后，业务飞速发展，其后盾架构也进行了屡次迭代。2009 年之前，淘宝网后盾的数据库架构是经典的 IOE 组合。IOE 是指 IBM 的小型机、 Oracle 的数据库加上 EMC 的高端存储。这套组合老本昂扬，但仍然无奈满足淘宝网对于高并发、大容量的扩展性需要。 好的 MySQL 兼容性能够做到什么水平PolarDB-X 如何做生态兼容 ——吴学强（燧木） 阿里云数据库高级技术专家 理解更多PolarDB-X 内容：https://developer.aliyun.com/... 家喻户晓，数据库是根底的软件系统，而根底的软件都有本人的生态。生态的构建有两种范式，第一种范式是从 0 到 1 的构建，第二种是基于已有的生态持续演变。 分布式数据库是数据库畛域的热门方向，目前已有十分多的开源我的项目。这些开源的我的项目大多都抉择了第二种形式，即从已有的 MySQL 或 Oracle 生态进行本人的生态构建。 而采纳第二种形式，就不得不思考与已有生态的兼容性。兼容性并不是0 和 1 的二分区别，用兼容度来表白会更主观。作为新的数据库，更应该关注的是它解决了什么新的问题或是带来了什么新的个性。 一、为什么要兼容 MySQLimage.png 2003 年淘宝网成立之后，业务飞速发展，其后盾架构也进行了屡次迭代。2009 年之前，淘宝网后盾的数据库架构是经典的 IOE 组合。IOE 是指 IBM 的小型机、 Oracle 的数据库加上 EMC 的高端存储。这套组合老本昂扬，但仍然无奈满足淘宝网对于高并发、大容量的扩展性需要。 为了解决这两个问题， 2009 年，淘宝发动了“去 IOE” 静止，其指标是用自研的分库分表中间件 TDDL 加本人保护的 MySQL 分支 AliSQL 来替换 IOE 组合。这套架构在 2011 年双 11 大促的时候，胜利接管了交易的外围库之一——商品库，从而验证了 TDDL +AliSQL 计划的可行性。 ...

作者：王悦 Copyright (C) 2021 wingYue 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 最近应用了 bcc 工具集中的 dbslower ，这个工具能够探测 MySQL 指定阈值下的慢 query ，应用十分不便。 应用举例： 因为这个工具是一个 python 脚本，于是关上学习一下外部的机制。 首先开始的一段是一些应用案例： 这里咱们关注这两个： dbslower mysql -p 480 -m 30 # trace MySQL queries slower than 30msdbslower mysql -x $(which mysqld) # trace MySQL queries with uprobes同样是检测慢日志，一种是提供 pid ，另一种是提供二进制文件地址，粗看之下只是应用形式的不同，其实其中齐全走向了不同的机制。 咱们接着看下一段 这一段是用来确认最终应用的机制 mode ，如果提供 pid ，那么 mode=“MYSQL57” ，如果提供的是二进制地址，那么 mode=“USDT” 。 这里 USDT 指的是(Userland Statically Defined Tracing）用户态动态探针，也就是说，当应用 pid 时，脚本理论应用了 USDT 动态探针机制，而应用二进制文件时，则应用了另一种动静探针机制。要持续了解上面的段落，咱们先来看一下动态探针和动静探针到底是指什么。 ...

简介： 摘自刘永平（慕少）阿里云 PolarDB-X 技术专家在PolarDB-X | 新品发布会中的解说内容。理解更多PolarDB-X 内容：https://developer.aliyun.com/... 一、DN 高可用计划1.png 在 PolarDB-X 的系统结构中，DN 组件负责数据存储。 一个 DN 节点是 一个 MySQL 实例。为了数据安全，咱们须要多正本，一个逻辑实例是由多个 DN 节点组成的集群。为了业务间断，咱们须要高可用，当局部机器或网络故障后集群仍然可能继续提供服务。这些能力都须要 DN 节点自闭环实现，如果再引入第三方组件来治理，那么第三方组件的高可用又将是新的问题。2.png 单机 MySQL，或者其余数据库，罕用的高可用计划有以下几种：第一种是经典的一主一从构造，基于 KeepAlive 进行 HA 治理；第二种具备更高的可靠性，能够一主多从，用更简单的节点管理器协调系统的运行；另外还有 MySQL 社区的多主复制，有基于共享存储的部署模式等。以上解决方案都有其各自适宜的利用场景，但在设计上，须要思考的问题是相似地，那就是：实践上 CAP 中的分区可用性和数据一致性如何取舍？工程上实现的复杂度、稳定性以及高可用对性能带来的损耗有多少？3.png PolarDB-X 的 DN 存储集群采纳了强统一计划，集群通过 X-Paxos 一致性协定进行数据复制。其特点是：1) 在有 2n+1 节点的集群中可容忍最多 N 个节点故障；2) 节点间数据强统一，对利用而言，RPO=0 内置了一致性协定；3) 暗藏了简单的节点治理逻辑。所以，此计划的外围是一致性协定的应用。二、X-Paxos 协定4.png X-Paxos 是 Paxos 协定的具体实现，基于多数派实践保证数据一致性，其实践根底是经典的 Paxos 论文。当协定失常运行时，集群中有一个 Leader 节点，其余为 Follower 节点。业务申请从 Leader 进入，Leader 将申请转化为一条增量日志并将日志播送到所有 Follower；等少数节点确认收到日志后，Leader 将日志利用到状态机，返回业务响应。过程中只有少数节点衰弱，协定就能失常运行，且可能保障集群数据的强统一。另外，在协定模型中还有 learner 角色，它不参加多数派决策，只是集群数据的订阅者。协定的要害算法有两局部，首先是选主，选主是一个共识的过程，保障集群中同时只有一个 Leader 并且 Leader 已领有达成多数派的所有日志；其次，日志复制，即上图中的运行过程。5.png ...

简介： PolarDB-X 2.1 是 PolarDB-X 十分重要的版本，也是第一次 PolarDB-X 分布式数据库的产品能够作为企业级的分布式数据库真正部署到客户的生产环境应用。 PolarDB-X 2.1 新版本公布让“MySQL 原生分布式”触手可及 ——黄贵（曲山） 阿里云数据首席架构师 理解更多PolarDB-X 内容：https://developer.aliyun.com/... PolarDB-X 2.1 是 PolarDB-X 十分重要的版本，也是第一次 PolarDB-X 分布式数据库的产品能够作为企业级的分布式数据库真正部署到客户的生产环境应用。 一、一个好的MySQL分布式数据库应该是什么样的image.png C++语言设计的概念 Zero Overhead Abstraction ——0累赘形象准则，它有两个重要个性： 毋庸为不必的个性付出代价： C 类用户降级到 C++ 时，如果不应用 C++里的高级个性，则毋庸为这些个性付出额定的代价。比方在 C 外面是 structure，到 C++ 里可能是class 。对于 C 中的 structure 和 C++ 中的 class ，如果不带 virtual function ，则在内存布局的性能耗费上是等同的，不必付出额定的代价。你所应用的代码，不可能手写得更好：如果想要应用更高级的个性，用 C++ 扩大的能力，肯定比手写的代码更好，即C++ 提供的语言个性可能很好地帮忙到用户。 C 语言的用户降级到 C++，必然是因为它带来了更新更强的能力，比方封装、形象的能力，能够做继承、有多态。另外，C++ 提供了多种编程范式，比方面向对象、泛型编程、函数式编程等，这些个性都能够极大地拓展语言的形象，带来能力的晋升。 同理，从单机的 MySQL 数据库降级到分布式 MySQL 数据库，咱们冀望它能有哪些体现？ 首先是齐全兼容，能够由单机平滑过渡到分布式系统，无需对利用进行革新；第二，无需对数据库的构造进行革新；第三，不应用分布式能力则毋庸付出额定的开销。 单机到分布式最重要的变动是数据会散布在多个节点上，对于数据库中很多操作而言，尤其是事务，是须要付出一些额定代价的。如果事务波及到多个数据的分区，而只是想将分布式系统作为单机数据库来用，同样也能够有单表的个性，毋庸付出分布式事务的代价。 降级到分布式系统后可能取得主动伸缩的能力，可能人造地利用分布式的个性实现跨地区的高可用，还能够解决混合的负载类型，包含事务的负载以及剖析的负载，提供了高性价比的解决方案。 二、让分布式能力透明化image.png 如何实现从单机到分布式齐全透明化？ ...

MVCC（Multiversion Concurrency Control）：多版本并发管制，是一个数据库设计实践，解决了读写之间阻塞的问题，使得读操作不阻塞写，写操作不阻塞读，它进步了数据库的并发能力。MVCC 是通过快照来实现的，事务启动时会对整个库拍一个快照。 简略来说，MVCC 的思维就是保留数据的历史版本，通过治理数据行的多个版本实现并发管制；MVCC 没有一个对立的实现规范，典型的有乐观（optimistic）锁实现和乐观（pessimistic）锁实现； MVCC 只在 READ COMMITTED（读取已提交） 和 REPEATABLE READ（可反复读） 两个隔离级别下工作，其余两个隔离级别和 MVCC 不兼容，READ UNCOMMITTED 总是读取最新的数据行，而不是合乎以后事务版本的数据行；SERIALIZABLE 则会对所有读取的行都加锁。 可反复读和读提交在 MVCC 里的区别是： 在可反复读隔离级别下，只在事务开始时创立读视图，之后事务里的其余查问都用这个读视图；在读提交隔离级别下，每一个语句执行前都会创立一个读视图；MySQL 的 InnoDB 实现了 MVCC，InnoDB 的 MVCC 实现依赖：暗藏字段、Read View、Undo log。 首先咱们来理解一下快照读和以后读： 快照读和以后读快照读（SnapShot Read）：是一种一致性不加锁的简略 SELECT 操作，读取历史版本的数据或本身插入、批改的数据； 一致性读：指的是事务读取到的数据，要么是存在的历史数据，要么是本身插入或批改的数据；以后读（Current Read）：读取到的是最新的数据；更新数据时都是先读后写的，而这个读，只能读取以后的值，所以称为以后读，以后读必须加锁。以下 SQL 语句均应用以后读： select ... lock in share modeselect ... for updateinsertupdatedeleteInnoDB 如何存储多个版本的？首先，咱们每开启一个事务，就会取得一个事务 ID，这个 ID 是自增长的，能够通过 ID 晓得事务执行的工夫程序； 而后，InnoDB 在每行记录的前面增加了 3 个暗藏字段： DB_TRX_ID (6 字节)：示意最近一次对本记录行作批改（insert | update）的事务 ID，对于删除（delete）操作，InnoDB 认为是一个 update 操作，并不会真的删除这条记录，而是设置该行的删除标记位 deleted_bit，将行示意为 deleted；DB_ROLL_PTR (7 字节)：回滚指针，指向这个记录的 Undo log 信息；DB_ROW_ID (6 字节)：暗藏的枯燥递增的行 ID，如果表中没有主键或非空的惟一索引时，InnoDB 会用这个 ID 主动生成聚簇索引；这个字段与 MVCC 关系不大；回滚指针将数据行的所有历史版本通过链表连接起来，每个历史版本都保留了过后的事务 ID，这样咱们能够通过遍历链表来找到历史版本； ...

Apache ShardingSphere 助力当当 3.5 亿用户量级顾客零碎重构，由 PHP+SQL Server 技术栈无缝转型为 Java+ShardingSphere+MySQL，性能、可用性及维护性均失去显著晋升，是 ShardingSphere 异构迁徙最佳实际。1  顾客零碎背景当当顾客零碎次要负责账户的注册、登录、隐衷数据保护等性能，历史技术栈为 PHP+SQL Server，是规范的集中式架构，如下图。重构我的项目启动前，顾客零碎的数个业务模块存在多个辣手的业务问题和技术挑战，如逻辑扩散、吞吐量低及运维老本低等问题。为改善顾客的购物体验，当当技术团队决定对业务逻辑和底层数据架构进行优化，实现顾客零碎多场景下的可用性、扩展性及综合晋升等多个指标。在重构过程也实现了泛滥技术创新，如跨数据源双写、读写拆散、智能网关及灰度公布等技术。 从需要设计、分库分表布局、逻辑优化、压测再到齐全上线等多个环节，当当技术团队用半年的工夫实现了基于 3.5 亿+用户的零碎重构。 应用 Java 语言重构十余个模块，通过 ShardingSphere+ MySQL 构建分布式数据库解决方案，顺利完成异构数据库在线迁徙，案例亮点如下。 应用 Java 语言重构 PHP 业务代码；应用 ShardingSphere+MySQL 替换 SQL Server；在线实现 3.5 亿用户数据残缺迁徙；通过数据双写计划实现无缝上线。2  痛点&挑战业务痛点在业务层面，顾客零碎局部模块的注册和登录逻辑扩散在各端，保护老本较高，且过后的技术架构对于性能的晋升和高可用性存在着很大的局限性。 不易保护：多平台注册和登录逻辑较为扩散，业务保护简单；性能受限：PHP+SQL Server 集中式技术架构，吞吐量有余；可用性&安全性差：SQL Server 主备状态变动后，订阅库会生效，重新配置须要窗口工夫；SQL Server 运行在 Windows Server 上，病毒影响导致安全性差，且打补丁后降级启动工夫长（>30min）。挑战数据完整性顾客零碎领有 3.5 亿+ 用户数据，在数据迁徙过程中，需保证数据从 SQL Server 迁徙到 MySQL 后的一致性及完整性； API 通明API 对调用方放弃通明，确保调用方无改变，最小化变更界面； 无缝切换须要满足业务零碎无缝切换，切换过程对业务无影响； 工夫紧迫“618”和“11.11”促销流动前后会封网，因而需在两大促流动间、无限窗口的工夫内实现切换，并紧接着面对“11.11”的验证。 3  解决方案整体规划为了改善顾客零碎的可维护性、可用性及性能，研发团队从新梳理顾客零碎的架构。 在应用层，对立各端的性能逻辑，晋升业务可维护性。在数据库层，将集中式架构调整为分布式数据库架构，晋升性能及可用性，即 ShardingSphere+MySQL 构建的开源分布式解决方案。 应用层：随当当整体技术栈的变迁，业务开发语言由 PHP 转为 Java；中间件：应用成熟的开源数据库中间件 ShardingSphere 实现分库分表；数据库：应用多套 MySQL 集群代替 SQL Server 数据库。在整体架构设计上，引入了分布式主键生成策略、分片治理、数据迁徙校验以及灰度公布等多个计划。分布式主键生成策略数据库架构由集中式转型为基于中间件的分布式架构，分布式主键生成策略是首先须要思考解决问题。在零碎重构中，抉择建设两台以上的数据库 ID 生成服务器，每台服务器都有一张记录各表以后 ID 的 Sequence 表，Sequence 中 ID 增长的步长是服务器的数量。起始值顺次错开，这样相当于把 ID 的生成散列到了每台服务器节点上。 ...

下列视频为Mysql系列十一，该视频演示了如何进行许可更新和应用对象搜寻性能，欢送观看！此链接中还有【Mysql系列】其余操作视频：https://dbcs.deskui.com/pages...，连贯中的视频已更新成有声视频，欢送拜访！https://www.bilibili.com/vide...

为了帮忙各位朋友疾速应用HHDBCS中的性能窗口，社区已陆续推出了数据库治理上手系列！HHDBCS工具中的"监控治理性能"里含有链接监控、锁监控、系统监控三个性能窗口，其中系统监控能够查看以后零碎的网络、硬盘、内存、CPU应用状况。具体操作请观看下方视频！社区里还有“Mysql治理系列“其余操作视频：https://dbcs.deskui.com/pages...，欢送拜访！https://www.bilibili.com/vide...

　配置后盾InnoDB I/O线程数　InnoDB应用后盾线程来解决各种类型的I/O申请。您能够应用innodb_read_io_threads和innodb_write_io_threads配置参数来配置服务于数据页读写I/O的后盾线程数。这些参数别离示意用于读和写申请的后盾线程数。它们在所有反对的平台上都是无效的。你能够在MySQL选项文件(my.cnf或my.ini)中设置这些参数的值;不能动静地更改值。这些参数的默认值是4，容许的值范畴是1-64。　这些配置选项的目标是让InnoDB在高端零碎上更具扩展性。每个后盾线程最多能够解决256个I/O申请。后盾I/O的一个次要起源是预读申请。InnoDB试图均衡传入申请的负载，使得大多数后盾线程都能平等地工作。InnoDB也尝试将读申请从雷同的extent调配到雷同的thread，以减少合并申请的机会。如果你有一个高端的I/O子系统，你在SHOW ENGINE INNODB STATUS输入中看到超过64个innodb_read_io_threads挂起的读申请，你能够通过减少innodb_read_io_threads的值来进步性能。　在Linux零碎上，InnoDB默认应用异步I/O子系统来执行数据文件页面的预读和写申请，这扭转了InnoDB后盾线程服务这些类型的I/O申请的形式。　在Linux上应用异步I/O　InnoDB应用Linux上的异步I/O子系统(原生AIO)来执行数据文件页面的预读和写申请。这种行为由innodb_use_native_aio配置选项管制，该选项只实用于Linux零碎，默认状况下是启用的。在其余类unix零碎上，InnoDB只应用同步I/O。过来，InnoDB只在Windows零碎上应用异步I/O。在Linux上应用异步I/O子系统须要libaio库。　应用同步I/O，查问线程会对I/O申请进行排队，而InnoDB后盾线程每次会检索一个排队的申请，并对每个申请收回同步I/O调用。当一个I/O申请实现并且I/O调用返回时，InnoDB后盾解决这个申请的线程调用一个I/O实现例程并返回解决下一个申请。并行处理的申请数为n，其中n为InnoDB后盾线程数。InnoDB后盾线程数由innodb_read_io_threads和innodb_write_io_threads管制。　应用本机AIO，查问线程间接将I/O申请分发给操作系统，从而打消了后盾线程数量的限度。InnoDB后盾线程期待I/O事件来告诉实现的申请。当一个申请实现时，后盾线程调用一个I/O实现例程，而后持续期待I/O事件。　本机AIO的劣势是可伸缩性，对于I/O绑定重大的零碎，通常在SHOW ENGINE INNODB STATUS\G输入中显示许多挂起的读/写。应用本机AIO时并行处理的减少意味着I/O调度器的类型或磁盘阵列控制器的属性对I/O性能有更大的影响。　本机AIO对于大量I/O绑定的零碎的一个潜在毛病是无法控制一次调配给操作系统的I/O写申请的数量。分派给操作系统进行并行处理的I/O写申请太多，在某些状况下可能导致I/O读有余，这取决于I/O流动的数量和零碎能力。　如果操作系统中异步I/O子系统的问题导致InnoDB无奈启动，你能够应用innodb_use_native_aio=0来启动服务器。如果InnoDB检测到一个潜在的问题，比方tmpdir地位，tmpfs文件系统，以及Linux内核不反对tmpfs上的异步I/O，这个选项也能够在启动时主动禁用。

注释开始"XXX语句加了什么锁"自身就是个伪命题，一条语句到底加了什么锁受到很多条件制约： 以后事务的隔离级别，例如：RC隔离级别只会呈现记录锁，RR隔离级别才有可能呈现GAP锁SQL是一致性非锁定读(Consistent NonLocking Read，即一般select语句)还是DML(INSERT/UPDATE/DELETE)或锁定读(Locking Read)SQL执行时是否应用到了索引，以及所应用的索引类型(聚簇索引/主键索引、非聚簇索引/二级索引/辅助索引、惟一索引)表中的数据状况等，即两个SQL的执行打算是什么？索引扫描？全表扫描？以及数据分布间隙影响临键锁(Next-Key)加锁情况也和数据库的版本非亲非故，目前眼下5.7.x和8.0.x系列加锁逻辑基本一致，本文是基于mysql-8.0.25版本撰写的！1、隔离级别(isolation level)数据库事务须要满足ACID四个准则，"I"即隔离性，它要求两个事务互不影响，不能看到对方尚未提交的数据。数据库有4中隔离级别(isolation level)，依照隔离性从弱到强(相应地，性能和并发性从强到弱)别离是： Read Uncommitted，上面简称RURead Committed，上面简称RCRepeatable Read，上面简称RRSerializable"I"隔离性正是通过锁机制来实现的。提到锁就会波及到死锁，须要明确的是死锁的可能性并不受隔离级别影响，因为隔离级别扭转的是读操作的行为，而死锁是由写操作产生的。 规范SQL隔离级别SQL的规范制定者提出了不同的隔离级别：读未提交（READ-UNCOMMITED）、读已提交（READ_COMMITED）、可反复读（REPEATABLE-READ）、序列化读（SERIALIZABLE）。其中最高级隔离级别就是序列化读，而在其余隔离级别中，因为事务是并发执行的，所以或多或少容许呈现一些问题。 脏读：后一个事物读取并应用到前一个事务还未提交的数据，称之为脏读。不可反复读：前一个事务中屡次读取同一个数据，并且期间该同一数据被后一个事物批改过，而引发的前一事务读取到同一数据不同后果的问题，称之为不可反复读。幻读：幻读是指同一查问在同一事务中屡次进行，因为其余事务所做的插入操作，导致每次返回不同的后果集，此时产生幻像读，就好象产生了幻觉一样。第1类更新失落：A事务撤销时，把曾经提交的B事务的更新数据笼罩了。这类更新失落在目前支流数据库中曾经不存在了。第2类更新失落：A事务笼罩B事务曾经提交的数据，造成B事务所做操作失落。留神此处的第2类更新失落指的是诸如：update account set money = money + 100 where id = 'xxx'这种状况；而对于update account set money = 100 where id = 'xxx'则无能为力，因为这波及到ABA问题，四种隔离级别都不能解决该问题，能够借助乐观锁来解决。隔离级别是否存在脏读是否存在不可反复读是否存在幻读是否存在第1类更新失落是否存在第2类更新失落读未提交（READ-UNCOMMITED）是是是否是读已提交（READ-COMMITED）否是是否是可反复读（REPEATABLE-READ）否否是否否序列化读（SERIALIZABLE）否否否否否规范SQL事务隔离级别实现原理咱们下面遇到的问题其实就是并发事务下的管制问题，解决并发事务的最常见形式就是乐观并发管制了（也就是数据库中的锁）。规范SQL事务隔离级别的实现是依赖锁的，咱们来看下具体是怎么实现的： 事务隔离级别实现形式读未提交（RU）事务对以后被读取的数据不加锁； 事务在更新某数据的霎时（就是产生更新的霎时），必须先对其加行级共享锁，直到事务完结才开释。读已提交（RC）事务对以后被读取的数据加行级共享锁（当读到时才加锁），一旦读完该行，立刻开释该行级共享锁； 事务在更新某数据的霎时（就是产生更新的霎时），必须先对其加行级排他锁，直到事务完结才开释。可反复读（RR）事务在读取某数据的霎时（就是开始读取的霎时），必须先对其加行级共享锁，直到事务完结才开释； 事务在更新某数据的霎时（就是产生更新的霎时），必须先对其加行级排他锁，直到事务完结才开释。序列化读（S）事务在读取数据时，必须先对其加表级共享锁 ，直到事务完结才开释； 事务在更新数据时，必须先对其加表级排他锁 ，直到事务完结才开释。能够看到，在只应用锁来实现隔离级别的管制的时候，须要频繁的加锁解锁，而且很容易产生读写的抵触。 MySQL的隔离级别查看MySQL的隔离级别MySQL的默认隔离级别是：REPEATABLE-READ -- MySQL8.0版本查问语句-- 查问以后会话的事务隔离级别SELECT @@transaction_isolation;-- 查问全局的事务隔离级别SHOW VARIABLES LIKE '%transaction_isolation%';SELECT @@global.transaction_isolation;-- MySQL5.7版本查问语句-- 查问以后会话的事务隔离级别SELECT @@tx_isolation;-- 查问全局的事务隔离级别SHOW VARIABLES LIKE '%tx_isolation%';SELECT @@global.tx_isolation;设置MySQL的隔离级别-- 设置零碎以后隔离级别set global transaction isolation level repeatable read-- 设置以后会话隔离级别set session transaction isolation level repeatable read-- 设置下一个会话的隔离级别，这个没法验证，但的确起效set transaction isolation level repeatable read或者在my.cnf文件中设置： ...

一、索引与慢查问聊一聊索引和慢查问，常常遇到的一个问题：一个SQL语句应用了索引，为什么还是会记录到慢查问日志之中？为了阐明，创立一个表t，该表3个字段，一个主键索引，一个一般索引 CREATE TABLE `t` ( `id` int(11) NOT NULL, `a` int(11) DEFAULT NULL, `b` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `a` (`a`)) ENGINE=InnoDB;insert into t values (1, 1, 1), (2, 2, 2); 首先MySQL判断一个语句是不是慢查问语句，用的是语句执行工夫，它把语句执行工夫跟long_query_time这个零碎参数做比拟，如果语句执行工夫比long_query_time还大，就会把这个语句记录到慢查问日志里。 long_query_time这个参数它的默认值是10s，在生产上咱们不会设置这么大的值，个别会设置1s，对于一些对提早比拟敏感的业务，会设置一个比1还小的值，而对于语句是否应用了索引，它的意思是语句执行过程中有没有用到表的索引。 具体到表象中是explain一个语句的时候，输入后果外面key的值不是NULL，图1就是执行 explain select from t; 的后果。能够看到key这一列显示的是NULL。图2就是执行explain select from t where id = 2的后果，这里key显示的是PRIMARY，就是咱们常说的应用了主键索引。图3就是执行select a from t 的后果，这里key这一列显示的是a，示意应用了a这个索引。能够看到图2和图3的后果里key的字段都不是NULL，而实际上图3是扫描了整个索引树a。 这个示例的表外面只有两行，那如果有100万行呢，有100万行的时候图2的语句还是能够执行很快，然而图3就必定慢了，如果是更极其的状况，比方如果这个数据库上CPU压力十分地高，那可能第二个语句的执行工夫也会超过long_query_time，会记录到慢查问日志外面，所以如果简略地答复这个问题，是否应用索引只是示意了一个SQL语句的执行过程，而是否记录到慢查问日志中是由它的执行工夫决定的，而这个执行工夫可能会受各种内部因素的影响，也就是说是否应用索引和是否记录慢查问之间没有必然的分割。 二、索引的过滤性如果咱们再深层次的看这个问题其实它还潜藏着一个问题须要廓清就是，什么叫做应用了索引。咱们晓得InnoDB是索引组织表，所有的数据都是存储在索引树下面的，比方表t，这个表它蕴含了两个索引，一个主键索引一个一般索引a，在InnoDB里数据是放在主键索引里的。咱们来看一下这个表的数据示意图，能够看到数据都放在主键索引上，如果从逻辑上说，所有的在InnoDB表上的查问，都至多用了一个索引，当初有一个问题：如果执行explain select * from t where id > 0; 这个语句有用上索引吗？当初咱们来看看这个语句的explain的后果，在输入后果里，key这里显示的是PRIMARY，其实从数据上你是晓得的这个语句肯定是做了全表扫描，然而优化器认为，这个语句的执行过程中，须要依据主键索引定位到第一个满足id>0的值，也算用到了索引。所以你看，即便explain后果外面写了key不是NULL，实际上也可能是全表扫描的，因而InnoDB外面只有一种状况叫做没有应用索引，那就是从主键索引的最右边的叶节点开始，向右扫描整个索引树，也就是说，没有应用索引并不是一个精确的形容，你能够用全表扫描来示意一个查问遍历了整个主键索引树。也能够用全索引扫描来阐明，像select a from t这样的查问，它扫描了整个一般索引树。而像select * from t where id = 2; 这样的语句才是咱们平时说的应用了索引，它示意的意思是咱们应用了索引的疾速搜寻性能，并且无效的缩小了扫描行数。 ...

在 MySQL 中，删除的办法总共有 3 种：delete、truncate、drop，而三者的用法和应用场景又齐全不同，接下来咱们具体来看。 1.deletedetele 可用于删除表的局部或所有数据，它的应用语法如下： delete from table_name [where...] [order by...] [limit...]PS：[] 中的命令为可选命令，能够被省略。如果咱们要删除学生表中数学成绩排名最高的前 3 位学生，能够应用以下 SQL： delete from student order by math desc limit 3;1.1 delete 实现原理在 InnoDB 引擎中，delete 操作并不是真的把数据删除掉了，而是给数据打上删除标记，标记为删除状态，这一点咱们能够通过将 MySQL 设置为非主动提交模式，来测试验证一下。非主动提交模式的设置 SQL 如下： set autocommit=0;之后先将一个数据 delete 删除掉，而后再应用 rollback 回滚操作，最初验证一下咱们之前删除的数据是否还存在，如果数据还存在就阐明 delete 并不是真的将数据删除掉了，只是标识数据为删除状态而已，验证 SQL 和执行后果如下图所示： 1.2 对于自增列在 InnoDB 引擎中，应用了 delete 删除所有的数据之后，并不会重置自增列为初始值，咱们能够通过以下命令来验证一下： 2.truncatetruncate 执行成果和 delete 相似，也是用来删除表中的所有行数据的，它的应用语法如下： truncate [table] table_nametruncate 在应用上和 delete 最大的区别是，delete 能够应用条件表达式删除局部数据，而 truncate 不能加条件表达式，所以它只能删除所有的行数据，比方以下 truncate 增加了 where 命令之后就会报错： ...

日期处理函数在用WHERE子句比拟的时候如果须要用到的是日期，请应用Date()。这样能够防止在同一天，然而时分秒不是00:00:00导致的谬误，例如: SELECT cus_id, order_num FROM orders WHERE Date(order_date) = '2022-06-06';如果想要检索2022年6月的所有订单，咱们就须要思考到不同月份的天数，这里举荐应用BETWEEN关键字： SELECT cus_id, order_num FROM orders WHERE Date(order_date) BETWEEN '2022-06-01' AND '2022-06-30';数值处理函数罕用的如下： 参考：Forta B. MySQL crash course[M]. Pearson Education India, 2006.

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。前言你晓得MySQL启停都做了些什么吗？ 启动的时候初始化配置文件，读取redo配合binlog进行事务recover；进行的时候如同没有啥操作可做；印象中除了这些，就再没有了，至多在明天之前，我是这么认为的，我是真的浮浅。明天就来聊一聊MySQL对于启停的惯例操作。 进行过程先说一下比较简单的进行过程 1) 能够由具备shutdown权限的用户在客户端执行shutdown命令敞开，或者是由mysqladmin shutdown敞开； 2) 如果是由客户端发动的shutdown，则须要创立独自的线程进行敞开后续操作；如果server是接管到SIGTERM信号(linix操作系统的kill命令产生的信号)，则由接管到信号的线程执行敞开操作。须要留神的是，如果此时服务器内存应用十分高，可能会敞开失败，并将失败信息记录到error日志中。 :::block-1 阐明：SIGTERM 这个是shell命令kill默认的信号，过程收到此信号后，能够持续做一些解决而后再退出，具体的命令为kill pid 或者kill -15 pid，即这两个命令收回后，过程会平安的退出。 SIGKILL 这个是shell命令kill -9 pid发送的信号，过程接管到此信号后，会立刻进行过程，无奈按失常的退出流程执行。 因而，在linux操作系统中，如果应用kill命令进行MySQL服务，倡议应用kill (-15) pid，而不是kill -9 pid，尽管kill -9可能疾速进行，然而可能会对数据、文件造成毁坏，导致数据库无奈启动。::: 3) 敞开新的的连贯申请，回绝所有尝试通过TCP/IP、socket、pip、shared memory的建设的连贯。 4) 终止以后沉闷过程。其操作形式是标记所有线程的状态为killed，和咱们通过mysql client收回kill processlist_id一样，如果thread为sleep状态，线程很快就敞开。如果是正在运行语句的线程，并且是在事务中(比方innodb的dml)，则会进行回滚；如果是非事务中的语句(比方myisam表的dml)则会终止，导致批量插入可能局部胜利，SQL执行后果与预期不符。有一个非凡状况，如果实例是slave节点，会期待sql_thread线程执行完以后的组事务、SQL命令，以缩小复制问题。 5) 敞开server层、敞开存储引擎层。在这一步，会刷新表构造到磁盘，敞开所有关上的表，刷新LSN到表空间文件(ibd文件)。另外很重要的一点，对于innodb存储引擎，会将innodb_buff_pool中的局部内容刷新到磁盘(如果innodb_fast_down设置为2，则不会刷新innodb_buff_pool到磁盘)。 6) MySQL实例敞开胜利，返回操作后果的状态码(0/1/2)。 如果是由shell发动了kill -9，第3、4、5步都不会有，间接跳过 启动过程本章节原本是打算详细描述下MySQL的启动过程，然而能力无限，临时只察看到以下大略的启动步骤 整个启动过程，其余步骤比拟容易了解，唯独复原innodb_buffer_pool这一步骤是以前未曾察看到的，明天就来重点聊一下它。 性能阐明为了防止重新启动MySQL服务后长时间的预热，特地是对于设置了比拟大的innodb_buffer_pool_size的实例，能够在服务器敞开时保留buffer_pool内容，并在服务器启动时将buffer_pool复原到敞开前的状态，防止数据库刚开始运行的一段时间内业务拜访所有申请数据页都须要从新从磁盘上读取，减小数据库重启对系统带来的性能影响。 此性能在5.6版本引入，默认敞开；在5.7及之后的版本，就默认关上此性能。 参数阐明innodb_buffer_pool_dump_at_shutdown -- 管制在实例敞开时保留innodb_buffer_pool内容innodb_buffer_pool_dump_pct -- 管制保留innodb_buffer_pool的残缺度，默认25%，此参数是在5.7中减少。innodb_buffer_pool_load_at_startup -- 管制在实例启动时加载上次敞开时保留的innodb_buffer_pool内容应用介绍一般来说，实例运行过程中会加载大量数据进入buffer_pool中，然而在保留innodb_buffer_pool内容时，并不会残缺的保留所有数据，而是仅仅保留innodb_buffer_pool_dump_pct百分比的数据，按最近拜访工夫程序保留， 数据能够在information_schema.INNODB_BUFFER_PAGE_LRU中查问到，保留的内容也仅仅是保留了SPACE_ID+PAGE_NUMBER，而后通过这两个属性组成的惟一值，到物理磁盘上获取残缺数据， 保留的文件是在数据目录的ib_buffer_pool文件中，文件名是由innodb_buffer_pool_filename管制，能够看到相比innodb_buffer_pool_size的设置值，该文件十分小 [#3#root@greatdb81 /greatdb/dbdata/datanode4406/data 15:38:54]3 ll ib_buffer_pool -rw-r-----. 1 greatdb greatdb 10555 5月 31 11:17 ib_buffer_pool[#4#root@greatdb81 /greatdb/dbdata/datanode4406/data 15:39:00]4因为在启动过程中，须要加载ib_buffer_pool文件的内容，还须要到对应数据文件中去读取残缺用户记录，因而启动过程中会有比拟大的IO耗费，但这个复原是由独自的线程异步解决，并不会阻塞MySQL服务的失常启动。 ...

定义：依据须要，应用排列组合将已有的字段组合成新的字段 拼接字段比方，要将学校和地位是两个字段，但当初须要合并成学校（地址）的格局，就能够用Concat()函数实现： SELECT Concat(university_name, '(',university_address,')') FROM universities ORDER BY university_name;另外，为了除去字段多余的空格，MySQL反对： 去除字符串左边的空格的函数：RTrim()去除字符串右边的空格的函数：LTrim()去除字符串左右两边空格函数：Trim()比方要去除数据右侧多余的空格： SELECT Concat(RTrim(university_name), '(',RTrim(university_address),')') FROM universities ORDER BY university_name;应用别名拼接实现后只有一个值，没有名字，客户机无奈援用，咱们能够应用AS关键字进行赋予别名： SELECT Concat(university_name, '(',university_address,')') AS university_fullname FROM universities ORDER BY university_name;执行计算除了拼接字段之外，计算字段另外一个常见的用处是讲检索进去的数据进行数据计算。举个例子,咱们有商品数量和单价，想要查问出满足要求的不同商品的总价及相干信息： SELECT p_id, p_num,p_price, p_num * p_price AS total_price FROM customer_order WHERE order_num=1005参考：Forta B. MySQL crash course[M]. Pearson Education India, 2006.

和LIKE操作符用法类似，REGEXP通知MySQL，前面跟的是正则表达式。 根本字符匹配在正则表达式中 “.” 这个符号示意匹配任意一个字符，例如： SELECT p_name FROM products WHERE p_name REGEXP '.00' 这句话就能够匹配500和300等p_name 或匹配搜寻两个串之一，相似SELECT的OR语句 SELECT p_name FROM products WHERE p_name REGEXP '300|500' 匹配几个字符之一例如，想要匹配1bill和2bill和3bill，能够这样写： SELECT p_name FROM products WHERE p_name REGEXP '[1|2|3]bill'也能够间接简写成： SELECT p_name FROM products WHERE p_name REGEXP '[123]bill'匹配字符集和的否定只用在后面加一个^,例如想找到除了123以外的任何字符： SELECT p_name FROM products WHERE p_name REGEXP '[^123]'匹配范畴能够用‘-’联合[]来定义范畴，比方[1-3]、[c-g]例如： SELECT p_name FROM products WHERE p_name REGEXP '[1-3]bill'匹配特殊字符匹配特殊字符须要用‘//’来结尾，比方匹配‘.’: SELECT p_name FROM products WHERE p_name REGEXP '//.'匹配字符类（character class） 不是很罕用 ： 匹配多个实例举个例子，如果要同时匹配‘Bill （1 apple)’和‘Bill （8 apples）’: ...

在MySQL中应用LIKE操作符就是通知MySQL，前面的搜寻模式利用通配符进行匹配。 百分号通配符百分号代表任意字符呈现任意次数，例如上面这句sql能够找到producets中所有以apple结尾的p_name商品: SELECT p_id FROM products WHERE p_name LIKE 'apple%'留神尾空格会导致匹配不胜利，解决办法1.最初加%；解决办法2.应用函数去掉尾空白（举荐）。下划线通配符下划线通配符能够代表任意字符呈现一次 SELECT p_id FROM products WHERE p_name LIKE '_o_' 通配符搜寻效率低，慎用。 参考：Forta B. MySQL crash course[M]. Pearson Education India, 2006.

WHERE子句咱们个别应用where子句进行数据过滤，比方： SELECT p_id FROM products WHERE p_price<5;应用ORDER BY应该放在WHERE之后 否则会报错。WHERE子句的操作符除了有大于小于等于之外还有不等于(不等于有两种写法：<>和!=)以及闭区间内BETWEEN。特地地，MySQL有一个非凡的WHERE子句IS NULL用来判空： SELECT p_id FROM products WHERE p_price IS NULL;逻辑操作AND操作符须要同时满足多个过滤性条件的时候能够应用AND，每加一个条件加一个AND，例如： SELECT p_id FROM products WHERE p_price<500 AND p_brand='Apple';OR操作符不须要同时满足给出的所有条件，只有有一个条件满足即可，例如： SELECT p_id FROM products WHERE p_price<500 OR p_brand='Apple';MySQL中AND的优先级高于OR，所以如果要进行简单的逻辑运算请增加适当的圆括号。IN操作符IN操作符有点像枚举，用来筛选合乎括号内条件的数据，并且举荐应用IN，因为语法直观，计算秩序容易治理，操作比OR等更快，能够蕴含其余SELECT语句，例如： SELECT p_id FROM products WHERE p_brand IN （'Apple', 'HUAWEI');NOTNOT操作符能够筛选出不满足之后的条件数据，例如： SELECT p_id FROM products WHERE p_brand NOT IN （'Apple', 'HUAWEI');参考：Forta B. MySQL crash course[M]. Pearson Education India, 2006.

按某一列排序通过SELECT筛选后的数据，会间接以底层表中呈现的程序显示（收到数据存入的程序、数据增删更新等影响）SQL由子句形成，有些子句是必须的，有些事可选的。能够应用ORDER BY 子句对SELECT检索出的数据进行排序，ORDER BY 取一个或多个列名，并且据此进行输入排序。举个例子： SELECT p_name FROM products ORDER BY p_name;这样MySQL就会依照p_name的字母程序对数据进行排序输入 按多列排序未完待续。。。。

索引数据结构详解Hash应用哈希算法；数组+链表；哈希碰撞问题； 长处从算法工夫复杂度剖析来看，哈希算法工夫复杂度为 O（1），检索速度十分快。比方查找 id=1 的数据，哈希索引只须要计算一次就能够获取到对应的数据，检索速度十分快。 毛病如果应用哈希算法实现的索引，SQL的范畴查找怎么做呢？一个简略的思路就是一次把所有数据找进去加载到内存，而后再在内存里筛选筛选指标范畴内的数据。所以，应用哈希算法实现的索引尽管能够做到疾速检索数据，然而没方法做数据高效范畴查找，因而哈希索引是不适宜作为 Mysql 的底层索引的数据结构。二叉树如果insert的数据从小到大排序，该极其状况下会进化为线性链表，二分查找也会进化为遍历查找，工夫简单进化为 O（N），检索性能急剧下降。红黑树&&均衡二叉树红黑树：存在右倾趋势，树的高度只是没有线性链表那么夸大；均衡二叉树：AVL 树是个相对均衡的二叉树，因而它在调整二叉树的状态上耗费的性能会更多。每个树节点只存储了一个数据，每次查问都要进行屡次磁盘IO。能够依据这个思路，咱们能够在一个树节点上尽可能多地存储数据，一次磁盘 IO 就多加载点数据到内存，这就是 B 树，B+树的的设计原理了。B树优良检索速度，工夫复杂度：B 树的查找性能等于 O（h*logn），其中 h 为树高，n 为每个节点关键词的个数；每个节点存储多个数据，尽可能少的磁盘 IO，放慢了检索速度；能够反对范畴查找。B+树B树和B+树的区别：B树节点存储的是数据，B+树节点存储的是索引，只有叶子结点存在数据。单个节点也能够存储大量索引，使得树的高度升高，较少磁盘IO。（//TODO 回表操作）且叶子结点通过链表连接起来，链表是有序的，在数据的范畴查找场景中更高效。B+树如何实现索引疾速查找(//TODO)索引的分类汇集索引索引项的排序形式和表中数据记录排序形式统一的索引；非汇集索引索引项程序与物理存储程序不同；聚簇索引InnoDB存储引擎；数据和索引都存储在同一个文件里。比非聚簇索引快，因为聚簇索引多一次磁盘IO。非聚簇索引Myisam存储引擎；一种数据存储形式；表数据和索引是分成两局部存储的，主键索引和二级索引存储上没有任何区别。应用的是B+树作为索引的存储构造，所有的节点都是索引，叶子节点存储的是索引+索引对应的记录的数据。InnoDB和Myisam的区别InnoDB 节约磁盘空间；如果每个字段的索引树都存储了具体数据，那么这个表的索引数据文件就变得十分微小。Myisam 间接找到物理地址后就能够间接定位到数据记录，然而 InnoDB 查问到叶子节点后，还须要再查问一次主键索引树，才能够定位到具体数据。为什么举荐应用自增主键做索引如果主键为自增 id 的话，MySQL 在写满一个数据页的时候，间接申请另一个新数据页接着写就能够了。如果主键是非自增 id，为了确保索引有序，MySQL 就须要将每次插入的数据都放到适合的地位上。不便范畴查找//TODO（因为索引是有序） 联结索引的底层数据结构 Mysql最左前缀优化准则最左前缀匹配准则和联结索引的索引构建形式及存储构造是有关系的。首先咱们创立的index_bcd(b,c,d)索引，相当于创立了(b)、（b、c）（b、c、d）三个索引，看完上面你就晓得为什么相当于创立了三个索引。联结索引是首先应用多列索引的第一列构建的索引树，用下面idx_t1_bcd(b,c,d)的例子就是优先应用b列构建，当b列值相等时再以c列排序，若c列的值也相等则以d列排序。 select * from T1 where b = 12 and c = 14 and d = 3;-- 全值索引匹配 三列都用到。select * from T1 where b = 12 and c = 14 and e = 'xml';-- 利用到两列索引。select * from T1 where b = 12 and e = 'xml';-- 利用到一列索引。select * from T1 where b = 12 and c >= 14 and e = 'xml';-- 利用到bc两列列索引及索引条件下推优化。select * from T1 where b = 12 and d = 3;-- 利用到一列索引 因为不能跨列应用索引 没有c列 连不上。select * from T1 where c = 14 and d = 3;-- 无奈利用索引，违反最左匹配准则。

DQL（Data Query Language）蕴含： 单表查问多表查问根底语法select <columnName> from <tableName> where <condition>; : 我的项目中不倡议应用select * from xxx条件语句罕用：=、!=、<、>、<=、>=多条件查问罕用未完待续。。。。

一. mysql 批改明码1.mysql -u root -p root 输出原明码登录命令行2.use mysql;3.update user set password=password ('root123') where 'user' = 'root'; 5.7 版本 update user set authentication_string=password ('root123') where 'user' = 'root';4.flush privileges; 提交利用.5.You must reset your password using ALTER USER statement before executing this statement 必须批改长期明码，命令:alter user user () identified by '@Juaner521'; 二. mysql 批改近程连贯1.mysql -u root -p root2.use mysql;3.select host,user,password from user; 查看是否容许近程连贯4.grant all privileges on . to root@'%' identified by "password"; , 如果 报错，可换个办法 ...

摘要：本文回顾了“湖仓一体”概念提出的相干背景，具体地论述了为什么须要“湖仓一体”以及“湖仓一体”数据架构的具体构想。最初对数据仓库、数据湖以及“湖仓一体”进行了具体的比拟。 自 20 世纪 80 年代末以来，数据仓库在决策反对和商业智能应用领域中施展了重要作用。数据湖尽管数据仓库非常适合结构化数据，但许多古代企业必须解决非结构化数据，半结构化数据。数据湖是企业卸载所有数据的中央，因为其低成本存储系统具备文件API，能够保留通用和凋谢文件格式的数据，例如Apache Parquet和ORC。凋谢格局的应用还使数据湖中的数据能够间接被各种其余剖析引擎（如机器学习零碎）拜访。一开始，人们认为所须要的只是提取数据并将其放入数据湖中。一旦进入数据湖，最终用户就能够潜入并找到数据并进行剖析。然而，组织很快发现，应用数据湖中的数据与仅仅将数据搁置在湖中齐全不同。换句话说，最终用户的需要与数据科学家的需要有很大不同。最终用户遇到了各种各样的阻碍： 须要的数据在哪里？一个数据单位如何与另一个单位的数据相分割数据？数据是否是最新的？数据的准确性如何？因为不足一些要害的基础设施性能，数据湖的许多承诺尚未实现：不反对事务，不强制执行数据品质或治理，以及性能优化不佳。后果，企业中的大多数数据湖都变成了数据沼泽。以后数据架构的挑战以后常见的数据架构是应用多个零碎 （一个数据湖、多个数据仓库和其余专用零碎）来均衡数据仓库和数据湖的优劣势。然而，这会导致三个常见问题：低廉数据挪动老本超过90%的模仿/物联网数据存储在数据湖中，因为它具备凋谢间接拜访文件的灵活性和低成本，因为它应用便宜的存储。为了克服数据湖不足性能和品质问题，企业应用ETL（提取/转换/加载）将数据湖中的一小部分数据复制到上游数据仓库，用于最重要的决策反对和BI应用程序。这种双系统架构须要对数据湖和仓库之间的ETL数据进行继续工程设计。每个 ETL 步骤都有产生故障或引入升高数据品质的谬误的危险 — 保持数据湖和数据仓库的一致性既艰难又低廉。同时，ETL能够整合数据。限度了对机器学习的反对只管对机器学习和数据管理的交融进行了大量钻研，但没有一个当先的机器学习零碎，如TensorFlow，PyTorch和XGBoost，在仓库之上工作得很好。与提取大量数据的商业智能（BI）不同，机器学习零碎应用简单的非SQL代码解决大型数据集。不足开放性数据仓库将数据锁定为专有格局，这会减少将数据或工作负载迁徙到其余零碎的老本。鉴于数据仓库次要提供仅SQL拜访，因而很难针对数据仓库运行任何其余剖析引擎，例如机器学习零碎。“湖仓一体”的呈现在数据湖的根底上，呈现了一种新的数据架构，称为”湖仓一体“。采取Lake-First的方法论利用数据湖中已有的模仿和物联网数据，因为数据湖曾经将大多数结构化、文本和其余非结构化数据存储在低成本存储（如 Amazon S3、Azure Blob Storage 或 Google Cloud）上。为数据湖带来可靠性和品质反对ACID反对Sechema，提供星型、雪花等模型剖析能力，提供弱小的治理和审计机制。反对Sechema强制查看，从而避免谬误数据导致数据损坏。架构演进容许数据一直更改，使最终用户可能对可主动利用的 schema 进行更改，而无需繁琐的DDL。增加治理和安全控制通过 Scala、Java、Python 和 SQL API 反对 DML，以合并、更新和删除数据集，从而合乎 GDPR 和 CCPA，并简化变更数据捕捉等用例。历史记录提供无关对数据所做的每个更改的记录详细信息，从而提供更改的残缺审核跟踪。数据快照使开发人员可能拜访和复原到晚期版本的数据，以进行审核、回滚或重现试验。基于角色的访问控制为表的行/列级别提供细粒度的安全性和治理。优化性能通过利用文件统计信息和数据压缩来调整文件大小，实现各种优化技术，例如缓存、多维聚类、z-ordering、data skipping等。反对机器学习反对多种数据类型来存储、优化、剖析和拜访许多新应用程序的数据，包含图像、视频、音频、半结构化数据和文本。高效间接读取大量数据（非SQL），以便应用 R 和 Python 库运行机器学习试验。通过内置反对 DataFrame API 申明性 DataFrame API，可针对机器学习工作负载中的数据拜访进行查问优化，因为 TensorFlow、PyTorch 和 XGBoost 等机器学习零碎已采纳 DataFrames 作为操作数据的次要形象。机器学习试验的数据版本控制，提供数据快照，使数据迷信和机器学习团队可能拜访和复原到晚期版本的数据以进行审核和回滚或重现机器学习试验。提供开放性凋谢文件格式，如Apache Parquet和ORC。Open API提供了一个凋谢的API，能够间接高效地拜访数据，而无需专有引擎和供应商锁定。语言反对，不仅反对SQL拜访，还反对各种其余工具和引擎，包含机器学习和Python/R库。数据仓库 vs 数据湖 vs 湖仓一体下图表是对数据仓库、数据湖、湖仓一体的比拟：思考与探讨你认为湖仓一体架构必须具备哪些性能，能力称为真正的”湖仓一体“，而不是炒作概念。事务（ACID）反对凋谢文件格式数据安全、数据治理其它HashData湖仓一体利用实际随着企业数字化转型的推动，越来越多的企业视湖仓一体为数字化改革的契机。当然，关注度越高，市场上嘈杂的声音也就越多。在理论业务场景中，数据的挪动不只是存在于数据湖和数据仓库之间，湖仓一体不仅须要把数仓和数据湖集成起来，还要让数据在服务之间按需流动。HashData采纳湖仓一体化架构，能够不便、快捷地将大量数据从数仓转移至数据湖内，同时这些移到湖里的数据，依然能够被数仓查问应用。目前，HashData已广泛应用于金融、电信、交通等行业，服务超过50家行业客户。在能源畛域，HashData为某大型央企设计了基于计算存储拆散的架构数据湖, 相比计算存储绑定的架构，HashData云端数据湖在保障查问需要的同时，缩小了服务器资源老本。在PB级的数据量下，能够为企业节俭上百万的服务器洽购老本，充沛实现了降本提效的指标。

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。[toc] 一、placement new的定义通常状况下，C++中通过用new形式申请内存空间时，是在零碎的堆内存空间中进行调配，底层应用C规范库的malloc()实现内存调配工作。 因而本次申请的内存空间大小，是依据程序运行时对象的大小及应用状况来决定的。 然而某些场景中，可能须要事后调配实现内存空间，而后再把对象"搁置"在之前事后调配的内存空间上。即所谓的placement new操作。 定点搁置的new操作的语法不同于一般的new操作，比方：咱们个别在堆中申请内存空间，通常写： Object* o = new Object();而定点搁置new的语法模式为： Object* o = new (pointer) Object();这里的pointer就是事后调配好内存块的首地址。 二、placement new应用场景传统堆分配内存形式的弊病：通过new操作符进行堆内存的调配，操作系统须要在堆中找到间断且大小符合要求的内存空间，这个查问匹配的效率是低下的。 极其状况下可能因为空间有余，导致呈现内存调配失败的问题产生。 placement new调配形式：创立的对象都在事后调配好的内存缓冲区中操作，无需查问及匹配内存空间，内存调配的工夫是常量O(1)。 因为在之前预留的内存空间进行调配，因而不会呈现程序运行时因为内存空间有余，导致内存调配失败的问题。 三、placement new和 MySQL 内存管理机制的关系正是因为上述placement new的机制个性，因而其非常适合那些对工夫，性能要求高，长时间运行，不心愿被中断的应用程序。例如数据库这类的利用场景，就是很好的例子。 MySQL外部应用mem_root进行内存治理，能够实现屡次批量的内存空间申请，并且能够把对象搁置到mem_root定义的内存空间中，这样程序运行失败或者中途异样crash退出，咱们就无需关怀是否胜利开释内存。 所有都通过mem_root进行代理操作，整个内存的申请、调配、回收过程通明实现。 四、MySQL中 mem_root 应用场景//申明 mem_root 对象MEM_ROOT execute_mem_root;Query_arena execute_arena(&execute_mem_root,Query_arena::STMT_INITIALIZED_FOR_SP);//预分配内存块空间init_sql_alloc(key_memory_sp_head_execute_root, &mem_root, MEM_ROOT_BLOCK_SIZE, 0);//把thd中的mem_root指针指向execute_mem_root对应的内存块thd->swap_query_arena(execute_arena, &backup_arena);//把对象调配在事后申请的mem_root上LEX *sublex = new (thd->mem_root) st_lex_local;//一些逻辑计算操作......//开释表空间free_root(&execute_mem_root, MYF(0));总结：MySQL通过mem_root进行内存的对立申请、回收、治理。岂但晋升了内存调配的效率，进步了系统资源的利用率，而且缩小了内存碎片化，是MySQL性能晋升的一个重要抓手。 Enjoy GreatSQL :) 文章举荐：面向金融级利用的GreatSQL正式开源https://mp.weixin.qq.com/s/cI... Changes in GreatSQL 8.0.25 (2021-8-18)https://mp.weixin.qq.com/s/qc... MGR及GreatSQL资源汇总https://mp.weixin.qq.com/s/qX... GreatSQL MGR FAQhttps://mp.weixin.qq.com/s/J6... 在Linux下源码编译装置GreatSQL/MySQLhttps://mp.weixin.qq.com/s/WZ... # 对于 GreatSQL GreatSQL是由万里数据库保护的MySQL分支，专一于晋升MGR可靠性及性能，反对InnoDB并行查问个性，是实用于金融级利用的MySQL分支版本。 Gitee: https://gitee.com/GreatSQL/Gr... GitHub: ...