Mysql

[toc] 1.新增个性1.2 新增MGR角色列在MySQL 5.7中，查问 performance_schema.replication_group_members 时，没有 MEMBER_ROLE 这个列，这很不便于疾速查看哪个节点是Primary Node。 在GreatSQL中，减少了这个列，查看节点角色更便当了，对一些中间件反对也更敌对。 mysql> select * from performance_schema.replication_group_members;+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE |+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+| group_replication_applier | 4c21e81e-953f-11ec-98da-d08e7908bcb1 | 127.0.0.1 | 3308 | ONLINE | SECONDARY || group_replication_applier | b5e398ac-8e33-11ec-a6cd-d08e7908bcb1 | 127.0.0.1 | 3306 | ONLINE | PRIMARY || group_replication_applier | b61e7075-8e33-11ec-a5e3-d08e7908bcb1 | 127.0.0.1 | 3307 | ONLINE | SECONDARY |+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+1.2 采纳全新的流控机制原生的流控算法有较大缺点，触发流控阈值后，会有短暂的流控进展动作，之后持续放行事务，这会造成1秒的性能抖动，且没有真正起到继续流控的作用。 在GreatSQL中，从新设计了流控算法，减少主从延迟时间来计算流控阈值，并且同时思考了大事务处理和主从节点的同步，流控粒度更粗疏，不会呈现MySQL社区版本的1秒小抖动问题。 新增选项 group_replication_flow_control_replay_lag_behind 用于管制MGR主从节点复制提早阈值，当MGR主从节点因为大事务等起因提早超过阈值时，就会触发流控机制。 System Variable Namegroup_replication_flow_control_replay_lag_behindVariable ScopeglobalDynamic VariableYESPermitted Values[0 ~ ULONG_MAX]Default600Description单位：秒。 用于管制MGR主从节点复制提早阈值，当MGR主从节点因为大事务等起因提早超过阈值时，就会触发流控机制该选项默认为600秒，可在线动静批改，例如： ...

引言 内容为慕课网的《高并发 高性能 高可用 MySQL 实战》视频的学习笔记内容和集体整顿扩大之后的笔记，本篇内容偏重Mysql备份的基本原理和罕用介绍为主，大部分为实践相干的内容。 数据备份在平时的工作和学习中可能应用的比拟少，然而对于一个线上我的项目来说却是不可或缺的一环，对于开发人员来说相熟和理解备份的相干常识是很有必要的，学习备份的相干内容能够帮忙咱们理解运维工作中一些根本的备份操作。 本节内容偏差实践为主，重点在于理解Mysqldump如何实现增量备份和全量备份，为前面的文章介绍Mysql主备同步打下基础。 知识点：Outfile 原生mysql工具介绍MysqlDump对于Outfile工具改良，MysqlDump特点介绍MysqlDump实现增量备份和全量备份的细节Xtrabackup备份工具的介绍以及实现增量备份和全量备份的细节备份介绍为什么须要备份？ 古代的少数服务少数零碎高可用，数据无价，失落会带来难以承当的损失。一套残缺的备份机制能够使得零碎遇到不可抗力的状况时将数据的修复代价降到最低甚至零损失。对于任何我的项目都应该具备定期备份数据的好习惯，无论是否为生产我的项目。备份模式 物理备份：比方咱们应用硬盘拷贝本人的重要数据，灵活性个别，安全性较高。云服务器备份：将数据传到第三方的云数据库进行保存，保护老本个别，安全性取决于第三方保护商的品质。自建服务器备份：开销比拟大，然而数据安全性和稳定性都是最高的，也能够离线进行物理备份，可操作性强。备份时候数据状态三种： 热备：失常运行备份。此时数据库可读可写。冷备：停机备份。数据库无奈进行任何操作。温备：数据库只读。数据库可用性弱于热备，备份期间，数据库只能进行读操作，不能进行写操作备份文件格局 备份文件的格局意味着导出的时候是什么样的： 逻辑备份：输入或者SQL语句，能够供技术人员浏览。物理备份（裸文件）：备份数据库底层文件然而不可浏览备份内容 齐全备份：备份残缺数据增量备份：备份全量备份之后的数据差别日志备份：也就是Binlog 备份常用工具 罕用的备份工具有上面两种 Mysqldump：逻辑备份，热备份，全量xtrabackup：物理，热，全量 + 增量备份小结 备份的根本模式：从备份的模式来看，能够应用物理磁盘备份，也能够依赖于三方服务商的服务器或者自建的服务器进行备份，而从备份数据状态来看，能够存在热备，冷备和温备，这里须要小心温备这个概念。备份工具比拟罕用的有两种：Mysqldump和xtrabackup，这两种工具都须要重点把握根底的操作应用，实际多余实践，多应用就会了。开发的时候应用逻辑备份比拟多，然而对于运维人员来说可能应用物理备份的形式更快，逻辑备份经常用于线上出问题的场景。Outfile命令备份（理解）怎么来？ 对于这个命令咱们只须要理解，在日常应用中并不波及应用场景，此命令为mysql自带的命令同时也是mysql 的预留关键字，能够说是最原始的逻辑备份形式，能够作为理解MysqlDump的前置根底。 应用前提 要晓得网站的绝对路径，能够通过报错信息、phpinfo界面、404界面等一些形式晓得。要有file的读写权限，倡议给相干文件夹执行chmod -R /xxx/xxx 。写的文件名肯定是在文件治理中中不存在的，不然也会不胜利！特点 简略的导出SQL后果次要用于长期须要数据验证的场景。Mysql原生命令反对的导出形式，执行效率高。命令简略操作不便，能够导出一致性视图。缺点 导出的格局较为简陋，通常须要对于数据进行二次解决能力失常应用。只能导出SQL执行后果，没有方法将导出后的数据用于还原。通过下面的介绍能够看出Outfile这个命令只能用于日常开发的场景下须要测试数据长期导出，不能作为热备的次要工具，然而这个命令对于Mysqldump来说是启发性的。如何应用？ 前提条件：在具体的导出之前咱们须要理解Mysql导出的具体门路，应用上面的语句检查一下以后的平安文件导出前缀，留神后果如果为NULL在Mysql5.6版本没有影响然而Mysql5.7版本是存在影响的。 另外集体应用的Mac零碎的文件系统治理尽管和Linux大体一致，然而其实有很多权限等等细节问题也是踩了一波小坑。 show variables like '%secure%'-- secure_file_priv NULL为什么说应用secure_file_priv为NULL是存在影响的？ 解答： Mysql5.7的版本中，在Mysql启动的时候，如果应用了这个参数的配置则会 限度你能够应用LOAD DATA INFILE加载文件的范畴，意味着如果想要导出必须是在这个配置指定的目录上面能力胜利，上面是此配置对应的变动： 1. secure\_file\_priv 为 NULL 时，示意限度mysqld不容许导入或导出。 2. secure\_file\_priv 为 /tmp 时，示意限度mysqld只能在/tmp目录中执行导入导出，其余目录不能执行。 3. secure\_file\_priv 没有值时，示意不限度mysqld在任意目录的导入导出。 实现下面这些筹备工作之后，咱们须要搭建根本的操作环境，比方新建数据库或者表，这里仍然应用了sakila数据库，咱们能够应用上面的命令进行尝试导出，比方上面的语句中咱们将payment表的所有数据导出。 select * from payment into Outfile '/Users/xxx/xxx/a.csv' 注：Sakila数据库在Mysql官网的example中能够间接下载。然而理论执行过程中会呈现如下的报错，从报错信息能够看到这里是因为secure_file_priv为NULL的问题： ...

服务器环境： CentOS-7.4-x86_64-DVD-1708 MySQL版本： mysql-5.7.27-linux-glibc2.12-x86_64.tar.gz 1，首先卸载Centos7自带的Mariadb# 查看零碎自带的Mariadb[root@CDH-141 ~]# rpm -qa|grep mariadbmariadb-libs-5.5.44-2.el7.centos.x86_64# 卸载零碎自带的Mariadb(此时要依据理论状况去卸载)[root@CDH-141 ~]# rpm -e --nodeps mariadb-libs-5.5.56-2.el7.x86_642，查看Msyql是否存在# 查看mysql是否存在[root@CDH-141 ~]# rpm -qa | grep mysql[root@CDH-141 ~]# 3，查看用户和组是否存在(1),先查看是否存在，如果不存在则创立# 查看mysql组和用户是否存在，如无则创立[root@CDH-141 ~]# cat /etc/group | grep mysql[root@CDH-141 ~]# cat /etc/passwd | grep mysql # 创立mysql用户组[root@CDH-141 ~]# groupadd mysql# 创立一个用户名为mysql的用户，并退出mysql用户组[root@CDH-141 ~]# useradd -g mysql mysql# 制订password 为111111[root@CDH-141 ~]# passwd mysqlChanging password for user mysql.New password:BAD PASSWORD: The password is a palindromeRetype new password:passwd: all authentication tokens updated successfully.4，下载mysql离线安装包tar文件官网下载地址：https://dev.mysql.com/downloa... ...

数据库公布要留神什么？ 1.多个SQL文件要按程序运行 2.文件中的每个语句要交互式运行，运行一句返回一句的后果 3.可能记录全副语句和对应的返回后果用于审计 4.任何一个语句出错，终止后续的运行 请登录https://www.deskui.com，揭秘管控平台，一键公布SQL的神秘 https://www.bilibili.com/vide...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 -- MySQL 8.0 有一个组件叫 component_log_filter_dragnet ， 它次要性能就是对 MySQL 的谬误日志内容进行定制化过滤与革新，之前有简略提过，这次来具体说下如何应用。 应用前，先装置组件： INSTALL COMPONENT 'file://component_log_filter_dragnet'; 装置后，设置零碎参数log_error_services 来启用它。 SET global log_error_services = 'log_filter_dragnet; log_sink_internal';通过零碎参数dragnet.log_error_filter_rules 来调整过滤规定，比方对指定错误代码限流、革新输入等等。相似对MySQL监控，必须有过滤条件、触发动作、最终后果等关键因素。 过滤条件则相似SQL语句中单个字段或者多个字段组合过滤。比方字段<操作符> 值、NOT EXISTS 字段、过滤条件组合等。存在三种字段：别离为外围字段，可选字段，用户自定义字段。 本篇咱们来介绍外围字段。外围字段列表如下：time: 工夫，比方能够设置在2022年12月1日之前都不容许写谬误日志。msg： 错误信息， 因为err_code间接能定位到msg，个别很少用它来判断，msg能够参加定制内容。prio：优先级，对应的值为ERROR、WARNING、INFORMATION、NOTE几个值或者任意组合，与设置零碎参数log_error_verbosity 成果相似。err_code/SQL_state： 具体错误代码，也即错误信息的KEY。err_symbol： 具体谬误符号，MySQL每个错误代码都对应一个谬误符号。具体的err_symbol 数据能够用perror 打印或者从官网谬误参考页面查找：https://dev.mysql.com/doc/mys...subsystem: 指定过滤的子系统我的项目，比方：Server、InnoDB等。触发动作有以下四个：drop: 删除谬误数据。throttle: 对内容限流。set：定制字段数据。unset: 重置字段数据。本篇要革新的谬误日志基于如下命令产生：全篇用命令A代替。 [root@ytt-pc ytt]# mysql -utest33333 ERROR 1045 (28000): Access denied for user 'test33333'@'localhost' (using password: NO)对应的谬误日志代码：从后果截取两个err_code 别离为MY-013360和MY-010926。 2022-03-24T06:03:59.511173Z 50 [Warning] [MY-013360] [Server] Plugin sha256_password reported: ''sha256_password' is deprecated and will be removed in a future release. Please use caching_sha2_password instead'2022-03-24T06:03:59.511322Z 50 [Note] [MY-010926] [Server] Access denied for user 'test33333'@'localhost' (using password: NO)接下来我举例说明一些常见用法：字段time相似对表工夫字段进行过滤，能够定义一个等值条件或者取值范畴。例如让2023-01-01之前的谬误数据不记入日志，配合字段time以及动作drop来实现： ...

导读： 俄乌交战，Oracle、IBM、微软、SAP等各大科技巨头相继发表暂停对俄罗斯服务，也让咱们警醒起来，信创国产化真的很重要！与此同时，国产纯自研数据库明星产品之一，达梦数据库也吸引了泛滥眼光。达梦数据库通过四十年继续更新迭代，保持走自主研发的技术路线，成为国内少有的领有全副源代码、具备齐全自主知识产权的数据库厂商。墨天轮社区 作为数据人的技术成长社区，致力于 “想数据人所想，懂数据人所需”，明天咱们邀请到达梦数据库的副总经理冯源学生，聚焦俄罗斯被制裁背景，为中国数据库行业的倒退方向、应答制裁动作、商业数据库或不可用等问题的解决指明路线。 达梦公司副总经理冯源 先后参加DM5、DM6、DM7、DM8的产品研发和测试工作。牵头实现达梦数据库管系统安全版的平安等保三级、等保四级攻关工作；实现达梦数据库管理系统的信息系统平安防护等级、信息系统平安评估保障等级（国内平安规范）剖析与认证工作；作为核心成员，屡次参加达梦公司牵头的重大专项课题，承当项目管理和研发测试工作。  — 以下为采访注释 — ❓：您认为Oracle等科技公司制裁俄罗斯对数据库行业以及相干产业会产生哪些影响？是否会呈现业务中断或瘫痪的状况？ 冯源：1、对于影响，甲骨文制裁俄罗斯，不论是对国产数据库厂商还是用户而言，都会起到肯定的警示作用。  同时，如果科技制裁频发将会加剧整个寰球软件市场的割裂，自身这个行业易呈现马太效应，强人愈强。如果人为的和平、立场或其余的因素将市场割裂开来，那么全球化的软件行业到最初极有可能演变成两套独立的经济体系，一套是东方的产品体系；另一边俄罗斯等面临这样危险的国家，将会减速软件代替化的过程。与此同时中国的软件企业也能够思考出海到俄罗斯等其余国家，造成另一个独立的市场。  不论如何，寰球软件市场割裂的场面不利于甲骨文本身的倒退，自身它是一家寰球份额独占的企业，但因为一些起因，毁坏了它的市场份额。 2、针对业务中断问题，对于俄罗斯而言，从短期来看不会呈现业务中断或者瘫痪的状况。一旦数据库跑起来，只有不出重大的安全漏洞或者是软件故障，都能维持当初的运行。 相较于业务自身的问题，俄罗斯当下更应该关注数据库的平安危险。首先甲骨文存在着肯定的安全漏洞危险，在没有官网提供修复的状况下，俄罗斯的企业如果保持数据库带破绽运行，将会面临很高的危险，受到平安攻打的可能性也会很大。 目前俄乌和平曾经不限于经济、科技领域的制裁，网络信息战也曾经开启，即便政府层面不做号召，民间也发展了信息系统的攻打。如果这时还在应用他人的操作系统，以及带着他人一清二楚的安全漏洞进行数据库的运行，这样的危险会比业务中断或者瘫痪都高得多。   ❓：您认为面对制裁，对国产数据库厂商来说是不是一件坏事？如何把握住这次“时机”呢？ 冯源：1、俄罗斯的IT的原创与技术能力都很不错，比方clickhouse数据库企业。但因为经济体量或是市场等因素，俄罗斯IT公司很难做好做大，优良的公司、产品与团队为了生存会走向寰球市场，从而被美国公司企业与机构所管制。 在中国，只管根底软件在寰球占据的规模不大，但至多养活国产公司不成问题，因而对于咱们而言，第一步是要保障国内的技术软件厂商可能活下来，第二步便是谋求做大。 俄罗斯最大的喜剧是很多原创的优良技术、产品、团队不受本人管制，最初都到了美国。 所以被制裁这件事件对于中国厂商而言，首先是个警示，“别的孩子在挨打”，咱们就要防患未然，提前做筹备工作。另一方面，还要思考一些非技术性的因素，除了做国产数据库产品、技术以外，还要思考如何保住它，否则将会面临遣散或是收买的终局。 就如同Nginx一样，是俄罗斯人创造的，但因为种种原因被收买后反过来制裁俄罗斯，这件事件自身就是无比讥刺的。因而面对这样的局势，中国肯定要倒退本人的技术与产品，比方发展“备胎打算”，躲避外围能力被国外管制的情景。 2、俄乌和平导致俄罗斯被科技制裁，并不等于中国的IT企业能够去填补这块空白市场， 因而对于中国来讲并不算一次间接的时机。  首先俄罗斯国内的新零碎仍旧能够运行，其次俄罗斯的IT也没有那么差，他们有很多的预案应答制裁。因而对中国来说与其说是时机，更多的应该是警醒，国内应该做好预案并保持方向走上来，这也是这件事件最大的意义。另一方面，我认为也要更主观的对待这个事件。商业公司制裁俄罗斯并不会有人感到惊讶，但如果开源社区也来制裁俄罗斯，这个才是新闻，也会突破很多人的空想。借助开源咱们能做到很多货色，但同时也要防止“依赖开源”的状况。当前中国的技术软件产业外面做自主化，走开源门路就要思考应该躲避哪些问题，同样也要设计机制防止“依赖开源”。 在数据库，或者操作系统这样上千万行代码规模的内核中被“投毒”，这会是一件不寒而栗的事件，大海里捞一根针都很难，更何况是在毫无觉察的状况下“偷偷投毒”，你不可能把每一行代码一寸一寸地捋过来，因而这样的危险是十分大的。源代码没有任何的意义，它只是一个技术的载体，领有源代码也不代表领有核心技术。  ❓：如果达梦是一家俄罗斯外乡的数据库厂商，您认为如何能力帮忙国家更好地应答“科技”制裁？ 冯源： 如果达梦是一家俄罗斯的外乡数据库厂商，并具备当初的程度和产品能力，能够帮忙国内起到很大的作用。达梦从写第一行代码到公布第一个版本，一直在市场上打磨产品，并基于用户的需要不断改进，用了几十年的工夫，达梦基本上将这样的迭代过程走完了。目前在很多行业与应用领域里，达梦曾经可能达到相似Oracle的利用成果。因而达梦如果作为一家俄罗斯的厂商，只有客户违心，咱们就可能以最快的速度将Oracle的产品替换掉，并极力做好安全漏洞修复与产品升级等运维工作。   ❓：俄罗斯发表制裁国家的专利生效，您认为是否会呈现盗版流行的状况？如果呈现应该如何应答？ 冯源：1、首先开源软件是收费供大家应用，而Oracle领有寰球的市场，因而一个国家盗版横行对它来讲影响不大。对于俄罗斯而言，在于它敢不敢放心使用被制裁盗版（开源软件），怕不怕被“投毒”。如果被投毒，惟一的区别就在于，一个来源于开源组织的贡献者、一个来源于商业软件的官网开发人员，同时安全漏洞没有修复，都会存在着危险，因而盗版并不是问题，平安危险才是最大的问题。 2、除了技术先进性以外，数据库产品还要看其成熟度，一直在市场上应用和打磨，来满足用户的需要。 如果产品在短短几年的窗口期中没有足够的成熟度，难以满足市场需求，那么它将失去机会。俄罗斯被科技制裁事发忽然，大概率很难有哪个厂商提前防患未然，就算俄罗斯国内的专利放开，产品也会面临成熟度不够的问题。所以中国国产化代替的战略眼光是很久远的，咱们从十年前、甚至二十年前就开始做筹备工作。可能在这二十年的工夫里，前五年就先做好产品，前面整整十五年乃至更多的工夫，都在为咱们的产品做继续的迭代，逐步完善、丰盛产品。   ❓：假如“开源”退出制裁行列，基于开源数据库开发的商业数据库是否同样存在不可用的危险？ 冯源： 显然是有的，假如中国的厂商以现状来应答这样的制裁，必定会比俄罗斯好一些。 这相当于分辨行业一个上下游的关系，上游是开源社区，上游是基于开源的厂商。如果这个开源上游是在美国或者欧洲，上游在国内的市场的危险将会十分大。如果上下游都在国内，危险会绝对小一些。举个例子，比方长江的源头与入海口都在中国境内，那么各省市之间布局建筑水坝、开闸放水等都能够正当协调。开源社区自身作为一个跨国界的组织，成员来自世界各地，这其中的协调无关国界，而是个体与个体之间的协调，也就是所谓的“国内分工”。然而当国内壁垒建设起来了，国内分工不复存在，这时最要害的就是开源社区的源头。开源社区的源头和厂商处于同一个营垒与国家，那么协调起来绝对来讲比拟容易。   ❓：国产化其中的一大阻力就是迁徙，请问目前贵司数据库曾经具备了哪些数据库平滑迁徙的能力？将来在迁徙方面有哪些想法和布局？ 冯源： 国产数据库的厂商做迁徙大体上走以下两条路线，一种是达梦谋求的“不迁徙而迁徙” ，原有的业务零碎不须要做特地的迁徙与批改就可能实现数据库的运行，这样的形式对于用户而言，体验最好，老本最低，危险也最可控。还有一种是“迁徙而迁徙”，迁徙有很多的伎俩与评估零碎，在迁徙前提前对数据库做评估，有哪些是待迁徙不兼容的问题，有哪些是实现平滑迁徙，对于这些不兼容的给一些倡议。最终用户更认可哪一条迁徙路线，这其实和生态无关。  MySQL、PG这样的数据库，用“迁徙而迁徙”的计划，老本绝对来讲更低。而达梦“不迁徙而迁徙”计划，瞄准的是oracle市场规模更大的生态，并且要对数据库的内核动刀。 可能很多人会疑难，数据库迁徙只用解决语法差别就能够，为什么要波及到内核呢？事实上如果只看到语法层面的问题，并不能解决迁徙问题。语法往往是迁徙中绝对没有技术难度的局部，性能的反对与否、解决机制的差别才是造成迁徙艰难的要害，而这些只有在数据库内核层面进行改良才可能平滑移植。对达梦而言，接触到很多用户的外围业务零碎，不是一个语法兼容能够搞定的，在没有搞定外围概念差别的状况下，你做任何语法兼容都是没有意义的。所以说咱们的 兼容路线不是一个语法层面的问题，它肯定要深刻到数据库的内核去”做手术”。 如果数据库的内核可能反对很多简单的性能，你才有可能在语法层面反对相应的性能。如果你的内核都很简略，那么你的语法层面即使反对了相干的概念，也不能实现数据库平滑迁徙。 为了“迁徙而迁徙”的计划最大的劣势是短平快，然而对于用户而言体验不太好。因而两者各有劣势，厂商能够依据本人的体量与投入来抉择适合的计划。对于达梦而言，咱们从2008年就开始布局数据库迁徙相干技术，用户甚至不须要任何实质性的利用代码更改，就可能间接将零碎移植达到梦上来。   ❓：在过来国产化数据库落地的过程中还存在哪些问题和难点？将来怎么更好地解决？ 冯源： 第一个问题是“进不了门”。随着国内的国产化代替过程逐步放慢，“没有用户”这个在2010年以前最大的问题曾经解决了，将来也心愿国内可能放弃这样的凋谢趋势，用户也可能更多地思考国产数据库产品。 第二点便是如何将国产数据库用在更有挑战性、更为重要的零碎上，并逐渐建设信赖。 现在国产数据库尽管敲开了门，然而依然有大量案例是跑在一些规模绝对小、压力绝对低的外围零碎上，这样对产品的打磨并没有太大帮忙。例如达梦目前在电力、能源、交通等一些行业与外围零碎都进行了国产化代替，从试用产品再到100%的信赖，这样的过程须要肯定的工夫，数据库产业界应该有这个思维筹备，该走的路早晚都是要走的。 第三点是厂商要持续性的对产品进行打磨，在做外围零碎的代替时，国产数据库厂商是否继续给用户做到正向的反馈。 当我作为一个甲方的负责人，决定引进某一个数据库产品做国产化代替时，如果厂商没有将业务零碎撑持好，那么对我来说将是一个危险十分高的决策。因而中国数据库厂商肯定要继续给用户、给甲方提供正向反馈，否则长时间后用户会对你产生质疑与不信赖。小范畴来讲，这件事件会影响你一家数据库，然而对整个市场而言，可能会造成用户对整个国产数据库产生不信赖。 因而，用户给你开了门，给了你利用机会，这时厂商肯定要可能给力地顶上来，继续给到正向反馈。  除此之外，即使厂商侧联结起来做国产化落地的推动，显然也是不够，用户侧肯定要一一动起来，国产化代替这件事才有可能胜利，并减速实现。     ❓：您感觉将来国产数据库要成为国内企业数字化建设的首选，须要具备哪些指标和个性？ 冯源： 指标我就不列举了，因为用户有本人的场景与零碎，对应的指标也是不同的。 将来国产数据库要成为国内企业数字化建设的首选，首先要具备的个性是生态得维持好。 国产数据库不太可能再造一套全新的生态，因而目前要么是认准甲骨文的生态去做代替，或者是基于开源生态去做。如果没有生态，很难在繁多的上下游环节中将利用零碎齐全迁徙过去，用户也不可能从零开始做一套全新的业务零碎。 第二点是稳定性要做好。 从产品的设计层面、产品质量、编码、测试等这一整套工程化的过程中，都要思考去用什么样的伎俩来保障产品能够提供继续稳固的服务。 最初一个是“口碑”。口碑并不是由繁多的生态、可靠性、性能某一个方面去决定的，它是一个综合经营的问题。在产品层面上把可靠性、安全性、稳定性作为根底因素，厂商还要思考从经营层面如何将口碑做起来：在某一个试点或者案例上获得了问题，不代表能在行业外面全面开花，最终还是要看口碑。 如果你在行业内的第一个客户不违心替你说坏话，那你的口碑就崩了。因而厂商肯定要器重在服务于客户的过程中，产品质量、服务运维人员的敬业水平等综合因素能不能为你挣得一份口碑，哪怕你在这个行业进入的晚一点，但有用户违心替你站台，为你说坏话，那么你就无望在这个行业里扩充市场。    【编者按】： 俄罗斯以后迫切需要解决的不是“业务问题”，而是更容易致命的“数据库安全问题”。如果“开源”被退出制裁行列，因为国内壁垒的建设，基于开源数据库开发的商业数据库也会存在不可用的危险，因而要做好预案。“平滑迁徙”是国产化的一大难题，达梦走的是“不迁徙而迁徙”的路线，对数据库内核动刀，并不是靠语法兼容就能搞定。针对国产数据库落地，各厂商须要将产品利用在更具挑战性的零碎上，继续打磨产品，建立口碑，建设良好的生态，将来国产数据库能力成为企业数字化建设的首选。查看原文：https://www.modb.pro/db/386810查看《如果你身处被“科技制裁”的俄罗斯》系列访谈合辑（行业专家、从业者等）：https://www.modb.pro/topic/386671更多精彩内容可返回墨天轮社区，围绕数据人的学习成长提供一站式的全面服务，打造集新闻资讯、在线问答、流动直播、在线课程、文档阅览、资源下载、常识分享及在线运维为一体的对立平台，继续促成数据畛域的常识流传和技术创新。 关注官网公众号： 墨天轮、 墨天轮平台、墨天轮成长营、数据库国产化 、数据库资讯

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 昨天一位网友的问题共享进去，以防大家入坑。这位网友对 MySQL 官网手册里的 hex 和 unhex 函数有些疑难： 本人试验后果和手册中给的后果有些差别。 手册上是这样写的： mysql> SELECT X'616263', HEX('abc'), UNHEX(HEX('abc')); -> 'abc', 616263, 'abc' mysql> SELECT HEX(255), CONV(HEX(255),16,10); -> 'FF', 255完后本人试验后果反而这样： mysql>SELECT X'616263', HEX('abc'), UNHEX(HEX('abc'));+----------------------+------------+--------------------------------------+| X'616263' | HEX('abc') | UNHEX(HEX('abc')) |+----------------------+------------+--------------------------------------+| 0x616263 | 616263 | 0x616263 |+----------------------+------------+--------------------------------------+1 row in set (0.00 sec)mysql>SELECT HEX(255), CONV(HEX(255),16,10);+----------+----------------------+| HEX(255) | CONV(HEX(255),16,10) |+----------+----------------------+| FF | 255 |+----------+----------------------+1 row in set (0.00 sec)第一条语句里X'616263' 和UNHEX(HEX('abc'))的执行后果和手册不统一，第二条语句执行后果和手册完全一致。 ...

作者：高鹏 DBA，负责我的项目日常问题排查，善于 MySQL 。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 前言本文章与一次日常运维过程中发现的问题无关。问题如下： 客户生产环境中有一个一主一从半同步的集群，运维共事发现连贯主库的时候很快，然而连贯从库的时候就很慢，故此征询起因； 拿到这个问题的时候感觉景象的确挺怪异，所以就进行了抓包比照。 连贯从库时的抓包后果： 从抓包后果能够看到三步握手后期待了10秒才收到 MySQL 给客户端的响应，那么问题呈现在 MySQL 这侧，什么状况下会导致 MySQL 呈现该问题？当咱们比照了主从配置文件后发现从库比主库少了 skip-name-resolve ，从库加上重启后问题得以解决。 1. MySQL 反向解析的过程 mysql-client向mysqld发动连贯申请；mysqld创立子线程来解决该连贯申请；子线程首先去查看主机名是否存在于performance_schema.host_cache表中；如果是，则进入权限验证阶段；如果否，那么会尝试解析将IP地址解析为主机名；而后再将主机名解析为IP地址；将解析到的后果和原始IP地址进行比拟；如果雷同则增加到host_cache中而后进行权限验证;如果不雷同，那么返回报错注：只有非本地主机的 TCP 连贯会应用主机缓存；应用网络回环地址或 socket 建设的连贯不会应用主机缓存 2. 主机缓存的作用通过缓存 IP 到主机名查找的后果，能够防止每次客户端进行连贯时都去寻找DNS进行解析，所能缓存条目标数量受 host_cache_size 管制。缓存中蕴含客户端连贯过程中产生的错误信息。如果同一主机间断屡次连贯谬误，那么将阻止该主机的进一步连贯，该行为受 max_connect_errors 管制。3.参数 host_cache_size与skip-host-cache和skip_name_resolve 的作用host_cache_size：管制主机缓存的数量，设置为0时，禁用主机缓存，每次服务器连贯时，服务器都会进行DNS查找，相比skip-host-cache来说，host_cache_size更加灵便，能够随时变更或禁用。 skip-host-cache：作用相似于host_cache_size，但mysql在运行时无奈对该参数进行变更，并且skip-host-cache在之后的版本中已弃用。 skip_name_resolve：查看客户端连贯时是否解析主机名，变量为off，则mysqld 会在查看客户端连贯时解析主机名。若变量为on，mysqld 只应用 IP ;在这种状况下，受权表中的所有列值都必须是 IP地址。 4.如何查看host_cache表mysql> select * from performance_schema.host_cache\G*************************** 1. row *************************** IP: 10.186.61.21 #连贯到服务器的IP地址 HOST: NULL #客户端DNS解析出的主机名，null代表未知 HOST_VALIDATED: YES #是否执行了DNS解析，如果值为YES则主机列将用作与IP绝对应的主机名，以便能够防止对DNS的其余调用；如果值为NO则每次连贯尝试都会尝试DNS解析，直到最终以无效后果或永恒谬误实现解析 SUM_CONNECT_ERRORS: 0 #被视为“阻塞”的连贯谬误数，仅统计协定握手谬误，并且仅统计HOST_VALIDATED=YES的主机 COUNT_HOST_BLOCKED_ERRORS: 0 #以下为各种连贯形式失败的计数 COUNT_NAMEINFO_TRANSIENT_ERRORS: 0 COUNT_NAMEINFO_PERMANENT_ERRORS: 1 COUNT_FORMAT_ERRORS: 0 COUNT_ADDRINFO_TRANSIENT_ERRORS: 0 COUNT_ADDRINFO_PERMANENT_ERRORS: 0 COUNT_FCRDNS_ERRORS: 0 COUNT_HOST_ACL_ERRORS: 0 COUNT_NO_AUTH_PLUGIN_ERRORS: 0 COUNT_AUTH_PLUGIN_ERRORS: 0 COUNT_HANDSHAKE_ERRORS: 0 COUNT_PROXY_USER_ERRORS: 0 COUNT_PROXY_USER_ACL_ERRORS: 0 COUNT_AUTHENTICATION_ERRORS: 17 COUNT_SSL_ERRORS: 0 COUNT_MAX_USER_CONNECTIONS_ERRORS: 0COUNT_MAX_USER_CONNECTIONS_PER_HOUR_ERRORS: 0 COUNT_DEFAULT_DATABASE_ERRORS: 0 COUNT_INIT_CONNECT_ERRORS: 0 COUNT_LOCAL_ERRORS: 0 COUNT_UNKNOWN_ERRORS: 0 FIRST_SEEN: 2020-12-18 10:30:03 #客户端第一次尝试连贯的工夫戳 LAST_SEEN: 2020-12-18 14:50:41 #客户端看到最新的连贯尝试的工夫戳 FIRST_ERROR_SEEN: 2020-12-18 10:30:03 #第一次连贯谬误的工夫戳 LAST_ERROR_SEEN: 2020-12-18 14:46:37 #最近一次连贯谬误的工夫戳1 row in set (0.00 sec)提醒：执行flush hosts能够刷新host_cache，刷新后会革除内存中的主机缓存 ...

三高Mysql - Mysql索引和查问优化（偏实战局部） 实战局部回筛选一些比拟常见的状况，当时强调集体应用的是mysql 8.0.26，所以不同版本如果呈现不同测试后果也不要诧异，新版本会对于过来一些不会优化的查问进行优化。 实战局部承接上一篇文章：三高Mysql - Mysql索引和查问优化解说（偏实践局部） - 掘金 (juejin.cn) 前置筹备 这里还是要再啰嗦一遍，所有的数据库和表均来自官网的sakila-db，作为学习和相熟mysql数据库操作十分好。 sakila-db sakila-db是什么？国外很火的一个概念，指的是国外电影租赁市场外国人应用租赁的形式进行电影的观看，过来非常受外国人的喜爱，这里拿进去介绍是因为后续的内容都用到了这个案例，所以咱们须要提前把相干的环境筹备好，从如下地址进行下载： 下载地址：https://dev.mysql.com/doc/ind... work-bench work-bench是官网开发的数据库关系图的可视化工具，应用官网案例的具体关系图展现成果如下，通过这些图能够看到Sakila-db之间的大抵关系： work-bench 是免费软件，下载地址如下： https://dev.mysql.com/downloa... 装置workbench和下载sakila-db的过程这里不做记录，在运行的时候须要留神先建设一个数据库运行Sheme文件，而后执行data的sql文件，最终借助navicat中查看数据和表构造关系： 注释局部where查问太慢怎么办？ 遇到where查问太慢，咱们第一步是须要剖析数据类型的组成以及数据表的设置是否正当，其次咱们能够应用explain对于查问语句进行剖析，应用形式非常简略在须要优化的查问语句后面增加explain语句，对于所有的查问来说，笼罩索引的查找形式是最优解，因为笼罩索引不须要回表查数据。 笼罩索引：笼罩索引是查问形式，他不是一个索引，指的是在查问返回后果的时候和应用的索引是同一个，这时候能够发现他压根不须要回表，间接查辅助索引树就能够失去数据，所以笼罩索引的查问效率比拟高。 如何应用sql语句查看某一个表的建表语句： 答复：应用show create table 表名称即可。 那么什么状况下会应用笼罩索引： 查问字段为辅助索引的字段或者聚簇索引的字段。合乎最左匹配准则，如果不是最左匹配则不能走索引。 咱们应用下面提到的sakila-db进行试验，这里能够应用inventory表作为试验，然而这个表须要进行一些调整，上面请看具体的sql： CREATE TABLE `inventory_test` ( `inventory_id` mediumint unsigned NOT NULL AUTO_INCREMENT, `film_id` smallint unsigned NOT NULL, `store_id` tinyint unsigned NOT NULL, `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`inventory_id`), -- KEY `idx_fk_film_id` (`film_id`), KEY `idx_store_id_film_id` (`store_id`,`film_id`) -- CONSTRAINT `fk_inventory_film` FOREIGN KEY (`film_id`) REFERENCES `film` (`film_id`) ON DELETE RESTRICT ON UPDATE CASCADE, -- CONSTRAINT `fk_inventory_store` FOREIGN KEY (`store_id`) REFERENCES `store` (`store_id`) ON DELETE RESTRICT ON UPDATE CASCADE) ENGINE=InnoDB AUTO_INCREMENT=4582 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci; 咱们将原始的sql建表语句只保留一个辅助索引，比方在下面的语句中删除了idx_fk_film_id索引，上面删除这个索引之后的试验成果： ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。MySQL 次要索引类型有如下几种：1.主键索引2.惟一索引3.一般索引4.空间索引5.全文索引假如有如下一张表CREATE TABLE `t1` ( `id` bigint unsigned NOT NULL AUTO_INCREMENT, `u1` int unsigned NOT NULL DEFAULT '0', `u2` int unsigned NOT NULL DEFAULT '0', `u3` varchar(20) NOT NULL DEFAULT '', `u4` varchar(35) NOT NULL DEFAULT '', PRIMARY KEY (`id`)) ENGINE=InnoDB聚簇索引索引与数据寄存在一起，找到索引的同时也找到了数据；聚簇索引具备唯一性，一张表只有一个聚簇索引。 聚簇索引默认是主键，如果表中没有定义主键，InnoDB 会抉择一个非空惟一索引代替。如果没有，InnoDB 会定义一个暗藏的_rowid 列来作为聚簇索引。非聚簇索引索引与数据离开寄存，索引构造的叶子节点指向了数据的对应行。主键索引# 查看创立的索引关键词PRIMARY KEY (`id`)惟一索引索引列的值必须惟一，但容许有空值。如果是组合索引，则列值的组合必须惟一# 创立惟一索引mysql> alter table t1 add unique idx_u1(`u1`);# 查看创立的索引关键词UNIQUE KEY `idx_u1` (`u1`)单列索引即索引创立在单个列上# 创立单列索引mysql> alter table t1 add index idx_u1(`u1`);# 查看创立的索引关键词KEY `idx_u1` (`u1`)多列索引创立多列索引时记得遵循最左匹配准则，把区分度较高的字段放后面# 创立多列索引mysql> alter table t1 add index idx_u1_u2(`u1`,`u2`);# 查看创立的多列索引关键词KEY `idx_u1_u2` (`u1`,`u2`)前缀索引即当字段的长度超过索引限度，能够为字段的局部前缀创立索引# 创立前缀索引，取字符串的前4个字符mysql> alter table t1 add index idx_u3(`u3`(4));# 查看创立的索引关键词KEY `idx_u3` (`u3`(4))倒序索引8.0 版本出的新性能，以往创立顺叙索引能够创立胜利，但实际上依然是程序的# 5.7 创立倒序索引mysql> select u1 from t1 limit 10;+----+| u1 |+----+| 12 || 23 || 12 || 34 |+----+10 rows in set (0.00 sec)# 创立倒序索引mysql> alter table t1 add index idx_u3(u3 desc);# 理论查出来还是程序mysql> select u1 from t1 limit 10;+----+| u1 |+----+| 12 || 12 || 12 || 12 |+----+# 8.0 创立倒序索引mysql> select u1 from t1 limit 5;+----+| u1 |+----+| 12 || 23 || 12 || 34 |+----+5 rows in set (0.00 sec)# 增加索引mysql> alter table t1 add index idx_u1(u1 desc);# 查问倒序索引胜利mysql> select u1 from t1 limit 5;+----+| u1 |+----+| 74 || 74 || 74 || 74 |+----+5 rows in set (0.00 sec)函数索引# 创立函数索引mysql> alter table t1 add index idx_abs_u2 ((ABS(`u2`)));# 查看创立的索引关键词KEY `idx_abs_u2` ((abs(`u2`)))表达式索引# 创立表达式索引mysql> alter table t1 add index idx_u1u2 ((u1 + u2));# 查看创立的索引关键词KEY `idx_u1u2` (((`u1` + `u2`)))不可见索引# 设置不可见（invisible），批改为可见（visible）mysql> ALTER TABLE t1 ALTER INDEX idx_u1 INVISIBLE;# 查看不可见索引关键词KEY `idx_u1` (`u1` DESC) /*!80000 INVISIBLE */# 解析查问时时全表扫描mysql> explain select * from t1 order by u1 desc limit 3;+----+-------------+-------+------------+------+---------------+------+---------+------+-------+----------+----------------+| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |+----+-------------+-------+------------+------+---------------+------+---------+------+-------+----------+----------------+| 1 | SIMPLE | t1 | NULL | ALL | NULL | NULL | NULL | NULL | 50184 | 100.00 | Using filesort |+----+-------------+-------+------------+------+---------------+------+---------+------+-------+----------+----------------+1 row in set, 1 warning (0.01 sec)# 执行SQL时即使force index也不可用，提醒不存在mysql> explain select * from t1 force index(idx_u1) order by u1 desc limit 3;ERROR 1176 (42000): Key 'idx_u1' doesn't exist in table 't1'空间索引空间索引是对空间数据类型的字段建设的索引，MYSQL应用SPATIAL关键字进行扩大，使其可能在空间数据类型的语法上创立空间索引。# 建表CREATE TABLE `gis_position` ( `id` int NOT NULL, `gis` geometry NOT NULL COMMENT '空间地位信息', `geohash` varchar(20) GENERATED ALWAYS AS (st_geohash(`gis`,12)) VIRTUAL, primary key(`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='空间地位信息';# 创立空间索引mysql> alter table gis_position add SPATIAL KEY `idx_gis` (`gis`) ;# 查看索引要害信息SPATIAL KEY `idx_gis` (`gis`)全文索引# 创立全文索引mysql> alter table t1 add fulltext index idx_fulltext_u4(`u4`) with parser ngram;# 查看索引要害信息FULLTEXT KEY `idx_fulltext_u4` (`u4`) /*!50100 WITH PARSER `ngram` */Enjoy GreatSQL :) ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。理论知识谬误日志内容谬误日志蕴含mysqld启动和敞开的工夫信息，还蕴含诊断音讯，如服务器启动和敞开期间以及服务器运行时呈现的谬误、正告和其余须要留神的信息。例如：如果mysqld检测到某个表须要查看或修复，会写入谬误日志。 依据谬误日志配置，谬误音讯还可能填充performance_schema.error_log表，以便为日志提供SQL接口，使谬误日志可能查问。 如果用mysqld_safe启动mysqld，mysqld_safe会将音讯写入谬误日志。例如，当mysqld_safe留神到mysqld异样退出时，它会重新启动mysqld，并将mysqld重新启动的音讯写入谬误日志。 谬误日志组件架构在MySQL 8.0中，谬误日志应用MySQL组件（component） 架构。谬误日志零碎由执行日志事件过滤和写出组件以及零碎变量组成，该零碎变量配置启用哪些组件来实现所需的日志记录。 基于组件的谬误日志记录提供了以下性能: 过滤器组件能够过滤日志事件，以影响写入的信息。日志事件由sink(写出)组件输入。能够启用多个写出组件，以将谬误日志输入到多个指标。内置的过滤和写出组件联合起来实现默认的谬误日志格局。反对JSON格局的日志记录。反对记录到操作系统日志。 log_error_services零碎变量管制为谬误记录启用哪些日志组件。多个组件用逗号或分号分隔，日志零碎依照此程序顺次执行。组件分过滤filter和写出sink两类。filter类组件过滤谬误日志信息，sink类组件将谬误日志写到不同的地位。 filter类组件过滤器组件过滤根据相干零碎变量log_filter_internal谬误事件的优先级及错误代码log_error_verbosity log_error_suppression_listlog_filter_dragnet用户定义的规定dragnet.log_error_filter_rulessink类组件零碎变量log_error指定谬误日志的缺省目的地，日志组件依据该零碎变量决定本人的日志输入目的地。 sink类日志组件log_error值目的地log_sink_internal（缺省）file_namefile_namelog_sink_internalstderr控制台log_sink_jsonstderr控制台log_sink_jsonfile_namefile_name.00.jsonfile_name.01.jsonlog_sink_teststderr控制台log_sink_testfile_namefile_namelog_sink_syseventlogstderr系统日志log_sink_syseventlogfile_name系统日志2. 运维操作查问以后的谬误日志配置（示例为缺省值）mysql> SELECT @@GLOBAL.log_error_services;+----------------------------------------+| @@GLOBAL.log_error_services |+----------------------------------------+| log_filter_internal; log_sink_internal |+----------------------------------------+查问已装置的组件mysql> select * from mysql.component;+--------------+--------------------+----------------------------------------+| component_id | component_group_id | component_urn |+--------------+--------------------+----------------------------------------+| 1 | 1 | file://component_log_sink_syseventlog |+--------------+--------------------+----------------------------------------+1 row in set (0.00 sec)配置谬误日志写出json格局装置sink组件log_sink_json，批改log_error_services参数减少log_sink_json写出组件。 mysql> INSTALL COMPONENT 'file://component_log_sink_json';SET GLOBAL log_error_services = 'log_filter_internal; log_sink_internal; log_sink_json';配置log_sink_internal组件指标：配置log_sink_internal组件只记录ERROR类信息。 办法：批改启动参数文件，调整log_error_verbosity参数。 [mysqld]log_error_verbosity=1 指标：配置log_sink_internal记录ERROR, WARNING, INFORMATION类谬误，将 WARNING, INFORMATION中谬误号MY-010001,MY-10002过滤掉。 办法：批改启动参数文件，调整log_error_verbosity和log_error_suppression_list参数 [mysqld]log_error_verbosity=3 log_error_suppression_list='MY-010001,10002'配置应用log_filter_dragnet过滤器指标：配置过滤器，依照用户定义的规定过滤谬误日志信息。 办法：应用log_filter_dragnet，配置变量dragnet.log_error_filter_rules增加过滤规定。 mysql>INSTALL COMPONENT 'file://component_log_filter_dragnet';SET GLOBAL log_error_services = 'log_filter_dragnet; log_sink_internal';SET GLOBAL dragnet.log_error_filter_rules = ' IF prio>=INFORMATION THEN drop. IF prio>=WARNING THEN throttle 1/60. IF EXISTS source_line THEN unset source_line.';配置谬误日志写入Linux系统日志指标：将MySQL的谬误日志写入Linux系统日志。 ...

一、前言上周老周的一个好敌人让我出一篇教你读懂 SQL 执行打算，和我另一位读者反馈的面试题如何排查慢 SQL 的强相干，索性先出一篇一文读懂 MySQL Explain 执行打算。Explain 执行打算你肯定得会看，不然你简历上就别去写什么你会 SQL 调优，不然面试官会感觉，Explain 执行打算你都不会看，那你还 SQL 调啥优啊？SQL 调你吧？？？开个小玩笑，玩笑归玩笑，重要是真的重要！！！ 二、Explain 执行打算是什么？什么是执行打算？简而言之，就是 SQL 在数据库中执行时的体现状况，通常用于 SQL 性能剖析、优化和加锁剖析等场景，执行过程会在 MySQL 查问过程中由解析器，预处理器和查问优化器独特生成。在 MySQL 中应用 explain 关键字来查看。 2.1 执行打算有什么用？它能够用来剖析 SQL 语句和表构造的性能瓶颈 关联查问的执行程序查问操作的操作类型哪些索引能够被命中哪些索引理论被命中每张表有多少记录参加查问...2.2 MySQL 执行过程 如上图所示，MySQL 数据库由 Server 层和 Engine 层组成： Server 层有 SQL 分析器、SQL优化器、SQL 执行器，用于负责 SQL 语句的具体执行过程；Engine 层负责存储具体的数据，如最常应用的 MyISAM、InnoDB 存储引擎，还有用于在内存中存储长期后果集的 TempTable 引擎。SQL 优化器会剖析所有可能的执行打算，抉择老本最低的执行，这种优化器称之为：CBO（Cost-based Optimizer，基于老本的优化器）。 而在 MySQL 中，一条 SQL 的计算成本计算如下所示： Cost = Server Cost + Engine Cost= CPU Cost + IO Cost其中，CPU Cost 示意计算的开销，比方索引键值的比拟、记录值的比拟、后果集的排序等这些操作都在 Server 层实现； ...

MySQL VersionMySQL 8.0.20 索引定义索引一种非凡的数据结构，为表中的数据行提供疾速查找性能，通常通过一个树结构（B树）来示意特定的列，或者一组列的所有值。Innodb引擎中的表有一个示意主键的汇集索引，还能够在一个列或者多个列上创立一个或多个二级索引。依据二级索引的构造，能够分为局部索引（col_name (length)），列索引（col_name），组合索引（col_name1,col_name2,...） 大多数 MySQL 索引（PRIMARY KEY、 UNIQUE、INDEX和 FULLTEXT）都存储在 B-trees中。例外：空间数据类型的索引应用 R-trees；MEMORY 表也反对散列索引；InnoDB应用倒排列表作为FULLTEXT索引 索引类型主键索引一种惟一索引，必须指定的是primary key ,个别在创立表的时候指定，也能够通过批改表的形式指定alter table。Innodb要求每个表必须有一个主键索引 惟一索引这种索引和一般索引基本相同，惟一的一个区别就是索引中所有的值只能呈现一次，且必须惟一。如果为列的前缀局部作惟一索引，那列的前缀局部必须是惟一的，如果增加的值曾经存在会产生谬误 如果一个表中有一个主键索引或者非空的惟一索引且是由单个的整数类型组成的，能够在select语句中应用此索引列_rowid，具体情况如下： 如果主键是由单个整数列组成的，则_rowid指向主键列，如果存在主键，但不是蕴含单个整数列，则不能应用_rowid_rowid指定第一个非空惟一索引的列，前提是该索引列是由单个整数类型组成的，如果第一个非空的惟一索引列是不蕴含单个整数类型的列，则不能应用_rowid一般索引一般的索引，没有任何的限度，也是咱们罕用的索引 全文索引全文索引仅反对Innodb和MyISAM，并且列的类型只能是char,varchar,text,不反对前缀索引，如果指定了也有效，会被疏忽。 空间索引MyISAM,Innodb,NDB,ARCHIVE 存储引擎反对point和geometry等空间列，然而不同的存储引擎对空间列索引的反对是不同的，空间列的空间和非空间索引能够依据一下规定应用。 空间列上的空间索引具备以下特色： 仅对Innodb和MyISAM引擎失效，为其余引擎指定空间索引会报错从mysql8.0.12开始，空间列的索引必须是空间索引（SPATIAL），因而SPATIAL关键字是可选的，然而对于空间列上创立索引是隐式的仅能在单个空间列上创立空间索引，不能在多个列上创立空间索引索引列不能为空不能指定列前缀长度，列的整体被退出索引不能用于主键索引或者惟一索引InnoDB Storage Engine Index Characteristics 参考链接https://dev.mysql.com/doc/ref...

在上一篇文章中，咱们介绍了MySQL中常见的索引类型以及每种索引的各自特点，那么这篇文章带你来与我一起看一下汇集索引与二级索引的关系，最初在附上常见的索引优化计划。首先咱们还是看一下汇集索引和二级索引的区别 https://mp.weixin.qq.com/s?__... 汇集索引和二级索引区别首先，每个Innodb引擎的表都有一个汇集索引，用于存储行数据，通常状况下，汇集索引也叫做主键索引。 如果一个表定义了主键，Innodb就应用它作为汇集索引。因而咱们要尽可能的为表增加一个主键，如果切实没有一个列是非空且惟一的能够作为主键列，倡议增加一个主动递增的列作为主键列如果表没有主键，Innodb会抉择第一个非空且惟一的列作为汇集索引如果表既没有主键，也没有非空且惟一的索引，则Innodb生成一个暗藏的汇集索引，GEN_CLUST_INDEX 蕴含rowid值的列，数据行依据rowid排序，rowid是一个6字节的字段，随着数据插入而枯燥递增，也就是说，数据行依据rowid排序也就是依据插入程序排序的在下面，咱们晓得了主键索引也就是汇集索引，而且咱们的日常工作中，查问如果依据主键查问都是很快的，那么汇集索引是如何晋升查问效率的呢？ 汇集索引如何晋升查问效率通过汇集索引拜访一条数据是很快的，这是因为所有的行数据和索引保留在同一个页上。如果表数据特地大，相较于数据和索引保留在不同的页上的存储构造相比，Innodb大大节俭了磁盘IO操作 当初咱们晓得了汇集索引之所以查问的快是因为要查问的行数据和索引都保留在同一个页上，也就缩小了去磁盘查找数据的过程，那么二级索引呢，二级索引是如何与汇集索引关联的呢？ 二级索引如何与汇集索引关联汇集索引之外的其它索引全副被称为二级索引。在Innodb中，二级索引中的每条记录都蕴含主键列以及自身二级索引指定的索引列，在汇集索引中，Innodb应用此主键值查问该行的数据 如果主键较长的话，那么咱们二级索引保留主键列时就会占用更多的空间，所以主键尽可能的短是无利的 读到这，咱们应该曾经晓得了，汇集索引中所有记录与索引都保留在同一个页中，所以这也是汇集索引查问快的起因。二级索引没有保留以后记录的数据，只保留了主键列，所以在应用二级索引的时候会波及到两步操作，即依据二级索引先定位主键列，而后依据主键列在汇集索引中查问数据返回。当初咱们也晓得了，通过二级索引查找会波及到多一次交互的问题，那么这个点也是咱们后文将要探讨的一个点，也就是所谓的回表。目前咱们罕用的索引优化形式有笼罩索引、最左前缀、索引下推，当初咱们一起来具体看下索引的优化形式是怎么工作的 罕用的索引优化形式笼罩索引首先咱们还是新建一张表t，在k列建设索引，建表语句如下 create table t( id int primary key, k int not null default 0, s varchar(16) not null default '', index k(k))engine=Innodb;# 退出测试数据insert into t values(100,1, 'aa'),(200,2,'bb'),(300,3,'cc'),(500,5,'ee'),(600,6,'ff'),(700,7,'gg');在上文中，咱们曾经晓得了汇集索引与二级索引的区别，所以在执行完下面的插入语句之后，数据的存储构造为两棵索引树，一棵主键索引树蕴含数据，一棵二级索引k的索引树 此处借鉴一下极客工夫丁奇老师的索引结构图，此处放个不同数据结构存储图，这个网站不错，能够模仿数据结构的存储过程，给大家举荐一下，这块网站模仿的和丁奇老师的还是不一样，这块起因还不理解，对这块还不是很相熟，有理解的能够评论区说一下，互相学习一下。本文还是以丁奇老师解说的图为主 https://www.cs.usfca.edu/ 首先咱们执行一条查问语句 select * from t where k between 3 and 5;执行过程是这样的，首先到k索引树取到值为3的到主键索引树获取主键等于300的R3记录返回，而后取k索引树下一值5的主键500到主键索引树取500的记录R5，而后取k索引树下一个值6的主键600到主键树查问，发现6不符合条件，不再去主键树查问，返回后果 通过下面的剖析，那么什么是笼罩索引呢，很简略，咱们看上面两条sql语句 1、explain select * from t where k between 3 and 5;2、explain select id from t where k between 3 and 5;两条语句的执行剖析后果如下 ...

序本文次要钻研一下mysql的树形构造存储及查问 存储parent这种形式就是每个节点存储本人的parent_id信息建表及数据筹备 CREATE TABLE `menu` (`id` int(11) NOT NULL AUTO_INCREMENT,`name` varchar(50) NOT NULL,`parent_id` int(11) NOT NULL DEFAULT '0',PRIMARY KEY (`id`)) ENGINE=InnoDB;INSERT INTO `menu` (`id`, `name`, `parent_id`) VALUES(1, 'level1a', 0),(2, 'level1b', 0),(3, 'level2a-1a',1),(4, 'level2b-1a',1),(5, 'level2a-1b', 2),(6, 'level2b-1b', 2),(7, 'level3-2a1a', 3),(8, 'level3-2b1a', 4),(9, 'level3-2a1b', 5),(10, 'level3-2b1b', 6);查问 -- 查问跟节点下的所有节点SELECT t1.name AS lev1, t2.name as lev2, t3.name as lev3FROM menu AS t1LEFT JOIN menu AS t2 ON t2.parent_id = t1.idLEFT JOIN menu AS t3 ON t3.parent_id = t2.idWHERE t1.name = 'level1a';+---------+------------+-------------+| lev1 | lev2 | lev3 |+---------+------------+-------------+| level1a | level2a-1a | level3-2a1a || level1a | level2b-1a | level3-2b1a |+---------+------------+-------------+-- 查问叶子节点SELECT t1.name FROMmenu AS t1 LEFT JOIN menu as t2ON t1.id = t2.parent_idWHERE t2.id IS NULL;+-------------+| name |+-------------+| level3-2a1a || level3-2b1a || level3-2a1b || level3-2b1b |+-------------+存储及批改上比拟不便，就是要在sql外头查问树比拟吃力，个别是加载到内存由利用本人结构存储path这种形式在存储parent的根底上，额定存储path，即从根节点到该节点的门路建表及数据筹备 ...

序本文次要钻研一下mysql如何用一个列来存储多个值 实例用bit类型建表及数据筹备 -- 这里定义了bit(3)，示意有3位，第一位1，第二位2，第三位4create table t_bit_demo( id int NOT NULL AUTO_INCREMENT PRIMARY KEY, multi_value bit(3) not null default 0);-- 这里插入了1，2，4的组合值insert into t_bit_demo(multi_value) values(b'000');insert into t_bit_demo(multi_value) values(b'001');insert into t_bit_demo(multi_value) values(b'010');insert into t_bit_demo(multi_value) values(b'011');insert into t_bit_demo(multi_value) values(b'100');insert into t_bit_demo(multi_value) values(b'101');insert into t_bit_demo(multi_value) values(b'110');insert into t_bit_demo(multi_value) values(b'111');-- 这里直接插入int值也能够，比方5相当于101-- insert into t_bit_demo(multi_value) values(5);SELECT multi_value+0, BIN(multi_value) FROM t_bit_demo;+---------------+------------------+| multi_value+0 | BIN(multi_value) |+---------------+------------------+| 0 | 0 || 1 | 1 || 2 | 10 || 3 | 11 || 4 | 100 || 5 | 101 || 6 | 110 || 7 | 111 |+---------------+------------------+位运算查问 ...

序本文次要展现如何应用mysql的多列组合查问 何为多列组合查问呢，就是查问的值不再是单个列的值，而是组合列的值。比方where (column1,column2) in ((a1,b1),(a2,b2),(a3,b3))实例建表create table t_demo( id int NOT NULL AUTO_INCREMENT PRIMARY KEY, name varchar(10), score int);insert into t_demo(name,score) values('a',10);insert into t_demo(name,score) values('b',20);insert into t_demo(name,score) values('c',30);insert into t_demo(name,score) values('d',40);insert into t_demo(name,score) values('d',50);insert into t_demo(name,score) values('e',60);多列in查问select * from t_demo where (name,score) in (('c',30),('e',60));+----+------+-------+| id | name | score |+----+------+-------+| 3 | c | 30 || 6 | e | 60 |+----+------+-------+2 rows in setTime: 0.112s多列=查问select * from t_demo where (name,score) = ('c',30) or (name,score) = ('e',60);+----+------+-------+| id | name | score |+----+------+-------+| 3 | c | 30 || 6 | e | 60 |+----+------+-------+2 rows in setTime: 0.119s小结多列组合查问平时比拟少见，首次看还感觉挺神奇的。 ...

前言最近整顿一份对于MySQL常见面试题的，也会依据本人的教训， 标注一些呈现的概率，最高5颗★呈现的概率最高。比方这样: 百万级别或以上的数据如何删除 呈现概率: ★★★ 一般来讲在面试当中， 对于数据库相干的面试题频率呈现比拟高的几个关键词是SQL优化、索引、存储引擎、事务、死锁、乐观锁、乐观锁、关系型数据库和非关系数据库比照等等。 把这几个点问完根本也差不多10~20分钟了(个别一轮面试1小时左右), 根本这些能够让面试官对你的数据库常识有肯定的理解了。 如果你线上运维教训, 个别也会问一些比方数据库扩容, 如何给大表加索引, 如何在业务顶峰是给一个大表增加字段等。 也欢送关注我的公众号: 散步coding。 一起交换, 在coding的世界里散步。 心愿这篇文章能够帮忙大家, 也心愿大家都能找到找到的好工作。 也能够通过我的博客地址: 在线浏览 一、数据库基础知识0、概要1、平时MySQL次要用哪个版本2、数据库三大范式是什么3、MySQL无关权限的表都有哪几个4、MySQL的binlog有有几种录入格局？别离有什么区别？5、平时用到哪些关系型数据库和非关系数据库, 能够谈谈你对它们的了解吗?6、能够简略说说你对MySQL的逻辑架构理解吗？7、理解MySQL中的MVCC是什么?8、PostgreSQL绝对于MySQL的劣势9、PostgreSQL和MySQL的一些区别1、平时MySQL次要用哪个版本呈现概率: ★★★★ 能够说说本人用的MySQL版本, 比方我本人用的版本是5.7版本，而后能够也简略聊聊这个版本的一些特点: 1)、安全性 在MySQL 5.7中，有不少安全性相干的改良。包含： MySQL数据库初始化实现当前，会产生一个 root@localhost 用户，从MySQL 5.7开始，root用户的明码不再是空，而是随机产生一个明码，这也导致了用户装置5.7时发现的与5.6版本比拟大的一个不同点。 MySQL官网曾经删除了test数据库，默认装置完后是没有test数据库的，就算用户创立了test库，也能够对test库进行权限管制了MySQL 5.7版本提供了更为简略SSL平安拜访配置，并且默认连贯就采纳SSL的加密形式。 能够为用户设置明码过期策略，肯定工夫当前，强制用户批改明码。 2)、灵活性 MySQL 5.7的两个全新的性能，即JSON和generate column CREATE TABLE t1 (jdoc JSON);INSERT INTO t1 VALUES('{"key1": "value1", "key2": "value2"}');3)、可用性 在线设置复制的过滤规定，不再须要重启MySQL，只须要进行SQL thread，批改实现当前，启动SQL thread 这个次要大抵谈谈你本人的了解， 也能够依据本人的了解多延展一些， 进步面试的加分。 2、数据库三大范式是什么呈现概率: ★★★ 第一范式：每个列都不能够再拆分。 第二范式：在第一范式的根底上，非主键列齐全依赖于主键，而不能是依赖于主键的一部分。 第三范式：在第二范式的根底上，非主键列只依赖于主键，不依赖于其余非主键。 在设计数据库构造的时候，要尽量恪守三范式，如果不恪守，必须有足够的理由。比方性能。事实上咱们常常会为了性能而斗争数据库的设计。 3、MySQL无关权限的表都有哪几个呈现概率: ★★★ MySQL服务器通过权限表来管制用户对数据库的拜访，权限表寄存在mysql数据库里，由mysql_install_db脚本初始化。这些权限表别离user，db，table_priv，columns_priv和host。上面别离介绍一下这些表的构造和内容： user权限表：记录容许连贯到服务器的用户帐号信息，外面的权限是全局级的。 db权限表：记录各个帐号在各个数据库上的操作权限。 table_priv权限表：记录数据表级的操作权限。 columns_priv权限表：记录数据列级的操作权限。 host权限表：配合db权限表对给定主机上数据库级操作权限作更粗疏的管制。这个权限表不受GRANT和REVOKE语句的影响。 ...

在之前公布的《墨天轮最受欢迎的技术文档-容灾备份篇》中，大家说想看故障解决案例篇的内容，这不！编辑部快马加鞭给大家整顿来了，心愿可能帮忙到大家。 数据库故障可能呈现在内存、网络、CPU、硬盘等多个环节，然而是否疾速诊断故障起因并高效地剖析、解决得靠长时间的教训积攒。有专家说，“诊断故障是一种能力， 防止故障同样也是能力”，如果能在故障产生前提前从日常监控中发现端倪，或者就能防止简单问题的呈现。 本文整顿了社区上一些数据库故障诊断思路、解决办法以及在日常运维中为避免故障产生能够进行的监控、配置优化形式和注意事项相干文档，次要蕴含 Oracle、MySQL 以及 PostgreSQL 三类数据库，欢送大家下载、补充。 Oracle-- 解决手册以下文档较系统地对故障可能呈现的环境及相应的故障解决办法进行了整顿记录，敌人们能够自行查看。 Oracle 数据库故障解决应急计划 Oracle 数据库多种故障场景 Rman 复原手册 Oracle DataGurd日常保护及故障解决 Oracle DBA 数据库项目组日常运维及应急故障解决手册  -- 多案例剖析PPT这部分文档中蕴含了诸如云和恩墨李真旭、姜劲松、张维照、尹涛等诸位老师整顿的 Oracle 故障诊断办法及避坑形式，联合具体的案例场景为大家解说了解决办法，欢送大家下载学习解决办法与剖析思路。 真实世界 Oracle 故障诊断一千零一夜 Oracle RAC 高并发零碎的故障诊断 OGG 日常运维及故障解决 从内存故障到 CPU 过高 Oracle 诊断案例(上) 从内存故障到 CPU 过高 Oracle 诊断案例(下) 高并发 Oracle OLTP 零碎的故障案例分享 我的故障剖析及解决思路分享——李真旭  -- 单个实战案例在墨天轮的问答板块中，常常可能看到大家遇到故障后的求助，类型十分多。从题目能够看出，这部分内容则是针对 Oracle 单个故障的解决办法所作的记录，具体地形容了问题的表象以及对故障的诊断剖析与解决方案。 数据库未设置大页，导致集群心跳超时，私网不通，节点频繁重启 某三甲医院 _HIS 零碎节点宕机故障剖析 从 Oracle 数据库故障到 AIX 内存治理 数据库服务器主机重启故障诊断剖析 异样掉电导致的 ORA-600 kfrValAcd30 故障解决 ORA-00600 4194故障解决   ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。一、update跟踪执行配置应用外部程序堆栈跟踪工具path_viewer，跟踪mysql update 一行数据的执行过程，配置执行脚本：call_update.shDROP DATABASE IF EXISTS d1;CREATE DATABASE d1;use d1;drop table if exists test;CREATE TABLE test (c0 int NOT NULL AUTO_INCREMENT,c1 date DEFAULT NULL,c2 time DEFAULT NULL, c3 datetime DEFAULT NULL, c4 year DEFAULT NULL, c5 int DEFAULT NULL, c6 decimal(10,6) DEFAULT NULL, c7 double DEFAULT NULL, c8 float DEFAULT NULL, c9 varchar(255) DEFAULT NULL, PRIMARY KEY (c0)) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;INSERT INTO test VALUES ('1', '2021-04-26', '15:36:37', NULL, '2021', NULL, '6.000000', '7.1', '118.169', 'a8.168111');INSERT INTO test VALUES ('2', '2021-04-28', '15:36:37', '2021-04-27 15:36:41', '2021', '6', '7877.126000', '8.1', '119.187', 'a9.16');INSERT INTO test VALUES ('3', '2021-04-29', '15:36:37', '2021-04-27 15:36:41', '2021', '6', '7877.126890', '8.1', '119.187', 'a9.1682');INSERT INTO test VALUES ('4', '2021-04-30', '15:36:37', '2021-04-27 15:36:41', '2021', '6', '7877.126890', '8.1', '119.187', 'a9.168333');EOFsleep 1mysql -h127.0.0.1 -P3300 -uroot <<EOF use d1;\! ./util/start_trace.shupdate test set c7=10.1 where c0=1;\! ./util/end_trace.shEOF# analyse the data./util/seperate.sh $TOPIC 10000 5~ 执行后，生成执行后果： ...

导读： 俄乌战局日益焦灼，东方各国相继发表制裁俄罗斯，Oracle、IBM、微软、SAP等各大科技巨头相继发表暂停对俄罗斯服务，这一系列制裁动作让技术人意识到“科技无国界”是个伪命题。俄罗斯的前事不忘;后事之师无疑给中国的数据库人敲响了警钟，开源有国界吗？国内数据库以及相干从业者该走向何方？国产数据库的代替化之路还有多远呢？ 这些问题的解决火烧眉毛。墨天轮作为数据人的技术成长社区，致力于 “想数据人所想，懂数据人所需”，明天咱们邀请到三位资深的数据库行业专家一起”闪现“俄罗斯，聚焦俄罗斯现有数据库行业相干问题、中国数据库行业及技术从业者倒退方向等问题，进行解读和分享。 韩锋金融行业数据库资深专家CCF（中国计算机学会）理事曾负责多家公司首席DBA，数据库架构师等职位 白鳝（徐戟）PostgreSQL ACE Director南京基石数据技术有限责任公司CTO公众号【白鳝的洞穴】作者 薛晓刚某公司数据库总监，行业资深数据库研究员从业10余年，次要从事设计、施行和运维高并发的数据架构曾服务于z府、交通、安防行业，从事过大型项目管理，单机解决超过100亿量级的数据库  —— 以下为采访注释 —— ❓ ：如果此刻您正身处俄罗斯并承当雷同的岗位，面对制裁可能就业、转行，是挑战也是时机，请联合您集体的工作谈谈当下会怎么做？将来有什么职业规划？ 韩锋： 首先拓宽本人的技术栈。 不仅局限于某种产品，开阔视野尝试接触更多技术。其次，晋升技术档次。 从使用者角色，逐渐降级到架构；布局层面；解脱对单项业余技术的依赖，晋升通用化技能要求。尝试多元化职业倒退，扩充本人可抉择范畴。 如从事数据库运维，可尝试在数据分析、数据治理、数据研发、数据库征询、产品等方向倒退。投身国产。 作为近年来的倒退热点，国产数据库行业正处于疾速倒退阶段，机会十分多。最初转变意味着时机。上述因素会对行业造成影响，同时也会带来新的机会，例如转型征询等。 白鳝： 对于Oracle等东方数据库厂商暂停俄罗斯的数据库相干服务，从短期来看，对DBA来说是一个利好，无论是服务于Oracle等原厂的DBA还是服务于企业的DBA，因为客户的数据库服务需要并不会马上隐没。原厂进行服务对于第三方服务来说，是个短期利好。从中长期来说，数年内，Oracle等数据库的服务还会有肯定的连续，不会马上呈现量变，因而在肯定期间内，Oracle DBA的生存环境不会很快好转。不过随着国家或者一些企业采取的躲避危险的措施，Oracle等东方主导的数据库产品的市场份额会逐步升高，更多的俄国企业会抉择开源或者国产数据库。在俄罗斯，POSTGRESQL、MySQL等的用户群体也非常宏大。因为俄罗斯的国产数据库产业规模很小，因而填补Oracle空白的必然是开源数据库，这些开源数据库份额晋升的速度会放慢。从长期来说，5-10年后，俄国的数据库市场会有较大的变动，国产数据库品牌也会有长足的倒退，因而数据库研发畛域的就业机会会大增。对于有肯定编程教训的DBA来说，投身数据库产品研发的时机很好。不过绝对比中国来说，俄国在IT基础设施等畛域的根底绝对单薄，开源数据库成为支流的可能性比拟大。如果我身处于这种环境中，能够有多种抉择。（1）持续深入研究ORACLE数据库的运维与优化，使本人在技术上可能达到或者超过原厂工程师的能力，那么我在将来的相当长时间内，在行业里仍然有很强的职业竞争力；（2）如果我要转型，在Oracle DBA需要不降反增的期间，致力赚钱，并利用这段时间进行转型，我会抉择学习PostgreSQL，一个ORACLE DBA转行做PG DBA，难度不大，而且PG DBA的需要会在将来逐步扩充；(3) 如果遇到一家靠谱的国产数据库公司，我也能够抉择转行去做国产数据库产品经理、产品策划甚至外围研发等工作。 薛晓刚： 如果我在俄罗斯所须要面临的就是各种数据库没有反对。对我而言其实影响不大， 我自身学习了Oracle、MYSQL、PostgreSQL、TiDB等等十几种，只有用数据库那么对我就没有什么影响。 反而来说如果这些数据库我都把握的八九不离十，如果没有原厂或者社区的反对，那么就由我来反对了。有人开玩笑说，如果哪天Oracle不给中国服务了，那么所有的服务都是恩墨的。我的老师之一是恩墨学院的首任院长。他说DBA有几种Database administrator；Database analyze，Database architect。数据库管理员、数据分析师、数据架构师。缩写都是DBA，我的布局就是做数据架构师。架构师是交融各种数据库和中间件以及设计外围逻辑实现的人。 ❓ ：如果您所在的公司与行业在俄罗斯发展雷同的业务，面对制裁是否会受影响？同时能够做哪些预案呢？</font> 韩锋： 我目前在一家金融企业，对以数据库为代表基础设施还是存在肯定依赖。金融行业，是数据密集性行业，重度依赖数据库，短期来看，没有太大影响，长期会有很大影响。从应答措施来看，可分为以下三方面：首先，提前预防。在国产化方面提前布局，有打算地逐渐代替；其次，无效躲避。防止重度依赖某款产品，通过兼容性规范进步通用适配能力；最初，应急解决。面对突发状况可疾速、安稳实现技术栈替换。 白鳝： 我认为影响不大。咱们次要从事智能化运维服务，这种服务能够通过私有云SAAS服务的形式提供，利用无国界的互联网来向所有须要咱们服务的客户提供线上服务。通过进步线上服务的比例，能够抵挡制裁带来的不利影响。 不过从负面的角度来看，公司会在引入美元资本投资，赴欧美上市，发展欧美市场业务方面产生不利影响。不过这方面都有代替选型，因而虽有影响，然而都能够解决。 薛晓刚： 我认为影响不大。制裁其实就是不卖商用，不容许应用开源，不提供服务，曾经购买过商用的不影响应用，俄罗斯甚至不买间接用。没有服务就本人发明，中国有能力的人还是很多的。第三方服务机构也有很多，相似恩墨、美创、中亦安图、新炬、沃趣等都是能够依附的搭档。  ❓ ：俄罗斯最大的盗版软件平台Rutracker全面凋谢，同时中国也存在很多企业应用盗版Oracle的状况，您感觉该如何防止盗版流行的状况？</font> 韩锋： 盗版景象，是客观存在的。但从客户角度来看，并不能通过应用盗版软件，解决上述危机。根底软件非常复杂，用好是须要从多角度思考，不能仅限于取得介质。从这点来看，开源软件无疑是解决问题的可能路径之一，通过凋谢获取路径及源代码凋谢，可在肯定水平上解决。当然，开源自身也可能受影响。 白鳝： Rutracker凋谢的问题实际上一些报道有失偏颇，这个最大的俄文盗版平台自身不在俄罗斯国内，只是以往俄罗斯互联网屏蔽了该网站，目前只是勾销了屏蔽而已。盗版等违反知识产权爱护国际法的做法永远不是一个正确的选项。俄罗斯暂停专利领取也是对等制裁东方解冻其资产的权宜之计，不会作为长期国策。 至于Oracle数据库的盗版问题，因为盗版的应用，才会导致Oracle在中国的市场占有率极高。 Oracle盗版对中国的信息化建设晚期有肯定的侧面作用，然而也妨碍了国产数据库的倒退。 我国的国产数据库起步其实并不晚，基本上和90年代末国内上关系型数据库风行工夫同步，不过在那段时间里东方呈现了SYBASE/INFORMIX/SQL SERVER等驰名的商用数据库，而在中国并没有在这一轮的关系型数据库大暴发阶段产生具备国内影响力的国产关系型数据库系统，这和国内过后不器重知识产权爱护，大量应用盗版数据库无关。盗版Oracle挤压了应该由国产关系型数据库占据的市场份额，咱们应该以此为戒，无论看待东方商用数据库还是国产数据库，都应该尊重知识产权，防止盗版。回绝盗版应该从大型国企、央企做起。 实际上盗版数据库的重灾区反而是国家机构和国企，因为IT投资估算的压缩无奈间接作用于必须洽购的硬件，同时IT管理人员对数据库版权机制不甚了解，有意无意间，数据库，中间件等就称为了盗版的重灾区。实际上国家没有必要给国产数据库厂家更多的财政补贴，而是应该通过进步党政机关与国企、央企的数据库产品的正版率，杜绝这些部门应用盗版数据库。 这种措施比给国产数据库厂家补贴更为无效。 薛晓刚： 我感觉盗版问题不能防止，这和咱们知识产权意识单薄有关系。大环境下没有建立付费理念。商用的盗版，开源的白嫖，甚至他人一开源，咱们就盲目应用，这也是存在的问题。这个问题可能从大环境能尊重劳动者开始，才有心愿解决。 当初连用Oracle都不付费，那么用国产的会付费吗？何况还能够收费应用开源的。只有尊重技术人员、尊重劳动成果、尊重产品的良好氛围造成了，先从购买开源软件的企业版做起，才有可能应用商用产品。否则只能等到许可证到期进行运行，这就又回到破解盗版问题上了。  ❓ ：”科技无国界“可能存在争议，但目前暂未有“开源数据库无奈在俄罗斯应用”的相干事实报道，您置信“开源”能做到无国界吗？</font> 韩锋： 开源自身是无国界的，但对于开源基金会、开源代码托管平台不能漠视其国家属性。作为整个开源生态链条的组成部分，受此影响必然也会对开源造成影响。齐全做到无国界的开源，从当初来看还是存在肯定艰难。 白鳝： 开源是无国界的，这一点到当初我也这么认为。不过开源的商业生态是有国界的，开源的许可协定是有国界的。 因为这两个问题的存在，可能会给人以开源软件有国界这个假象。 ...

1.explain是什么2.explain能做什么3.explain具体应用 1.explain是什么mysql的explain（查看执行打算）能够模仿数据库执行引擎执行sql语句，从而晓得mysql是如何解决你的sql语句的，进而剖析这个查问语句的瓶颈。 此外，mysql有本人的专门负责优化select语句的优化器模块，它会剖析你这个select语句，提供它认为最优的执行打算，比方去掉一些无用而不言而喻的条件（1=1）,结构调整（依据索引的程序调整where前面的程序）。 2.explain能做什么explain能够列出一个查问的执行打算，显示出以下这些信息1)表的读取程序2)数据读取的时候的操作类型3)哪些索引可能被应用4)**哪些索引理论被应用5)被应用的索引长度6)表之间的援用7)如果有分区，是哪个分区被应用7)每张表有多少行被优化器查问8)这些被查问的行，最终被查问出的无效数据命中率是多少9)一些额定的排序等信息 3.explain具体应用 3.1如何应用explain explain 你的查问语句 比方 explain select * from t_customer 执行结束后会查出很多信息： 咱们来挨个解释一下 3.2 idid示意select查问的序号，蕴含一组数字，示意查问中执行的select语句中操作表的程序 它会有两种状况：当id雷同的时候，执行程序由上到下： 咱们从图中能够看出，这个查问是先执行了t1，再执行t2的查问。 当id不同的时候，id值越大的越先被执行：咱们能够看出，这个查问先查问的是t2，而后再查问t1 3.3 select_typeselect_type会有以下的值： SIMPLE:简略的select查问，查问中不蕴含子查问或者union PRIMARY:若查问中蕴含任何简单的子局部，最外层的查问则被标记为PRIMARY SUBQUERY:在select或者where列表中蕴含了子查问 DEREVED:在from列表中蕴含的子查问被标记为DEREVED（衍生），mysql会递归执行这些子查问，把后果放到长期表外面。 UNION:若第二个select呈现在union之后，则被标记为union，如果union蕴含在from子句的子查问中，外层select将标记为DEREVED。 UNION RESULT:从union中取后果的select 3.4 tabletable显示这一行的数据是对于哪张表的。 3.5 partitions如果查问时基于分区表的查问，会显示查问将拜访的分区。 3.6 type type极为重要，是较为重要的一个指标，后果值从最好到最坏顺次为：system>const>eq_ref>ref>fulltext>ref_or_null>unique_subquery>index_subquery>range>index>All 这么写可能太多，咱们能够列举几个罕用的：system>const>eq_ref>ref_range>index>all system:表只有一行记录，间接查问就查到了，这种状况十分稀少。 const:数据示通过索引顺次就能够查到，罕用于主键或者惟一索引，只用匹配一行数据，如果主键置于where列表中，mysql就能将该查问转换为一个const。 eq_ref:惟一索引扫描，对于每个索引的key，表中只有一行记录能够和一个key匹配，这是除了下面那两种类型以外最好的类型了。 ref:应用到了索引，然而索引不是惟一索引，这个索引key可能会和多条数据匹配，会找到多条合乎数据的行。 range：范畴扫描，通常呈现在 <,>,between,in之类的语句中，用索引来检索一个给定的范畴。 index:index类型为遍历所有的索引，找到匹配的数据。 ALL：扫描数据库所有的行，找到匹配的数据。 index和all相比，一个是扫描所有的索引，一个是原表扫描所有的数据，所以index会比all快很多 3.7 possible_key 可能会用到的索引，然而不肯定在理论查问中被应用。 3.8 key 理论用到的索引，如果为null就是没用到索引。 3.9 key_len示意索引中应用的字节数，指要查问到这条数据应用的索引长度，长度越短越好。 3.10 ref显示索引哪一列被应用了。 3.11 rows要查出这条数据，大略须要扫描多少行，越少越好。 3.12 filtered示意通过rows筛选出的数据后，符合条件的比例，留神是百分比，不是记录总数。 如：扫描一行就能够得出数据，命中率是百分之一百 3.13 extra蕴含不适宜在其它列中显示，然而却非常重要的信息： Using filesort（坏）：阐明mysql无奈应用索引排序，会对数据应用一个内部的索引排序，而不是依照表内的索引程序进行读取。 Using temporary （坏）：应用了长期表的两头后果，mysql在对查问后果进行排序的时候应用了长期表，常见于order by 或者group by . ...

目前来说，网上有很多相干的材料证实ClickHouse数据库查问响应速度比MySQL快上一百到几百倍。实际上，ClickHouse和MySQL具备不同的利用场景和局限性，最近在钻研这个ClickHouse打算利用于大量数据的表来做查问的时候，踩了些坑，于是在此做个总结，用于后续做数据存储以及解决的时候作为备忘，以及对想要用ClickHouse替换MySQL数据库某局部数据存储的时候做个参考。 采纳 VersionedCollapsingMergeTree 引擎来做会产生批改然而不常批改的数据自身 ClickHouse 不适宜解决数据的频繁批改以及删除操作，对于删除和批改会耗费大量的性能，特地是频繁的单条数据批改。所以，通常咱们看到很多材料上说数据尽量批量写入，不论是以1000条，10000条还是多少条为一批，用以晋升ClickHouse的性能。 另外，自身ClickHouse的数据写入、批改、删除是异步的，对于操作写入、批改、删除后的数据须要做及时查问的，不适宜用ClickHouse来做存储，且ClickHouse不反对事务，所以ClickHouse不要用于数据一致性较高的场景。 在某些场景，可能数据通常来说是不须要批改的，然而某些场景须要批改一次或者几次，而后为了响应速度，心愿切换到ClickHouse来的话，能够采纳VersionedCollapsingMergeTree引擎来做数据存储，对于这个存储引擎，我这里能够简略介绍一下，具体的能够参考ClickHouse的具体文档。 这个存储引擎的大抵原理是，通过提供一个sign和一个version标记，sign存储的时候，值为1和-1，version存储数据的版本号，具体利用于以下两种场景的规定为： 须要删除的状况下，从新插入这一行的数据，version放弃不变，sign设置为-1，那么数据表就会存在两条除了sign不一样的反复数据。而后ClickHouse会定期执行合并折叠，把这样两条数据统一，然而两条sign相加为0的数据删掉。这里就须要留神一点，是定时合并革除的，所以查问的时候须要用group by之后，再做having(sign)>0)来手动排除删除的数据。批改的状况下，在做以上操作的同时，插入新数据，sign标记为1，version在上一次的根底上减少1即可。当然查问的时候，也须要进行手动排除前一个版本的数据。稠密索引不适宜用于准确查问在说这个稠密索引不适宜做准确查问之前，先来说以下我说的这种准确查问的场景： 须要依据某个加了索引的条件，比方id或者user_id来查问以后行的数据；须要依据某个加了索引的条件，如id或者user_id来取数据列表做分页ClickHouse 用的是稠密索引，和MySQL的B+树不一样。（对于稠密索引和B+树索引我这里不做介绍，这两个货色如果做介绍不是一时半会能解释分明，如果有人看到我这篇文章不理解的话，能够自行去先钻研一下。）,所以再做准确条件查问的时候，ClickHouse扫描数据量会很大，理论响应速度并不会达到现实的状态。 而对于ClickHouse采纳了稠密索引的状况，特地适宜用group by来做查问，通过几次group by 之后，就能排除大量的数据，所以通常状况下最适宜的场景就是用于解决统计查问，在这种状况下，大量数据状况下响应速度比MySQL快几十倍，几百倍就能提现进去了。 列式数据库不适宜一次性查问大量列另外就是ClickHouse的列式数据库的个性，基于以上说的，须要准确查问的场景，一次性须要查问大量的字段状况下，响应速度也没有设想的现实。就算式减少了很多个group by条件，最初因为须要扫描的列很多，在MySQL正确加索引的状况下，ClickHouse响应速度通常没有MySQL快。 ClickHouse 查问成果比 MySQL 稳固具体的测试我这里就不做多说，次要说一下场景。在两种数据表都正确做好索引的状况下，在做2亿数据列表查问的时候，MySQL在做分页数据查问的时候，开始的几页查问会显著比拟耗时，大略在500ms至800ms不等，然而后续的的分页查问基本上能达到50ms至80ms，这里应该是MySQL数据预热起了作用。然而ClickHouse基本上都是稳固在230ms至300ms。 总结以目前的测试和察看来看，如果须要做统计查问，且数据不是频繁批改的状况下，采纳ClickHouse来存储和解决数据查问。如果须要频繁批改或是做大数据列表查问的场景，最好的计划还是用MySQL查问，并对数据进行分表处理，失去的数据响应性能会比ClickHouse好太多。

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。[toc] 本文介绍MGR的选主算法，以及当MGR集群中有多个不同版本混搭时，如何能力失常运行，有什么注意事项。 1. 选主算法MGR运行在单主模式时，当产生主节点切换，就须要进行选主工作。多主模式下，所有节点都是主节点，就不须要选主了。 MGR的选主工作是主动的，每个节点都会参加。选主时会查看以后最新的组视图，对潜在的新主节点（各个备选节点）进行排序，最初选出最合适的那个作为新的主节点。 不同的MySQL版本选主算法略有不同，各节点选主时会依据以后的MySQL版本选主算法而决定，因而当MGR集群中有多个版本并存时，则此时MGR会做出调整，以便各个不同版本的节点都能就选主达成算法统一。 通常而言，选主算法的各个因素优先级程序如下： 依据MySQL版本号排序，低版本的优先级更高（因为要向下兼容）。如果是MySQL 8.0.17及以上版本，则优先依据补丁版本号排序（例如17、18、20）。如果是8.0.16及以下版本，则优先依据主版本号排序（例如5.7、8.0）。版本号雷同的各节点则依据各节点的权重值排序，权重越高优先级也越高。节点的权重值可通过设置 group_replication_member_weight 选项来调整。这个选项是MySQL 8.0版本引入的，如果是5.7版本则不反对。当版本号和节点权重值都一样时，再依据 server_uuid（或者说是 MEMBER_ID）排序（留神，不是 server_id），排在后面的优先级越高。MySQL Server在启动时，会生成一个随机的UUID值，其值记录在文件 datadir/auto.cnf 文件中，实际上能够在实例启动前，通过批改这个UUID值来扭转 server_uuid 的值，只有合乎UUID数据格式即可。因而，相当于是能够认为调整 server_uuid 以调整选主时节点的排序优先级。从下面可知，当有MySQL 8.0和5.7的节点混搭运行MGR集群时，运行5.7版本的节点会优先被选中，其次再依据 group_replication_member_weight 抉择权重搞的节点，最初再依据 server_uuid 排序。 因而，运行MGR集群时最好各节点版本号雷同，选主规定就简略多了。 在MySQL 8.0中，通过查问 performance_schema.replication_group_members 表的MEMBER_ROLE 即可晓得哪个是主节点： 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 | 4ebd3504-11d9-11ec-8f92-70b5e873a570 | 172.16.16.10 | 3306 | ONLINE | PRIMARY | 8.0.25 | <---主节点| group_replication_applier | 549b92bf-11d9-11ec-88e1-70b5e873a570 | 172.16.16.11 | 3307 | ONLINE | SECONDARY | 8.0.25 || group_replication_applier | 5596116c-11d9-11ec-8624-70b5e873a570 | 172.16.16.12 | 3308 | ONLINE | SECONDARY | 8.0.25 |+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+如果是在MySQL 5.7中，则须要通过查问 group_replication_primary_member 这个 status 能力晓得，比8.0麻烦。所以说，还是尽量应用MySQL 8.0来构建MGR集群。 ...

1.mysql锁的概述2.mysql的表锁及案例剖析3.mysql的行锁及案例剖析4.总结 1.mysql锁的概述 1.1锁的定义咱们先来看一下锁的定义：锁是计算机协调多个过程或者线程并发拜访某一资源的机制 那么在数据库中，数据也是一种供许多用户的共享资源，如何保证数据并发拜访的一致性，有效性，排他性，这也是所有数据库必须解决的一个问题，锁抵触也是影响数据库并发拜访性能的一个次要因素，从这些角度来看，锁对数据库显得尤其重要。 咱们举一个例子，淘宝购物。 假如咱们到购物网站上购买一个商品，这个时候库存为数不多，多集体一起抢购，那么如何解决是你买到还是他人买到的问题？ 这个时候，就须要用锁，对无限的资源进行爱护，解决并发的矛盾。 1.2锁的分类 从数据操作的类型来看，锁能够分为读锁和写锁： 读锁（共享锁）：针对读操作，多个读操作能够同时进行而不相互影响，然而不能进行写操作。 写锁（排它锁）：以后操作没有实现前，它会阻断其余写锁和读锁。 从对数据操作的颗粒度来看，锁能够分为表锁和行锁。 表锁：操作数据的时候，锁住整张表。 行锁：操作数据的时候，锁住须要操作的那一行数据。 2.mysql的表锁及案例剖析 表锁：mysql的表锁是MyISAM存储引擎有的锁，开销小，加锁快，无死锁，锁的粒度大，产生锁抵触的概率最高，并发量最低。 代码演示： 咱们先创立一张myISAM为存储引擎的表： CREATE TABLE `t_error_name` ( `error_name` varchar(255) COLLATE utf8_bin DEFAULT NULL) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin;加读锁： session 1session2加读锁 连贯mysql以后session能够查问该表的记录 其它的session也能够读该表的记录以后session不能够查问没有read锁的表 其余session能够查问或者更新未锁定的表以后session不能够插入或者更新read锁的表 其余session插入或者更新read锁住的表表会阻塞 开释锁 其余session插入或者更新实现加写锁： session1session2以后session加写锁 期待session1加锁结束以后session的查问，减少，批改，删除都能够执行实现对其它session，任何操作都锁定开释锁 session2能够对该表进行操作 论断：1.对MyISAM表的读操作（加读锁），不会阻塞其余过程对同一表的读申请，但会阻塞对同一表的写申请。只有当读锁开释后，才会执行对其它过程的写操作。2.对MyISAM表的写操作（加写锁），会阻塞其它过程对同一表的读和写操作，只有当写操作开释后，才会执行其它过程的读写操作。 总而言之，读会阻塞写，不会阻塞读，写会同时阻塞读写。 所以咱们能够得出，MyISAM存储引擎的读写锁调度是写优先，也就是MyISAM不适宜做主表的引擎，因为一张表加上写锁后，会极大升高吞吐量，大量的申请将会被阻塞。 3.mysql的行锁及案例剖析 行锁是偏差Innodb的存储引擎，开销大，加锁慢，会呈现死锁，锁定粒度最小，产生锁抵触的概率极低，并发度也最高。 Innodb和MYISAM的两个最大不同点，Innodb反对了事务，Innodb采纳了行锁。 3.1事务的隔离级别 在看事务的隔离级别之前，咱们要先了解以下这几个概念： 1.脏读脏读指的是数据库读到其余事务未提交的数据，未提交就代表着这些数据可能回滚，这些可能会回滚的数据到最初可能会不存在，所以读到了不肯定最终存在的数据，这就是脏读。 2.不可反复读 不可反复读指的是在同一事务内，不同时刻读到的同一批数据可能是不一样的，可能会受到其它曾经实现的事务的影响，比方其余事务改了这批数据并提交了，通常针对的是UPDATE操作。 3.可反复读 可反复读指的是，在一个事务内，最开始读到的数据和事务完结的任意时刻读到的同一批数据都是统一的，通常也是针对数据的update操作。 4.幻读 可反复读和不可反复读只是对于update而言的，而幻读是针对数据插入insert操作来说的，假如事务A对某些内容作了更改，还未提交，此时事务B又对事务A范畴内操作的数据中，又插入了几条数据，事务A在事务快完结的时候，再去查问事务A开始操作的数据，发现会比一开始操作的时候多了几条，但这其实是事务B刚刚插入进来的，让用户感觉到了幻觉，这就叫幻读。 事务的隔离级别： 事务的隔离级别脏读不可反复读幻读读未提交可能可能可能读提交不可能可能可能可反复读不可能不可能可能串行化不可能不可能不可能接下来咱们演示一下行锁，留神，行锁是建设在索引的根底上的，如果你要查问的这个字段没有加上索引，那么mysql就会默认锁住所有的行。 行锁演示： session 1session 2设置手动提交事务设置手动提交事务 更新然而不提交，没有commit 被阻塞 提交更新 解除阻塞，更新失常 间隙锁： 当咱们应用范畴条件而不是相等条件检索数据，并申请共享或者排他的时候，InnoDB会将目前符合条件的所有记录的索引加锁，对于键值在条件内然而不存在的记录，叫做间隙。 InnoDB也会对这个间隙加锁，这种机制就是所谓的间隙锁。 危害：因为query在执行的过程当中通过范畴查找的话，就会疾速锁定这个范畴内的所有索引键值，即便这个键不存在，造成锁定的时候，无奈插入这个范畴内的所有值，在某些场景下可能会造成很大的危害。 优化锁的倡议：1.尽可能让所有数据检索都通过索引实现，防止无索引行锁降级为表锁。2.正当设计索引，尽量放大锁的范畴4.尽可能减少检索条件，防止间隙锁5.尽量管制事务大小，缩小锁定资源量和工夫长度6.尽可能低级别事务隔离 4.总结明天学习了mysql的锁机制，次要学习了行锁和表锁，以及间隙锁的危害和优化倡议。

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 记起来有一次去讲 MySQL 8.0 开发相干个性，在 QA 环节，有人对 MySQL 的几个十分用窗口函数有些困惑，过后现场给了一些示范并且做了具体的解答，明天我用几个简略例子分享下具体的用法。 有困惑的是这四个窗口函数（其实是因为我PPT里仅写了这四个窗口函数）：frist_value、last_value、nth_value、ntile 。 谈到这四个窗口函数的具体用法，特地是前两个，得先相熟 MySQL 窗口函数的框架用法。这里提到的窗口函数框架，其实就是定义一个分组窗口的边界，边界能够是具体的行号，也能够是具体的行内容，以这个边界为终点或者起点，来展示分组内的过滤数据。详情见我之前的发稿：https://opensource.actionsky.... 接下来咱们来看看这四个窗口函数如何应用。 first_value： 用来返回一个分组窗口里的第一行记录，也即排名第一的那行记录。咱们用表t1来示范，这张表里只有12行记录，其中每6行记录依照字段r1来分组。 localhost:ytt_new>select id,r1,r2 from t1; +----+------+------+ | id | r1 | r2 | +----+------+------+ | 1 | 10 | 20 | | 2 | 10 | 30 | | 3 | 10 | 40 | | 4 | 10 | 50 | | 5 | 10 | 2 | | 6 | 10 | 3 | | 7 | 11 | 100 | | 8 | 11 | 101 | | 9 | 11 | 1 | | 10 | 11 | 3 | | 11 | 11 | 10 | | 12 | 11 | 20 | +----+------+------+ 12 rows in set (0.00 sec)比方想拿到每个分组里的第一名（升序），能够用row_number()函数，咱们来回顾下： ...

索引介绍索引是一种非凡的数据库构造，被设计用来疾速查询数据库表中的特定记录。索引有多种类型，就像字典有拼音查找和偏旁查找一样都是为了进步检索效率。MySQL中最常见的索引类型有B+树索引 和 哈希索引，上面来简略介绍一下这两种索引类型有哪些差异和优劣。B+树索引B+树索引是一种多路径的均衡搜寻树，具备如下特点：1.非叶子节点不保留数据，只保留索引值2.叶子节点保留所有的索引值和数据3.同级节点通过指针自小而大程序链接4.节点内的数据也是自小而大程序寄存5.叶子节点领有父节点的所有信息构造如下图： 长处如图可知，因为数据程序寄存，所以无论是区间还是程序扫描都更快。非叶子节点不存储数据，因而简直都能放在内存中，搜寻效率更高单节点中可存储的数据更多，均匀扫描I/O申请树更少均匀查问效率稳固（每次查问都从根结点到叶子结点，查问门路长度雷同）毛病新增数据不是按程序递增时，索引树须要重新排列，容易造成碎片和页决裂状况。哈希索引哈希索引就是采纳肯定的哈希算法，把键值换算成新的哈希值，检索时不须要相似B+树那样从根节点到叶子节点逐级查找，只需一次哈希算法即可立即定位到相应的地位，速度十分快，具备如下特点：1.哈希索引建设在哈希表的根底上2.对于每个值，须要先计算出对应的哈希码（Hash Code），不同值的哈希码惟一3.把哈希码保留在哈希表中，同时哈希表也保留指向对应每行记录的指针构造如下图： 长处大量惟一等值查问时，哈希索引效率通常更高。毛病哈希索引对于范畴查问和含糊匹配查问显得无能为力。哈希索引不反对排序操作，对于多列联结索引的最左匹配规定也不反对。哈希索引不反对局部索引列匹配查找，因为哈希索引始终是应用索引列的全部内容来计算哈希值的。拜访哈希索引的数据十分快，除非有很多哈希抵触（不同的索引列值却有雷同的哈希值）当呈现哈希抵触的时候，存储引擎必须遍历链表中所有的行指针，逐行进行比拟，直到找到所有符合条件的行。Enjoy GreatSQL :) 本文由博客一文多发平台 OpenWrite 公布！

@[toc]为什么要两阶段提交？一阶段提交不行吗？ 小伙伴们晓得，MySQL 中的事务是两阶段提交，咱们见到的很多分布式事务也都是两阶段提交的，例如 Seata，那么为什么要两阶段提交呢？一次间接提交了不行吗？明天咱们来聊聊这个话题。 对于分布式事务 seata，不懂的小伙伴能够参考松哥之前的文章，传送门： 五分钟带你体验一把分布式事务！so easy！看了那么多博客，还是不懂 TCC，无妨看看这个案例！XA 事务水很深，小伙子我怕你把握不住！你这 Saga 事务保“隔离性”吗？1. 什么是两阶段提交1.1 binlog 与 redologbinlogbinlog 咱们中文个别称作归档日志，如果大家看过松哥之前发的 MySQL 主从搭建，应该对这个日志有印象，当咱们搭建 MySQL 主从的时候就离不开 binlog（传送门：MySQL8 主从复制踩坑指南）。 binlog 是 MySQL Server 层的日志，而不是存储引擎自带的日志，它记录了所有的 DDL 和 DML(不蕴含数据查问语句)语句，而且是以事件模式记录，还蕴含语句所执行的耗费的工夫等，须要留神的是： binlog 是一种逻辑日志，他里边所记录的是一条 SQL 语句的原始逻辑，例如给某一个字段 +1，留神这个区别于 redo log 的物理日志（在某个数据页上做了什么批改）。binlog 文件写满后，会主动切换到下一个日志文件持续写，而不会笼罩以前的日志，这个也区别于 redo log，redo log 是循环写入的，即前面写入的可能会笼罩后面写入的。一般来说，咱们在配置 binlog 的时候，能够指定 binlog 文件的有效期，这样在到期后，日志文件会主动删除，这样防止占用较多存储空间。依据 MySQL 官网文档的介绍，开启 binlog 之后，大略会有 1% 的性能损耗，不过这还是能够承受的，一般来说，binlog 有两个重要的应用场景： MySQL 主从复制时：在主机上开启 binlog，主机将 binlog 同步给从机，从机通过 binlog 来同步数据，进而实现主机和从机的数据同步。MySQL 数据恢复，通过应用 mysqlbinlog 工具再联合 binlog 文件，能够将数据恢复到过来的某一时刻。redo log后面咱们说的 binlog 是 MySQL 本人提供的，在 MySQL 的 server 层，而 redo log 则不是 MySQL 提供的，是存储引擎 InnoDB 本人提供的。所以在 MySQL 中就存在两类日志 binlog 和 redo log，存在两类日志既有历史起因（InnoDB 最早不是 MySQL 官网存储引擎）也有技术起因，这个咱们当前再细聊。 ...

[toc] 为了方面社区用户体验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:e3c7b3dcebcbb6e2a1ab60993f0999c9ce7e1c85e4a87ab4022d2c1351840f6fStatus: Downloaded newer image for docker.io/greatsql/greatsql:latest查看是否胜利 [root@greatsql]# docker imagesREPOSITORY TAG IMAGE ID CREATED SIZEdocker.io/greatsql/greatsql latest 1130a28e310b 3 days ago 570 MB2.2 创立新容器之后，就能够间接创立一个新的容器了，先用惯例形式 ...

[toc] 0. 前言因为GreatSQL 8.0.27版本中引入MGR仲裁节点（投票节点，ARBITRATOR）个性，MySQL提供的mysql-shell无奈辨认该个性，因而提供mysql-shell for GreatSQL版本。 1. 批改阐明须要批改mysql-shell源码，减少对仲裁节点（投票节点）角色类型的反对，波及到两个文件： mysqlshdk/libs/mysql/group_replication.hmysqlshdk/libs/mysql/group_replication.cc在 Member_role 对象中减少 ARBITRATOR 角色类型即可。整个patch文件只有35行，很简略：$ cat mysqlsh-for-greatsql-8.0.27.patchdiff --git a/mysqlshdk/libs/mysql/group_replication.cc b/mysqlshdk/libs/mysql/group_replication.ccindex ef6a8e1b9..9edbab628 100644--- a/mysqlshdk/libs/mysql/group_replication.cc+++ b/mysqlshdk/libs/mysql/group_replication.cc@@ -108,6 +108,8 @@ std::string to_string(const Member_role role) { return "PRIMARY"; case Member_role::SECONDARY: return "SECONDARY";+ case Member_role::ARBITRATOR:+ return "ARBITRATOR"; case Member_role::NONE: return "NONE"; }@@ -119,6 +121,8 @@ Member_role to_member_role(const std::string &role) { return Member_role::PRIMARY; } else if (shcore::str_casecmp("SECONDARY", role.c_str()) == 0) { return Member_role::SECONDARY;+ } else if (shcore::str_casecmp("ARBITRATOR", role.c_str()) == 0) {+ return Member_role::ARBITRATOR; } else if (role.empty()) { return Member_role::NONE; } else {diff --git a/mysqlshdk/libs/mysql/group_replication.h b/mysqlshdk/libs/mysql/group_replication.hindex c76385e4b..1d957eae5 100644--- a/mysqlshdk/libs/mysql/group_replication.h+++ b/mysqlshdk/libs/mysql/group_replication.h@@ -73,7 +73,7 @@ enum class Member_state { MISSING };-enum class Member_role { PRIMARY, SECONDARY, NONE };+enum class Member_role { PRIMARY, SECONDARY, ARBITRATOR, NONE }; enum class Topology_mode { SINGLE_PRIMARY, MULTI_PRIMARY, NONE };2. 编译mysql-shell从MySQL官网下载的mysql-shell 8.0.27源码包是有问题的，会导致编译失败，须要本人手动批改 CMakeLists.txt 文件。我曾经提交bug（#106730）了，降级到8.0.28就能够了。 ...

CS246: Mining Massive Datasets Winter 2016Hadoop TutorialDue 11:59pm January 17, 2017General InstructionsThe purpose of this tutorial is (1) to get you started with Hadoop and (2) to get youacquainted with the code and homework submission system. Completing the tutorial isoptional but by handing in the results in time students will earn 5 points. This tutorial isto be completed individually.Here you will learn how to write, compile, debug and execute a simple Hadoop program.First part of the assignment serves as a tutorial and the second part asks you to write yourown Hadoop program.Section 1 describes the virtual machine environment. Instead of the virtual machine, youare welcome to setup your own pseudo-distributed or fully distributed cluster if you prefer.Any version of Hadoop that is at least 1.0 will suffice. (For an easy way to set up acluster, try Cloudera Manager: http://archive.cloudera.com/c...cloudera-manager-installer.bin.) If you choose to setup your own cluster, you are responsiblefor making sure the cluster is working properly. The TAs will be unable to helpyou debug configuration issues in your own cluster.Section 2 explains how to use the Eclipse environment in the virtual machine, including howto create a project, how to run jobs, and how to debug jobs. Section 2.5 gives an end-to-endexample of creating a project, adding code, building, running, and debugging it.Section 3 is the actual homework assignment. There are no deliverable for sections 1 and 2.In section 3, you are asked to write and submit your own MapReduce jobThis assignment requires you to upload the code and hand-in the output for Section 3.All students should submit the output via Gradescope and upload the code via snap.Gradescope: To register for Gradescope,• Create an account on Gradescope if you don’t have one already.• Join CS246 course using Entry Code MBDY2MUpload the code: Put all the code for a single question into a single file and upload it athttp://snap.stanford.edu/subm... You must aggregate all the code in a singlefile (one file per question), and it must be a text file.CS246: Mining Massive Datasets - Problem Set 0 2Questions1 Setting up a virtual machine• Download and install VirtualBox on your machine: http://virtualbox.org/wiki/Downloads• Download the Cloudera Quickstart VM at https://downloads.cloudera.co...vm/virtualbox/cloudera-quickstart-vm-5.5.0-0-virtualbox.zip.• Uncompress the VM archive. It is compressed with 7-zip. If needed you can downloada tool to uncompress the archive at http://www.7-zip.org/.• Start VirtualBox and click Import Appliance in the File dropdown menu. Click thefolder icon beside the location field. Browse to the uncompressed archive folder, selectthe .ovf file, and click the Open button. Click the Continue button. Click the Importbutton.• Your virtual machine should now appear in the left column. Select it and click on Startto launch it.• To verify that the VM is running and you can access it, open a browser to the URL:http://localhost:8088. You should see the resource manager UI. The VM uses portforwarding for the common Hadoop ports, so when the VM is running, those ports onlocalhost will redirect to the VM.• Optional: Open the Virtual Box preferences (F ile → P references → Network) andselect the Adapter 2 tab. Click the Enable Network Adapter checkbox. Select HostonlyAdapter. If the list of networks is empty, add a new network. Click OK. If youdo this step, you will be able to connect to the running virtual machine via SSH fromthe host OS at 192.168.56.101. The username and password are ’cloudera’.The virtual machine includes the following software• CentOS 6.4• JDK 7 (1.7.0 67)• Hadoop 2.5.0• Eclipse 4.2.6 (Juno)The virtual machine runs best with 4096MB of RAM, but has been tested tofunction with 1024MB. Note that at 1024MB, while it did technically function,it was very slow to start up.CS246: Mining Massive Datasets - Problem Set 0 32 Running Hadoop jobsGenerally Hadoop can be run in three modes. ...

MySQL存储过程0.环境阐明：软件版本mysql5.6HeidiSQL 1.应用阐明 存储过程时数据库的一个重要的对象，能够封装SQL语句集，能够用来实现一些较简单的业务逻辑，并且能够入参出参(相似于java中的办法的书写)。 创立时会事后编译后保留，用户后续的调用都不须要再次编译。 // 把editUser类比成一个存储过程public void editUser(User user,String username){ String a = "nihao"; user.setUsername(username);}main(){ User user = new User(); editUser(user,"张三"); user.getUseranme(); //java根底还记得不} 大家可能会思考，用sql解决业务逻辑还要从新学，我用java来解决逻辑（比方循环判断、循环查问等）不行吗？那么，为什么还要用存储过程解决业务逻辑呢？ 长处： 在生产环境下，能够通过间接批改存储过程的形式批改业务逻辑（或bug），而不必重启服务器。 执行速度快，存储过程通过编译之后会比独自一条一条执行要快。 缩小网络传输流量。 不便优化。毛病： 过程化编程，简单业务解决的保护老本高。 调试不便 不同数据库之间可移植性差。-- 不同数据库语法不统一！2.筹备：数据库参阅材料中的sql脚本； delimiter $$ --申明结束符3.语法-- 官网参考网址https://dev.mysql.com/doc/refman/5.6/en/sql-statements.htmlhttps://dev.mysql.com/doc/refman/5.6/en/sql-compound-statements.html3.0 语法结构CREATE [DEFINER = user] PROCEDURE sp_name ([proc_parameter[,...]]) [characteristic ...] routine_body -- proc_parameter参数局部，能够如下书写： [ IN | OUT | INOUT ] param_name type -- type类型能够是MySQL反对的所有类型 -- routine_body(程序体)局部，能够书写非法的SQL语句 BEGIN ... END简略演示： -- 申明结束符。因为MySQL默认应用‘;’作为结束符，而在存储过程中，会应用‘;’作为一段语句的完结，导致‘;’应用抵触delimiter $$CREATE PROCEDURE hello_procedure ()BEGIN SELECT 'hello procedure';END $$call hello_procedure();3.1 变量及赋值类比一下java中的局部变量和成员变量的申明和应用局部变量：用户自定义，在begin/end块中无效 ...

一、XA是什么？XA 协定本就是为一个分布式事务协定，它规定了 XA PREPARE、XA COMMIT、XA ROLLBACK 等命令。XA 协定规定了事务管理器（协调者）和资源管理器（数据节点）如何交互，共同完成分布式 2PC 的过程XA次要规定了RM与TM之间的交互，上面来看下XA标准中定义的RM 和 TM交互的接口： xa_start负责开启或者复原一个事务分支，并且治理XID到调用线程 xa_end 负责勾销以后线程与事务分支的关联xa_prepare负责询问RM 是否筹备好了提交事务分支xa_commit告诉RM提交事务分支xa_rollback 告诉RM回滚事务分支XA协定是应用了二阶段协定的，其中： 第一阶段TM要求所有的RM筹备提交对应的事务分支，询问RM是否有能力保障胜利的提交事务分支，RM依据本人的状况，如果判断本人进行的工作能够被提交，那就就对工作内容进行长久化，并给TM回执OK；否者给TM的回执NO。RM在发送了否定回答并回滚了曾经的工作后，就能够抛弃这个事务分支信息了。 第二阶段TM依据阶段1各个RM prepare的后果，决定是提交还是回滚事务。如果所有的RM都prepare胜利，那么TM告诉所有的RM进行提交；如果有RM prepare回执NO的话，则TM告诉所有RM回滚本人的事务分支。 也就是TM与RM之间是通过两阶段提交协定进行交互的。 二、MySQL中XA实现1.外部XA事务MySQL中只有InnoDB引擎反对XA协定，外部XA事务次要用来协调存储引擎和二进制日志确认下mysql是否启动了xa性能：测试手动执行xa事务：其中首先应用XA START ‘xid' 启动了一个XA事务，并把它置于ACTIVE状态 对于一个ACTIVE状态的 XA事务，咱们能够执行形成事务的多条SQL语句，也就是指定分支事务的边界，而后执行一个XA END ‘xid'语句，XA END把事务放入IDLE状态，也就是完结事务边界，在xa start和xa end之间的语句就形成了本分支事务的一个事务范畴。当调用xa end 'xid1'后因为完结了事务边界，所以这时候如果在执行sql语句会抛出ERROR 1399 (XAE07): XAER_RMFAIL: The command cannot be executed when global transaction is in the IDLE state谬误，也就是当分支事务处于IDLE状态时候不容许执行没有蕴含到分支事务边界外面的其余sql. 对于一个IDLE 状态XA事务，能够执行一个XA PREPARE语句或一个XA COMMIT…ONE PHASE语句,其中XA PREPARE把事务放入PREPARED状态。在此点上的XA RECOVER语句将在其输入中包含事务的xid值，因为XA RECOVER会列出处于PREPARED状态的所有XA事务。XA COMMIT…ONE PHASE用于准备和提交事务，也就是转换为一阶段协定，间接提交事务。 对于一个PREPARED状态的 XA事务,能够执行XA COMMIT 语句来提交或者执行XA ROLLBACK来回滚xa事务。 其中二阶段协定中第一阶段是执行 xa prepare时候，这时候MySQL客户端（TM）向MySQL数据库服务器（RM）收回prepare"筹备提交"申请，数据库收到申请后执行数据批改和日志记录等解决，解决实现后只是把事务的状态改成"能够提交",而后把后果返回给事务管理器。 ...

又到了金三银四的时候，大家都按耐不住心田的躁动，我在这里给大家分享下之前面试中遇到的一个知识点（死锁问题），如有有余，欢送大佬们指导指导。 1、什么是死锁？死锁指的是在两个或两个以上不同的过程或线程中，因为存在独特资源的竞争或过程（或线程）间的通信而导致各个线程间互相挂起期待，如果没有外力作用，最终会引发整个零碎解体。2、Mysql呈现死锁的必要条件资源独占条件指多个事务在竞争同一个资源时存在互斥性，即在一段时间内某资源只由一个事务占用，也可叫独占资源（如行锁）。申请和放弃条件指在一个事务a中曾经取得锁A，但又提出了新的锁B申请，而该锁B已被其它事务b占有，此时该事务a则会阻塞，但又对本人已取得的锁A放弃不放。不剥夺条件指一个事务a中曾经取得锁A，在未提交之前，不能被剥夺，只能在应用完后提交事务再本人开释。互相获取锁条件指在产生死锁时，必然存在一个互相获取锁过程，即持有锁A的事务a在获取锁B的同时，持有锁B的事务b也在获取锁A，最终导致互相获取而各个事务都阻塞。3、 Mysql经典死锁案例假如存在一个转账情景，A账户给B账户转账50元的同时，B账户也给A账户转账30元，那么在这过程中是否会存在死锁状况呢？3.1 建表语句CREATE TABLE `account` ( `id` int(11) NOT NULL COMMENT '主键', `user_id` varchar(56) NOT NULL COMMENT '用户id', `balance` float(10,2) DEFAULT NULL COMMENT '余额', PRIMARY KEY (`id`), UNIQUE KEY `idx_user_id` (`user_id`) USING BTREE) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='账户余额表';3.2 初始化相干数据INSERT INTO `test`.`account` (`id`, `user_id`, `balance`) VALUES (1, 'A', 80.00);INSERT INTO `test`.`account` (`id`, `user_id`, `balance`) VALUES (2, 'B', 60.00); 3.3 失常转账过程在说死锁问题之前，咱们先来看看失常的转账过程。失常状况下，A用户给B用户转账50元，可在一个事务内实现，须要先获取A用户的余额和B用户的余额，因为之后须要批改这两条数据，所以须要通过写锁（for UPDATE）锁住他们，避免其余事务更改导致咱们的更改失落而引起脏数据。相干sql如下：==开启事务之前须要先把mysql的主动提交敞开== set autocommit=0;# 查看事务主动提交状态状态show VARIABLES like 'autocommit';# 转账sqlSTART TRANSACTION;# 获取A 的余额并存入A_balance变量：80SELECT user_id,@A_balance:=balance from account where user_id = 'A' for UPDATE;# 获取B 的余额并存入B_balance变量:60SELECT user_id,@B_balance:=balance from account where user_id = 'B' for UPDATE;# 批改A 的余额UPDATE account set balance = @A_balance - 50 where user_id = 'A';# 批改B 的余额UPDATE account set balance = @B_balance + 50 where user_id = 'B';COMMIT;执行后的后果：能够看到数据更新都是失常的状况 ...

摘要本文以MySQL数据库为钻研对象，探讨与数据库索引相干的一些话题。特地须要阐明的是，MySQL反对诸多存储引擎，而各种存储引擎对索引的反对也各不相同，因而MySQL数据库反对多种索引类型，如BTree索引，哈希索引，全文索引等等。为了防止凌乱，本文将只关注于BTree索引，因为这是平时应用MySQL时次要打交道的索引，至于哈希索引和全文索引本文暂不探讨。 第一局部次要从数据结构及算法实践层面探讨MySQL数据库索引的数理根底。 第二局部联合MySQL数据库中MyISAM和InnoDB数据存储引擎中索引的架构实现探讨汇集索引、非汇集索引及笼罩索引等话题。 第三局部解说Explain命令的应用标准 第四局部探讨MySQL中高性能应用索引的策略。 数据结构与算法根底索引的实质MySQL官网对索引的定义为：索引（Index）是帮忙MySQL高效获取数据的数据结构。提取句子骨干，就能够失去索引的实质：索引是数据结构。 咱们晓得，数据库查问是数据库的最次要性能之一。咱们都心愿查问数据的速度能尽可能的快，因而数据库系统的设计者会从查问算法的角度进行优化。最根本的查问算法当然是程序查找（linear search），这种复杂度为O(n)的算法在数据量很大时显然是蹩脚的，好在计算机科学的倒退提供了很多更优良的查找算法，例如二分查找（binary search）、二叉树查找（binary tree search）等。如果略微剖析一下会发现，每种查找算法都只能利用于特定的数据结构之上，例如二分查找要求被检索数据有序，而二叉树查找只能利用于二叉查找树上，然而数据自身的组织构造不可能齐全满足各种数据结构（例如，实践上不可能同时将两列都按程序进行组织），所以，在数据之外，数据库系统还保护着满足特定查找算法的数据结构，这些数据结构以某种形式援用（指向）数据，这样就能够在这些数据结构上实现高级查找算法。这种数据结构，就是索引。 看一个例子： 图1展现了一种可能的索引形式。右边是数据表，一共有两列七条记录，最右边的是数据记录的物理地址（留神逻辑上相邻的记录在磁盘上也并不是肯定物理相邻的）。为了放慢Col2的查找，能够保护一个左边所示的二叉查找树，每个节点别离蕴含索引键值和一个指向对应数据记录物理地址的指针，这样就能够使用二叉查找在O(log2n)的复杂度内获取到相应数据。 尽管这是一个货真价实的索引，然而理论的数据库系统简直没有应用二叉查找树或其进化种类红黑树（red-black tree）实现的，起因会在下文介绍。 B-Tree和B+Tree目前大部分数据库系统及文件系统都采纳B-Tree或其变种B+Tree作为索引构造，在本文的下一节会联合存储器原理及计算机存取原理探讨为什么B-Tree和B+Tree在被如此宽泛用于索引，这一节先单纯从数据结构角度形容它们。 B-TreeB树的定义(维基百科) 依据 Knuth 的定义，一个 m 阶的B树是一个有以下属性的树： 每一个节点最多有 m 个子节点每一个非叶子节点（除根节点）起码有 ⌈m/2⌉ 个子节点如果根节点不是叶子节点，那么它至多有两个子节点有 k 个子节点的非叶子节点领有 k − 1 个键所有的叶子节点都在同一层每一个外部节点的键将节点的子树离开。例如，如果一个外部节点有3个子节点（子树），那么它就必须有两个键： a1 和 a2 。右边子树的所有值都必须小于 a1 ，两头子树的所有值都必须在 a1 和a2 之间，左边子树的所有值都必须大于 a2 。 外部节点外部节点是除叶子节点和根节点之外的所有节点。它们通常被示意为一组有序的元素和指向子节点的指针。每一个外部节点领有最多 U 个，起码 L 个子节点。元素的数量总是比子节点指针的数量少一（元素的数量在 L-1 和 U-1 之间）。U 必须等于 2L 或者 2L-1;因而，每一个外部节点都至多是半满的。U 和 L 之间的关系意味着两个半满的节点能够合并成一个非法的节点，一个全满的节点能够被决裂成两个非法的节点（如果父节点有空间包容移来的一个元素）。这些个性使得在B树中删除或插入新的值时能够调整树来放弃B树的性质。 根节点根节点领有的子节点数量的下限和外部节点雷同，然而没有上限。例如，当整个树中的元素数量小于 L-1 时，根节点是惟一的节点并且没有任何子节点。 叶子节点叶子节点对元素的数量有雷同的限度，然而没有子节点，也没有指向子节点的指针。一个深度为n+1 的B树能够包容的元素数量大概是深度为 n 的B树的 U 倍，然而搜寻、插入和删除操作的开销也会减少。和其余的均衡树一样，这一开销减少的速度远远慢于元素数量的减少。 一些均衡树只在叶子节点中存储值，而且叶子节点和外部节点应用不同的构造。B树在每一个节点中都存储值，所有的节点有着雷同的构造。然而，因为叶子节点没有子节点，所以能够通过应用专门的构造来进步B树的性能。 ...

“精准营销是以客户为核心，使用各种可利用的形式，在失当的工夫，以失当的价格，通过失当的渠道，向失当的顾客提供失当的产品。” 这是学者许瑾在科特勒精准营销实践的根底上，从实际的角度对精准营销下过的定义。 在这个金融科技疾速倒退，资管行业载体与社交媒体、电子商务的交融越来越严密的时代，华夏基金的实际为行业内外展示了一个数字化转型与精准营销的标杆案例。 2021年4月，华夏基金与袋鼠云达成单干，构建一站式标签体系，搭建画像剖析零碎，积淀企业标签资产。由此，华夏基金使用袋鼠云数栈先进的技术手段，将智能标签利用于企业经营与营销，对指标客户进行精确辨认，提供精准的产品和服务，并帮助业务人员进行商业剖析，驱动业务增长。 对于“华夏基金”华夏基金成立于1998年，定位于综合性、全能化的资产治理公司，服务范畴笼罩多个资产类别、行业和地区，构建了以公募基金和机构业务为外围，涵盖华夏香港、华夏资本、华夏财产的多元化资产治理平台，公司以业余、谨严的投资钻研为根底，为投资人提供投资理财产品和服务。 基金业正在经验的改革身处一个全方位数字化的平台型经济时代，企业的数字化转型已是由内而外的必然趋势，相比于银行业、保险业、证券业等金融行业公司，目前基金公司的科技投入显著起码，但基金公司所治理的资产又特地宏大，从这个意义上而言，基金公司会更加依赖于先进科技，须要尽早做到数字化高度赋能于业务。 “80后、90后总计共有4.3亿人口，并且正在逐渐成为基金行业的次要消费者，然而他们的生产习惯和60、70后的人群有很大的不同。”华夏基金相干人士通知咱们。随着公众理财意识的增强，公募基金逐步成为泛滥集体投资者的首选理财工具，基金行业的客户群体也随之呈现细分化趋势。 市场上很难有一种产品或一类服务能够满足所有用户的需要，不同支出、不同年纪、不同职业、不同性情的客户对基金产品的需要都不尽相同，有的客户偏差高风险高收益，有的客户则更心愿持重收益，有的客户主见大、理财意识高，有的客户齐全没有主见，你说什么就是什么…… “华夏基金面对的客户群体基数很大，咱们须要为不同的客户定制产品，满足不同客户的须要。”相干人士坦言，“理清数据，高效使用，通过用户画像为用户匹配更合乎需要的理财产品，进行针对性地营销触达，正是咱们的事不宜迟。” 业务需要背地的数据问题2021年4月，袋鼠云确定携手华夏基金开启数字化转型之路，经后期调研发现： 作为基金行业的传统巨头，近年来，华夏基金各项业务迅猛发展，客户数据量急剧增长，在简单的市场环境下，公司对客户、产品、渠道、反洗钱等方面的数据分析、经营提出了更高的要求。 华夏基金前端业务类型多样，数据孤岛、零碎烟囱景象重大，客户数据扩散在各个系统，没有对立的剖析平台。 各类数据分析和提取大多采纳半自动的工作模式，无迷信的标签体系及资源共享平台，提供及时和无力的反对，导致客户信息维度不残缺，客户流动开发周期长，经营不精准，营销成果不足及时追踪、运行反馈不及时。 “数字化转型的外围永远是为客户服务，从以产品为核心的经营理念转变为以客户为核心，围绕客户做深度服务。”袋鼠云数栈架构师谈到，“华夏基金短少的正是这样一个标签治理剖析平台，可能通过数字化形式去理解客户，将金融、基金从单纯的理财输入变为陪伴式的金融服务。” 而这份陪伴式的和煦正是由各种寒冷的数据形成。可能寻找到潜在指标客户和触达客户，并提供个性化、精细化的金融服务的根底，正是采集领有大量实在主观的数据，并对数据进行深度开掘。 华夏基金与袋鼠云数栈携手，构建标签开发、运算、展现和输入的全生命周期管理体系，聚焦于具备明确业务价值的数字化机会与场景，从而实现“业务、技术、数据”的三位一体。 数栈实现数仓多引擎兼容数据采集是“千里之行始于足下”的第一步，而在迈出这一步的时候，数栈就遇到了挑战。 华夏基金此前已搭建TDH计算平台，而数栈的智能标签产品采纳的OLAP引擎是Presto，过后Presto的公开插件中没有Inceptor的连接器，对计算集群的对接产生了一些艰难。袋鼠云团队不负众望，基于数栈技术先进、凋谢的数仓多引擎兼容性能，通过技术人员的自研插件，实现Presto可读写Inceptor。并且基于Presto计算引擎，在金融客户生产环境应用中，达到了亿级别数据的秒级查问。 一方面，反对presto连贯TDH Inceptor，数据同步反对读写Inceptor的事务表，做到无缝对接TDH，达到客户诉求；另一方面，因为客户一部分数据存储在Oracle中，引入数栈离线开发产品，通过数据同步工具将数据同步至Inceptor，实现数据采集与对接，为后续标签性能开发中须要的数据调用打下基础。 建设标签体系：降本增效是第一要义鉴于华夏基金的痛点问题，及为了更好的适应并反对事实业务的须要。以荡涤治理好的数据为根底，袋鼠云数栈助力华夏基金建设了本人的一站式标签体系与画像剖析零碎，搭建波及客户、产品、渠道的三层标签体系，共计7大类，250+标签，反对销售、服务、合规等不同角度的需要。 并且，基于数仓荡涤的原子标签，可进行衍生、组合标签、自定义SQL标签的产品化加工，标签加工形式灵活多样，真正做到开箱即用。即便是齐全不懂技术的一线业务人员也可间接染指规定类标签加工，疾速实现标签的创立，且标签创立实现后，可立刻进行标签更新，让业务人员立刻应用。创立新标签的效率晋升90%，极大地缩短了标签建设周期，进一步使营销策略更新迭代速率放慢。 另一方面，从标签定义-标签开发-标签公布-标签更新-标签评估-标签下线，数栈帮忙华夏基金真正实现了标签的全生命周期治理，各过程可管可控，对立标签治理标准、积淀企业外围标签资产，造成企业对立的标签核心，继续输入数据价值。此外，细粒度的标签权限治理和高效稳固的标签展现和输入，确保了平安且高效的业务发展能力，积木式的组件标签搭建和复用，又可疾速反对例行、长期或专题性的数据分析，并且反对客户个体及群组画像、客户群圈选和比照，为后续的疾速推广、智能营销、精准服务等用户数据化经营奠定技术根底。 “基金公司的通病，数据零散、源头多元，各类标签的利用率很低，这些问题以前华夏基金也有，每次花了大量的人力工夫去进行标签的半自动开发之后，却没有方法进行正当复用，导致大量标签被节约和忘记，重大影响了降本增效的公司倒退要义。”相干人员说道，“直到袋鼠云数栈进场实现标签零碎的构建之后，这个问题才算是被真正解决了。” 基金业数字化转型：用户是第一突破口数字化浪潮深度浸透的背景下，“用户”和“生态”成为重要抓手。《2019基金业金融科技白皮书》中说到，基金行业已进入全面数字化阶段，用户是数字化浸透的“第一突破口”，生态将成为翻新服务模式的重要根底。 基于建设好的标签，华夏基金的业务人员便可透明化的应用标签，将数据库的黑盒子变成业务语言的白盒子，辅助业务决策，驱动业务增长，让千人千面的营销经营成为可能。 比方，基于标签体系，进行疾速、精准的自助式圈群，保留成各种类型的人群包，为人、物、场等构建360°画像体系，把握单个用户、群组的全副特点，如某客户的资产信息、行为偏好、投资偏好、危险偏好等，进行用户的深度细分，并开掘群组的画像特色、显著性特色、对比性特色，把握群组特点，灵便迭代营销策略，利用画像体系进行精细化经营。并且，数栈反对以API模式对外提供标签和人群包服务，能快捷对接CRM等营销零碎，实现营销链路全闭环。再如，当新基金发行时，公司会进行肯定的营销流动，向用户进行推广。如华夏预计公布一支新基金，业务人员会依据其个性，首先抉择偏差直销平台、危险讨厌指数低的用户进行推送，先圈定一部分用户之后，再联合客户的交付格调、持仓格调圈定优选客群，之后，可再基于首轮命中客群的类似人群进行补充推广，利用智能标签零碎，胜利实现继续迭代的营销过程。 实现这一系列的营销链路之后，数栈为华夏基金搭建的标签零碎可将这部分数据进行回收采集录入，基于机器学习模型进行协同过滤，在下一次的新基金产品设计发行过程中，提前站在“以客户为核心”的视角进行开发，真正实现从用户需要登程去设计产品、推广服务，实现带有温度的金融个性化举荐。 另外，基于标签零碎的平安预警也是数栈为华夏基金提供的一类重要场景利用。依据用户危险类标签，业务人员可能疾速找到短期内频繁开立账户、撤销账户、频繁交易、交易IP跨境、交易工夫异样的客户，进行重点防备与预警，保障金融平安。依据客户活跃度、交易周期、账户余额区间、盈利状况等标签，又可能顺利找到静默用户，进行触点激活。 “不节约一条数据，不让标签杳无音信，做到更粗浅地了解用户，个性化地服务用户，使业务营销更加精确、疾速，正是袋鼠云数栈为华夏基金搭建智能标签零碎的初衷。”数栈“智能标签”产品经理这样通知咱们。 “数字化转型”已成为当今各行各业，所有企业绕不开的一个名词，“十四五“布局倡议的全文中也屡次提到“数字化”三个字。金融行业作为数字化水平绝对较高的行业，一路以来始终紧跟国家策略，进步本身数字化建设程度。 作为行业传统巨头的华夏基金，在面对已经的行业窘境时，便早早意识到了科技的力量，摸索大数据在金融畛域的使用，科技感和基金投顾，曾经成为了华夏在新时代的新招牌。 作为金融行业数字化改革的共建者，“智能标签”畛域的践行者，袋鼠云很荣幸能参加到华夏基金的数智化建设中，助力其构建撑持数字化转型需要的全方位大数据能力体系，见证华夏基金持续在金融行业大数据浪潮的顶端舞蹈。

联表更新update record_detail dinner join record r on d.record_id = r.id set d.column1 = d.column1 / 100, d.column2 = d.column2 / 100where r.column1 = 1复制表//复制表构造及数据CREATE TABLE 新表 SELECT * FROM 旧表//复制表构造CREATE TABLE 新表 SELECT * FROM 旧表 WHERE 1=2CREATE TABLE 新表 LIKE 旧表//复制数据(表构造一样)INSERT INTO 新表 SELECT * FROM 旧表//复制数据(表构造不一样)INSERT INTO 新表(字段1,字段2,.......) SELECT 字段1,字段2,...... FROM 旧表IF CASE//case whenselectuser_id,year,(CASE WHEN year = 2020 THEN '去年' WHEN year = 2019 THEN '前年' ELSE '其余'END) as year_titlefromyear_report//ifselectuser_id,year,IF(count_year = 2020, '去年', '前年') as year_titlefromyear_reportON DUPLICATE KEY UPDATE//释义为 若判断该数据不存在，则执行insert，若存在则将update前面的列更新为对应的值//判断数据存在的条件为惟一索引（会引起DUPLICATE KEY报错的条件）ON DUPLICATE KEY UPDATE column1 = value1,column2 = value2, column3 = value3, ...;

文章分五大内容别离是：连贯MySQL、MySQL治理与受权、数据库简略操作、数据库的导入与导出、数据库备份 杜聚宾（杜公公）独家MySQL数据库根底实战视频教程指路： https://www.bilibili.com/vide... 视频目录： 视频简介： 本套是MySQL数据库视频教程是能源节点教学总监杜老师讲述，其中具体解说了MySQL的相干常识，包含MySQL概述，MySQL应用环境，MySQL零碎个性，MySQL初学根底，MySQL管理工具，如何装置MySQL及MySQL新个性，通过观看本套Java视频教程就可把握MySQL全套常识。 (试验环境:Redhat9.0,MySQL3.23.54) 一，连贯MySQL格局：mysql -h 近程主机地址 -u 用户名 -p 回车 输出明码进入： mysql -u root -p 回车 Enter password: ,输出明码就能够进入 mysql> 进入了 退出命令:>exit 或者ctrl+D 二，MySQL治理与受权1.批改明码：格局：mysqladmin -u 用户名 -p 旧明码 password 新密码 2.减少新用户:grant create,select,update….(授予相干的操作权限)->on 数据库.* -> to 用户名@登录主机 identified by ‘明码’ 操作实例： 给root用户增加明码: mysqladmin -u root password 52netseek**因为开始root没有明码,所以-p旧明码一项能够省略. 登陆测试： mysql -u root -p 回车输出明码,胜利登陆. 将原有的mysql治理登陆密码52netseek改为52china. mysqladmin -u root -p 52netseek password ’52china’创立数据库增加用户并授予相应的权限: mysql> create database phpbb; ...

@[toc] 一、简述简述ShardingSphere-Proxy4.0 曾经降级到5.0了，然而两者的配置文件还有肯定的差异的，这篇文章讲述的就是ShardingSphere-Proxy 5.0 的落地。概念、分表、分库、分库分表的原理的根本和4.0一样的，须要理解可查看 https://blog.csdn.net/Fu_Shi_...。开发者文档https://shardingsphere.apache...二、ShardingSphere-Proxy5.0 落地环境 JAVA JDK下载 https://pan.baidu.com/s/1A-ksNN0YicT3hXjFscGGwA 提取码：r9e0JDBC数据连贯驱动下载 https://pan.baidu.com/s/1924iUe7wxGpStAzxxv2K3g 提取码：jy7zShardingSphere-Proxy 5.0 下载、 https://archive.apache.org/dist/shardingsphere/5.0.0/Window 11落地 条件 实在数据库逻辑数据库ShardingSphere-Proxy5.0 配置文件步骤 新建实在数据库和表【hmms.user 表为例】 数据库表构造语句 SET NAMES utf8mb4;SET FOREIGN_KEY_CHECKS = 0;-- ------------------------------ Table structure for user-- ----------------------------DROP TABLE IF EXISTS `user`;CREATE TABLE `user` ( `useid` int(11) NOT NULL, `usenam` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT '登录名', `usepwd` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '登录明码', `usestate` int(11) NULL DEFAULT 2 COMMENT '-1：删除1：登记 2：失常 3：挂失', `usekey` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '用户秘钥', `usetel` varchar(11) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '用户手机', `createbyid` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '增加人', `createbytime` datetime(0) NULL DEFAULT NULL COMMENT '增加工夫', `modifybyid` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '批改人', `modifybytime` datetime(0) NULL DEFAULT NULL COMMENT '批改工夫', PRIMARY KEY (`useid`) USING BTREE) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Dynamic;SET FOREIGN_KEY_CHECKS = 1;运行后果如下： ...

视图定义视图是一种有构造的虚构表，自身不存放数据，视图中数据来源于实在的表，实在的表也被称之为基表。 视图作用1.简化SQL语句: 比方将一条多表联结查问做成视图，后续间接SELECT * 视图进行查问即可。2.绝对平安的权限管制: 针对不同利用只须要建设对应视图表，提供所须要的字段信息，利用无奈感知到其余字段信息。3.保障数据安全: 对视图进行删除操作不会影响基表的数据。创立视图根本语法 CREATE [OR REPLACE] [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}] [DEFINER = user] [SQL SECURITY { DEFINER | INVOKER }] VIEW view_name [(column_list)] AS select_statement [WITH [CASCADED | LOCAL] CHECK OPTION]视图算法ALGORITHM = UNDEFINED | MERGE | TEMPTABLE UNDEFINED # 未定义(默认的), 由零碎自行调整 MERGE # 合并算法: 零碎应该先将视图对应的select语句与内部查问视图的select语句进行合并,而后执行(效率高: 常态) TEMPTABLE # 长期表算法: 零碎应该先执行视图的select语句,后执行内部查问语句 create view 视图名字 as select语句 select 语句能够是一般查问、连贯查问、联结查问、子查问等各种类型。 创立单表视图: 基表只有一个 [root@GreatSQL][test]>create view v_t_name as select * from t_name;Query OK, 0 rows affected (0.14 sec)[root@GreatSQL][test]>show create view v_t_name\G;*************************** 1. row *************************** View: v_t_name Create View: CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `v_t_name` AS select `t_name`.`id` AS `id`,`t_name`.`name` AS `name` from `t_name`character_set_client: utf8collation_connection: utf8_general_ci1 row in set (0.01 sec)ERROR:No query specified[root@GreatSQL][test]>desc v_t_name;+-------+-------------+------+-----+---------+-------+| Field | Type | Null | Key | Default | Extra |+-------+-------------+------+-----+---------+-------+| id | int | NO | | 0 | || name | varchar(64) | YES | | NULL | |+-------+-------------+------+-----+---------+-------+2 rows in set (0.01 sec)创立多表视图: 基表起源至多两个 ...

1 主机配置主机的配置就三个步骤，比拟容易： 1.1 受权给从机服务器GRANT REPLICATION SLAVE ON *.* to 'rep1'@'10.3.50.27' identified by '123';FLUSH PRIVILEGES;这里示意配置从机登录用户名为 rep1，明码为 123，并且必须从 10.3.50.27 这个地址登录，登录胜利之后能够操作任意库中的任意表。其中，如果不须要限度登录地址，能够将 IP 地址更换为一个 %。 留神，在 MySQL8 里边，这块有一些变动。MySQL8 中用户创立和受权须要离开，不能像下面那样一步到位，具体形式如下： CREATE USER `rep1`@`10.3.50.27` IDENTIFIED WITH caching_sha2_password BY 'javaboy.COM';GRANT Replication Slave ON *.* TO `rep1`@`10.3.50.27`;2. 批改主库配置文件开启 binlog ，并设置 server-id ，每次批改配置文件后都要重启 MySQL 服务才会失效 开启 binlog 次要是批改 MySQL 的配置文件 mysqld.cnf，该文件在容器的 /etc/mysql/mysql.conf.d log-bin：同步的日志门路及文件名，肯定留神这个目录要是 MySQL 有权限写入的（我这里是偷懒了，间接放在了上面那个datadir上面）。binlog-do-db：要同步的数据库名，当从机连上主机后，只有这里配置的数据库才会被同步，其余的不会被同步。server-id: MySQL 在主从环境下的惟一标志符，给个任意数字，留神不能和从机反复。批改 binlog_format 的值为 STATEMENT，这一点很要害。配置实现后重启 MySQL 服务端： docker restart mysql33061再看一眼 binlog_format 设置胜利没：

一、前言最近有很多读者要我出一些面试题的文章，个别我会给他一个老周整顿的电子书，但有些读者反馈回来的面试题我感觉还是蛮经典的，而老周又在写系列的文章，本着对读者负责的态度，我会交叉写几篇我认为比拟经典的面试题，让大家对这种经典问题不再是背八股文，而是深刻底层原理以及数据结构。后续再碰到这类问题，不论哪个公司问的，你都会得心应手、慌慌张张的答复。 明天这一篇腾讯的一道面试题：说一说 MySQL 中索引的底层原理，先不论哪个公司，如果老周是面试官，MySQL 这块我很可能也会用这道来考查，因为这能够考查出你对 MySQL 实质是否了解，而且当初很多人动不动就索引优化，索引底层是个啥我置信还有蛮多人不是特地理解。 没关系，跟着老周走，这一篇咱们彻底拿下 MySQL 的索引。 二、索引是什么？索引是对数据库表中一列或多列的值进行排序的一种构造，应用索引可进步数据库中特定数据的查问速度。 索引的目标在于进步查问效率，就像书的目录一样。一本 1000 页的书，如果你想疾速找到其中的某一个知识点，在不借助目录的状况下，这个事件是不是很难实现？同样，对于数据库的表而言，索引其实就是它的“目录”。 三、索引的分类常见的索引类型有：主键索引、惟一索引、一般索引、全文索引、组合索引 3.1 主键索引即主索引，依据主键 pk_clolum（length）建设索引，不容许反复，不容许空值。 ALTER TABLE 'table_name' ADD PRIMARY KEY pk_index('col')；3.2 惟一索引用来建设索引的列的值必须是惟一的，容许空值。 ALTER TABLE 'table_name' ADD UNIQUE index_name('col')；3.3 一般索引MySQL 中的根本索引类型，容许在定义索引的列中插入反复值和空值。 ALTER TABLE 'table_name' ADD INDEX index_name('col')；3.4 全文索引全文索引类型为 FULLTEXT，用大文本对象的列构建的索引，在定义索引的列上反对值的全文查找，容许在这些索引的列中插入反复值和空值。全文索引能够在 CHAR、VARCHAR 或 TEXT 类型的列上创立。MySQL 中只有 MyISAM 存储引擎反对全文索引。 ALTER TABLE 'table_name' ADD FULLTEXT INDEX ft_index('col')；3.5 组合索引在表的多个字段组合上创立的索引，只有在查问条件中应用了这些字段的右边字段时，索引才会被应用。应用组合索引时遵循最左前缀准则，并且组合索引这多个列中的值不容许有空值。 ALTER TABLE 'table_name' ADD INDEX index_name('col1','col2','col3')；留神了，遵循最左前缀准则很重要！！！把最罕用作为检索或排序的列放在最左，顺次递加，组合索引相当于建设了 col1、col1col2、col1col2col3 三个索引，而 col2 或者 col3 是不能应用索引的。 ...

问题数据库主机内存只有 100G，对一个 200G 的大表做全表扫描，会不会导致数据库主机OOM？ 例子对一个 200G 的 InnoDB 表 db1. t，执行一个全表扫描，把扫描后果保留在客户端 mysql -h$host -P$port -u$user -p$pwd -e "select * from db1.t" > $target_file全表扫描server层全表扫描执行流程1、获取一行，写到 net_buffer （每个session一个）中。这块内存的大小是由参数 net_buffer_length 定义的，默认是 16k。2、反复获取行，直到 net_buffer 写满，调用网络接口收回去。3、如果发送胜利，就清空 net_buffer，而后持续取下一行，并写入 net_buffer。4、如果发送函数返回 EAGAIN 或 WSAEWOULDBLOCK，就示意本地网络栈（socket send buffer）写满了，进入期待。直到网络栈从新可写，再持续发送。 全表扫描问题1、一个查问在发送过程中，占用的 MySQL 外部的内存最大就是 net_buffer_length 这么大，并不会达到 200G；2、socket send buffer 也不可能达到 200G（默认定义 /proc/sys/net/core/wmem_default），如果 socket send buffer 被写满，就会暂停读数据的流程。（因为socket send buffer内存是每个连贯独自限度的，所以不会对服务端网路造成太大影响，当然如果并发很多查问，可能会影响网络。）3、MySQL 是“边读边发的”，这就意味着，如果客户端接管得慢，会导致 MySQL 服务端因为后果发不进来，这个事务的执行工夫变长。（客户端为了疾速解决接管的数据，默认是先把接管的数据缓存到本地内存，再做解决，这样做能够不拖慢MySQL服务器）4、对于一个查问，执行器拿到的所有后果，如果能够一次性放入net_buffer, 对于执行器来说就意味着“全都写出去了”，也就不会有 sending to client 状态。 只有当查问的后果，不可能全副放入net_buffer，须要等net_buffer里的内容清空后再持续放入后续的后果，这时候状态才是显示 sending to client。 当查问后果能够全副放入net_buffer, 执行器也不论 net_buffer是否发送给 socket send buffer，都认为执行完了。5、对于失常的线上业务来说，如果一个查问的返回后果不会很多的话，倡议应用 mysql_store_result 这个接口，间接把查问后果保留到本地内存。 ...

敞开 mysql 的 ssl 性能首先咱们须要敞开 mysql 的 ssl，不然看不到具体的 sql 语句是什么 sudo vim /etc/mysql/mysql.conf.d/mysqld.cnf 编辑 mysqld 的配置文件，增加 skip_ssl 而后重启 mysql 服务 sudo service mysql restart 参考文章：MySql 敞开ssl 应用 tsharktshark -Y mysql -T fields -e mysql.query

问题你只有用缓存，就可能会波及到缓存与数据库双存储双写，你只有是双写，就肯定会有数据一致性的问题，那么你如何解决一致性问题？ 剖析先做一个阐明，从实践上来说，有两种解决思维，一种需保证数据强一致性，这样性能必定大打折扣；另外咱们能够采纳最终一致性，保障性能的根底上，容许肯定工夫内的数据不统一，但最终数据是统一的。 一致性问题是如何产生的？对于读取过程： 首先，读缓存；如果缓存里没有值，那就读取数据库的值；同时把这个值写进缓存中。双更新模式：操作不合理，导致数据一致性问题咱们来看下常见的一个谬误编码方式： public void putValue(key,value){ // 保留到redis putToRedis(key,value); // 保留到MySQL putToDB(key,value);//操作失败了}比方我要更新一个值，首先刷了缓存，而后把数据库也更新了。但过程中，更新数据库可能会失败，产生了回滚。所以，最初“缓存里的数据”和“数据库的数据”就不一样了，也就是呈现了数据一致性问题。 你或者会说：我先更新数据库，再更新缓存不就行了？ public void putValue(key,value){ // 保留到MySQL putToDB(key,value); // 保留到redis putToRedis(key,value);}这仍然会有问题。 思考到上面的场景：操作 A 更新 a 的值为 1，操作 B 更新 a 的值为 2。因为数据库和 Redis 的操作，并不是原子的，它们的执行时长也不是可管制的。当两个申请的时序产生了错乱，就会产生缓存不统一的状况。 放到实操中，就如上图所示：A 操作在更新数据库胜利后，再更新 Redis；但在更新 Redis 之前，另外一个更新操作 B 执行结束。那么操作 A 的这个 Redis 更新动作，就和数据库外面的值不一样了。 那么怎么办呢？其实，咱们把“缓存更新”改成“删除”就好了。 不再更新缓存，间接删除，为什么？业务角度思考起因很简略，很多时候，在简单点的缓存场景，缓存不单单是数据库中间接取出来的值。比方可能更新了某个表的一个字段，而后其对应的缓存，是须要查问另外两个表的数据并进行运算，能力计算出缓存最新的值的。 性价比角度思考更新缓存的代价有时候是很高的。如果频繁更新缓存，须要思考这个缓存到底会不会被频繁拜访？ 举个栗子，一个缓存波及的表的字段，在 1 分钟内就批改了 20 次，或者是 100 次，那么缓存更新 20 次、100 次；然而这个缓存在 1 分钟内只被读取了 1 次，有大量的冷数据。实际上，如果你只是删除缓存的话，那么在 1 分钟内，这个缓存不过就从新计算一次而已，开销大幅度降低。用到缓存才去算缓存。“后删缓存”能解决少数不统一因为每次读取时，如果判断 Redis 里没有值，就会从新读取数据库，这个逻辑是没问题的。 ...

1. 一条查问SQL的执行过程客户端 => 连接器 权限验证（连贯断开开释内存，对长连贯须要reset_connection）查问缓存（尽量不要应用，缓存命中率比拟低，8.0后齐全删除）分析器 语法分析 词法剖析 MySQL晓得你要做什么优化器 优化查问打算：抉择哪个索引？ 表连贯的时候决定表的连贯程序执行器：调用存储引擎接口取得每行数据，将合乎的后果存储在后果集中2. 一条更新SQL的执行过程redo log：先写日志，再写磁盘 => 保障 crash safeUpdate Set WHERE id = 2 1. 执行器找存储引擎取ID = 2的这一行，ID是主键索引，引擎间接通过树搜寻取得该行。如果原本就在内存中，间接返回；否则，从磁盘中加载这一行 1. 执行器将该行数据更改后调用引擎接口写入这行新数据 1. 引擎将数据更新到内存，同时写redo log，redo log 处于prepare状态，同时引擎告知执行器随时能够提交 1. 执行器写binlog并落盘 1. 执行器调用引擎的提交事务接口，引擎将redo log的状态改为提交，更新实现redo log 和 bin log 都能够示意事务的提交状态，而两阶段提交保障了二者逻辑一致性全量备份 + bin log ：复原、备库3. 事务隔离读未提交是指，一个事务还没提交时，它做的变更就能被别的事务看到。读提交是指，一个事务提交之后，它做的变更才会被其余事务看到。可反复读是指，一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是统一的。当然在可反复读隔离级别下，未提交变更对其余事务也是不可见的。串行化，顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当呈现读写锁抵触的时候，后拜访的事务必须等前一个事务执行实现，能力继续执行。可反复读的实现：回滚段 => 尽量避免长事务4. 索引为什么要用自增主键作为主键索引？（话中有话主键是间断的）：益处：每次插入都是追加操作，不须要移动其余记录，也不波及叶子节点的决裂。而采纳有业务逻辑的字段作为主键，则不能保障是有序插入，波及节点的决裂、合并。自增主键字段空间更小（4或8），则一般索引的叶子节点小，单页存储更多。个别状况下都应用自增主键，只有KV场景（只有一个惟一索引）例外。笼罩索引：不用回表最左前缀：建设联结索引时思考索引的程序5. 行锁两阶段锁：当须要时加锁，事务提交时才开释锁 => 尽可能将影响并发度的锁后推高并发时，死锁检测很有可能占用大量CPU资源6. 事务到底是隔离的还是不隔离的视图 view => 查问语句定义的虚构表实现MVCC用到的一致性读视图 =>事务ID 每行数据不同版本 row_trx_id 为每个事务结构了事务启动时以后沉闷的事务ID (启动了然而尚未提交） 低水位：数组外面最小trx_id 高水位：以后零碎创立的最大trx_id + 1 如果落在绿色局部，示意这个版本是已提交的事务或者是以后事务本人生成的，这个数据是可见的；如果落在红色局部，示意这个版本是由未来启动的事务生成的，是必定不可见的；如果落在黄色局部，那就包含两种状况a. 若 row trx_id在数组中，示意这个版本是由还没提交的事务生成的，不可见；b. 若 row trx_id不在数组中，示意这个版本是曾经提交了的事务生成的，可见。以后读 ：update 或 select for update / lock in share mode ...

摘要: 无论在平时开发中还是面试中咱们都会遇到一些MySQL的问题, 最近也在梳理一些MySQL的一些问题和整顿了一些学习思维导图，心愿对你有帮忙, 也欢送大家一起交换。 本文首发于公众号: 散步codingMySQL学习思维导图该图以 Markdown 绘制思维导图的开源工具——markmap(https://markmap.js.org/repl)主动渲染进去的, 如果须要Markdown原稿(看的更加清晰), 关注公众号, 回复mysql 即可取得。 面试中MySQL一些常见的问题1、CHAR、VARCHAR的区别是什么？ VARCHAR类型用于存储可变长度字符串，是最常见的字符串数据类型。它比固定长度类型更节俭空间，因为它仅应用必要的空间(依据理论字符串的长度扭转存储空间)。 VARCHAR节俭了存储空间，所以对性能也有帮忙。然而，因为行是变长的，在UPDATE时可能使行变得比原来更长，这就导致须要做额定的工作。如果一个行占用的空间增长，并且在页内没有更多的空间能够存储，在这种状况下，不同的存储引擎的解决形式是不一样的。例如，MylSAM会将行拆成不同的片段存储，InnoDB则须要决裂页来使行能够放进页内。 CHAR类型用于存储固定长度字符串：MySQL总是依据定义的字符串长度调配足够的空间。当存储CHAR值时，MySQL会删除字符串中的开端空格(在MySQL 4.1和更老版本中VARCHAR 也是这样实现的——也就是说这些版本中CHAR和VARCHAR在逻辑上是一样的，区别只是在存储格局上)。 同时，CHAR值会依据须要采纳空格进行残余空间填充，以不便比拟和检索。但正因为其长度固定，所以会占据多余的空间，也是一种空间换工夫的策略。 CHAR适宜存储很短或长度近似的字符串。例如，CHAR非常适合存储明码的MD5值，因为这是一个定长的值。对于常常变更的数据，CHAR也比VARCHAR更好，因为定长的CHAR类型不容易产生碎片。对于十分短的列，CHAR比VARCHAR在存储空间上也更有效率。例如用CHAR(1)来存储只有Y和N的值，如果采纳单字节字符集只须要一个字节，然而VARCHAR(1)却须要两个字节，因为还有一个记录长度的额定字节。 2、TRUNCATE和DELETE的区别是什么？ DELETE命令从一个表中删除某一行，或多行，TRUNCATE命令永恒地从表中删除每一行。 3、什么是触发器，MySQL中都有哪些触发器？ 触发器是指一段代码，当触发某个事件时，主动执行这些代码。在MySQL数据库中有如下六种触发器：1.Before Insert2.After Insert3.Before Update4.After Update5.Before Delete6.After Delete 4、FLOAT和DOUBLE的区别是什么？ FLOAT类型数据能够存储至少8位十进制数，并在内存中占4字节。DOUBLE类型数据能够存储至少18位十进制数，并在内存中占8字节。5、如何在MySQL种获取以后日期？ SELECT CURRENT_DATE()6、如何查问第N高的分数？ 这里有几个留神点: 因为问题可能有一样的值，所以应用DISTINCT进行去重如果不存在第N高问题的分数，那么查问应返回 null把下方的N换成具体的数值查问select ifNull( (select distinct `score` from students order by score Desc limit N-1,1),null) as target_score7、请阐明InnoDB和MyISAM的区别 这个在面试过程中过的比拟多。 InnoDB反对事务，MyISAM不反对；InnoDB数据存储在共享表空间，MyISAM数据存储在文件中；InnoDB反对行级锁，MyISAM只反对表锁；InnoDB反对解体后的复原，MyISAM不反对；InnoDB反对外键，MyISAM不反对；InnoDB不反对全文索引，MyISAM反对全文索引；8、innodb引擎的个性 1、插入缓冲（insert buffer)2、二次写(double write)3、自适应哈希索引(ahi)4、预读(read ahead)9、请阐明varchar和text的区别 varchar可指定字符数，text不能指定，外部存储varchar是存入的理论字符数+1个字节（n<=255）或2个字节(n>255)，text是理论字符数+2个字节。text类型不能有默认值。varchar可间接创立索引，text创立索引要指定前多少个字符。varchar查问速度快于text,在都创立索引的状况下，text的索引简直不起作用。查问text须要创立长期表。10、简略形容MySQL中，索引，主键，惟一索引，联结索引的区别，对数据库的性能有什么影响？ 这个在面试过程中过的比拟多。 一个表只能有一个主键索引，然而能够有多个惟一索引。主键索引肯定是惟一索引，惟一索引不是主键索引。主键能够与外键形成参照完整性束缚，避免数据不统一。联结索引：将多个列组合在一起创立索引，能够笼罩多个列。（也叫复合索引，组合索引）外键索引：只有InnoDB类型的表才能够应用外键索引，保证数据的一致性、完整性、和实现级联操作（根本不必）。全文索引：MySQL自带的全文索引只能用于MyISAM，并且只能对英文进行全文检索 （根本不必）11、创立MySQL联结索引应该留神什么？ 需遵循前缀准则 12、列值为NULL时，查问是否会用到索引？ 在MySQL里NULL值的列也是走索引的。当然，如果打算对列进行索引，就要尽量避免把它设置为可空，MySQL难以优化援用了可空列的查问,它会使索引、索引统计和值更加简单。 13：以下语句是否会利用索引：SELECT FROM users WHERE YEAR(adddate) < 2019 ...

"三高"Mysql - Mysql的根底构造理解引言 内容为慕课网的《高并发 高性能 高可用 MySQL 实战》视频的学习笔记内容和集体整顿扩大之后的笔记，在疾速视频学习一遍之后发现了许多须要补充的点，比方三次握手的连贯和Mysql的外部交互流程等等，对于后续的章节也会整合多篇文章后续会陆续公布。 Mysql的连贯形式 应用最多的形式是第一种形式，另外三种形式受限于非凡的平台形式实现，重点把握第一种TCP/IP的形式即可。 tcp/ip的连贯模式共享内存的连贯形式命名空间模式unix套接字的连贯形式Tcp/ip的通信协定 这一块在视频中解说比拟浅，所以这里参考了多方材料后，以《TCP/IP协定》作为参考介绍三次握手和四次挥手的过程。 通信协定也就是咱们常见的三次握手和四次挥手的流程，留神这里疏忽TCP/IP报文的格局介绍。 SYN：同步序号。FIN：发送方实现标记。ACK：仅当ACK=1时，确认号字段才无效，并且建设TCP连贯之后所有的连贯必须ACK=1。ack：承受申请之后将申请序列号+1进行回送应用。ISN：起始序号也别叫做Seq，该序号由工夫决定，所以每一个Tcp都有一个惟一的起始序号，组成的形式是开始的序号、一个冒号、隐含的结尾序号 及圆括号内的数据字节数，比方1415531521:1415531521（0），如果字节为0则被暗藏，只有当存在字节数据或者SYN、 FIN 或 RST 被设置为 1 才进行展现。Mss：示意的是以后报文的最大字节数。ISM可看作是一个32比特的计 数器，每 4ms + 1。三次握手建设TCP连贯（报问段1-3）第一步：客户端被动关上TCB端口，服务器被动关上TCB端口。发起方携带一个SYN标记，并且携带一个ISN序号Seq=x，然而须要留神的是第一步的过程这个ISN序号是暗藏传递的（因为没有传递数据），然而如果不存在数据的替换，则不会被显示。客户端发送SYN命令之把SYN=1，并且把SYN-SENT（同步-已发送状态）。第二步：服务器收到客户端TCP报文之后，也将SYN=1，并且回送一个新的ISN序号ack=x+1，并且将ACK=1示意本人收到了，而后在返回参数回送本人新的序列号示意本人的确认申请Seq=y，将状态设置为SYN-RCVD（同步收到）状态，（示意心愿收到的序号为xxxx1522），最初也是指定MSS。第三步：客户端收到服务器的确认报文之后，还须要向服务端返回确认报文，确认报文的ACK=1，并且回传服务器传递的ISN序号+1（ack = y+1），以及本人的ISN序号+1（Seq = x+1），此时TCP连贯进入已连贯状态，ACK是能够携带数据的，然而如果不携带数据则不耗费序列号。最初一步：当服务器收到客户端的确认，也进入已连贯状态。 Mysql认证连贯：（参考资料：http://mysql.taobao.org/monthly/2018/08/07/） Mysql的认证链接能够看作是三次交互，留神第一次申请是服务端发动的，有点相似咱们去店外面买货色，首先闭口的必定是员工，比方问咱们要什么货色，于是咱们花钱买货色，而后把货色带走，认证过程能够相似于这样的一个过程。 服务端 → 客户端 发送初始化包：服务端首先确认是那个客户端须要连贯客户端 → 服务端 验证服务端 → 认证后果音讯认证通过客户端与服务端断开 四次挥手端口tcp连贯（报文段4开始）第一步（客户端）：TCP发送开释连贯的报文，进行发送数据，开释报文首部，把FIN=1，同时发送序列号，依据上一次传送的序列号+1传送Seq = t + 1（因为下图是在连贯之后立马进行四次挥手，所以序列号没有变），此时客户端进行终止期待1的状态。留神FIN不携带数据也须要耗费序列号。第二步（服务端）：服务器回送确认报文，收回确认报文，ACK=1，并且把回传序列号+1回传（ack = t + 1），而后再带上本人的序列号Seq = y，此时服务端进入CLOSE-WAIT状态（敞开期待状态），TCP服务器此时须要进行下层利用客户端向服务端申请开释，处于 半敞开 阶段，此时服务端仍然能够向客户端发数据并且客户端须要承受并解决，敞开期待状态意味着整个状态还须要继续一段时间。第三步（客户端）：客户端接管到服务端确认申请，此时客户端进入到FIN-WAIT-2终止期待2的阶段，期待服务器的开释报文。（还有一部分服务器没有发送完的数据须要解决）第四步（服务端）：服务器把最初的数据处理结束，向客户端发送开释报文，FIN=1，ack=t + 1，因为须要把剩下的数据发送实现，假如解决实现之后须要带上本人的序列号Seq=w，服务器进入最初确认状态，期待客户端确认。第五步（客户端）：客户端收到报文之后，收回确认 ACK=1，ack=w+1，本人的序列号为Seq = t + 1，此时客户端进入到了TIME-WAIT（工夫期待状态），此时客户端还是没有开释，必须通过2 * MSL（最长报文寿命）之后，客户端撤掉TCB之后才进入CLOSED状态。第六步（服务端）：服务器收到客户端的申请立马进入CLOSE状态，同时撤销TCB，完结此次TCP的连贯。（服务端完结TCP连贯要比客户端早一些） 为什么须要四次挥手能力敞开连贯？ TCP/IP 是一种全双工的协定，任何一方敞开都须要双向的确认操作，单方敞开须要给对方发送一个FIN来终止连贯，一端收到FIN告诉应用层的另一端终止数据的发送，而收到一个FIN仅仅阐明一个方向不进行数据流动，通常敞开的一方（发送FIN的一方）为被动敞开，接受方为被动敞开，因为全双工个性单方都须要对方被动敞开。 通过上面的图能够简略理解为什么要这样设计： ...

前一段时间，有一个需要，须要做一个比较复杂的权限判断。问题是这样，已知用户领有权限[a,b,c].某个资源须要[c,d,e]权限之一即可拜访。那么如何用Mysql判断两个json数组是否存交加。 答案就是应用MySQL提供的 JSON_OVERLAPS() 函数。 留神，这个JSON_OVERLAPS() 是MySQL 8.0.17版本以上才反对的，如果你的MySQL版本低于这个版本，就能够考虑一下降级了先看两个简略示例： mysql> select JSON_OVERLAPS('[1,2]','[2,3]');+--------------------------------+| JSON_OVERLAPS('[1,2]','[2,3]') |+--------------------------------+| 1 |+--------------------------------+1 row in set (0.00 sec)因为数组[1,2]和数组[2,3]存在交加，所以返回值是1 mysql> select JSON_OVERLAPS('[1,2]','[3,4]');+--------------------------------+| JSON_OVERLAPS('[1,2]','[3,4]') |+--------------------------------+| 0 |+--------------------------------+1 row in set (0.00 sec)因为数组[1,2]和数组[3,4]不存在交加，所以返回值是0。 下面两个示例都是数值型的数组，那么字符串类的数组反对吗？当然是反对的，请看： mysql> select JSON_OVERLAPS('["a","b"]','["b","c"]');+----------------------------------------+| JSON_OVERLAPS('["a","b"]','["b","c"]') |+----------------------------------------+| 1 |+----------------------------------------+1 row in set (0.00 sec)mysql> select JSON_OVERLAPS('["a","b"]','["c","d"]');+----------------------------------------+| JSON_OVERLAPS('["a","b"]','["c","d"]') |+----------------------------------------+| 0 |+----------------------------------------+1 row in set (0.00 sec)那么咱们要如何把这个函数利用到select 查问当中呢，请看上面的示例。咱们先创立表，筹备根底数据 CREATE TABLE `user` ( `username` varchar(45) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL, `role` varchar(45) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL, UNIQUE INDEX `username_UNIQUE`(`username`) USING BTREE) ENGINE = InnoDB AUTO_INCREMENT = 35 CHARACTER SET = utf8 COLLATE = utf8_bin ROW_FORMAT = Dynamic;INSERT INTO `user` VALUES ('u1', '[\"a\",\"b\"]');INSERT INTO `user` VALUES ('u2', '[\"b\",\"c\"]');INSERT INTO `user` VALUES ('u3', '[\"c\",\"d\"]');所以表里数据是这样的。 ...

前言最近在看《高性能Mysql》-宁海元版一书的时候，原本想找对于mysql所有日志的介绍，深刻理解这些日志在整个mysql中表演的角色和作用，然而没有发现这块的汇总，零散的在书中散布，而后翻看了mysql官网文档中，也是在各种不同的中央简略介绍了日志，为了不便加深本人对mysql日志的了解，决定汇总一下这些mysql下的不同日志，所以写下这篇文章。 一、Mysql日志是什么？所谓日志，就是一种将行为动作记录到一个中央，这个中央能够是文件，文本等可存储的载体。Mysql日志就是记录整个mysql从启动，运行，到完结的整个生命周期下的行为。 二、Mysql日志类别1.General Query Log 一般查问日志• Log Control at Server Startup • Log Control at RuntimeGeneral Query Log是在服务器启动时和运行时的记录。 #查看一般查问日志是否开启 show VARIABLES like "%general_log" #开启形式 set global general_log = ON设置日志保留的地位set global general_log_file='D:\\log\\general.lg'执行一条SQL查问语句： select id from test;关上general.log发现这条语句被残缺记录下来了。留神：当开启general_Log后，mysql中的所有操作将会记录下来，这样general_Log文件就会产生很大的文件，此时须要清空此文件来开释磁盘空间，因而个别默认都是不开启general_Log。 2.Slow Query Log 慢查问日志查问日志由执行工夫超过 long_query_time几秒且至多min_examined_row_limit须要查看行的SQL组成**留神： mysqld在执行完所有锁之后，会在慢查问日志中写入一条语句，因而日志程序可能与执行程序不同** 查看慢查问日志是否开启show variables like 'slow_query%' 默认查问超过几秒才记录(个别状况下，默认是10秒)show variables like 'long_query_time'; 设置慢查问日志保留文件set global slow_query_log_file='D:\\log\\slow.log' 测试执行一条慢查问语句select sleep(11);这里能够看出是那个sql以及查问工夫。 慢查问日志内容解读：• Query_time: duration语句执行工夫，以秒为单位。• Lock_time: duration获取锁的工夫（以秒为单位）。• Rows_sent: N发送到客户端的行数。• Rows_examined:服务器层查看的行数（不包含存储引擎外部的任何解决）。• Set timestamp：语句蕴含批示慢语句何时被记录的工夫戳（在语句实现执行后产生） 开启慢查问日志中蕴含慢治理语句( ALTER TABLE、 ANALYZE TABLE、 CHECK TABLE、 CREATE INDEX、 DROP INDEX、 OPTIMIZE TABLE和 REPAIR TABLE)show VARIABLES like '%log_slow_admin_statements%'set global log_slow_admin_statements = on写入慢查问日志的语句中蕴含不应用索引进行行查找的查问show VARIABLES like '%log_queries_not_using_indexes%'set global log_queries_not_using_indexes = on ...

1：事务的基本要素（ACID）A (atomicity) 原子性# 默认mysql开启主动提交 将对应sql主动commit，否则须要人工提交show VARIABLES like 'autocommit'C (consistency) 连贯性protect data from crashes I (Isolation) 隔离性保障同一时间段 多个事务对同雷同数据的查问更新的操作 仍然放弃牢靠连贯(彼此隔离) D (Durability) 持久性2：概念阐明脏读(dirty read)事务A读取了事务B更新的数据，而后B回滚操作，那么A读取到的数据是脏数据(事务读取了另外一个事务中没有提交的数据) 不可反复读在同一个事务中，屡次读取同样的数据返回不同的后果 幻读3：隔离级别1： 读未提交（READ UNCOMMITTED）2： 读提交 （READ COMMITTED） oracle默认3： 可反复读 （REPEATABLE READ） mysql默认能够保障其余事务的对数据的批改(曾经提交)不会影响以后事务(以后事务读取同一个数据应该始终统一)，然而对于其余事务插入的数据能够读到(幻读) 4： 串行化 （SERIALIZABLE）从上往下，隔离强度逐步加强，性能逐步变差 事务隔离级别脏读不可反复读幻读读未提交（read-uncommitted）存在存在存在读提交（read-committed）否存在存在可反复读（repeatable-read）否否存在串行化（serializable）否否否# 演示基于mysql5.7# 查看隔离级别 默认为REPEATABLE READ mysql> select @@tx_isolation;+-----------------+| @@tx_isolation |+-----------------+| REPEATABLE-READ |+-----------------+1 row in setmysql> show variables like 'tx_isolation';+---------------+-----------------+| Variable_name | Value |+---------------+-----------------+| tx_isolation | REPEATABLE-READ |+---------------+-----------------+1 row in set# 批改以后session 隔离级别SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;读未提交(read-uncommitted)SELECT statements are performed in a nonlocking fashion,因为不加锁，性能最好。 ...

基于工夫类分区我之前写过实现篇、细节篇。明天来持续分享一下工夫类分区的实在案例： 某家互联网公司数据库系统内的分区表调优过程。 问题与背景：单张表数据量太大，每天会产生 10W 条记录，一年就是 3650W 条记录，对这张表的查问 95% 都是在某一天或者几天内，过滤区间最大不超过一个月。比方在2019年3月1日、2019年4月20日或者是2019年5月1日和2019年5月5日这个时间段内。偶然会波及到跨月、跨年查问，然而频率很低。记录保留10年。也就是单表3.6亿条记录，单表太大，不便于管理，前期如果单表损坏，修复也难。单表查问性能很差，对历史数据删除性能也很差。基于以上需要剖析后得出结论：查问过滤的数据范畴绝对比拟集中，不是那么扩散；要同时思考过期数据清理性能问题。思考把表拆分为10张新表，一张是以后表，残余9张是历史归档表；以后表寄存最近两年的数据，每到年底迁徙老旧数据到历史表进行归档，并且对过期历史数据进行清理。思考对局部过滤场景应用 MySQL 分区表，非常适合 95% 的查问；能够应用分区置换性能把数据移到历史表。分区表带来几个益处： 一是查问性能晋升；二是治理不便，过期数据间接疾速清理；三是对利用通明，临时不须要利用改代码。接下来看看表的优化过程：因为隐衷思考，不不便贴原始表构造，这里用构造简化的示例表来看下优化过程。原始表为 pt_old ，缩减字段个数到3，记录数缩减10倍为 3650W ，每年365W（客户原来字段有30个，记录数3.6亿），记录范畴从2011年到2020年，刚好十年的数据。 (localhost:ytt)<mysql>show create table pt_old\G*************************** 1. row *************************** Table: pt_oldCreate Table: CREATE TABLE `pt_old` ( `id` bigint unsigned NOT NULL AUTO_INCREMENT, `r1` int DEFAULT NULL, `log_date` date DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_log_date` (`log_date`)) ENGINE=InnoDB AUTO_INCREMENT=64306811 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci1 row in set (0.00 sec)(localhost:ytt)<mysql>select min(log_date),max(log_date),count(*) from pt_old;+---------------+---------------+----------+| min(log_date) | max(log_date) | count(*) |+---------------+---------------+----------+| 2011-01-01 | 2020-12-31 | 36500000 |+---------------+---------------+----------+1 row in set (21.14 sec)先导出原始表数据（依照年导出10份数据），前期间接导入到新分区表，执行以下脚本： ...

MySQL简介： 依据查问后果返回一个正的 MySQL 后果资源号，出错时返回 FALSE。本函数会对 INSERT/UPDATE/DELETE 查问返回 TRUE/FALSE 来批示胜利或失败。 mysql_db_query() 抉择一个数据库并在其上执行查问。如果没有提供可选的连贯标识，本函数会去找一个到 MySQL 服务器的已关上的连贯，如果找不到已关上连贯则会尝试无参数调用 mysql_connect() 来建设一个。 留神此函数不会切换回先前连贯到的数据库。换句话说，不能用此函数长期在另一个数据库上执行 sql 查问，只能手工切换回来。强烈建议用户在 sql 查问中应用 database.table 语法来代替此函数 MySQL相干视频教程：https://www.bilibili.com/video/BV1Vy4y1z7EX 增删改查语句 增删改查的语句命令为： 库操作 表操作创立数据库表：创立一个表名为：employee，该表中含有id、name、sex、birthday、job字段 create table employee( id int, name varchar(40), sex char(4), birthday date, job varchar(100));表中减少image字段： alter table employee add image blob;批改job值，使其长度为60（原长度为100）： alter table employee modify job varchar(60);删除sex列： alter table employee drop sex;表名改为user（原名employee）： rename table employee to user;批改表的字符集为utf-8： alter table user character set utf8;列名name改为username： alter table user change column name username varchar(100);删除表： ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。[toc] 本次介绍如何利用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/Linux筹备好上面三台服务器： IP端口角色172.16.16.103306Primary172.16.16.113306Secondary172.16.16.123306Secondary1. 装置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了。 ...

@[toc]明天想和大家聊一聊 MySQL 中的 redo log，其实最早我是想聊两阶段提交的，起初想想可能有小伙伴还不理解 binlog，所以就先整了一篇 binlog： 手把手教你玩 MySQL 删库不跑路，间接把 MySQL 的 binlog 玩溜！MySQL删库不跑路（视频版）binlog 大家懂了之后，接下来还差个 redo log，redo log 大家也懂了，那么再讲两阶段提交置信小伙伴们就很容易懂了，咱们一步一步来。 1. 谁的 redo log学习 redo log，我感觉首先要搞明确一个问题，就是是谁的 redo log？ 咱们晓得，MySQL 架构整体上分为两层：Server 层和存储引擎层，如下图： 后面松哥文章+视频跟大家聊的 binlog，是 MySQL 本人提供的 binlog，而 redo log 则不是 MySQL 提供的，而是存储引擎 InnoDB 本人提供的。所以在 MySQL 中就存在两类日志 binlog 和 redo log，存在两类日志既有历史起因（InnoDB 最早不是 MySQL 官网存储引擎）也有技术起因，这个咱们当前再细聊。 先把这个问题搞清楚，前面很多中央就容易懂了。 2. buffer pool在正式介绍 redo log 之前，还有一个 buffer pool 须要大家理解。 小伙伴们晓得，InnoDB 引擎存储数据的时候，是以页为单位的，每个数据页的大小默认是 16KB，咱们能够通过如下命令来查看页的大小： 16384/1024=16 刚好是 16KB。 ...

一、理解对等部署KunlunDB是计算&存储拆散的分布式数据库，反对海量数据处理，能够解决传统数据库分库&分表带来的复杂性问题。 KunlunDB的外围组件如下图所示，由计算引擎和存储引擎组成。 计算引擎次要负责数据处理计算，是CPU资源密集型服务器，而存储引擎是IO资源密集型服务器，在理论生产环境部署过程中，能够将计算引擎和存储引擎部署在同一台服务器上，以取得资源的无效利用，同时通过不同节点间的组件冗余来实现高可靠性。 典型的对等部署构造下图所示： KunlunDB集群服务数量没有限度，对等部署架构的特点是计算节点与存储节点并存于同一台物理服务器内，每台服务器既运行计算节点，同时也运行存储节点。 对于多正本Shard,主从正本不能位于同一台服务器内，而应该对等的散布在其余的服务器里。 1.1 KunlunServer(计算节点） 计算节点运行无状态计算&查问引擎，与存储进行交互执行SQL 工作，采纳异步通信模式，计算节点岂但能够本机上的存储节点交互，也能够通过网络与对接节点上其余的存储节点交互进行数据处理。 客户应用程序能够连贯到任意一台计算节点执行KunlunDB集群的数据处理工作。 1.2 KunlunStorage(存储节点） 存储节点由多个存储分片（Shard）组成，Shard的主从正本对等散布在可用的服务器中，每台服务器的存储节点是由某个Shard的主正本及其他Shard的从正本组成。 对等部署的益处： 无效利用服务器硬件资源 组件在服务器之间互相冗余进步系统可靠性 不便扩容，灵便扩大 二、对等部署指南2.1 资源筹备：在对等部署计划中，各台服务的硬件配置应该统一， 操作系统及版本统一，服务器之间的网络带宽倡议是千兆或以上。 2.2 每台服务器的运行一个计算节点。 2.3 集群的Shard个数不应该超过服务器的数量，每台服务器只能运行集群的一个Shard的主节点。每个Shard的主从正本的参数配置利用统一。不同Shard的参数配置能够依据业务需要做共性配置。 2.4 每个Shard的正本数量能够依据业务需要定义，KunlunDB集群对正本数量没有限度，但从可靠性思考，倡议每个shard起码3个正本，正本数量不超过可用的机器数量。 2.5 在配置，倡议主从正本不要运行在同一台服务器内。 2.6 治理组件及其他组件： 元数据集群：倡议部署为一主两从的高可用模式，暂用资源较少，可依据现网状况抉择相应服务器部署。集群管理器：倡议部署为一主两从的高可用模式，暂用资源较少，可依据现网状况抉择相应服务器部署。节点管理器：每台服务器部署一个。三、装置部署过程对等部署的装置具体过程能够参考文档: KunlunDB疾速入门装置指南, KunlunDB 1.0将反对基于WEB UI界面的对等模式装置，进步装置的易用性。 对等部署的服务器资源布局参照上面表格（以三节点为例） 四、对等部署服务器配置要求做为分布式数据库，KunlunDB集群对服务器的配置要求绝对较低，入门级的KunlunDB集群的服务器配置参考如下： KunlunDB入门级机器配置： 服务器3台：亚马逊m5.4xlarge机型（CPU 8cores 16Threads , 内存64G，存储gp3, 通用型SSD卷3000IOPS ，125MB/s吞吐量，节点间网络带宽10G）。数据库软件：KunlunDB 0.9.1。部署架构：对等部署，3Shard , 每个Shard有3个正本。KunlunDB我的项目已开源 【GitHub：】https://github.com/zettadb 【Gitee：】https://gitee.com/zettadb END

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。深入浅出MGR1.MGR简介 | 深入浅出MGRhttps://mp.weixin.qq.com/s/lbU5KaY2hEPq4gnwJ8PgCg 2.组复制技术架构https://mp.weixin.qq.com/s/6__H3-HFsBtZk336EaAcrQ 3.装置部署MGR集群Rhttps://mp.weixin.qq.com/s/Nh37KuBQZ137BpmqG26_OQ 4.利用MySQL Shell装置部署MGR集群https://mp.weixin.qq.com/s/51ESDPgeuXqsgib6wb87iQ 5.MGR治理保护https://mp.weixin.qq.com/s/D5obkekTClZEdN2KQ9xiXg 6.MGR状态监控http://mp.weixin.qq.com/s/XXc-WeErjaVhISAuIJz1eA MGR其余内容MGR的gtid_executed不间断的问题剖析https://mp.weixin.qq.com/s/20X9Hwl7SSzeTp5yo6X08Q MGR及GreatSQL资源汇总https://mp.weixin.qq.com/s/qXMct_pOVN5FGoLsXSD0MA 主从复制MySQL主从复制原理及搭建过程https://mp.weixin.qq.com/s/X2k2oOROZOAdVql4SeoO3Q MySQL主从复制之GTID模式介绍https://mp.weixin.qq.com/s/9gzGmFKyjxTgkWtBpetl2A MySQL主从复制之半同步(semi-sync replication)https://mp.weixin.qq.com/s/BhQgCcoOgC6sEgzxux858w MySQL主从复制之并行复制阐明https://mp.weixin.qq.com/s/tx2W_IQufX-ngmtjYE5HQw 主从构造不统一复制问题验证https://mp.weixin.qq.com/s/8DJ_5WpdyPeukqpviKtJzg 万答系列万答#20，索引下推如何进行数据过滤https://mp.weixin.qq.com/s/pt6mr3Ge1ya2aa6WlrpIvQ 万答#21，如何查看 MySQL 数据库一段时间内的连贯状况https://mp.weixin.qq.com/s/1eAb4AdvPDeJFlxVTxIrvw 万里课程只有9.9元！零根底学习MySQLhttps://mp.weixin.qq.com/s/7g4wjxs_m3AGuCrEhnmtxg 其余内容Windows环境下部署MySQL主从并模仿降级到8.0https://mp.weixin.qq.com/s/XZOutq9dkaPwlSqK8z6-Ww Linux环境监控工具汇总https://mp.weixin.qq.com/s/SYFR3VnSl4zMGfMix_6Dig MySQL Test Run 测试框架介绍https://mp.weixin.qq.com/s/JA5hfaZuRMPFa7LmLUvfbQ 对于MySQL function创立的限度https://mp.weixin.qq.com/s/y6pMRD2-NAf6a5AXu0n0qQ 简略学习一下ibd数据文件解析https://mp.weixin.qq.com/s/gpYlkBZcqQRt01EELPk_zw Enjoy GreatSQL :) 文章举荐：GreatSQL季报（2021.12.26） https://mp.weixin.qq.com/s/FZ... 技术分享|sysbench 压测工具用法浅析 https://mp.weixin.qq.com/s/m1... 故障剖析 | linux 磁盘io利用率高，剖析的正确姿态 https://mp.weixin.qq.com/s/7c... 技术分享|闪回在MySQL中的实现和改良 https://mp.weixin.qq.com/s/6j... 万答#20，索引下推如何进行数据过滤 https://mp.weixin.qq.com/s/pt... 对于 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 公布！

大家好，我是咔咔 不期速成，日拱一卒 在平时开发工作中join的应用频率是十分高的，很多SQL优化博文也让把子查问改为join从而晋升性能，但局部公司的DBA又不让用，那么应用join到底有什么问题呢？ 一、什么是Nested-Loop Join 在MySQL中，应用Nested-Loop Join的算法进行优化join的应用，此算法翻译过去为嵌套循环连贯，并且应用了三种算法来实现。 ● Index Nested-Loop Join ：简称NLJ● Block Nested-Loop Join ：简称BNLJ● Simple Nested-Loop Join ：简称 BNL 这几种算法大抵意思为索引嵌套循环连贯、缓存块嵌套循环连贯、粗犷嵌套循环连贯，你当初看的程序就是MySQL抉择join算法的优先级。 从名字上给人感觉Simple Nested-Loop Join算法是非常简单同样也是最快的，但理论状况是MySQL并没有应用这种算法而是优化成应用Block Nested-Loop Join，带着各种疑难一起来摸索其中的神秘。 都看到这里了，是不是对嵌套循环连贯的意思不太明确？其实是非常简单的，一个简略的案例你就能明确什么是嵌套循环连贯。 假如当初有一张文章表article，一张文章评论表article_detail，需要是查问文章的id查问出所有的评论当初的首页，那么SQL就会是以下的样子 select * from article a left join article_detail b on a.id = b.article_id 若应用代码来形容这段SQL的实现原理大抵如下，这段代码应用切片和双层循环实现冒泡排序，这段代码就能十分代表SQL中join的实现原理，第一层for即为驱动表，第二层for则为被驱动表。 func bubble_sort(arr []int) { a := 0 for j := 0; j < len(arr)-1; j++ { for i := 0; i < len(arr)-1-j; i++ { if arr[i] > arr[i+1] { a = arr[i] arr[i] = arr[i+1] arr[i+1] = a } }}} ...

EEE6207 – Assignment – 2020/21P. Rockett12th December 2020NoteThis assignment will almost certainly require you to do some searching to identify suitablemethods of solving the problem(s). The Linux API—the system to be used here—contains somany functions that it is impossible to learn all the details. Therefore, real systems programmingfrequently involves looking through the documentation. However, by this stage in thecourse, you should understand enough about operating systems to narrow your search downto the relevant OS features.1 IntroductionComputers are increasingly being used in control applications. Consider the case of a computerbasedcontroller where the system generates an updated control input every 10-15 minutes—in otherwords, this is a real-time controller, but the time scale is not computationally very demanding. Suchsystems are common in, for example, chemical engineering where the characteristic response time ofa physically massive chemical reactor is very slow due to inertia.Looking at the simple example program below, the main program comprises an infinite loop(since control is ongoing). The value of the input to the control variable u is determined by a simplefunction called control function that takes the time index t as an input. Notice that in this trivialexample, the printf statement mimics sending the value of u to the plant at which point the processsleeps for some period equal to the update time for the controller—maybe 10-15 minutes might beused in practice for a large, slowly-responding plant1.// Example controller program -- pir ...

前言随着对mysql的深刻了解，以及接触mysql越来的频繁，发现mysql的这些ID们在整个mysql中的作用非常可观，因而对于这些ID，专门写一篇文章来让大家介绍和深刻的了解，目前文章中列出来的是比拟罕用的和我所想到的这几个ID，后续有其余的会持续补充。 一、什么是ROW_ID？ROW_ID If a table has a PRIMARY KEY or UNIQUE NOT NULL index that consists of a single column that has an integer type, you can use _rowid to refer to the indexed column in SELECT statements简略翻译一下，如果在表中存在主键或非空惟一索引，并且仅由一个整数类型的列形成，那么就能够应用SELECT语句间接查问_rowid，也就是说row_id就是行索引id。总结一下就是三个条件： 1. ，主键 2. ，非空惟一索引 3. ，整数类型 接下来看看这些条件在以下各个场景组合会产生什么？后果就先放进去： 若只存在主键+整型 -》 row_id失效 ，取主键值若只存在非空惟一索引+整型 -》row_id失效 ，取非空索引值若存在多个非空惟一索引 -》 row_id严格取第一个，满足就无效，第一个不满足就生效。 若主键和非空惟一索引同时存在 -》row_id失效，取主键值。若主键和非空惟一索引都不存在：取全局变量dictsys.row_id测试场景1： 设置了主键，并且主键字段是数值类型的状况下，_rowid间接援用了主键字段的值，这种叫显示rowid。 改了主键类型为varchar，就报错了。 其余的几个场景我就不在这一一举例了，有趣味的能够本人去测试一下。 二、什么是XID？XIDXid 是由 server 层保护的。InnoDB 外部应用 Xid，就是为了可能在 InnoDB 事务和 server 之间做关联。Xid 在 MySQL 外部的生成逻辑： ...

MySQL Shell无奈拉起MGR集群解决办法用MySQL Shell要从新拉起一个MGR集群时，可能会提醒上面的错误信息： Dba.rebootClusterFromCompleteOutage: Unable to get an InnoDB cluster handle. The instance '172.16.130.197:3306' may belong to a different cluster from the one registered in the Metadata since the value of 'group_replication_group_name' does not match the one registered in the Metadata: possible split-brain scenario. Please retry while connected to another member of the cluster. (RuntimeError)意思是该节点属于其余MGR集群（从元数据读取到的 group_replication_group_name 值判断的），因而不能间接拉起。 这种谬误常见于MySQL 5.7版本构建的MGR集群环境下，如果是运行MySQL 8.0的话则个别很少见。 之所以会这样，是因为MySQL 5.7中还不反对 SET PERSIST 性能。 在MySQL 8.0中，用MySQL Shell构建MGR集群时，会随机生成一个UUID作为 group_replication_group_name，并以 SET PERSIST 的形式长久化（保留到 mysqld-auto.cnf 文件中），实例重启时还能持续读取。 ...

天色将晚， 在我看着你的眼里色彩斑斓 《娱乐天空》序在《MySQL事务学习笔记(一) 初遇篇》咱们曾经交代了如何开启事务、提交、回滚。然而还有一个小尾巴被脱漏了，就是如何设置事务的隔离级别。本篇咱们就来介绍MySQL中是如何设置隔离级别ySQL中是如何实现事务的ACID以及隔离级别。写作这篇文章的时候，我也在思考如何组织这些内容，是再组织一下本人看的材料上的内容，还是笔记式的，列举一下知识点。坦白的说我不是很喜爱列举知识点这种模式的，感觉没有一条线组织起来，我集体比拟喜爱的是像是树个别的常识组织构造，有一条骨干。所以本篇在介绍MySQL是实现事务实现的时候，会先从宏观上介绍其组织，局部知识点不会太具体，这样的形式能够让咱们先把握其骨干，不会迷失在细节中。 设置事务隔离级别select @@tx_isolation; 我的MySQL默认隔离级别为可反复读，SQL事务的隔离级别: 未提交读已提交读可反复读可串行化。MySQL反对在运行时和启动时设置隔离级别: 启动时设置隔离级别: windows下的配置文件取 my.ini Linux下的配置文件取 my.cnf 在配置文件中增加: transaction-isolation = 隔离级别 隔离级别的候选值: READ COMMITTED， REPEATABLE READ， READ UNCOMMITTED，SERIALIZABLE 运行时设置隔离级别 SET [GLOBAL|SESSION] TRANSACTION ISOLATION LEVEL level; LEVEL的候选值: READ-COMMITTED， REPEATABLE READ， READ UNCOMMITTED，SERIALIZABLE GLOBAL的关键字在全局范畴内影响，在执行完上面语句之后: SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE;前面所有的会话的隔离级别都会变为可串行化； 而SESSION关键字则是只在会话范畴内影响，如果事务还未提交则只对前面的事务无效。 如果GLOBAL和SESSION都没有，则只对以后会话中下一个行将开启的事务无效，下一个事务执行结束，后序事务将复原到之前的隔离级别。该语句不能在曾经开启的事务中执行，会报错。 上面咱们就来演示事务在不同的隔离级别会呈现的问题: 事务的隔离级别为未提交读:SET GLOBAL TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; 而后再关上一个窗口: 产生了脏读 事务的隔离级别为已提交读SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED; ...

最近的工作在做业务库迁徙，如何做到平滑迁徙，保持数据一致性，尽量不停服是迁徙工作谋求的指标。本文分享一些数据迁徙工作常见计划以及当中须要留神的点。 先说下数据迁徙当中须要留神的点： 集体了解最重要的应该是数据的一致性，说的直白点，就是在数据迁徙当中，怎么保证数据不失落（大部分业务零碎的访问量很高，即使在凌晨两三点也有肯定的访问量，在迁徙当中怎么保障写入的数据不失落至关重要）。 其次重要的是迁徙步骤当中的执行程序，比方是先改db host，还是先迁徙数据，还是先做其余什么操作？个别的过程大体是这样： 1.先选一个闲时，尽量还是抉择用户操作少的时间段（比方凌晨），缩小数据写入和读取 2.停掉定时工作&一些周边容许进行的服务组件（比方消费者MQ之类的），这一步的目标还是为了缩小数据写入和读取，这一步视零碎而定，鄙人迁徙的过程，停掉定时工作是在容许范畴内的。对于零碎自身，绝大部分性能还是可用的，只有少部分性能可能受到影响，主体性能不受影响，零碎提供有损服务。 3.dump mysql源库数据 4.将上一步失去的数据source到指标库 5.脚本检查数据迁徙的正确性（数据量和库表是否合乎预期） 6.将db配置指向新库【可能是改host, 可能是改db的形式，或者还须要配合公布等操作】（这一步不能提前到source之前，如果提前的话，从用户角度来看，存在数据失落，从运维角度来看，会加大存量历史数据的解决难度，比方id抵触之类的） 7.查看流量是否全切到新库 8.开启定时工作等job服务以及其余周边服务组件 大体是上述流程，可能会依据具体零碎不同而略有差别，以上就是迁徙过程中须要留神的点，然而具体要怎么操作呢？比方上述第三步之后源库产生新的数据怎么破？ 上面介绍一些数据迁徙的一些常见计划： 1.主从同步的形式迁徙数据。具体操作： A. 给源库挂一个从库，开启主从同步（个别先全量dump --master-data=2，而后再设置从库） B. 从库数据数据追上后，闲时停服，将从库降级为主库，将业务DB指向新的主库 C. 查看旧库上是否还有流量 D. 启动服务 这种形式的成本低，操作性强，但须要停服一会儿。 2.双写，适宜场景：数据结构不同，我的项目中常常用到，罕用于重构某个性能导致的数据结构变动的迁徙。具体操作： A. 新旧库同时写入（增删改） B. 公布新代码前，先全量同步一次数据到新库，公布实现后，再增量对账（对账脚本）一遍新旧库数据（次要针对公布当中，因为滚动更新新旧代码共存期间产生的局部数据只写了旧库，没有写新库的状况），或者依据modified或created字段，增量同步此段时间产生的数据，当然也要视双写代码的具体实现而定，如果双写每次新库都是删除后新增的话，可能就没有必要第二次的对账。如果双写要思考性能，能够用MQ等异步队列的形式写新库。 C. 通常为了验证双写的正确性，能够采纳灰度的形式，让局部流量切到新库，直到稳固后，才全量新库。 3.利用Canal和DTS等数据同步工具做数据同步4.利用MHA高可用计划做 mysql迁徙（对外vip不变，业务层不须要改变） 以上就是一些数据迁徙的惯例计划。 专一Web开发、后盾开发、DB性能及架构我的公众号“码农漫谈”，如果喜爱我的文章，能够关注公众号，打工不易：（，欢送技术沟通与交换，每天提高一点点

数值类型TINYINT，大小1bytes，有符号范畴为-128~127，无符号范畴为0~255 #计算(-2 ^ (8 * 1)) / 2 = -128 (2 ^ (8 * 1))/2 - 1 = 127 (2 ^ (8 * 1)) - 1 = 255SMALLINT，大小2bytes，有符号范畴为-32768~32767，无符号范畴为0~65535 #计算(-2 ^ (8 * 2)) / 2 = -32768(2 ^ (8 * 2)) / 2 - 1 = 32767(2 ^ (8 * 2)) - 1 = 65535MEDIUMINT，大小3bytes，有符号范畴为-8388608~8388607，无符号范畴为0~16777215 #计算(-2 ^ (8 * 3)) / 2 = -8388608(2 ^ (8 * 3)) / 2 - 1= 8388607(2 ^ (8 * 3)) - 1 = 16777215INT，大小4bytes，有符号范畴为-2147483648~2147483647，无符号范畴为0~4294967295 ...

一、分布式数据库的根底外围能力-程度扩容（ScaleOut）数据库系统架构的演变，如实的反映了信息社会一直倒退所带来的数据处理规模一直变大这一根本事实。 现在，分布式数据库产品已成为各行各业信息系统的存储服务中，利用越来越宽泛的技术选型。究其原因，是因为其在海量数据存储管理的扩大能力和性价比方面，较单机数据库有着压倒性的劣势。 在咱们对昆仑分布式数据库的扩容性能正式开始介绍之前，咱们首先回顾一下数据库管理系统扩容的常见模式。 数据库的扩容大体上分为如下两种模式：垂直扩容（Vertically Scale Up），程度扩容（Horizontally Scale Up）。 Vertically Scale Up垂直扩容是指对物理资源，如存储容量、计算能力、网络带宽等资源的扩大。 这种扩容形式由单机物力资源的瓶颈触发，以裁减单机物理资源为解决方案，满足数据库系统对物力资源的需要。然而这种扩容形式的毛病也是不言而喻的：单机物理资源总有下限，且个别价格十分低廉。 Horizontally Scale Up程度扩容的基本思路是将数据依照肯定的规定散布在不同的物理设施上，整个零碎对外依然出现逻辑上的繁多数据库服务。 零碎的扩大形式以通过减少物理设施的个数，来晋升数据库的整体对外服务能力。这种扩大模式，能够说在实践上实现了有限扩大。 其中，如果扩大的物理节点，蕴含了存储能力，则称为share-nothing架构，否则称为share-storage架构。 咱们熟知的oracle-RAC就是典型的share-storage架构，所有计算节点共用一套存储服务，而昆仑分布式数据库是典型的share-nothing架构。 如果从物理设施扩大引发的读写抵触的角度来扫视这两种架构的优劣的话，share-nothing架构下，数据分片存储在多个存储集群中，分片之间没有交加，因此不会产生多点写入抵触的问题，因而线性扩大能力绝对于share-storage有劣势，但分布式事务处理和分布式查询处理性能以及主动的、利用无感知的程度弹性扩容等外围性能是在这种架构下必须要实现的性能，只有具备了所有这些性能，才是真正的分布式数据库系统。 这也是为什么分库分表中间件和应用层分库分表曾经不再适宜以后的技术水平要求—这些技术计划没有上述性能，会给利用开发者和DBA带来惨重的累赘和工作量，相当于要在利用代码中case by case实现分布式数据库系统的分布式事务处理和分布式查询处理性能，以及DBA手动停服实现扩容，这些惨重的累赘给利用零碎的稳定性可靠性带来微小的危险，并且验证影响客户业务发展和终端用户体验。 昆仑分布式数据库在架构选型时，就充分考虑到了上述的种种问题。基于咱们本身对分布式事务处理和分布式查询处理性能以及主动程度扩容的等分布式数据库外围性能的丰盛的设计和实现教训以及对相干用户需要的深刻理解，以及对线性扩展性的极致谋求，咱们在昆仑分布式数据库中实现了基于share-nothing架构的业务无感知的程度弹性扩容机制，更好地满足业务快速增长对数据库系统的服务要求。 二、昆仑分布式数据库ScaleOut性能介绍2.1 存储层程度扩容昆仑分布式数据库的存储服务逻辑上由多个独立的MySQL集群组成，每个集群称为一个shard。 每个shard是昆仑分布式数据库存储层的独立的容灾服务单元，不同shard之间数据互相独立。因而存储层的扩容，咱们只须要减少shard这一独立的容灾存储单元即可。 在实现新的shard退出集群后，另一个更重要的须要解决的问题是如何将数据从原有的shard中迁徙到新的shard中，从而对数据读写的申请和数据存储的负载，实现存储层整体服务能力的晋升。 昆仑分布式数据库基于上述的业务要求，实现了无锁的数据shuffle（搬迁）服务，在实现热数据无效摊派的根底上，牢靠的保障了存储服务的连续性，并且对利用零碎无感知无侵入。该搬迁服务既能够用于扩容也能够用于缩容。比方为了双十一促销须要长期减少几倍的计算和存储能力，促销完结后开释相干计算和存储资源并还给私有云平台。 lock-free shuffle service在抉择迁徙哪些数据上，昆仑分布式数据库会依据某些规定选定须要搬迁的表分片（后续撰文介绍），给出待迁徙表的汇合。其目标是为了可能辨认出真正的热点数据，从而更加平衡实现流量摊派以及更加高效的分布式查问。同时在数据 shuffle 的流程设计上，咱们也做了无锁化解决，确保一个表在被搬迁的整个过程中继续的可读可写，达到了业务零感知。 整个shuffle过程包含以下几个步骤。假如以后给出的shuffle-set(待迁徙的库表) 是从shard2迁徙到新shard上。 第一步：须要实现的就是shuffle-set的dump和load操作。 在dump阶段，会保留一个snapshot的点位，即后续开始binlog复制的起始地位。整个dump的过程不会阻塞业务的申请。dump实现后，会并行的将dump的数据文件，load到新的shard中。 在dump和load的过程中，昆仑分布式数据库的集群管控模块cluster_mgr 和节点管控模块node_mgr会协同工作，实现shuffle-set中表的数据搬迁工作。 如上图所示整个过程会划分为三个子工作下发到对应的node_mgr上： Dump_taskCluster_mgr下发dump工作到shard2的备机上，对应的node_mgr应用mydumper工具开始并发执行dump工作，待实现工作后，向cluster_mgr应答工作实现。 Transfer_task第一阶段的dump工作实现后，cluster_mgr会向shard-new主机上的 node_mgr下发transfer_task的命令，由shard-new向shard2 拉取对应的dump文件。download实现后，shard-new上的node_mgr向cluster_mgr 应答工作实现。 Load_task在实现了transfer_task后，cluster_mgr开始向shard_new下发load_task，工作的执行过程中，node_mgr应用myloader工具，并发的向shard-new中load 数据，实现后向cluster_mgr应答工作胜利。 第二步：会建设新shard与源shard之间的数据同步，将源shard 上从snapshot点开始到以后工夫shuffle-set的数据变动全副apply 到新的shard上。 数据同步链路的建设，利用MySQL原生的基于binlog的同步机制，通过建设一个只蕴含shuffle-set同步表的长期同步通道，并利用dump snapshot作为同步的起始点，拉取数据的增量志，并且以并发的形式在shard-new上重放这些日志，直到整个同步提早在预约的工夫范畴内（默认3 秒），之后开始进行表切换操作。 表切换操作，会在源shard上对表进行rename，切断业务的新的申请。随后如果计算节点拜访该表会发现表不存在，计算节点会从本人的元数据中找到表的新地位，该新地位由cluster_mgr在后续步骤更新。 实现shard2上的rename操作后，会在shard-new上确认rename操作曾经replay，之后整个数据同步channel会被切断。假如表A在shuffle-set中，那么此刻，shard-2上蕴含一个表A-renamed，同时，shard-new上也蕴含一个完全相同的表A-renamed。 第三步：告诉所有的计算节点shuffle-set表的路由更新。shuffle-set表正式对外服务。 当数据同步的提早在一个正当的小的范畴内的时候，此时会在源shard上对表进行rename操作，切断业务的新的申请。实现rename操作后，整个数据同步链路会被切断。假如表A在shuffle-set中，那么此刻，shard-2上蕴含一个表A-renamed，同时，shard-new上也蕴含一个齐全想同的表A-renamed(rename 操作也会由源 shard 同步到指标shard)。 2.2 计算层程度扩容昆仑分布式数据库的计算节点采纳无状态服务设计，所有的计算节点不在本地长久化任何与集群相干的数据。 因而，在计算能力扩容的设计和实现上，昆仑分布式数据库有着人造的劣势，即疾速的部署计算节点服务到集群中，计算节点服务在拉起后，会主动的从元数据集群中同步相干信息，包含路由信息，存储节点相干信息等。 ...

1. 获取工夫函数性能返回格局CURDATE(), CURRENT_DATE()返回以后日期，只蕴含年、月、日2022-03-08CURTIME(), CURRENT_TIME()返回以后工夫，只蕴含时、分、秒19:35:46NOW(), SYSDATE(), CURRENT_TIMESTAMP(), LOCALTIME(), LOCALTIMESTAMP()返回以后零碎日期和工夫2022-03-08 19:37:07UTC_DATE()返回UTC（世界规范工夫）日期2022-03-08UTC_TIME()返回UTC（世界规范工夫）工夫11:38:522. 日期与工夫戳的转换函数性能返回格局UNIX_TIMESTAMP(), UNIX_TIMESTAMP(NOW())以UNIX工夫戳的模式返回以后工夫1646739875FROM_UNIXTIME(1646739875)将UNIX工夫戳转换为一般工夫格局2022-03-08 19:44:353. 获取月份、星期、星期数、天数等函数函数性能返回格局YEAR(NOW()),/MONTH(NOW()),/DAY(NOW())返回年/月/日2022/3/8HOUR(NOW()), /MONTH(NOW()), /DAY(NOW())返回时/分/秒19/3/8MONTHNAME(NOW())返回英文月份MarchDAYNAME(NOW())返回星期几TuesdayWEEKDAY(NOW())返回周几（从0开始）1（星期二）QUARTER(NOW())返回日期对应的季度，范畴1-41WEEK(NOW()), WEEKOFYEAR(NOW())返回一年中的第几周10DAYOFYEAR(NOW())返回一年中的第几天67DAYOFMONTH(NOW())返回所在月份中的第几天8DAYOFWEEK(NOW())返回周几（周日为1）3（星期二）4. 日期的操作函数-- 返回指定日期中的特定局部，type指定返回的值；SELECT EXTRACT(TYPE FROM NOW()) FROM DUAL;TYPE的含意与取值： type取值含意返回值MICROSECOND返回毫秒数 SECOND返回秒数12MINUTE返回分钟数25HOUR返回小时数20（24小时制）DAY返回天数8WEEK返回日期在一年中的第几个星期10MONTH返回日期在一年中的第几个月3QUARTER返回日期在一年中和第几个季度1YEAR返回日期的年份2022SECOND_MICROSECOND返回秒和毫秒值34000000MINUTE_MICROSECOND返回分钟和毫秒值3716000000MINUTE_SECOND返回分钟和秒值3851（2022-03-08 20:38:51）HOUR_MICROSECOND返回小时和毫秒值203944000000（2022-03-08 20:39:44）HOUR_SECOND返回小时和秒值204025（2022-03-08 20:40:25）HOUR_MINUTE返回小时和分钟值2040（2022-03-08 20:40:52）DAY_MICROSECOND返回天和毫秒值204126000000（2022-03-08 20:41:26）DAY_SECOND返回天和秒值204208（2022-03-08 20:42:08）DAY_MINUTE返回天和分钟值2043（2022-03-08 20:43:17）DAY_HOUR返回天和小时20（2022-03-08 20:43:54）YEAR_MONTH返回年和月202203（2022-03-08 20:44:23）5. 时钟和秒钟转换的函数-- 将time转化为秒并返回后果值，转化公式为：小时*3600*分钟*69+秒SELECT TIME_TO_SEC('2022-03-08 20:44:23')FROM DUAL;-- 转换后果：74663-- seconds转化为时分秒SELECT SEC_TO_TIME(74663) FROM DUAL; -- 转换后果：20:44:236. 计算日期和工夫的函数6.1 计算工夫距离函数性能备注DATE_ADD（datetime, INTERVAL expr type),ADDDATE(datetime, INTERVAL expr type)计算工夫距离（工夫减少）expr示意工夫距离，type值见下表DATE_SUB（datetime, INTERVAL expr type),SUBDATE(datetime, INTERVAL expr type)计算工夫距离（工夫缩小）expr示意工夫距离，type值见下表举例： SELECT DATE_ADD('2022-03-08 20:43:54', INTERVAL 2 DAY) AS A FROM DUAL;SELECT ADDDATE('2022-03-08 20:43:54', INTERVAL 2 DAY) AS B FROM DUAL;-- 返回雷同后果：2022-03-10 20:43:54SELECT DATE_SUB('2022-03-08 20:43:54', INTERVAL 2 DAY) C FROM DUAL;SELECT SUBDATE('2022-03-08 20:43:54', INTERVAL 2 DAY) D FROM DUAL;-- 返回雷同后果：2022-03-06 20:43:54-- 距离两和类型的工夫时能够用冒号和下划线，要用单引号SELECT DATE_ADD('2022-03-08 20:43:54', INTERVAL '2:2' DAY_HOUR ) AS A FROM DUAL;SELECT DATE_ADD('2022-03-08 20:43:54', INTERVAL '2_2' DAY_HOUR ) AS A FROM DUAL;-- 返回雷同后果：2022-03-10 22:43:54type值如下表： ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。[toc] 本文介绍如何在MGR集群前端部署MySQL Router以实现读写拆散、读负载平衡，以及故障主动转移。 MySQL Router是一个轻量级的中间件，它采纳多端口的计划实现读写拆散以及读负载平衡，而且同时反对mysql和mysql x协定。 倡议把MySQL Router部署在应用服务器上，每个应用服务器都部署一套，这样应用程序能够间接连贯本机IP，连贯的效率更高，而且后端数据库发生变化时，程序端也无需批改IP配置。 1. 部署MySQL RouterMySQL Router第一次启动时要先初始化： ##参数解释# 参数 --bootstrap 示意开始初始化# 参数 GreatSQL@172.16.16.10:3306 是MGR服务专用账号# --user=mysqlrouter 是运行mysqlrouter过程的零碎用户名#$ mysqlrouter --bootstrap GreatSQL@172.16.16.10:3306 --user=mysqlrouterPlease enter MySQL password for GreatSQL: <-- 输出明码# 而后mysqlrouter开始主动进行初始化# 它会主动读取MGR的元数据信息，主动生成配置文件Please enter MySQL password for GreatSQL:# Bootstrapping system MySQL Router instance...- Creating account(s) (only those that are needed, if any)- Using existing certificates from the '/var/lib/mysqlrouter' directory- Verifying account (using it to run SQL queries that would be run by Router)- Storing account in keyring- Adjusting permissions of generated files- Creating configuration /etc/mysqlrouter/mysqlrouter.conf# MySQL Router configured for the InnoDB Cluster 'MGR1'After this MySQL Router has been started with the generated configuration $ /etc/init.d/mysqlrouter restartor $ systemctl start mysqlrouteror $ mysqlrouter -c /etc/mysqlrouter/mysqlrouter.confthe cluster 'MGR1' can be reached by connecting to:## MySQL Classic protocol <-- MySQL协定的两个端口- Read/Write Connections: localhost:6446- Read/Only Connections: localhost:6447## MySQL X protocol <-- MySQL X协定的两个端口- Read/Write Connections: localhost:6448- Read/Only Connections: localhost:6449如果想自定义名字和目录，还能够在初始化时自行指定 --name 和 --directory 选项，这样能够实现在同一个服务器上部署多个Router实例，参考这篇文章：MySQL Router能够在同一个零碎环境下跑多实例吗 ...

KunlunDB在0.9版本之后，减少了运维监控平台(Xpanel), 通过集群治理（Cluster_mgr）的HTTP命令接口，能够实现对整个集群环境进行治理和监控。 以下是具体的命令接口介绍：获取cluster工作状态，POST接口： curl -d "{\"job_type\":\"get_status\",\"job_id\":\"uuid999\"}" http://127.0.0.1:57000因为创立集群，和复原一个新集群，会生成新的集群名称，通过get_status这个命令获取状态时，如果返回result为succeed，那info就是新集群的名称。 命令接管： {"result":"accept"} 胜利返回： {"result":"done","info":"something done"}正在工作： {"result":"ongoing","info":"something ongoing"}失败返回： {"result":"failed","info":"something error"}创立机器, 异步，须要查问，不阻塞其余操作。返回result=done/failed,info:create machine succeed(或者错误信息)。操作表记录：info:create machine succeed(或者错误信息)。门路为根门路，必须存在，total_mem单位是Mbyte。 {"ver":"0.1","job_id":"uuid999","job_type":"create_machine","hostaddr":"127.0.0.1","rack_id":"1","datadir":"/home/kunlun;/nvme2","logdir":"/home/kunlun;/nvme3","wal_log_dir":"/home/kunlun","comp_datadir":"/nvme2","total_mem":"1024","total_cpu_cores":"8","user_name":"zhangsan"}更新机器, 异步，须要查问，不阻塞其余操作。返回result=done/failed时, info:update machine succeed(或者错误信息)。操作表记录：info:update machine succeed(或者错误信息)。门路为根门路，必须存在，total_mem单位是Mbyte。{"ver":"0.1","job_id":"uuid999","job_type":"update_machine","hostaddr":"127.0.0.1","rack_id":"1","datadir":"/home/kunlun;/nvme2","logdir":"/home/kunlun;/nvme3","wal_log_dir":"/home/kunlun","comp_datadir":"/nvme2","total_mem":"4096","total_cpu_cores":"8","user_name":"zhangsan"}删除机器, 异步，须要查问，不阻塞其余操作。返回result=done/failed时, info:delete machine succeed(或者错误信息)。操作表记录：info:delete machine succeed(或者错误信息)。{"ver":"0.1","job_id":"uuid999","job_type":"delete_machine","hostaddr":"127.0.0.1","user_name":"zhangsan"}创立集群, 异步，须要查问。返回result=done时, info:集群名称。操作表记录：info:create cluster succeed(或者错误信息)。max_storage_size单位是G, innodb_size单位是G。innodb_size按要求先默认1G吧，范畴1-16G。user_name为网页端应用，保留到操作记录外面。machine为指定装置机器，以machine0开始。{"ver":"0.1","job_id":"uuid999","job_type":"create_cluster","ha_mode":"mgr","shards":"2","nodes":"1","comps":"1","max_storage_size":"20","max_connections":"6","cpu_cores":"8","innodb_size":"1","user_name":"zhangsan","machinelist":[{"hostaddr":"127.0.0.2"},{"hostaddr":"127.0.0.3"}]}删除集群, 异步，须要查问。返回result=done时, info:集群名称。操作表记录：info:delete cluster succeed(或者错误信息)。{"ver":"0.1","job_id":"uuid999","job_type":"delete_cluster","cluster_name":"cluster001","user_name":"zhangsan"}在现有集群上，新增分片，能够减少多个。返回result=done时, info:shard2;shard3。操作表记录：info:add shards succeed(或者错误信息)。分片名称排列,分隔符改为分号，因为之前创立机器的门路也是分号，对立了比拟好。{"ver":"0.1","job_id":"uuid999","job_type":"add_shards","cluster_name":"cluster001","shards":"2","user_name":"zhangsan","machinelist":[{"hostaddr":"127.0.0.2"},{"hostaddr":"127.0.0.3"}]}在现有集群上，删除分片，只能一个一个删返回result=done时, info:删除分片名。操作表记录：info:delete shard succeed(或者错误信息)。{"ver":"0.1","job_id":"uuid999","job_type":"delete_shard","cluster_name":"cluster001","shard_name":"shard1","user_name":"zhangsan"}在现有集群上，新增计算节点，能够减少多个。返回result=done时, info:comp2;comp3。操作表记录：info:add comps succeed(或者错误信息)。{"ver":"0.1","job_id":"uuid999","job_type":"add_comps","cluster_name":"cluster001","comps":"2","user_name":"zhangsan","machinelist":[{"hostaddr":"127.0.0.2"},{"hostaddr":"127.0.0.3"}]}在现有集群上，删除计算节点，只能一个一个删。返回result=done时, info:删除计算节点名。操作表记录：info:delete shard succeed(或者错误信息)。{"ver":"0.1","job_id":"uuid999","job_type":"delete_comp","cluster_name":"cluster001","comp_name":"comp1","user_name":"zhangsan"}为集群所有分片减少node, 异步，须要查问。带有shard_name字段，只减少该分片，否则所有分片都减少。返回result=done时, info:ip:port;ip:port,分隔符分号。操作表记录：info:add nodes succeed(或者错误信息)。该操作只能是MGR模式，先备份分片，创立出新NODE, 把备份复原到新NODE, 将新NODE退出分片。{"ver":"0.1","job_id":"uuid999","job_type":"add_nodes","cluster_name":"cluster001","shard_name":"shard1","nodes":"2","user_name":"zhangsan","machinelist":[{"hostaddr":"127.0.0.2"},{"hostaddr":"127.0.0.3"}]}某个分片删除node, 异步，须要查问。返回result=done时, info:ip:port,分隔符分号。操作表记录：info:delete node succeed(或者错误信息)。该操作只能是MGR模式，先备份分片，创立出新NODE, 把备份复原到新NODE, 将新NODE退出分片。{"ver":"0.1","job_id":"uuid999","job_type":"delete_node","cluster_name":"cluster001","shard_name":"shard1","ip":"127.0.0.1","port":"57338","user_name":"zhangsan"}备份集群, 异步，须要查问。返回result=done时, info:备份的工夫。操作表记录：info:backup cluster succeed(或者错误信息)。{"ver":"0.1","job_id":"uuid999","job_type":"backup_cluster","backup_cluster_name":"cluster001","user_name":"zhangsan"}复原集群, 异步，须要查问，该命令敞开，不给客户执行。返回result=done时, info:复原集群名称。操作表记录：info:restore cluster succeed(或者错误信息)。{"ver":"0.1","job_id":"uuid999","job_type":"restore_cluster","timestamp":"2021-12-20 19:22:20","backup_cluster_name":"cluster003","restore_cluster_name":"cluster004","user_name":"zhangsan"}复原出新集群, 异步，须要查问返回result=done时, info:新集群名称。操作表记录：info:restore new cluster succeed(或者错误信息)。{"ver":"0.1","job_id":"uuid999","job_type":"restore_new_cluster","timestamp":"2021-12-20 19:22:20","backup_cluster_name":"cluster003","user_name":"zhangsan","machinelist":[{"hostaddr":"127.0.0.2"},{"hostaddr":"127.0.0.3"}]}获取元数据MGR模式,同步返回。 ...

一、理解KunlunDB1.1 KunlunDB产品基本概念&架构KunlunDB是一个开源、高性能的分布式关系数据库，反对混合负载（HTAP）、PB级数据量治理并提供毫秒提早的新一代数据库解决方案。 1.1.1 集群组件架构图1.2 KunlunDB次要组件： 1.1.2 KunlunServer(计算节点）计算节点运行无状态计算&查问引擎，与Kunlun Storage进行交互执行SQL 工作，采纳异步通信模式，一个计算节点能够协调多个存储节点执行数据处理（增删改查）工作。计算节点从元数据集群获取集群元数据并在本地长久化。Kunlun Server的SQL层兼容PostgreSQL和MySQL协定(开发中……)，各个计算节点独立解决SQL计算。Kunlun Server反对规范SQL连贯。 1.1.3 KunlunStorage(存储节点）采纳Shared-nothing架构，各存储节点运行肯定数目的存储引擎实例，用来长久化利用（用户）数据。存储引擎执行计算节点发动SQL语句（在XA事务中的分支）。能够应用MGR单主模式或Binlog强同步模式做集群高可用。 1.1.4 Meta Cluster(元数据集群）用来存储着若干个昆仑分布式数据库集群的元数据，及分布式事务两阶段提交的commit log。元数据集群采纳一主两从的部署模式。 集群治理（Cluster_mgr）作为守护过程运行，‎负责监控和保护每一个存储集群及其节点的replication状态、集群计算节点与存储节点之间的元数据和状态同步、解决分布式事务节点故障解决等。集群管理器提供API供第三方管理软件调用。 节点治理（Node_mgr）在集群的每一台机器运行，检测该机器上所有计算节点，以及存储节点的状态，对所有节点实例进行保活治理。并通过HTTP接口接管集群治理的命令，进行节点实例装置，删除等性能。 1.1.5 Xpanel(运维监控平台）KunlunDB的运维治理模块，能够对整个集群环境进行治理和监控。Xpanel能够监控集群各个节点的操作系统及各要害组件的重要信息，包含操作系统资源，操作系统谬误日志，计算&存储引擎的要害日志错误信息等。 KunlunDMP是KunlunDB备份复原工具，DataPump是数据加载工具，反对 MySQL,PostgreSQL逻辑备份和数据的加载。 二、疾速装置一键装置流程2.1 装置环境&配置需要2.1.1 硬件配置开发及测试环境（最低要求） 2.1.2 Linux 操作系统版本要求 2.2 布局集群拓扑以一个三台服务器的配置为例： 做为开发测试环境，每台服务器的硬件最低配置为：4核CPU , 16G内存。（如果仅作功能测试，能够下载KunlunDB docker映像装置，一般笔记本就能够部署KunlunDB docker装置指南） 表格1-1 2.3 装置环境筹备装置之前，要确保服务器操作系统环境满足以下要求： 所有节点所在机器须为Linux,装置了bash,sed,gzip,python2, python2-dev等工具或者库。python2可执行程序设置为python2。 所有集群节点所在机器曾经正确设置好用户，节点将以该用户启动，该用户可能运行sudo而不须要明码。 配置防火墙，开发所有install.json 配置文件波及的端口。 对于装置存储节点的机器，须要事后装置以下库(此处为ubuntu 20.04): libncurses5 libaio-dev。 对于装置计算节点的机器，须要事后装置以下库(此处为ubuntu 20.04): libncurses5 libicu66python-setuptools gcc 在centos上装置，参考附录2。 对于装置动作，须要事后将二进制公布包(kunlun-cluster-manager-0.9.1.tgz,kunlun-server-0.9.1.tgz,kunlun-storage-0.9.1.tgz)放入当前目录. 此外，工具运行机器和节点所在机器间网络不能太慢，因为须要将公布包传递到这些机器上。 对于装置的所有机器，须要设置装置用户及root用户的主动登录验证 设置结束后ssh username@host.com ubuntu能够参考：ubuntu登录主动验证。 centos能够参考:centos登录主动验证。 如果在该步骤提醒sudo：须要明码，能够参考：sudonopasswd 2.4 下载安装包抉择一台服务器： 通过git clone形式在gitee上拉kunlun-scripts包： git clone https://github.com/zettadb/cloudnative.gitcd进入kunlunnative/cluster下: ...

近日，DB-Engines 颁布了 2022 年 3 月份的数据库榜单。 本次榜单第 1-10 位里，前五位排名并未变动，且前三位仍旧是霸榜多年的 Oracle、MySQL 和 Microsoft SQL Server 。 榜单前十位里，同样未有变动的还有别离排在第四、第五位的 PostgreSQL 、MongoDB，以及第八位的 Elasticsearch；发生变化的别离为排名第六的 Redis、排名第七位的 IBM Db2 —— 相比去年，这两者的排名互相换了地位，但相比上个月排名并未变动；同样，排名第九位的 Microsoft Access 和 排名第十位的 SQLite 两者相比去年的排名也产生了互相换位。 评分方面，霸榜前三位的 Oracle、MySQL 和 Microsoft SQL Server 均略微有变动：第一位的 Oracle 库模型本次以 1251.32 的评分再次蝉联 No1，不过相比上个月评分略微降落了 5.51，同比去年也降落了 70.42 ；第二位的 MySQL 本月评分为 1198.23，相比上个月评分降落了 16.45，同比去年降落了 56.59；第三位的 Microsoft SQL Server 本次评分为 933.78，相比上个月降落了 15.27，同比去年降落了 81.52。反之，排名第四位的 PostgreSQL 与 第五位的 MongoDB 评分却有所上涨。 榜单第 10- 20 位外面，备受关注的 Snowflake 排名从上月的第 15 名回升到了第 14 名；评分方面比上个月减少了 3.05，同比去年则减少了 63.04。 ...

本文首发：《appsmith 怎么用？评估如何 - 卡拉云》 AppSmith 是印度一家守业公司开发的低代码开发工具，它的原型是另一家名叫 Retool 的美国的守业公司。AppSmith 从 2019 年开始开发，到当初曾经发行了 1.x 版本，也就是处于正式发行状态。那么 Appsmith 到底怎么样？它的评估如何？比照卡拉云它有哪些优缺点呢？ AppSmith 怎么用？AppSmith 自身是开源软件，然而它提供一个云端版本。如果你须要公有部署的话，那么须要比拟相熟 k8s 或 docker，能力比拟自在地部署胜利。但对于很多同学来说，上手最好的方法可能是间接应用云端版本。 在 AppSmith 注册帐号后，就能够创立利用了。AppSmith 中的利用概念与卡拉云中一样，每个利用是一个罕用操作汇合。比如说，对于一个员工管理系统，你能够在卡拉云或者 AppSmith 中创立一个“员工治理”利用，这个利用调用对应的查问，就能够对对应的员工数据进行增删改查。 与卡拉云架构相似，AppSmith 也采纳的是 proxy 服务器执行的架构。即你的查问会通过一次 AppSmith 的服务器，再到你的数据库或者服务器，实现跳转查问。如图所示 组件操作上，AppSmith 与卡拉云十分相似，都是采纳拖拽创立的形式。你能够从组件库中拖入一个组件，这样一个组件就创立好了。 组件连贯逻辑上，AppSmith 也采纳的是用简略的 JavaScript 来连贯组件间的逻辑。比方在文本框中输出 {{Input1.value}} 那么文本框中就会援用 Input1 里用户输出的值。 其它的数据源连贯、查问设置等，与卡拉云相差不大，这里就不赘述了。在一些特地的组件设计上，比方日期选择器，咱们采纳了更适宜国内用户应用习惯的设计。其它特地的组件包含文件上传(七牛云，阿里云，腾讯云等)，图表组件(应用Echart)，地图(百度地图/高德地图)等等 AppSmith 评估如何Appsmith 自身是比拟优良的开源软件，因为开创团队来自印度，因而在印度的风行程度较高。同时因为其次要语言为英文，因而在英文国家也较风行。 如果细读 Appsmith 的代码的话，有个小问题是代码自身较为凌乱。首先代码用的依然是 React 16.8 之前的 class 写法，因而无奈与更新的 react hook 兼容，这就为持续开发和奉献代码发明了不小的麻烦。 同时 Appsmith 的全局状态治理用的是 Redux Saga，这个状态治理库较为小众和简单，也为 Appsmith 的倒退代来了一些局限。 当然对于少数情境下应用，代码的整洁度自身不是大问题，但这也从侧面可能反映出凌乱的代码可能藏起来较多的 bug 和问题。举个例子，不少用户发现大量的 bug ...

前言一、事务是什么？事务（Transaction），个别是指要做的或所做的事件。在计算机术语中是指拜访并可能更新数据库中各种数据项的一个程序执行单元(unit)。事务通常由高级数据库操纵语言或编程语言（如SQL，C++或Java）书写的用户程序的执行所引起，并用形如begin transaction和end transaction语句（或函数调用）来界定。事务由事务开始(begin transaction)和事务完结(end transaction)之间执行的整体操作组成。 二、事务四大个性1.原子性事务是数据库的逻辑工作单位，事务中蕴含的各操作要么都做，要么都不做 2.一致性事 务执行的后果必须是使数据库从一个一致性状态变到另一个一致性状态。因而当数据库只蕴含胜利事务提交的后果时，就说数据库处于一致性状态。如果数据库系统 运行中产生故障，有些事务尚未实现就被迫中断，这些未实现事务对数据库所做的批改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不统一的状态。 3.隔离性一个事务的执行不能其它事务烦扰。即一个事务外部的操作及应用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能相互烦扰。 4.持久性也称永久性，指一个事务一旦提交，它对数据库中的数据的扭转就应该是永久性的。接下来的其它操作或故障不应该对其执行后果有任何影响。 三、环境筹备MySQL：5.7winows 10Navicate for Mysql 11.1 脚本和数据库筹备筹备一张test表和简略插入几条数据,主键id列和年龄age列 DROP TABLE IF EXISTS `test`;。CREATE TABLE `test` ( `id` int(11) NOT NULL AUTO_INCREMENT, `age` int(11) DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;-- ------------------------------ Records of test-- ----------------------------INSERT INTO `test` VALUES ('1', '2');INSERT INTO `test` VALUES ('2', '10');INSERT INTO `test` VALUES ('3', '4');INSERT INTO `test` VALUES ('4', '5');INSERT INTO `test` VALUES ('5', '6');查问主动提交状态show VARIABLES like 'autocommit'勾销主动提交set autocommit = off;查问全局事务select @@global.tx_isolation;四、事务的几种隔离级别和验证1.读未提交(READ UNCOMITTED)2.读提交(READ COMMITTED)3.可反复读(REPEATABLE READ)4.串行化(SERIALIZABLE) ...

前言mysql按锁的范畴分三种 表级锁：开销小，加锁快；不会呈现死锁，锁定粒度大，产生锁抵触概率最高，并发度最低。行级锁：开销大，加锁慢，会呈现死锁，锁定粒度小，产生锁抵触的概率最低，并发度最高。页面锁：开销和加锁工夫界于表锁和行锁之间，会呈现死锁，锁定粒度界于表锁和行锁之间，并发度个别。从上述三种锁的特点来看，很难说哪种锁更好，只能就具体利用的特点来说哪种锁更适合。比方，MyISAM和MEMORY引擎采纳的是表级锁；InnoDB引擎既反对行级锁，也反对表级锁，但默认状况下采纳行级锁。 InnoDB的加锁模式InnoDB实现了以下两种类型的行锁。 共享锁（S）：容许一个事务读一行，阻止其余事务取得雷同数据的排他锁，也叫读锁。排他锁（X）：容许取得排他锁的事务更新数据，阻止其余事务获得雷同数据集的共享锁与排他锁，也叫写锁。同时mysql还反对与行共享锁和行排他锁相似的表共享锁和表排他锁因为锁的粒度不同，表锁的范畴笼罩了行锁的范畴，所以表锁和行锁会产生抵触，例如事务A对表中某一行数据加了行锁，而后事务B想加表锁，失常来说是应该要抵触的。要判断是否抵触就得遍历每一行数据了，这样的效率不高，因而咱们就有了意向表锁。 意向锁的次要目标是为了使得 行锁 和 表锁 共存，事务在申请行锁前，必须先申请表的意向锁，胜利后再申请行锁。 意向锁分为动向共享锁和动向排他锁。 动向共享锁（IS）：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁之前必须先去的该表的动向共享锁动向排他锁（IX）：事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先获得该表的动向排他锁。上述锁模式的兼容状况如下表所示 右侧代表申请锁模式，下侧代表以后锁模式XIXSISX抵触抵触抵触抵触IX抵触兼容抵触兼容S抵触抵触兼容兼容IS抵触兼容兼容兼容如果一个事务申请的锁模式与以后的锁模式兼容，InnoDB就将申请的锁授予该事务，反之，如果两者不兼容，该事务就要期待锁开释。 意向锁是表级锁，然而却示意事务正在读或写某一行记录，而不是整个表，所以意向锁之间不会产生抵触，真正的抵触在加行锁时查看。 加锁办法意向锁是InnoDB主动加的，不须要用户干涉。 隐式上锁对于UPDATE，DELETE和INSERT语句，InnoDB会主动给设计数据集加排他锁；对于一般SELETE语句，INNODB不会加任何锁；InnoDB会依据隔离级别在须要的时候主动加锁； 显式上锁select * from tableName lock in share mode;//读锁select * from tableName for update;//写锁解锁提交事务（commit）回滚事务（rollback）kill阻塞过程上读锁实例 事务A事务Bbegin; select * from teacher where id = 2 lock in share mode;// 上读锁 select * from teacher where id = 2;// 能够失常读取update teacher set name = 3 where id =2;// 能够更新操作update teacher set name = 5 where id =2;// 被阻塞commit; update teacher set name = 5 where id =2;// 更新操作胜利上写锁实例 ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 以往 MySQL 想要限度单个连贯的内存，只能小心翼翼的设置各种 SESSION 变量，避免执行某些 SQL 导致单个连贯的内存溢出！ 能不能间接在 MySQL 服务端蕴含这样一个性能，简化数据库的运维呢？ MySQL 最新版本 8.0.28 在前几天公布，其中有一项新性能就是在数据库侧来限度单个连贯内存，着实有点小兴奋。 MySQL 8.0.28 与此性能无关的几个新参数如下：connection_memory_limit：外围参数！用来限度单用户连贯的内存上限值，默认为 BIGINT UNSIGNED 的最大值：18446744073709551615 字节，最小为2MB。global_connection_memory_tracking：设置是否开启对连贯内存性能的追踪，并且把连贯内存数据存入状态变量 Global_connection_memory 。为了性能思考，默认敞开。connection_memory_chunk_size: 在参数 global_connection_memory_tracking 开启的场景下，设置状态变量 Global_connection_memory 的更新频率。接下来咱们体验下这个新个性。管理员端设置内存限度参数下限：为了尽快看到成果，设置为最小值。 localhost:(none)>set global connection_memory_limit=2097152;Query OK, 0 rows affected (0.00 sec)创立一个新用户 tt1 ，并赋予基于库 ytt 的只读权限。 localhost:(none)>create user tt1 identified by 'tt';Query OK, 0 rows affected (0.03 sec)localhost:(none)>grant select on ytt.* to tt1;Query OK, 0 rows affected (0.02 sec)创立一张表，插入一行记录： 这里应用 longtext 数据类型能让查问后果更快内存溢出。 ...

传统单线程复制阐明家喻户晓，MySQL在5.6版本之前，主从复制的从节点上有两个线程，别离是I/O线程和SQL线程。I/O线程负责接管二进制日志的Event写入Relay Log。SQL线程读取Relay Log并在数据库中进行回放。以上形式偶然会造成提早，那么可能造成主从节点提早的状况有哪些?1.主库执行大事务（如：大表构造变更操作）。2.主库大批量变更（如：大量插入、更新、删除操作）。3.ROW同步模式下，主库大表无主键频繁更新。4.数据库参数配置不合理，从节点性能存在瓶颈（如：从节点事务日志设置过小，导致频繁刷盘）。5.网络环境不稳固，从节点IO线程读取binlog存在提早、重连状况。6.主从硬件配置差别，从节点的硬件资源应用达到下限。(比方：主节点SSD盘，从节点SAS盘)能够对以上提早起因做个大抵分类。1.硬件方面问题（包含磁盘IO、网络IO等）2.配置方面问题。3.数据库设计问题。4.主库大批量变更，从节点SQL单线程解决不够及时。总结剖析以上起因能够看出要想升高主从提早，除了改善硬件方面条件之外，另外就是须要DBA关注数据库设计和配置问题，最初就是须要进步从节点的并发解决能力，由单线程回放改为多线程并行回放是一个比拟好的办法，关键点在于如何在多线程复原的前提下解决数据抵触和故障复原地位点的确认问题。MySQL5.6基于库级别的并行复制在实例中有多个数据库的状况下，能够开启多个线程，每个线程对应一个数据库。该模式下从节点会启动多个线程。线程分为两类 Coordinator 和 WorkThread。线程分工执行逻辑Coordinator线程负责判断事务是否能够并行执行，如果能够并行就把事务分发给WorkThread线程执行，如果判断不能执行，如DDL，跨库操作等，就期待所有的worker线程执行实现之后，再由Coordinator执行。 要害配置信息slave-parallel-type=DATABASE计划有余点这种并行复制的模式,只有在实例中有多个DB且DB的事务都绝对忙碌的状况下才会有较高的并行度，然而日常保护中其实单个实例的的事务处理绝对集中在一个DB上。通过观察提早能够发现基本上都是基于热点表呈现提早的状况占大多数。如果可能提供基于表的并行度是一个很好办法。MySQL5.7基于组提交的并行复制组提交阐明简略来说就是在双1的设置下，事务提交后即刷盘的操作改为多个事务合并成一组事务再进行对立刷盘，这样解决就升高了磁盘IO的压力。详细资料参考老叶茶馆对于组提交的阐明推文https://mp.weixin.qq.com/s/rcPkrutiLc93aTblEZ7sFg一组事务同时提交也就意味着组内事务不存在抵触，故组内的事务在从节点上就能够并发执行，问题在于如何辨别事务是否在同一组中的，于是在binlog中呈现了两个新的参数信息last_committed 和 sequence_number 如何判断事务在一个组内呢?解析binlog能够发现外面多了last_committed和sequence_number两个参数信息，其中last_committed存在反复的状况。sequence_number # 这个值指的是事务提交的序号，枯燥递增。last_committed # 这个值有两层含意，1.雷同值代表这些事务是在同一个组内，2.该值同时又是代表上一组事务的最大编号。[root@mgr2 GreatSQL]# mysqlbinlog mysql-bin.0000002 | grep last_committedGTID last_committed=0 sequence_number=1GTID last_committed=0 sequence_number=2GTID last_committed=2 sequence_number=3GTID last_committed=2 sequence_number=4GTID last_committed=2 sequence_number=5GTID last_committed=2 sequence_number=6GTID last_committed=6 sequence_number=7GTID last_committed=6 sequence_number=8数据库配置slave-parallel-type=LOGICAL_CLOCK计划有余点基于LOGICAL_CLOCK的同步有个有余点，就是当主节点的事务忙碌度较低的时候，导致时间段内组提交fsync刷盘的事务量较少，于是导致从库回放的并行度并不高，甚至可能一组外面只有一个事务，这样从节点的多线程就根本用不到，能够通过设置上面两个参数，让主节点提早提交。binlog_group_commit_sync_delay # 期待提早提交的工夫，binlog提交后期待一段时间再 fsync。让每个 group 的事务更多，人为进步并行度。binlog_group_commit_sync_no_delay_count # 待提交的最大事务数，如果等待时间没到，而事务数达到了，就立刻 fsync。达到冀望的并行度后立刻提交，尽量放大期待提早。MySQL8.0基于writeset的并行复制writeset 基于事务后果抵触进行判断事务是否能够进行并行回放的办法，他由binlog-transaction-dependency-tracking参数进行管制，默认采纳WRITESET办法。要害参数查看Command-Line Format--binlog-transaction-dependency-tracking=valueSystem Variablebinlog_transaction_dependency_trackingScopeGlobalDynamicYesSET_VAR Hint AppliesNoTypeEnumerationDefault ValueCOMMIT_ORDERValid ValuesCOMMIT_ORDERWRITESET WRITESET_SESSION参数配置项阐明COMMIT_ORDER # 应用 5.7 Group commit 的形式决定事务依赖。WRITESET # 应用写汇合的形式决定事务依赖。WRITESET_SESSION # 应用写汇合，然而同一个session中的事务不会有雷同的last_committed。writeset 是一个HASH类型的数组，外面记录着事务的更新信息，通过transaction_write_set_extraction判断以后事务更新的记录与历史事务更新的记录是否存在抵触，判断过后再采取对应解决办法。writeset贮存的最大存储值由binlog-transaction-dependency-history-size管制。 须要留神的是，当设置成WRITESET或WRITESET_SESSION的时候，事务提交是无序状态的，能够通过设置 slave_preserve_commit_order=1 强制按程序提交。 binlog_transaction_dependency_history_size设置保留在内存中的行哈希数的下限，用于缓存之前事务批改的行信息。一旦达到这个哈希数，就会革除历史记录。Command-Line Format--binlog-transaction-dependency-history-size=#System Variablebinlog_transaction_dependency_history_sizeScopeGlobalDynamicYesSET_VAR Hint AppliesNoTypeIntegerDefault Value25000Minimum Value1Minimum Value1000000transaction_write_set_extraction该模式反对三种算法，默认采纳XXHASH64，当从节点配置writeset复制的时候，该配置不能配置为OFF。该参数曾经在MySQL 8.0.26中被弃用，后续将会进行删除。Command-Line Format--transaction-write-set-extraction[=value]Deprecated8.0.26System Variablebinlog_transaction_dependency_history_sizeScopeGlobal, SessionDynamicYesSET_VAR Hint AppliesNoTypeEnumerationDefault ValueXXHASH64Valid ValuesOFFMURMUR32XXHASH64数据库配置slave_parallel_type = LOGICAL_CLOCKslave_parallel_workers = 8binlog_transaction_dependency_tracking = WRITESETslave_preserve_commit_order = 1援用材料：阿里内核月报：http://mysql.taobao.org/monthly/2018/06/04/官网文档：https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.htmlEnjoy GreatSQL :) ...

起源：原创投稿 作者：花家舍 简介：数据库技术爱好者。 GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。简略学习一下数据文件解析这是尝试应用Golang语言简略解析MySQL 8.0的数据文件（*.ibd）过程的一个简略介绍，解析是反序列化的一个过程，或者叫解码的过程。 1.为什么要解析尽管有很多开源的代码曾经实现了这个解码过程，例如应用C实现的undrop-for-innodb[1]，反对到MySQL 5.7版本，后续未作更新。 姜老师的py_innodb_page_info.py也能够对数据文件进行剖析（剖析页的类型），对MySQL 8.0版本的兼容如同还没来得及做。 还有Ali应用Java实现了数据文件的解析[2]，并且肯定水平兼容MySQL 8.0版本。然而本人通过解析数据文件过程对数据文件编码/解码、复原已删除数据等进行深刻学习。 解析过程枯燥乏味，有种按图索骥的感觉，即通过文档或者源码形容的页构造，建设对应构造体来解析，难度可能并不简单，通过对存储建设更为平面全面的意识，补齐MySQL常识拼图很有意义。 2.应用Golang解析数据文件抉择应用Golang来实现这个过程，则是因为其比C++简略的多，易上手，不必过多关注垃圾回收问题，代码简洁，有丰盛的软件包以供援用，不需费劲本人实现。 当然还有更多有吸引力的个性，例如并发性（goroutine）与通道（channel），对gRPC与Protocol Buffers一流的反对等，这些优良的个性在本文解析MySQL数据文件时并没有用到，则无需赘言。 3.文件3.1 linux文件文件是对I/O设施的一个抽象概念，比方咱们不须要理解磁盘技术就能够解决磁盘文件内容，就是通过操作文件这个形象来进行的。 在CSAPP（ComputerSystem: A programer perspective）中文版第三版中，对文件有过精辟的定义：文件就是字节序列，仅此而已。那么对MySQL数据文件的解析，可视为对字节序列的解析，解析的过程由此能够简略地视为对编码规定的逆向过程，即解码。 3.2 MySQL 8.0数据文件MySQL在8.0版本中对数据字典做了从新调整，元数据对立存储到InnoDB数据字典表。不再在Server层中冗余表构造信息（不再存储在ibdata中），也不再在frm文件中存储。 不仅将元数据信息存储在数据字典表中，同时也冗余了一份在SDI（Serialized Dictionary Information）中，而对于InnoDB，SDI数据则间接存储在ibd数据文件中，文件中有SDI类型页来进行存储。因为元数据信息均存储在InnoDB引擎表中，反对crash-safe，联合一套DDL_LOG机制，以此实现了DDL原子性。 在文件的结尾（并不是十分靠前的地位，大略是第四个数据页，page number=3，这在之前的版本中是所谓的根页：root page）冗余表构造信息，十分相似于Avro的编码格局，即在蕴含几百万记录的大文件结尾蕴含模式（形容数据的组成，包含元素组成，数据类型等）信息，后续每个记录则不再冗余这部分信息，以达到节俭存储、传输老本目标。 而在解析数据时，模式是必要的，须要首先获取表构造信息，以便于后续数据解码过程。所以在这次解析数据文件时，首先须要获取数据文件中SDI页中的表构造（模式）。 为简化解析过程，默认数据库是设置了UTF-8字符集，即数据文件是以UTF-8进行编码的。并且数据库启用了innodb_file_per_table参数，表被存储在他们本人的表空间里（*.ibd）。 4.解析文件解析并不是非常复杂的过程。就程序角度而言首先是关上文件，而后是解析文件，最初是敞开文件。 然而过程很有可能产生其余未知的问题，例如不同的编码格局，简单的数据类型等，只是在本文解析中抉择了回避而已。 Golang提供了os.OpenFile()函数来关上文件（倡议以只读模式关上），并提供了file.Close()函数来敞开文件，留下了解析过程来本人实现。 4.1 获取表构造像JSON或者XML这种自我形容的数据，其自我形容局部比拟冗余，在大文件中，冗余过多信息很不明智。而在MySQL的数据文件中，数据增长是个显著问题，自我形容的局部须要精简，不能每写入一条数据，就要追随写入表名、列名。 所以MySQL仅在文件结尾保留了表构造信息（在更早的版本，表构造信息则是存储在frm文件中，并在数据字典中冗余）。 这种形式的编码能够很节俭存储空间，但解析关上数据文件，输入的是字节序列，显然是人类不可读的，须要找到模式（表构造信息）来解读成人类可读，才达到解析的目标。 如果能够通过数据库，很容易取得表构造信息，但如果仅有一个数据文件，获取表后果信息只能从SDI中解析获取，过程比拟麻烦。 侥幸的是，MySQL官网提供了专有工具：ibd2sdi。通过ibd2sdi默认获取的是所有的列和索引信息，是以JSON格局输入的。 4.2 构造体和切片MySQL的数据文件中是以页（默认大小为16k）为单位存储，索引能够利用B-tree的查找个性疾速的定位到页，在页内的数据则是通过十分相似于二分查找的形式来定位。 在解析数据文件时，也是以页为单位，InnoDB中大略有31种类型页，在源码storage/innobase/include/fil0fil.h中能够看到相干定义。 真正存储用户数据的是FIL_PAGE_INDEX（数字编码是17855，解析到page_type=17855，代表这是一个索引页）类型的页，这不代表其余类型的页没有用途，在形容文件中页的应用的状况（FIL_PAGE_TYPE_FSP_HDR），空页调配（FIL_PAGE_TYPE_ALLOCATED），insert buffer（FIL_PAGE_IBUF_FREE_LIST），压缩页（FIL_PAGE_COMPRESSED）等，须要各种类型页进行存储不同的信息。 而不同的页，在解析过程中，则应用Golang的构造体（struct）来进行形象示意，这相似于Java的类，是对具体事务的形象，也十分相似于C语言的构造体。解析不同的数据页，则应用相应的构造体，为了简化解析过程（毕竟是学习过程），只对大略六种页进行了解析。 不光是页在解析过程中应用构造体，在页中的一些局部也是用了构造体来进行形象，例如每个数据页的结尾会有38个字节的File Header[3]，在解析过程中，也是通过构造体进行解析的。 第3节中说文件是字节序列，InnoDB数据文件通常很大，整体关上后则是一个超长的字节数组，并不不便进行整体解析，或者数据文件远超内存大小，全副载入内存不太可能，须要对其逐渐读取，或者说叫做进行切割，例如依照页的默认大小进行切割，行将数据文件切割成若干个16k大小的片段（数据文件必然是页大小的整数倍）。 在Golang中，这种数组片段的数据结构叫做切片，即slice。这让人想到早餐面包，一整块面包并不不便抹上果酱，那么能够切成面包片，后续就能够很好的解决了。在解析局部的代码中，会常常的应用构造体和切片这两种数据结构进行解析字节序列。 4.3 页4.3.1 页构造在数据文件中，页是以16K大小，即16384 Byte（这是一个默认大小，由innodb_page_size参数管制）的字节序列存储的，一个数据文件蕴含很多个数据页。在内存中，则以B-tree模式来组织，B-tree的每一个节点，就是一个页，非叶子节点通过指针指向下一层节点（页）。 当事务在记录上加逻辑锁时，在B-tree上则是增加的栓锁（latch）来避免页（在页决裂和膨胀时，还可能蕴含页的父节点）被其余线程批改。规范数据页（INDEX page）蕴含七个局部，组成构造如下列表格所示[4]。 NameSizeRemarksFile Header38页的一些通用信息Page Header56不同数据页专有的一些信息Infimum/Supremum26两个虚构的行记录，即最大值最小值User Records 理论存储的行记录内容Free Space 页中尚未应用的空间Page Directory 页中的某些记录的绝对地位（slot）File Trailer8校验信息，4byte的checksum，4byte的Low32lsn其中，38个字节长度的File Header在简直所有类型的页中都存在。其构造蕴含八个局部，组成构造如下： NameSizeRemarksFIL_PAGE_SPACE4ID of the space the pageFIL_PAGE_OFFSET4ordinal page number from start of spaceFIL_PAGE_PREV4offset of previous page in key orderFIL_PAGE_NEXT4offset of next page in key orderFIL_PAGE_LSN8log serial number of page's latest log recordFIL_PAGE_TYPE2current defined page typeFIL_PAGE_FILE_FLUSH_LSN8log serial numberFIL_PAGE_ARCH_LOG_NO4archived log file number而56个字节长度的Page Header蕴含14个局部，组成构造如下： ...

1、概述评论性能曾经成为APP和网站开发中的必备性能。本文次要介绍评论性能的数据库设计。 评论性能最次要的是发表评论和回复评论（删除性能在后盾）。评论性能的拓展性能体现有以下几方面：（1）单篇文章的评论数量和信息展现；（2）从工夫维度，依照工夫顺叙的形式展现动静的用户评论信息；（3）不同栏目，不同模块，不同工夫维度的评论排行展现；（4）精髓评论的独自举荐和聚合展现；（5）评论后间接分享到绑定的第三方平台；（6）点赞数、回复数等维度的排行等。 评论的后盾治理：（1）删除；（2）举荐；（3）精髓；（4）屏蔽，敏感关键字的库的欠缺、主动屏蔽或者替换性能。 本篇文章次要剖析几种客户端评论数据表的设计。 2、数据表设计2.1 一问一答模式（1）需要剖析大部分APP采纳简略的评论设计即可，即是一问一答模式，比方微信朋友圈的评论性能的设计。如： 徐志胜：怎么回事？何广智@徐志胜：你就是一条舔人的海狗！这种设计简略、间接，也满足了用户评论、回复的根本要求，对于没有大量用户评论的APP需要足够。 （2）数据库设计这种场景下个别评论较少，评论不沉闷，能够不辨别评论和回复，对立看成评论。区别是，有些评论是间接评论主题，而有些是@其余用户，应用一张表就能够达到成果，评论表设计如下： 表字段字段阐明id主键topic_id主题idtopic_type主题类型content评论内容from_uid评论用户idto_uid评论指标用户idtopic_type：为了能复用评论模块，咱们引入这个字段来辨别主题的类别。 from_uid：示意评论人的id，通过该id咱们能够检索到评论人的相干信息。 to_uid 是评论指标人的id，如果没有指标人，则该字段为空 出于性能的思考，往往咱们会冗余评论人的相干信息到评论表中，比方评论人的昵称、头像，指标用户也是如此。 这样一来咱们就只用查问单表就能够达到显示的成果 有时，指标用户有多个，那么能够将to_uid字段批改为to_uids，保留时用分隔符来宰割用户id，而指标用户的信息再去查问缓存或者数据库。也能够简略的将多个指标用户的信息一起存成json格局，能够应酬简略的展示需要。 2.2 评论为主模式(1)需要剖析如果以评论为主的显示模式，相似于上面的CSDN的评论显示模式：这里将评论分为评论和回复，所有评论均挂在评论上面，相似于树状构造。 （2）数据库设计在以评论为主的树形显示状况下，数据库的设计非常灵便，能够应用单表，增加一个parent_id字段来指向父评论，须要嵌套查问。 同时也能够将评论拆分为评论表和回复表，评论挂在各种主题上面，而回复挂在评论上面。 评论表设计如下： 表字段字段阐明id主键topic_id主题idtopic_type主题类型content评论内容from_uid评论用户id回复表设计： 表字段字段阐明id主键comment_id评论idreply_id回复指标idreply_type回复类型from_uid回复用户idto_uid指标用户id因为咱们拆分了评论和回复，那么评论表就不再须要指标用户字段了，因为评论均是用户对主题的评论，评论表的设计更佳简洁了。 回复表增加了一个comment_id字段来示意该回复挂在的根评论id，这样设计也是出于性能方面的思考，咱们能够间接通过评论id一次性的找出该评论下的所有回复，而后通过程序来编排回复的显示构造。 通过适当的冗余来进步性能也是罕用的优化伎俩之一。 reply_type：示意回复的类型，因为回复能够是针对评论的回复(comment)，也能够是针对回复的回复(reply)， 通过这个字段来辨别两种情景。 reply_id：示意回复指标的id，如果reply_type是comment的话，那么reply_id＝commit_id，如果reply_type是reply的话，这示意这条回复的父回复。 2.3 网易新闻盖楼模式（1）需要剖析这种场景中评论和回复是同级显示的，回复不在显示构造上不必挂在一个评论上面。 双表的设计在这里就不太适合了，因为波及到评论和回复的混排，应用双表则会导致查问的逻辑过于简单。 所以倡议还是采纳单表的设计，不辨别评论和回复会简化应用层的逻辑。 咱们对立都看成评论，而有些评论是能够援用其余评论的。 （2）数据库设计自己举荐采纳闭包表的设计，例如： comment表设计： 表字段字段阐明id主键topic_id主题idtopic_type主题类型content评论内容from_uid评论用户idparent_child表： 表字段字段阐明parent_id父idchild_id子idcomment表保留所有评论内容，而parent_children表则记录评论表中各个评论的父子关系。 查问时往往会依照工夫排序，咱们能够间接按id或者创立工夫降序排列查问comment表即可。 如果用户想查问一条评论的残缺援用，则能够通过parent_children来找到对应的门路。 闭包表在查问时十分不便，然而插入的性能稍差，因为除了插入评论表以外，还须要把该条评论所有的父子关系插入到父子关系表中。 插入性能会随着评论层级的加深而线性降落。 3、数据库优化如果你的零碎每天都会领有成千上万条评论，那么单表的设计必定是不行，优化的形式有以下几种思路。 （1）分库分表。 分库分表是最为罕用也最无效的优化形式，倡议依照主题来分库分表。 这样同一个主题上面的评论就会落到同一张表里，防止了跨表查问。 （2）适当的数据冗余。 如果你须要显示评论人的相干信息，那么在插入评论时就把这些信息写入评论表中，防止屡次查问。 实际上，如果是纪录数据，都能够冗余对应的数据信息，因为它们的数据的实时行和一致性要求并不高。 （3）附加幂。数据只容许单项操作。 因为从幂性的要求来说，每个赞全都是一条记录。 评论的赞数如果都从点赞表中统计得出，那么性能开销会非常微小，而且点赞如此轻量级的一个操作肯定会加剧点赞表的竞争操作。 所以倡议间接在评论表中增加一个like_count的计数器，该字段只增不减。客户端，能够设置勾销成果。 （4）热门评论加缓存。 相似于网易新闻的热门评论，读取频度十分高，能够专门开接口做缓存。

明天早上，业务库磁盘告警了，之前咱们有聊过如何对web服务器磁盘告警的解决，明天咱们来讲一下如何解决DB实例磁盘告警，最常见的解决办法有如下几种： 磁盘扩容，当初大部分公司的业务都应用了各种云的Paas产品，间接界面扩容即可。 对数据进行归档，常见的是对一些日志表的解决，比方只保留最近三个月或半年或一年的数据，其余过往数据都归档到一个冷备库中。 清理数据，比方业务上的一些bug导致的短时间内业务数据量增长过快的状况。 迁徙数据，比方把告警的DB实例上一些库迁往另一个DB实例。 不论用哪种形式，首先咱们都须要理解一下DB库里到底是哪些表比拟占空间，这样才比拟好，因为很有可能是因为某个不合理的业务点导致某个表过大，从而引起磁盘告警，这样从优化业务的角度去从根本上解决磁盘告警的问题。 那么咱们首先要找到某个库或者某个表占用比拟大，我明天遇到的是告警实例就一个业务库，那我能够通过以下几种形式来获取占用比拟大的表： 1.通过Phpmyadmin size字段排序查看哪个表占用过大 2.通过SQL 来获取占用空间大小的表的排序 SELECT TABLE_NAME, concat(truncate(data_length/1024/1024,2),' MB') as data_size, concat(truncate(index_length/1024/1024,2),' MB') as index_size FROM information_schema.tables WHERE TABLE_SCHEMA = '库名' GROUP BY TABLE_NAME ORDER BY data_length desc+--------------------------------+-----------+------------+| TABLE_NAME | data_size | index_size |+--------------------------------+-----------+------------+| xxxxxxxxxxxxxxxxx | 499.08 MB | 95.03 MB || yyyyyyyyyyyyyyyyy | 101.96 MB | 19.13 MB || zzzzzzzzzz | 63.49 MB | 14.32 MB || ddddddddddddddddddddd | 56.97 MB | 30.93 MB || eeeeeeee | 52.17 MB | 12.31 MB || fffffffffffffffffffff | 39.94 MB | 0.00 MB || gggggggggggggggg | 37.22 MB | 21.50 MB |3.如果有多个数据库想查问所有数据库占用空间大小： ...

大家好，我是大彬~ 明天给大家分享MySQL的索引下推。 什么是索引下推索引条件下推，也叫索引下推，英文全称Index Condition Pushdown，简称ICP。 索引下推是MySQL5.6新增加的个性，用于优化数据的查问。 在MySQL5.6之前，通过应用非主键索引进行查问的时候，存储引擎通过索引查问数据，而后将后果返回给MySQL server层，在server层判断是否符合条件。 在MySQL5.6及以上版本，能够应用索引下推的个性。当存在索引的列做为判断条件时，MySQL server将这一部分判断条件传递给存储引擎，而后存储引擎会筛选出合乎MySQL server传递条件的索引项，即在存储引擎层依据索引条件过滤掉不符合条件的索引项，而后回表查问失去后果，将后果返回给MySQL server。 能够看到，有了索引下推的优化，在满足肯定的条件下，存储引擎层会在回表查问之前对数据进行过滤，能够缩小存储引擎回表查问的次数。 举个例子假如有一张用户信息表user_info，有三个字段name, level, weapon（配备），建设联结索引(name, level)，user_info表初始数据如下： idnamelevelweapon1大彬1键盘2盖聂2渊虹3卫庄3鲨齿4大铁锤4铁锤如果须要匹配姓名第一个字为"大"，并且level为1的用户，SQL语句如下： SELECT * FROM user_info WHERE name LIKE "大%" AND level = 1;那么这条SQL具体会怎么执行呢？ 上面分状况进行剖析。 先来看看MySQL5.6以前的版本。 后面提到MySQL5.6以前的版本没有索引下推，其执行过程如下： 查问条件name LIKE 不是等值匹配，依据最左匹配准则，在(name, level)索引树上只用到name去匹配，查找到两条记录（id为1和4），拿到这两条记录的id别离回表查问，而后将后果返回给MySQL server，在MySQL server层进行level字段的判断。整个过程须要回表2次。 而后看看MySQL5.6及以上版本的执行过程，如下图。 相比5.6以前的版本，多了索引下推的优化，在索引遍历过程中，对索引中的字段先做判断，过滤掉不符合条件的索引项，也就是判断level是否等于1，level不为1则间接跳过。因而在(name, level)索引树只匹配一个记录，之后拿着此记录对应的id（id=1）回表查问全副数据，整个过程回表1次。 能够应用explain查看是否应用索引下推，当Extra列的值为Using index condition，则示意应用了索引下推。 总结从下面的例子能够看出，应用索引下推在某些场景下能够无效缩小回表次数，从而进步查问效率。 码字不易，如果感觉对你有帮忙，能够点个赞激励一下！

Windows10装置MySQL8筹备工作装置平台：Windows10。 官网下载 MySQL8 安装包：mysql-8.0.28-winx64。 解压后解压后的文件夹拖到装置门路。 在 mysql-8.0.28-winx64 文件夹下新建目录 data 用来存放数据。 装置过程：1、筹备 my.ini 配置文件：在 mysql-8.0.28-winx64 文件夹下创立文件：my.ini 把上面的配置拷贝进 my.ini，批改两处门路。 [mysqld]# 设置3306端口port=3306# 设置mysql的装置目录basedir=D:\\mysql-8.0.28-winx64# 设置mysql数据库的数据的寄存目录datadir=D:\\mysql-8.0.28-winx64\\data# 容许最大连接数max_connections=200# 容许连贯失败的次数。这是为了避免有人从该主机试图攻打数据库系统max_connect_errors=10# 服务端应用的字符集默认为UTF8character-set-client-handshake=FALSEcharacter-set-server=utf8mb4collation-server=utf8mb4_unicode_ciinit_connect='SET NAMES utf8mb4'# 创立新表时将应用的默认存储引擎default-storage-engine=INNODB# 默认应用“mysql_native_password”插件认证default_authentication_plugin=mysql_native_password[mysql]# 设置mysql客户端默认字符集default-character-set=utf8mb4[client]# 设置mysql客户端连贯服务端时默认应用的端口port=3306default-character-set=utf8mb42、配置环境变量 path：环境变量加 bin 文件夹门路。例如：D:\mysql-8.0.28-winx64\bin 3、管理员身份运行 cmd：进入装置目录下的 bin 文件夹，执行初始化： mysqld --initialize --console命令行运行时会显示初始账户和明码，记下root@locahost：前面的初始密码，前面批改明码时会用到。 4、装置：管理员身份运行 cmd，在 bin 目录执行上面的命令： mysqld --install mysql5、运行MySQL开启服务命令：net start mysql其余命令：改明码命令：mysql -u root -pALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '新密码';卸载命令：先进行 MySQL： net stop mysql再执行卸载命令： sc delete mysqlmysqld remove mysql重装命令：mysqld --install mysql

起源：原创投稿 作者：土豆娃娃简介：高级数据库工程师，从事数据库行业近10年，从Oralce转战MySQL，善于MySQL数据库性能优化、备份复原、国产数据库迁徙，对开源数据库相干技术有浓厚兴趣。 GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。 背景阐明：在一次断网测试过程中，在主库发动了DDL操作，备库失落该DDL，导致主从表构造不统一，接下来的测试居然都失常，表构造不统一，不影响复制过程，感觉比拟奇怪，在这之前都是认为主从表构造不统一会导致复制异样，为了弄明确这个问题，进行了问题复现验证。测试环境MySQL社区版 8.0.25 binlog_format=row复现过程：1、初始化8.0.25版本的两个实例，并且建设了主从复制关系，过程略 主机IP端口角色10.0.0.703309master10.0.0.583309slave2、在58:3309中查看复制关系,确认失常 mysql> show slave status \G*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 10.0.0.70 Master_User: repl Master_Port: 3309 Connect_Retry: 60 Master_Log_File: mysql-bin.000002 Read_Master_Log_Pos: 1094 Relay_Log_File: mysql-relay-bin.000003 Relay_Log_Pos: 442 Relay_Master_Log_File: mysql-bin.000002 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: ...1 row in set, 1 warning (0.01 sec)3、在70:3309中创立test库，并且创立测试表t_diff mysql> create database test;Query OK, 1 row affected (0.00 sec)mysql> use testDatabase changedmysql> create table t_diff(id int primary key auto_increment, a varchar(10), b varchar(10), c varchar(10), d varchar(10));Query OK, 0 rows affected (0.01 sec)mysql>4、在70:3309中，往t_diff中插入4条测试数据 ...

navicat for mysql 16 有限试用 win+R关上运行,输出 regedit 关上注册表 HKEY_CURRENT_USER\SOFTWARE\PremiumSoft\Navicat\Registration16XCS 删除 Registration16XCS 中所有的内容, Registration16XCS不删除如果存在 HKEY_CURRENT_USER\SOFTWARE\PremiumSoft\Navicat\Update 删除 UpdateHKEY_CURRENT_USER\Software\Classes\CLSID{xxx-xxx-xxx-xxx-xxx} 找到一个蕴含Info的 , 删除 Info

1. 前言在SQL开发当中，多表联查是相对绕不开的一种技能。同样的查问后果不同的写法其运行效率也是千差万别。 在理论开发当中，我见过（如同还写过~）不少又长又臭的查问SQL，数据量一上来查个十几分钟那是粗茶淡饭。 因而，深刻了解SQL的多表查问机制，少写一些慢查问，应该能够少挨点骂。 2. 等值连贯和非等值连贯2.1 等值连贯等值连贯是在多表查问中最根底，也最简略的一种，其值为所有满足条件的笛卡尔积。 在from前面，哪个表写在后面后果中哪个表的值就先呈现，如下： select *from student, familywhere student.family_id = family.id; 阿里在最新公布的Java开发手册中强制要求，只有波及多个表，必须在列名前加表的别名（或表名）进行限定 2.2 非等值连贯非等值连贯是通过a表中的值在b表中的某一个范畴来进行的，可能很好的满足预设定好的分段统计需要。 非等值连贯有两种写法，应用between...and...或大于号小于号 -- 第一种写法：应用between...and...select a.discipline_name, a.score, b.grade_tagfrom achievement a, achievement_grade bwhere a.score between b.lowest_score and b.highest_score;-- 第二种写法，应用>=或<=select a.discipline_name, a.score, b.grade_tagfrom achievement a, achievement_grade bwhere a.score >= b.lowest_score and a.score <= b.highest_score; 3. 自连贯和非自连贯3.1 自连贯自连贯，顾名思义就是同一张表本人跟本人连贯，为了辨别须要给表取不同的别名。如一张成绩表，须要查问所有分数比“语文”高的数据： 若不应用自连贯，须要先通过查问语文的分数，而后再查问大于这个分数的数据。 具体能够按如下步骤进行查问： -- 先查问语文的分数select score from achievement where discipline_name = '语文';-- 再查问分数比语文分数更高的数据select * from achievement where score > 76;而应用自连贯，则能够在一条sq语句里实现查问： ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。[toc] MGR和传统主从复制相似，在运行过程中次要关注各节点的运行状态，以及Secondary节点的事务是否有提早。本文介绍如何监控MGR节点状态、事务状态等。 1. 节点状态监控通过查问 performance_schema.replication_group_members 表即可晓得MGR各节点的状态： 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 | af39db70-6850-11ec-94c9-00155d064000 | 192.168.6.27 | 4306 | ONLINE | PRIMARY | 8.0.25 || group_replication_applier | b05c0838-6850-11ec-a06b-00155d064000 | 192.168.6.27 | 4307 | ONLINE | SECONDARY | 8.0.25 || group_replication_applier | b0f86046-6850-11ec-92fe-00155d064000 | 192.168.6.27 | 4308 | ONLINE | SECONDARY | 8.0.25 |+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+输入后果中次要几个列的解读如下： MEMBER_ID 列值就是各节点的 server_uuid，用于惟一标识每个节点，在命令行模式下，调用 udf 时传入 MEMBER_ID 以指定各节点。MEMBER_ROLE 示意各节点的角色，如果是 PRIMARY 则示意该节点可承受读写事务，如果是 SECONDARY 则示意该节点只能承受只读事务。如果只有一个节点是 PRIMARY，其余都是 SECONDARY，则示意以后处于 单主模式；如果所有节点都是 PRIMARY，则示意以后处于 多主模式。MEMBER_STATE 示意各节点的状态，共有几种状态：ONLINE、RECOVERING、OFFLINE、ERROR、UNREACHABLE 等，上面别离介绍几种状态。 ...

咱们上篇文章简略剖析了下InnoDB行锁，文中有提及索引生效时，行锁会降级为表锁，明天咱们这篇文章来聊一聊常见的索引生效的几种状况： 还是和平常一样，咱们先建一张表： CREATE TABLE `user_info` ( `id` int(11) DEFAULT NULL auto_increment, `name` varchar(255) DEFAULT NULL, `nick` varchar(255) DEFAULT NULL, `sex` char(2), `score` int(3), KEY `idx_id` (`id`), KEY `idx_sex` (`sex`), KEY `idx_name_score_nick` (`name`, `score`, `nick`)) ENGINE=InnoDB DEFAULT CHARSET=utf8insert into user_info values (1, '杨过', 'yangguo', '1', 90);insert into user_info values (2, '小龙女', 'xiaolongnv', '0', 88);insert into user_info values (3, '黄药师', 'huangyaoshi', '1', 75);insert into user_info values (4, '郭襄', 'guoxiang', '0', 66);insert into user_info values (5, '何足道', 'hezudao', '1', 50);insert into user_info values (6, '独孤求败', 'duguqiubai', '1', 55);insert into user_info values (7, '方东白', 'fangdongbai', '1', 88);insert into user_info values (8, '赵敏', 'zhaomin', '0', 75);insert into user_info values (9, '程灵素', 'chenglingsu','0', 66);MySQL [wakka]> select * from user_info;+----+--------------+-------------+------+-------+| id | name | nick | sex | score |+----+--------------+-------------+------+-------+| 1 | 杨过 | yangguo | 1 | 90 || 2 | 小龙女 | xiaolongnv | 0 | 88 || 3 | 黄药师 | huangyaoshi | 1 | 75 || 4 | 郭襄 | guoxiang | 0 | 66 || 5 | 何足道 | hezudao | 1 | 50 || 6 | 独孤求败 | duguqiubai | 1 | 55 || 7 | 方东白 | fangdongbai | 1 | 88 || 8 | 赵敏 | zhaomin | 0 | 75 || 9 | 程灵素 | chenglingsu | 0 | 66 |+----+--------------+-------------+------+-------+9 rows in set (0.00 sec)索引生效的第一种常见状况：对字段进行运算，比方对name字段截取操作 ...

背景刚入行的同学，看到在SQL语句中呈现where 1 = 1这样的条件可能会有所困惑，而长时间这样应用的敌人可能又司空见惯。 那么，你是否还记得当初为什么要这样写？是否有性能问题？有没有更好的写法？ 明天这篇文章，带大家从头到尾梳理一下where 1 = 1的应用及改良，或者你能从中失去更多意想不到的播种。 where 1=1的作用如果要问在SQL语句的where条件中多加1=1目标是什么，很简略：使得where条件语句永远为真。实质上就是尽管加了where条件，但实际上永远为真，也就相当于没有加任何约束条件。 应用该语句的场景次要是：动静构建SQL语句。 String sql = "select * from t_user where 1=1 "; if(!b.equals("")){ sql += "and b='"+b+"'";} 在上述语句拼写时，应用where 1=1，当b不等于空时，能够间接拼接“and”语句，而不会导致语法错误。如果没有where 1=1，原来的SQL语句就变成（假如b传入了"abc"）： "select * from t_user where and b= 'abc' "; 很显著，上述SQL语句会有语法错误。所以，之所以增加1=1，就是为了不便SQL拼接。 从另外一个角度来讲，不仅仅1=1能够这样应用，像：1<>2、2>1、'a'='a'等表达式，只有后果为true，都能够如此应用。 where 1<>1下面讲了where 1=1的来历及应用，那么你是否应用过where 1<>1的模式呢？ 你还别说，where 1<>1也是有应用场景的，比方：只获取表构造而不取数据。 create table t_temp as select * from t_user where 1<>1上述语句，创立了一个与t_user表构造一样但没有任何数据的新表t_temp。 当然，除了表构造，其余的构造也能够如此应用。 where 1=1的性能问题有人说，应用where 1=1可能会有性能问题，咱们间接来试验一下。 mysql 8.0.18，t_user表，id_no字段有索引： explain select * from t_user where id_no = 'Tom25';explain select * from t_user where 1=1 and id_no = 'Tom25';执行上述两行SQL语句，explain后果都是如下： ...

前言考研分数落定，往年无缘，着手筹备春招。说到往年考研，分数堪称水涨船高，去年本校专硕270就能进，往年一舍友考了270，排名排到了140名（报的业余要70个），进复试根本有望，预计考本校分数线能到290。走校招的话公司个别面试问题方方面面，重点离不开算法和语言的基础知识。大厂非常重视校招生的算法能力，因为校招生我的项目教训少，而大厂我的项目用户量大。算法这个就是在力扣上多做题，多理解答案思路。语言基础知识这块，就得多看书，有些货色是咱们平时开发接触不到的，面试官又爱问。面试就是这样，面试造火箭，工作拧螺丝。喜硕学长举荐了两本书，一本《深入浅出mysql》，翟振兴著，一本《深刻了解jvm虚拟机》，周志明著。粗略看了一下《深入浅出mysql》更像是一本mysql的字典，外面从根本sql语句到sql优化保护都有波及，心学数据库没有教材买本这个书看也能够，必定比学校发的教材强，学校发的大多都是学校老师本人写的。并且外面举例比拟多，好了解。《深刻了解jvm虚拟机》能够当扩大读物看，外面讲了一些java底层一些常识，比方new一个对象具体产生了什么，jvm如何进行内存回收，jvm调优，咱们不晓得这些货色也不影响咱们用java开发。并且举例较少，倡议有肯定java根底和操作系统常识根底再来看这本书。 mysql锁概述锁是协调各个过程或者线程并发拜访一个资源的重要机制。一个好的锁机制，不仅保障了数据并发拜访的一致性、有效性。并且也尽量减少并发性能的影响。咱们晓得InnoDB引擎绝对于其余来说反对事务。事务是一组SQL语句组成的逻辑处理单元，具备4个个性，通常简称为事务ACID属性。 原子性：事务是一个原子操作单元，要么全副执行，要么全副不执行。一致性：在事务开始和实现时，数据要保持一致状态。就是说在事务开始和实现时，数据放弃一个正确的状态。隔离性：数据库提供肯定的隔离机制，保障事务在不受内部事务影响的环境运行。这意味着事务处理过程中的中间状态对其余事务来说是不可见的。持久性：事务实现后，对于数据的批改时永久性的。咱们拿经典的银行转帐来了解事务。比如说张三账户上想往李四账户上转1000块钱。那么用sql语句就是这样的 update bank set balance = balance - 1000 where name = '张三';update bank set balanc = balance + 1000 where name = '李四';如果咱们将其中的一个字段打错，那么其中一条语句无奈正确执行。 update bank set balance = balance - 1000 where name = '张三';update bank set balance = balance + 1000 where name = '李四';那么会照成张三少了1000块钱而李四没有多1000块钱状况。如果退出事务则不会产生这种状况。原子性保障要么两条语句都执行，要么都不执行。一致性保障钱转帐过程的开始和实现时总数放弃不变，且余额都不会少于0。隔离性保障这个事务执行完之前，不会对其余事务造成影响。持久性保障事务实现后对钱的批改时永恒的。 并发事务带来的问题并发事务减少了数据库利用率，进步吞吐量，也带来了一些问题。 更新失落： 事务A事务B开启一个事务开启一个事务将张三账户余额加200将张三账户余额加500提交//提交这造成了两个人同时给张三存钱，一个人存200，一个人存500，后果账户只多了500，200没了。 脏读： 事务A事务B开启一个事务开启一个事务查问张三余额为1000 如果查问的后果大于等于1000则将张三账户余额减1000查问张三余额为1000/如果查问的后果大于等于1000则将张三账户余额减1000/提交提交/不可反复读： 事务A事务B开启一个事务开启一个事务查问张三余额为1000//将张三账户余额加500/提交查问张三余额为1500/提交/这造成事务A两次查问后果不统一，不晓得已哪个为准。 幻读： 事务A事务B开启一个事务开启一个事务查问姓张的人的余额，查到张三余额为1000//新建个账户叫张四，余额为0/提交查问姓张的人的余额，查到张三余额为1000，张四余额为0/提交/更新失落只有保障一个事务在对数据更新提交之前，另一个事务不能更改数据。这个次要靠利用层面来解决。脏读，不可反复读，幻读，须要靠数据库提供的肯定的事务隔离机制来解决。数据库实现数据隔离形式，根本分以下两种： 一种是在读取数据前，对其加锁，阻止其余事务对数据进行更改。一种是不加任何锁，通过肯定机制生成一个数据申请工夫点的数据快照，并用这个快照来提供肯定级别的数据读取。从用户角度看，好想数据库能够提供对立数据不同版本，这种技术叫做数据多版本并发管制，也就是MVCC。数据库事务隔离越严格，并发副作用越小，但付出代价越大。这是一个衡量的过程。将来解决隔离与并发矛盾，sql定义了4个事务隔离级别，利用依据本人业务逻辑要求，抉择不同隔离级别来均衡隔离与并发的矛盾。 脏读不可反复读幻读未提交读 READ-UNCOMMITTED是是是已提交读 READ-COMMITTED否是是可反复读 REPEATABLE-READ否否是可序列化 SERIALIZABLE否否否

作者：任坤 现居珠海，先后负责专职 Oracle 和 MySQL DBA，当初次要负责 MySQL、mongoDB 和 Redis 保护工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 1、背景线上某外围 MySQL ，版本为 5.6，本地机房1主2从，同时部署了一个异地从库。 从2月14号起异地从库开始报警复制提早，一开始认为是网络稳定导致就没有解决，然而2天后该报警仍然存在且提早越来越高。 2、诊断登录该异地从库，首先甄别是不是IO复制线程引发的提早。 该步骤很简略，查看 show slave status 的 Master_Log_File 是不是主库以后的 binlog ，如果是阐明IO复制线程没有提早，那就是 SQL 复制 线程引起的。 获取该 mysqld 的过程 ID ，执行 perf record -ag -p 11029 -- sleep 10; perf report 重复执行屡次，每次都有 deflate_slow 且占据比例最高 将其开展，和压缩页有关联 pstack 11029 屡次抓取现场，也是和压缩页无关。 该实例的确有个大表，并且只有异地从库开启了页压缩，将其行格局转为 dynamic 。 查看 Seconds_Behind_Master，提早指标开始逐渐降落，阐明该计划失效了。 再次抓取 perf 和 pstack 现场。 --perf report ...

libmysqlclient.a动态库获取办法1、下载源码编译的形式获取MariaDB源码 下载相应源码，下载地址mariadb-5.5.56.tar.gz 下载后传到虚拟机中，解压而后编译。 装置所需罕用的库 apt-get install bison apt-get install flexapt-get install ncurse-develapt-get install cmake编译MariaDB失去libmysqlclient.a tar –zxvf mariadb-5.5.56.tar.gzcd mariadb-5.5.56cmake . –LH #查看cmake的可用选项cmake . -DCMAKE_INSTALL_PREFIX=/home/mysql -DMYSQL_DATADIR=/home/mysqldata -DSYSCONFDIR=/etc -DWITHOUT_TOKUDB=1 -DMYSQL_UNIX_ADDR=/home/tmp/mysql.sock -DDEFAULT_CHARSET=gbk -DDEFAULT_COLLATION=gbk_general_cimakemake install实现上述命令后，在/home/mysql/lib/目录下可失去libmysqlclient.a动态库文件 2、间接获取libmysqlclient.a的形式下载编译后的MariaDB文件，mariadb下载地址 找到对应的版本，我用的是Linux所以对应mariadb-5.5.56-linux-x86_64.tar.gz 解压 tar -zxvf mariadb-5.5.56-linux-x86_64.tar.gzlibmysqlclient.a文件在目录的lib文件夹下 3、间接下载我上传的libmysqlclient.a在我的CSDN外面的资源外面能够找到 32位零碎的libmysqlclient.a 链接63位零碎的libmysqlclient.a 链接

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。[toc] 简要阐明常常有童鞋在群里询问MGR、GreatSQL相干的资源和一些常见的问题，其实这些资源都有公布到各个平台。这里做个汇总，有须要的同学珍藏一下，不便下次查找。MGR相干课程《实战MGR》这是一份比较完善的视频资源，然而没有提供相干的PPT材料，须要大家本人做笔记去学习。初学者最好边学边做笔记，这样记得更牢。视频地址：https://space.bilibili.com/1363850082/channel/seriesdetail?sid=488623 《深入浅出MGR》这份资源相比《实战MGR》内容更精密且在一直连载中，同时每周三都会有公开课针对文档内容进行解说和答疑，相干文字版的资源公布在Gitee上。视频地址：https://space.bilibili.com/1363850082/favlist?fid=1475247782&ftype=create 文档地址：https://gitee.com/GreatSQL/GreatSQL-Doc/tree/master/deep-dive-mgr MGR学习过程呈现故障或疑难征询应用MGR的过程中不免呈现问题或疑难，比方集群无奈开启、MySQL Shell是否跨版本治理等，能够先看下FAQ有没有本人须要的。FAQ地址：https://gitee.com/GreatSQL/GreatSQL-Doc/blob/master/docs/GreatSQL-FAQ.md MGR学习交换群如果以上内容不能解答你的疑难，能够在群里进行征询。QQ群：533341697微信：分割 wanlidbc 发送加群申请如何无效发问总结：尽量具体的内容和前因后果。举例说明。环境：CentOS 7.6版本：MySQL 8.0.14前因：依照XXX文档搭建`MGR单主`集群，做了哪些操作后呈现从节点退出主节点异样的状况。谬误日志：xxxxx贴出谬误日志xxxxxGreatSQL相干资源Gitee主页Gitee上GreatSQL的主页简略阐明了GreatSQL的一些相干内容、版本个性、下载地址、以及部署形式，大家如果有问题能够间接提issue。https://gitee.com/GreatSQL/GreatSQL 版本迭代内容记录着GreatSQL各个公布版本新增、优化的内容，参数等信息。https://mp.weixin.qq.com/mp/appmsgalbum?action=getalbum&__biz=MzkzMTIzMDgwMg==&scene=1&album_id=2271700371393822725&count=3#wechat_redirect 万里数据库出品课程万里数据库出品的面向零根底学员的免费课程，只须要9.9元，即可退出学习，专家坐镇答疑，性价比十分高。《零根底学习MySQL课程》地址：https://ke.qq.com/course/4333819?quicklink=1 课程交换群：975866284 总结以上就是万里数据库出品的一些对于MySQL相干的内容，咱们会继续一直的进行更新优化，并尽力推广MGR的遍及应用，欢送大家持续关注。Enjoy GreatSQL :) 文章举荐：GreatSQL季报（2021.12.26） https://mp.weixin.qq.com/s/FZ... 技术分享|sysbench 压测工具用法浅析 https://mp.weixin.qq.com/s/m1... 故障剖析 | linux 磁盘io利用率高，剖析的正确姿态 https://mp.weixin.qq.com/s/7c... 技术分享|闪回在MySQL中的实现和改良 https://mp.weixin.qq.com/s/6j... 万答#20，索引下推如何进行数据过滤 https://mp.weixin.qq.com/s/pt... 对于 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 的function创立会有各种限度，常常应用的语句的限度如下: 1、CONTAINS_DYNAMIC_SQLCREATE function f1() returns int BEGIN set @cmd = 'select * from t1'; PREPARE stmt1 FROM @cmd; EXECUTE IMMEDIATE @cmd; return 1;END;SQL Error [1336] [0A000]: Dynamic SQL is not allowed in stored function or trigger如果在function创立的时候蕴含PREPARE，EXECUTE, DEALLOCATE，那么这些都会被判断为蕴含DYNAMIC SQL，这些语法都会被回绝。因为应用存储过程的目标是避免应用严格类型的数据进行SQL注入。这个例子外面的sql语句是固定的，曾经脱离了prepare的应用意义，因而不须要创立这种场景。。 2、MULTI_RESULTSCREATE function f1() returns int BEGIN select * from tb_tmp; return 1;END;SQL Error [1415] [0A000]: Not allowed to return a result set from a function这里select语句会返回多行后果，而function只能容许返回一个固定后果，因而这种状况也不容许。 3、HAS_COMMIT_OR_ROLLBACKCREATE function f1() returns int BEGIN commit; return 1;END;SQL Error [1422] [HY000]: Explicit or implicit commit is not allowed in stored function or trigger.因为在procedure的set x=fi()的场景外面，一个set语句蕴含了begin work和commit work，如果f1有commit的话会影响事务前面的治理。 ...

背景无论你是技术大佬，还是刚入行的小白，时不时都会踩到Mysql数据库不走索引的坑。常见的景象就是：明明在字段上增加了索引，但却并未失效。 前些天就遇到一个略微非凡的场景，同一条SQL语句，在某些参数下失效，在某些参数下不失效，这是为什么呢？ 另外，无论是面试或是日常，Mysql索引生效的通常状况都应该理解和学习。 为了不便学习和记忆，这篇文件将常见的15种不走索引状况进行汇总，并以实例展现，帮忙大家更好地防止踩坑。倡议珍藏，以备不时之需。 数据库及索引筹备创立表构造为了逐项验证索引的应用状况，咱们先筹备一张表t_user： CREATE TABLE `t_user` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT 'ID', `id_no` varchar(18) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT '身份编号', `username` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT '用户名', `age` int(11) DEFAULT NULL COMMENT '年龄', `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创立工夫', PRIMARY KEY (`id`), KEY `union_idx` (`id_no`,`username`,`age`), KEY `create_time_idx` (`create_time`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;在上述表构造中有三个索引： id：为数据库主键；union_idx：为id_no、username、age形成的联结索引；create_time_idx：是由create_time形成的一般索引；初始化数据初始化数据分两局部：根底数据和批量导入数据。 根底数据insert了4条数据，其中第4条数据的创立工夫为将来的工夫，用于后续非凡场景的验证： INSERT INTO `t_user` (`id`, `id_no`, `username`, `age`, `create_time`) VALUES (null, '1001', 'Tom1', 11, '2022-02-27 09:04:23');INSERT INTO `t_user` (`id`, `id_no`, `username`, `age`, `create_time`) VALUES (null, '1002', 'Tom2', 12, '2022-02-26 09:04:23');INSERT INTO `t_user` (`id`, `id_no`, `username`, `age`, `create_time`) VALUES (null, '1003', 'Tom3', 13, '2022-02-25 09:04:23');INSERT INTO `t_user` (`id`, `id_no`, `username`, `age`, `create_time`) VALUES (null, '1004', 'Tom4', 14, '2023-02-25 09:04:23');除了根底数据，还有一条存储过程及其调用的SQL，不便批量插入数据，用来验证数据比拟多的场景： ...

咱们都晓得MySQL表引擎常见的分两种，一种MyISAM, 一种InnoDB，这题个别大家都会，常常在DB类面试题中呈现，题目常常问及两者的区别，一聊就是MyISAM是表锁，InnoDB是行锁，InnoDB反对事务，MyISAM不反对事务等等。 明天咱们这篇文章次要来聊一下InnoDB的行锁（因为以后我的我的项目中次要是InnoDB的表引擎）。 InnoDB实现了以下两种类型的行锁， 一种为共享锁，又称为读锁，共享锁是指多个事务对同一数据能够共享同一把锁，都能拜访数据，然而只能读不能批改。 另一种为排他锁，又称为写锁，排他锁不能与其余锁共存，如果一个事务取得了一个数据行的排他锁，其余事务就不能获取该行的其余锁，包含共享锁和排他锁，然而获取排他锁的事务能够对该数据行读取和批改。 对于update, delete, insert 这三种DML语句，InnoDB会主动给波及到的数据行加排他锁。 对于个别的select 语句而言，InnoDB则不会加任何锁。 我上面来举些例子来简略解释一下上述的锁状况：1.建一张test表 create table test( id int(11), name varchar(255), alias varchar(255))engine = innodb default charset=utf8;2.给test表建两个单列索引 create index idx_id on test(id);create index idx_name on test(name);3.test表插一些测试数据 insert into test values(1, '张三', 'zhangsan');insert into test values(2, '李四', 'lisi');insert into test values(3, '王五', 'wangwu');insert into test values(4, '赵六', 'zhaoliu');insert into test values(5, '孙七', 'sunqi');insert into test values(6, '冯八', 'fengba');insert into test values(7, '杨九', 'yangjiu');4.咱们开两个会话窗口来模仿两个事务（一个会话1, 一个会话2）,并且敞开两个会话的autocommit，便于模仿两个事务 ...

例子create database db1;use db1;create table t(id int primary key, a int, b int, index(a))engine=innodb;delimiter ;; create procedure idata() begin declare i int; set i=1; while(i<=1000)do insert into t values(i,i,i); set i=i+1; end while; end;;delimiter ;call idata();create database db2;create table db2.t like db1.t先创立一个表 db1.t，并插入 1000 行数据，同时创立一个雷同构造的表 db2.t。把 db1.t 外面 a>900 的数据行导出来，插入到 db2.t 中。 mysqldump命令mysqldump -h$host -P$port -u$user --add-locks=0 --no-create-info --single-transaction --set-gtid-purged=OFF db1 t --where="a>900" --result-file=/client_tmp/t.sqlmysqldump参数阐明：参数阐明–single-transaction在导出数据的时候不须要对表 db1.t 加表锁，而是应用 START TRANSACTION WITH CONSISTENT SNAPSHOT 的办法–add-locks=0在输入的文件后果里，不减少" LOCK TABLES t WRITE;"–no-create-info须要导出表构造–set-gtid-purged=off不输入跟 GTID 相干的信息–result-file指定输入文件门路，client 示意生成的文件在客户端机器上–skip-extended-insert生成的文件中一条 INSERT 语句只插入一行数据将这些 INSERT 语句放到 db2 库里去执行mysql -h127.0.0.1 -P13000 -uroot db2 -e "source /client_tmp/t.sql"客户端指令source：关上文件，默认以分号为结尾读取一条条的 SQL 语句；将 SQL 语句发送到服务端执行。服务端执行的并不是这个“source t.sql"语句，而是 INSERT 语句。所以，不论是在慢查问日志（slow log），还是在 binlog，记录的都是这些要被真正执行的 INSERT 语句。 ...

最近，又遇到了慢 SQL，简略的看了下，又是因为 MySQL 自身优化器还有查问打算预计不准的问题。SQL 如下： select * from t_pay_recordWHERE(( user_id = 'user_id1' AND is_del = 0 )) ORDER BY id DESC LIMIT 20这个 SQL 执行了 20 分钟才有后果。然而咱们换一个 user_id，执行就很快。从线上业务体现来看，大部分用户的体现都失常。咱们又用一个数据分布与这个用户类似的用户去查，还是比拟快。 咱们先来 EXPLAIN 下这个原始 SQL，后果是： +----+-------------+--------------+------------+-------+-----------------------------------------------------------------------------------------+---------+---------+------+-------+----------+-------------+| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |+----+-------------+--------------+------------+-------+-----------------------------------------------------------------------------------------+---------+---------+------+-------+----------+-------------+| 1 | SIMPLE | t_pay_record | NULL | index | idx_user_id,idx_user_status_pay,idx_user_id_trade_code_status_amount_create_time_is_del | PRIMARY | 8 | NULL | 22593 | 0.01 | Using where |+----+-------------+--------------+------------+-------+-----------------------------------------------------------------------------------------+---------+---------+------+-------+----------+-------------+而后咱们换一些散布差不多的用户然而响应工夫失常的用户，EXPLAIN 后果有的是： ...

ELECT COLUMN_NAME 字段名称, COLUMN_TYPE 数据类型,IF ( IS_NULLABLE = 'NO', '是', '否' ) AS '必填', COLUMN_COMMENT 正文 FROM INFORMATION_SCHEMA.COLUMNS WHERE table_schema = 'srms' AND table_name = 'base_user_role';

MYSQL呈现WAITING FOR TABLE METADATA LOCK的起因和解决方案: 应用管理员权限登录mysql数据库查看未提交的事务：select * from information_schema.innodb_trx 或者select * from information_schema.innodb_trx\G;【纵向查看】 其中字段解释如下： trx_state: 事务状态，个别为RUNNINGtrx_started: 事务执行的起始工夫，若工夫较长，则要剖析该事务是否正当trx_mysql_thread_id: MySQL的线程ID，用于killtrx_query: 事务中的sqlkill 掉线程ID

5.6 中ONLY_FULL_GROUP_BY 默认开启的，group by字段必须在select 查问字段中明确列出，就算selec * 也必须额定加上该字段，所以倡议select 的时候明确写上查问字段；