Mysql

作者：贲绍华 爱可生研发核心工程师，负责我的项目的需要与保护工作。其余身份：柯基铲屎官。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 当咱们应用 MySQL 进行数据存储时，个别会为一张表设置一个自增主键，当有数据行插入时，该主键字段则会依据步长与偏移量增长（默认每次+1）。 下文以 Innodb 引擎为主进行介绍，应用自增主键的益处有很多，如：索引空间占比小、范畴查问与排序都敌对、防止像 UUID 这样随机字符串带来的页决裂问题等... 一、自增ID是如何调配的？1.1 计数器的初始化当咱们对该表设置了自增主键之后，则会在该表上产生一个计数器，用于为自增列调配 ID 。 自增的值并不是保留在表构造信息内的，对于不同的版本它们有如下的区别： 1.1.1 MySQL 8.0 版本之前（重启后可能会产生变动）：计数器的值存储在内存中的，重启后抛弃，下一次将读取最大的一个自增ID往后持续发号。 https://dev.mysql.com/doc/ref... 1.1.2 MySQL 8.0版本（重启后放弃不变）：计数器的值将会长久化到磁盘。在每次发号时都将写入 Redolog ，并在每个 Checkpoint 都进行保留，重启时候应用 Redolog 复原重启之前的值。 https://dev.mysql.com/doc/ref... 1.2 数据的插入模式1.2.1 Simple Inserts（简略插入）：能够预先确定插入行数的语句（像简略 insert 的语句蕴含多个 value 这种状况也是属于简略插入，因为在进行插入时就曾经能够确定行数了） 1.2.2 Bulk Inserts（大量插入）：事后不晓得要插入的行数的语句（包含 INSERT ... SELECT, REPLACE ... SELECT 和 LOAD DATA 语句，但不包含 plain INSERT ） 1.3 AUTO-INC 表级锁如果一个事务正在向表中插入值，则会产生表级的共享锁，以便以后事务插入的行接管间断的主键值。 1.3.1 加锁策略：当处于[ 传统模式 ]与[ 间断模式 ]时，每次拜访计数器时都会加上一个名为 AUTO-INC 的表级锁 1.3.2 开释策略：传统模式：锁只持有到该语句执行完结，留神是语句完结，不是事务完结 间断模式：批量插入时锁持有到该语句执行完结，简略插入时锁持有到申请完自增ID后即开释，不直到语句实现 1.4 计数器的三种模式（innodb_autoinc_lock_mode）通过调整 innodb_autoinc_lock_mode 配置项，能够定义 AUTO-INC 锁的模式，不同的模式对应的策略与锁的粒度也将不同。 ...

作者：余振兴 爱可生 DBA 团队成员，热衷技术分享、编写技术文档。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 背景信息因为平安因素,客户须要将 MySQL 降级到 8.0.26 版本,但因为 8.0.26 的一些术语的不兼容性变更,对于监控采集的工具/程序会出现异常,针对这个状况，MySQL 官网也提供了解决方案，那就是新增了一个参数terminology_use_previous，当将该参数设置为BEFORE_8_0_26时，能够放弃 8.0.26 版本之前的术语模式，如仍旧放弃 master,slave 的术语模式，以下是官网文档 8.0.26 release note 的形容片段摘要 Incompatible Change: From MySQL 8.0.26, new aliases or replacement names are provided for most remaining identifiers that contain the terms “master”, which is changed to “source”; “slave”, which is changed to “replica”; and “mts” (for “multithreaded slave”), which is changed to “mta” (for “multithreaded applier”). Help text is also changed where applicable to use the new names.If the incompatible changes do have an impact for you, you can set the new system variable terminology_use_previous to BEFORE_8_0_26 to make MySQL Server use the old versions of the names for the objects specified in the previous list. This enables monitoring tools that rely on the old names to continue working until they can be updated to use the new names. The system variable can be set with session scope to support individual functions, or global scope to be a default for all new sessions. When global scope is used, the slow query log contains the old versions of the names.当降级到 8.0.26 实现后,数据库开启失常监控采集,频繁的触发了 MySQL crash ，须要剖析是什么起因导致，以下的剖析日志均为测试环境模拟。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。1. 遇到问题测试人员小玲筹备在docker环境中部署MGR集群进行一些测试，她有三个容器，容器IP别离是： 172.33.0.2172.33.0.3172.33.0.4每个容器中别离装置一个MySQL实例，每个实例的group_replication_local_address和group_replication_group_seeds两个配置项别离是： group_replication_local_address= "172.33.0.2:33061"group_replication_group_seeds= "172.33.0.2:33061,172.33.0.3:33061,172.33.0.4:33061"group_replication_local_address= "172.33.0.3:33061"group_replication_group_seeds= "172.33.0.2:33061,172.33.0.3:33061,172.33.0.4:33061"group_replication_local_address= "172.33.0.4:33061"group_replication_group_seeds= "172.33.0.2:33061,172.33.0.3:33061,172.33.0.4:33061"在通过了一番根底的筹备操作之后，小玲在172.33.0.2上执行START GROUP_REPLICATION，后果遇到了不应该呈现的错误信息： mysql> START GROUP_REPLICATION;ERROR 3092 (HY000): The server is not configured properly to bean active member of the group. Please see more details on error log.2. 问题排查察看谬误日志： 2021-07-13T03:11:42.645537Z 0 [Warning] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Connection attempt from IP address ::ffff:172.33.0.2 refused. Address is not in the IP allowlist.'2021-07-13T03:11:42.645622Z 0 [ERROR] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Error connecting to the local group communication engine instance.'依据谬误日志中的信息，咱们大略能够晓得报错的间接起因是172.33.0.2这个IP不在白名单中。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。利用ansible一键装置GreatSQL并实现MGR部署。本次介绍如何利用ansible一键装置GreatSQL并实现MGR部署。 本文介绍的运行环境是CentOS 7.9： [root@greatsql ~]# cat /etc/redhat-releaseCentOS Linux release 7.9.2009 (Core)[root@greatsql ~]# uname -aLinux greatsql 3.10.0-1160.11.1.el7.x86_64 #1 SMP Fri Dec 18 16:34:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux1. 装置ansbile间接用yum装置ansible即可： [root@greatsql ~]# yum install -y ansible查看版本号，确认装置胜利： [root@greatsql ~]# ansible --versionansible 2.9.21 config file = /etc/ansible/ansible.cfg configured module search path = [u'/root/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules'] ansible python module location = /usr/lib/python2.7/site-packages/ansible executable location = /usr/bin/ansible python version = 2.7.5 (default, Apr 2 2020, 13:16:51) [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)]这就OK了。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。为了方面社区用户体验GreatSQL，咱们同时还提供Docker镜像，本文具体介绍如何在Docker中部署GreatSQL，并且构建一个MGR集群。 本文波及的运行环境如下： [root@greatsql]# cat /etc/redhat-releaseCentOS Linux release 7.9.2009 (Core)[root@greatsql]# uname -aLinux GreatSQL 3.10.0-1160.11.1.el7.x86_64 #1 SMP Fri Dec 18 16:34:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux1、装置Docker间接用yum装置docker，十分省事。 [root@greatsql]# yum install -y docker之后启动 docker 服务，并设置开机自启动。 [root@greatsql]# systemctl enable docker[root@greatsql]# systemctl start docker2、拉取GreatSQL镜像，并创立容器2.1 拉取镜像拉取GreatSQL官网镜像： [root@greatsql]# docker pull greatsql/greatsqldocker pull greatsql/greatsqlUsing default tag: latestTrying to pull repository docker.io/greatsql/greatsql ...latest: Pulling from docker.io/greatsql/greatsql...Digest: sha256:63eff1b099a75bb4e96b2c5bc7144889f6b3634a6163b56642a71a189183966cStatus: Downloaded newer image for docker.io/greatsql/greatsql:latest查看是否胜利： [root@greatsql]# docker imagesREPOSITORY TAG IMAGE ID CREATED SIZEdocker.io/greatsql/greatsql latest d1963ef0c403 3 days ago 582 MB2.2 创立新容器之后，就能够间接创立一个新的容器了，先用惯例形式。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。MySQL作为最风行的开源关系型数据库，有大量的拥趸。其生态曾经相当欠缺，各项个性在圈内都有大量钻研。每次新个性公布，都会有业界大咖对其进行全面扫视、解读、钻研，本文要讲的MySQL binlog解析也有很多的前辈开发过优良的工具进行解析过（例如canal），本文再提旧案未免有造轮子嫌疑。 然而我作为菜鸟，通过MySQL Internals手册来钻研一下MySQL的binlog的协定、event类型、存储格局，并通过MySQL Internals手册的形容来窥探MySQL的数据存储格局，并且学习Golang语言个性，应该还有肯定的学习意义。 所以不揣冒昧，对解析binlog的过程编辑了以下，来梳理我对binlog只知其一;不知其二，心愿不会贻笑大方之家。 波及到的工具版本信息： IDE: GoLand 2021.1.1 试用版Golang: go1.12.10DB: mysql 8.0.23MySQL Internals手册： https://dev.mysql.com/doc/int... Talk is cheap,show the code. 一、MySQL binlogbinlog是对数据库执行的所有DDL、DML语句以事件（event）模式记录的的日志，事务平安，目标是用来进行复制和复原应用，是MySQL重要的个性之一。 在解析binlog之前数据库须要开启binlog。 配置如下参数： [mysqld]log-bin=mysql-binserver-id=1binlog_format=ROW~注：binlog_format格局还有statement和mixed格局，篇幅所限，这里只探讨RBR状况。~ 解析binlog，MySQL提供了mysqlbinlog工具来解析binlog文件。但这里我是通过程序模仿一个从库（slave）角色来解析流式的binlog，所以须要创立账号，用来连贯主库和申请binlog。其中： 1、获取主库binlog，必须有REPLICATION SLAVE权限。2、获取binlog filename和position必须有REPLICATION CLIENT或SUPER权限倡议的受权： CREATE USER mysqlsync@'%' IDENTIFIED BY 'mysqlsync';GRANT REPLICATION SLAVE, REPLICATION CLIENT, SELECT ON *.* TO 'mysqlsync'@'%';二、解析流程解析形式时模仿从库（slave），MySQL的从库在通过ip、port、user、password连贯主库后，向主库发送： binlogPositionbinlogFlagserverId而后获取主库binlog。 程序实现解析binlog首先是连贯主库注册slave身份。而后向主库发送COM_BINLOG_DUMP或COM_BINLOG_DUMP_GTID申请binlog。 COM_BINLOG_DUMP与COM_BINLOG_DUMP_GTID的区别在于COM_BINLOG_DUMP_GTID如果发送的通信包内不蕴含binlog-filename，主库则从已知的第一个binlog发送binlog-stream。 手册 14.9.6 介绍： If the binlog-filename is empty, the server will send the binlog-stream of the first known binlog. 流程如下：1、连贯Master数据库输出数据库IP:PORT，用户名明码连贯到Master数据库。2、设置相干参数master_binlog_checksum：MySQL在5.6版本之后为binlog引入了checksum机制，从库须要与主库相干参数保持一致。server_id：解析程序相当于一个从库，须要向主库发送set注册@master_binlog_checksum= @@global.binlog_checksum.3、注册从节点告知客户端的host、port、用户名与明码、serverId 发送COM_BINLOG_DUMP向Master申请binlog stream.4、接管binlog stream接管binlog后，依据event type解析获取数据输入。三、解析binlog3.1 连贯主库程序应用tcp协定来连贯主库，所以须要构建mysql协定的通信包来与主库进行三次握手。在通信包构建以及连贯、发送和读取通信包，调用了kingshard的源码，见： ...

需要如下在后盾会针对商品SKU配置售卖开始工夫startTime和售卖完结endTime，当初想做一查问性能在查问框中输出一个查问开始工夫和查问完结工夫，查问在这段时间范畴内售卖的SKU并展现进去，比方当初是12月，之前配置了一个SKU它的售卖工夫是10月1日至11月6日，那么输入框中输出9月1日-10月1日、10月1日-11月6日、11月6日至12月1日等，都已查到此配置。 转化成代码语言就是：SKU售卖配置的时间段和查问输出的时间段，两段工夫取交加，若有值则代表此配置ok。 图解 select * from lingyejun.product_config where(startTime > reqStartTime AND startTime <= reqEndTime) OR (startTime < reqStartTime AND endTime > reqEndTime) OR(endTime >= reqStartTime AND endTime < reqEndTime)本篇文章如有帮忙到您，请给「翎野君」点个赞，感谢您的反对。

作为最风行的开源数据库软件之一，MySQL数据库软件曾经广为人知了。以后很火的Facebook、腾讯、淘宝等大型网站都在应用MySQL的数据库。 互联网行业的少数业务场景有非常明显的特点：用户量大、引发 数据容量大、并发高、业务复杂度适中。MySQL数据库产品初期的定位 就是Web利用的数据服务，故简直所有互联网企业都应用MySQL数据库产品，有很多企业简直全副应用MySQL提供的数据服务。 这本《MySQL性能优化和高可用架构实际》从企业实战的角度纵观整个MySQL生态体系，将两大关键技术有机交融，并比照了多种计划， 为读者展示了多种在两个实质上矛盾的个性之间获得均衡的精妙办法，对实践架构与企业实战都有丰盛的指导意义。浏览本书，你能够站在对数据畛域有多年深耕教训的作者肩膀上，吸取作者的实践经验与心血总结，从作者的角度了解和意识数据技术，一步赶上云与智能时代的数据技术倒退前沿。 本书分为13章，详解MySQL 5.7数据库体系结构，InnoDB存储引 擎，MySQL事务和锁，性能优化，服务器全面优化、性能监控，以及MySQL主从复制、PXC、MHA、MGR、Keepalived+双主复制等高可用集群架构的设计与实际过程，并介绍海量数据分库分表和Mycat中间件的实战操作。 须要《MySQL性能优化和高可用架构实际》文档的小伙伴，点赞+转发之后【点击此处】即可收费获取！第1章 MySQL架构介绍1.1 MySQL简介1.2 MySQL支流的分支版本1.3 MySQL存储引擎1.4 MySQL逻辑架构1.5 MySQL物理文件体系结构第2章　InnoDB存储引擎体系结构2.1　缓冲池2.2　change buffer2.3　自适应哈希索引2.4　redo log buffer2.5　double write2.6　InnoDB后盾线程2.7　redo log2.8　undo log2.9　Query Cache第3章　MySQL事务和锁3.1　MySQL事务概述3.2　MySQL事务隔离级别3.3　InnoDB的锁机制介绍3.4　锁期待和死锁3.5　锁问题的监控第4章　SQL语句性能优化4.1　MySQL查问过程4.2　创立高性能索引4.3　慢SQL语句优化思路4.4　索引应用的准则及案例剖析第5章　MySQL服务器全面优化5.1　MySQL 5.7 InnoDB存储引擎加强个性5.2　硬件层面优化5.3　Linux操作系统层面优化5.4　MySQL配置参数优化5.5　MySQL设计规范须要《MySQL性能优化和高可用架构实际》文档的小伙伴，点赞+转发之后【点击此处】即可收费获取！第6章　MySQL性能监控6.1　监控图表的指导意义6.2　Lepus数据库监控零碎实战第7章　MySQL主从复制详解 7.1　主从复制的概念和用处7.2　主从复制的原理及过程形容7.3　主从复制的重点参数解析7.4　主从复制的部署架构7.5　异步复制7.6　半同步复制7.7　GTID复制7.8　多源复制7.9　主从复制故障解决7.10　主从提早解决方案和并行复制第8章　PXC高可用解决方案8.1　PXC概述8.2　PXC的实现原理8.3　PXC集群的优缺点8.4　PXC中的重要概念8.5　PXC集群部署实战8.6　PXC集群状态监控8.7　PXC集群的实用场景和保护总结第9章　基于MHA实现的MySQL主动故障转移集群9.1　MHA简介9.2　MHA原理9.3　MHA的优缺点9.4　MHA工具包的性能9.5　MHA集群部署实战第10章　MySQL Group Replication10.1　MGR概述10.2　MGR基本原理10.3　MGR服务模式10.4　MGR的注意事项10.5　MGR部署实战10.6　MGR的监控10.7　MGR的主节点故障无感知切换第11章　Keepalived+双主复制的高可用架构11.1　Keepalived+双主架构介绍11.2　Keepalived介绍11.3　双主+Keepalived集群搭建第12章　数据库分库分表与中间件介绍12.1　关系数据库的架构演变12.2　分库分表带来的影响12.3　常见的分库分表中间件介绍第13章　Mycat中间件详解13.1　Mycat简介13.2　Mycat外围概念13.3　Mycat装置部署13.4　Mycat配置文件详解13.5　Mycat分库分表实战13.6　Mycat读写拆散实战须要《MySQL性能优化和高可用架构实际》文档的小伙伴，点赞+转发之后【点击此处】即可收费获取！

基础架构构造Server层包含连接器，查问缓存，分析器，优化器，执行器等涵盖Mysql大多数外围服务性能，和所有内置函数（日期，工夫，数学，加密等）实现所有跨存储引擎的性能（存储过程，触发器，视图等）存储引擎层负责数据的存储和提取架构模式是插件式的，从Mysql5.5.5开始InnoDB成为默认存储引擎1.连接器连贯Mysqlmysql -h$ip -P$port -u$user -p一个用户胜利建设连贯后，即便你用管理员账号对这个用户的权限做了批改，也不会影响曾经存在连贯的权限。批改实现后，只有再新建的连贯才会应用新的权限设置。 闲暇连贯连贯实现后，如果你没有后续的动作，这个连贯就处于闲暇状态show processlistCommand 列显示为“Sleep”的这一行，就示意当初零碎外面有一个闲暇连贯。客户端如果太长时间没动静，连接器就会主动将它断开。这个工夫是由参数 wait_timeout 管制的，默认值是 8 小时。短连贯短连贯则是指每次执行完很少的几次查问就断开连接，下次查问再从新建设一个。长连贯(举荐)长连贯是指连贯胜利后，如果客户端继续有申请，则始终应用同一个连贯。MySQL 在执行过程中长期应用的内存是治理在连贯对象外面的。这些资源会在连贯断开的时候才开释。如果长连贯累积下来，可能导致内存占用太大，被零碎强行杀掉（OOM），从景象看就是 MySQL 异样重启了。 解决办法： 定期断开长连贯。应用一段时间，或者程序外面判断执行过一个占用内存的大查问后，断开连接，之后要查问再重连。MySQL 5.7 或更新版本，能够在每次执行一个比拟大的操作后，通过执行 mysql_reset_connection 来从新初始化连贯资源。这个过程不须要重连和从新做权限验证，然而会将连贯复原到刚刚创立完时的状态。2.查问缓存（Mysql8.0已删除）MySQL拿到一个查问申请后，会先到查问缓存看看，之前是不是执行过这条语句。MySQL之前执行过的语句及其后果可能会以 key-value 对的模式，被间接缓存在内存中。查问缓存的生效十分频繁，只有有对一个表的更新，这个表上所有的查问缓存都会被清空。能够将参数 query_cache_type 设置成 DEMAND，这样对于默认的 SQL 语句都不应用查问缓存。强制查问缓存语句 select SQL_CACHE * from T where ID=10；3.分析器分析器先会做“词法剖析”。你输出的是由多个字符串和空格组成的一条 SQL 语句，MySQL 须要辨认出外面的字符串别离是什么，代表什么。如果没有命中查问缓存，就要开始真正执行语句了。 语法错误揭示：ERROR 1064 (42000): You have an error in your SQL syntax; 4.优化器优化器是在表外面有多个索引的时候，决定应用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连贯程序。5.执行器开始执行的时候，要先判断一下有没有执行权限，如果没有，就会返回没有权限的谬误如果有权限，就继续执行，执行器会依据表的引擎定义，去应用这个引擎提供的接口。示例： mysql> select * from T where ID=10;执行流程： 调用 InnoDB 引擎接口取这个表的第一行，判断 ID 值是不是 10，如果不是则跳过，如果是则将这行存在后果集中；调用引擎接口取“下一行”，反复雷同的判断逻辑，直到取到这个表的最初一行。执行器将上述遍历过程中所有满足条件的行组成的记录集作为后果集返回给客户端。数据库的慢查问日志中有一个rows_examined字段，示意这个语句执行过程中扫描了多少行。这个值就是在执行器每次调用引擎获取数据行的时候累加的。 小结问题：如果表 T 中没有字段 k，而你执行了这个语句 select * from T where k=1, 那必定是会报“不存在这个列”的谬误： “Unknown column ‘k’ in ‘where clause’”。你感觉这个谬误是在咱们下面提到的哪个阶段报进去的呢？答案：分析器。Oracle会在分析阶段判断语句是否正确，表是否存在，列是否存在等。其余答案：预处理器。解析器解决语法和解析查问, 生成一课对应的解析树。预处理器进一步查看解析树的非法。比方: 数据表和数据列是否存在, 别名是否有歧义等。如果通过则生成新的解析树，再提交给优化器。 ...

MySQL最重要、最不同凡响的个性是它的存储引擎架构，这种架构的设计将查询处理（Query Processing）及其他零碎工作（Server Task）和数据的存储/提取相拆散。这种解决和存储拆散的设计能够在应用时依据性能、个性，以及其余需要来抉择数据存储的形式。 1.连贯层 最上层是一些客户端和连贯服务，蕴含本地sock通信和大多数基于客户端/服务端工具实现的相似于tcplip的通信。次要实现一些相似于连贯解决、受权认证、及相干的平安计划。在该层上引入了线程池的概念，为通过认证平安接入的客户端提供线程。同样在该层上能够实现基于SSL的平安链接。服务器也会为平安接入的每个客户端验证它所具备的操作权限。 ⒉服务层 第二层架构次要实现大多少的外围服务性能，如SQL接口，并实现缓存的查问，SQL的剖析和优化及局部内置函数的执行。所有跨存储引擎的性能也在这一层实现，如过程、函数等。在该层，服务器会解析查问并创立相应的外部解析树，java培训并对其实现相应的优化如确定查问表的程序，是否利用索引等，最初生成相应的执行操作。如果是select语句，服务器还会查问外部的缓存。如果缓存空间足够大，这样在解决大量操作的环境中可能很好地晋升零碎的性能。 3.引擎层 存储引擎层，存储引擎真正的负责了MySQL中数据的存储和提取，服务器通过API与存储引擎进行通信。不同的存储引擎具备的性能不同，这样咱们能够依据本人的理论须要进行选取。前面介绍MyISAM和InnoDB 4存储层 数据存储层，次要是将数据存储在运行于裸设施的文件系统之上，并实现与存储引擎的交互。 SHOW ENGINES; SHOW VARIABLES LIKE '%storage_engine%'; 创立新表时如果不指定存储引擎，那么零碎就会应用默认存储引擎，MySQL5.5之前的默认存储引擎是MyISAM，5.5之后改为了InnoDB。 MySQL中同一个数据库，不同的表格能够抉择不同的存储引擎。 l MyISAM不反对事务、也不反对外键，其劣势是拜访的速度快，对事务完整性没有要求或者以SELECT、INSERT为主的利用。每个MyISAM在磁盘上存储成三个文件。第一个文件的名字以表的名字开始，扩展名指出文件类型。.frm文件存储表定义。数据文件的扩大名为.MYD (MYData)。索引文件的扩展名是.MYI (MYIndex)。 l InnoDB存储引擎提供了具备提交、回滚和解体恢复能力的事务平安。西安java培训然而比照MyISAM的存储引擎，InnoDB写的解决效率差一些，并且会占用更多的磁盘空间以保留数据和索引。InnoDB：所有的表都保留在同一个数据文件中，InnoDB表的大小只受限于操作系统文件的大小限度。Myisam只缓存索引，不缓存实在数据；Innodb不仅缓存索引还要缓存实在数据，对内存要求较高，而且内存大小对性能有决定性的影响。 l MEMORY存储引擎应用存在于内存中的内容来创立表。MEMORY类型的表拜访十分的快，因为它的数据是放在内存中的，并且默认应用HASH索引，然而一旦服务敞开，表中的数据就会失落。次要用于那些内容变动不频繁的代码表或者作为统计操作的两头后果表。

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。内容提纲一、测试环境搭建 二、执行过程解析 三、注意事项 一、测试环境搭建首先创立一张表，并插入几行数据字段： CREATE TABLE t (s1 INT, s2 char(100),PRIMARY KEY (s1));INSERT INTO t values(1,'aaa');INSERT INTO t values(2,'bbb');INSERT INTO t values(3,'ccc');接着创立存储过程，这里的v_total用于判断数据行数。 因为MySQL游标获取完后，最初一行没有退出机制。所以不进行判断是否取完最初一行，就持续取数会产生报错。 DELIMITER ;; CREATE PROCEDURE test_mysql_cursor_loop() BEGIN declare v_total int default 0; declare i int default 0; declare str1 int; declare str2 varchar(255); DECLARE stuCursor CURSOR FOR SELECT s1,s2 FROM t; select count(s2) into v_total from t; OPEN stuCursor; stuLoop:LOOP IF i = v_total THEN LEAVE stuLoop; end if; FETCH stuCursor INTO str1,str2; SELECT str1,str2; set i = i+1; end loop stuLoop; END;;DELIMITER ;二、执行过程解析这个存储过程在MySQL外部转化为存储过程指令如下： ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。一、发现问题小玲是一名数据库测试人员，这一天她尝试在docker环境中部署GreatDB集群，后果在对greatsqld过程进行kill操作后，意外发现greatsqld过程变成了僵尸过程（如下图所示）。 因为小玲成为测试人员的工夫较短，她没有遇见过这种状况，所以无奈第一工夫判断这个景象，是她的操作失误导致的正当景象，还是一个新发现的bug。 于是她进行了以下尝试： 1.在物理机上反复上述操作，并没有呈现僵尸过程。2.在docker内，对MySQL的mysqld过程进行雷同操作，呈现了僵尸过程。通过这样的尝试，小玲初步判断出docker环境才是产生僵尸过程的本源，但具体是什么起因，又该如何防止，还须要小玲的进一步摸索。 二、僵尸过程简介首先须要搞清楚的是： 僵尸过程是什么？僵尸过程又是如何造成的？以下定义内容和解决办法来自维基百科。 僵尸过程：在类UNIX零碎中，僵尸过程是指实现执行（通过exit零碎调用，或运行时产生致命谬误或收到终止信号所致），但在操作系统的过程表中依然存在其过程管制块(PCB)，处于"终止状态"的过程。僵尸过程不能被杀死，因为它们曾经死亡，只期待它们的父过程回收它们。通过这样的概念，和其余一些相干资料，小玲理解了僵尸过程的呈现，问题多半是呈现僵尸过程的父过程上。 这时，小玲看到了一个比较简单粗犷的解决办法，就是间接将僵尸过程的父过程杀死。她立即去实际了一番，惋惜她又失败了。 在docker中，她kill产生的僵尸过程的父过程PID是1，而1这个过程在docker外部是kill不掉的；如果在docker内部的物理机找到1的对应过程进行kill，则会将整个容器杀死。 三、孤儿过程的呈现小玲并不泄气，她持续通过搜索引擎进行摸索学习，很快她就理解到更多的概念。 当过程的父过程id变为1的时候，这个过程也有了专门定义的称呼，叫做孤儿过程。 孤儿过程：父过程完结后仍在运行的子过程。没有了父过程总要有人“关照”它。 在类UNIX操作系统中，为防止孤儿过程退出时无奈开释所占用的资源而僵死，任何孤儿过程产生时都会立刻被零碎过程init或systemd主动接管为子过程，这一过程也被称为“收养”。在此需注意，尽管事实上该过程已有init作为其父过程，但因为创立该过程的过程已不存在，所以仍应称之为“孤儿过程”。依据下面的解释，又引出来一个概念，init 过程。咱们也来看下它的定义。 init过程:是 Unix 和 类Unix 零碎中用来产生其它所有过程的程序。它以守护过程的形式存在，其过程号为1。init过程是非凡的：它不取得它不想解决的信号，因而它能够疏忽SIGKILL。这里又有个新概念，SIGKILL信号。 个别咱们kill过程是发信号给过程，而后被过程捕捉之后执行对应操作。次要须要理解的信号有上面3种。都是来终止过程应用的。 四、整顿景象产生的过程小玲曾经分明这个景象跟GreatDB和MySQL都没有关系了，于是应用sleep命令持续尝试。 进入容器，执行命令。此时子过程PID是61，父过程PID是44，父过程是bash。 退出容器，再进入容器。PID是44的bash过程因为退出容器的操作被杀死，子过程61就被init收养了，父过程的PID就变成了1。 杀掉这个过程61，而后查看这个过程状态，发现它曾经成为一个僵尸过程。 到这里，小玲就曾经很靠近问题的假相了：docker容器在默认的参数配置下，其init过程并没有解决孤儿过程的能力。 对于这个问题，docker的开发者们曾经思考到了。 五、如何解决docker中的僵尸过程有两个解决办法能够让docker的init过程可能解决孤儿过程。 1.启动docker容器时，指定init过程为bash，由bash过程对孤儿过程的资源进行回收。 2.减少专门的 init 过程，比方 tini。 咱们能够去docker官网文档找到答案： The container’s main process is responsible for managing all processes that it starts.In some cases， the main process isn’t well-designed， and doesn’t handle “reaping” (stopping) child processes gracefully when the container exits.If your process falls into this category， you can use the --init option when you run the container.The --init flag inserts a tiny init-process into the container as the main process， and handles reaping of all processes when the container exits.Handling such processes this way is superior to using a full-fledged init process such as sysvinit， upstart， or systemd to handle process lifecycle within your container.依据文档倡议，能够在启动容器时候加上 --init 参数，开始应用tini。这样会有一个tiny的过程来负责过程"收养"之后的解决工作。 ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答问题形容 问题来自一位群友，简略说就是用 mysqlbinlog 工具读取 binlog 欲进行复原，却发现数据并没被复原。 先一起来看下他是怎么做复原的。 表中原来有几条数据，但不小心被清空了： [yejr]> select * from t1;+----+| c1 |+----+| 1 || 2 || 3 || 4 |+----+查看binlog event，有几条插入数据，最初还有一条 truncate table 的"误操作"，当初想要把表数据恢复到误删数据前的状态。 [yejr]> show binlog events in 'binlog.000003';+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+| binlog.000003 | 4 | Format_desc | 3306 | 125 | Server ver: 8.0.25-15, Binlog ver: 4 || binlog.000003 | 125 | Previous_gtids | 3306 | 196 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:1-5 || binlog.000003 | 196 | Gtid | 3306 | 282 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:6' || binlog.000003 | 282 | Query | 3306 | 358 | BEGIN || binlog.000003 | 358 | Rows_query | 3306 | 405 | # insert into t1 select 1 || binlog.000003 | 405 | Table_map | 3306 | 454 | table_id: 91 (yejr.t1) || binlog.000003 | 454 | Write_rows | 3306 | 494 | table_id: 91 flags: STMT_END_F || binlog.000003 | 494 | Xid | 3306 | 525 | COMMIT /* xid=75 */ || binlog.000003 | 525 | Gtid | 3306 | 611 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:7' || binlog.000003 | 611 | Query | 3306 | 687 | BEGIN || binlog.000003 | 687 | Rows_query | 3306 | 734 | # insert into t1 select 2 || binlog.000003 | 734 | Table_map | 3306 | 783 | table_id: 91 (yejr.t1) || binlog.000003 | 783 | Write_rows | 3306 | 823 | table_id: 91 flags: STMT_END_F || binlog.000003 | 823 | Xid | 3306 | 854 | COMMIT /* xid=76 */ || binlog.000003 | 854 | Gtid | 3306 | 940 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:8' || binlog.000003 | 940 | Query | 3306 | 1016 | BEGIN || binlog.000003 | 1016 | Rows_query | 3306 | 1063 | # insert into t1 select 3 || binlog.000003 | 1063 | Table_map | 3306 | 1112 | table_id: 91 (yejr.t1) || binlog.000003 | 1112 | Write_rows | 3306 | 1152 | table_id: 91 flags: STMT_END_F || binlog.000003 | 1152 | Xid | 3306 | 1183 | COMMIT /* xid=77 */ || binlog.000003 | 1183 | Gtid | 3306 | 1269 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:9' || binlog.000003 | 1269 | Query | 3306 | 1345 | BEGIN || binlog.000003 | 1345 | Rows_query | 3306 | 1392 | # insert into t1 select 4 || binlog.000003 | 1392 | Table_map | 3306 | 1441 | table_id: 91 (yejr.t1) || binlog.000003 | 1441 | Write_rows | 3306 | 1481 | table_id: 91 flags: STMT_END_F || binlog.000003 | 1481 | Xid | 3306 | 1512 | COMMIT /* xid=78 */ || binlog.000003 | 1512 | Gtid | 3306 | 1596 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:10' || binlog.000003 | 1596 | Query | 3306 | 1693 | use `yejr`; truncate table t1 /* xid=87 */ |运行上面的命令想要进行复原数据，但发现不能正确复原： ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答内容提要用delete语句应用drop、truncate删除表以及drop删除库应用rm 删除实例小结1. 应用delete语句复原形式：应用binlog，利用Flashback工具复原，Flashback的原理是批改binlog拿到原库里回放，这个计划的前提是binlog_format=row 并且binlog_row_image=full 单个事务的解决：1.insert 对应的 write_row event 改成delete_row event2.delete 对应的 delete_row event 改成write_row event3.update binlog中记录了批改前和批改后的值，对掉地位就能够了 多个事务的解决留神调整事务的程序，说完预先解决，上面说下事先预防：1.将sql_safe_updates设置为on，这样delete和update中无where子句的语句就会报错，生产如果要执行整表删除能够用truncate或者where 1=1。2.上线，必须做sql审计，至多也要在测试环境实现验证。 2. 应用drop、truncate删除表以及drop删除库复原形式：全量备份+binlog复原，这里无奈应用Flashback工具，起因是drop table、truncate table 即应用的是binlog_format=row但在binlog中记录还是statement格局 复原的技巧：因为应用mysqlbinlog无奈指定表复原，能够将全量复原出的长期库做为主库的备库，而后指定表复原，能够放慢复原速度。复原形式：应用提早复制的备库，5.6当前的性能通过change master to master_delay=N,N的单位是秒。 change master to master_delay=N缩小误操作的倡议，账号拆散:1.业务账号，默认只给select update insert权限，delete权限须要按表申请，DDL通过运维平台实现，如有主动建表的需要，能够指定分create table的权限。2.开发共事和dba只给只读权限，变更操作通过运维平台实现，如果须要更高权限，再独自申请。3.删除表的时候遵循修先改表名再删除的形式操作，表名对立命名前缀，并放到指定的长期库里，删除操作由平台主动对立实现。 3. 应用rm删除实例这个就只能靠咱们的HA了，如果零碎层面误操作，把咱们的集群主机干掉了，那就得靠咱们的跨机房HA了。 4. 小结以上是对误删除数据恢复的总结，作为dba咱们也要时刻关注业务，尽管被误删除的数据肯定是要找回来的，然而复原业务不肯定要复原全副数据。 举个例子,咱们误操作的是一张日志表只写不读那就不影响业务，给咱们复原的工夫就比拟拮据，不复原那是必定不行滴！又或者是咱们进行了drop table，交易要写这张表，简直不读，那先复原个表构造。这些要日常积攒业务知识，并迅速与开发确认，确保本人做出的决策能复原业务且不影响业务完整性。 每次误操作都是血的教训，在没有想分明sql执行的后果之前，先不要敲下回车键哦！数据是公司的生命线，咱们做为数据库管理员，要守好公司的生命线。 最初，作为dba技术原理要精通，库对应的业务也要理解哦，这样遇到问题的时候咱们能力找到更全面更正当的解决方案。 Enjoy MySQL :) 文章举荐：GreatSQL MGR FAQhttps://mp.weixin.qq.com/s/J6... 万答#12，MGR整个集群挂掉后，如何能力主动选主，不必手动干涉https://mp.weixin.qq.com/s/07... 『2021数据技术嘉年华·ON LINE』：《MySQL高可用架构演进及实际》https://mp.weixin.qq.com/s/u7... 一条sql语句慢在哪之抓包剖析https://mp.weixin.qq.com/s/AY... 万答#15，都有哪些状况可能导致MGR服务无奈启动https://mp.weixin.qq.com/s/in... 技术分享 | 为什么MGR一致性模式不举荐AFTERhttps://mp.weixin.qq.com/s/rN... 对于 GreatSQLGreatSQL是由万里数据库保护的MySQL分支，专一于晋升MGR可靠性及性能，反对InnoDB并行查问个性，是实用于金融级利用的MySQL分支版本。 Gitee: https://gitee.com/GreatSQL/Gr... GitHub: https://github.com/GreatSQL/G... Bilibili：https://space.bilibili.com/13... 微信&QQ群：可搜寻增加GreatSQL社区助手微信好友，发送验证信息“加群”退出GreatSQL/MGR交换微信群 QQ群：533341697微信小助手：wanlidbc 本文由博客一文多发平台 OpenWrite 公布！

I、count实现形式（无where条件时）MyISAM引擎：把一个表的总行数存在了磁盘上，执行 count时间接返回，效率很高；InnoDB引擎：把数据一行一行地从引擎外面读出来，而后累积计数。 1、有where条件时，MyISAM和InnoDB实现形式一样2、因为MVCC（多版本并发管制），InnoDB引擎即便是在同一个时刻的多个查问，“应该返回多少行”也是不确定的。3、InnoDB默认隔离级别可反复读，代码上通过MVCC实现。每一行记录都要判断本人是否对这个会话可见。4、InnoDB是索引组织表，主键索引树的叶子节点是数据，而一般索引树的叶子节点是主键值。所以，一般索引树比主键索引树小很多。对于count操作，遍历哪个索引树失去的后果逻辑上都是一样的。因而，MySQL 优化器会找到最小的那棵树来遍历。在保障逻辑正确的前提下，尽量减少扫描的数据量，是数据库系统设计的通用法令之一。II、count毛病MyISAM尽管count很快，然而不反对事务；show table status命令尽管返回很快，然而不精确；InnoDB间接count会遍历全表，尽管后果精确，但会导致性能问题。 因而须要本人实现。III、用缓存零碎保留计数-应用Redis服务保留表的总行数1、将计数保留在缓存零碎中的形式，还不只是失落更新的问题。即便 Redis 失常工作，这个值还是逻辑上不准确的。 这里次要起因是“MySQL插入一行数据”跟“Redis计数加1”这两个操作是离开的，不是原子性的，这就很可能在两头过程因为某些并发呈现问题。 更形象一点：MySQL和Redis是两个不同的载体，将关联数据记录到不同的载体，而不同载体要实现原子性很难，因为不是原子性很容易引起并发问题。如果能将数据对立在同个载体即MySQL，并由其保障操作的原子性，行将插入一行数据和计数加1作为一个残缺的事务，通过事务的隔离此时外界看到的就是要么全副执行结束要么全副都没执行，进而放弃逻辑统一。2、在并发零碎外面，咱们是无奈准确管制不同线程的执行时刻的。 IV、在数据库保留计数-计数间接存储到数据库里独自的一张计数表1、在数据库中建表计数，能够失去精准的计数，办法是通过数据库中的事务来实现的。计数器的批改和数据的写表在一个事务中。读取计数器和查问最近数据也在一个事务中。2、解决办法：将计数的记录 + 1和插入一条数据放入到同一个事务中。 V、count1、count() 是一个聚合函数，对于返回的后果集，一行行地判断，如果 count 函数的参数不是 NULL，累计值就加 1，否则不加。最初返回累计值。2、对于count(主键id)来说，InnoDB引擎会遍历整张表，把每一行的id值都取出来，返回给server层。server层拿到id后，判断是不可能为空的，就按行累加。3、对于count(1)来说，InnoDB引擎遍历整张表，但不取值。server层对于返回的每一行，放一个数字“1”进去，判断是不可能为空的，按行累加。4、对于count(字段) 来说：——如果这个“字段”是定义为not null的话，一行行地从记录外面读出这个字段，判断不能为 null，按行累加；——如果这个“字段”定义容许为null，那么执行的时候，判断到有可能是null，还要把值取出来再判断一下，不是null才累加。5、count(）并不会把全副字段取出来，而是专门做了优化，不取值。count()必定不是 null，按行累加。 依照效率排序的话，依照效率排序的话，count(字段)<count(主键 id)<count(1)≈count(*)。所以尽量应用 count(*)。VI、剖析性能差异准则：1、server层要什么就给什么；2、InnoDB只给必要的值；3、当初的优化器只优化了count(*) 的语义为“取行数”，其余“不言而喻”的优化并没有做。 VII、温习-InnoDB特点事务反对: redolog持久性，undolog原子性，mvcc+锁隔离级别。并发：行锁而不是简略的表级锁。数据安全：数据要长久化到磁盘

MySQL 事务小伙伴们都懂，通过 begin 开启事务，通过 commit 提交事务或者通过 rollback 回滚事务。 在后面的文章中，松哥也和大家聊了一些事物原理以及相干的细节，小伙伴们能够回顾一下： MVCC 水略深，然而弄懂了真的好爽！一致性视图是啥时候建设的？四个案例看懂 MySQL 事务隔离级别失常来说，当咱们开启一个事务之后，须要 commit 或者 rollback 来完结一个事务的，然而有时候，一些操作会主动帮咱们提交事务，如果大家不理解隐式事务的话，那么在具体应用事务的事务可能就会遭逢一些莫名其妙的问题。 1. DDL 操作首先一点就是 DDL 操作会隐式提交事务，这个松哥在之前的文章中其实有说过，咱们再来一起回顾下： 所有的 DDL 语句都会导致事务隐式提交，换句话说，当你在执行 DDL 语句前，事务就曾经提交了。这就意味着带有 DDL 语句的事务未来没有方法 rollback。我举一个简略的例子，大家一起来看下： 咱们来一起看下我这里的测试逻辑： 首先查问总记录数有四条。开启一个事务。执行一条删除语句。alter 表，新增一个字段。回滚。再次查问数据。到第六步的时候，咱们发现查问到的数据只剩三条了，阐明第五步的回滚并没有失效。起因就在于执行 alter 之前，事务曾经被隐式提交了。 所以小伙伴们在日常开发中，最好不要在事务中混有 DDL 语句，DDL 语句和 DML 语句离开写。 对于下面的案例，如果大家去掉第四步的 alter，那么回滚是能够回滚胜利的，这个小伙伴们本人来测试，我就不演示了。 当然 DDL 操作可不仅仅是 alter，其余的如 CREATE、DROP 等操作也会导致事务隐式提交，这里松哥就不一一举例了，小伙伴们能够自行尝试。 2. DCL 操作DDL 和 DML 大家应该常常接触到，然而 DCL 可能有小伙伴不分明，DCL 其实就是 Data Control Language，中文译作数据管制语言，咱们日常受权或者回收数据库上的权限所应用的 GRANT、REVOKE 等，就算是 DCL 操作。 我举个简略例子： 能够看到，跟第一大节的测试步骤一样，只不过第四步换成一个 GRANT 语句，那么最终的事务回滚也会生效，起因就在于事务曾经提交了。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。近期打算制作一个GreatSQL的docker镜像，不便社区用户应用GreatSQL。 制作docker镜像的环境基于CentOS 7.9： [root@greatsql]# cat /etc/redhat-releaseCentOS Linux release 7.9.2009 (Core)[root@greatsql]# uname -aLinux GreatSQL 3.10.0-1160.11.1.el7.x86_64 #1 SMP Fri Dec 18 16:34:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux1、筹备工作要制作docker镜像，须要先装置docker，并启动服务。 [root@greatsql]# yum install -y docker[root@greatsql]# systemctl start docker筹备好一个CentOS根底镜像，选用CentOS 7这个根底镜像。 [root@greatsql]# docker pull centos:7[root@greatsql]# docker imagesREPOSITORY TAG IMAGE ID CREATED SIZEdocker.io/centos 7 8652b9f0cb4c 7 months ago 204 MB这个镜像的仓库是 docker.io/centos，标签是 7（示意是CentOS 7版本），标签ID是 8652b9f0cb4c，最初更新工夫是7个月前，镜像大小是204MB。 这里如果抉择CentOS 8的镜像也是能够的，不过一些系统命令略有区别，具体选哪个纯正看集体爱好。 2、开始制作docker镜像先创立工作目录 /data/docker-greatsql： [root@greatsql]# mkdir -p /data/docker-greatsql && cd /data/docker-greatsql2.1 筹备安装包及配套运行GreatSQL须要用到jemalloc，默认的yum源里通常没有，所以先自行下载到本地： ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。江湖传言MySQL最多只能用到128个逻辑CPU，是真的吗？共事从客户现场回来，冤屈巴巴的说，某PG服务商通知客户“MySQL最高只能反对128个逻辑CPU，更多就用不上了，还是用PG吧”。 作为从MySQL 3.23时代就开始一路陪跑过来的我，必定不能忍啊。。。 在晚期以MyISAM引擎为主的年代，确实有相似的限度。MyISAM存在泛滥限度，这个也是家喻户晓的，不赘述了。 但自从InnoDB成为MySQL默认引擎后，这个状况应该是不复存在了。尤其是自从MySQL引入innodb_autoinc_lock_mode、innodb_io_capacity、innodb_read_io_threads、innodb_write_io_threads等多个可控参数选项后，对于高并发的业务场景，基本上都能把所有逻辑CPU跑满。 口说无凭，间接测试验证下吧。 测试环境： #查看CPU，共有176个逻辑CPU$ lscpuArchitecture: x86_64CPU op-mode(s): 32-bit, 64-bitByte Order: Little EndianCPU(s): 176On-line CPU(s) list: 0-175Thread(s) per core: 2Core(s) per socket: 22Socket(s): 4...#OS环境$ cat /etc/redhat-releaseCentOS Linux release 7.8.2003 (Core)$ uname -aLinux3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux下载MySQL 5.5.62版本的二进制包，批改上面几个参数选项： innodb_io_capacity = 20000innodb_autoinc_lock_mode = 2innodb_read_io_threads = 16innodb_write_io_threads = 16innodb_thread_concurrency = 0实例启动后，在另外的客户机上运行sysbench进行压测（sysbench不要和MySQL服务器跑在同一个服务器上）： #128个测试表，每个表10万行记录，并发256个线程$ sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=172.16.10.10 --mysql-port=3306 --mysql-user=xx --mysql-password=xx --mysql-db=sbtest --db-driver=mysql --tables=128 --table_size=100000 --threads=256 --report-interval=1 --db-ps-mode=disable --time=0 run而后运行htop察看所有CPU的状态，肉眼即可见所有逻辑CPU上都有负载： ...

导语：MySQL是存储网站数据的中央，如果不进行优化的话，会导致申请很慢，响应很慢，影响数据渲染，给产品带来不好的体验，我就本人之前的我的项目教训，说一下如何进行MySQL数据表方面的优化工作。目录硬件配置服务器参数数据库设计sql语句优化上面就这四个方面进行论述，剖析总结我在接口我的项目中进行的优化总结经验办法。 硬件配置个别我的项目如果你的我的项目比拟小，估算比拟节俭，能够应用1C1G1M配置的服务器，装置mysql5.6即可；如果我的项目比拟大，估算短缺，能够配置2C4G5M等服务器，装置mysql8即可。我目前应用的是MySQL8版本。 大型项目如果数据量压力特地大，能够思考购买多台服务器，进行读写拆散，主从同步，主服务器用来写入，而后同步数据到辅服务器，辅服务器用来读取数据，这样压力会变得小一些，然而给开发工作带来的微小的累赘。 能够思考应用官网的mysql-proxy来作为一个代理中间件，具体实现办法能够参考这篇文章1 服务器参数次要是装置mysql程序后，如果进行配置项优化，以便达到最大性能，施展出MySQL的劣势价值。 在配置文件my.ini或者my.cnf中写入以下参数： #my.inimax_connections=200max_connect_errors=10default-storage-engine=INNODB#mysql_native_passworddefault_authentication_plugin=mysql_native_passwordngram_token_size=2default-time_zone='+8:00'包含最大连接数，最大连贯谬误，明码兼容性，时区设置东八区等。 我感觉这些就基本上能够了，如果你还想进一步优化，能够参考以下文章2 数据库设计设计规范范式设计当咱们进行关系型数据库设计时，要遵循不同的标准，设计出正当的关系型数据库，那么这些不同的标准就会产生不同的范式，越高的范式冗余越小。 目前关系型数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式（4NF）和第五范式（5NF，又称完满范式）。 第三范式一般来说，数据库只须要满足第三范式就行了，当然了，这个范式也是人定的，必然有优缺点，你能够依据你本人的理论状况来定义你所采纳的标准。 第三范式次要是表中的字段和主键间接对应不依附其余两头字段，说白了就是，决定某字段值的必须是主键；毛病在于查问时通常须要join很多表，导致查问效率很低。能够适当的进行反范式，进行适当的冗余，以便进步查问效率。 最佳实际抉择适合的引擎MySQL为咱们提供的很多的引擎，比方myisam，innodb，memory等，你能够针对不同的存储需要抉择最合适你的存储引擎。具体的能够参考这两篇文章：3 我这个项目选择的是innodb，看中它的主动增长列以及外键束缚个性、提交、回滚和解体恢复能力等事务平安。 建设适当的索引建设一个索引即可，不加内存，不改程序，不调sql 抉择适当的字段类型比方id能够采纳int类型，类型等字段能够采纳tinyint；文本内容依据大小优先级能够是char>varchar>text；日期依据存储字节能够是timestamp>datetime>date，文件资源只须要存储在服务器的门路即可。通过以上一系列的字段类型优化，能够无效升高存储大小，字节节俭，加重读写压力，提供数据库性能。 适当机会进行写入先写入和后写入都会对数据库产生影响。 尽量批量操作读写如果单个频繁的读写，会对服务器产生很大压力，能够采纳批量脚本，批量录入数据。 对数据表进行程度和垂直划分一个表记录的货色太多，会影响读写效率，能够思考化整为零，进行逻辑划分，一个表拆成多张表。 sql语句优化最初一个要优化的中央就是sql语句，一条好的sql语句能够帮忙咱们实现便捷的curd操作，进步读写效率。 慢日志如果某一天发现零碎查问变慢了，又找不到起因。能够应用这个进行问题定位，然而因为慢查问日志记录信息较多，会影响mysql的性能，所以生产环境不倡议长期开启。 在配置文件my.ini或者my.cnf中写入以下参数。 # slow logslow_query_log=1 # 1开启 0敞开slow_query_log_file=/usr/local/mysql/data/slow-query.log # 慢查问日志存储文件long_query_time = 2 # 慢查问日志的工夫定义（秒），默认为10秒，多久就算慢查问的日志log_queries_not_using_indexes=1语句优化技巧防止全表字段查问，能够查问某一个，依据条件。 这里有能够参考下。4 对了，我最近写了一个mysql语句生成npm包，有趣味的能够去理解下，包地址xqsql 参考文章： <div id="mysql-proxy"></div> [1]《mysql数据库的主从同步，实现读写拆散》<div id="mysql-params"></div> [2]《mysql数据库参数详解》<div id="mysql-practice"></div> [3]《MySQL存储引擎概述&MyISAM&InnoDB&MEMORY》<div id="mysql-statement"></div> [4]《30条语句优化技巧》好了，以上就是我做我的项目过程中，发现的，总结的一些对于mysql优化方面的内容，如果有什么问题，能够底部发我邮箱分割。

MySQL语法入门（一）根本运算符应用SELECT 1 + 2;-- 3SELECT 1 / 0;-- nullSELECT 1 + NULL;-- nullSELECT '2' * '4';-- 8SELECT '2f' + 3;-- 5SELECT 2.2 + 2;-- 4.2SELECT 1 = 2;-- 0SELECT 1 = 1;-- 1SELECT 1 = NULL;-- nullSELECT 1 <=> NULL;-- 0SELECT 'hello' = 'HELLO';-- 1SELECT 'hello' = ' HELLO ';-- 0SELECT BINARY 'hello' = 'HELLO';-- 0SELECT 'a' > 'b';-- 0SELECT 'b' > 'a';-- 1SELECT 'b' BETWEEN 'a' AND 'c';-- 1SELECT 'a' BETWEEN 'a' AND 'c';-- 1SELECT 'c' BETWEEN 'a' AND 'c';-- 1 >= <=SELECT NOT 'b' BETWEEN 'a' AND 'c';-- 0SELECT NOT 'a' BETWEEN 'a' AND 'c';-- 0SELECT NOT 'c' BETWEEN 'a' AND 'c';-- 0 >= <=SELECT 3 IN (3 , 4, 5);-- 1SELECT 1 IN (3 , 4, 5);-- 0SELECT NULL IN (3 , 4, 5);-- nullSELECT NULL IN (3 , 4, 5, NULL);-- nullSELECT 'hello' LIKE 'he%';-- 1SELECT 'hel%' LIKE 'hello';-- 0SELECT 1 BETWEEN 1 AND 2;SELECT NOT 1;-- 0SELECT ! 1;-- 0SELECT (1 > 2) AND (19 > 10);-- 0SELECT (11 > 2) && (19 > 10);-- 1SELECT (1 > 2) OR (19 > 10);-- 1SELECT (21 > 2) || (19 > 10);-- 1SELECT (1 > 2) XOR (19 > 10);-- 1SELECT (21 > 2) XOR (19 > 10);-- 0SELECT 1 | 2;-- 3;001 | 010 -> 011SELECT 3 >> 1;-- 1; 11 >> 1 -> 1SELECT 3 << 1;-- 6; 11 << 1 -> 110SELECT 3 ^ 2;-- 1; 11 ^ 10 -> 01根本数学函数应用SELECT ABS(- 5);-- 5SELECT ABS(- 5.8);-- 5.8SELECT CEIL(1.2);-- 2SELECT CEILING(1.2);-- 2SELECT CEIL(1.6);-- 2SELECT CEILING(1.6);-- 2SELECT CEIL(- 1.2);-- -1SELECT CEILING(- 1.2);-- -1SELECT CEIL(- 1.6);-- -1SELECT CEILING(- 1.6);-- -1SELECT FLOOR(1.2);-- 1SELECT FLOOR(- 1.2);-- -2SELECT GREATEST(1, 4, 6);-- 6SELECT LEAST(1, 3, 2);-- 1SELECT MOD(10, 6);-- 4SELECT PI();-- 3.141593SELECT RAND();-- 0.9857855839522421SELECT ROUND(22.3563, 2);-- 22.36SELECT TRUNCATE(12.4562, 2);-- 12.45SELECT SIGN(1);-- 1 负数SELECT SIGN(0);-- 0 0SELECT SIGN(- 1.3);-- -1 正数SELECT POWER(2, 4);-- 16 SELECT POW(2, 4);-- 16SELECT EXP(1);-- 2.718281828459045SELECT EXP(2);-- '7.38905609893065'SELECT SQRT(4);-- 2SELECT SQRT(5);-- 2.23606797749979SELECT BIN(10);-- 1010SELECT OCT(10);-- 12SELECT HEX(10);-- ASELECT OCT(10);-- 12SELECT OCT(10);-- 12根本字符串函数应用SELECT LENGTH('hello');-- 5SELECT LCASE('helLO');-- helloSELECT LOWER('helLO');-- helloSELECT UCASE('hello');-- HELLOSELECT UPPER('hello');-- HELLOSELECT STRCMP('hello', 'yes');-- -1SELECT STRCMP('zworld', 'yes');-- 1SELECT POSITION('yes' IN 'yesman');-- 1SELECT REPLACE('hello', 'l', 'a');-- heaaoSELECT INSERT('hello world', 2, 3, 'bb');-- hbbo worldSELECT INSERT('hello world', 2, 1, 'bb');-- hbbllo worldSELECT CONCAT('hello', 'world');-- helloworldSELECT CONCAT_WS('@', 'hello', 'world');-- hello@worldSELECT LEFT('hello', 2);-- heSELECT RIGHT('hello', 2);-- loSELECT LPAD('hello', 7, 'a');-- aahello 右边填充指定字符 长度 7 需大于原字符串长度SELECT RPAD('hello', 7, 'b');-- hellobb 左边填充指定字符 长度 7 需大于原字符串长度SELECT LTRIM(' hello');-- helloSELECT RTRIM('hello ');-- helloSELECT TRIM(' hello ');-- helloSELECT SUBSTRING('hello', 2, 3);-- ellSELECT ASCII('0');-- 48SELECT ASCII('A');-- 65SELECT ASCII('a');-- 97根本日期工夫函数应用SELECT NOW();-- 2022-01-06 22:31:15SELECT CURTIME();-- 25:31:49SELECT CURDATE();-- 2022-01-06SELECT YEAR(20220106);-- 2022SELECT YEAR('20220106');-- 2022SELECT YEAR('2022-01-06');-- 2022SELECT YEAR('2022/01/06');-- 2022SELECT MONTH('2022/01/06');-- 1SELECT MONTHNAME('2022/01/06');-- JanuarySELECT DAYOFYEAR('2022/01/06');-- 6SELECT DAYOFWEEK('2022/01/06');-- 5SELECT DAYNAME('2022/01/06');-- ThursdaySELECT WEEK('2022/01/06');-- 1SELECT HOUR('25:31:49');-- 25SELECT MINUTE('25:31:49');-- 31SELECT SECOND('25:31:49');-- 49SELECT DATE_ADD(NOW(), INTERVAL 2 MONTH);-- 2022-03-06 22:40:55SELECT DATE_ADD(NOW(), INTERVAL 3 DAY);-- 2022-01-09 22:41:30SELECT DATE_SUB(NOW(), INTERVAL 3 YEAR);-- 2019-01-06 22:42:11

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 通过上一章节的介绍，咱们曾经理解ProxySQL 如何基于 MySQL 主从以及组复制架构来构建读写拆散、故障转移等性能点，但没有涵盖ProxySQL 相干配置表的工作细节。那本章就对上节脱漏的内容进行一个延长解说。 先来理解下 ProxySQL 的内置数据库列表：ytt:admin> show databases;+-----+---------------+-------------------------------------+| seq | name | file |+-----+---------------+-------------------------------------+| 0 | main | || 2 | disk | /var/lib/proxysql/proxysql.db || 3 | stats | || 4 | monitor | || 5 | stats_history | /var/lib/proxysql/proxysql_stats.db |+-----+---------------+-------------------------------------+5 rows in set (0.00 sec)以上所列数据库中，main 代表 runtime ，也即运行时库；disk 代表长久化库；stats 代表统计数据库；monitor 代表监控数据库；stats_history 代表统计数据库归档。 对于贮存 MySQL 主从、组复制、读写拆散的几张配置表，在每个库里都存在，不同的库代表不同的运行领域。 ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。1、测试环境2、测试数据GreatSQL马上正式开源了，这次又新增了两个重磅个性：InnoDB事务锁优化 以及 InnoDB引擎的并行查问优化，这两个个性是由华为鲲鹏计算团队奉献的Patch合并而来。 InnoDB并行查问优化怎么实现的？ 依据B+树的特点，能够将B+树划分为若干子树，此时多个线程能够并行扫描同一张InnoDB表的不同局部。对执行打算进行多线程革新，每个子线程执行打算与MySQL原始执行打算统一，但每个子线程只需扫描表的局部数据，子线程扫描实现后再进行后果汇总。通过多线程革新，能够充分利用多核资源，晋升查问性能。 优化后，在TPC-H测试中体现优异，最高可晋升30倍，均匀晋升15倍。 该个性实用于周期性数据汇总报表之类的SAP、财务统计等业务，例如月初、月底跑批业务等。 应用限度： 暂不反对子查问，可想方法革新成JOIN。临时只反对ARM架构平台，X86架构平台优化也会尽快实现。对于该Patch详情见：https://support.huaweicloud.c... 本文针对 InnoDB引擎的并行查问优化 个性进行比照测试。 1、测试环境服务器：神州鲲泰R222，华为Hi1616 * 2（主频 2400 MHz 共64个逻辑CPU），256G内存。 操作系统：Docker 20.10.2，Docker容器下的CentOS Linux release 7.9.2009，Linux 4.15.0-29-generic。 本次测试采纳TPC-H，dbgen结构测试数据参数 dbgen -vf -s 50，导入后数据库物理大小约70G。GreatSQL要害配置： #运行Q10测试时，须要较大长期表temptable_max_ram = 6G#使得本测试基于纯内存场景innodb_buffer_pool_size=96G#InnoDB并行查问优化#global级别，设置并行查问的开关，bool值，on/off。默认off，敞开并行查问个性。可在线动静批改。force_parallel_execute = ON#global级别，设置零碎中总的并行查问线程数。有效值的范畴是（0, ULONG_MAX），默认值是64。parallel_max_threads = 64#global级别，并行执行时leader线程和worker线程应用的总内存大小下限。有效值的范畴是（0, ULONG_MAX），默认值是1Gparallel_memory_limit = 32G2、测试数据测试过程中，留神要确保每次查问都是基于纯内存的场景，也就是确保innodb_buffer_pool_size大于数据库物理大小，并确认查问过程中没有额定的物理I/O产生。 个别SQL例如Q10在运行过程中会产生长期表（Using temporary），这时候须要加大 temptable_max_ram 选项值。该选项默认值1G，在上述测试数据量前提下，大略须要加大到4G能力hold住。如果该选项值不够的话，可能运行过程中会提醒诸如 The table '/tmp/#sql57_a1_0' is full 这样的谬误提醒，而后退出查问，这是MySQL的BUG#99100。 InnoDB并行查问个性通过HINT语法能够很不便地应用，首先确认启用了该个性（可在线动静关上）： $ mysqladmin var|grep force_parallel_execute| force_parallel_execute | ON那么默认所有的SQL只有符合条件，即可主动采纳并行查问，通过查看执行打算确认： mysql> EXPLAIN SELECT ... FROM ... WHERE ......Parallel execute (4 workers)...能够看到执行打算输入中蕴含 Parallel execute (4 workers) 关键字，这就示意最高可并行4个线程查问。 ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答SQL语句大家并不生疏，但某种程度上来看，咱们只是晓得了这条语句是什么性能，它能够给咱们失去什么样的后果，但咱们如果把这条语句写错或是数据库表设计上有什么缺点，会引发什么谬误咱们却无从得悉，所以明天想分享一下在MySQL体系下SQL语句大抵上是如何在零碎中执行的，在当前SQL语句提醒谬误时将更好定位问题。 1、问题导入咱们以一条SELECT语句为例，咱们晓得SELECT语句是属于咱们的DML下的DQL语言，它能够通过咱们指定的字段列表和表列表并进行条件的形容来查问某张数据表中咱们所须要的某些数据。假如： mysql> select * from test_table where sname = '王五';+-----+-------+---------+| sno | sname | major |+-----+-------+---------+| 1 | 王五 | English |+-----+-------+---------+1 row in set (0.00 sec)如果咱们将字段SELECT漏写成ELECT，将会： mysql> elect * from test_table where sname = '王五';ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'elect * from test_table where sname = '王五'' at line 1咱们通过观察use near前方提醒的内容：''elect * from test_table where sname = '王五'' at line 1，可得悉咱们的SELECT语句写错了。 ...

本来的SQL和查出的后果如下： SELECT biz_day, record.amount FROM ods_sale_pay_record record WHERE project.delete_flag = 'N' AND ( record.biz_day >= '2021-10-01' AND record.biz_day <= '2021-10-31' OR record.biz_day >= '2022-01-01' AND record.biz_day <= '2022-01-31' )后果：现要求依照月份为维度汇总数据，能够应用DATE_FORMAT函数批改后的SQL如下： SELECT DATE_FORMAT(biz_day,'%Y%m') months, SUM( record.amount ) 'amount' FROM ods_sale_pay_record record WHERE record.status_code = 'PAY_RECORD_PAID' AND ( record.biz_day >= '2021-10-01' AND record.biz_day <= '2021-10-31' OR record.biz_day >= '2022-01-01' AND record.biz_day <= '2022-01-31' ) GROUP BY record.biz_day 后果如下： 拓展：如果想要依照天、周、月等不同的粒度对数据进行分组统计也能够参考如下的语法： 1）按天统计：select DATE_FORMAT(biz_day,'%Y%m%d') days,SUM( record.amount ) 'amount' from test group by biz_day; 2）按周统计：select DATE_FORMAT(biz_day,'%Y%u') weeks,SUM( record.amount ) 'amount' from test group by biz_day; 3）按月统计:select DATE_FORMAT(biz_day,'%Y%m') months,SUM( record.amount ) 'amount' from test group by biz_day;

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。本次介绍如何利用Docker来将GreatSQL源码编译成二进制文件，以及制作二进制包、RPM包等。 本文介绍的运行环境是CentOS 7.9： [root@greatsql ~]# cat /etc/redhat-releaseCentOS Linux release 7.9.2009 (Core)[root@greatsql ~]# uname -aLinux greatsql 3.10.0-1160.11.1.el7.x86_64 #1 SMP Fri Dec 18 16:34:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux1、筹备工作1.1、配置yum源开始编译之前，倡议先配置好yum源，不便装置一些工具。 以阿里、腾讯两大云主机为例，能够这样配置（两个yum源自行二选一）： [root@greatsql ~]# mv /etc/yum.repos.d/CentOS-Base.repo{,.orig}#阿里云[root@greatsql ~]# wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo#腾讯云[root@greatsql ~]# wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.cloud.tencent.com/repo/centos7_base.repo#替换完后，更新缓存[root@greatsql ~]# yum clean all[root@greatsql ~]# yum makecache1.2、装置docker[root@greatsql]# yum install -y docker[root@greatsql]# systemctl start docker1.3、提前下载几个必要的安装包别离下载几个编译过程中须要的依赖包： boost, https://boostorg.jfrog.io/artifactory/main/release/1.73.0/source/boost_1_73_0.tar.gzgit, https://github.com/git/git/archive/v2.27.0.tar.gz, 下载后重命名为 git-v2.27.0.tar.gzpatchelf, https://github.com/NixOS/patchelf/archive/refs/tags/0.12.tar.gz, 下载后重命名为 patchelf-0.12.tar.gzrpcsvc-proto, https://github.com/thkukuk/rpcsvc-proto/releases/download/v1.4/rpcsvc-proto-1.4.tar.gz下载GreatSQL源码包：https://gitee.com/GreatSQL/GreatSQL/archive/greatsql-8.0.25-15.tar.gz1.4、构建docker镜像用上面这份Dockerfile构建镜像，这里以CentOS 7为例： FROM centos:7ENV LANG en_US.utf8RUN yum install -y epel-release && \curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.cloud.tencent.com/repo/centos7_base.repo && \yum clean all && \yum makecacheRUN yum install -y yum-utils && \yum install -y wget diffutils net-tools vim git gcc gcc-c++ automake libtool cmake cmake3 \make psmisc openssl-devel zlib-devel readline-devel bzip2-devel expat-devel gflags-devel \bison bison-devel flex wget unzip libcurl-devel libevent-devel libffi-devel lz4-devel lz4-static \file clang bzip2 snappy-devel libxml2-devel libtirpc libtirpc-devel numactl-devel numactl-libs \numactl gtest-devel openldap-devel openldap-clients rpcgen pam-devel valgrind boost-devel rpm* tar \centos-release-scl libzstd libzstd-static libzstd-devel perl-Env perl-JSON time libaio-devel \ncurses-devel ncurses-libs pam python-devel redhat-lsb-core scl-utils-build pkg-config ccacheRUN yum install -y devtoolset-10-gcc*RUN echo 'scl enable devtoolset-10 bash' >> /root/.bash_profile# update gitCOPY git-v2.27.0.tar.gz /tmp/RUN cd /tmp/ && tar -xzvf git-v2.27.0.tar.gz && cd git-2.27.0 && make prefix=/opt/git/ all && make prefix=/opt/git/ installRUN mv /usr/bin/git /usr/bin/git.bk && ln -s /opt/git/bin/git /usr/bin/git# update patchelf 0.12COPY patchelf-0.12.tar.gz /tmp/RUN cd /tmp && tar -xzvf patchelf-0.12.tar.gz && cd patchelf && ./bootstrap.sh && ./configure && make && make installCOPY rpcsvc-proto-1.4.tar.gz /tmp/rpcsvc-proto-1.4.tar.gzRUN tar zxvf /tmp/rpcsvc-proto-1.4.tar.gz -C /tmp && cd /tmp/rpcsvc-proto-1.4/ && ./configure && make && make installRUN rm -fr /tmp/*COPY boost_1_73_0.tar.gz /opt/RUN ln -fs /usr/bin/cmake3 /usr/bin/cmake开始构建docker镜像，胜利后再保留到本地并导入本地镜像： ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。1、引子2、AFTER 的写一致性3、AFTER 的读一致性4、AFTER 执行流程5、BEFORE 执行流程6、一些思考7、参考文档1、引子某次测试过程中，发现在 AFTER 级别下，节点故障会导致集群无奈进行事务提交，同时，当事务进入提交阶段后，其它节点无奈开启只读事务。整个集群无奈失常提供服务，直到故障节点被踢出集群。 以下首先复现上述故障场景的步骤： 1、初始化一个3节点的集群。集群信息如下： mysql> select * from performance_schema.replication_group_members; +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+ | group_replication_applier | c223cde5-0719-11ec-8295-ec5c6826bca3 | 127.0.0.1 | 13000 | ONLINE | PRIMARY | 8.0.25 | | group_replication_applier | c22847e0-0719-11ec-b30b-ec5c6826bca3 | 127.0.0.1 | 13004 | ONLINE | PRIMARY | 8.0.25 | | group_replication_applier | c22c3752-0719-11ec-98ef-ec5c6826bca3 | 127.0.0.1 | 13002 | ONLINE | PRIMARY | 8.0.25 | +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+ 3 rows in set (0.00 sec) mysql> select @@group_replication_member_expel_timeout; +------------------------------------------+ | @@group_replication_member_expel_timeout | +------------------------------------------+ | 1000 | +------------------------------------------+ 1 row in set (0.00 sec)2、在 AFTER 级别下创立表并插入一条数据 ...

复原步骤概要 备份frm、ibd文件如果mysql版本发生变化，装置回本来的mysql版本创立和本来库名统一新库，字符集都要放弃一样通过frm获取到原先的表构造，通过的失去的表构造创立一个和原先构造一样的空表。应用“ALTER TABLE DISCARD TABLESPACE;”命令卸载掉表空间将原先的ibd拷贝到mysql的仓库下增加用户权限 “chown . .ibd”,如果是操作和mysql的应用权限统一能够跳过通过“ALTER TABLE IMPORT TABLESPACE;”命令复原表空间实现实际操作 1）备份文件 mkdir /usr/local/backupcp * /usr/local/backup2）装置本来版本的数据库 略 3）创立和本来统一的库 创立和本来库名统一新库，字符集都要放弃一样 4）frm获取到原先的表构造 这里应用dbsake读取frm的表构造 （1）dbsake装置 #下载curl -s get.dbsake.net > dbsake#增加执行权限chmod u+x dbsake（2）应用dbsake读取表构造 #根底应用./dbsake frmdump [frm-file-path]#将所有读取后果输出到文件中./dbsake frmdump [frm-file-path] > <文件名>例如：./dbsake frmdump student.frm teacher.frm > school.txt（3）复原表构造 文件中寄存的是frm对应表构造的sql，间接复制进去运行就行了，此时数据库中所有的构造都复原了，就是还没有数据 5）卸载表空间 在mysql中执行命令，卸载掉表空间 ALTER TABLE <tabelName> DISCARD TABLESPACE;例如：ALTER TABLE student DISCARD TABLESPACE;ALTER TABLE teacher DISCARD TABLESPACE;6）拷贝本来的ibd，到新的库中 （1）确定新数据库的数据寄存地位 在mysql中执行命令 show variables like 'datadir';进入对应文件夹中，会有一个和须要复原的数据库名齐全一样的文件夹，进入文件夹 （2）将ibd文件复制过去 cp命令间接复制过去就行了 7）命令复原表空间 在mysql执行命令，复原表空间 ALTER TABLE <tabelName> IMPORT TABLESPACE;例如：ALTER TABLE student IMPORT TABLESPACE;ALTER TABLE teacher IMPORT TABLESPACE;8）实现 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。1、试验环境2、软件下载3、开始测试4、附参数阐明生产上产生误删数据或者误更新数据的事变时，传统复原办法是利用备份重搭实例，再利用binlog来复原数据，有时候须要找回的数据条数非常少，却要复原几十甚至上百G的备份，费时费力。 那有没有像oracle一样的能够闪回的形式来不便的复原数据呢，答案是有的。咱们MySQL有binlog，binlog以event的模式，记录了MySQL server从启用binlog以来所有的变动。 对于binlog就不做过多的赘述，咱们能够利用binlog记录的信息，在不做备份复原的状况下来迅速找回误操作的数据。 MySQL不像oracle间接一个命令就搞定了，MySQL须要借助工具来实现，明天咱们来测试下git上2500星的闪回小工具，测试过程如下: 1、试验环境操作系统：centos 7 数据库版本：MySQL 5.7.34 软件：binlog2sql 2、软件下载https://github.com/danfengcao/binlog2sql解压装置： unzip binlog2sql-master.zip cd binlog2sql-masterpip install -r requirements.txtMySQL server必须设置以下参数: server_id = 1log_bin = /var/log/mysql/mysql-bin.logmax_binlog_size = 1Gbinlog_format = rowbinlog_row_image = fulluser须要的最小权限汇合： selectsuper/replication clientreplication slave倡议受权： GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 3、开始测试权限阐明： select：须要读取server端information_schema.COLUMNS表，获取表构造的元信息，拼接成可视化的sql语句super/replication client：两个权限都能够，须要执行'SHOW MASTER STATUS', 获取server端的binlog列表replication slave：通过BINLOG_DUMP协定获取binlog内容的权限创立用户，造试验数据: 应用sysbench生成测试表，此步骤略 受权用户： GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO test_flash@'%' identified by 'test_flash';批改数据： INSERT INTO test_flash.test_flash_tab (`id`, `k`, `c`,`pad`,`test_col1`) VALUES (10001,'5014614','68487932199-96439406143-93774651418-41631865787-96406072701-20604855487-25459966574-28203206787-41238978918-19503783441','22195207048-70116052123-74140395089-76317954521-98694025897','');update test_flash.test_flash_tab set pad='22195207048-70116052123-74140395089-76317954521-98694025897' where id=10000;delete from test_flash.test_flash_tab where id=9998;找回数据： ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答前情提要：业务须要删除大量数据，如果间接 delete 会造成如下问题： 1.会产生大事务，造成主从提早，影响数据库高可用切换。2.零碎表空间会一直收缩。3.锁定的记录多,更容易可能导致锁期待。问1：如何优雅的删除大量数据 答： 1.如果表不须要就间接 drop 2.如果只保留表构造用 truncate 3.如果只保留局部数据能够应用 pt-archive 进行分批删除 特地留神，如果表太大的话，间接drop会truncate可能会造成大量IO导致数据库呈现短暂响应提早，能够通过硬链接的形式对表删除解决 问2：零碎表空间一直收缩怎么解决答： 1.如果是已存在的数据库 无奈在线膨胀，那就通过mysqldump的形式建设新的从库，而后主从切换 2.新实例如何解决 a. 能够设置独立表空间，要害参数innodb_file_per_table独立表空间也会产生碎片，然而能够通过 OPTIMIZE TABLE 或 ALTER TABLE xxxx ENGINE=INNODB 进行碎片回收，5.7之后该操作属online ddl，具体能够自行测试 b. 设置独立UNDO空间，而后设置主动回收。5.6 版本就反对独立UNDO空间，然而不反对在线回收，要害参数 innodb_undo_directoryinnodb_undo_tablespacesinnodb_undo_logs5.7 版本减少了在线回收的性能，要害参数 innodb_undo_log_truncateinnodb_max_undo_log_sizeinnodb_purge_rseg_truncate_frequency8.0 版本中undo log的治理更加灵便，次要如下改良 1.能够动态创建或删除UNDO表空间2.能够动静减少或缩小UNDO表空间的数量3.无论是否要进行InnoDB复原，也能够在启动前更改相干设置问：ibtmp文件一直增大，怎么解决 答： 5.7 版本能够设置限度ibtmp大小，然而须要重启实例；同时超过设定的最大值会导致SQL执行失败，要害参数 innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:5G8.0 版本长期表空间有辨别全局和session级；垃圾SQL生成的长期表空间随着SQL的完结也会跟着主动开释。 Enjoy GreatSQL :) 文章举荐：GreatSQL MGR FAQhttps://mp.weixin.qq.com/s/J6... 万答#12，MGR整个集群挂掉后，如何能力主动选主，不必手动干涉https://mp.weixin.qq.com/s/07... 『2021数据技术嘉年华·ON LINE』：《MySQL高可用架构演进及实际》https://mp.weixin.qq.com/s/u7... 一条sql语句慢在哪之抓包剖析https://mp.weixin.qq.com/s/AY... 万答#15，都有哪些状况可能导致MGR服务无奈启动https://mp.weixin.qq.com/s/in... 技术分享 | 为什么MGR一致性模式不举荐AFTERhttps://mp.weixin.qq.com/s/rN... 对于 GreatSQLGreatSQL是由万里数据库保护的MySQL分支，专一于晋升MGR可靠性及性能，反对InnoDB并行查问个性，是实用于金融级利用的MySQL分支版本。 Gitee: https://gitee.com/GreatSQL/Gr... GitHub: https://github.com/GreatSQL/G... Bilibili：https://space.bilibili.com/13... 微信&QQ群：可搜寻增加GreatSQL社区助手微信好友，发送验证信息“加群”退出GreatSQL/MGR交换微信群 QQ群：533341697微信小助手：wanlidbc 本文由博客一文多发平台 OpenWrite 公布！

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。1. 需要背景与万里平安数据库软件GreatDB分布式部署模式介绍1.1 需要背景混沌测试是检测分布式系统不确定性、建设零碎弹性信念的一种十分好的形式，因而咱们采纳开源工具Chaos Mesh来做GreatDB分布式集群的混沌测试。 1.2 万里平安数据库软件GreatDB分布式部署模式介绍万里平安数据库软件GreatDB 是一款关系型数据库软件，同时反对集中式和分布式的部署形式，本文波及的是分布式部署形式。 分布式部署模式采纳shared-nothing架构；通过数据冗余与正本治理确保数据库无单点故障；数据sharding与分布式并行计算实现数据库系统高性能；可无限度动静扩大数据节点，满足业务须要。 整体架构如下图所示： 2. 环境筹备2.1 Chaos Mesh装置在装置Chaos Mesh之前请确保曾经事后装置了helm，docker，并筹备好了一个kubernetes环境。 1）在 Helm 仓库中增加 Chaos Mesh 仓库： helm repo add chaos-mesh https://charts.chaos-mesh.org2）查看能够装置的 Chaos Mesh 版本： helm search repo chaos-mesh3）创立装置 Chaos Mesh 的命名空间： kubectl create ns chaos-testing4）在docker环境下装置Chaos Mesh： helm install chaos-mesh chaos-mesh/chaos-mesh -n=chaos-testing验证装置执行以下命令查看Chaos Mesh的运行状况： kubectl get pod -n chaos-testing上面是预期输入： NAME READY STATUS RESTARTS AGEchaos-controller-manager-d7bc9ccb5-dbccq 1/1 Running 0 26dchaos-daemon-pzxc7 1/1 Running 0 26dchaos-dashboard-5887f7559b-kgz46 1/1 Running 1 26d如果3个pod的状态都是Running，示意 Chaos Mesh 曾经胜利装置。 ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。1、对于systemdsystemd 是Linux系统启动和服务器守护过程管理器，负责在系统启动或运行时，激活系统资源，服务器过程和其它过程，systemd被设计用来改良原来sysvinit中的多个毛病。 CentOS 7的systemd服务程序脚本寄存在 /usr/lib/systemd/目录下，并辨别 system 和 user，每一个服务程序脚本以 .service 结尾，例如 /usr/lib/systemd/system/sshd.service。 2、编辑systemd服务程序脚本设定 GreatSQL 二进制文件放在 /usr/local/GreatSQL-8.0.23-14/ 目录下，即设定 basedir 为此目录，先进入到这个工作目录中。 [root@greatsql~]# cd /usr/local/GreatSQL-8.0.23-14/复制 support-files/greatsql.server 程序脚本到 /usr/lib/systemd/system/ 目录下： [root@greatsql~]# cp -f ./support-files/greatsql.server /usr/lib/systemd/system/该脚本内容如下，基本上不须要再批改什么内容： [root@greatsql~]# cat /usr/lib/systemd/system/greatsql.service[Unit]Description=GreatSQL ServerDocumentation=man:mysqld(8)Documentation=http://dev.mysql.com/doc/refman/en/using-systemd.htmlAfter=network.targetAfter=syslog.target[Install]WantedBy=multi-user.target[Service]User=mysqlGroup=mysqlType=notifyTimeoutSec=0PermissionsStartOnly=trueExecStartPre=/usr/local/GreatSQL-8.0.23-14/bin/mysqld_pre_systemdExecStart=/usr/local/GreatSQL-8.0.23-14/bin/mysqld $MYSQLD_OPTSEnvironmentFile=-/etc/sysconfig/mysqlLimitNOFILE = 10000Restart=on-failureRestartPreventExitStatus=1Environment=MYSQLD_PARENT_PID=1PrivateTmp=false3、筹备my.cnf及其他配置文件复制 support-files/my.cnf 到 /etc/ 目录下，替换原来的配置文件（原来的 /etc/my.cnf 倡议先备份），并确认 datadir、port、server_id 等参数是否要批改： [root@greatsql~]# cp -f ./support-files/my.cnf /etc/my.cnf[root@greatsql~]# cat /etc/my.cnf#my.cnf[mysqld]user = mysqlport = 3306server_id = 3306basedir=/usr/local/GreatSQL-8.0.23-14datadir = /data/GreatSQLsocket = /data/GreatSQL/mysql.sockpid-file = mysql.pidcharacter-set-server = UTF8MB4skip_name_resolve = 1#若你的MySQL数据库次要运行在境外，请务必依据理论状况调整本参数default_time_zone = "+8:00"#performance setttingslock_wait_timeout = 3600open_files_limit = 65535back_log = 1024max_connections = 512max_connect_errors = 1000000table_open_cache = 1024table_definition_cache = 1024thread_stack = 512Ksort_buffer_size = 4Mjoin_buffer_size = 4Mread_buffer_size = 8Mread_rnd_buffer_size = 4Mbulk_insert_buffer_size = 64Mthread_cache_size = 768interactive_timeout = 600wait_timeout = 600tmp_table_size = 32Mmax_heap_table_size = 32M#log settingslog_timestamps = SYSTEMlog_error = /data/GreatSQL/error.loglog_error_verbosity = 3slow_query_log = 1log_slow_extra = 1slow_query_log_file = /data/GreatSQL/slow.loglong_query_time = 0.1log_queries_not_using_indexes = 1log_throttle_queries_not_using_indexes = 60min_examined_row_limit = 100log_slow_admin_statements = 1log_slow_slave_statements = 1log_bin = /data/GreatSQL/binlogbinlog_format = ROWsync_binlog = 1binlog_cache_size = 4Mmax_binlog_cache_size = 2Gmax_binlog_size = 1Gbinlog_rows_query_log_events = 1binlog_expire_logs_seconds = 604800#MySQL 8.0.22前，想启用MGR的话，须要设置binlog_checksum=NONE才行binlog_checksum = CRC32gtid_mode = ONenforce_gtid_consistency = TRUE#myisam settingskey_buffer_size = 32Mmyisam_sort_buffer_size = 128M#replication settingsmaster_info_repository = TABLErelay_log_info_repository = TABLErelay_log_recovery = 1slave_parallel_type = LOGICAL_CLOCK#能够设置为逻辑CPU数量的2倍slave_parallel_workers = 64binlog_transaction_dependency_tracking = WRITESETslave_preserve_commit_order = 1slave_checkpoint_period = 2#mgr settingsloose-plugin_load_add = 'mysql_clone.so'loose-plugin_load_add = 'group_replication.so'loose-group_replication_group_name = "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1"#MGR本地节点IP:PORT，请自行替换loose-group_replication_local_address = "172.16.16.10:33061"#MGR集群所有节点IP:PORT，请自行替换loose-group_replication_group_seeds = "172.16.16.10:33061,172.16.16.11:33061,172.16.16.12:33061"loose-group_replication_start_on_boot = OFFloose-group_replication_bootstrap_group = OFFloose-group_replication_exit_state_action = READ_ONLYloose-group_replication_flow_control_mode = "DISABLED"loose-group_replication_single_primary_mode = ON#innodb settingstransaction_isolation = REPEATABLE-READinnodb_buffer_pool_size = 2Ginnodb_buffer_pool_instances = 8innodb_data_file_path = ibdata1:12M:autoextendinnodb_flush_log_at_trx_commit = 1innodb_log_buffer_size = 32Minnodb_log_file_size = 1Ginnodb_log_files_in_group = 3innodb_max_undo_log_size = 4G# 依据您的服务器IOPS能力适当调整# 个别配一般SSD盘的话，能够调整到 10000 - 20000# 配置高端PCIe SSD卡的话，则能够调整的更高，比方 50000 - 80000innodb_io_capacity = 4000innodb_io_capacity_max = 8000innodb_open_files = 65535innodb_flush_method = O_DIRECTinnodb_lru_scan_depth = 4000innodb_lock_wait_timeout = 10innodb_rollback_on_timeout = 1innodb_print_all_deadlocks = 1innodb_online_alter_log_max_size = 4Ginnodb_print_ddl_logs = 1innodb_status_file = 1#留神: 开启 innodb_status_output & innodb_status_output_locks 后, 可能会导致log_error文件增长较快innodb_status_output = 0innodb_status_output_locks = 1innodb_sort_buffer_size = 67108864#innodb monitor settingsinnodb_monitor_enable = "module_innodb"innodb_monitor_enable = "module_server"innodb_monitor_enable = "module_dml"innodb_monitor_enable = "module_ddl"innodb_monitor_enable = "module_trx"innodb_monitor_enable = "module_os"innodb_monitor_enable = "module_purge"innodb_monitor_enable = "module_log"innodb_monitor_enable = "module_lock"innodb_monitor_enable = "module_buffer"innodb_monitor_enable = "module_index"innodb_monitor_enable = "module_ibuf_system"innodb_monitor_enable = "module_buffer_page"innodb_monitor_enable = "module_adaptive_hash"#pfs settingsperformance_schema = 1#performance_schema_instrument = '%memory%=on'performance_schema_instrument = '%lock%=on'再复制 support-files/sysconfig/mysql 文件到 /etc/sysconfig 目录下。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。问题1，有举荐的MGR运行最佳配置参考吗在「3306」社区广州站5月22日的分享会上，万里数据库CTO娄帅给出了他倡议的配置参考，咱们一起来看下： group_replication_single_primary_mode=ONlog_error_verbosity=3group_replication_bootstrap_group=OFF group_replication_transaction_size_limit=<默认值150MB，但倡议调低在20MB以内，不要应用大事务>group_replication_communication_max_message_size=10Mgroup_replication_flow_control_mode=OFF #官网版本的流控机制不太正当，其实能够思考敞开group_replication_exit_state_action=READ_ONLYgroup_replication_member_expel_timeout=5 #如果网络环境不好，能够适当调高另外，应用MGR的其余倡议有： 只是用InnoDB表。 每个表都必须要有主键。节点数采纳奇数。保障网络可靠性，低提早环境，不要跨城部署（个别倡议网络提早低于1ms）。应用单主模式。BINLOG_FORMAT=ROW。更多对于MGR的最佳应用实际，能够关注「3306」社区公众号（pai3306），获取娄帅老师本次分享内容。 问题2，MySQL Performance Schema都倡议开启哪些监控采集指标（除了默认主动开启的指标）先说我的认识：个别倡议只开启锁(Lock)监控相干的监测指标。 # 开启MDL监测指标mysql> CALL sys.ps_setup_enable_instrument('wait/lock/metadata/sql/mdl');# 开启全副Lock相干监测指标mysql> CALL sys.ps_setup_enable_instrument('%lock%');其余的监测指标，例如Memory、Statement、Transaction等，有必要再长期开启。因为从MySQL 5.7开始，PFS反对在线动静开启和敞开，因而非必要的话，不倡议一口气全开。 一般而言，PFS里的监测指标全开的话，对性能影响个别5%左右，内存耗费1G左右，整体还是可控的。 已知的问题是在Percona分支版本中，如果同时开启PFS和线程池后，很容易产生OOM。 小结： 需要的话，能够全开。对性能影响无限。但还是倡议只开锁监控相干的。问题3，mysqld过程占用内存过高怎么排查遇到一个比拟极其的案例，innodb_buffer_pool_size 值仅设置为2GB，然而mysqld过程却占用了25GB的内存。 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND45305 mysql 20 0 28.4g 25g 8400 S 48.5 81.4 64:46.82 mysqld前面会有专门的文章介绍详细分析排查过程，这里先间接说可能的起因以及解决方案。 可能的起因 1、session（会话）级内存buffer参数设置过高，并且连接数也设置过高，例如 read_buffer_size = 64Mread_rnd_buffer_size = 32Msort_buffer_size = 64Mjoin_buffer_size = 64Mtmp_table_size = 1Gmax_heap_table_size = 1Gmax_connections=2000当连接数较少时，须要耗费的内存并不多。 然而当遇到突发流量时，可能并发连接数会靠近打满，再加上可能有产生长期表、额定排序的低效率的SQL频繁呈现，这就很容易导致内存占用快速增长。 因而倡议调低session级buffer参数值，并无效管制并发连接数，上面是一个比拟通用的设置值参考： read_buffer_size = 4Mread_rnd_buffer_size = 4Msort_buffer_size = 4Mjoin_buffer_size = 4Mtmp_table_size = 32Mmax_heap_table_size = 32Mmax_connections = 5122、PFS中开启过多检测指标，造成内存耗费过大。 ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。客户发给我一个SQL，让我看看，为什么执行几分钟没有执行完。 我第一眼看到SQL的时候，我也感觉很简略，优化过程也比较简单，然而带来的剖析过程与教训还是值得分享的。 SQL语句如下： update ap_receive_benefits_log set orderstate= i_orderstate where requestid = i_orderid;然而这个SQL执行时被重大阻塞了 然而这个SQL执行时被重大阻塞了 该SQL的执行打算 疑难1 发现执行打算key走的主键，然而细看行数，会发现是全表扫描了数据。 如果没有可用索引的状况下，执行打算为什么显示走的主键，而不是空的呢？ 疑难2 这个SQL里的 i_orderid 字段会不会是表中的一个字段呢，如果不是字段，是哪里来的？ 剖析解决步骤如下 1.确认表中的数据量约75万，这个UPDATE语句每天都须要执行很屡次。 2.查看表后，发现并没有 i_orderid 字段，很是奇怪。就想这个SQL怎么来的，让开发确认一下这个SQL的起源，我来确认执行打算。如果是mysql 5.6以上版本能够间接查看UPDATE的执行打算，发现这个语句没有利用任何索引。 3.开发找了半天，确认程序没有这个语句。怎么办，如同成了‘没人认领的死尸’,开发确认不了，只能本人查了。 4.应用 pt-query-digest 剖析最近几个小时的慢查问，发现问题如下： 5.有一个存储过程执行次数很多，响应工夫也是也是最大，剖析此过程，查看该存储过程： 6.此存储过程执行状况： 7.到此，通过查看存储过程，能够确认产生阻塞的语句是过程里调用的，把存储过程发给开发，再次失去确认。 8.晓得语句了，优化就简略了，先确认字段的基数（唯一性）。 9.加上索引 alter table ap_receive_benefits_log idx_requestId(requestId); 后，这个UPDATE就能够走索引了，问题解决。 再次回应下面的疑难 疑难1 为什么update执行打算没有索引状况下，应用的主键？ 这个因为update语句查看执行打算的时候显示用的是主键，全表更新就是汇集索引，把这个update语句换成select，执行打算就是key显示的空。以下是测试的例子： update的时候执行打算 转成select语句执行打算 疑难2 为什么show processlist显示的是字段或者是变量名，误导了我的思路？ 测试一下： 创立过程并调用，提早后果 查看processlist的后果 从测试后果看到，过程调用有变量传参的时候，在processlist中显示的变量传参名，而不是表的字段名。 Enjoy GreatSQL :) ...

背景最近频繁呈现慢SQL导致系统性能问题，于是决定针对索引进行一些优化。一些表构造自身曾经有了不少索引，如果再持续增加索引，势必会影响到插入数据的性能。那么，是否能够应用组合索引来达到目标呢？这篇文章咱们来一探到底。 意识复合索引如果where条件中应用到多个字段，并且须要对多个字段建设索引，此时就能够思考采纳复合索引（组合索引）。比方查问地址时须要输出省、市，那么在省、市上建设索引，当数据量大时会明显提高查问速度。 组合索引有啥劣势呢？ 缩小查问开销：建设复合索引（c1,c2,c3），实际上相当于建设了（c1）,（c1,c2）,（c1,c2,c3）三个索引。对于大表来说，能够极大缩小开销。笼罩索引：MySQL能够间接通过遍历索引获得数据，而无需回表，缩小了很多的随机io操作。效率高：索引列越多，通过索引筛选进去的数据就越少，从而晋升查问效率。毛病： 索引字段越多，创立的索引越多，每个索引都会减少磁盘空间的开销；索引越多对查问效率晋升越高，但对须要更新索引的增删改操作会有效率影响；复合索引应用倡议：单表最好不要超过1个复合索引，单个复合索引最好不超过3个字段。一旦超过，就须要思考必要性和是否有其余代替计划。 最左匹配准则复合索引听从最左匹配准则，顾名思义，在组合索引中，最左侧的字段优先匹配。因而，在创立组合索引时，where子句中应用最频繁的字段放在组合索引的最左侧。 辅助索引是B+树实现的，尽管能够指定多个列，然而每个列的比拟优先级不一样，写在后面的优先比拟高。一旦呈现脱漏，在B+树上就无奈持续搜寻了（通过补齐等措施解决的除外），因而是依照最左间断匹配来的。既然是在B+树上搜寻，对于条件的比拟天然是要求准确匹配（即"="和"IN"）。 在where子句中用到两个字段c1和c2，那么创立索引时，两个字段的程序应该是（c1，c2）还是（c2，c1）呢？ 正确的做法是：把反复值起码的放后面。比方，95%的值都不反复，则可思考放最后面。 字段程序的影响复合索引听从最左匹配准则，那么在where查问条件中的字段是否也须要依照索引的程序来写呢？ 比方，复合索引为（c1,c2,c3），上面两个查问条件是否会对索引有影响呢？ select * from t_user where c1 = 1 and c2 = 4;select * from t_user where c2 = 4 and c1 = 1;看到有文章提出第一条SQL语句的效率更高，是否可信？两种查问形式条件一样，后果也应该一样，失常来说Mysql也会让它们走同样的索引。 通过Mysql的查问优化器explain剖析上述两个条语句，会发现执行打算完全相同。也就是说：SQL语句中的字段程序并不需要与复合索引字段程序统一，查问优化器会主动调整程序。 如果说有效率影响，那么也就是查问优化器改正程序的影响吧，简直能够忽略不计。 单字段是否能够触发索引？对于复合索引为（c1,c2,c3），相当于（c1）,（c1,c2）,（c1,c2,c3）三个索引，如果查问条件中只有c1，很显然是会走索引的。 但如果where条件如下呢： from t_user where c2 = 4;上述语句是否会走索引呢？这得分几种状况来阐明。 执行explan查问c1为条件的SQL语句： explain select * from t_user where c1 = 1;上述语句走的索引类型为：ref。ref类型示意Mysql会依据特定的算法疾速查找到符合条件的索引，而不会对索引中每一个数据都进行扫描判断。这种类型的索引为了疾速查出数据，索引就须要满足肯定的数据结构。 执行explan查问c2为条件的SQL语句： explain select c2 from t_user where c2 = 4;上述语句走的索引类型为：index。index类型示意Mysql会对整个索引进行扫描，只有是索引或索引的一部分Mysql就可能会采纳index方类型的形式扫描。因为此种形式是一条数据一条数据查找，性能并不高。 在这个例子中，对查问的字段有肯定的要求，where中条件为c2，select中查问出的字段也只能是c2，才会走index类型的索引。 如果将c2换成*或其余字段： explain select * from t_user where c2 = 4;上述语句会发现，不再走index索引，而是走全表扫描了。这也从侧面阐明了Mysql为什么要讲最左匹配准则了。 ...

作者：梁行 万里数据库DBA，善于数据库性能问题诊断、事务与锁问题的剖析等，负责解决客户MySQL日常运维中的问题，对开源数据库相干技术十分感兴趣。 GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。一、景象阐明在排查问题时发现MySQL主备做了切换，而查看MySQL服务是失常的，DBA也没有做切换操作，服务器也无保护操作，万幸的是业务还没有受到大的波及。这到底是是为什么呢？ 假如原主服务器地址为：172.16.87.72，原备主服务器地址为：172.16.87.123。 二、排查思路通过监控查看MySQL的各个指标查看双主（keepalived）服务切换日志MySQL谬误日志信息 三、问题排查3.1 通过监控零碎查看MySQL监控指标，判断故障产生的具体工夫（通过流量判断大抵切换工夫点） 通过监控查看当初主库MySQL（撑持业务）的监控指标，看一天的、十五天的 (以每秒查问数量速率为例) 发现从22号开始陡增，初步狐疑，可能22号产生了主备切换，再看一下备库的折线图，进一步确认 查看双主（keepalived）服务切换日志，确定主从切换工夫 3.2 查看keepalived判断为什么会做主从切换 先登录87.72查看keepalived的切换日志，日志信息如下：注：零碎是ubuntu而且keepalived没有指定输入日志输入，所以keepalived会将日志输入到零碎默认日志文件syslog.log中 shell> cat syslog.6|grep "vrrp"Oct 23 15:50:34 bjuc-mysql1 Keepalived_vrrp: VRRP_Script(check_mysql) failedOct 23 15:50:34 bjuc-mysql1 syslog-ng[31634]: Error opening file for writing; filename='/var/log/tang/Keepalived_vrrp.log', error='No such file or directory (2)'Oct 23 15:50:35 bjuc-mysql1 Keepalived_vrrp: VRRP_Instance(VI_74) Received higher prio advertOct 23 15:50:35 bjuc-mysql1 Keepalived_vrrp: VRRP_Instance(VI_74) Entering BACKUP STATEOct 23 15:50:35 bjuc-mysql1 syslog-ng[31634]: Error opening file for writing; filename='/var/log/tang/Keepalived_vrrp.log', error='No such file or directory (2)'Oct 23 15:50:35 bjuc-mysql1 syslog-ng[31634]: Error opening file for writing; filename='/var/log/tang/Keepalived_vrrp.log', error='No such file or directory (2)'Oct 23 15:50:35 bjuc-mysql1 syslog-ng[31634]: Error opening file for writing; filename='/var/log/tang/Keepalived_vrrp.log', error='No such file or directory (2)'Oct 23 15:50:35 bjuc-mysql1 syslog-ng[31634]: Error opening file for writing; filename='/var/log/tang/Keepalived_vrrp.log', error='No such file or directory (2)'Oct 23 15:50:56 bjuc-mysql1 Keepalived_vrrp: VRRP_Script(check_mysql) succeeded日志剖析后果 ...

『叶问』#41，三节点的MGR集群，有两个节点宕机后还能失常工作吗每周学点MGR常识。1. 三节点的MGR集群，有两个节点宕机后还能失常工作吗要看具体是哪种状况。 如果两个节点是失常敞开的话，则会向MGR集群发送退出信号，这种状况下，这两个节点属于失常退出，最初仅剩的节点会被晋升为Primary角色，还能够失常工作，容许对其进行读写，只是此时没有可用性冗余了。当其余节点再次启动并退出集群后，又能恢复正常服务。 如果是因为网络故障，或者mysqld过程产生oom、或被误杀、或其余起因退出了，则这些节点会被标识为 UNREACHABLE 状态，期待直到 group_replication_member_expel_timeout 时长（单位：秒）后这个节点才会正式退出集群。在这种状况下，一旦超过多数派节点处于 UNREACHABLE 状态时，则整个集群不可用，无奈提供读写服务。这种状况下，须要把剩下的节点重启MGR服务能力复原。 失常状况下，不要把 group_replication_member_expel_timeout 值调整太大，并且MGR的事务一致性级别尽量不要抉择 AFTER 模式，以防呈现整个集群服务不可用的问题，具体参见这篇文章：为什么MGR一致性模式不举荐AFTER。 2. MGR能够像主从复制那样只启动两个节点吗MGR在初始化启动时，是能够只启动两个节点，甚至只有一个节点，然而这样就失去MGR的意义了。因为只有少于三个节点，就没方法进行多数派投票，当产生网络故障等状况时，无奈投票确认哪些节点该被踢出集群。 Enjoy GreatSQL :) 文章举荐：GreatSQL MGR FAQhttps://mp.weixin.qq.com/s/J6... 万答#12，MGR整个集群挂掉后，如何能力主动选主，不必手动干涉https://mp.weixin.qq.com/s/07... 『2021数据技术嘉年华·ON LINE』：《MySQL高可用架构演进及实际》https://mp.weixin.qq.com/s/u7... 一条sql语句慢在哪之抓包剖析https://mp.weixin.qq.com/s/AY... 万答#15，都有哪些状况可能导致MGR服务无奈启动https://mp.weixin.qq.com/s/in... 技术分享 | 为什么MGR一致性模式不举荐AFTERhttps://mp.weixin.qq.com/s/rN... 对于 GreatSQLGreatSQL是由万里数据库保护的MySQL分支，专一于晋升MGR可靠性及性能，反对InnoDB并行查问个性，是实用于金融级利用的MySQL分支版本。 Gitee: https://gitee.com/GreatSQL/Gr... GitHub: https://github.com/GreatSQL/G... Bilibili：https://space.bilibili.com/13... 微信&QQ群：可搜寻增加GreatSQL社区助手微信好友，发送验证信息“加群”退出GreatSQL/MGR交换微信群 QQ群：533341697微信小助手：wanlidbc 本文由博客一文多发平台 OpenWrite 公布！

JuiceFS 非常适合用来做 MySQL 物理备份，具体应用参考咱们的官网文档。最近有个客户在测试时反馈，备份验证的数据筹备（xtrabackup --prepare）过程十分慢。咱们借助 JuiceFS 提供的性能剖析工具做了剖析，疾速发现性能瓶颈，通过一直调整 XtraBackup 的参数和 JuiceFS 的挂载参数，在一个小时内将工夫缩短到原先的 1/10。本文将咱们性能剖析和优化的过程记录分享下来，给大家剖析和优化 IO 性能提供参考。 数据筹备咱们通过 SysBench 工具生成一个大小 11GiB 左右的单表数据库，数据库表的 partition 设置成 10。为了模仿一个失常的数据库读写场景，通过 SysBench 以秒 50 个申请的压力拜访数据库，在该压力下数据库对数据盘造成的写数据在 8~10MiB/s 范畴内。通过下列命令将数据库备份到 JuiceFS 上。 # xtrabackup --backup --target-dir=/jfs/base/为了保障每次数据筹备操作的数据齐全一样，应用 JuiceFS 的快照（snapshot）性能基于 /jfs/base 目录生成快照 /jfs/base_snapshot/。每一次操作前都会将前一次数据筹备操作过的数据删掉从新生成一个新的快照。 应用默认参数# ./juicefs mount volume-demoz /jfs# time xtrabackup --prepare --apply-log-only --target-dir=/jfs/base_snapshot执行总耗时62秒。 JuiceFS反对导出操作日志 oplog，并能对 oplog 进行可视化展现。在执行 xtrabackup --prepare操作之前咱们新开一个终端连贯到该服务器，在命令行输出 # cat /jfs/.oplog > oplog.txt开始收集 oplog 日志，而后执行 xtrabackup --prepare 操作，操作完结后将 oplog.txt 下载到本地，上传到 JuiceFS 提供的 oplog 剖析页面：https://juicefs.com/oplog/。 ...

作者：烧鸡太子爷 起源：恒生LIGHT云社区 1、前言 阿里云的RDS服务提供了比较完善的DTS数据迁徙的计划,然而在做非阿里云间服务或跨数据库间数据迁徙时还是须要用ETL计划来同步。基于此，明天和大家一起针对DataX做一个分享和探讨，以便于后续在我的项目中遇到数据同步的需要的时候能够多一个技术抉择 2、DataX介绍 DataX 是淘宝开源的一个异构数据源离线同步工具，致力于实现包含关系型数据库(MySQL、postgreSQL等)、HDFS、Hive、ODPS、HBase、FTP等各种异构数据源之间稳固高效的数据同步性能。咱们心愿在一个很短的工夫窗口内，将一份数据从一个数据库同时导出到多个不同类型的数据库。 DataX正是为了解决这些问题而生DataX在阿里巴巴团体内被宽泛应用，承当了所有大数据的离线同步业务，并已继续稳固运行了6年之久。目前每天实现同步8w多道作业，每日传输数据量超过300TB。3、DataX框架设计 （图片起源官网）DataX自身作为离线数据同步框架，采纳Framework + plugin架构构建。将数据源读取和写入形象成为Reader/Writer插件，纳入到整个同步框架中。 Reader：Reader为数据采集模块，负责采集数据源的数据，将数据发送给Framework。 Writer： Writer为数据写入模块，负责一直向Framework取数据，并将数据写入到目标端。 Framework：Framework用于连贯reader和writer，作为两者的数据传输通道，并解决缓冲，流控，并发，数据转换等核心技术问题。 DataX自身作为数据同步框架，将不同数据源的同步形象为从源头数据源读取数据的Reader插件，以及向指标端写入数据的Writer插件，实践上DataX框架能够反对任意数据源类型的数据同步工作。同时DataX插件体系作为一套生态系统, 每接入一套新数据源该新退出的数据源即可实现和现有的数据源互通。 源码下载地址： https://github.com/alibaba/DataX 插件开发宝典地址： https://github.com/alibaba/DataX/blob/master/dataxPluginDev.md 4、DataX3.0插件体系 DataX目前曾经有了比拟全面的插件体系，支流的RDBMS数据库、NOSQL、大数据计算零碎都曾经接入。 DataX目前反对数据如下： 类型数据源Reader(读)Writer(写)RDBMS 关系型数据库MySQL√√``Oracle√√``SqlServer√√``PostgreSQL√√``达梦√√``通用RDBMS(反对所有关系型数据库)√√阿里云数仓数据存储ODPS√√``ADS``√ ``OSS√√``OCS√√NoSQL数据存储OTS√√``Hbase0.94√√``Hbase1.1√√``MongoDB√√无结构化数据存储TxtFile√√``FTP√√``HDFS√√DataX Framework提供了简略的接口与插件交互，提供简略的插件接入机制，只须要任意加上一种插件，就能无缝对接其余数据源。 当然也能够本人开发插件，官网也提供了插件开发宝典。 插件开发者不必关怀太多，根本只须要关注特定零碎读和写，以及本人的代码在逻辑上是怎么被执行的，哪一个办法是在什么时候被调用的。在此之前，须要明确以下概念： Job: Job是DataX用以形容从一个源头到一个目标端的同步作业，是DataX数据同步的最小业务单元。比方：从一张mysql的表同步到odps的一个表的特定分区。Task: Task是为最大化而把Job拆分失去的最小执行单元。比方：读一张有1024个分表的mysql分库分表的Job，拆分成1024个读Task，用若干个并发执行。TaskGroup: 形容的是一组Task汇合。在同一个TaskGroupContainer执行下的Task汇合称之为TaskGroupJobContainer: Job执行器，负责Job全局拆分、调度、前置语句和后置语句等工作的工作单元。相似Yarn中的JobTrackerTaskGroupContainer: TaskGroup执行器，负责执行一组Task的工作单元，相似Yarn中的TaskTracker。简而言之， Job拆分成Task，在别离在框架提供的容器中执行，插件只须要实现Job和Task两局部逻辑。 5、DataX3.0外围架构DataX3.0开源版本反对单机多线程模式实现同步作业运行，本大节按一个DataX作业申明周期的时序图，从整体架构设计十分简要阐明DataX各个模块互相关系。 （图片起源网络）外围模块介绍： 1.DataX实现单个数据同步的作业，咱们称之为Job，DataX承受一个Job之后，将启动一个过程来实现整个作业同步过程。DataX Job模块是单个作业的中枢治理节点，承当了数据荡涤、子工作切分（将繁多作业计算转化为多个子Task）. 2.DataXJob启动后，会依据不同的源端切分策略，将job切分成多个小的Task（子工作），以便于并发执行。Task便是DataX作业的最小单元，每一个Task都负责一部分数据的同步工作。 3.切分多个Task之后，DataX Job会调用Scheduler模块儿，依据配置的并发数据量，将拆分成的Task重新组合，组装成TaskGroup(工作组)。每一个TaskGroup负责以肯定的并发运行结束调配好的所有Task,默认单个工作组的并发数量为5. 4:每一个Task都由TaskGroup负责启动，Task启动后，会固定启动ReaderChannelWriter的线程来实现工作同步工作。 5.DataX作业运行起来之后，Job监控并期待多个TaskGroup模块工作实现，期待所有TaskGroup工作实现后Job胜利退出。否则，异样退出，过程退出值非0. DataX调度流程： 举例来说，用户提交了一个DataX作业，并配置了20个并发，目标是将一个100张分表的mysql数据同步到odps外面。 DataX的调度决策思路是： 1.DataXJob依据分库分表切分成了100个Task. 2.依据20个并发，DataX计算共须要调配4个TaskGroup. （默认每个TaskGroup的并发数量是5） 3.4个TaskGrou均匀切分好的100个Task,每一个TaskGroup负责5个并发共计25个Task. 6、DataX装置 运行环境： JDK (1.8.0_xxx) 必选DataX 必选Python (2.x) (反对Python3须要批改替换datax/bin上面的三个python文件，替换文件在doc/datax-web/datax-python3下) 必选，次要用于调度执行底层DataX的启动脚本，默认的形式是以Java子过程形式执行DataX，用户能够抉择以Python形式来做自定义的革新装置： 1、源码编译 2、官网编译好的包。 ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答自从GreatSQL 8.0.25 于 2021.8.26公布以来，针对MGR的新增或改良的次要内容 新增性能1.新增MGR Arbitrator节点（仲裁节点）角色。该节点只参加MGR投票仲裁，不寄存理论数据，也无需执行DML操作，因而能够用个别配置级别的服务器，在保障MGR可靠性的同时还能升高服务器老本。2.单主模式减少一个新的模式 -- 单主疾速模式，集群同步数据只有在内存确认即可，无需同步各个节点的apply信息。这种疾速模式，在跨机房部署，poc测试和内存要求不高的场合十分实用，这种模式弱于传统的异步复制，但强于半同步复制，且没有mgr默认的认证数据库内存问题。机制优化1.优化Xcom协程调度机制，避免个别task始终在读数据，而其余task无奈读取（个别task饿死），导致某些工作执行超时，会被误判为网络异样/超时/故障等状况。BUG修复1.修复了在BEFORE模式下一致性读可能导致断言谬误的问题。2.修复了在疾速单主模式下（group_replication_single_primary_fast_mode=1），非凡场景下存在内存透露的问题。该性能是GreatSQL中新增的。3.修复了因为hostname配置谬误，可能导致启动时报告新端口曾经被占用的问题。4.修复了运行时新增节点导致吞吐量稳定异样的问题，使得吞吐更安稳。5.修复了个别情况下view显示不正确的问题。6.修复了谬误启动PRIMARY节点时，如果同时退出多个节点可能导致集群丢数据的问题，此时如果只退出单个节点，则不会导致此问题。以上改良内容打算在Percona Server 8.0.27公布后跟进推出，敬请急躁期待。 Enjoy GreatSQL :) 文章举荐：GreatSQL MGR FAQhttps://mp.weixin.qq.com/s/J6... 万答#12，MGR整个集群挂掉后，如何能力主动选主，不必手动干涉https://mp.weixin.qq.com/s/07... 『2021数据技术嘉年华·ON LINE』：《MySQL高可用架构演进及实际》https://mp.weixin.qq.com/s/u7... 一条sql语句慢在哪之抓包剖析https://mp.weixin.qq.com/s/AY... 万答#15，都有哪些状况可能导致MGR服务无奈启动https://mp.weixin.qq.com/s/in... 技术分享 | 为什么MGR一致性模式不举荐AFTERhttps://mp.weixin.qq.com/s/rN... 对于 GreatSQLGreatSQL是由万里数据库保护的MySQL分支，专一于晋升MGR可靠性及性能，反对InnoDB并行查问个性，是实用于金融级利用的MySQL分支版本。 Gitee: https://gitee.com/GreatSQL/Gr... GitHub: https://github.com/GreatSQL/G... Bilibili：https://space.bilibili.com/13... 微信&QQ群：可搜寻增加GreatSQL社区助手微信好友，发送验证信息“加群”退出GreatSQL/MGR交换微信群 QQ群：533341697微信小助手：wanlidbc 本文由博客一文多发平台 OpenWrite 公布！

实用分区或者说分表最多的场景仍然是针对工夫字段做拆分， 这节咱们具体讲讲如何更好的基于工夫字段来拆分。别离依照年、月、日几个维度的实现办法以及一些细节注意事项。 第一，以年为维度做拆分日期字段拆分粒度的抉择跟业务检索申请密切相关。比方保留10年数据，每次查问基于某个具体年份做为过滤条件，那依照年拆分必定最好。例如上面SQL： select * from ytt_pt1 where log_date >='2018-01-01' and log_date < '2019-01-01';那咱们来看下依照年独自拆分的理论例子：表ytt_pt1 ，蕴含1000W条记录，以年为粒度建设分区表。 mysql> create table ytt_pt1(id bigint, log_date date);Query OK, 0 rows affected (0.18 sec)mysql> insert into ytt_pt1 select id,log_date from ytt_p1 limit 10000000;Query OK, 10000000 rows affected (3 min 49.53 sec)Records: 10000000 Duplicates: 0 Warnings: 0mysql> ALTER TABLE ytt_pt1 PARTITION BY RANGE (year(log_date)) -> ( -> PARTITION p0001 VALUES LESS THAN (2012), -> PARTITION p0002 VALUES LESS THAN (2013), -> PARTITION p0003 VALUES LESS THAN (2014), -> PARTITION p0004 VALUES LESS THAN (2015), -> PARTITION p0005 VALUES LESS THAN (2016), -> PARTITION p0006 VALUES LESS THAN (2017), -> PARTITION p0007 VALUES LESS THAN (2018), -> PARTITION p0008 VALUES LESS THAN (2019), -> PARTITION p0009 VALUES LESS THAN (2020), -> PARTITION p0010 VALUES LESS THAN (2021), -> PARTITION p_max VALUES LESS THAN (maxvalue) -> );Query OK, 10000000 rows affected (2 min 33.31 sec)Records: 10000000 Duplicates: 0 Warnings: 0看下按年为粒度的查问成果：以下SQL 间接走分区p0008，查问工夫0.91秒， 这个工夫不算短，前期能够减少过滤条件来缩小查问工夫。 ...

最近生产环境零星呈现了几笔脏数据，即同一业务编号呈现了两条数据(咱们零碎中唯一性并未依附于数据库的索引)。明明代码中曾经加锁了， 还呈现这样的问题，经定位，发现是事务的隔离性，导致第二个事务看不到第一个事务的数据，从而导致数据反复。 业务伪代码// 省略了一些必要的异样解决。@Transactionalpublic void saveAndComplete(T entity) { lock.lock(); code = repository.findByCode(entity.getCode()); if (code.isEmpty()) { repository.save(entity); } this.Complete(entity.getCode()); lock.unlock();}代码很简略，有一个saveAndComplete办法，用来保留实体，并实现工作，并用Spring的事务管理器治理事务，当Complete办法抛出异样时，进行回滚。然而如果数据库事务隔离级别为读已提交及以上，在高并发量下，还是会呈现反复数据。 起因剖析 事务t1启动。事务t2启动。线程t1获取锁，胜利。事务t2获取锁，失败，并期待。线程t1查看是否存在entity1，发现不存在，保留数据。线程t1开释锁。事务t1提交。事务t2获取锁。事务t2 查看是否存在entity1，发现不存在，保留数据。事务t2 开释锁。事务t2 提交。次要起因就在步骤9，因为InnoDB默认的隔离级别是可反复读，所以即便事务t1曾经将entity1插入数据库，事务t2也是看不到的，所以会呈现反复数据。 问题解决问题解决起来也不难，只有保障事务t2在事务t1完结之后再开始即可，即插入数据这个动作的事务线性化。代码如下 // 省略了一些必要的异样解决。public void saveAndComplete(T entity) { lock.lock(); transactionManager.getTransaction(); // 先获取锁，再开启事务 code = repository.findByCode(entity.getCode()); if (code.isEmpty()) { repository.save(entity); } this.Complete(entity.getCode()); transactionManager.commit(); // 先提交事务，最初开释锁。 lock.unlock();}

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

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答转载申明：以下文章来源于MySQL学习 ，作者八怪（高鹏） 一、两个重要的指标这两个指标就是 replication_group_member_status 视图中的 COUNT_TRANSACTIONS_IN_QUEUE ：期待抵触验证的队列数量，实际上是进行pipeline解决的队列数量（外部示意m_transactions_waiting_certification），单位为事务数量。COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE：期待利用的队列数量（外部示意m_transactions_waiting_apply），单位为事务数量。这两个值，特地是第二个咱们通常用于在单主模式下，作为判断是否提早的规范。本文就是来解释一下这两个指标具体的含意。 二、相干起源和broadcast线程实际上这两个信息实际上次要是供流控应用的，次要来自本地节点和远端节点pipeline的信息。那么远端的信息是如何获取到的呢？实际上在咱们的MGR线程中有一个叫做Certifier_broadcast_thread::dispatcher的线程，这个线程发送本地的pipeline信息给远端节点。这个线程次要实现的工作蕴含： 30秒设置一次 设置send_transaction_identifiers = true，这个值次要用于在构建Pipeline_stats_member_message类型音讯的时候是否蕴含gtid信息。这些GTID信息次要是蕴含committed_transactions和last_conflict_free_transaction。这些信息同样会在replication_group_member_status中进行体现，也就是咱们看到的TRANSACTIONS_COMMITTED_ALL_MEMBERS和LAST_CONFLICT_FREE_TRANSACTION。 每秒进行 构建Pipeline_stats_member_message类型的音讯（type CT_PIPELINE_STATS_MEMBER_MESSAGE），并且发送给远端节点。其中蕴含了咱们上述的2个重要指标也就是m_transactions_waiting_certification/m_transactions_waiting_apply. COUNT_TRANSACTIONS_IN_QUEUE （m_transactions_waiting_certification） 实际上这是appler线程进行pipeline解决的队列数量，来自于applier_module->get_message_queue_size()，一旦解决实现就会写入到relay log，相应的队列也会出队。理论它的入队是xcom engine线程进行的push操作。一旦写入relay log后就会进行pop解决，队列数量也会缩小。参考Applier_module::applier_thread_handle处 applier线程解决的流程。因而并不是单主就不会有抵触验证队列，一样是有的，只是解决要快于多主，因为任何事务的event都须要进行pipeline解决，其中蕴含了抵触验证、GTID生成、写入relay log等操作。COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE（m_transactions_waiting_apply） 来自于m_transactions_waiting_apply.load()，这个值在Applier_handler::handle_event函数减少，当pipeline的Applier_handler解决实现，也就是写入了relay log后减少。这个值在hook group_replication_trans_before_commit处进行缩小，函数首先就会判断提交的事务是不是来自applier通道，如果是则进行缩小。当然如果是主库咱们事务提交是前台线程本人，而不是applier通道，所以不会影响这个值。简略的写入relay log的逻辑和指标减少逻辑：error = channel_interface.queue_packet((const char *)p->payload, p->len); //写入 relay log 调用仍旧为queue event if (event->get_event_type() == binary_log::GTID_LOG_EVENT && local_member_info->get_recovery_status() == Group_member_info::MEMBER_ONLINE) { applier_module->get_pipeline_stats_member_collector() ->increment_transactions_waiting_apply(); //减少期待利用当然本音讯中蕴含了所有replication_group_member_status的指标，这里简略列举如下： m_transactions_certified.load() 这个值在认证最初进行更新，用于统计以后认证了多少工作，当然这里只是通过了 Certifier::certify的事务的个数，因而单主也会有这个值。 m_transactions_applied.load() 曾经利用的事务，这个值在hook group_replication_trans_before_commit处进行减少 首先就会判断提交的事务是不是来自applier通道，如果是则进行减少m_transactions_local.load() 本地事务的数量，这个值在hook group_replication_trans_before_commit处进行减少 在group_replication_trans_before_commit中会判断提交的事务到底是applier通道过的 sql线程还是前台session，如果是前台session则减少(cert_interface != nullptr) ? cert_interface->get_negative_certified(): 0 抵触认证操作失败的事务数量(cert_interface != nullptr) ? cert_interface->get_certification_info_size(): 0 抵触认证数据库的大小send_transaction_identifiers 30秒一次设置为true，是否发送了本地相干的GTID信息committed_transactions 全局提交的事务的gtid信息，这里这个信息30秒发送一次，次要来自于 为 CT_CERTIFICATION_MESSAGE 音讯后处理的所有节点执行 GTID事务的交加last_conflict_free_transaction 最初一次没有抵触的事务数量m_transactions_local_rollback.load() 因为抵触认证，本地须要回滚的事务数量mode 是否开启了流量管制而后会依据是否开启流控进行综合各个节点的pipeline信息，进行流控指标的计算，如果一旦计算出须要进行流控解决，则事务须要在group_replication_trans_before_commit处进行流控期待。 ...

问题查问城市是“杭州”的所有人名字，并且依照姓名排序返回前 1000 集体的姓名、年龄。建表语句： CREATE TABLE `t` ( `id` int(11) NOT NULL, `city` varchar(16) NOT NULL, `name` varchar(16) NOT NULL, `age` int(11) NOT NULL, `addr` varchar(128) DEFAULT NULL, PRIMARY KEY (`id`), KEY `city` (`city`)) ENGINE=InnoDB;查问语句： select city,name,age from t where city='杭州' order by name limit 1000 ;全字段排序1、初始化 sort_buffer，确定放入 name、city、age 这三个字段；2、从索引 city 找到第一个满足 city='杭州’条件的主键 id，也就是图中的 ID_X；3、到主键 id 索引取出整行，取 name、city、age 三个字段的值，存入 sort_buffer 中；4、从索引 city 取下一个记录的主键 id；5、反复步骤 3、4 直到 city 的值不满足查问条件为止，对应的主键 id 也就是图中的 ID_Y；6、对 sort_buffer 中的数据依照字段 name 做疾速排序；依照排序后果取前 1000 行返回给客户端。 ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答在MGR测试中，人为制作磁盘满问题后，节点被oom killed问题形容在对MySQL 8.0.26 vs GreatSQL 8.0.25的比照测试过程中，有一个环节是人为制作磁盘满的场景，看看MGR是否还能失常响应申请。 在实测过程中，最初发现磁盘满的那个节点，持续时间足够久后，会因为内存耗费过大而最终被OS给OOM Kill。 这个问题我已报告BUG（#104979），上面是该过程的具体记录。 首先，间接利用dd复制空文件填满磁盘。 MySQL 8.0.26 测试过程disk full报告过程及何时被oom killed 来看下MySQL 8.0.26遇到disk full时日志都输入哪些内容： # 首次提醒disk full的时刻是 09:44:10.052558，这时其实还能写入日志，只是不能写数据和binlog2021-09-18T09:44:10.052558+08:00 10 [ERROR] [MY-000035] [Server] Disk is full writing './yejr-mgr3-relay-bin-group_replication_applier.000046' (OS errno 28 - No space left on device). Waiting for someone to free space... Retry in 60 secs. Message reprinted in 600 secs.2021-09-18T09:44:10.052558+08:00 15 [ERROR] [MY-000035] [Server] Disk is full writing '/data/MySQL/binlog.000039' (OS errno 28 - No space left on device). Waiting for someone to free space... Retry in 60 secs. Message reprinted in 600 secs.2021-09-18T09:54:10.109075+08:00 15 [ERROR] [MY-000035] [Server] Disk is full writing '/data/MySQL/binlog.000039' (OS errno 28 - No space left on device). Waiting for someone to free space... Retry in 60 secs. Message reprinted in 600 secs.2021-09-18T09:54:10.109828+08:00 10 [ERROR] [MY-000035] [Server] Disk is full writing './yejr-mgr3-relay-bin-group_replication_applier.000046' (OS errno 28 - No space left on device). Waiting for someone to free space... Retry in 60 secs. Message reprinted in 600 secs.2021-09-18T09:56:15.020870+08:00 152 [ERROR] [MY-010907] [Server] Error writing file '/data/MySQL/slow.log' (errno: 28 - No space left on device)# 最初一次提醒disk full时是10:04:10.166349，这时候彻底无奈写入日志了2021-09-18T10:04:10.166349+08:00 15 [ERROR] [MY-000035] [Server] Disk is full writing '/data/MySQL/binlog.000039' (OS errno 28 - No space left on device). Waiting for someone to free space... Retry in 60 secs.从disk full时刻开始，大概过了2.5小时，mysqld过程内存耗费持续上升，最终引发oom kill ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。MySQL 8.0.26下MGR体现如何？用实测数据谈话。此外，MySQL 8.0.26还存在一个重大缺点。MySQL 8.0.26公布差不多两个月了，始终还没对它进行测评，看到release notes中波及到几个MGR相干的Bug fixed，最近抽空对其简略测试一番，上面说说后果吧。 本文后半段还会爆出MySQL 8.0.26的一个重大缺点。 本次测试选用sysbench的mix-load计划（感激楼方鑫老师的分享）： require("oltp_common")local runtype = 0;function prepare_statements() -- use 1 query per event, rather than sysbench.opt.point_selects which -- defaults to 10 in other OLTP scripts sysbench.opt.point_selects=1 runtype = (10 * sysbench.tid + 10) / sysbench.opt.threads if runtype <= 6 then prepare_point_selects() else prepare_non_index_updates() endendfunction event(thread_id) if runtype <= 6 then execute_point_selects() else execute_non_index_updates() endend上面是压测相干的几个指标参数： --tables=10--table_size=100000--threads=16--report-interval=1上面是InnoDB & MGR相干的几个主要参数选项值： innodb_buffer_pool_size = 256Mslave_parallel_type = LOGICAL_CLOCKslave_parallel_workers = 64binlog_transaction_dependency_tracking = WRITESETslave_preserve_commit_order = 1slave_checkpoint_period = 2group_replication_flow_control_mode = "DISABLED"备注：因为测试机配置个别，所以压测的数据量并不大，并发也不高。 ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。本文来自投稿：by 作业帮DBA团队一、架构需要:失常状况下每个云的业务程序(下图中的APP) 通过本地的cetus 写入本地的MGR 节点(默认启动时通过cetus 配置本地MGR 节点为rw); 读申请会依据 cetus 读写拆散策略路由到不同的云的MGR 节点当本地MGR 节点故障,则cetus 会自动检测配置中的后端MGR 节点,选取一个新的存活节点作为rw 节点。此时业务跨云读写。当单个云整体故障时(单云孤岛),集群残余节点能够失常提供服务,业务层须要切流,将业务流量指向其余失常云的服务(APP) 二、测试流程1.性能测试比照同机房是指 sysbench 以及压测的节点都在同一个机房; 跨机房指 sysbench 和 压测脚本中配置的mysql_host 在不同的机房次要进行Read_Write 以及 Write_Only 两个模式进行比照主机配置: 35C 376GMySQL 版本: GreatSQL 8.0.25buffer_pool: 24G测试数据: sbtest 8张表 * 3000wsysbench压测脚本:- oltp_read_write.lua- oltp_write_only.lua=> Read_Write 压测比照 跨机房状况下集群吞吐量降落显著,耗时减少显著 => Write_Only 压测比照 跨机房比照同机房耗时减少20ms 左右 跨机房下耗时高起因排查: 通过抓包剖析,压测应用的脚本中的事务都是带有begin,commit。在commit 之前的每个语句都要减少一个rtt 的延迟时间(机房之间的耗时在3ms 左右)。 因而在跨机房的状况下每个事务的响应工夫都会至多额定减少(每个事务中 sql个数 * 3ms) 的工夫。 2.故障场景测试次要测试在单节点故障,多节点故障,单机房整体故障时对业务的预期影响以及DB 侧应答的策略 集群初始状态: (3个 主机,每台主机部署一个MGR 节点+cetus 节点) Cetus中rw节点在172上 ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 明天咱们来持续介绍 MySQL 8.0 的新密码策略， 别离为双明码策略和内置随机明码生成。 第一，双明码策略：首先来解释下什么是双明码策略？ 双明码策略就是在日常运维中，须要定期更改指定用户明码，同时又须要旧明码临时保留肯定时长的一种策略。其作用是提早利用与数据库之间的用户新旧明码对接工夫，进而平滑利用的操作感知。能够在如下场景中应用： 在 MySQL 数据库里咱们部署最多也是最成熟的架构：一主多从。比如说此架构做了读写拆散，主负责解决前端的写流量，读负责解决前端的读流量，为了平安起见，须要定期对利用连贯数据库的用户更改明码。有了双明码机制，对用户明码的更改在利用端能够有肯定的缓冲提早，防止业务中断危险以及开发人员的埋怨。利用端仍然能够应用旧明码来实现对数据库的检索，期待适合机会再应用管理员发来的新密码检索数据库。 双明码机制蕴含主明码与备明码，当备明码不再应用时，告知管理员抛弃备明码，此时用户的主明码即是惟一明码。 具体如何应用呢？ 用法如下： 管理员先创立一个新用户 ytt ，明码是 root_old ，完了更改他的明码为 root_new 。此时 root_new 即为主明码，而 root_old 即为备明码。 mysql:(none)>create user ytt identified by 'root_old';Query OK, 0 rows affected, 2 warnings (0.24 sec)mysql:(none)>alter user ytt identified by 'root_new' retain current password;Query OK, 0 rows affected (0.17 sec)接下来用户 ytt 别离应用备明码与主明码连贯 MySQL 并且执行一条简略的 SQL 语句： ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 本篇持续介绍 MySQL 8.0 的新密码验证策略。 假如有这样的需要： 管理员别离创立了一个开发用户与运维用户，并且要求这两个用户必须满足如下需要， 开发用户要求定期更改明码，并且明码不能与近期更改过的明码重叠，也即不能复用历史明码，这里限定历史明码个数为3；运维用户同样要求定期更改明码，并且明码不能与某段时间内更改过的明码重叠，也即同样不能复用历史明码，这里限定时间段为一个礼拜。以上两种改明码需要，在数据库侧临时无奈实现，只能拿个”小本子记住历史明码保留个数、历史明码保留天数“，在用户每次更改明码前，先检测小本子上有没有和新密码重叠的历史明码。 MySQL 8.0 对以上这两种改明码需要，间接从数据库端实现，用户能够扔掉“小本子”了。 我来分两局部解说在 MySQL 8.0 版本里对以上改明码需要的具体实现。 第一，在配置文件里写上全局参数参数 password_history 示意最近应用的明码保留次数； 参数 password_reuse_interval 示意最近应用的明码保留天数。 先来实现开发用户的需要：保留历史明码个数为3。管理员用户登录，设置全局参数： mysql:(none)>set persist password_history=3;Query OK, 0 rows affected (0.00 sec)退出重连，创立用户 ytt_dev : root@ytt-ubuntu:/home/ytt# mysql -S /opt/mysql/mysqld.sockWelcome to the MySQL monitor. Commands end with ; or \g.Your MySQL connection id is 33Server version: 8.0.27 MySQL Community Server - GPL...mysql:(none)>create user ytt_dev identified by 'root123';Query OK, 0 rows affected (0.15 sec)退出连贯，用户 ytt_dev 从新连贯数据库，并且更改两次明码： ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 引言 引言这里来介绍下MySQL 8.0 版本自带的新密码验证策略。 注释咱们十分相熟这样的模式： 用户想更改本人明码，须要提供原来明码或者追加手机验证码才能够， 这种模式在MySQL数据库里始终不存在。在MySQL 8.0 之前的版本，普通用户能够间接更改本人明码，不须要旧明码验证，也不须要知会管理员，比方用户ytt_admin 须要更改明码，在MySQL 5.7 下间接敲alter user 命令即可： root@ytt-ubuntu:~# mysql -uytt_admin -proot1234 -P5734 -h ytt-ubuntu -e "alter user ytt_admin identified by 'root'"mysql: [Warning] Using a password on the command line interface can be insecure.这样的明码更改行为其实不是很平安，假如有上面的场景呈现：用户ytt_admin 登录到MySQL服务后，做了些日常操作，实现后遗记退出；此时刚好有一个居心叵测的用户ytt_fake 进入ytt_admin的登录环境，间接敲命令alter user 即可更改用户ytt_admin的明码，并且退出以后登录环境，用户ytt_admin本尊再次登录MySQL，就会提醒明码谬误，不容许登录，此时用户ytt_admin大脑必定是懵的。为了避免这类不安全事件的产生，MySQL 8.0 公布了一系列明码验证策略。 这里介绍第一项：以后明码验证策略设置！以后明码验证策略有两种办法来给到具体用户。第一种，从管理员侧来设置单个用户的以后明码验证策略。创立用户或者更改用户设置时应用子句： password require current（示意强制此用户满足以后明码验证策略） 。 mysql:(none)>create user ytt_admin identified by 'root123' password require current;Query OK, 0 rows affected (0.11 sec)之后以用户ytt_admin 登录MySQL并且更改明码，提醒须要提供旧明码才行。 ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 ProxySQL 是一个应用十分宽泛并且较稳固的中间件，有很多性能点。 比方查问缓存，查问重写，读写拆散，数据分片等等。 本篇要介绍的是 ProxySQL 和 MySQL Replication 以及 MySQL MGR 的初步联合，初步读写拆散以及 failover 性能的体验。 在本机装置一个 ProxySQL 实例，六个 MySQL 实例；ProxySQL 和 MySQL 版本均是最新版。 ProxySQL: 治理端口6032，流量端口6033。 MySQL Replication：流量端口别离为：3340、3341、3342 MySQL MGR： 流量端口别离为：3343、3344、3345 第一，ProxySQL 以及六个 MySQL 部署。ProxySQL 装置比较简单，官网 apt/yum ，或者本人下载安装。装好六个 MySQL 实例，并且配置好 MySQL 主从以及组复制环境。 第二，ProxySQL 记录 MySQL 实例相干信息。进入 ProxySQL 治理端，把以上六个 MySQL 实例信息顺次插入到表 mysql_servers ：主从实例的 hostgroup_id 对立设置为1， 为了不毁坏后续 failover 相干 hostgroup_id 的连续性，组复制实例的 hostgroup_id 对立设置为3。 ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。1. 导言咱们在采纳InnoDB引擎的状况下，编写SQL语句WHERE条件的时候，能够通过AND操作符来进步数据的过滤能力，当然，在应用AND操作符也有许多须要留神的中央，就好比一条更新语句： mysql>update testtable set price = 52.0,name = 'test_name';本意是将表内对应字段重置为指定信息，可是当初不小心写成了： mysql>update testtable set price = 52.0 and name = 'test_name';这个时候，咱们查看表发现： mysql> select * from testtable;+----+----------+------------+| id | name | price |+----+----------+------------+| 1 | old_name | 0.00 || 2 | old_name | 0.00 |+----+----------+------------+显然，零碎会把AND当做判断条件进行逻辑判断，这里所有列都不满足条件，所以后果为0。此时，咱们能够利用事务回滚个性，回滚这个update，而为了更好地了解，咱们须要从新来看看这一条update语句 2. binlog和redo log现有一条SQL语句： mysql>update testtable set price = price + 1 where id = 5;咱们晓得，这条语句在分析器是进行词法和语法解析，并且晓得这是一条更新语句。并由优化器决定要应用id这个索引。而后，执行器负责具体执行，找到这一行，而后更新。说到更新流程，说到更新操作，咱们不得不提到两个日志模块：binlog和redo log 2.1 binlog先来说一说binlog，该日志存在于Server档次中，是应用存储引擎都能够应用的日志模块，binlog是逻辑日志，记录的是这个语句的原始逻辑，比方“给id=5这一行的price字段值加1”binlog的日志文件是能够追加写入的。“追加写入”是指binlog日志文件写到肯定大小后会切换到下一个文件进行写入，能够设置sync_binlog为1，让每次事务的binlog都长久化保留到磁盘中 2.2 redo log而重做日志redo log是MySQL中InnoDB引擎才有的日志，它是物理日志，即记录的内容是“在某个数据页上做了什么批改“ MySQL对于每一次的更新操作如果都须要写进磁盘，而后磁盘也要找到对应的那条记录，而后再更新，过程中的IO老本、查找老本都很高。redo log无效的晋升了更新效率 redo log是固定大小的，比方能够配置为一组4个文件，每个文件的大小是1GB，那么总共就能够有4GB的空间去记录咱们进行的操作。从头开始写，写到开端就又回到结尾循环写，如下图： ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。背景介绍在我的项目选型中，在KVM(16c 16G ssd160G )的 Linux7.6 零碎上部署了MYSQL MGR 集群 (GreatSQL 8.0.25)。 应用 sysbench 创立了100仓数据，且针对表创立为 partition 表，进行间断12小时的稳固下压测，来评估对应的架构的可能撑持的业务并发数，以及最高的TPS/QPS是多少。 在应用256并发，间断压测进行了12个小时之后，发现节点的SSD磁盘空间使用率达到 95% 以上，过后第一工夫去查看 log 目录，log目录曾经达到 100G+，认为是 binlog 设置的工夫太长导致的 binlog 没有及时清理造成的，去清理 binlogbinlog 过期工夫设置的 1800s，理论 binlog 和 MGR 的 relay-group 空间占用在11G左右而 du -sh * 查看到的日志文件大小时，发现其中undo大小1个是71G另一个4.1G，且MGR的3个节点的undo均是这个状况，急需开释空间。 然而MySQL8.0是否反对类型oracle的undo在线的替换来进行膨胀呢，答案是必定的，而且有些相似。 oracle/mysql undo 表空间设置主动扩大，如果业务上有跑批量或者大表的DML操作时，引起大事物，或针对多张大表关联更新工夫较长，可能短时间内会将undo"撑大"，oracle 咱们能够通过创立一个新的 undo，通过在线的替换的形式，将收缩的 undo 应用 drop 删除以开释空间。 mysql 8.0同样能够应用这种形式来解决，因大事物或长事物引起的undo过大占用空间较多的状况。 办法如下1、增加新的undo文件undo003。mysql8.0中默认innodb_undo_tablespace为2个，有余2个时，不容许设置为inactive，且默认创立的undo受爱护，不容许删除。2、将收缩的 undo 长期设置为inactive，以及 innodb_undo_log_truncate=on，主动 truncate 开释收缩的undo空间。3、从新将开释空间之后的undo设置为active，可从新上线应用。具体操作如下[greatdb@mysql ~]$ mysql -ugreatsql -pgreatsql -h172.16.130.15 -P3307 mysql: [Warning] Using a password on the command line interface can be insecure.Welcome to the MySQL monitor. Commands end with ; or \g.Your MySQL connection id is 74Server version: 8.0.25-15 GreatSQL, Release 15, Revision c7feae175e0Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.Oracle is a registered trademark of Oracle Corporation and/or itsaffiliates. Other names may be trademarks of their respectiveowners.Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.mysql[(none)]> show variables like '%undo%';+--------------------------+-----------------------------+| Variable_name | Value |+--------------------------+-----------------------------+| innodb_max_undo_log_size | 4294967296 || innodb_undo_directory | /app/dbdata/sqlnode3306/log || innodb_undo_log_encrypt | OFF || innodb_undo_log_truncate | ON || innodb_undo_tablespaces | 2 |+--------------------------+-----------------------------+5 rows in set (0.01 sec)1、查看undo大小 ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答本文起源：原创投稿 GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。筹备编译环境部署2.1 首先先装置Cmake 2.2 也能够应用软件包管理工具brew进行装置 2.3 其余软件包装置类同，留神安装包版本 2.4 所有软件包装置实现后解压percona源码到本人目录 可能呈现的问题目前percona局部函数在Macos零碎与ubuntu、centos上的差别1. 筹备编译环境所需软件包，顺次装置: CMake3.21.2、OpenSSL1.1、ncurses、bison3.5.1、m4、boost1.73、flex 2.6.4以上软件包能够自行到对应官网下载安装，下载地址参考如下 MySQL官网参考阐明(https://dev.mysql.com/doc/ref...)percona下载(https://github.com/percona/pe...)boost下载(https://www.boost.org/users/d...)cmake下载(https://cmake.org/download/)目前已在Macos零碎10.14.6、10.15、11.6尝试编译通过，雷同硬件配置目前10.14.6零碎编译速度最快2. 编译环境部署2.1 首先先装置Cmake双击cmake安装包进行装置，装置实现后执行命令查看cmake版本 $cmake --version2.2 也能够应用软件包管理工具brew进行装置以下具体以brew形式装置为样例 1）首先装置软件包治理⼯具brew /bin/zsh -c "$(curl -fsSL https://gitee.com/cunkai/HomebrewCN/raw/master/Homebrew.sh)"2）应用以下命令先查看须要装置的版本是否存在，例如：$ brew search openssl找到对应版本1.1后执行命令进行装置 $ brew install openssl@1.1装置实现执行以下命令后依据提醒设置环境变量 $ brew link openssl --force编辑⽤户根⽬录.profile 文件(Macos零碎版本不同文件名可能存在不同，依据提醒操作相应文件)加⼊环境变量，增加该文件如： 依据装置完提醒加⼊ export PATH="/usr/local/opt/openssl@1.1/bin:$PATH"export LDFLAGS="-L/usr/local/opt/openssl@1.1/lib"export CPPFLAGS="-I/usr/local/opt/openssl@1.1/include"2.3 其余软件包装置类同，留神安装包版本2.4 所有软件包装置实现后解压percona源码到本人目录进入percona源码目录，依据本人设置命令中相应资源目录： -DWITH_ROCKSDB ：boost压缩包目录-DCMAKE_INSTALL_PREFIX：编译实现后默认装置目录其余参数可依据须要自行添加和批改，命令参考如下：$ cmake -DCMAKE_BUILD_TYPE=DEBUG -DWITH_DEBUG=true -DDOWNLOAD_BOOST=1 -DWITH_BOOST=/usr/local/boost/ -DCMAKE_INSTALL_PREFIX=/usr/local/percona/ -DWITH_ZLIB=bundled -DWITH_LIBEVENT=bundled 执行胜利后再执行编译并装置，其中-j10示意10个编译命令并行编译能够进步编译速度，具体并行编译命令应用个数能够依据本身电脑配置状况设定 $ make -j10 && make install编译并装置实现后配置my.cnf文件启动数据库 3. 可能呈现的问题1）编译过程中如果呈现提醒xcode装置，依据提醒装置即可2）因为Macos零碎默认应用本人的ssl库，在cmake编译过程中如果呈现提醒找不到ssl库谬误，此时能够在cmake命令后退出参数指定openssl目录-DWITH_SSL='/usr/local/opt/openssl@1.1'3）呈现谬误后，再次执行cmake 命令前先清理CMakeCache.txt文件4. 目前percona局部函数在Macos零碎与ubuntu、centos上的差别因为零碎起因目前percona一些函数运算后果与其余零碎存在肯定的差别例如：以整数123456求正弦值等为例 Enjoy GreatSQL :) 文章举荐：GreatSQL MGR FAQhttps://mp.weixin.qq.com/s/J6... ...

MySQL的json查问简略理解只从MySQL反对json字段当前，我还是很少用，然而问的人的确不少，为了不便大家更好的了解用法，咱们应用理论例子来简略理解一下json字段。篇幅可能不少，大家急躁看即可。 json函数列表（弃用的不在进行阐明）名称形容链接->json字段的列，相当于array_extract()博文->>json字段的列，并去除引号，相当于json_unquote(array_extract())博文json_array创立一个数组博文json_array_append向指定地位后追加值博文json_array_insert向指定地位前插入值博文json_contains海底捞针博文json_contains_path是否有键名博文json_depthjson深度博文json_lengthjson长度博文json_valid是否是无效json博文json_typejson类型博文json_insertjson中插入值博文json_replacejson中替换值博文json_setjson中插入或者替换值博文json_merge_patchjson合并，同名键值合并博文json_merge_preservejson合并，同名键值合成新对象博文json_removejson移除指定值博文json_keys获取json的键值博文json_object创立一个json对象博文json_overlaps比照俩个json，如果有一个雷同则返回true博文json_pretty格式化json博文json_quote将字符串转为带引号的字符串博文待实现列表名称形容链接json_schema_valid json_schema_validation_report json_search json_storage_free json_storage_size json_table json_unquote json_value member_of 留言点击留言

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答背景阐明AWS RDS 权限受限，应用 mysqldump 的时候无奈增加 --master_data 参数获取Binlog 的 Pos 信息，故须要调用官网存储过程进行解决，具体步骤如下。 操作步骤1.登陆aws从实例确认下主从同步 mysql> show slave status\G;2.调用aws的存储过程进行同步 mysql> call mysql.rds_stop_replication;3.调用aws的存储过程，调整binlog保留工夫为168H mysql> call mysql.rds_set_configuration('binlog retention hours',168);4.在直达的aws服务器上进行数据导出 mysql> mysqldump --single-transaction --default-character-set=utf8 -h 从aws的域名 -P从aws端口 -uroot -pGreatSQL -R -E -B 导出的库名 > /backup/导出的库名_工夫.sql记录以下4个信息 Master_Host # RDS的HOST信息，通常是一串域名Master_Port # RDS的端口Relay_Master_Log_File # 主RDS节点BinlogExec_Master_Log_Pos # 主RDS节点Pos5.将导出SQL导入的本地实例中 mysql> mysql -uroot -pGreatSQL -S /tmp/mysql.sock < /backup/导出的库名_工夫.sql6.创立同步权限 mysql> GRANT REPLICATION SLAVE ON *.* TO 'sync'@'%' IDENTIFIED BY 'GreatSQL';mysql> flush privileges;7、建设同步 ...

version: '3' services: db: image: mysql:5.7.23 restart: always container_name: "mysql_5_7" environment: MYSQL_ROOT_PASSWORD: 123456 ports: - "3306:3306" volumes: - ./data:/var/lib/mysql

一、慢查问参数阐明slow_query_log 慢查问开启状态slow_query_log_file 慢查问日志寄存的地位（这个目录须要MySQL的运行帐号的可写权限，个别设置为MySQL的数据寄存目录）long_query_time 查问超过多少秒才记录 二、操作步骤1、查看慢查问参数mysql> show variables like 'slow_query%';+---------------------------+----------------------------------+| Variable_name | Value |+---------------------------+----------------------------------+| slow_query_log | OFF || slow_query_log_file | /mysql/data/localhost-slow.log |+---------------------------+----------------------------------+mysql> show variables like 'long_query_time';+-----------------+-----------+| Variable_name | Value |+-----------------+-----------+| long_query_time | 10.000000 |+-----------------+-----------+2、设置办法办法一：全局变量设置1.将 slow_query_log 全局变量设置为“ON”状态 mysql> set global slow_query_log='ON';2.设置慢查问日志门路 mysql> set global slow_query_log_file='/usr/local/mysql/data/slow.log';设置慢查问工夫，设置超过1s就统计mysql> set global long_query_time=1;办法二：配置文件设置 批改配置文件my.cnf，在[mysqld]下的下方退出[mysqld]slow_query_log = ONslow_query_log_file = /usr/local/mysql/data/slow.loglong_query_time = 1重启mysql服务失效配置3、验证慢查问配置查看设置后的参数mysql> show variables like 'slow_query%';+---------------------+--------------------------------+| Variable_name | Value |+---------------------+--------------------------------+| slow_query_log | ON || slow_query_log_file | /usr/local/mysql/data/slow.log |+---------------------+--------------------------------+mysql> show variables like 'long_query_time';+-----------------+----------+| Variable_name | Value |+-----------------+----------+| long_query_time | 1.000000 |+-----------------+----------+执行一条慢查问SQLmysql> select sleep(2);查看慢查问日志中是否有记录

测试数据CREATE TABLE `book_comment` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `user_id` int(10) unsigned NOT NULL, `like_num` int(10) NOT NULL DEFAULT '0' COMMENT '点赞数', `content` varchar(200) NOT NULL, `addtime` datetime NOT NULL, PRIMARY KEY (`id`), KEY `user_id` (`user_id`), KEY `addtime` (`addtime`), KEY `uid_addtime` (`user_id`,`addtime`)) ENGINE=InnoDB COMMENT='书本评论表';INSERT INTO `book_comment` VALUES ('1', '1', '0', '评论1', '2017-05-17 00:00:00');INSERT INTO `book_comment` VALUES ('2', '1', '2', '评论2', '2017-05-17 00:03:01');INSERT INTO `book_comment` VALUES ('3', '2', '3', '评论3', '2017-05-17 00:03:02');INSERT INTO `book_comment` VALUES ('4', '2', '4', '评论4', '2017-05-17 00:00:03');INSERT INTO `book_comment` VALUES ('5', '3', '0', '评论5', '2017-05-17 00:00:04');INSERT INTO `book_comment` VALUES ('6', '1', '1', '评论6', '2017-05-17 00:00:05');INSERT INTO `book_comment` VALUES ('7', '4', '0', '评论7', '2017-05-17 00:00:06');INSERT INTO `book_comment` VALUES ('8', '4', '2', '评论8', '2017-05-17 00:00:07');INSERT INTO `book_comment` VALUES ('9', '4', '0', '评论9', '2017-05-17 00:00:08');INSERT INTO `book_comment` VALUES ('10', '4', '3', '评论10', '2017-05-17 00:00:09');INSERT INTO `book_comment` VALUES ('11', '3', '2', '评论11', '2017-05-17 00:00:10');CREATE TABLE `book_comment_like` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `comment_id` int(10) unsigned NOT NULL COMMENT '评论表id', `like_name` varchar(200) NOT NULL COMMENT '点赞用户', `addtime` datetime NOT NULL, PRIMARY KEY (`id`), KEY `comment_id` (`comment_id`), KEY `addtime` (`addtime`)) ENGINE=InnoDB COMMENT='书本评论点赞表';INSERT INTO `book_comment_like` VALUES ('1', '1', '点赞用户1', '2017-05-17 00:03:01'); INSERT INTO `book_comment_like` VALUES ('2', '1', '点赞用户2', '2017-05-17 00:03:01'); INSERT INTO `book_comment_like` VALUES ('3', '2', '点赞用户3', '2017-05-17 00:03:02'); INSERT INTO `book_comment_like` VALUES ('4', '2', '点赞用户4', '2017-05-17 00:03:02'); INSERT INTO `book_comment_like` VALUES ('5', '2', '点赞用户5', '2017-05-17 00:03:02'); INSERT INTO `book_comment_like` VALUES ('6', '2', '点赞用户6', '2017-05-17 00:00:03'); INSERT INTO `book_comment_like` VALUES ('7', '3', '点赞用户7', '2017-05-17 00:00:04'); INSERT INTO `book_comment_like` VALUES ('8', '5', '点赞用户8', '2017-05-17 00:00:06'); INSERT INTO `book_comment_like` VALUES ('9', '5', '点赞用户9', '2017-05-17 00:00:07'); INSERT INTO `book_comment_like` VALUES ('10', '5', '点赞用户10', '2017-05-17 00:00:08'); 关联表一对多。一条评论会有多个用户点赞。 ...

1、删掉 data 文件夹，这个文件夹的具体位置是 my.ini 里决定的数据库数据的寄存地位，个别默认都是数据库的根目录。 遇到删除不了的状况，关上服务->敞开mysql服务 2、应用命令初始化data数据 mysqld --initialize --console 会从新生成一个明码，用这个明码就能够从新登录数据库了 3、登录数据库留神 mysql -uroot -pshow databases; # 无奈应用，会提醒你批改明码alter user 'root'@'localhost' identified by 'root';报错ERROR 2003 (HY000): Can't connect to MySQL server on 'localhost' (10061)，因为数据库服务没有启动，从新开启数据库服务，已有的mysql80服务预计无奈失常启动，因而须要mysqld -nstall 重新安装一下，装置服务默认名为mysql # 服务->开启mysql服务net start mysql # 启动mysql服务net start mysql80 # 无奈启动# 如果找不到mysql服务mysqld -install# 删除原来无用的服务sc delete mysql80

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。0.背景介绍在某零碎中为了保障历史数据的压缩性，采纳tokudb引擎存储数据。 slave节点所在机器数据盘总大小33TB，故障时磁盘残余空间1.1TB。 [root@redhat76-greatdb greatdb]# df -hFilesystem Size Used Avail Use% Mounted on/dev/vda1 33T 32T 1.1T 97% /devtmpfs 63G 0 63G 0% /devtmpfs 63G 0 63G 0% /dev/shmtmpfs 63G 4.0G 59G 7% /run1.景象形容master节点失常进行，slave节点的数据库谬误日志如下： 2021-05-08T18:31:00.210203+08:00 44458 [ERROR] Slave SQL for channel '': Worker 1 failed executing transaction 'fb18799a-afeb-11eb-a3f0-fa163e18e1d9:513684180' at master log greatdb-bin.031344, end_log_pos 8397; Could not execute write_rows event on table test.t1; Got error 28 from storage engine, Error_code: 1030; handler error No Error!; the event's master log FIRST, end_log_pos 8397, Error_code:10302021-05-08T18:31:00.210236+08:00 44457 [Warning] Slave SQL for channel '': ... The slave coordinator and worker threads are stoppped, possibly leaving data in inconsistent state, A restart should restore consistency automatically, althougn using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details). Error_code:1756 此时slave不可进行读写，回放停止 ...

前言： 后面文章咱们介绍过一些罕用数据类型的用法，比方 int、char、varchar 等。始终没具体介绍过 blob 及 text 类型，尽管这两类数据类型不太罕用，但在某些场景下还是会用到的。本篇文章将次要介绍 blob 及 text 数据类型的相干常识。 1. blob 类型blob(binary large object) 是一个能够存储二进制文件的容器，次要用于存储二进制大对象，例如能够存储图片，音视频等文件。依照可存储容量大小不同来分类，blob 类型可分为以下四种： 类型可存储大小用处TINYBLOB0 - 255字节短文本二进制字符串BLOB0 - 65KB二进制字符串MEDIUMBLOB0 - 16MB二进制模式的长文本数据LONGBLOB0 - 4GB二进制模式的极大文本数据其中最罕用的就是 blob 字段类型了，最多可存储 65KB 大小的数据，个别可用于存储图标或 logo 图片。不过数据库并不适宜间接存储图片，如果有大量存储图片的需要，请应用对象存储或文件存储，数据库中能够存储图片门路来调用。 2. text 类型text 类型同 char、varchar 相似，都可用于存储字符串，个别状况下，遇到存储长文本字符串的需要时能够思考应用 text 类型。依照可存储大小辨别，text 类型同样可分为以下四种： 类型可存储大小用处TINYTEXT0 - 255字节个别文本字符串TEXT0 - 65 535字节长文本字符串MEDIUMTEXT0 - 16 772 150字节较大文本数据LONGTEXT0 - 4 294 967 295字节极大文本数据不过在日常场景中，存储字符串还是尽量用 varchar ，只有要存储长文本数据时，能够应用 text 类型。比照 varchar ，text 类型有以下特点： text 类型毋庸指定长度。若数据库未启用严格的 sqlmode ，当插入的值超过 text 列的最大长度时，则该值会被截断插入并生成正告。text 类型字段不能有默认值。varchar 可间接创立索引，text 字段创立索引要指定前多少个字符。text 类型检索效率比 varchar 要低。上面咱们来具体测试下 text 类型的应用办法： ...

下载MySQL安装包和装置源： wget https://dev.mysql.com/get/mysql57-community-release-el7-11.noarch.rpmyum -y localinstall mysql57-community-release-el7-11.noarch.rpm 在线装置MySQL后启动服务且设置开机启动 yum -y install mysql-community-serversystemctl start mysqldsystemctl enable mysqldsystemctl daemon-reload批改root登录明码 vim /var/log/mysqld.log登录数据库批改明码 mysql -u root -p#输出明码#设置root明码ALTER USER 'root'@'localhost' IDENTIFIED BY '123456';# 设置近程登录GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY '123456' WITH GRANT OPTION;flush privileges;exit;#开启3306端口firewall-cmd --zone=public --add-port=3306/tcp --permanent;firewall-cmd --reload;firewall-cmd --list-all;#重启数据库systemctl restart mysqld;

〇、对于DDL、DML和DCLDDL（Data Definition Languages）语句：数据定义语言，这些语句定义了不同的数据段、数据库、表、列、索引等数据库对象的定义。罕用的语句关键字次要包含 create、drop、alter 等。 DML（Data Manipulation Language）语句：数据操纵语句，用于增加、删除、更新和查询数据库记录，并查看数据完整性。罕用的语句关键字次要包含 insert、delete、udpate 和 select 等。(增删改查） DCL（Data Control Language）语句：数据管制语句，用于管制不同数据段间接的许可和拜访级别的语句。这些语句定义了数据库、表、字段、用户的拜访权限和安全级别。次要的语句关键字包含 grant、revoke 等。 一、DDL 实现形式在 MySQL5.6 版本以前，执行 DDL 次要有两种形式：Copy 形式 和 In-place 形式 Copy 形式执行DDL操作创立与原表构造定义完全相同的长期表为原表加MDL（meta data lock，元数据锁）锁，禁止对表中数据进行增删改，容许查问在长期表上执行DDL语句依照主键 ID 递增的程序，把数据一行一行地从原表里读出来再插入到长期表中降级原表上的锁，禁止对原表中数据进行读写操作将原表删除，将长期表重命名为原表名，DDL操作实现In-place 形式执行DDL操作In-place 形式 又称为 Fast Index Creation 。与 Copy 形式相比，In-place形式不复制数据，因而大大放慢了执行速度。然而这种形式仅反对对二级索引进行增加、删除操作，而且与Copy形式一样须要全程锁表。上面以增加索引为例，简略介绍In-place形式的实现流程： 创立新索引的数据字典为原表加MDL（meta data lock，元数据锁）锁，禁止对表中数据进行增删改，容许查问依照聚簇索引的程序，查问数据，找到须要的索引列数据，排序后插入到新的索引页中期待关上以后表的所有只读事务提交创立索引完结In-place 形式执行DDL操作MySQL5.6 版本之后退出了 Online DDL 新个性，用于反对DDL执行期间DML语句的并行操作，进步数据库的吞吐量。与 Copy 形式和 In-place 形式相比，Online 形式在执行DDL的时候能够对表中数据进行读写操作。Online DDL能够无效改善DDL期间对数据库的影响： Online DDL期间，查问和DML操作在少数状况下能够失常执行，对表格的锁工夫也会大大减少，尽可能的保障数据库的可扩展性；容许 In-place 操作的 DDL，防止重建表格占用过多磁盘IO及CPU资源，缩小对数据库的整体负荷，使得在DDL期间，可能维持数据库的高性能及高吞吐量；容许 In-place 操作的 DDL，比须要COPY到临时文件的操作要更少占用buffer pool，防止以往DDL过程中性能的长期降落，因为以前须要拷贝数据到长期表，这个过程会占用到buffer pool ，导致内存中的局部频繁拜访的数据会被清理进来。Online DDL 实现本质上也能够分为2种形式：Copy 形式和 In-place 形式： ...

最近，线上的 ETL 数据归档 SQL 产生了点问题，有一个 UPDATE SQL 跑了两天还没跑进去： update t_order_record set archive_id = '420a7fe7-4767-45e8-a5f5-72280c192faa', update_time = update_time where order_id in (select order_id from t_retailer_order_record force index (idx_archive_id) where archive_id = '420a7fe7-4767-45e8-a5f5-72280c192faa')这个 SQL 其实就是将 t_retailer_order_record 中 archive_id 为 420a7fe7-4767-45e8-a5f5-72280c192faa 的所有记录的订单 id order_id，对应的订单表中的记录的 archive_id 也更新为 420a7fe7-4767-45e8-a5f5-72280c192faa 并且更新工夫放弃不变（因为表上有 update_time 按以后工夫更新的触发器）。 对于 SQL 的优化，咱们能够应用上面三个工具进行剖析： EXPLAIN：这个是比拟通俗的剖析，并不会真正执行 SQL，剖析进去的可能不够精确具体。然而能发现一些关键问题。PROFILING： 通过 set profiling = 1 开启的 SQL 执行采样。能够剖析 SQL 执行分为哪些阶段，并且每阶段的耗时如何。须要执行并且执行胜利 SQL，并且剖析进去的阶段不够具体，个别只能通过某些阶段是否存在如何防止这些阶段的呈现进行优化（例如防止内存排序的呈现等等）。OPTIMIZER TRACE：具体展现优化器的每一步，须要执行并且执行胜利 SQL。MySQL 的优化器因为思考的因素太多，迭代太多，配置相当简单，默认的配置在大部分状况没问题，然而在某些非凡状况会有问题，须要咱们进行人为干涉。首先，咱们针对这个 SQL 进行 EXPLAIN： ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答 MySQL优化器索引抉择迷思。 高鹏（八怪）对本文亦有奉献。 1. 问题形容群友提出问题，表里有两个列c1、c2，别离为INT、VARCHAR类型，且别离创立了unique key。 SQL查问的条件是 WHERE c1 = ? AND c2 = ?，用EXPLAIN查看执行打算，发现优化器优先选择了VARCHAR类型的c2列索引。 他示意很不了解，难道不应该抉择看起来代价更小的INT类型的c1列吗？ 2. 问题复现创立测试表t1： [root@yejr.run]> CREATE TABLE `t1` ( `c1` int NOT NULL AUTO_INCREMENT, `c2` int unsigned NOT NULL, `c3` varchar(20) NOT NULL, `c4` varchar(20) NOT NULL, PRIMARY KEY (`c1`), UNIQUE KEY `k3` (`c3`), UNIQUE KEY `k2` (`c2`)) ENGINE=InnoDB;利用 mysql_random_data_load 写入一万行数据： mysql_random_data_load -h127.0.0.1 -uX -pX yejr t1 10000查看执行打算： [root@yejr.run]> EXPLAIN SELECT * FROM t1 WHERE c2 = 1755950419 AND c3 = 'MichaelaAnderson'\G*************************** 1. row *************************** id: 1 select_type: SIMPLE table: t1 partitions: NULL type: constpossible_keys: k3,k2 key: k3 key_len: 82 ref: const rows: 1 filtered: 100.00 Extra: NULL能够看到优化器确实抉择了 k3 索引，而非"预期"的 k2 索引，这是为什么呢？ ...

MySQL的json查问之json_insert、json_merge_patch、json_merge_preserve、josn_remove、json_replace、json_set json_insert就是向json中插入，如果不存在则插入，存在则疏忽json_replace就是替换json中的项，如果不存在则疏忽，存在则替换json_set联合后面俩个，存在则替换，不存在则插入json_merge_patch多个json进行合并，雷同键名，前面的笼罩后面的，如果值是对象，则递归进行解决json_merge_preserve多个json进行合并，雷同键名，则键值组成新的对象json_remove移除掉json某一项数据表 json_insert例一select json_insert(info, '$.age', 26) from member; json中并不存在age键名，则插入 例二select json_insert(info, '$.name', 'swk') from member; json中存在name键名，则疏忽 json_replace例一select json_replace(info, '$.name', 'swk') from member; json中存在name键名，则进行替换 例二select json_replace(info, '$.age', 26) from member; json中不存在age键名，则疏忽 json_set例一select json_set(info, '$.name', 'swk') from member; json中存在name键名，则进行替换 例二select json_set(info, '$.age', 26) from member; json中不存在age键名，则插入 json_merge_patch例一select json_merge_patch(info, '{"name":"swk","age":26}') from member; json合并，如果存在雷同键名，则前面的笼罩后面的，如果值是对象，会递归 json_merge_preserveselect json_merge_preserve(info, '{"name":"swk","age":26}') from member; json合并，如果存在雷同键名，则组成新的对象 json_remove例一select json_remove(info, '$.name') from member; 移除json中指定项 留言点击留言

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答作者：景云丽、卢浩、宋源栋 GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。引言批量更新数据，不同于这种 update a=a+1 where pk > 500，而是须要对每一行进行独自更新 update a=1 where pk=1;update a=12 where pk=7;... 这样间断多行update语句的场景，是少见的。 能够说是偶尔也是一种必然，在GreatDB 5.0的开发过程中，咱们须要对多语句批量update的场景进行优化。 两种多行更新操作的耗时比照在咱们对表做多行更新的时候通常会遇到以下两种状况 1.单语句批量更新（update a=a+1 where pk > 500） 2.多语句批量更新（update a=1 where pk=1;update a=12 where pk=7;...） 上面咱们进行实际操作比拟两种场景，在更新雷同行数时所耗费的工夫。 数据筹备数据库版本：MySQL 8.0.23 t1表，建表语句以及筹备初始数据1000行 create database if not exists test;use test##建表create table t1(c1 int primary key,c2 int);##创立存储过程用于生成初始数据DROP PROCEDURE IF EXISTS insdata;DELIMITER $$CREATE PROCEDURE insdata(IN beg INT, IN end INT) BEGIN WHILE beg <= end DO INSERT INTO test.t1 values (beg, end);SET beg = beg+1;END WHILE;END $$DELIMITER ;##插入初始数据1000行call insdata(1,1000)1.单语句批量更新更新语句 ...

json_depth顾名思义就是深度，json_length顾名思义就是长度，json_type就是类型，json_valid是否是无效的json，这几个是比拟容易了解的，对于我而言，这几个其实没什么太大的用途。还是用例子进行解说。数据表（member）select * from member; 例一select json_depth(info) from member; 特地留神：json是空数组或者空对象是返回的是1，更深的请自行测试 例二select json_length(info) from member; 例三select json_type(info) from member; 例四select json_valid(id),json_valid(info) from member; 留言点击留言

温习1、MYSQL索引构造 数据结构应用范畴12hash较少索引以hash模式组织起来，查找单条记录时速度十分快不反对范畴查找和排序等性能B+ tree频繁索引以均衡树的模式来组织，更适宜用来解决排序、范畴查找等性能查找单条记录的速度不如hash2、MYSQL常见索引类型 表列 A表列 B一般索引最根本的索引，没有任何限度惟一索引与"一般索引"相似，不同的就是：索引列的值必须惟一，但容许有空值主键索引一种非凡的惟一索引，不容许有空值全文索引仅可用于 MyISAM 表，针对较大的数据，生成全文索引很耗时好空间组合索引为了更多的进步mysql效率可建设组合索引，遵循”最左前缀“准则3、非主键索引会存储主键索引的值，因而举荐选用短字段当主键索引。4、惟一索引：插入的时候，一般索引比惟一索引性能要高一点，惟一索引须要校验内容。 查问过程1、一般索引跟惟一索引执行上的区别：一般索引的等值查问，会持续遍历到第一个不相等的值才会完结，而惟一索引等值查问，命中则完结（性能差距微不足道）。2、Innodb按页读取，一页16KB。 更新过程1、change buffer概念：当须要更新一个数据页时，如果数据页在内存中就间接更新，而如果这个数据页还没有在内存中的话，在不影响数据一致性的前提下，InnoDB 会将这些更新操作缓存在 change buffer 中，这样就不须要从磁盘中读入这个数据页了。在下次查问须要拜访这个数据页的时候，将数据页读入内存，而后执行 change buffer 中与这个页无关的操作。2、change buffer应用条件：惟一索引的更新不能应用 ，实际上也只有一般索引能够应用。3、change buffer应用场景：——对于写多读少的业务来说，页面在写完当前马上被拜访到的概率比拟小，此时 change buffer 的应用成果最好。这种业务模型常见的就是账单类、日志类的零碎；——假如一个业务的更新模式是写入之后马上会做查问，那么即便满足了条件，将更新先记录在 change buffer，但之后因为马上要拜访这个数据页，会立刻触发 merge 过程。这样随机拜访 IO 的次数不会缩小，反而减少了 change buffer 的保护代价。4、总结——一般索引与惟一索引，一般索引在更新时速度更快，尽量选一般索引——更新之后马上就是查问时，不应用change buffer——change buffer更适宜一般索引 索引抉择和实际1、机械硬盘，change buffer收益高2、redo log 与 change buffer(含磁盘长久化) 这2个机制，不同之处在于优化了整个变更流程的不同阶段。 先不思考redo log、change buffer机制，简化形象一个变更(insert、update、delete)流程： 1、从磁盘读取待变更的行所在的数据页，读取至内存页中。 2、对内存页中的行，执行变更操作 3、将变更后的数据页，写入至磁盘中。 步骤1，波及 随机 读磁盘IO； 步骤3，波及 随机 写磁盘IO； --change buffer机制，优化了步骤1,防止了随机读磁盘IO；--redo log机制， 优化了步骤3,防止了随机写磁盘IO，将随机写磁盘，优化为了程序写磁盘(写redo log，确保crash-safe)；--在咱们mysql innodb中， change buffer机制不是始终会被利用到，仅当待操作的数据页以后不在内存中，须要先读磁盘加载数据页时，change buffer才有用武之地。 redo log机制，为了保障crash-safe，始终都会用到。3、redo log 次要节俭的是随机写磁盘的 IO 耗费（转成程序写）；change buffer 次要节俭的则是随机读磁盘的 IO 耗费。 ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。 用GreatSQL，上MGR更释怀！P.S，文末有彩蛋，别错过 ：）在3月20日「3306」社区成都站分享会上，万里数据库CTO娄帅做了主题分享《MGR Bug修复之路》。 娄帅指出，因为MGR本身的复杂性，以及复现BUG场景也更艰难，所以MySQL官网针对MGR的BUG修复工作通常比拟迟缓，沉积较多。这也就造成了社区用户不太敢放心使用官网版本的MGR，放心遇到各种不可控的BUG，甚至较重大的线程、事务hang住等问题，感觉还是不那么牢靠。 万里数据库外围研发团队深入研究MGR架构，并在一直的BUG修复实际中总结出了一套欠缺、晦涩的BUG修复流程，将MGR的缺点分为BUG和性能两类，整顿出共16种BUG及性能缺点问题。 万里数据库研发团队通过一段时间精心筹备，对BUG修复的代码进行review后，决定先放出第一个稳固版本GreatSQL 8.0.22-13，这是基于Percona Server 8.0.22-13源码编译而来。之所以抉择Percona分支版本，是因为它曾经在官网版本的根底上进行了性能补充以及性能晋升等优化工作，也算是"站在伟人肩膀上"吧。 本次放出的版本，次要有以下改良和晋升： 1.稳定性晋升晋升大事务稳定性优化MGR队列garbage collect机制、改良流控算法，以及缩小每次发送数据量，防止性能抖动解决了AFTER模式下，存在节点退出集群时容易出错的问题在AFTER模式下，强一致性采纳多数派准则，以适应网络分区的场景当MGR节点解体时，能更快发现节点异样状态，无效缩小切主和异样节点的等待时间优化MGR DEBUG日志输入格局2.bug修复修复了节点异样时导致MGR大范畴性能抖动问题修复了传输大数据可能导致逻辑判断死循环问题修复了启动过程中低效期待问题修复了磁盘满导致吞吐量异样问题修复了多写模式下可能丢数据的问题/单主模式下切主丢数据的问题修复了TCP self-connect问题随着代码review工作的推动，咱们也会持续放弃版本更新，一直放出新版本，以飨社区敌人们。咱们也很欢送大家一起起来试用体验，并把遇到的问题在gitee上提交issue（提交地址：https://gitee.com/GreatSQL/Gr...），咱们会第一工夫进行反馈和回复。再次感激大家对GreatSQL的反对，让咱们一起打造更好的MySQL社区生态。 接下来说两个要害的、重要的事哈。 1.GreatSQL下载地址GreatSQL二进制包已公布到gitee.com平台上，下载地址：https://gitee.com/GreatSQL/Gr... ，下载的同时，别忘了顺便给加个星(star)，感激哈。 2. GreatSQL测评有礼流动自发稿之日起，只有向咱们提交GreatSQL的应用报告/测评报告/BUG报告，任一形式均可，前5位即可取得流动专属惊喜福利。 不晓得哪些小伙伴能领先拿到呢，让咱们刮目相待。 Enjoy GreatSQL :) 文章举荐：技术分享 | MGR最佳实际(MGR Best Practice) https://mp.weixin.qq.com/s/66... 技术分享 | 万里数据库MGR Bug修复之路https://mp.weixin.qq.com/s/Ia... Macos零碎编译percona及局部函数在Macos零碎上运算差别https://mp.weixin.qq.com/s/jA... 技术分享 | 利用systemd治理MySQL单机多实例https://mp.weixin.qq.com/s/iJ... 产品 | GreatSQL，打造更好的MGR生态https://mp.weixin.qq.com/s/By... 产品 | GreatSQL MGR优化参考https://mp.weixin.qq.com/s/5m... 对于 GreatSQLGreatSQL是由万里数据库保护的MySQL分支，专一于晋升MGR可靠性及性能，反对InnoDB并行查问个性，是实用于金融级利用的MySQL分支版本。 Gitee: https://gitee.com/GreatSQL/Gr... GitHub: https://github.com/GreatSQL/G... 微信&QQ群： 可搜寻增加GreatSQL社区助手微信好友，发送验证信息“加群”退出GreatSQL/MGR交换微信群 QQ群：533341697微信小助手：wanlidbc 本文由博客一文多发平台 OpenWrite 公布！

我集体之所有应用MySQL的这个json个性，最大的起因就是json_contains这个用法，咱们只关注前俩个参数，这个就像咱们说的“海底捞针”，第一个参数是“大海”，第二个参数是“针”，就是判断“大海”外面是否有“针”。 数据表 例一select * from member where json_contains(info, '4'); 特地留神，如果参数不是数据库中的字段的话，肯定要加引号，就算是整型也得加 例二select * from member where json_contains(json_array(1,2,3,4,5,6,7), info); 例三select * from member where json_contains(json_array(21,31,41,51), json_array(age)); 这种用法的后果和in是一样的，也跟后面咱们讲json_array一样，区别在于一个是数据库自身就是array，另外一个是咱们本人创立 json_contains_path这个函数用来判断是否有键名的，我的认识是这个函数根本用不到，数据库后果根本都是提前设计好的，不须要判断。第一个参数判断的指标，第二个参数是one或者all，第三个参数指定的键名，当前的参数都是键名，如果第二个参数是one，则其中一个键名存在则返回正确；如果第二个参数是all，则所有键名都存在才返回正确。例一select * from member where json_contains_path(info, 'one', '$[0]'); 例二select * from member where json_contains_path(info, 'one', '$[3]'); 例三select * from member where json_contains_path(info, 'one', '$.a'); 留言点击留言

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。前情提要：工作中咱们常常有收到这类的需要；比方，只须要将A实例的某个库、某张表同步到B实例上；或者不须要同步某个库、某类表等。 遇到这样的需要如何解决呢？上面列举出几个场景进行阐明。 实际上当咱们在同步库上执行 show slave status\G; 时，会发现MySQL的同步信息外面如下几个同步参数；也就是当咱们建设同步的时候，须要额定指定过滤同步信息即可实现对应需要。 Replicate_Do_DB: # 指定只同步某个库Replicate_Ignore_DB: # 疏忽某个库的同步Replicate_Do_Table: # 指定只同步某个表 Replicate_Ignore_Table: # 疏忽某个表的同步Replicate_Wild_Do_Table: # 指定同步某些表，能够用通配符Replicate_Wild_Ignore_Table: # 疏忽某些表的同步，能够用通配符Replicate_Rewrite_DB: # 从库替换原库名以下场景在MySQL5.7后可动静调整须要先进行SQL线程 STOP SLAVE SQL_THREAD;场景1：只须要同步 3301 实例上的 test 库到 3302 实例上CHANGE REPLICATION FILTER REPLICATE_DO_DB=(test);场景2：只须要同步 3301 实例上的 test 库到 3302 实例上,同时改名为 mytestCHANGE REPLICATION FILTER REPLICATE_DO_DB=(mytest);CHANGE REPLICATION FILTER REPLICATE_REWRITE_DB = ((test,mytest)); 场景3：只须要同步 3301 实例上的 test.t1 表到 3302 实例上CHANGE REPLICATION FILTER REPLICATE_DO_DB=(test);CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE =('test.t1');场景4：只须要同步 3301 实例上的 test 库 t 结尾的所有表 到 3302 实例上CHANGE REPLICATION FILTER REPLICATE_DO_DB=(test);CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE =('test.t*');场景5：如何不同步 3301 实例上的 test 库 到 3302 实例上CHANGE REPLICATION FILTER REPLICATE_IGNORE_DB = (test);如何勾销过滤，间接将同步过滤项设置为空即可，如下举例CHANGE REPLICATION FILTER REPLICATE_DO_DB=();设置实现后开启SQL线程 START SLAVE SQL_THREAD;更多信息能够查看官网阐明 ...

测试数据CREATE TABLE `book_comment` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `user_id` int(10) unsigned NOT NULL, `like_num` int(10) NOT NULL DEFAULT '0' COMMENT '点赞数', `content` varchar(200) NOT NULL, `addtime` datetime NOT NULL, PRIMARY KEY (`id`), KEY `user_id` (`user_id`), KEY `addtime` (`addtime`), KEY `uid_addtime` (`user_id`,`addtime`)) ENGINE=InnoDB;INSERT INTO `book_comment` VALUES ('1', '1', '0', '评论1', '2017-05-17 00:00:00');INSERT INTO `book_comment` VALUES ('2', '1', '2', '评论2', '2017-05-17 00:03:01');INSERT INTO `book_comment` VALUES ('3', '2', '3', '评论3', '2017-05-17 00:03:02');INSERT INTO `book_comment` VALUES ('4', '2', '4', '评论4', '2017-05-17 00:00:03');INSERT INTO `book_comment` VALUES ('5', '3', '0', '评论5', '2017-05-17 00:00:04');INSERT INTO `book_comment` VALUES ('6', '1', '1', '评论6', '2017-05-17 00:00:05');INSERT INTO `book_comment` VALUES ('7', '4', '0', '评论7', '2017-05-17 00:00:06');INSERT INTO `book_comment` VALUES ('8', '4', '2', '评论8', '2017-05-17 00:00:07');INSERT INTO `book_comment` VALUES ('9', '4', '0', '评论9', '2017-05-17 00:00:08');INSERT INTO `book_comment` VALUES ('10', '4', '3', '评论10', '2017-05-17 00:00:09');INSERT INTO `book_comment` VALUES ('11', '3', '2', '评论11', '2017-05-17 00:00:10');1：惯例group语句mysql> SELECT *,count(*) as num from book_comment GROUP BY user_id;+----+---------+----------+---------+---------------------+-----+| id | user_id | like_num | content | addtime | num |+----+---------+----------+---------+---------------------+-----+| 1 | 1 | 0 | 评论1 | 2017-05-17 00:00:00 | 3 || 3 | 2 | 3 | 评论3 | 2017-05-17 00:03:02 | 2 || 5 | 3 | 0 | 评论5 | 2017-05-17 00:00:04 | 2 || 7 | 4 | 0 | 评论7 | 2017-05-17 00:00:06 | 4 |+----+---------+----------+---------+---------------------+-----+依据用户分组，分组内默认显示第一条数据 ...

json_array_append、json_array_insert顾名思义就是向数组中追加和插入值，因为没有找到适合的例子，所以就应用官网的例子进行阐明数据表 json_array_append向指定的地位后追加值例一select json_array_append(info, '$', 1) from member; 特地留神：'$'指的是info字段自身，也能够指定第几项 例二select json_array_append(info, '$[1]', 2) from member; 特地留神：下标不能是正数，会报错，不能超过本来json数量，会被疏忽 例三select json_array_append(info, '$[-1]', 2) from member; 例四select json_array_append(info, '$[100]', 2) from member; json_array_insert向指定的地位前插入值例一select json_array_insert(info, '$[1]', 100) from member; 特地留神：下标同样不能是正数，然而能够超过json数量，超过就是插入到最初 留言点击留言

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答 本文转载自微信公众号 “老叶茶馆” 欢送大家关注！ 1.都有哪些状况可能导致MGR服务无奈启动简略整顿了下，大略有以下起因可能导致MGR服务无奈启动： 1.网络起因，例如网络原本就不通，或被防火墙拦住。防火墙通常至多有两道，操作系统默认的firewall策略，以及云主机被默认的安全策略。2.第一个启动的节点没有先做初始疏导操作（group_replication_bootstrap_group=ON）。3.没有正确配置group_name，所有节点的 group_replication_group_name 值要统一才能够。4.没正确配置 group_replication_group_name，常见于老手。要为MGR服务专门新开一个服务端口，罕用33061端口，但老手可能会照样写成3306端口。5.通常，咱们会在各MGR节点的 hosts 文件里加上所有节点的hostname。这是为了避免本地节点应用的hostname和MGR收到的hostname不统一，这种状况下，能够在每个本地节点设置 report-host，被动上报hostname即可解决。6.没设置正确的allowlist。有可能退出MGR各节点的IP不在默认的allowlist中，可参考这篇文章：MySQL Group Replication集群对IP地址的限度导致的一些问题与解决办法 (https://mp.weixin.qq.com/s/sb...)。7.个别节点的本地事务更多，例如误操作写入数据，也会无奈退出MGR，这种状况须要重建本地节点。8.个别节点的本地事务缺失太多，且退出MGR时无奈主动实现复原，这种状况比拟少见，须要手动执行clone复制数据，或者其余相似操作。更多MGR相干问题请移步到这篇文章：GreatSQL MGR FAQ。(https://mp.weixin.qq.com/s/Bz...) 2. MySQL中怎么晓得一个表的创立工夫来自群友的问题：有中央能够查看到mysql第一次初始化启动的工夫吗？ 这个问题能够换个角度来思考，即：怎么查的实例中MySQL元数据表初始化创立工夫。 至多有两种办法可用： 办法一，查问MySQL日志。如果MySQL实例自从初始化后的日志始终留存着的话，天然能够查到过后的工夫。 办法二， 查问MySQL元数据表。执行相似上面的命令，即可查得该实例初始化的工夫： [root@yejr.run]> SELECT TABLE_NAME, CREATE_TIME, UPDATE_TIME, CHECK_TIME FROM information_schema.TABLES where table_schema='mysql' order by create_time limit 2;+--------------------+---------------------+---------------------+------------+| TABLE_NAME | CREATE_TIME | UPDATE_TIME | CHECK_TIME |+--------------------+---------------------+---------------------+------------+| innodb_table_stats | 2020-02-17 08:21:19 | 2021-11-18 21:50:17 | NULL || innodb_index_stats | 2020-02-17 08:21:19 | 2021-11-18 21:50:17 | NULL |+--------------------+---------------------+---------------------+------------+Enjoy GreatSQL :) ...

json_array顾名思义就是创立一个数组，理论的用法，我目前没有想到很好的应用场景。应用官网的例子阐明一下吧。例一select json_array(1,2,3,4); json_array尽管独自应用的场景没找到，然而联合json_contains查问还是能够的，前面的json_contains会具体讲，这里咱们应用一个简略的例子数据表 例二select * from member where json_contains(json_array(1,2,3,4,5,6,7,8), info); json_containers的用法稍后具体解说，第二个参数必须蕴含第二个参数 留言点击留言

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。试验场景GreatSQL 8.0.25 InnoDB 1.备份,导出单表, test.t_user/usr/bin/xtrabackup -uroot -p'GreatSQL' -S /data/GreatSQL/mysql.sock --tables='test.t_user' --backup --target-dir=/data/backup2.复原备份xtrabackup --prepare --export --target-dir=/data/backup3.建测试表[root@GreatSQL][test02]>CREATE TABLE `t_user` ( -> `id` bigint NOT NULL AUTO_INCREMENT, -> `name` varchar(255) DEFAULT NULL, -> `age` tinyint DEFAULT NULL, -> `create_time` datetime DEFAULT NULL, -> `update_time` datetime DEFAULT NULL, -> PRIMARY KEY (`id`), -> KEY `idx_name` (`name`), -> KEY `idx_age` (`age`) -> ) ENGINE=InnoDB AUTO_INCREMENT=1091002 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;Query OK, 0 rows affected (0.16 sec)4.卸载新表表空间[root@GreatSQL][test02]>ALTER table t_user discard tablespace;Query OK, 0 rows affected (0.11 sec)5.拷贝备份的t_user文件[root@localhost test]# cd /data/backup/test/[root@localhost test2]# cp * /data/GreatSQL/test02/[root@localhost test2]# ll-rw-r--r-- 1 root root 964 Nov 24 04:12 t_user.cfg-rw-r----- 1 root root 18874368 Nov 24 04:10 t_user.ibd6.挂载新表表空间[root@GreatSQL][test02]>ALTER TABLE t_user import tablespace;Query OK, 0 rows affected, 1 warning (0.47 sec)7.查问复原数据[root@GreatSQL][test02]>select count(*) from test02.t_user;+----------+| count(*) |+----------+| 91002 |+----------+1 row in set (0.10 sec)# 旧表的数据[root@GreatSQL][test02]>select count(*) from test.t_user;+----------+| count(*) |+----------+| 91002 |+----------+1 row in set (0.07 sec)(Wed Nov 24 21:35:57 2021)[root@GreatSQL][test02]>Enjoy GreatSQL :) ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。前情提要明天简略介绍下MySQL中有哪些罕用的日志和各个日志的性能。 1、binlog二进制日志：记录SQL的各种变更操作，有Mixed、Statement和ROW 3种格局、不同格局各有优缺点，次要用于复制和数据任意工夫点还原。 二进制日志是SERVER引擎层面产生记录的，也就是说甭管你是、InnoDB、MySIAM或是其余引擎都会记录binlog，除非在配置上给敞开了。 2、error log谬误日志：记录MySQL启动，运行过程，进行中产生的各种错误信息，便于排查故障。 3、slow query log慢日志：记录所有执行工夫超过long_query_time（单位秒）和没有应用到索引的SQL语句。 4、general log个别通用日志：具体记录建设的客户端连贯信息和执行的所有SQL语句，如果你不晓得哪个业务是否有应用，或某个申请来自哪里，能够把general log 开起来就比拟容易查问。 5、relay log中继日志：主从同步过程中，从节点产生的转储日志，用于从节点利用复原。 6、redo log重做日志：InnoDB层产生的，记录物理数据页批改的信息，无效缩小事务提交刷盘的频次升高IO压力，redo log 保障了数据库的crash-safe能力，同时与在线热备份非亲非故。 7、undo log回滚日志：记录数据产生变更前的信息，次要用于回滚，同时提供多版本并发管制下的快照读性能。 更多信息能够查看官网阐明 https://dev.mysql.com/doc/ref... Enjoy GreatSQL :) 本文由博客一文多发平台 OpenWrite 公布！

装置局部Centos7装置mysql5.7.35mysql-5.7.35-linux-glibc2.12-x86_64.tar.gz的rpm包百度网盘链接（635MB）： 链接：https://pan.baidu.com/s/1On8I...提取码：linu环境查看 rpm -qa|grep -i mysql;rpm -e mysql-community-libs-5.7.36-1.el7.x86_64 --nodeps;上传解压创立用户，（如果之前有mysql用户，userdel -r mysql 删除），创立mysql数据库，赋予权限 tar -zxvf mysql-5.7.35-linux-glibc2.12-x86_64.tar.gz;mv mysql-5.7.35-linux-glibc2.12-x86_64 /usr/local/mysql;groupadd mysql;useradd -r -g mysql mysql;mkdir -p /data/mysql;chown mysql:mysql -R /data/mysql;配置/etc/my.cnf文件 vi /etc/my.cnf[mysqld]bind-address=0.0.0.0 #绑定地址运行近程连贯port=3306 #Mysql凋谢的端口user=mysql #登录用户basedir=/usr/local/mysql #Mysql装置的绝对路径datadir=/data/mysql #Mysql数据寄存的绝对路径socket=/tmp/mysql.sock #套接字文件log-error=/data/mysql/mysql.err #mysql生成的谬误日志寄存的门路pid-file=/data/mysql/mysql.pid #为mysqld程序指定一个寄存过程ID的文件character_set_server=utf8mb4 #数据库字符编码symbolic-links=0 #是否反对符号链接，即数据库或表能够存储在my.cnf中指定datadir之外的分区或目录，为0不开启explicit_defaults_for_timestamp=true #timestamp类型的列的自动更新于更新操作工夫点初始化mysql，增加零碎服务到/etc/init.d/mysql 目录下，启动mysql，设置全局变量，如果提醒软连贯文件mysql存在，用 ln -sf 笼罩 cd /usr/local/mysql/bin/./mysqld --defaults-file=/etc/my.cnf --basedir=/usr/local/mysql/ --datadir=/data/mysql/ --user=mysql --initializecp /usr/local/mysql/support-files/mysql.server /etc/init.d/mysqlservice mysql startservice mysql statusln -s /usr/local/mysql/bin/mysql /usr/bin#查看明码cat /data/mysql/mysql.err | grep passwordmysql -u root -p设置明码与近程连贯，默认明码的强度验证等级为OFF SET PASSWORD = PASSWORD('123456');ALTER USER 'root'@'localhost' PASSWORD EXPIRE NEVER;FLUSH PRIVILEGES;USE mysql：UPDATE user SET host = '%' WHERE user = 'root';FLUSH PRIVILEGES;exit;凋谢3306端口 ...

MySQL 数据库当初次要用的引擎是 InnoDB ，InnoDB 没有相似于 MERGE 引擎这样的原生拆表计划，不过有原生分区表，以程度形式拆分记录集，对利用端通明。 分区表的存在为超大表的检索申请、日常治理提供了一种额定的抉择路径。分区表应用切当，对数据库性能会有大幅晋升。 分区表次要有以下几种劣势：大幅晋升某些查问的性能。简化日常数据运维工作量、晋升运维效率。并行查问、平衡写 IO 。对利用通明，不须要在应用层部署路由或者中间层。接下来咱们用理论例子来让前两种劣势体现更新清晰。针对检索来讲：优化查问性能（范畴查问）拆分适合的分区表，对同样的查问来讲，扫描的记录数量要比非分区表少很多，性能远比非分区表来的高效。 以下示例表 t1 为非分区表，对应的分区表为 p1 ，两张表有雷同的纪录数，都为 1KW 条。 localhost:ytt> show create table t1\G*************************** 1. row *************************** Table: t1Create Table: CREATE TABLE `t1` ( `id` int NOT NULL, `r1` date DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci1 row in set (0.00 sec)localhost:ytt> show create table p1\G*************************** 1. row *************************** Table: p1Create Table: CREATE TABLE `p1` ( `id` int NOT NULL, `r1` date DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci/*!50100 PARTITION BY RANGE (`id`)(PARTITION p0 VALUES LESS THAN (1000000) ENGINE = InnoDB, PARTITION p1 VALUES LESS THAN (2000000) ENGINE = InnoDB, PARTITION p2 VALUES LESS THAN (3000000) ENGINE = InnoDB, PARTITION p3 VALUES LESS THAN (4000000) ENGINE = InnoDB, PARTITION p4 VALUES LESS THAN (5000000) ENGINE = InnoDB, PARTITION p5 VALUES LESS THAN (6000000) ENGINE = InnoDB, PARTITION p6 VALUES LESS THAN (7000000) ENGINE = InnoDB, PARTITION p7 VALUES LESS THAN (8000000) ENGINE = InnoDB, PARTITION p8 VALUES LESS THAN (9000000) ENGINE = InnoDB, PARTITION p9 VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */1 row in set (0.00 sec)localhost:ytt> select count(*) from t1;+----------+| count(*) |+----------+| 10000000 |+----------+1 row in set (0.94 sec)localhost:ytt> select count(*) from p1;+----------+| count(*) |+----------+| 10000000 |+----------+1 row in set (0.92 sec)咱们来别离对两张表做范畴检索，以下为执行打算： ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。1、发现问题2、复现问题3、查看导入文件4、问题起因5、解决问题6、总结1、发现问题在一次数据迁徙的工作中，小玲将源端数据库中数据导出为CSV文件，而后通过 load data 导入数据到MySQL，后果惊奇地发现id字段失落了，就像这个样子： mysql> select * from t2;+----+-------+---------------------+| id | col1 | col2 |+----+-------+---------------------+ | || TfdESTA |TESTA |4 | TEfdfdSTA | 5 | TEST5 | TESfddfdsfdsfdsfTA |TEST6 | TESffdfdfddTA+----+-------+---------------------+6 rows in set (0.00 sec)指标数据库版本与表构造如下： mysql> select @@version;+-----------+| @@version |+-----------+| 8.0.25 |+-----------+1 row in set (0.00 sec)mysql> show create table t2;+-------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+| Table | Create Table |+-------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+| t2 | CREATE TABLE `t2` ( `id` int NOT NULL AUTO_INCREMENT, `col1` varchar(69) DEFAULT NULL, `col2` varchar(79) DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci |+-------+----------------------------------------------------------------------------------小玲沉着一下之后，通过以下语句验证了主键id并没有真的失落，仿佛只是呈现了某种显示谬误： ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 引言AppArmor （Debian 系平台）是一款内核级别的平安机制，通过 AppArmor 来让 Linux 零碎实现严格的资源访问控制，相似 SELinux（RedHat 系列平台）。 我本地环境为：OS 版本 Ubuntu 18，DB 版本 MySQL 8.0.27。 AppArmor 通过目录/etc/apparmor.d/ 下的一系列配置文件来别离限度每个过程对 OS 资源的拜访权限。 AppArmor 有两种工作模式： Enforced/Confined: 严格依照配置文件来限度对应的过程拜访OS资源的行为，回绝不在配置范畴内的过程运行。Complaining/Learning: 仅记录过程行为，不对其进行限度。遇到的问题是：我启动 MySQL ，未胜利： root@ytt-ubuntu:~# systemctl start mysqlJob for mysql.service failed because the control process exited with error code.See "systemctl status mysql.service" and "journalctl -xe" for details.我摘出来几条外围的错误信息： root@ytt-ubuntu:~# journalctl -xe-- Defined-By: systemd-- user-122.slice 单元已完结进行操作。11月 16 16:14:00 ytt-ubuntu kernel: audit: type=1400 audit(1637050440.395:101): apparmor="DENIED" operation="mknod" profile="/usr/sbin/mysqld" name="/op11月 16 16:14:00 ytt-ubuntu audit[7237]: AVC apparmor="DENIED" operation="mknod" profile="/usr/sbin/mysqld" name="/opt/mysql/data/mysqld_tmp_file_case_i11月 16 16:14:01 ytt-ubuntu audit[7270]: AVC apparmor="DENIED" operation="mknod" profile="/usr/sbin/mysqld" name="/opt/mysql/log/error.log" pid=7270 com11月 16 16:14:01 ytt-ubuntu systemd[1]: mysql.service: Main process exited, code=exited, status=1/FAILURE11月 16 16:14:01 ytt-ubuntu systemd[1]: mysql.service: Failed with result 'exit-code'.11月 16 16:14:01 ytt-ubuntu systemd[1]: Failed to start MySQL Community Server.-- Subject: mysql.service 单元已失败由错误信息能够看到，AppArmor 阻止了 MySQL 服务启动，可能的起因是启动 MySQL 服务须要拜访的目录在 AppArmor 里没有配置。 ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答Percona XtraBackup个性阐明Percona Xtrabackup 备份复原权限限度创立备份用户、配置参数及数据筹备全量备份与复原增量备份压缩备份流备份1. Percona XtraBackup 个性阐明1)Percona Xtrabackup 8.0.26新增反对MyRocks存储引擎，不反对TokuDB引擎 2)Percona Xtrabackup 8.0.26 不反对低于MySQL 8.0的备份（因为MySQL 8.0在数据字典、redo log中和之前版本不兼容） 3)Percona Xtrabackup 8.0.26 目前X86版本能够从官网下载，ARM版本须要手动编译 4)备份文件必须是空的，没有任何文件 2. Percona Xtrabackup 备份复原权限限度1)备份门路须要有可读写权限 2)reload和Lock Tables（指定--no-locak选项除外），因为备份前须要执行FLUSH TABLES WITH READ LOCK和FLUSH ENGINE LOGS 3)Backup_admin权限,因为备份时须要查问performance_schema.log_status表并运行LOCK INSTANCE FOR BACKUP, LOCK BINLOG FOR BACKUP, or LOCK TABLES FOR BACKUP 4)Replication client权限。备份时为了读取二进制日志文件 5)Create tablespace权限。复原表时须要创立表 6)Process权限。备份时须要运行show engine innodb status命令 7)Super权限。为了在复制环境中启动/进行复制线程 8)Create权限。为了创立percona_schema.xtrbackup_history表 9)Alter权限。为了更新percona_schema.xtrbackup_history表 10)Insert权限。为了将历史记录插入到percona_schema.xtrbackup_history表 11)Select权限。为了查问历史数据 3. 创立备份用户、配置参数及数据筹备 //创立用户 mysql > CREATE USER 'bkpuser' @ 'localhost' IDENTIFIED BY 's3cr%T' ; mysql > GRANT BACKUP_ADMIN,PROCESS,RELOAD,LOCK TABLES,REPLICATION CLIENT ON *.* TO 'bkpuser' @ 'localhost' ; mysql > GRANT SELECT ON performance_schema.log_status TO 'bkpuser' @ 'localhost' ; Mysql > GRANT SELECT ON performance_schema.keyring_component_status TO bkpuser @ 'localhost' mysql > FLUSH PRIVILEGES ;配置参数，Xtrbackup在备份时会读取MySQL的my.cnf配置文件中[mysqld]和[xtrabackup]局部，所以咱们能够在配置文件中设置备份的目录[xtrabackup],target_dir = /data/backups/mysql ...

MySQL 团队开发标准1、数据库对象命名标准数据库对象数据库对象全局命名标准数据库命名标准表命名标准字段命名标准索引命名标准视图命名标准存储过程命名标准函数命名标准触发器命名标准束缚命名标准用户命名标准2、数据库对象设计规范存储引擎的抉择字符集的抉择表设计规范字段设计规范索引设计规范束缚设计规范3、SQL应用标准select 检索的规范性操作的规范性4、程序上的束缚一、数据库对象命名标准1、数据库对象数据库对象是数据库的组成部分，常见的有以下几种：表（Table ）、索引（Index）、视图（View）、图表（Diagram）、缺省值（Default）、规定（Rule）、触发器（Trigger）、存储过程（Stored Procedure）、 用户（User）等。命名标准是指数据库对象如数据库（SCHEMA）、表（TABLE）、索引（INDEX）、束缚（CONSTRAINTS）等的命名约定。 2、数据库对象全局命名标准1、命名应用具备意义的英文词汇，词汇两头以下划线分隔 2、命名只能应用英文字母、数字、下划线，以英文字母结尾 3、防止用MySQL的保留字如：backup、call、group等 4、所有数据库对象应用小写字母，实际上MySQL中是能够设置大小写是否敏感的，为了保障统一性，咱们这边标准全副小写示意。 3、数据库命名标准1、数据库命名尽量不超过30个字符。 2、数据库命名个别为项目名称+代表库含意的简写，比方IM我的项目的工作流数据库，能够是 im_flow。 3、数据库创立时必须增加默认字符集和校对规定子句。默认字符集为UTF8（已迁徙dumbo的应用utf8mb4） 4、命名应应用小写。 4、表命名标准1、惯例表表名以t_结尾，t代表table的意思，命名规定即 t + 模块（蕴含模块含意的简写）+ 表（蕴含表含意的简写），比方用户模块的教育信息表：t_user_eduinfo。 2、长期表（RD、QA或DBA同学用于数据长期解决的表），命名规定：temp前缀+模块+表+日期后缀：temp_user_eduinfo_20210719 3、备份表（用于保留和归档历史数据或者作为灾备复原的数据）命名规定，bak前缀+模块+表+日期后缀：bak_user_eduinfo_20210719 4、同一个模块的表尽可能应用雷同的前缀，表名称尽可能表白含意 5、多个单词以下划线 _ 分隔 6、惯例表表名尽量不超过30个字符，temp表和bak表视状况而定，也尽量简短为宜，命名应应用小写 5、字段命名标准1、字段命名须要示意其理论含意的英文单词或简写，单词之间用下划线 _ 进行连贯，如 service_ip、service_port。 2、各表之间雷同意义的字段必须同名，比方a表和b表都有创立工夫，应该对立为create_time，不统一会很凌乱。 3、多个单词以下划线 _ 分隔 4、字段名尽量不超过30个字符，命名应该应用小写 6、索引命名标准1、惟一索引应用uni + 字段名 来命名：create unique index uni_uid on t_user_basic(uid) 。 2、非惟一索引应用idx + 字段名 来命名：create index idx_uname_mobile on t_user_basic(uname,mobile) 。 3、多个单词以下划线 _ 分隔。 4、索引名尽量不超过50个字符，命名应该应用小写，组合索引的字段不宜太多，不然也不利于查问效率的晋升。 5、多单词组成的列名，取尽可能代表意义的缩写，如 test_contact表member_id和friend_id上的组合索引：idx_mid_fid。 6、了解组合索引最左前缀准则，防止反复建设索引，如果建设了(a,b,c)，相当于建设了(a), (a,b), (a,b,c)。 7、视图命名标准1、视图名以v结尾，示意view，残缺构造是v+视图内容含意缩写。 2、如果视图只起源单个表，则为v+表名。如果视图由几个表关联产生就用v+下划线（_）连贯几个表名，视图名尽量不超过30个字符。如超过30个字符则取简写。 3、如无非凡须要，严禁开发人员创立视图。 4、命名应应用小写。 8、存储过程命名标准1、存储过程名以sp结尾，示意存储过程（storage procedure）。之后多个单词以下划线（_）进行连贯。存储过程命名中应体现其性能。存储过程名尽量不能超过30个字符。 2、存储过程中的输出参数以i_结尾，输入参数以o_结尾。 ...

先说一些废话很多时候深刻学习诚然很重要，然而想要写下一篇给老手都能看得懂看的很香，并且老鸟能够查漏补缺的的练习博客，还是挺有难度，所以明天尝试写一些对于MySQL的语句练习大全，供想要从零开始练习MySQL的老手们去学习。 须要留神的是写代码是一种脑力和操作并行的技术，倡议没怎么写过SQL的人肯定要先从命令行的语句练习开始，这样才可能更好的加深印象！！！ 所有的语句我会写一些根本的正文，须要深刻学习的童鞋能够参考单个知识点持续理解。 当然明天列出的所有语句都有测试过，然而不确保没有手误打错的时候，如果有什么谬误的中央请在评论区指出，非常感谢！！！ 提示信息：本文测试所应用的MySQL版本是5.7.26 其余废话不多说间接上代码连贯MySQL# 用户名和明码要紧跟-u-p不能有空格mysql -u用户名 -p明码# 如果不想明文显示明码，执行命令后会提醒输出明码，并且不会明文显示明码mysql -u 用户名 -p数据库# 查看所有的数据库SHOW DATABASES;# 创立一个数据库CREATE DATABASE test;# 删除一个数据库DROP DATABASE test;# 应用数据库USE test;表# 查看所有的表SHOW TABLES;# =======================================================# 知识点提醒！！！# 主键束缚（PRIMARY KEY）：没有明确的概念定义，是唯一性索引的一种，不能反复，一个表只能有一个主键# 主动减少（AUTO_INCREMENT）：主动减少（须要和主键PRIMARY KEY一起应用）# 非空束缚（NOT NULL）：要求被装璜的字段非空# 外键束缚（FOREIGN KEY）：用来在表与表的数据之间建设链接，它能够是一列或者多列 # 举个栗子帮忙了解：班级表，10个班级，年级表，6个年级，每个班级只能所属1个年级，# 且必须是这6个年级中的1个，这个时候班级表就须要用年级表来建设外键，确保数据统一且残缺 # 惟一束缚（UNIQUE KEY）：指所有记录中的字段的值不能反复呈现，能够联结非空UNIQUE(字段1，字段2) # 数据类型，务必深刻理解，对数据库的优化十分重要 # AS 别名或者连贯语句的操作符# =======================================================# 创立一个表，领有主键CREATE TABLE test(id INT, name VARCHAR(10), PRIMARY KEY (id));# 创立另一个表，领有主键，并蕴含前一个表的外键束缚，以及惟一束缚 CREATE TABLE test_key(id INT, name VARCHAR(10), PRIMARY KEY (id), FOREIGN KEY (id) REFERENCES test(id), UNIQUE (name));# 间接将查问后果导入或复制到，一个新创建的表CREATE TABLE test_copy SELECT * FROM test;CREATE TABLE test_copy_as AS SELECT * FROM test;# 将一个已存在表的数据结构克隆到，一个新创建的表CREATE TABLE test_clone LIKE test;# 创立一个长期表，各种形式 # 长期表将在你连贯MySQL期间存在，当断开连接时，MySQL将主动删除表并开释所用的空间，也可手动删除。CREATE TEMPORARY TABLE test_tem(id INT, name VARCHAR(10));CREATE TEMPORARY TABLE test_tem_copy SELECT * FROM test;# 删除一个存在表DROP TABLE IF EXISTS test;# 更改存在表的名称ALTER TABLE test RENAME test_rename;RENAME TABLE test_rename TO test;# 查看表的构造# 以下五条语句成果雷同，举荐第一条，因为简略 DESC test;DESCRIBE test;SHOW COLUMNS IN test;SHOW COLUMNS FROM test;EXPLAIN test;# 查看表的创立语句SHOW CREATE TABLE test;表构造# 增加表字段ALTER TABLE test ADD age VARCHAR(2);# 删除表字段ALTER TABLE test DROP age;# 更改表字段和表字段属性ALTER TABLE test CHANGE age age_change INT;# 只更改表字段属性ALTER TABLE test MODIFY age VARCHAR(7);# 查问所有表信息SHOW TABLE STATUS;表数据# 减少表数据INSERT INTO test VALUES (1, 'alpha', '24'), (2, 'beta', '25'), (3, 'delta', '27');# =======================================================# 因为test表设置了主键无奈用上面这种形式减少，前两个语句先重建一张表CREATE TABLE test_insert(id INT, name VARCHAR(8));INSERT INTO test_insert VALUES (1, 'alpha'), (2, 'beta'); # =======================================================# 减少查问之后的表数据 INSERT INTO test_insert SELECT * FROM test_insert;# 删除表数据DELETE FROM test_insert WHERE id = 2;# 更改表数据UPDATE test_insert SET name = 'delta' WHERE id = 1;# =======================================================# 为了上面的查问语句可能更直观一些咱们再插入一些数据并把age_change的表字段改为ageINSERT INTO test VALUES (10, 'gamma', '39'), (6, 'zeta', '30'), (19, 'theta', '10'), (8, 'eta', '20'), (46, 'zeta', '11'), (56, 'zeta', '9'), (66, 'zeta', '3');ALTER TABLE test CHANGE age_change age VARCHAR(20);# =======================================================# =======================================================# 知识点提醒！！！# SELECT DISTINCT * FROM '表名' WHERE '限度条件' GROUP BY '分组根据' HAVING '过滤条件' # ORDER BY LIMIT '展现条数' OFFSET '跳过的条数'# 以上关键字应用程序不能谬误，否则会产生错误信息# DISTINCT 去重，留神如果是多个表字段去重，只有每个表字段都雷同才会认为雷同# * 代表通配符，会返回所有字段数据# WHERE 语句用来蕴含查问条件，对原始记录过滤# HAVING 语句也是用来蕴含查问条件，然而HAVING是对WHERE查问分组之后的记录持续过滤# ORDER BY 排序默认正序也就是升序，DESC示意反序也就是降序# LIMIT 属性来设定返回的记录数，个别用于列表的分页# OFFSET 属性来设定跳过的返回的记录数，个别配合LIMIT# =======================================================# 查找表数据SELECT * FROM test;# 查问去除反复数据之后的表数据SELECT DISTINCT name FROM test;# 依据表字段查找表数据SELECT * FROM test WHERE name = 'zeta';# 查找name为zeta并且id大于30的表数据SELECT * FROM test WHERE name = 'zeta' HAVING id > 30;# 依据id分组查问age小于20的表数据SELECT * FROM test GROUP BY id HAVING age < 20;# 查找依据name排序之后的表数据SELECT * FROM test ORDER BY name;# 查找依据name反序排序之后的表数据SELECT * FROM test ORDER BY name DESC; # =======================================================# 留神上面这个排序，如果排序的第一个字段所有值都不同，那么第二列排序就没有意义了，# 所以咱们之前退出了一些name雷同的值，所以能够咱们能够看下zeta字段的age排序# =======================================================# 查找先依据name排序，再依据age排序之后的表数据SELECT * FROM test ORDER BY name, age;# 查找先依据age反序，再依据name排序之后，年龄最大的前三位的表数据SELECT * FROM test ORDER BY age DESC, name LIMIT 3;# 查找先依据age反序，再依据name排序之后，年龄最大的前三位，并跳过第一条的表数据SELECT * FROM test ORDER BY age DESC, name LIMIT 3 OFFSET 1;SELECT * FROM test ORDER BY age DESC, name LIMIT 1,3;# 应用正则查问name表字段中蕴含字母g的表数据SELECT * FROM test WHERE name regexp '.*[g]+.*';表数据 —— 连贯查问# =======================================================# 为了不便大家更为直观的看到连贯查问的成果，我再从新建一个用于连贯的表CREATE TABLE test_join(id INT, join_name VARCHAR(20), join_desc VARCHAR(100));INSERT INTO test_join VALUES (10, 'join_a', 'desc_a'), (11, 'join_b', 'desc_b'), (10, 'gamma', 'join_gamma');# =======================================================# =======================================================# 解释一下上面的内连贯查问为什么会有三种# 第一种为不设置别名的写法# 第二种为简写AS设置别名的写法# 第三种为有AS关键字设置别名的写法# 后续均应用第二种写法# =======================================================# 内连贯查问# 留神JOIN连贯默认应用内连贯SELECT * FROM test INNER JOIN test_join ON test.id = test_join.id;SELECT * FROM test m INNER JOIN test_join ON m.id = n.id;SELECT * FROM test AS m INNER JOIN test_inert AS n ON m.id = n.id;# 左外连贯查问SELECT * FROM test m LEFT JOIN test_join n ON m.id = n.id;# 左外连贯查问，左表独有数据SELECT * FROM test m LEDT JOIN test_join n ON m.id = n.id WHERE n.id IS NULL;# 右外连贯查问SELECT * FROM test m RIHGT JOIN test_join n ON m.id = n.id;# 右外连贯查问，右表独有数据SELECT * FROM test m RIGHT JOIN test_join n ON m.id = n.id WHERE m.id IS NULL;# 穿插连贯查问，又叫笛卡尔连贯SELECT * FROM test CROSS JOIN test_join;SELECT * FROM test,test_join;# 全连贯查问 # UNION默认不返回反复的数据，UNION ALL则会返回反复的数据SELECT id,name FROM test UNION SELECT id,join_name FROM test_join;SELECT id,name FROM test UNION ALL SELECT id,join_name FROM test_join;键# =======================================================# 这里是指定主键束缚名的增加和删除形式，然而主键只能有一个，所以感觉主键指定名称貌似有点多余？ALTER TABLE test ADD CONSTRAINT pk_test PRIMARY KEY (id);ALTER TABLE test DROP PRIMARY KEY `pk_test`;# =======================================================# 增加主键ALTER TABLE test ADD PAIMARY KEY (id);# 删除主键ALTER TABLE test DROP PRIMARY KEY;# =======================================================# 知识点提醒！！！# 不指定外键束缚名，会主动生成一个，然而不晓得怎么查出来，# 有人说用SHOW CREATE TABLE 表名 能够查问进去然而我测试了一下不行# 这个问题先放着，前期我来填坑# =======================================================# =======================================================# 外键增删改查，都要通过外键的束缚名，创立时尽量留神写外键的束缚名，# 所以不倡议上面这种不指定外键束缚名的形式ALTER TABLE test ADD FOREIGN KEY (id) REFERENCES test_join(id);# =======================================================# =======================================================# 建两个表用于测试CREATE TABLE test_key(id INT, key_name VARCHAR(20), PRIMARY KEY(id));CREATE TABLE test_foreign_key(id INT, foreign_key_name VARCHAR(20), PRIMARY KEY(id));# =======================================================# 增加外键ALTER TABLE test_key ADD CONSTRAINT fk_id FOREIGN KEY (id) REFERENCES test_foreign_key(id);# 删除外键ALTER TABLE test_key DROP FOREIGN KEY `fk_id`;# 批改外键ALTER TABLE test_key DROP FOREIGN KEY `fk_id`, ADD CONSTRAINT fk_id_new FOREIGN KEY (id) REFERENCES test_foreign_key(id);# 增加惟一键# 这种不指定惟一键束缚名的形式，能够用SHOW CREATE TABLE 查看束缚名ALTER TABLE test_key ADD UNIQUE(key_name);# 增加惟一键，指定键名ALTER TABLE test_key ADD UNIQUE un_name (name);ALTER TABLE test_key ADD UNIQUE INDEX un_name (name);ALTER TABLE test_key ADD CONSTRAINT un_name UNIQUE (name);CREATE UNIQUE INDEX un_name ON test_key(name);# 删除惟一键DROP INDEX un_name ON test_key;# 增加索引ALTER TABLE test_key ADD INDEX (key_name);# 增加索引，指定索引名ALTER TABLE test_key ADD INDEX in_name (key_name);CREATE INDEX in_name ON test_key(key_name);# 删除索引DROP INDEX in_name ON test_key;函数# =======================================================# 聚合函数# =======================================================# 求总数SELECT count(id) AS total FROM test;# 求和SELECT sum(age) AS total_age FROM test;# 求平均值SELECT avg(age) AS avg_age FROM test;# 求最大值SELECT max(age) AS max_age FROM test;# 求最小值SELECT min(age) AS min_age FROM test;# =======================================================# 数学函数# =======================================================# 绝对值：8SELECT abs(-8);# 二进制：1010，八进制：12，十六进制：ASELECT bin(10), oct(10), hex(10);# 圆周率：3.141593SELECT pi();# 大于x的最小整数值：6SELECT ceil(5.5);# 小于x的最大整数值：5SELECT floor(5.5);# 返回汇合中最大的值：86SELECT greatest(13, 21, 34, 41, 55, 69, 72, 86);# 返回汇合中最小的值：13SELECT least(13, 21, 34, 41, 55, 69, 72, 86);# 余数：3SELECT mod(1023, 10);# 返回0-1内的随机值，每次不一样SELECT rand();# 提供一个参数生成一个指定值SELECT rand(9); # 0.406868412538309SELECT rand('test123'); # 0.15522042769493574# 四舍五入：1023SELECT round(1023.1023);# 四舍五入，保留三位数：1023.102SELECT round(1023.1023, 3);# 四舍五入整数位：SELECT round(1023.1023, -1); # 1020SELECT round(1025.1025, -1); # 1030，留神和truncate的区别# 截短为3位小数：1023.102SELECT truncate(1023.1023, 3);# 截短为-1位小数：1020SELECT truncate(1023.1023, -1); # 1020SELECT truncate(1025.1025, -1); # 1020，留神和round的区别# 符号的值的符号(正数，零或正)对应-1，0或1SELECT sign(-6); # -1SELECT sign(0); # 0SELECT sign(6); # 1# 平方根：10SELECT sqrt(10);# =======================================================# 字符串函数# =======================================================# 连贯字符串 'fx67ll'SELECT concat('f', 'x', '67', 'll');# 用分隔符连贯字符串 'fx67ll'，留神如果分隔符为NULL，则后果为NULLSELECT concat_ws('-', 'fx', '6', '7', 'l', 'l'); # fx-6-7-l-lSELECT concat_ws(NULL, 'fx', '6', '7', 'l', 'l'); # NULL# 将字符串 'fx67ll' 从3地位开始的2个字符替换为 '78'SELECT insert('fx67ll', 3, 2, '78'); # fx78ll# 返回字符串 'fx67ll' 右边的3个字符：fx6SELECT left('fx67ll', 3);# 返回字符串 'fx67ll' 左边的4个字符: 67llSELECT right('fx67ll', 4);# 返回字符串 'fx67ll' 第3个字符之后的子字符串：67llSELECT substring('fx67ll', 3);# 返回字符串 'fx67ll' 倒数第3个字符之后的子字符串：7llSELECT substring('fx67ll', -3);# 返回字符串 'fx67ll' 第3个字符之后的2个字符：67SELECT substring('fx67ll', 3, 2);# 切割字符串 ' fx67ll ' 两边的空字符，留神字符串左右有空格：'fx67ll'SELECT trim(' fx67ll ');# 切割字符串 ' fx67ll ' 右边的空字符：'fx67ll 'SELECT ltrim(' fx67ll ');# 切割字符串 ' fx67ll ' 左边的字符串：' fx67ll'SELECT rtrim(' fx67ll ');# 反复字符 'fx67ll' 三次：fx67llfx67llfx67llSELECT repeat('fx67ll', 3);# 对字符串 'fx67ll' 进行反向排序：ll76xfSELECT reverse('fx67ll');# 返回字符串的长度：6SELECT length('fx67ll');# 对字符串进行大小写解决，大小写各两种形式SELECT upper('FX67ll'); # FX67LLSELECT lower('fx67LL'); # fx67llSELECT ucase('fX67Ll'); # FX67LLSELECT lcase('Fx67lL'); # fx67ll# 返回 'f' 在 'fx67ll' 中的第一个地位：1SELECT position('f' IN 'fx67ll');# 返回 '1' 在 'fx67ll' 中的第一个地位，不存在返回0：0SELECT position('1' IN 'fx67ll');# 比拟字符串，第一个参数小于第二个返回正数，否则返回负数，相等返回0SELECT strcmp('abc', 'abd'); # -1SELECT strcmp('abc', 'abb'); # 1SELECT strcmp('abc', 'abc'); # 0# =======================================================# 工夫函数# =======================================================# 返回以后日期，工夫，日期工夫SELECT current_date, current_time, now();# 返回以后工夫的时，分，秒SELECT hour(current_time), minute(current_time), second(current_time);# 返回以后日期的年，月，日SELECT year(current_date), month(current_date), day(current_date);# 返回以后日期的季度SELECT quarter(current_date);# 返回以后月份的名称，以后星期的名称SELECT monthname(current_date), dayname(current_date);# 返回以后日在星期的天数，以后日在月的天数，以后日在年的天数SELECT dayofweek(current_date), dayofmonth(current_date), dayofyear(current_date);# =======================================================# 控制流函数# ======================================================= # IF判断：1SELECT IF(2>1, '1', '0') # 1# IFNULL判断# 判断第一个表达式是否为NULL，如果为NULL则返回第二个参数的值，否则返回第一个参数的值SELECT IFNULL(NULL, 1); # 1SELECT IFNULL('fx67ll', 0); # fx67ll# ISNULL判断# 承受1个参数，并测试该参数是否为NULL，如果参数为NULL，则返回1，否则返回0SELECT ISNULL(1); # 0SELECT ISNULL(1/0); # 1# NULLIF判断# 承受2个参数，如果第1个参数等于第2个参数，则返回NULL，否则返回第1个参数SELECT NULLIF('fx67ll', 'fx67ll'); # NULLSELECT NULLIF('fx67ll', 'll76xf'); # fx67ll# NULLIF相似于上面的CASE表达式CASE WHEN expression_1 = expression_2 THEN NULLELSE expression_1END;# CASE判断：secondSELECT CASE 2 WHEN 1 THEN 'first' WHEN 2 THEN 'second' WHEN 3 THEN 'third' ELSE 'other' END;# =======================================================# 零碎信息函数# =======================================================# 显示以后数据库名SELECT database();# 显示以后用户idSELECT connection_id();# 显示以后用户SELECT user();# 显示以后mysql版本SELECT version();# 返回上次查问的检索行数SELECT found_rows();视图# 创立视图CREATE VIEW v AS SELECT id,name FROM test;CREATE VIEW sv(sid,sname) AS SELECT id,name FROM test;# =======================================================# 知识点提醒！！！# MySQL视图规定FROM关键字前面不能蕴含子查问# 批改了视图对基表数据会有影响，反之，批改了基表数据对视图也会有影响# =======================================================# 查看创立视图语句SHOW CREATE VIEW v;# 查看视图构造DESC v;DESCRIBE v;SHOW COLUMNS IN v;SHOW COLUMNS FROM v;EXPLAIN v;# 查看视图数据SELECT * FROM v;# 批改视图CREATE OR REPLACE VIEW v AS SELECT name,age FROM test;ALTER VIEW v AS SELECT age FROM test;# 删除视图DROP v IF EXISTS v;# =======================================================# 知识点提醒！！！# 应用视图的益处：# 1. 平安，只查问须要的数据 # 2. 性能，防止过多应用JOIN查问 # 3. 灵便，放弃应用一些过旧的表 # =======================================================存储过程# 因为存储过程比拟灵便，这里不写具体示例，次要写一些定义语法 # 申明语句结束符DELIMITER $$# =======================================================# 知识点提醒！！！# 下面的($$)结束符能够本人定义，MySQL中默认是; # =======================================================# 申明存储过程CREATE PROCEDURE 存储过程名( [IN | OUT | INOUT] 参数 数据类型)# =======================================================# 知识点提醒！！！# IN 输出参数 OUT 输入参数 INOUT 输入输出参数 # =======================================================# 申明存储函数CREATE FUNCTION 存储函数名(参数 数据类型)# 申明存储过程开始和完结BEGIN ...... END# 申明变量DECLARE 变量名 变量类型 默认值# 变量赋值SET @变量名 = 值# 调用存储过程CALL 存储过程名(传参)# 正文-- 正文体# 查看存储过程的具体SHOW CREATE PROCEDURE 数据库.存储过程名 # 批改存储过程ALTER PROCEDURE# 删除存储过程DROP PROCEDURE# =======================================================# 知识点提醒！！！# 把过多的业务逻辑写在存储过程汇中不利于保护治理，# 除了个别对业务性能要求较高的业务，其余的必要性不是很大 # =======================================================备份还原# 备份命令# 选项参考下方列表内容mysqldump [选项] 数据库名 [表名] > 脚本名mysqldump [选项] --数据库名 [选项 表名] > 脚本名# 备份所有数据库命令mysqldump [选项] --all-databases [选项] > 脚本名# =======================================================# 知识点提醒！！！# 下方在导入备份数据库前，db_name如果没有，是须要创立的，# 而且与db_name.db中数据库名是一样的才能够导入# =======================================================# 零碎行还原命令mysqladmin -uroot -p create db_name mysql -uroot -p db_name < /backup/mysqldump/db_name.db# source还原命令mysql > use db_namemysql > source /backup/mysqldump/db_name.db# =======================================================# 知识点提醒！！！# 不同的业务场景与规模有不同的备份策略 # 双机热备：通过日志文件来传输服务器上的数据变动，主服务器上数据被更新时触发，# 传输相应的日志文件到从服务器，并通过日志文件，作出相应的操作 # =======================================================备份命令选项阐明参数名缩写含意--host-h服务器IP地址--port-P服务器端口号--user-uMySQL用户名--password-pMySQL明码--databases 指定要备份的数据库--all-databases 备份MySQL服务器上的所有数据库--compact 压缩模式，产生更少的输入--comments 增加正文信息--complete-insert 输入实现的插入语句--lock-tables 备份前，锁定所有数据库表--no-create-db/--no-create-info 禁止生成创立数据库语句--force 当呈现谬误时依然持续备份操作--default-character-set 指定默认字符集--add-locks 备份数据库表时锁定数据库表用户用户权限是十分敏感的一类操作，须要十分小心的应用，所以这里只介绍批改明码的罕用操作，其余操作请在残缺理解过MySQL权限零碎之后再作尝试 您能够参考这篇文章 -- Mysql用户与权限操作系统学习MySQL用户与权限 ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答[toc] 对于GreatSQL及MGR的FAQ，继续更新中。 Last Update: 2021.12.10。 0. GreatSQL简介GreatSQL是由万里数据库保护的MySQL分支，开源、收费。GreatSQL基于Percona Server，在其根底上进一步晋升MGR（MySQL Group Replication）的性能及可靠性。此外，GreatSQL合并了华为鲲鹏计算团队奉献的Patch，实现了InnoDB并行查问个性，以及对InnoDB事务锁的优化。 GreatSQL能够作为MySQL或Percona Server的可选代替计划，用于线上生产环境。 GreatSQL完全免费并兼容MySQL或Percona Server。 1. GreatSQL的特色有哪些绝对于MySQL官网社区版，GreatSQL有以下几个劣势： InnoDB性能更好 反对InnoDB并行查问，TPC-H测试中均匀晋升聚合剖析型SQL性能15倍，最高晋升40多倍。优化InnoDB事务锁，tps性能可晋升约10%。MGR更牢靠、稳固，性能也更好。 MGR中引入天文标签个性，次要用于解决多机房数据同步的问题。MGR中优化了流控算法，运行更加安稳。解决磁盘空间爆满时导致MGR集群阻塞的问题。解决MGR多主模式下或切主时可能导致丢数据的问题。解决节点异样退出MGR集群时导致性能抖动的问题。MGR节点异样状态判断更欠缺。从新设计MGR事务认证队列清理算法，不复存在每隔60秒性能抖动的问题。修复了recovery过程中长时间期待的问题。修复了传输大数据可能导致逻辑判断死循环问题。修复了多数派节点不同类型异样退出集群导致的视图更新的问题。无论是更牢靠的MGR还是性能更好的InnoDB，都值得将以后的MySQL或Percona Server降级到GreatSQL。 对于GreatSQL的劣势可浏览上面几篇文章： GreatSQL 更新阐明 8.0.25GreatSQL重磅个性，InnoDB并行并行查问优化测试面向金融级利用的GreatSQL正式开源2. GreatSQL在哪里能够下载二进制包、RPM包二进制包下载地址：https://gitee.com/GreatSQL/GreatSQL/releases。 目前提供CentOS 7、CentOS 8两种操作系统，以及X86和ARM两种不同架构下的二进制包、RPM包。 带 minimal 关键字的安装包是对二进制文件进行strip后，所以文件尺寸较小，性能上没本质区别，仅是不反对gdb debug性能，能够放心使用。 源码能够间接用git clone的形式下载GreatSQL源码，例如： # 可从gitee下载$ git clone https://gitee.com/GreatSQL/GreatSQL.git# 或从github下载$ git clone https://github.com/GreatSQL/GreatSQL.gitAnsible安装包GreatSQL提供Ansible一键安装包，可在gitee或github下载： https://gitee.com/GreatSQL/Gr...https://github.com/GreatSQL/G...Docker镜像GreatSQL提供Docker镜像，可间接从docker hub拉取： # 间接下载最新版本$ docker pull docker.io/greatsql/greatsql# 或自行指定版本$ docker pull docker.io/greatsql/greatsql:8.0.25# 或指定ARM版本$ docker pull docker.io/greatsql/greatsql:8.0.25-aarch643. 应用GreatSQL遇到问题时找谁应用GreatSQL过程中如果遇到问题，可将问题细节整顿分明后，分割GreatSQL社区寻求帮忙。 QQ群：533341697 微信小助手：wanlidbc 4. GreatSQL版本打算是怎么的GreatSQL不打算每个小版本都追随，暂定奇数版本追随形式，即 8.0.25、8.0.27、8.0.29 ... 以此类推。 将来若有版本打算变更咱们再更新。 5. GreatSQL反对读写拆散吗能够利用MySQL Router来实现读写拆散。 ...

mongodb 3.0和之前版本的explain执行打算有十分微小的差距，这里只学习介绍3.0当前的用法 反对查看以下几种操作的执行打算 根本的应用形式db.collection.find().explain(verbose)verbose是explain执行打算的输入模式有以下三种 queryPlanner这是explain的默认输入形式 蕴含执行打算的根本详情信息，蕴含：查问打算、汇合信息、查问条件、最佳执行打算、查问形式和mongodb的根底信息 executionStats这种输入形式会在queryPlanner的根底上输入最佳执行打算的一些统计信息 allPlansExecution获取所有的执行打算，也就是把汇合中所有的每一种索引都生成一个执行打算内容，给与用户判断 详解explain字段样例上面是allPlansExecution模式下输入的执行打算，也蕴含了其它两种模式会输入的内容 { "queryPlanner":{ "plannerVersion":1, "namespace":"mock.users", "indexFilterSet":false, "parsedQuery":{ "age":{ "$gte":10 } }, "winningPlan":{ "stage":"FETCH", "inputStage":{ "stage":"IXSCAN", "keyPattern":{ "age":1, "username":1 }, "indexName":"age_1_username_1", "isMultiKey":false, "multiKeyPaths":{ "age":[ ], "username":[ ] }, "isUnique":false, "isSparse":false, "isPartial":false, "indexVersion":2, "direction":"forward", "indexBounds":{ "age":[ "[10, inf.0]" ], "username":[ "[MinKey, MaxKey]" ] } } }, "rejectedPlans":[ { "stage":"FETCH", "inputStage":{ "stage":"IXSCAN", "keyPattern":{ "age":1 }, "indexName":"age_1", "isMultiKey":false, "multiKeyPaths":{ "age":[ ] }, "isUnique":false, "isSparse":false, "isPartial":false, "indexVersion":2, "direction":"forward", "indexBounds":{ "age":[ "[10, inf.0]" ] } } } ] }, "executionStats":{ --这个汇合是executionStats&allPlansExecution模式才有的 "executionSuccess":true, "nReturned":680520, "executionTimeMillis":1121, "totalKeysExamined":680520, "totalDocsExamined":680520, "executionStages":{ "stage":"FETCH", "nReturned":680520, "executionTimeMillisEstimate":143, "works":680521, "advanced":680520, "needTime":0, "needYield":0, "saveState":680, "restoreState":680, "isEOF":1, "docsExamined":680520, "alreadyHasObj":0, "inputStage":{ "stage":"IXSCAN", "nReturned":680520, "executionTimeMillisEstimate":43, "works":680521, "advanced":680520, "needTime":0, "needYield":0, "saveState":680, "restoreState":680, "isEOF":1, "keyPattern":{ "age":1, "username":1 }, "indexName":"age_1_username_1", "isMultiKey":false, "multiKeyPaths":{ "age":[ ], "username":[ ] }, "isUnique":false, "isSparse":false, "isPartial":false, "indexVersion":2, "direction":"forward", "indexBounds":{ "age":[ "[10, inf.0]" ], "username":[ "[MinKey, MaxKey]" ] }, "keysExamined":680520, "seeks":1, "dupsTested":0, "dupsDropped":0 } }, "allPlansExecution":[ --这是allPlansExecution执行才会有的返回汇合 { "nReturned":101, "executionTimeMillisEstimate":0, "totalKeysExamined":101, "totalDocsExamined":101, "executionStages":{ ....... } } ] }, "serverInfo":{ "host":"supman", "port":27017, "version":"4.4.10", "gitVersion":"58971da1ef93435a9f62bf4708a81713def6e88c" }, "ok":1}详解queryPlanner ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答 本文向您介绍一种利用mysql解析器和bison的调试选项进行sql语法解析跟踪的办法。 数据库开发过程中咱们常会遇到批改sql语法的需要。咱们晓得，mysql的sql解析器是基于yacc文法，采纳EBNF格局进行规定形容(sql/sql_yacc.yy)，并借助bison工具生成(sql_yacc.h, sql_yacc.cc), 所以批改sql语法，不可避免地要和这些yacc文法打交道，对sql_yacc.yy进行革新降级。 yacc文法是对语法解析的高度概括，它为咱们批改解析器提供了一种优雅的形式，但与此同时当咱们遇到语句解析问题，通常比拟难间接从形象的语法规定中找到起因。侥幸的是，联合mysql和bison提供的调试工具，咱们有机会将整个语法解析的过程形象化，通过解析日志，yacc规定和主动状态机的对应，可能比拟快地实现问题的定位。 mysql解析器调试开关sql/sql_yacc.yy文件下，能够看到如下一段代码： #ifndef NDEBUGvoid turn_parser_debug_on(){ /* MYSQLdebug is in sql/sql_yacc.cc, in bison generated code. Turning this option on is **VERY** verbose, and should be used when investigating a syntax error problem only. The syntax to run with bison traces is as follows : - Starting a server manually : mysqld --debug="d,parser_debug" ... - Running a test : mysql-test-run.pl --mysqld="--debug=d,parser_debug" ... The result will be in the process stderr (var/log/master.err) */ extern int yydebug; yydebug= 1;}#endif它通知咱们，debug版本下，在mysqld启动时增加 -debug="d, parser_debug选项，数据库服务器会为咱们输入sql解析的具体信息(bison traces)。 ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答1、闪回实现原理 2、binlog文件格式初探 3、闪回实现过程 1、闪回实现原理闪回的业务价值是，在DBA执行谬误的数据提交操作之后，还能把数据恢复还原到之前某个时刻的状态，最大水平地挽回损失。 在MySQL中，binlog文件次要用于主从同步二进制数据日志。当主服务器数据产生变更时，会把变动明细长久化到binlog文件中，此时从服务器通过拉取并解析binlog文件，实现数据的同步。正是因为binlog文件中记录了数据变更的信息，因而MySQL的闪回是基于binlog文件来实现的。 说的更精确一点，如果要在MySQL中实现闪回，则必须要求binlog文件日志格局是 binlog_format=row ，并且 binlog_row_image=full 。通过指定binlog文件的日志格局，就能在binlog中残缺记录数据变动的轨迹和具体的操作行为（增删改）的前后差别。 基于上述前提，咱们能够解析并解决binlog文件中的事件，而后反序遍历。同时对增删改进行反转逆操作，即插入映射成删除、删除映射成插入、更新替换新旧数据区间。最初输入对应数据回滚的binlog文件，将其再次导入mysql，即实现对增删改数据的回滚还原。 2、binlog文件格式初探binlog是一个二进制文件，具体寄存的门路，能够通过在mysql的客户端执行：show variables like '%datadir%'，这个SQL语句来查看。这时联合下面的门路信息，在终端中能够输出： # binlog文件寄存门路cd /home/mysql-server/bld_debug/install_debug/data/ # binlog.000006指要查看的binlog文件名 hexdump -C binlog.000006|more。后果示例如下： 00000000 fe 62 69 6e ad 10 15 61 0f 01 00 00 00 79 00 00 |.bin...a.....y..| 00000010 00 7d 00 00 00 00 00 04 00 38 2e 30 2e 32 35 2d |.}.......8.0.25-| 00000020 31 35 2d 64 65 62 75 67 00 00 00 00 00 00 00 00 |15-debug........| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 00 00 00 00 00 00 00 ad 10 15 61 13 |..............a.| 00000050 00 0d 00 08 00 00 00 00 04 00 04 00 00 00 61 00 |..............a.| 00000060 04 1a 08 00 00 00 08 08 08 02 00 00 00 0a 0a 0a |................| 00000070 2a 2a 00 12 34 00 0a 28 01 ea d7 cf 01 ad 10 15 |**..4..(........| 00000080 61 23 01 00 00 00 1f 00 00 00 9c 00 00 00 80 00 |a#..............| ......后面的4个字节fe 62 69 6e是魔数，标识文件类型是binlog。前面的二进制数据则示意事件，binlog中记录的事件类型次要有： ...

前言： 默认状况下，咱们的 MySQL 实例是可读写的。但有些状况下，咱们能够将整个实例设置为只读状态，比方做迁徙保护的时候或者将从库设为只读。本篇文章咱们来看下 MySQL 设置只读相干常识。 1.对于 read_only 参数MySQL零碎中，提供有 read_only 和 super_read_only 两个只读参数，参考官网文档，这里介绍下这两个参数的作用： read_only 参数默认不开启，开启后会阻止没有 super 权限的用户执行数据库变更操作。开启后，一般权限用户执行插入、更新、删除等操作时，会提醒 --read-only 谬误。但具备 super 权限的用户仍可执行变更操作。 super_read_only 参数同样默认敞开，开启后不仅会阻止普通用户，也会阻止具备 super 权限的用户对数据库进行变更操作。 read_only 和 super_read_only 是有关联的，二者之间的关系如下： 设置 super_read_only=on ，也就隐式地设置了 read_only=on。设置 read_only=off ，也就隐式地设置了 super_read_only=off。能够独自开启 read_only 而不开启 super_read_only。不过，从库开启 read_only 并不影响主从同步，即 salve 端依然会读取 master 上的日志，并且在 slave 实例中利用日志，保障主从数据库同步统一。（经测试，从库端开启 super_read_only 仍不影响主从同步。） 上面咱们具体来操作下，看下 read_only 参数的用法： # 查看 read_only 参数mysql> show global variables like '%read_only%';+-----------------------+-------+| Variable_name | Value |+-----------------------+-------+| innodb_read_only | OFF || read_only | OFF || super_read_only | OFF || transaction_read_only | OFF || tx_read_only | OFF |+-----------------------+-------+# 动静批改 read_only 参数 （若想重启失效 则需将 read_only = 1 退出配置文件中）mysql> set global read_only = 1;Query OK, 0 rows affected (0.00 sec)mysql> show global variables like 'read_only';+---------------+-------+| Variable_name | Value |+---------------+-------+| read_only | ON |+---------------+-------+# read_only 开启的状况下 操作数据# 应用超级权限用户mysql> create table tb_a (a int);Query OK, 0 rows affected (0.05 sec)# 应用一般权限用户mysql> create table tb_b (b int); ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement# 开启 super_read_only，再次应用超级权限用户来操作数据mysql> set global super_read_only = 1;Query OK, 0 rows affected (0.00 sec)mysql> show global variables like 'super_read_only';+-----------------+-------+| Variable_name | Value |+-----------------+-------+| super_read_only | ON |+-----------------+-------+mysql> create table tb_c (c int); ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement# 敞开 read_only 参数mysql> set global read_only = 0;Query OK, 0 rows affected (0.00 sec)2.flush tables with read lock 设置除了 read_only 参数外，执行 flush tables with read lock 也可将数据库设置为只读状态，那么二者有什么区别呢？咱们先来理解下 flush tables with read lock 的作用。 ...

【赵强老师】往期学员待业薪水统计，期待Oracle第01期课程

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答一、简介在开始排错之前咱们须要晓得 Update 在 MySQL 中的生命周期是什么，MySQL 如何执行一个事务的。 了解了如何执行，咱们才晓得如何去排查故障。 二、Update 生命周期Server 层阶段 2.1 连接器客户端发动一个 TCP 申请后，MySQL Server 端会负责通信协议解决、线程解决、账号认证、安全检查。 2.2 分析器MySQL Server 端对一个 SQL 申请进行词法剖析（辨认 select、from），而后会对语法 进行分析判断语法是否正确。 2.3 优化器优化器会剖析 SQL 语句，抉择适合的索引，依据预后果集判断是否应用全表扫描。 2.4 执行器InnoDB 引擎层阶段 2.4.1 事务执行阶段1） 申请进入 InnoDB 引擎后，首先判断该事务波及到的数据页是否在 BP 中，不存在则会从磁盘中加载此事务波及的数据页到 BP 缓冲池中，并对相应的索引数据页加锁 思考？ 数据是如何从磁盘加载到 BP 中的?BP 中的新老生代是如何交替及回收?如何对相应数据加? 解答： 通过 B+Tree 读取到磁盘的索引页加载到 BP 缓冲池中。 1、通过 space id 和 page no 哈希计算之后把索引页加载到指定的 buffer pool instance 中。2、判断 Free List 是否有闲暇页可用（innodb_buffer_pool_pages_free、innodb_buffer_pool_wait_free），没有 则淘汰脏页或 LRU List 的 old。3、将数据页加载到Free List 中，而后加载到 LRU List 的 old 区的 midpoint（头部）。4、通过二分查找法，找该页对应的记录，试图给该事物波及到的行记录加上排他锁。(1) 判断该事物以后记录的行锁被其余事物占用的话，须要进入锁期待。(2) 进入锁期待后，同时判断会不会因为本人的退出导致了死锁。(3) 检测到没有锁期待和不会造成死锁后，行记录加上排他锁。2） 将批改前的数据写入到 Undo 中，批改后将回滚针执行 Undo log 中批改前的行 ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答一、需要背景查问Percona官网手册，Xtrabackup 8.0能够备份MySQL 8.0以上。 二、环境筹备因为在中标麒麟ky10零碎上间接编译报gcc等谬误，所以须要在ARM下筹备CentOS零碎。 中标麒麟ky10的内核为4.19，而CentOS 7的内核为3.xx，CentOS 8的内核为4.18，故须要在CentOS 8的操作系统进行编译，编译实现后拿到中标麒麟ky10中应用。 2.1 查看零碎架构及版本 Shell> cat /etc/redhat-release CentOS Linux release 8.1.1911 (Core) Shell> uname -srm Linux 4.18.0-147.el8.aarch64 aarch642.2 下载源码包web下载地址： shell操作： Shell> cd /root Shell>wget https://github.com/percona/percona-xtrabackup/archive/refs/tags/percona-xtrabackup-8.0.25-17.tar.gz2.3 配置CentOS 8的yum源Shell> mkdir /etc/yum.repos.d/repo.bak Shell> mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/repo.bak/ //查看dns是否失常 Shell> ping baidu.com //批改dns地址 Shell> vim /etc/resolv.conf Shell> curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-8.repo Shell> sed -i -e '/mirrors.cloud.aliyuncs.com/d' -e '/mirrors.aliyuncs.com/d' /etc/yum.repos.d/CentOS-Base.repo Shell> sed -i.bak -e 's|^mirrorlist=|#mirrorlist=|' -e 's|^#baseurl=|baseurl=|' -e 's|http://mirror.centos.org|https://mirrors.aliyun.com|' /etc/yum.repos.d/CentOS-*.repo Shell> dnf makecache Shell> dnf install lrzsz三、装置编译依赖 Shell> dnf install cmake openssl-devel libaio libaio-devel automake autoconf bison libtool ncurses-devel libgcrypt-devel libev-devel libcurl-devel zlib-devel vim-common libarchive git centos-release-stream gcc-toolset-10-gcc-c++PS: 以上依赖都必须装置，否则CMake时会报依赖谬误。 ...

作者：threedayman 起源：恒生LIGHT云社区 备份还原应用到的命令mysqldump、mysql 对于mysqldump命令更多内容 详见 https://dev.mysql.com/doc/refman/5.7/en/mysqldump.html 筹备工作创立两张表user、his_user CREATE TABLE `user` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT 'id', `name` varchar(100) NOT NULL COMMENT '姓名', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='用户表';CREATE TABLE `his_user` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT 'id', `name` varchar(100) NOT NULL COMMENT '姓名', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='历史用户表';插入数据 INSERT INTO user(name) VALUES('three');INSERT INTO his_user(name) VALUES('wang');mysql> select * from user;+----+-------+| id | name |+----+-------+| 1 | three |+----+-------+1 row in set (0.01 sec)mysql> select * from his_user;+----+------+| id | name |+----+------+| 1 | wang |+----+------+1 row in set (0.00 sec)备份全库备份 ...

OGG装置环境介绍，为了节俭资源OGG我抉择和原库装置在了同一台服务器 1.1 解压ogg的安装包 上传并解压mysql ogg安装包，无需装置解压即可应用 # mkdir /ogg# unzip 213000_ggs_Linux_x64_MySQL_64bit.zip# tar -xvf ggs_Linux_x64_MySQL_64bit.tar1.2 Mysql数据库配置 源库配置 OGG21C能够应用基于日志的DDL复制，要求添binlog_row_metadata为full模式才能够实现 # vi /etc/my.cnf[mysqld]datadir=/usr/local/mysql/databasedir=/usr/local/mysqlsocket=/tmp/mysql.sockuser=mysqlport=3306character-set-server=utf8mb4symbolic-links=0server_id = 1log_bin = mysql-binexpire_logs_days = 1binlog_format = rowbinlog_row_metadata=full[mysqld_safe]log-error=/var/log/mysqld.logpid-file=/var/run/mysqld/mysqld.pid指标库配置 [mysqld]datadir=/usr/local/mysql/databasedir=/usr/local/mysqlsocket=/tmp/mysql.sockuser=mysqlport=3306character-set-server=utf8mb4symbolic-links=0server_id = 2log_bin = mysql-binexpire_logs_days = 1binlog_format = rowbinlog_row_metadata=full[mysqld_safe]log-error=/var/log/mysqld.logpid-file=/var/run/mysqld/mysqld.pid主备数据库创立同步用户并附权 CREATE USER 'ogg'@'%' IDENTIFIED BY 'Sandata@123';GRANT ALL PRIVILEGES ON *.* TO 'ogg'@'%' WITH GRANT OPTION;FLUSH PRIVILEGES;1.3 OGG配置 在21C的OGG中ogg能够独自部署并不需要每台服务器都装置，只有网络可达即可 [root@mysql ogg]# ./ggsci Oracle GoldenGate Command Interpreter for MySQLVersion 21.3.0.0.0 OGGCORE_21.3.0.0.0_PLATFORMS_210728.1047Oracle Linux 7, x64, 64bit (optimized), MySQL on Jul 28 2021 18:17:46Operating system character set identified as UTF-8.Copyright (C) 1995, 2021, Oracle and/or its affiliates. All rights reserved.GGSCI (mysql) 1> CREATE SUBDIRSCreating subdirectories under current directory /oggParameter file /ogg/dirprm: created.Report file /ogg/dirrpt: created.Checkpoint file /ogg/dirchk: created.Process status files /ogg/dirpcs: created.SQL script files /ogg/dirsql: created.Database definitions files /ogg/dirdef: created.Extract data files /ogg/dirdat: created.Temporary files /ogg/dirtmp: created.Credential store files /ogg/dircrd: created.Master encryption key wallet files /ogg/dirwlt: created.Dump files /ogg/dirdmp: created.配置mgr过程 ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答 当主库宕机后，提早从库如何能力"勾销"被动提早，以便复原服务？ 问题形容本问题来自一位群友，他遇到的状况我简略演绎一下： 实例A是主库，B是提早从库（设置了提早7200秒）。当A挂掉后（已无奈连贯，或无奈启动），心愿用B晋升成主库。然而在B上执行 change master to MASTER_DELAY=0 后，B上曾经保留的7200秒的relay文件也会被革除掉，并尝试再次从A获取binlog，这样会造成7200秒的数据失落，未能达成目标。TA想问：在这样的场景下，还有方法让B库尽快跑完这7200秒提早数据吗，或者正确的方法是什么呢？ 问题解决先答复问题：这个需要是有方法达成的（而且还不只一种办法），最正确的办法也并不麻烦/简单（看到最初），只不过有些小窍门要留神下。 办法1，批改零碎工夫也就是批改B主机的零碎工夫，将其往后调整超过7200秒，而后重启slave线程，就能让SQL_THREAD持续利用relay log了。所有relay log利用结束后，再将零碎工夫批改回来。 # 批改零碎工夫，减少7200秒[root@greatsql]# date -s "`date --date '7200 second'`"# 重启slave线程[root@GreatSQL](none)> STOP SLAVE; START SLAVE;留神：这种办法（潜在）影响很大，可能对其余零碎利用有影响，或者MySQL里局部波及到日期工夫的后果也会受到影响，十分不举荐。 办法2，自行手动复原relay log/binlog当主库（A）宕机后，查看以后slave的状态： [root@GreatSQL](none)> SHOW SLAVE STATUS\G... Master_Log_File: binlog.000011 Read_Master_Log_Pos: 2671 Relay_Log_File: relay-bin.000005 Relay_Log_Pos: 361 Relay_Master_Log_File: binlog.000011 Slave_IO_Running: Connecting Slave_SQL_Running: Yes... Exec_Master_Log_Pos: 746 Relay_Log_Space: 2704... Seconds_Behind_Master: 387... SQL_Delay: 7200 SQL_Remaining_Delay: 6814 Slave_SQL_Running_State: Waiting until MASTER_DELAY seconds after master executed event能够看到这时候有387秒的落后，被动提早7200秒，还有6814秒之后能力利用最新的relay log。尽管事务有提早，但其实slave曾经把binlog都复制过去了，在relay log里。 Read_Master_Log_Pos: 2671 <-- 已读取到最新的binlog了，pos = 2671 Relay_Log_File: relay-bin.000005 <-- 对应的relay log Relay_Log_Pos: 361 <-- 对应的relay log pos... Exec_Master_Log_Pos: 746 <-- 但只apply到 pos = 746当初，只须要手动把这两头的差别数据拿进去apply就能够了。解析relay log，找到对应master binlog pos = 746的地位，或者间接指定realy log pos = 361的地位也能够： ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答 lsof中附加不同参数产生的后果也不同，小心“踩坑”。 1、背景：偶尔发现数据库连不上，在数据库的err日志中，呈现了“Too many open files”谬误，都晓得这个是mysqld过程触发了句柄限度，导致无奈建设新连贯。 度娘下面找到了统计句柄数的命令 lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr| head -n 10发现输入的后果远超了ulimit -n的后果。然而报错景象才继续不长时间，失常状况下不可能产生这么多句柄。 为了钻研这个问题的根因，在本人的服务器下面模仿了以下测试。 服务器配置4C8G，MySQL 8.0.22，lsof版本为4.87(为什么特地介绍lsof版本，后续会提到，很重要) 2、测试过程：1、在服务器下面装置好MySQL，设置上面的参数，重启数据库服务 max_connections=150open_files_limit=1000此时，数据库过程的open_files_limit为2160 mysql> show variables like '%open%';+----------------------------+-------+| Variable_name | Value |+----------------------------+-------+| have_openssl | YES || innodb_open_files | 1000 || mysqlx_port_open_timeout | 0 || open_files_limit | 2160 || table_open_cache | 1000 || table_open_cache_instances | 16 |+----------------------------+-------+6 rows in set (0.01 sec)其计算公式为table_open_cache*2+max_connections+10 具体见上面的官网介绍 2、此时数据库刚刚启动，查看过程占用的句柄数 [root@greatdb mysql]# ps -ef| grep mysqlroot 6239 8644 0 16:25 pts/5 00:00:00 mysql -urootroot 10134 8260 0 16:42 pts/1 00:00:00 mysql -urootroot 10177 1 0 16:47 ? 00:00:00 /bin/sh /usr/local/mysql/bin/mysqld_safe --defaults-file=/data/mysql/my.cnfmysql 11604 10177 8 16:47 ? 00:00:02 /usr/local/mysql/bin/mysqld --defaults-file=/data/mysql/my.cnf --basedir=/usr/local/mysql --datadir=/data/mysql/data --plugin-dir=/usr/local/mysql/lib/plugin --user=mysql --log-error=/data/mysql/logs/mysqld-error.log --open-files-limit=1000 --pid-file=/data/mysql/mysqld.pid --socket=/data/mysql/mysql.sock --port=3306root 11696 8572 0 16:47 pts/2 00:00:00 grep --color=auto mysql[root@greatdb mysql]# [root@greatdb mysql]# [root@greatdb mysql]# lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr| head -n 10 5727 11604 1575 1384 525 1550 455 879 371 561 135 1101 130 1001 120 16780 114 1304 88 16894[root@greatdb mysql]#能够看到刚刚启动的数据库，用下面的命令统计进去的句柄数5727就曾经超过了设置的值2160了，然而数据库依然能够失常应用和连贯。 ...

近日，行将到职转投谷歌的 Oracle 甲骨文工程师在本人的博客中发文对 MySQL 进行了“鞭挞”。 他宣称，PostgreSQL 是开源 RDBMS 的更好抉择，“MySQL 是一款’相当蹩脚’的数据库，你应该强烈思考应用 Postgres”。 据悉，这位工程师名叫 Steinar Gunderson ，此前始终负责 Oracle 的首席软件工程师，也是 MySQL Optimizer 团队的成员。目前，该工程师已在谷歌 Chrome 团队中任职。 此博文一经公布，便引起热议。 有媒体评论称，对于行将到职的开发人员来说，这篇博文堪称对他已钻研了五年的技术进行的一种“诽谤”。但令人吃惊的是，不少业内人士却十分认可这位工程师的观点。 Gunderson 示意，“来到 MySQL 就像走进了一个平行的世界，在那里有很多人真的置信 MySQL 是一个最先进的产品。”然而，代码状态意味着“有足够的改良空间”和“管理层强烈反对大型重构”。 只管 Gunderson 对 MySQL 的工作感到骄傲，“这有助于让 MySQL 8.0 版本成为比 5.7 版更好的产品”，但他也示意“你能做的只有这么多”。 “我和其余共事所做的扭转，使 MySQL 优化器朝着一个相当规范的 21 世纪初的设计方向倒退，并做了一些很好的调整，但这也是它完结的中央。不论公司外部通信部门如何证实 Oracle 充斥蠢才且正在云计算中获胜，但最终，我仍旧看不到足够的资源让它成为一个有竞争力的产品。” 对此舆论，有媒体评论示意事实并非如此，Oracle 并没有在 MySQL 上停滞不前。 原来早在去年 12 月份，甲骨文就对其 Oracle 云的在线剖析解决性能进行了降级，以确保平衡倒退；此外，由解决 Oracle 同名数据库的同一团队开发的内存剖析引擎，也致力于进步开源数据库的性能。 “诽谤”or瞎话？MySQL 到底是不是个“蹩脚”的数据库对于这位 Gunderson 博文所指出的观点，这到底是不是一种“诽谤”？除了媒体评论之外，咱们还是要看更多业内人士的认识。 据理解，MySQL 最后是由 David Axmark 和 Michael Widenius 共同开发的，第一个版本可追溯到 1995 年。开创的瑞典公司 MySQL AB 于 2008 年被 Sun Microsystems 收买，而 Sun 于 2009 年又被甲骨文收买。 ...

欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答问题 问题原文是这样的： 如果在MySQL事务里，给某个表的一行加了 共享锁，实践上这个表自身会主动加上动向共享锁，那么能不能用 sql 查出这个表加了意向锁？答复 答案是必定的，当然能够执行SQL查问表上的IS锁加锁状态。 先申明，咱们本次探讨的是MySQL里的InnoDB引擎表，上面探讨的内容都是基于这个前提。 在揭晓答案之前，多介绍点InnoDB引擎锁相干的一些常识吧。次要有以下几点 InnoDB引擎表既反对表级锁，也反对行级锁。加表级锁的办法和MyISAM表是一样的，执行 LOCK TABLE READ/WRITE 即可。InnoDB表的行锁是加在索引上的，因而如果没有适合的索引，是会导致表里所有记录都被加上行锁，其结果等同于表级锁，但产生的影响比表级锁可就大多了。因为锁对象数量大了很多，耗费的内存也多很多。加上行锁时，同时还须要对表加上相应的意向锁。例如，想要对一行数据加上共享锁（S锁），则相应的要对表加上动向共享锁（IS锁）；同样地，想要对一行数据加上排他锁（X锁），则相应的要对表加上动向排他锁（IX锁）。意向锁是加在汇集索引的根节点上的，因而无论锁定多少行，只须要加一个意向锁。上面是几个锁之间的兼容矩阵 好了，接下来咱们来看下怎么查看表级IS锁。其实很简略，只须要查看 PFS.data_locks 表就能够了。另一个表 PFS.metadata_locks 表能够查看MDL锁的详情。 查问后果例如上面这样： [root@yejr.run] [(none)]>select * from performance_schema.data_locks\G*************************** 1. row *************************** ENGINE: INNODB ENGINE_LOCK_ID: 140701134495048:1350:140701396637648ENGINE_TRANSACTION_ID: 422176111205704 THREAD_ID: 87 EVENT_ID: 95 OBJECT_SCHEMA: yejr OBJECT_NAME: t1 PARTITION_NAME: NULL SUBPARTITION_NAME: NULL INDEX_NAME: NULLOBJECT_INSTANCE_BEGIN: 140701396637648 LOCK_TYPE: TABLE LOCK_MODE: IS LOCK_STATUS: GRANTED LOCK_DATA: NULL*************************** 2. row *************************** ENGINE: INNODB ENGINE_LOCK_ID: 140701134495048:267:4:9:140701409130528ENGINE_TRANSACTION_ID: 422176111205704 THREAD_ID: 87 EVENT_ID: 95 OBJECT_SCHEMA: yejr OBJECT_NAME: t1 PARTITION_NAME: NULL SUBPARTITION_NAME: NULL INDEX_NAME: PRIMARYOBJECT_INSTANCE_BEGIN: 140701409130528 LOCK_TYPE: RECORD LOCK_MODE: S,REC_NOT_GAP LOCK_STATUS: GRANTED LOCK_DATA: 1此时咱们能看到t1表上共有两个锁，一个是表级IS锁，另一个是c1=1上的共享锁。 ...