Mysql

DML数据操纵语言用于对数据表中对数据的（插入，删除， 批改）操作。 插入数据语法insert into <tablename> (columnName1,columnName2,...) values(value1, value2,...) 这里只要求columnName1,columnName2,...和value1, value2,...一一对应。尽管，如果所有字段都要输出，省略字段名他也能够，但在理论我的项目中，还是都会把字段名列出来，以加强SQL的稳定性。例子 mysql> INSERT into students(stu_num, stu_name, stu_gender, stu_age, stu_tel) values('20220601','bill','Male','17','18888888888');删除数据语法delete from <tableName> where **** 删除整张表的数据:    delete from <tableName>删除某些数据:     delete from stus where stu_num='20220609'批改数据语法update <tablename> set columnName=value [where]例子 update stus set stu_gender='Male',stu_qq='88888'where stu_num='20220602'tips:批改多个中央，用逗号隔开如上例。 参考：bilibili

基础架构 客户端Server层连接器治理连贯，连贯命令 mysql -h127.0.0.1 -P3306 -uroot -p权限校验一个用户胜利建设连贯后，即便你用管理员账号对这个用户的权限做了批改，也不会影响曾经存在连贯的权限。批改实现后，只有再新建的连贯才会应用新的权限设置。mysql数据库(零碎数据库)下的表：user、db、tables_priv、columns_priv、proce_priv、proxies_priv独特形成受权表。查问缓存执行的语句及其后果会以 key-value 对的模式，被间接缓存在内存中。 #设置query_cache_type = DEMANDselect SQL_CACHE * from T where id=1；分析器词法剖析，语法分析。分析器先会做“词法剖析”。你输出的是由多个字符串和空格组成的一条 SQL 语句，MySQL 须要辨认出外面的字符串别离是什么，代表什么。做完了这些辨认当前，就要做“语法分析”。依据词法剖析的后果，语法分析器会依据语法规定，判断你输出的这个 SQL 语句是否满足 MySQL 语法。优化器执行打算生成，索引抉择。优化器是在表外面有多个索引的时候，决定应用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连贯程序。执行器操作引擎，返回后果。开始执行的时候，要先判断一下你对这个表 table 有没有执行查问的权限，如果没有，就会返回没有权限的谬误；如果有权限，就关上表继续执行。关上表的时候，执行器就会依据表的引擎定义，去应用这个引擎提供的接口。存储引擎(//TODO索引详解)innodbmyisammemory usage总结本章介绍了 MySQL 的逻辑架构，心愿读者对一个SQL语句残缺执行流程的各个阶段有了一个初步的概念。

前言偶尔的机会敌人说他部门的数据库误删了，想复原回来，他百度了一些材料，也跟着试了。但发现会报一些错，于是他就找我帮忙看一下。对于我来说，因为公司的数据库都是DBA在管控，平时都没机会操作，基本上都停留在实践上。 但为了维持我在他心中的光芒形象，不能让他看出我是个半吊子，我就装逼让他把谬误的信息发给我一下，我好百度一下。于是就有明天这么一篇水文呈现。 敌人的数据库是基于docker搭建的，敌人一度狐疑是因为docker起因导致他复原不胜利。 数据恢复之binlog前置常识注： 本文的例子为demo示例，mysql基于docker搭建。版本为mysql 8.0 1、先确认mysql是否曾经开启binlogSHOW VARIABLES LIKE '%log_bin%';注： mysql8.0默认就曾经开启binlog，且binlog-format为row格局。如果是mysql8.0以下，需通过/etc/my.cnf进行配置开启。配置内容如下 ##配置binlog日志门路以及日志文件名前缀、生成的日志格局为：binlog.000001log-bin=/var/lib/mysql/binlog##留神配置server-id，保障唯一性server-id=1##binlog格局，有3种statement,row,mixedbinlog-format=row2、查看binlog日志列表SHOW MASTER LOGS; 3、查看以后binlog以及以后地位SHOW MASTER STATUS; 4、查看binlog内容SHOW BINLOG EVENTS IN 'binlog.000008'; 5、指定位点查问，比方从pos为746开始查问SHOW BINLOG EVENTS IN 'binlog.000008' FROM 746; 6、指定位点分页查问SHOW BINLOG EVENTS IN 'binlog.000008' FROM 746 LIMIT 0,5 7、刷新产生新binlogFLUSH LOGS; 数据恢复案例有这么一张用户表 假如咱们误删了lisi这条记录当初咱们想把lisi复原回来。 1、查看binlogSHOW MASTER LOGS; 2、查看binlog事件SHOW BINLOG EVENTS IN 'binlog.000010'; 3、通过指定地位复原数据/usr/bin/mysqlbinlog --start-position=65945--stop-position=66150 --database=demo_test /var/lib/mysql/binlog.000010 | /usr/bin/mysql -uroot -p123456 -v demo_test注： /usr/bin/mysqlbinlog 为binlog命令--start-position=65945为复原的开始地位--stop-position=66150为复原的完结地位--database=demo_test 指定数据库为demo_test/var/lib/mysql/binlog.000010 为binlog日志| /usr/bin/mysql -uroot -p123456 -v demo_test通过管道连贯数据库，并通过-v显示详细信息此时执行上来就会可能会呈现 ...

全文建设在MySQL的存储引擎为InnoDB的根底上先看一条SQL如何入库的： 这是一条很简略的更新SQL，从MySQL服务端接管到SQL到落盘，先后通过了MySQL Server层和InnoDB存储引擎。 Server层就像一个产品经理，剖析客户的需要，并给出实现需求的计划。InnoDB就像一个基层程序员，实现产品经理给出的具体计划。在MySQL”剖析需要，实现计划“的过程中，还夹杂着内存操作和磁盘操作，以及记录各种日志。 他们到底有什么用途？他们之间到底怎么配合的？MySQL又为什么要分层呢？InnoDB外面的那一块Buffer Pool又是什么？ 咱们缓缓剖析。 分层构造MySQL为什么要分为Server层和存储引擎两层呢？ 这个问题官网也没有给出明确的答案，然而也不难猜，简略来说就是为了“解耦”。 Server层和存储引擎各司其职，分工明确，用户能够依据不同的需要去应用适合的存储引擎，多好的设计，对不对？ 起初的倒退也验证了“分层设计”的优越性：MySQL最后搭载的存储引擎是自研的只反对简略查问的MyISAM的前身ISAM，起初与Sleepycat单干研发了Berkeley DB引擎，反对了事务。江山代有才人出，技术后浪推前浪，MySQL在继续的降级着本人的存储引擎的过程中，遇到了横空出世的InnoDB，InnoDB的功能强大让MySQL倍感压力。 本人的存储引擎打不过InnoDB怎么办？ 打不过就退出！ MySQL抉择了和InnoDB单干。正是因为MySQL存储引擎的插件化设计，两个公司单干的十分顺利，MySQL也在单干后不久就公布了正式反对nnoDB的4.0版本以及经典的4.1版本。 MySQL合并天下模式也成为MySQL走向凋敝的一个重要因素。这能让MySQL短暂地放弃着极强竞争力。时至今日，MySQL仍然占据着极高数据库市场份额，仅次于王牌数据库Oracle。 Buffer Pool在InnoDB里，有一块十分重要的构造——Buffer Pool。 Buffer Pool是个什么货色呢？ Buffer Pool就是一块用于缓存MySQL磁盘数据的内存空间。 为什么要缓存MySQL磁盘数据呢？ 咱们通过一个例子阐明，咱们先假如没有Buffer Pool，user表外面只有一条记录，记录的age = 1，假如须要执行三条SQL： 事务A：update user set age = 2事务B：update user set age = 3事务C：update user set age = 4如果没有Buffer Pool，那执行就是这样的： 从图上能够看出，每次更新都须要从磁盘拿数据（1次IO），批改完了须要刷到磁盘（1次IO），也就是每次更新都须要2次磁盘IO。三次更新须要6次磁盘IO。 而有了Buffer Pool，执行就成了这样： 从图上能够看出，只须要在第一次执行的时候将数据从磁盘拿到Buffer Pool（1次IO），第三次执行完将数据刷回磁盘（1次IO），整个过程只须要2次磁盘IO，比没有Buffer Pool节俭了4次磁盘IO的工夫。 当然，Buffer Pool真正的运行流程没有这么简略，具体实现细节和优化技巧还有很多，因为篇幅无限，本文不做详细描述。 我想表白的是：Buffer Pool就是将磁盘IO转换成了内存操作，节俭了工夫，进步了效率。 Buffer Pool是进步了效率没错，然而呈现了一个问题，Buffer Pool是基于内存的，而只有一断电，内存外面的数据就会全副失落。 如果断电的时候Buffer Pool的数据还没来得及刷到磁盘，那么这些数据就失落了吗？ 还是下面的那个例子，如果三个事务执行结束，在age = 4还没有刷到磁盘的时候，忽然断电，数据就全副丢掉了： ...

字段束缚目标：保证数据的：有效性、完整性、正确性。分类： not null: 非空束缚 此列不为null 必须提供unique: 惟一束缚 此列的值不能反复primary key: 主键束缚 惟一标一条数据foreign key: 外键束缚 建设不同表之间的关系非空束缚&惟一束缚not null: 非空束缚 此列不为null 必须提供例如上面带有not null或者带有unique的字段： CREATE TABLE students( -> stu_num char(8) not null unique, -> stu_name varchar(20) not null, -> stu_age int not null, -> stu_tel char(11) not null unique, -> stu_qq varchar(11) unique -> );主键束缚一张数据表只能有一个主键，不过一个主键能够有多个列组成（联结主键）,另外，主键肯定非空且惟一，所以设置主键之后，该字段就没必要加非空和惟一束缚了，比方：写法一： CREATE TABLE students( -> stu_num char(8) not null primary key, -> stu_name varchar(20) not null, -> stu_age int not null, -> stu_tel char(11) not null unique, -> stu_qq varchar(11) unique -> );写法二： ...

MySql之json_extract函数解决json字段在db中存储json格局的数据，置信大家都或多或少的应用过，那么在查问这个json构造中的数据时，有什么好的办法么？取出String之后再代码中进行解析？ 接下来本文将介绍一下Mysql5.7+之后提供的json_extract函数，能够通过key查问value值 <!-- more --> 1. 应用形式数据存储的数据是json字符串，类型为咱们罕用的varchar即可 语法: JSON_EXTRACT(json_doc, path[, path] …)若json字符串非数组时，能够通过$.字段名来示意查问对应的value 2.应用演示创立一个测试的表 CREATE TABLE `json_table` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键id', `val` json DEFAULT NULL COMMENT 'json字符串', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;插入几条数据 insert into `json_table` values (1, '{"name": "一灰灰blog", "age": 18}');insert into `json_table` values (2, '{"name": "一灰灰blog", "site": "https://blog.hhui.top"}');查问json串中的name，如下 mysql> select json_extract(`val`, '$.name') from `json_table`;+-------------------------------+| json_extract(`val`, '$.name') |+-------------------------------+| "一灰灰blog" || "一灰灰blog" |+-------------------------------+如果查问的key不在json串中，返回的是null，而不是抛异样 mysql> select json_extract(`val`, '$.name') as `name`, json_extract(`val`, '$.site') as `site` from `json_table`;+-----------------+-------------------------+| name | site |+-----------------+-------------------------+| "一灰灰blog" | NULL || "一灰灰blog" | "https://blog.hhui.top" |+-----------------+-------------------------+接下来再看一下如果为json数组，怎么整 ...

作者：陈书俊 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 1、Oracle 为什么能够对 MySQL 采纳双许可证模式（GPLv2 开源许可证和商业许可证）公布？在 MySQL 中援用的第三方源代码，全副都基于不具备许可证传染性的宽松开源许可证公布，或者基于双许可证公布，Oracle 在其开源版 MySQL 中对此类双许可证的第三方代码 抉择应用 GPLv2 许可证，在闭源的商业版 MySQL 中对此类双许可证的第三方代码抉择使 用更为宽松的许可证。 例如 MySQL 在援用 Memcached.pm 的源代码时有如下申明（Artistic license 就是更 为宽松且没有传染性的开源许可证，容许批改或援用其源代码后不开源）： Memcached.pm Memcached.pm Memcached.pm is licensedunder the Perl license. Oracle may use, redistribute and/or modify this code under the terms of either: a) the GNU General Public License as published by the Free Software Foundation; either version 1, or (at your option) any later version, or ...

数值类型类型内存空间大小示意范畴阐明tinyint1byte有符号 -128~ 127 无符号 0~255特小型整数（能够寄存人类的年龄）smallint2byte(16bit)有符号：-32768~32767 无符号 0~65535小型整数mediumint3byte 中型整数int/integer4byte 整数bigint8byte 大型整数float4byte 单精度double8byte 双精度decimal第一个参数+2 罕用于价格decimal(10,2)示意最多8位整数且肯定保障2位小数字符类型存储字符系列的类型 类型字符长度(字节)阐明char0-255定长字符串，最多存储255个字符；当指定字段为char(n)此列数据中最长为n个字符，如果增加数据为a个少于n，会主动补充n-a个'\u0000'varchar0-2^16-1可变长度字符串，此类型最大长度为2^16-1tinyblob0-255存取二进制字符串blob0-2^16-1存取二进制字符串mediumblob0-2^24-1存取二进制字符串longblob0-2^32-1存取二进制字符串tinytext0-255文本数据（字符串）text0-2^16-1文本数据（字符串）mediuntext0-2^24-1文本数据（字符串）longtext0-2^32-1文本数据（字符串）日期类型因为很多场景须要基于日期进行查问某个时间段的数据，这种类型就应运而生了。 类型格局阐明date2022-05-30日期 只存储年月日time12:00:00工夫 只存储工夫datetime2022-05-30 12:00:00日期+工夫timestamp20220530120000日期+工夫（工夫戳）参考：bilibili

重做日志 redo log重做日志是用来保障事务的持久性的，它体现了 MySQL 中的 WAL 技术，即在长久化数据之前，先保障 redo log 曾经写到了磁盘上。重做日志是基于磁盘的数据结构，记录了在某个数据页上做了什么批改，是 InnoDB 引擎特有的日志，在事务提交前重做日志被写入磁盘，当零碎解体时，就能够依据 redo log 来复原数据。 WAL：Write-Ahead Logging，先写日志，再写磁盘。当执行一条更新语句时，InnoDB 首先会将更新信息写入重做日志中，而后将重做日志放到重做日志缓冲区（redo log buffer），之后依照肯定的频率将 redo log buffer 写入重做日志文件中。 重做日志对应的物理文件 默认状况下，在数据库的 data 目录下有两个文件 ib_logfile1 和 ib_logfile2。重做日志文件以循环写入的形式进行： 重做日志缓冲区刷新到磁盘 依照上面三种状况刷新： Master Thread 每一秒将重做日志缓冲刷新到重做日志文件；每个事务提交时会将重做日志缓冲刷新到重做日志文件；当重做日志缓冲残余空间小于 1 / 2 时刷新到重做日志文件；对于第二种状况，触发写磁盘的条件由 innodb_flush_log_at_trx_commit 参数管制，示意当提交事务时，解决 redo log 的形式。 innodb_flush_log_at_trx_commit 的有效值为 0, 1, 2；默认为 1： 0：提交事务时并不刷新缓冲区，而是期待主线程每秒的刷新；1：提交事务时将重做日志缓冲区刷新到磁盘；合乎事务的 ACID 个性；2：提交事务时将重做日志缓冲区先刷新到文件系统的缓存中，之后每秒将缓存刷新到磁盘中，也就是说重做日志异步写到磁盘；当值为 0 和 2 时，数据库产生解体，会存在局部日志未刷新到磁盘，因而会失落局部数据； 二进制日志 binlog后面提到的 redo log 是 InnoDB 引擎特有的日志，而 Server 层也有本人的日志，即二进制日志 binlog，binlog 记录了数据库增删改操作的信息，以二进制的格局保留在磁盘中。当提交事务时，一次性将事务中的所有 SQL 语句写入 binlog 中。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。微服务零碎架构背景回顾一下微服务架构是如何进化产生的，最早呈现的是单体利用架构，起初为了具备肯定的扩大和可靠性，就有了垂直拆分架构，也就是加了个负载平衡，而到当初的微服务架构则是进一步在探讨一个利用零碎该如何设计才可能更好的开发、治理更加灵便高效。 什么是微服务架构微服务架构的核心思想是：分而治之，就是开发多个围绕业务畛域的组件来构建利用，让组件能够独立的开发、测试、部署和减速。 其长处在于： 反对独立迭代按需扩大，适宜业务疾速变动和扩大反对分布式或多团队开发，不同的团队负责各自不同的畛域，绝对独立、专一，也就更高效反对多语言混合开发、多版本组件独立部署、测试和共存微服务架构的前置条件从技术角度看：服务注册、对立配置、平安认证、对立日志/告警、分布式事务、继续集成等根底服务要前置于业务模块之前实现，该局部工作如果在业务实现后，重构减少该局部性能会减少不必要的老本。 从团队角度看：架构和团队的影响是双向的，微服务在组织的落地须要实际或者点，须要组织外部成员在：服务划分、继续交付、问题剖析等畛域造成一些教训后，再分步骤推广。 微服务架构的准则无状态准则首先，须要定义一下状态，如果数据须要被多个服务或特定服务的多个阶段共享，能够将其成为状态。 无状态准则并不是说在微服务架构中不容许状态的存在，而是要把有状态的服务扭转成无状态的独立业务服务，比方：将状态数据在申请间传递或放到分布式存储中，都能够解决状态服务的问题，这样服务就能够按需动静伸缩。 Restful通信格调JSON申请和响应，轻量简略，人机可读实现编程语言无关基于无状态HTTP协定，易测试易扩大前后端拆散简略的说，就是前后端代码物理拆散，而不是将：JS, HTML, CSS, JSP都堆到一起，前期难以保护。 微服务架构与SOA架构的异同 相同点： 业务被拆分成多个不同的服务单个服务反对部署多个繁多服务反对同时多版本部署不同点： 微服务的指导方针中包含：每个服务应用独立的数据库存储SOA服务之间通常通过ESB音讯总线进行通信，微服务之间通常间接通信微服务架构实用的场景研发团队：研发团队分布式、多开发语言场景下绝对适宜，人员在20人以上的规模有独立的运维部署团队业务简单：10+以上外围业务模块，且业务继续降级改良我的项目须要长期迭代保护业务处于高速发展期或成熟期微服务架构不实用的场景初创公司或10人以下的小团队概念验证性质的我的项目微服务与单体利用在生产率上的比拟依据马丁·福勒介绍， 在零碎复杂度较小时，单体利用的生产率更高，微服务架构反而升高了生产率。然而，当复杂度到了肯定规模，无论采纳单体利用还是微服务架构，都会升高零碎的生产率。区别是：单体利用生产率开始急剧下降，而微服务架构则能缓解生产率降落的水平。如下图： 结束语在软件开发的世界，没有银弹，架构的抉择是基于研发团队、业务需要和市场机会等因素综合思考的后果，不要随声附和，也不要旧调重弹， Enjoy GreatSQL :) 文章举荐：面向金融级利用的GreatSQL正式开源https://mp.weixin.qq.com/s/cI... Changes in GreatSQL 8.0.25 (2021-8-18)https://mp.weixin.qq.com/s/qc... MGR及GreatSQL资源汇总https://mp.weixin.qq.com/s/qX... GreatSQL MGR FAQhttps://mp.weixin.qq.com/s/J6... 在Linux下源码编译装置GreatSQL/MySQLhttps://mp.weixin.qq.com/s/WZ... # 对于 GreatSQL GreatSQL是由万里数据库保护的MySQL分支，专一于晋升MGR可靠性及性能，反对InnoDB并行查问个性，是实用于金融级利用的MySQL分支版本。 Gitee: https://gitee.com/GreatSQL/Gr... GitHub: https://github.com/GreatSQL/G... Bilibili： https://space.bilibili.com/13... 微信&QQ群： 可搜寻增加GreatSQL社区助手微信好友，发送验证信息“加群”退出GreatSQL/MGR交换微信群 QQ群：533341697 微信小助手：wanlidbc 本文由博客一文多发平台 OpenWrite 公布！

DDL罕用于数据库的操作，比方数据库的增删查改。 创立数据库 CREATE database db_test或者CREATE database if not exists db_test;显示所有数据库SHOW databases;批改数据库 ALTER database db_test character set gbk;删除数据库DROP database db_test;或者DROP database if exists db_test ;抉择数据库进行操作USE db_test 在抉择数据库之后，咱们就能够创立数据表了：创立数据表未完待续。。。。。。。

SQL的分类DDL（Data Definition Language）包含CREATE、DROP、ALTER、RENAME、TRUNCATE等用来创立、删除、批改数据库和数据表的构造的关键字。DML（Data Manipulation Language）包含INSERT、DELETE、UPDATE、SELECT等用来增加、删除、更新、查询数据库记录的关键字。DCL（Data Contril Language）包含GRANT、REVOKE、COMMIT、ROLLBACK、SAVEPOINT等用来定义安全级别和拜访权限的关键字。SQL的规定和标准根本规定SQL能够写在一行 or 多行， 为了可读性，举荐将子句分行写，引入必要的缩进。每天SQL语句用英文分号‘;’或者\g、\G结尾。关键字不能缩写不能分行字符串和日期类型的数据能够用单引号，其余列名尽量用双引号，不倡议省略as。大小写标准数据库名、表名、表别名、变量名、字段别名全副小写SQL关键字、函数名、绑定变量都大写正文标准MySQL特有单行正文办法： #正文文字单行正文办法： -- 正文文字 -- 记得两个-前面必须有一个空格多行正文办法： /正文文字/

DDL是数据定义语言，用于定义和治理SQL 数据库中的所有对象的语言,罕用的命令有：create，drop，alter等。通常来说，浪潮云溪数据库DDL语句的流程次要分为四个局部，别离是逻辑打算生成，物理打算生成，打算执行和schemachange。本文次要介绍逻辑打算生成，物理打算生成和打算执行。 - 逻辑打算生成 - 逻辑打算生成次要是生成一个planNode逻辑打算节点，每一条SQL都会有本人的planNode，以create table为例，该SQL生成的planNode中蕴含有CREATETABLE statement信息例如表名，有该表所属数据库的信息，还有该表的列的信息等。planNode生成后将其记录到planner的curplan（curplan有以后打算的属性，蕴含形象语法树，planNode，子查问打算等）里，次要流程如下图所示。 以create table语句为例，构建逻辑打算次要是进行memo的构建以及RBO和CBO优化（memo是用来存储查问打算森林的一种数据结构）。首先会初始化一个优化打算的上下文optPlanningCtx，外面会初始化优化器并记录是否应用memo cache进行memo的缓存复用，而这也是DDL与DML语句之间的区别，DDL语句不会复用memo。 构建memo会调用builder的build()办法，对于不同的DDL语句，会调用不同的办法去构建逻辑打算。Create table语句会调用buildCreateTable,构建outScope，次要是生成语句的表达式expr记录在outScope里，最终记录到memo外面。而对于其余的DDL语句则会调用tryBuildOpaque，而后通过ConstructOpaqueDDL函数构建memo的expr。 Memo构建完当前就是进行优化，通过Optmize()函数进入进行RBO和CBO优化，而DDL语句不会进行优化，这也是与DML语句的区别，DML会将优化完的memo退出缓存。而后就是进行逻辑打算planNode的构建，DDL语句中，create语句会执行buildCreateTable进行ConstructCreateTable构建createTableNode，而drop和alter语句则会执行buildOpaque，通过ConstructOpaque返回所对应的planNode，最初将构建好的planNode封装到planTop外面，并且如果是DDL语句会在planTop的flags外面置planFlagIsDDL。 - 物理打算生成 - 逻辑打算生成后，就会依据逻辑打算生成物理打算，次要的流程如下图所示。 在生成物理打算之前会先判断语句是否须要分布式执行，DDL不会进行分布式执行，会生成一个本地的PlanningCtx（PlanningCtx 蕴含在单个查问的整个布局过程中应用和更新的数据）。如果SQL语句有子句的话，则会调用PlanAndRunSubqueries函数先执行子句。DDL语句会进入到wrapPlan进行物理打算的生成。在wrapPlan中会深度优先遍历planNode树，找到第一个反对DistSQL processor的planNode而后在该planNode上递归DistSQL优化，如果有等效的 DistSQL 处理器调用createPlanForNode生成物理打算。 函数首先判断以后planNode的类型，调用对应的函数为planNode创立物理打算(如indexJoinNode会调用createPlanForIndexJoin)，DDL则会递归调用wrapPlan将planNode包起来持续解决(wrapPlan只包装节点自身而不包含孩子节点)。而后，调用shouldPlanTestMetadata函数判断是否须要进行元数据处理，如果须要则增加相干信息）。而后再进行创立planNodeToRowSource（该构造体），如果被包裹的planNode是flow中的第一个node，且语句类型是RowsAffected（返回受影响行的计数的语句）则能够应用fast path，planNode子树若反对DistSQL优化会在被优化后连贯到wrapper。返回wrapper后，为物理打算增加LocalProcessor和LocalProcessorIndexes的元素，LocalProcessors数组蕴含了所有的planNodeToRowSource，即被包裹的planNode，记录物理打算的ResultTypes。 每当增加新的PhysicalPlan时，都须要覆写ResultRouters，咱们将只须要一个result router，因为local processor不是分布式的，确保p.ResultRouters只有一个元素，最初填充打算的endpoints就进入执行流程。 - 执行 - 执行过程的次要流程如下图所示。 StartExec是具体执行planNode的办法，依据构建的物理打算对表描述符进行操作。StartExec会先对commend遍历（以alter table为例，commend是一个表批改操作的切片），在遍历中获取集群版本信息，查看在以后版本中是否反对增加列的类型，若反对则为true，反之报错；接着依照打算中的列定义信息生成列描述符，若增加的列是主键或含有唯一性束缚，还会生成索引描述符，将这些描述符会包装成一个个mutation并增加到表描述符的Mutations字段里；而后依据表、mutation等信息创立一个job，job也是通过零碎表system.jobs进行保护，这个job是用来触发及跟踪schema change执行，接着将含有mutations的表形容通过batch更新到零碎表"descriptor"里。 执行流程中最次要的构造体就是batch，表描述符会存在batch外面，通过writeTableDescToBatch函数，在该函数外面，首先判断这个表如果不是一个新的表，须要将表的version+1，而后会验证表描述符格局是否良好，调用addUncommittedTable函数，这容许事务在绕过表租赁机制的状况下查看本人的批改，最初是将表描述符的KV写入到batch外面。batch构建完当前就执行batchRequest。 在执行流程完结后，如果须要数据回填的话，则进入到online schema change流程回填数据而后写入零碎表实现执行流程，如果不需要的话，则在执行算子的时候就将数据写入到零碎表中实现执行流程。

下方视频中演示了如何应用HHDBCS工具中的文件治理性能进行文件编辑、搜寻、重命名，还可通过文件治理性能导入文件到指定的窗口等，欢送观看！社区里还有“Mysql治理系列“其余操作视频：https://dbcs.deskui.com/pages...，欢送拜访！https://www.bilibili.com/vide...

应用HHDBCS工具创立增加SQL文件工作，能够在指定的数据库中执行SQL文件，创立胜利后，可通过工作治理生成表格数据。具体操作请参看下方视频！社区里还有“Mysql治理系列“其余操作视频：https://dbcs.deskui.com/pages...，欢送拜访！https://www.bilibili.com/vide...

目录 明天给大家分享个生产事变，一个因为 MySQL 分页导致的线上事变，事件是这样的～ 背景 一天早晨 10 点半，上班后欢快的坐在在回家的地铁上，心里想着周末的生存怎么安顿。 忽然电话响了起来，一看是咱们的一个运维同学，登时缓和了起来，本周的版本曾经公布过了，这时候打电话一般来说是线上出问题了。 果然，沟通的状况是线上的一个查问数据的接口被疯狂的失去理智般的调用，这个操作间接导致线上的 MySQL 集群被拖慢了。 好吧，这问题算是重大了，匆匆赶到家后关上电脑，跟共事把 Pinpoint 上的慢查问日志捞进去。 看到一个很奇怪的查问，如下： 1 POST  domain/v1.0/module/method?order=condition&orderType=desc&offset=1800000&limit=500 domain、module 和 method 都是化名，代表接口的域、模块和实例办法名，前面的 offset 和 limit 代表分页操作的偏移量和每页的数量，也就是说该同学是在翻第（1800000/500+1=3601）页。初步捞了一下日志，发现有 8000 屡次这样调用。 这太神奇了，而且咱们页面上的分页单页数量也不是 500，而是 25 条每页，这个相对不是人为的在性能页面上进行一页一页的翻页操作，而是数据被刷了（阐明下，咱们生产环境数据有 1 亿+）。 具体比照日志发现，很多分页的工夫是重叠的，对方应该是多线程调用。 通过对鉴权的 Token 的剖析，根本定位了申请是来自一个叫做 ApiAutotest 的客户端程序在做这个操作，也定位了生成鉴权 Token 的账号来自一个 QA 的同学。立马打电话给同学，进行了沟通和解决。 剖析 其实对于咱们的 MySQL 查问语句来说，整体效率还是能够的，该有的联表查问优化都有，该简略的查问内容也有，要害条件字段和排序字段该有的索引也都在，问题在于他一页一页的分页去查问，查到越前面的页数，扫描到的数据越多，也就越慢。 咱们在查看前几页的时候，发现速度十分快，比方  limit 200，25，霎时就进去了。然而越往后，速度就越慢，特地是百万条之后，卡到不行，那这个是什么原理呢。 先看一下咱们翻页翻到前面时，查问的 sql 是怎么的： 1 select * from t_name where c_name1='xxx' order by c_name2 limit 2000000,25;这种查问的慢，其实是因为 limit 前面的偏移量太大导致的。 比方像下面的 limit 2000000，25，这个等同于数据库要扫描出 2000025 条数据，而后再抛弃后面的 20000000 条数据，返回剩下 25 条数据给用户，这种取法显著不合理。 大家翻看《高性能 MySQL》第六章：查问性能优化，对这个问题有过阐明：分页操作通常会应用 limit 加上偏移量的方法实现，同时再加上适合的 order by 子句。但这会呈现一个常见问题：当偏移量十分大的时候，它会导致 MySQL 扫描大量不须要的行而后再摈弃掉。 ...

办法1：集体统计int型状态的时候，该办法应用比拟多。 SELECT SUM(CASE WHEN `status` = 0 THEN 1 ELSE 0 END) AS status_zero,SUM(CASE WHEN `status` = 1 THEN 1 ELSE 0 END) AS status_oneFROM `vg_camera_status`;//其中，status为字段名，等号前面的值为要统计的状态值。status_zero,status_one为查问后果新的字段名(可任意)。vg_camera_status为表名。我的项目中应用记录： 办法2：SELECT status,COUNT(status) AS cacount FROM vg_camera_status WHERE status=0 GROUP BY status HAVING cacount > 1 ORDER BY cacount DESC;//其中，status为字段名，cacount是查问后果新的字段名(可任意)，vg_camera_status 为表名//WHERE status=0 GROUP BY status HAVING cacount > 1;示意从查问的后果中获取状态为0的总数,具体对于GROUP BY，HAVING，ORDER BY的用法可自行百度。(字段名和关键字能够不辨别大小写)

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。[toc] 一、Prometheus# 1.下载wget https://github.com/prometheus/prometheus/releases/download/v2.35.0/prometheus-2.35.0.linux-amd64.tar.gz# 2.解压tar xvpf prometheus-2.35.0.linux-amd64.tar.gz -C /usr/local# 3.建软链ln -s /usr/local/prometheus-2.35.0.linux-amd64 /usr/local/prometheus# 4.建用户和目录并开权限groupadd prometheususeradd prometheus -g prometheus -s /sbin/nologinmkdir -p /data/prometheuschown prometheus.prometheus /data/prometheus -Rchown prometheus.prometheus /usr/local/prometheus/ -R# 5.配置启动echo '[Unit]Description=prometheusAfter=network.target[Service]Type=simpleUser=prometheusExecStart=/usr/local/prometheus/prometheus \ --config.file=/usr/local/prometheus/prometheus.yml \ --storage.tsdb.path=/data/prometheus \ --web.console.templates=/usr/local/prometheus/consoles \ --web.console.libraries=/usr/local/prometheus/console_librariesExecReload=/bin/kill -HUP $MAINPIDRestart=on-failureRestartSec=60s[Install]WantedBy=multi-user.target' > /usr/lib/systemd/system/prometheus.service# 6.增加prometheus.yml配置echo 'global: scrape_interval: 15s scrape_timeout: 10s evaluation_interval: 15salerting: alertmanagers: - static_configs: - targets: - localhost:9093 scheme: http timeout: 10srule_files:- /usr/local/prometheus/rules.d/*.rulesscrape_configs:- job_name: prometheus honor_timestamps: true scrape_interval: 5s scrape_timeout: 5s metrics_path: /metrics scheme: http static_configs: - targets: - localhost:9090- job_name: node-exporter honor_timestamps: true scrape_interval: 5s scrape_timeout: 5s metrics_path: /metrics scheme: http static_configs: - targets: - localhost:9100- job_name: mysqld-exporter honor_timestamps: true scrape_interval: 5s scrape_timeout: 5s metrics_path: /metrics scheme: http static_configs: - targets: - localhost:9104' > /usr/local/prometheus/prometheus.yml# 7.启动systemctl enable prometheus.servicesystemctl start prometheus.service# 8.确认开启[root@mgr2 prometheus]# netstat -nltp|grep prometheustcp6 0 0 :::9090 :::* LISTEN 11028/prometheus9.浏览器拜访呈现prometheus的治理后盾 ...

问题形容 显示表不存在或者写sql时表名没有提醒 问题起因1，没有同步产生的变更数据库没有刷新曾经改变的变更，刷新下最新的数据，操作如下： 问题起因2，插件配置未实现，配置步骤如下，缺一不可配置数据库连贯确保连贯胜利，须要指定数据库，确保只抉择了一个schema，并且是表所在的schema配置我的项目中数据库的方言配置我的项目中插件的方言

1、新建User表，构造，及表中数据如下 2、查问User表中，雷同年龄最大的一条记录3、查问语句： select * from ( select ROW_NUMBER() over(partition by tt.name order by tt.age desc) RowNum ,tt.* from user tt) as t1 where RowNum = 14、查问后果：5、查问，每组中，年龄最小的，须要查出所有的最小年龄记录6、查问语句： select t1.* from user t1 INNER JOIN(select * from ( select ROW_NUMBER() over(partition by tt.name order by tt.age ASC) RowNum ,tt.* from user tt) as t1 where RowNum = 1) t2 on t1.`name` = t2.name and t1.age = t2.age

HHDBCS上线统信商店以来，受到了各地敌人的青睐和宽泛应用，但因一些其余因素在统信中无奈胜利装置HHDBCS时，就成了大家比拟苦恼的事件，因而咱们为大家录制了一个在“uos下apt装置hhdbcs”的操作视频，心愿能给大家带来帮忙。版本升级和更新许可拜访此链接：https://dbcs.deskui.com/pages...，外面有相干的操作视频，欢送拜访！https://www.bilibili.com/vide...

HHDBCS工具中模板窗口性能，能够通过模板疾速创立所须要的SQL，模板编辑器还可生成批量测试数据，为咱们进步工作效率。平铺窗口性能则能够创立窗口模板，自定义想要的窗口，可通过模板列表关上自定义的窗口。请参看下方视频中的应用操作！社区里还有“Mysql治理系列“其余操作视频：https://dbcs.deskui.com/pages...，欢送拜访！https://www.bilibili.com/vide...

　前言　Seconds_behind_master 是咱们察看主从提早的一个重要指标。但任何指标所能示意的精度都是无限的。例如用精度只能到秒的指标去掂量毫秒级的体现就会产生十分大的误差。如果再以此误差去剖析问题，就会让思维走上弯路。例如用 Seconds_behind_master 去评估 1s 内的主从提早就是一个典型的例子。　问题现场　在一些问题的排查中，咱们留神到一个很奇怪的景象。那就是雷同配置的从库体现进去的主从提早差距有将近 500ms。而这两个从库之间的差异就是所在的机房不一样 (和主库都不在同一个机房)。如下图所示： 网络问题　难道是网络问题？那咱们 ping 一下吧，最多也就相差 1ms。那么还有 499ms 去哪里了呢，看来还得持续开掘。　Seconds_behind_master 的取点数据　直觉上来说网络问题不可能导致 500ms 这么大的误差，而机器配置和 MySQL 版本又是一样的。这就让笔者不得不狐疑这个兼容数据的准确性。所以就先看看这个 500ms 是怎么计算出来的。 从监控取点数据来看从库 C 的确有主从提早，不然为什么有那么多取点为 0 呢。　Seconds_behind_master 什么时候计算出来为 1　这时候笔者忽然想到一个点，如果主从提早一个是 501ms 一个是 499ms，那么 Seconds_behind_master 计算的时候会不会采纳四舍五入法。501ms (>=500ms) 的就是 1，499 (<500ms) 的就是 0？为了理解这一问题，笔者就去翻了翻源码。 ###Seconds_behind_master 在 MySQL 中的计算源码 计算这个指标的代码有很多奥妙的分支，应答了各种 corner case。在此笔者只列出和以后问题相干的源码。 long time_diff= ((long)(time(0) - mi->rli->last_master_timestamp) - mi->clock_diff_with_master);　后面 time (0) - mi->rli->last_master_timestamp 显著就是指时间差。然而，咱们要思考到一个很容易被疏忽的常识，也就是不同机器的工夫戳是不一样的！ ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。[toc] 1.新增个性1.1 新增仲裁节点（投票节点）角色该节点仅参加MGR投票仲裁，不寄存理论数据，也无需执行DML操作，因而能够用个别配置级别的服务器，在保障MGR可靠性的同时还能升高服务器老本。 新增参数group_replication_arbitrator用于设置仲裁节点。 若想新增一个仲裁节点，只需在 my.cnf 配置文件中增加如下配置：group_replication_arbitrator = true 当集群中只剩下 Arbitrator 节点时，则会主动退出。 mysql> select * from performance_schema.replication_group_members;+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+----------------------------+| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+----------------------------+| group_replication_applier | 4b2b46e2-3b13-11ec-9800-525400fb993a | 172.16.16.16 | 3306 | ONLINE | SECONDARY | 8.0.27 | XCom || group_replication_applier | 4b51849b-3b13-11ec-a180-525400e802e2 | 172.16.16.10 | 3306 | ONLINE | ARBITRATOR | 8.0.27 | XCom || group_replication_applier | 4b7b3b88-3b13-11ec-86e9-525400e2078a | 172.16.16.53 | 3306 | ONLINE | PRIMARY | 8.0.27 | XCom |+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+----------------------------+能够看到，MEMBER_ROLE 这列显示为 ARBITRATOR，示意该节点是一个仲裁节点。 ...

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

首先，要留神的是，NOT IN 和 NOT EXISTS 在某些状况下相等，然而 IN 与 EXISTS 在所有状况下都是不相等的；只有在相比拟的两个字段都不容许存在空值（NOT NULL）时 NOT IN 和 NOT EXISTS 才相等，只有相比拟的某个字段存在 null 值，那么它们就不能等同而视。具体来说，只有相比拟的字段存在一个 null 值，NOT IN 就不会匹配任何行。 为什么会这样呢？咱们先来看看 NOT IN 原理： SELECT * FROM student s WHERE s.id NOT IN ( SELECT a.id FROM assistant)下面这条语句等价于： SELECT * FROM student s WHERE (s.id != (SELECT a.id FROM assistant WHERE a.id=1)ANDs.id != (SELECT a.id FROM assistant WHERE a.id=2)ANDs.id != (SELECT a.id FROM assistant WHERE a.id=3)ANDs.id != (SELECT a.id FROM assistant WHERE a.id=4))假如 a.id = 1 这一行的值为 null，那么 != 就会返回未知（UNKNOWN），因为这些值通过 AND 连接起来，所以最终 WHERE 子句不会失去 true，也就不会返回任何记录。 ...

问题形容在 HANA 数据库外面有个用户 SYS_XSA, 连贯时总报错 authentication failed， 然而明码是刚改过的，必定是对的，还有什么起因会导致无奈连贯数据库呢？ SYS_XSA authentication failed SQLSTATE: 28000 先装了 HANA2.0, 装置之后 HANA cockpit 是能够用的，起初又装置了 S/4HANA，后果装置之后，原来的 hana-cockpit 就不能用了。接着用 XSA diagnose 试了试。 装置 S/4HANA 导致原来的 HANA-COCKPIT 不能用了，解决这个问题的过程中，呈现了后面改了明码也无奈登陆的问题，发现更改明码操作对 SYS_XSA 这个用户有效。 剖析装置 XS 高级应用程序服务器会创立一组预约义用户，这些用户用于反对底层零碎的操作。 零碎的超级用户 (<sid>adm) 须要可用能力管理系统的生命周期。 同样，须要一个治理 XS 高级零碎用户（默认为 XSA_ADMIN）来执行应用程序服务器的初始设置，例如，授予其余用户在专用组织中创立空间的权限等。 技术数据库用户是在装置期间为所有须要在 SAP HANA 模式中保留数据的服务器组件创立的。 SYS_XSA 用户的职责见 SAP 官网： 依据谬误音讯 SYS_XSA authentication failed SQLSTATE: 28000 在网络上搜寻，找到了一篇帖子：Troubleshooting sap hana error： 这是与 sap hana 中的身份验证失败相干的一般性谬误。 该谬误背地有不同的起因，这些起因并不总是不言而喻的。 此谬误音讯可能是因为明码更新或批处理 Shell 脚本正在尝试连贯造成的。在这种状况下，用户存储密钥将受到影响，并且必须应用新密码从新构建。 这种状况会产生在技术用户身上。 ...

常见函数 字符函数数学函数日期函数其余函数【补充】流程管制函数【补充】字符函数大小写管制函数 这类函数扭转字符的大小写。字符管制函数 这类函数控制字符:数字函数 ROUND: 四舍五入TRUNCATE: 截断MOD: 求余日期函数 now：获取以后日期 str_to_date: 将日期格局的字符转换成指定格局的日期STR_TO_DATE('9-13-1999','%m-%d-%Y') 1999-09-13 date_format:将日期转换成字符 DATE_FORMAT(‘2018/6/6’,‘%Y年%m月%d日’) 2018年06月06日条件表达式 在 SQL 语句中应用IF-THEN-ELSE 逻辑应用办法:– CASE 表达式 CASE 表达式 在须要应用IF-THEN-ELSE 逻辑时: CASE expr WHEN comparison_expr1 THEN return_expr1 [WHEN comparison_expr2 THEN return_expr2 WHEN comparison_exprn THEN return_exprn ELSE else_expr] END 练习：查问部门号为 10, 20, 30 的员工信息, 若部门号为 10, 则打印 其工资的 1.1 倍, 20 号部门, 则打印其工资的 1.2 倍, 30 号部门打印 其工资的 1.3 倍数 CASE 表达式 上面是应用case表达式的一个例子： 关键词：java培训

背景对话框在前端开发利用中，是一种十分罕用的界面模式。对话框作为一个独立的窗口，经常被用于信息的展现，输出信息，亦或者更多其余性能。然而我的项目的应用过程中，在某些场景下对话框用起来会有一些麻烦。例如：场景一如果想要在多个子组件（A、B）中管制一个对话框（C）的显示影藏，这个对话框必须在共有的父组件（MySalesOrders）中进行申明。场景二如果须要给对话框（C）传递参数，个别状况咱们会应用 props 传入，意味着状态的治理必须也是子组件（A、B）的父组件或者更高一级进行治理和保护，然而其实这些状态可能只须要在子组件 A 或者 B 中保护。这种状况下，咱们就须要自定义事件，将状态进行回传，比拟麻烦。const MySalesOrders: React.FC = () => { const [visible, setVisible] = React.useState(false); ... return ( <> <A modalVisible={setVisible}/> <B modalVisible={setVisible}/> { visible ? ( <C ... /> ) : null }</>);} const A: React.FC = (props) => { ... return ( <> <Button onClick={() => { props.modalVisible(...) }} /></>);} const B: React.FC = (props) => { ... return ( <> <Button onClick={() => { props.modalVisible(...) }} /></>);}复制代码场景三一个展现的对话框，对话框在不同的模块可能只是提醒文案不一样，须要在不同的中央屡次导入定义。例如零碎中罕用的提醒胜利、提醒失败的对话框。咱们通常会定义一个通用的组件，在父组件中定义，而后应用时唤起，然而如果咱们须要在不同的页面应用，咱们就须要在不同的页面组件中应用引入定义。这些场景都是在我在理论开发中都会用到的，并且这些实现办法其实自身来说都是能够失常应用的，也没有什么问题。然而影藏了几个问题。问题一：难以扩大如果和 MySalesOrders 同级的组件也要拜访这个对话框（C）？又或者， MySalesOrders 上面的某个深层级的孙子组件也要能对话框（C）？前者意味着代码须要重构，持续晋升状态到 MySalesOrders 组件的父组件；后者意味着业务逻辑解决更简单，须要通过层层的自定义事件回调来实现。问题二：保护问题同一个组件，须要在不同的中央屡次的导入定义。在零碎中减少了大量反复的代码。代码很快就会变得臃肿，且难以了解和保护。问题的实质对上诉问题来说，实质在于：在咱们日常的我的项目中应该哪里定义去对话框？又该如何和对话框进行数据交互？ ...

背景在程序员的职业生涯中，总会遇到数据库表被锁的状况，前些天就又撞见一次。因为业务突发需要，各个部门都在批量操作、导出数据，而数据库又未做读写拆散，后果就是：数据库的某张表被锁了！ 用户反馈系统局部性能无奈应用，紧急排查，定位是数据库表被锁，而后进行紧急解决。这篇文章给大家讲讲遇到相似紧急状况的排查及解决过程，倡议点赞珍藏，以备不时之需。 故障追踪用户反馈某性能页面报502谬误，于是第一工夫看服务是否失常，数据库是否失常。在控制台看到数据库CPU飙升，沉积大量未提交事务，局部事务曾经阻塞了很长时间，根本定位是数据库层呈现问题了。 查看阻塞事务列表，发现其中有锁体现象，本想利用控制台间接完结掉阻塞的事务，但控制台账号权限无限，于是通过客户端登录对应账号将锁表事务kill掉，才防止了状况好转。 上面就聊聊，如果当忽然面对相似的状况，咱们该如何紧急响应？ 解决方案设想一个场景，当然也是软件工程师职业生涯中会遇到的一种场景：本来运行失常的程序，某一天忽然数据库的表被锁了，业务无奈失常运行，那么咱们该如何疾速定位是哪个事务锁了表，如何完结对应的事物？ 首先最简略粗犷的形式就是：重启MySQL。对的，网管解决问题的神器——“重启”。至于结果如何，你能不能跑了，要你本人三思而后行了！ 重启是能够解决表被锁的问题的，但针对线上业务很显然不太具备可行性。 上面来看看不必跑路的解决方案： 第一步：查看表应用遇到数据库阻塞问题，首先要查问一下表是否在应用。 show open tables where in_use > 0 ;如果查问后果为空，那么阐明表没在应用，阐明不是锁表的问题。 mysql> show open tables where in_use > 0 ;Empty set (0.00 sec)如果查问后果不为空，比方呈现如下后果： mysql> show open tables where in_use > 0 ;+----------+-------+--------+-------------+| Database | Table | In_use | Name_locked |+----------+-------+--------+-------------+| test | t | 1 | 0 |+----------+-------+--------+-------------+1 row in set (0.00 sec)则阐明表（test）正在被应用，此时须要进一步排查。 第二步：查看过程查看数据库以后的过程，看看是否有慢SQL或被阻塞的线程。 执行命令： show processlist;该命令只显示以后用户正在运行的线程，当然，如果是root用户是能看到所有的。 在上述实际中，阿里云控制台之所以可能查看到所有的线程，猜想应该应用的就是root用户，而笔者去kill的时候，无奈kill掉，是因为登录的用户非root的数据库账号，无奈操作另外一个用户的线程。 第三步：查看以后运行的所有事务如果情况紧急，此步骤能够跳过，次要用来查看核查： SELECT * FROM information_schema.INNODB_TRX;第四步：查看以后呈现的锁如果情况紧急，此步骤能够跳过，次要用来查看核查： ...

提到分区表，个别依照范畴（range）来对数据拆分居多，以哈希来对数据拆分的场景相来说有肯定局限性，不具备标准化。接下来我用几个示例来讲讲 MySQL 哈希分区表的应用场景以及相干革新点。 对于哈希分区表，最艰深的办法就是 hash 单个字段，比方上面表 hash_t1（存有500W行记录），依照自增 ID 来做 HASH ，分区数目为 1024 ： mysql:ytt_new> show create table hash_t1\G*************************** 1. row *************************** Table: hash_t1Create Table: CREATE TABLE `hash_t1` ( `id` bigint unsigned NOT NULL AUTO_INCREMENT, `r1` int DEFAULT NULL, `log_date` date DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=5000001 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci/*!50100 PARTITION BY HASH (`id`)PARTITIONS 1024 */1 row in set (0.00 sec)mysql:ytt_new> select count(*) from hash_t1;+----------+| count(*) |+----------+| 5000000 |+----------+1 row in set (2.43 sec)表 hash_t1 的分区形式很好了解，依照 ID 来对数据进行 HASH 拆分，也就是依照分区数量求模， 相似于 hash(mod(id,1024)) ，数据分布十分平均。 ...

Replication 用来进行 MySQL 数据库之间的高效复制，是构建 MySQL 主备和多主架构的根底能力。PolarDB-X 2.1.0 版本新增兼容 MySQL Replica 相干指令，实现了 MySQL 和 PolarDB-X 之间的数据复制。本期分享将别离演示 PolarDB-X 作为 MySQL 和 PolarDB-X 的备库，并简略介绍背地的技术原理。 PolarDB-X 云原生分布式数据库已在 GitHub 开源，欢送关注：https://github.com/ApsaraDB/g... 直播工夫 5 月 13 号（本周五）16:00～17:00 参加形式 钉钉扫描下图二维码退出 PolarDB-X 开源交换群 讲师介绍 佘志伟(积月) 阿里云 PolarDB-X 云原生分布式数据库高级开发工程师，毕业于南京大学计算机系。2021 年退出 PolarDB-X 团队，次要负责数据迁徙等生态组件研发工作。

1—根本 SELECT 语句*|{[DISTINCT] column|expression [alias],...} table; SELECT 标识抉择哪些列。FROM 标识从哪个表中抉择。抉择全部列 departments; 抉择特定的列 department_id, location_id注 意 SQL 语言大小写不敏感。SQL 能够写在一行或者多行关键字不能被缩写也不能分行各子句个别要分行写。应用缩进进步语句的可读性。列的别名列的别名: 重命名一个列。便于计算。紧跟列名，也能够在列名和别名之间退出关键字 ‘AS’，别名应用双引号，以便在别名中蕴含空格或非凡的字符并辨别大小写。应用别名SELECT last_name AS name, commission_pct comm FROM employees;字符串 字符串能够是 SELECT 列表中的一个字符,数字,日期。日期和字符只能在单引号中呈现。每当返回一行时，字符串被输入一次。显示表构造应用 DESCRIBE 命令，示意表构造DESC[RIBE] tablename DESCRIBE employees2—过滤和排序数据过滤 应用WHERE 子句，将不满足条件的行过滤掉。SELECT *|{[DISTINCT] column|expression [alias],...} FROM table [WHERE condition(s)]; WHERE 子句紧随 FROM 子句。 在查问中过滤行 EMPLOYEES返回在 90号部门工作的所有员工的信息WHERE 子句 SELECT employee_id, last_name, job_id, department_id FROM employees WHERE department_id = 90 ;比拟运算 SELECT last_name, salary FROM employees WHERE salary<= 3000;其它比拟运算BETWEEN ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。[toc] 介绍首先，先介绍一下 Sanitizer 我的项目，该我的项目是谷歌出品的一个开源我的项目，该我的项目蕴含了 ASAN、LSAN、MSAN、TSAN等内存、线程谬误的检测工具，这里简略介绍一下这几个工具的作用： ASAN: 内存谬误检测工具，在编译命令中增加-fsanitize=address启用LSAN: 内存透露检测工具，曾经集成到 ASAN 中，能够通过设置环境变量ASAN_OPTIONS=detect_leaks=0来敞开ASAN上的LSAN，也能够应用-fsanitize=leak编译选项代替-fsanitize=address来敞开ASAN的内存谬误检测，只开启内存透露查看。MSAN: 对程序中未初始化内存读取的检测工具，能够在编译命令中增加-fsanitize=memory -fPIE -pie启用，还能够增加-fsanitize-memory-track-origins选项来追溯到创立内存的地位TSAN: 对线程间数据竞争的检测工具，在编译命令中增加-fsanitize=thread启用其中ASAN就是咱们明天要介绍的重头戏。ASAN，全称 AddressSanitizer，能够用来检测内存问题，例如缓冲区溢出或对悬空指针的非法拜访等。 依据谷歌的工程师介绍 ASAN 曾经在 chromium 我的项目上检测出了300多个潜在的未知bug，而且在应用 ASAN 作为内存谬误检测工具对程序性能损耗也是及其可观的。 依据检测结果显示可能导致性能升高2倍左右，比Valgrind（官网给的数据大略是升高10-50倍）快了一个数量级。 而且相比于Valgrind只能查看到堆内存的越界拜访和悬空指针的拜访，ASAN 不仅能够检测到堆内存的越界和悬空指针的拜访，还能检测到栈和全局对象的越界拜访。 这也是 ASAN 在泛滥内存检测工具的比拟上超群绝伦的重要起因，基本上当初 C/C++ 我的项目都会应用ASAN来保障产品质量，尤其是大我的项目中更为须要。 如何应用 ASAN作为如此弱小的神兵利器，天然是不会在程序员的战场上得宠的。 从LLVM3.1、GCC4.8、XCode7.0、MSVC16.9开始ASAN就曾经成为泛滥支流编译器的内置工具了，因而，要在我的项目中应用ASAN也是非常不便。 当初只须要在编译命令中加上-fsanitize=address检测选项就能够让ASAN在你的我的项目中大展神通，接下来通过几个例子来看一下 ASAN 到底有哪些本事。 留神： 在上面的例子中关上了调试标记-g，这是因为当发现内存谬误时调试符号能够帮忙错误报告更精确的告知谬误产生地位的堆栈信息，如果错误报告中的堆栈信息看起来不太正确，请尝试应用-fno-omit-frame-pointer来改善堆栈信息的生成状况。如果构建代码时，编译和链接阶段离开执行，则必须在编译和链接阶段都增加-fsanitize=address选项。检测内存透露// leak.c#include <stdio.h>#include <stdlib.h>#include <string.h>int main(int argc, const char *argv[]) { char *s = (char*)malloc(100); strcpy(s, "Hello world!"); printf("string is: %s\n", s); return 0;}上述代码中咱们调配了100个字节的内存空间，但在main函数返回前始终没有开释，接下来咱们应用ASAN看一下是否可能检测进去，增加-fsanitize=address -g参数构建代码并执行： ~/Code/test$ gcc noleak.c -o noleak -fsanitize=address -g~/Code/test$ ./leak string is: Hello world!===================================================================1621572==ERROR: LeakSanitizer: detected memory leaks // 1)Direct leak of 100 byte(s) in 1 object(s) allocated from: // 2) #0 0x7f5b986bc808 in __interceptor_malloc ../../../../src/libsanitizer/ASAN/ASAN_malloc_linux.cc:144 #1 0x562d866b5225 in main /home/chenbing/Code/test/leak.c:7 #2 0x7f5b983e1082 in __libc_start_main ../csu/libc-start.c:308SUMMARY: AddressSanitizer: 100 byte(s) leaked in 1 allocation(s).这里，ASAN 提供的报告阐明了谬误起因是detected memory leaks内存透露了1），同时，2)阐明ASAN检测到应用程序调配了100个字节，并捕捉到了内存调配地位的堆栈信息，还通知了咱们内存是在leak.c:7调配的。 ...

MongoDB 是近年来十分风行的一个介于关系数据库和非关系数据库之间的解决方案，采取面向文档的分布式设计思路，具备弱小的可扩展性，表构造自在，并且反对丰盛的查问语句和数据类型。时至今日，MongoDB 以其灵便的数据存储形式，逐步成为 IT 行业十分风行的一种非关系型数据库解决方案。 笔者在我的项目中也经验了从零开始学习 MongoDB 数据库的过程，因而想把我学习过程中的一些心得通过文章分享进去。 步骤1 - MongboDB 环境搭建MongoDB 反对的数据结构十分涣散，是相似 json 的 bson 格局，这种灵便的格局使得 MongoDB 能够存储比较复杂的数据类型。Mongo 最大的特点是它反对的查询语言(Query Language)十分弱小，其语法有点相似于面向对象的查询语言，因而可读性十分好，并且简直能够实现相似关系数据库单表查问的绝大部分性能。 本步骤介绍 MongoDB 学习的第一步：环境搭建。 从 MongoDB 的 官网下载安装包。 我装置在 C 盘的 MyApp 目录下的 mongoDB，装置结束后，bin 文件夹里有好几个执行文件。把 bin 文件门路加到 windows 零碎的环境变量里。 应用如下命令行启动 MongoDB 服务器： mongod --dbpath C:MyAppmongoDBjerryserverdb从控制台打印的 console 里看到下列音讯： Mongo DB starting: pid=16588 port=27017意思是过程 id 为 16588 的过程启动了 MongoDB，监听端口号为 27017. console 里还有其余一些有用的提醒，比方: Read and write access to data and configuration is unrestricted - 没有对数据读写设置权限 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。[toc] 1. 导入本文介绍如何应用 Vagrant 在 VirtualBox 中疾速装置 Linux 虚拟机。本文演示零碎未 Windows 零碎，须要筹备好 Vagrant 和 VirtualBox 2.工具介绍VirtualBox;VirtualBox是一款开源虚拟机软件。开始是由德国Innotek公司开发，由Sun公司出品的软件，在Sun被Oracle收买后正式更名成Oracle VM VirtualBoxVagrant:Vagrant是一个能够应用Oracle的开源VirtualBox虚拟化零碎用于创立和部署虚拟化开发环境的工具。 原理是通过Vagrant提前准备好的镜像来实现疾速的创立，能够拜访镜像仓库：(https://app.vagrantup.com/box...),如下图： 3.通过Vagrant为VirtualBox装置CentOS 7在应用工具之前，先要进行工具的装置，如下： VirtualBox下载：（https://www.virtualbox.org/）Vagrant下载：（https://www.vagrantup.com/dow...）为了验证Vagrant是否装置胜利能够在装置Vagrant的门路下关上cmd窗口输出Vagrant命令会有相干的提示信息，之后就能够应用Vagrant为VirtualBox装置CentOS 7了： 通过init语法为VirtualBox疾速初始化一台虚拟机，init前方指定对应的镜像文件，可参照上文提过的镜像仓库，语法如下：vagrant init centos/7初始化后，Vagrant会在当前目录下创立一个Vagrantfile，达到初始化一个对应镜像的环境，并提醒应用命令Vagrant up来启动这个虚拟环境,该语句会从镜像仓库下载对应的镜像来启动虚拟环境，语句如下：vagrant up启动虚拟环境后VirtualBox中就会蕴含这个初始化的镜像。此外，在启动虚拟环境的同时Vagrant为咱们创立了SSH连贯，因而咱们不仅能够间接通过VirtualBox操作虚构零碎，也能够通过SSH连贯来操作虚构零碎，默认应用的是Vagrant为咱们提供的账号：Vagrant，所以能够通过这种连贯形式以Vagrant的账户连贯虚构零碎，命令如下：vagrant ssh4.总结明天介绍了应用Vagrant在VirtualBox中疾速装置Linux虚拟机。为了方便使用下方列举了Vagrant的常见命令： 命令形容vagrant box add增加box的操作vagrant init初始化box的操作，会生成vagrant的配置文件Vagrantfilevagrant up启动本地虚拟环境vagrant ssh通过ssh登录本地环境所在虚拟机vagrant halt敞开本地虚拟环境vagrant suspend暂停本地虚拟环境vagrant resume复原本地虚拟环境vagrant package打包命令，能够把以后的运行的虚拟机环境进行打包vagrant status获取以后虚拟机的状态vagrant global-status显示以后用户Vagrant的所有环境状态vagrant reload批改了 Vagrantfile 后，使之失效（相当于先 halt，再 up）Enjoy GreatSQL :) 文章举荐：面向金融级利用的GreatSQL正式开源https://mp.weixin.qq.com/s/cI... Changes in GreatSQL 8.0.25 (2021-8-18)https://mp.weixin.qq.com/s/qc... MGR及GreatSQL资源汇总https://mp.weixin.qq.com/s/qX... GreatSQL MGR FAQhttps://mp.weixin.qq.com/s/J6... 在Linux下源码编译装置GreatSQL/MySQLhttps://mp.weixin.qq.com/s/WZ... # 对于 GreatSQL GreatSQL是由万里数据库保护的MySQL分支，专一于晋升MGR可靠性及性能，反对InnoDB并行查问个性，是实用于金融级利用的MySQL分支版本。 Gitee: https://gitee.com/GreatSQL/Gr... GitHub: https://github.com/GreatSQL/G... Bilibili： https://space.bilibili.com/13... ...

一、MySQL 8.0次要新个性 1、性能峰值简直是5.7的两倍 2、可疾速在线新增列——instant add new column 3、可并行写入redo log，晋升大量事务写入时的性能 4、可在线调整redo log buffer和undo log相干设置 5、可针对单个会话SET_VAR设置变量，晋升灵活性 6、新增更多数据字典，元数据全副采纳InnoDB引擎存储，无frm文件 7、自增列长久化，解决了服务重启后自增值回退的问题 8、可在线长久化配置（set persist会生成mysqld.auto.cnf） 9、减少CREATE TABLE ... SELECT的原子性和crash safe反对，解决了MGR架构下无奈应用的问题 10、应用新的明码插件caching_sha2_password（代替本来的mysql_native_password）（客户端须要降级驱动），反对更高的明码策略，即使雷同的明码加密后的密文也是不同的 11、新增角色role性能 12、新增倒排索引、不可见索引 13、重构SQL分析器，加强优化器和CBO个性 14、反对通用表达式、窗口函数，次要用于OLAP场景 15、默认字符集为utf8mb4 16、反对应用shutdown命令间接敞开服务 17、谬误日志减少了不同谬误的谬误编号，不便查问 18、并行复制writeset机制，晋升从库复制性能 19、反对创立零碎级别或者用户级别资源组以限度SQL对服务器资源的占用 二、降级8.0前的筹备 1、先浏览官网What Is New In MySQL 8.0文档，关注被废除的性能，防止配置文件中仍然存在这些历史配置 2、须要思考回滚计划 3、通过先降级从库的形式进行平稳过渡 4、降级前须要关注是否存在关键词兼容问题以及GROUP BY语句兼容问题，能够应用官网的查看工具 Bash mysqlsh root:123456@192.168.1.101:3306 -e "util.checkForServerUpgrade();"5、5.7版本反对间接降级8.0（5.6不反对），降级大版本前倡议先把小版本升级到最新 6、倡议降级形式采纳逻辑备份+导入的形式 三、降级MySQL 8.0步骤 1、敞开以后MySQL 2、备份数据 3、应用新版本二进制包替换原版本 4、更改配置文件 5、启动服务，不须要mysql_upgrade，MySQL 8.0反对通过配置upgrade = AUTO参数来主动解决降级须要做的所有 

【墨天轮最受欢迎的技术文档】系列文章失去了很多敌人的反对，大家也通知了咱们期待看到的主题这不！大家想看的优化系列-SQL优化篇来啦~原文文末送墨值中，欢送大家参加！数据库的调优被分成多个阶段，每个阶段具备不同的调优要点，而高质量、标准SQL的书写却是很多人最后会疏忽的中央，然而在理论运维的过程中，很多数据库运行迟缓、提早、查问性能低乃至宕机等事变、“血案”却可能仅因一条“简略的SQL”导致。 为了助力大家把握更业余的SQL书写、优化能力，咱们整顿了墨天轮社区上一些受欢迎且优质的SQL语句优化原理思路、技术要点和办法实操案例文档，蕴含Oracle、SQL Server、PostgreSQL、MySQL等数据库，欢送大家下载、补充。 SQL优化形式及思路- OracleOracle SQL性能优化40条 从一条 SQL 看基于 Oracle 的 SQL 优化 SQL与性能优化（云和恩墨经典文档） 从 Oracle 的 SQL 优化到 MySQL 的 SQL 优化 Oracle SQL 优化培训(精髓整顿) - SQL Server、PostgreSQL、MySQL 等特地给力的 SQL 优化培训文档（SQL Server） SQL Server SQL 优化指南 PostgreSQL SQL 优化 2.5W字，图文详解 " MySQL 优化" 问题！ MySQL 性能优化-常用命令 基于金仓数据库 KingbaseES 的 SQL 优化 GBase SQL 性能优化分享 案例剖析及优化客户外围数据库CPU 100%问题的解决及 SQL 优化过程 SQL 优化根底思路（1） SQL 优化思路剖析（2） 一条 SQL 引发的“血案”：与 SQL 优化相干的4个案例 SQL 优化 | MySQL 问题解决案例分享三则 ...

HHDBCS工具中的命令窗口可反对SQL执行、SQL文件导入执行和反对导出命名窗口的内容到本地。命名窗口虽和语句窗口性能类似，但更为简略快捷。在命令窗口中也可应用快捷命名唤醒帮忙，快捷窗口则不便大家疾速查找数据库对象。请参看下方视频中的应用操作！社区里还有“Mysql治理系列“其余操作视频：https://dbcs.deskui.com/pages...，欢送拜访！https://www.bilibili.com/vide...

什么是虚构列创立字段时应用 [GENERATED ALWAYS] AS (expr) 通过表达式来生成的字段。虚构列依据是否进行物理存储分为两种类型（VIRTUAL）和 （STORED）。STORED模式在新增和批改时会进行批改和存储。VIRTUAL模式在读取数据时进行计算（在BEFORE触发器后执行）。虚构列如不指定默认为VIRTUAL模式。 虚构列不容许手动输出值援用：http://t.zoukankan.com/nkefww...此文提到一个标准，虚构列通过增加对立前缀v_ ,在团队写作时写入数据时防止sql呈现谬误，一起记录下。 应用场景我用到的场景环境：mysql5.7一张表中存在一个表有text字段存储的json数据，此表中多个类型数据进行混合，json数据key大多不统一然而存在雷同的值。比方：json 数据可能是 {"a":"1"} 也可能是 {"b":"2"} ... 问题：当我读取json中的一个字段进行连贯表的时候，耗时很慢，没有连贯表的时候200毫秒查问500条数据。连贯像这样：from table a left join b on a.json ->> '$.id' = b.id 思考为什么会慢我连贯这个表的时候，须要将文本的字段转换成json对象并进行连贯，相当于连贯之前做了一次运算，并且json的字段不能够走索引。 怎么优化我是通过创立虚构列来实现的，采纳VIRTUAL模式 为什么虚构列会快官网：虚构生成的列能够用作简化和对立查问的一种形式。能够将简单条件定义为生成的列，并从对表进行多个查问，以确保所有查问都应用完全相同的条件。 猜想：而不论是应用哪种模式，都相当于表中的一个字段，相当于把计算过程提前到读取数据，将读取出的值进行连贯表或者其余操作。 其余场景大多是对索引进行函数操作生效或者同json数据的操作怎么创立虚构列col_name data_type [GENERATED ALWAYS] AS (expr) [VIRTUAL | STORED] [NOT NULL | NULL] [UNIQUE [KEY]] [[PRIMARY] KEY] [COMMENT 'string'] example： create table test_virual( id int auto_increment primary key, name varchar(255), age int);# 创立虚构列 将name 和 age字段进行拼接alter table test_virual add column name_age varchar(300) GENERATED ALWAYS AS (concat(name,age)) virtual;# 插入数据insert into test_virual(name, age) values ('tom',13),('rose',16),('jack',19);# 查问数据select * from test_virual;+--+----+---+--------+|id|name|age|name_age|+--+----+---+--------+|1 |tom |13 |tom13 ||2 |rose|16 |rose16 ||3 |jack|19 |jack19 |+--+----+---+--------+# 验证virtual是否反对索引create index v_idx on test_virual(name_age);explain select * from test_virual where name_age like 't%';+--+-----------+-----------+----------+-----+-------------+-----+-------+----+----+--------+-----------+|id|select_type|table |partitions|type |possible_keys|key |key_len|ref |rows|filtered|Extra |+--+-----------+-----------+----------+-----+-------------+-----+-------+----+----+--------+-----------+|1 |SIMPLE |test_virual|NULL |range|v_idx |v_idx|1203 |NULL|1 |100 |Using where|+--+-----------+-----------+----------+-----+-------------+-----+-------+----+----+--------+-----------+# 验证virtual是否反对联结索引create index v_idx_combo on test_virual(name_age,age);explain select * from test_virual where name_age like 't%' and age = 13;+--+-----------+-----------+----------+-----+-------------+-----------+-------+----+----+--------+-----------+|id|select_type|table |partitions|type |possible_keys|key |key_len|ref |rows|filtered|Extra |+--+-----------+-----------+----------+-----+-------------+-----------+-------+----+----+--------+-----------+|1 |SIMPLE |test_virual|NULL |range|v_idx_combo |v_idx_combo|1208 |NULL|1 |33.33 |Using where|+--+-----------+-----------+----------+-----+-------------+-----------+-------+----+----+--------+-----------+参考：mysql 创立表和字段https://dev.mysql.com/doc/ref...mysql 创立辅助索引https://dev.mysql.com/doc/ref... ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。[toc] 一、问题发现在一次开发中应用 MySQL PREPARE 当前，从 prepare 间接取 name 赋值给 lex->prepared_stmt_name 而后给 EXECUTE 用，发现有肯定概率找不到 prepare stmt 的 name，于是开始入手考察问题产生的起因。 SQL语句示例： CREATE TABLE t1 (a INT, b VARCHAR(10));PREPARE dbms_sql_stmt4 FROM 'INSERT INTO t1 VALUES (1,''11'')';EXECUTE dbms_sql_stmt4;报错：SQL Error [1243] [HY000]: Unknown prepared statement handler (dbms_sql_stmt4??p??]UU) given to EXECUTE二、问题调查过程1、依据报错信息找到对应源码，发现在MySQL_sql_stmt_execute外面有判断当找不到 stmt name 时候报错信息。 这里的 name 此时曾经是乱码了。 void MySQL_sql_stmt_execute(THD *thd) { LEX *lex = thd->lex; const LEX_CSTRING &name = lex->prepared_stmt_name; DBUG_TRACE; DBUG_PRINT("info", ("EXECUTE: %.*s\n", (int)name.length, name.str)); Prepared_statement *stmt; if (!(stmt = thd->stmt_map.find_by_name(name))) { my_error(ER_UNKNOWN_STMT_HANDLER, MYF(0), static_cast<int>(name.length), name.str, "EXECUTE"); return; }2、这个 lex->prepared_stmt_name 是从 prepare name 中赋值的，于是考察 prepare 这个 name 设置的函数。 ...

度过了欢快的五一假期，MySQL系列也陆续推出了系列四之“查问窗口的应用‘’,应用HHDBCS工具通过语句窗口来执行SQL，如格式化sql、查问剖析，对表格进行查问、新增、批改、删除等。欢送参看下方视频中的操作！社区里还有“Mysql治理系列“其余操作视频：https://dbcs.deskui.com/pages...，欢送拜访！https://www.bilibili.com/vide...

为了帮忙各位朋友应用HHDBCS时能疾速进行对象治理，社区会陆续推出数据库治理上手系列，请参考如下的“Mysql治理系列之——03、对象治理”。社区里还有“Mysql治理系列“其余操作视频：https://dbcs.deskui.com/pages...，欢送拜访！https://www.bilibili.com/vide...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。[toc] 个别节点可能存在事务抵触，导致无奈退出MGR集群，该怎么解决？1. 问题场景形容有些时候，可能因为网络分区等异常情况导致节点意外退出MGR集群，在退出之前可能有些事务还没来得及发送到其余节点。或者可能因为误操作，在这个节点上意外写入数据。那么这个节点重退出MGR集群时，就可能会报告相似上面的谬误： [ERROR] [MY-011526] ... This member has more executed transactions than those present in the group. Local transactions: xx:1-300917674 > Group transactions: xx:1-300917669[ERROR] [MY-011522] ... The member contains transactions not present in the group. The member will now exit the group.'这段日志的意思是，本地节点的事务GTID为 1-300917674，而欲退出的MGR集群的事务GTID是 1-300917669，本地节点多了5个事务，因而无奈正确退出。 2. 如何修复遇到这种报错不要慌，咱们一起来看下怎么解决。大抵能够分为X步走。 2.1 找出事务差别点首先，依据报错日志，找出本地节点绝对于MGR集群多进去的或有差别的事务。在本案中，本地节点多了5个事务，利用mysqlbinlog来看这些事务都波及到哪些数据对象： # -vvv, 打印更多冗余信息，不便排查# --base64-output=decode-rows，进行base64解码# --include-gtids=，指定要蕴含的GTID范畴$ mysqlbinlog -vvv --base64-output=decode-rows --include-gtids="0d432272-bddf-11ec-82a9-d08e7908bcb1:300917669-300917674" mgr03.000003 > diff-trxs.sql接下来就能够对解析进去的SQL文件进行查看，判断影响了哪些数据对象，以及具体哪些数据。 此时，如果MySQL曾经设置了 binlog_rows_query_log_events = ON*（这个选项默认值是 OFF，倡议改成开启），则binlog里还会记录原始SQL语句，更不便排查了，例如这样： SET @@SESSION.GTID_NEXT= '0d432272-bddf-11ec-82a9-d08e7908bcb1:300917669'/*!*/;# at 1412#220419 16:43:37 server id 3308 end_log_pos 1494 CRC32 0xe0bed25b Query thread_id=93 exec_time=0 error_code=0SET TIMESTAMP=1650357817/*!*/;BEGIN/*!*/;# at 1494#220419 16:43:37 server id 3308 end_log_pos 1541 CRC32 0xc3635e5d Rows_query# insert into t1 select 4 <-- 这里是原始SQL语句# at 1541#220419 16:43:37 server id 3308 end_log_pos 1591 CRC32 0x3e190d83 Table_map: `sbtest`.`t1` mapped to number 129# at 1591#220419 16:43:37 server id 3308 end_log_pos 1631 CRC32 0x890bd335 Write_rows: table id 129 flags: STMT_END_F### INSERT INTO `sbtest`.`t1`### SET### @1=4 /* INT meta=0 nullable=0 is_null=0 */# at 1631#220419 16:43:37 server id 3308 end_log_pos 1662 CRC32 0x53c6a05a Xid = 267COMMIT/*!*/;2.2 决定如何解决当初曾经晓得本地节点和MGR集群相差了哪些数据，就须要进行抉择了，看看是要舍弃这些事务数据，还是人工补差。 ...

数据库工具类通过学习咱们晓得,连贯一个数据库很麻烦,代码很多,而且像注册驱动这些代码咱们在我的项目的启动后只须要执行一次。所以咱们能不能写一个数据库连贯的工具类嘞? ** * @program: Dream * @description: 数据库工具类 * @author: stop.yc * @create: 2022-03-18 10:57 **/public class DbUtil { private static String driver = null; private static String url = null; private static String username = null; private static String password = null; /*配置信息,程序运行后,只有一次,就不会扭转了,而后驱动加载也只须要一次,那么就是用动态代码块,程序运行后,运行一次*/ static { try { //通过字节输出流,获取文件中的配置信息. InputStream in = DbUtil.class.getClassLoader().getResourceAsStream("db.properties"); //文件加载 Properties properties = new Properties(); properties.load(in); //获取 driver = properties.getProperty("driver"); url = properties.getProperty("url"); username = properties.getProperty("username"); password = properties.getProperty("password"); //加载驱动(如果在这里呈现NPE的话,看看是不是没有导入连贯jar包) Class.forName(driver); } catch (Exception e) { e.printStackTrace(); } } //内部调用获取连贯办法,被CRUD工具类调用 public static Connection getCon() throws Exception { return DriverManager.getConnection(url,username,password); } //内部调用敞开办法.被CRUD工具类调用 public static void close(Connection con,PreparedStatement ps,ResultSet rs) { if(rs!=null) { try { rs.close(); } catch (SQLException e) { e.printStackTrace(); } } if(ps!=null) { try { ps.close(); } catch (SQLException e) { e.printStackTrace(); } } if(con!=null) { try { con.close(); } catch (SQLException e) { e.printStackTrace(); } } }}//包同级目录下,新建一个文件,db.properties,内容如下:driver=com.mysql.jdbc.Driver#db——dream为你的项目名称url=jdbc:mysql://localhost:3306/db_dream?useUnicode=true&characterEncoding=utf8&useSSL=false#数据库的账号密码username=usernamepassword=password 对于CRUD工具类,就请到另一篇文章看看,顺便学习一下CRUD的封装 ...

小白升级巨匠第1篇文章，开始写一些有深度的文章了 先举荐一个数据结构可视化工具网站，用于B+树可视化查看 Data Structure Visualizations 面试技术岗的时候，面试官问你： mysql索引底层用的是B+树结构，为什么不必B树、二叉树、红黑树呢？这里其实就是比拟各种数据结构的优劣点，最初阐明为什么要用B+树结构； 假如数据查问场景：当初有100W的数据存储，查问其中的一条，应该用哪种存储构造呢？ 二叉查找树二叉查找树即有序二叉树，满足二叉树的性质，具备上面特点： 任意节点左子树不为空时，左子树值小于根节点值右子树不为空时，右子树值大于根节点值；顺次存入数据，如果数据是递增的，则原二叉树进化为链表构造，如图 这种状况下，查问的工夫复杂度就是O(n)了 AVL树AVL树即均衡二叉查找树，通过均衡因子差值判断是否均衡，再用旋转来实现树的均衡。左右子树的树高差不超过1。在执行插入删除操作时，对不满足条件的子树，通过旋转保持平衡。性能开销次要在旋转操作上，由此能够晓得AVL树适宜查问多，插入删除少的场景 如图，我创立了一棵AVL树，感兴趣的能够在网站上看一下插入过程和旋转调整均衡的过程。 AVL树须要维持树的均衡，而保护这种均衡的开销要大于取得的收益，理论利用中不多 红黑树红黑树是一种二叉查找树，每个节点新增一个存储位标记是red或black，通过任何一条从根节点到叶子节点门路上，各个节点着色形式的限度，确保没有一条门路比其余门路长2倍，红黑树性质： 根节点是彩色，每个节点非红即黑；叶子节点都是彩色如果一个节点是红色，那它的子节点都是彩色任意节点到叶子节点的门路都蕴含雷同数目的彩色节点如图是红黑树的可视化： AVL树和红黑树一样，随着记录数的减少，树的高度会一直减少，查问次数也会减少。 文章结尾咱们说的要查问100w条数据中的一条，就须要20次搜寻，搜寻效率不高，查问次数剖析如下 $$2^{20} = 1048576$$ B-树即B树，和红黑树相比，B树的树高远远小于红黑树的高度。B树是为了和磁盘交互而设计的均衡多路查找树，操作效率有磁盘的拜访次数决定，树高越小，磁盘I/O工夫越短。 B树性质： 非叶子节点上最多有M个子节点，且M>2；根节点的子节点数目为[2, M]；每个节点寄存至多M/2-1，至少M-1个关键字非叶子节点关键字数目=指向子节点的指针个数-1；所有叶子节点位于同一层 比照红黑树能够发现，每个节点上能够存储更多的数据，且树高固定，数据插入之后横向扩大。即每一次查问只须要搜寻3次就行。搜寻效率大大提高了。接着咱们再来看看B+树 B+树说一下B+树的性质： 非叶子节点的子树指针 和 关键字 个数一样；非叶子节点的子树指针，指向闭区间[k[i], k[i+1]]，即B树不容许关键字反复，B+树容许为所有叶子节点减少一个链指针；非叶子节点作为索引，叶子节点才存储关键字所有关键字存储在叶子节点 B+树比起B树的长处有： 只在叶子节点存储数据，16k的内存能够存下更多数据，升高树高冗余索引，不便查找；B+树叶子节点减少了双向链表，不便范畴查问；于是，回到结尾的问题，100W的数据，B+树只须要3次或4次I/O查问就能定位到了，且相比拟B树，B+树更适宜简单的查问场景，如范畴查问。

背景生产环境，文件表file表全表误更，零碎中所有的图片全副展现成为张三的身份证侧面照，间接导致审核中的单子不能失常进行。 数据恢复思路生产环境每天凌晨1点对数据库进行全量备份，应用最近一次全量备份 + 增量binlog来对表数据进行复原。 操作误更新操作产生在2021.11.11 18:10:00左右，取相干的文件进行操作 获取最近一次的数据库全量备份，如：finance.2021.11.11.sql获取2021.11.11这天在2021.11.11 01:00:00 到 2021.11.11 18:20:00（把误更新操作工夫点蕴含进去）之间所有的binlog日志，如：mysql-binlog.000032找台装置有mysql数据库（最好版本和生产环境统一）的测试服务器，新建一个空的数据库，将数据库备份文件finance.2021.11.11.sql执行在测试服务器上执行如下命令，将binlog日志重定向至32.txt文本，关上32.txt文件，依照误更新的sql语句关键字找到误更数据的具体工夫点，比方：2021.11.11 18:10:20mysqlbinlog --no-defaults mysql-bin.000032 >32.txt将mysql-bin.000032日志转换为mysql可辨认语句，应用命令：mysqlbinlog --no-defaults --database=finance --start-datetime='2018-09-11 10:48:53' --stop-datetime='2018-09-11 10:49:24' mysql-bin.000032 >temp20211111.sql在测试库执行temp20211111.sql文件，数据就复原到了误更新前的正确数据source temp20211111.sql; 因为生产环境file表只新增，所以把测试库中已复原正确数据的file表重命名为file_copy表，而后导入到生产环境，将生产环境此时file表中绝对file_copy表中的新增数据写入到file_copy表，而后对file表和file_copy名称调换rename table file to file_to_be_droppd, file_copy to file;插曲从数据库备份中导出单个表进行复原，查看并过滤，执行命令： cat finance.2021.11.11.sql | grep "Table structure for table"|more解决方案：A和B表之间的表的区间，就等于取A表 awk '/-- Table structure for table `table_A`/,/-- Table structure for table `table_B`/{print}' db.sql >>db_table_A_temp.sql将A表重定向到一个长期表“temp.sql”，独自复原这张A表

背景业务库中有三张表数据量比拟大，别离是cloud_box_event_state（事件信息表）、cloud_box_workhour（工时汇总表）、cloud_box_workhour_detail（工时明细表），随着业务倒退数据量还在减少，这些表用于存储智能硬件上报的事件信息，以及记录装置了智能硬件的设施的工作时长等。因为这三张大表的存在，业务库存储空间曾经吃紧，另外智能硬件高并发申请给业务库也造成了肯定的压力。因而，业务库曾经呈现响应变慢，甚至主从提早的问题，主从提早对业务零碎影响比拟大，这几张大表引发进去的问题须要亟待解决，须要对业务库进行优化。 分库为了应答高并发申请给业务库造成的压力，须要把事件信息和设施工时信息相干的业务表从业务数据库拆分进来，新建一个数据库进行数据存储与解决。从原来的数据库cloudbox中把三张大表cloud_box_event_state、cloud_box_workhour和cloud_box_workhour_detail拆分进去，放在cloudbox_data数据库中。此时先不要从cloudbox业务库中删除三张大表，拆分示意图如下： 多数据源应用sharding-jdbc组件创立和治理多数据源，利用中生成两个数据源，别离是dataSource和cloudboxDataSource，其中dataSource用来拜访cloudbox库，cloudboxDataSource用来拜访cloudbox_data库。基于sharding-jdbc加载与创立cloudboxDataSource数据源的代码如下： @Configurationpublic class SpringBootShardingJdbcConfiguration implements EnvironmentAware { private static Logger logger = LoggerFactory.getLogger(SpringBootShardingJdbcConfiguration.class); private Environment environment; private final String MASTER_SLAVE_PREFIX = "cloudboxdata.sharding.jdbc.config.masterslave"; private final String SHARDING_RULE = "cloudboxdata.sharding.jdbc.config"; private final String DATASOURCE_PREFIX = "cloudboxdata.sharding.jdbc.datasource."; @Bean @ConfigurationProperties(prefix = MASTER_SLAVE_PREFIX) public YamlMasterSlaveRuleConfiguration cloudBoxDataMasterSlaveProperties() { return new YamlMasterSlaveRuleConfiguration(); } @Bean @ConfigurationProperties(prefix = SHARDING_RULE) public YamlShardingRuleConfiguration cloudBoxDataShardingProperties() { return new YamlShardingRuleConfiguration(); } @Bean public CloudBoxDataSourceFactory cloudBoxDataSourceFactory() { CloudBoxDataSourceFactory cloudBoxDataSourceFactory = new CloudBoxDataSourceFactory(); try { cloudBoxDataSourceFactory.setCloudBoxDataSource(getCloudBoxDataSource()); } catch (SQLException e) { logger.error("initialize CloudBoxDataSourceFactory error", e); } return cloudBoxDataSourceFactory; } private DataSource getCloudBoxDataSource() throws SQLException { return Objects.isNull(cloudBoxDataMasterSlaveProperties().getMasterDataSourceName()) ? ShardingDataSourceFactory.createDataSource(getDataSourceMap(DATASOURCE_PREFIX), cloudBoxDataShardingProperties().getShardingRuleConfiguration(), cloudBoxDataShardingProperties().getConfigMap(), cloudBoxDataShardingProperties().getProps()) : MasterSlaveDataSourceFactory.createDataSource(getDataSourceMap(DATASOURCE_PREFIX), cloudBoxDataMasterSlaveProperties().getMasterSlaveRuleConfiguration(), cloudBoxDataMasterSlaveProperties().getConfigMap(), cloudBoxDataMasterSlaveProperties().getProps()); } private Map<String, DataSource> getDataSourceMap(String prefix) { Map<String, DataSource> dataSourceMap = new LinkedHashMap<>(); String dataSources = environment.getProperty(prefix + "names"); for (String each : dataSources.split(",")) { try { Map<String, Object> dataSourceProps = PropertyUtil.handle(environment, prefix + each, Map.class); Preconditions.checkState(!dataSourceProps.isEmpty(), "Wrong datasource properties!"); DataSource dataSource = DataSourceUtil.getDataSource(dataSourceProps.get("type").toString(), dataSourceProps); dataSourceMap.put(each, dataSource); } catch (final ReflectiveOperationException ex) { throw new ShardingException("Can't find datasource type!", ex); } } return dataSourceMap; } @Override public final void setEnvironment(final Environment environment) { this.environment = environment; }}测试利用中可能失常的通过cloudboxDataSource数据源操作和拜访cloudbox_data数据库中的表。 ...

热衷学习，热衷生存！ 积淀、分享、成长，让本人和别人都能有所播种！ 一、一致性非锁定读对于一致性非锁定度的实现，通常的形式是加一个版本号或者工夫戳，在更新数据的时候版本号+1或者更新工夫戳。查问时，将以后可见的版本号与对应记录的版本号做比照，如果记录的版本号小于可见版本，则示意该记录可见。 在InnoDB存储引擎中，多版本控制就是对一致性非锁定读的实现。如果读取的行正在执行delete或者update操作，这时候读取操作不会去期待行开释锁，而是会去读取行的一个快照数据，对于这种读取历史数据的形式，叫做快照度。 在可反复读和读取已提交两个隔离级别下，如果是执行一般的select语句（不包含select ... lock in share mode, select ... for update）则会应用一致性非锁定读。 并且在可反复读下 MVCC 实现了可反复读和避免局部幻读。 二、锁定读（以后读）如果执行的是上面语句，就是锁定读。 select ... lock in share modeselect ... for updateinsert、update、delete操作在锁定读下，读取的是数据的最新版本，这种读也被称为以后读。锁定读会对读取到的记录加锁： select ... lock in share mode：对记录加S锁，其余事务也能够加S锁，如果加X锁则会被阻塞。select ... for update、insert、update、delete：对记录加X锁，且其余事务不能加任何锁。在一致性非锁定读下，即便读取的数据曾经被其它事务加上了X锁，记录也是能够被读取的，读取的是快照数据。下面说了在可反复读隔离级别下MVCC避免了局部幻读，这个局部是指在一致性锁定读状况下，只能读取到第一次查问之前插入的数据（依据Read View判断数据可见性，Read View在第一次查问时生成）。然而如果是以后读，每次读取的都是最新数据，这个如果两次查问两头有其余事物插入数据就能够产生幻读。所以InnoDB在可重读时，如果以后执行的是以后读，则会对读取的记录应用Next-Key Lock，来避免其余事物在间隙间插入数据。 快照读和以后读栗子开启A和B两个会话。 首先在A会话中查问user_id = 1的user_name的记录： begin;select user_name from t_user where user_id = 1;查问进去的后果是：user_name = '张三'。 而后再B会话对user_id = 1的user_name进行批改： update t_user set user_name = '李四' where user_id = 1;而后再回到A会话持续做查问操作： select user_name from t_user where user_id = 1;select user_name from t_user where user_id = 1 for update;select user_name from t_user where user_id = 1 lock in share mode;三条数据查问进去的后果别离是：user_name = '张三'、user_name = '李四'、user_name = '李四' ...

集体创作公约：自己申明创作的所有文章皆为本人原创，如果有参考任何文章的中央，会标注进去，如果有疏漏，欢送大家批评。如果大家发现网上有剽窃本文章的，欢送举报，并且踊跃向这个 github 仓库 提交 issue，谢谢反对~ 本文是“为什么我倡议”系列第三篇，本系列中会针对一些在高并发场景下，我对于组内后盾开发的一些开发倡议以及开发标准的要求进行阐明和剖析解读，置信能让各位在面对高并发业务的时候避开一些坑。往期回顾： 为什么我倡议在简单然而性能要害的表上所有查问都加上 force index为什么我倡议线上高并发量的日志输入的时候不能带有代码地位个别当初对于业务要查问的数据量以及要放弃的并发量高于肯定配置的单实例 MySQL 的极限的状况，都会采取分库分表的计划解决。当然，当初也有很多 new SQL 的分布式数据库的解决方案，如果你用的是 MySQL，那么你能够思考 TiDB（实现了 MySQL 协定，兼容 MySQL 客户端以及 SQL 语句）。如果你用的是的 PgSQL，那么你能够思考应用 YugaByteDB（实现了 PgSQL 协定，兼容 PgSQL 客户端以及 SQL 语句），他们目前都有本人的云部署解决方案，你能够试试： TiDB CloudYugaByte Cloud然而对于传统分库分表的我的项目，底层的数据库还是基于 MySQL 以及 PgSQL 这样的传统关系型数据库。个别在业务刚开始的时候，会思考依照某个分片键多分一些表，例如订单表，咱们预计用户间接要查的订单记录是最近一年内的。如果是一年前的，提供其余入口去查，这时候查的就不是有业务数据库了，而是归档数据库，例如 HBase 这样的。例如咱们预计一年内用户订单，最多不会超过 10 亿，更新的并发 TPS （非查问 QPS）不会超过 10 万/s。那么咱们能够思考分成 64 张表（个数最好是 2^n，因为 2^n 取余数 = 对 2^n - 1 取与运算，缩小分片键运算量）。而后咱们还会定时的归档掉一年前的数据，应用相似于 delete from table 这样的语句进行“彻底删除”（留神这里是引号的删除）。这样保障业务表的数据量级始终维持在 然而，日久天长当前，会发现，某些带分片键（这里就是用户 id）的一般查问，也会有些慢，有些走错本地索引。 查问越来越慢的起因例如这个 SQL： select * from t_pay_recordWHERE(( user_id = 'user_id1' AND is_del = 0 )) ORDER BY id DESC LIMIT 20这个表的分片键就是 user_id ...

最近须要应用mysql8.0版本，然而本来的mysql5.7版本曾经被多个服务依赖，于是想想能不能同一台服务器装多个版本的mysql，一查的确可行，这里做一个记录不便本人前期回顾 浏览本文前请留神！！！本文是帮忙您建设在mysql5.7版本曾经装置实现并在运行中，另外装置配置mysql8.0版本如果须要同时装置两个版本，能够先查阅我之前所写对于mysql5.7版本的装置，实现后再按本文持续操作即可装置环境CentOS7 + MySQL8.0 下载安装包点击进入MySQL Community Server 8.0.29 官网下载地址点击下拉抉择 Linux - Generic，找到名为 mysql-8.0.29-linux-glibc2.12-x86_64.tar.xz 点击下载即可简化版命令步骤给我本人的揭示：原来的mysql5.7配置根本没有动，服务也没无关，上面的命令都是对于mysql8.0的，原mysql5.7的配置文件在/etc/my.cnf 解压xz文件为tar文件，留神命令无过程显示须要期待窗口跳至下一行 xz -d /usr/soft/sort/mysql-8.0.29-linux-glibc2.12-x86_64.tar.xz -C /usr/soft/sort/tar -xvf /usr/soft/sort/mysql-8.0.29-linux-glibc2.12-x86_64.tar -C /usr/soft/install/赋予权限 chown -R mysql.mysql /usr/soft/install/mysql-8.0.29-linux-glibc2.12-x86_64批改配置文件 vi /usr/soft/install/mysql-8.0.29-linux-glibc2.12-x86_64/my.cnf [client]port=3307# mysql57 不要这个mysqlx_port=33070socket=/tmp/mysql80.sock# mysql57 不要这个mysqlx_socket=/tmp/mysqlx80.sock[mysqld]# skip-grant-tables# mysql装置目录basedir=/usr/soft/install/mysql-8.0.29-linux-glibc2.12-x86_64# mysql数据库目录datadir=/usr/soft/install/mysql-8.0.29-linux-glibc2.12-x86_64/dataport=3307innodb_file_per_table=1character-set-server=utf8# mysql57 不要这个mysqlx_port=33070socket = /tmp/mysql80.sock# mysql57 不要这个mysqlx_socket=/tmp/mysqlx80.sock[mysqld_safe]# 谬误日志log-error=/usr/soft/install/mysql-8.0.29-linux-glibc2.12-x86_64/data/error.log# pid文件pid-file=/usr/soft/install/mysql-8.0.29-linux-glibc2.12-x86_64/data/mysqld.pidtmpdir=/tmp/mysql80赋予配置文件权限 chmod 755 /usr/soft/install/mysql-8.0.29-linux-glibc2.12-x86_64/my.cnf批改连贯服务文件 vi /usr/soft/install/mysql-8.0.29-linux-glibc2.12-x86_64/support-files/mysql.server # 这两项在结尾比拟好找basedir=/usr/soft/install/mysql-8.0.29-linux-glibc2.12-x86_64datadir=/usr/soft/install/mysql-8.0.29-linux-glibc2.12-x86_64/data# 这项默认的不必找lockdir='/var/lock/subsys'# 这项默认有然而须要在最初改个80lock_file_path="$lockdir/mysql80"# 上面两个藏在上面仔细的找一下mysqld_pid_file_path=/usr/soft/install/mysql-8.0.29-linux-glibc2.12-x86_64/data/mysqld.pidconf=/usr/soft/install/mysql-8.0.29-linux-glibc2.12-x86_64/my.cnf复制注册连贯服务文件 cp -i /usr/soft/install/mysql-8.0.29-linux-glibc2.12-x86_64/support-files/mysql.server /etc/init.d/mysql80初始化mysql80 /usr/soft/install/mysql-8.0.29-linux-glibc2.12-x86_64/bin/mysqld --defaults-file=/usr/soft/install/mysql-8.0.29-linux-glibc2.12-x86_64/my.cnf --user=mysql --initialize root@localhost: 初始密码启动mysql80服务 service mysql80 start，而后要记得凋谢防火墙的3307端口能力应用内部连贯登录 /usr/soft/install/mysql-8.0.29-linux-glibc2.12-x86_64/bin/mysql --socket=/tmp/mysql80.sock -u root -p'初始密码'重置明码，登录后顺次执行命令 ...

一、前言SQL 最弱小的性能之一就是能在数据检索查问的执行中联结表。联结是利用 SQL 的 SELECT 执行的最重要的操作，很好地了解联结及其语法是学习 SQL 的一个极为重要的组成部分。 二、E-R 图与班级学生表E-R 图如下：学生表如下，如果学生曾经调配了班级，class_id 列则为调配班级的编号，否则为 NULL（意为未调配）：班级表如下： 三、内联结内联结将两个表中满足指定联结条件的记录联结成新的后果集，并舍弃所有不满足联结条件的记录。（一）两个表之间的联结语法： SELECT ... FROM tb_1 INNER JOIN tb_2 ON tb_1.f_1 = tb_2.f_1;// 1. tb_1 INNER JOIN tb_2 意为 tb_1 内联 tb_2，INNER 可省略：tb_1 JOIN tb_2。// 2. ON 前面接的是联结条件。例子：如果我要查看所有曾经调配班级的学生信息，以及对应的班级信息。 SELECT student_id, student_no, student_name, class_no, class_name FROM students AS s JOIN classes AS c ON s.class_id = c.class_id; 后果如下： （二）多个表的联结SQL 对一条 SELECT 语句中能够联结的表的数目没有限度。语法： SELECT ...FROM tb_1,tb_2,tb_3WHERR tb_1.f_1 = tb_2.f_1 AND tb_1.f_1 = tb_3.f_1;四、外联结（1）左联结左表的行肯定会列出，右表如果没有匹配的行，那么列值就为null 。特地须要留神的是如果右表有多行和左表匹配，那么左表雷同的行会呈现屡次。语法： ...

一、根本用法（一）通式S Fs F W? (G (H)?)? O? L?; // 问号借用了正则表达式的含意：// 呈现 0 次或者 1 次。（二）通式组成(1) S：SELECT， 必须应用。 (2) Fs：fields，列或者字段，下文第二节会具体阐明。 (3) F: FROM，从中检索的数据表，必须应用。 (4) W：WHERE，用于行级过滤，也能够了解为限定条件。 当只有单个条件时，应用根本的操作符就能够实现过滤。根本操作符如下表： 查看操作符查看单个值$=、 <、 <=、 >、 >=$不匹配查看!=、<>范畴查看BETWEEN a AND b空值查看IS NULL当有多个条件时，须要应用 AND、OR、IN、NOT 等操作符来连贯多个条件。具体如下表： 操作符性能AND用来批示检索满足所有给定条件的行OR用来批示检索满足任一给定条件的行IN用来指定要匹配值的清单的关键字，性能有 OR 相当。NOT取反，MySQL 反对应用NOT 对 IN、BETWEEN 和 EXISTS 子句取反当条件不确定时，则须要应用通配符进行含糊查问。具体如下表： 通配符形容例子%示意任意字符呈现任意次数，相似于正则表达式中的 .*查找姓张的同学 LIKE name='张%'_（下划线）只匹配单个字符，相似于正则表达式中的 .（点）查找李姓单名的同学 LIKE name='李_'(5) G：GROUP BY，数据分组，用来获取数据表中以分组字段为根据的统计数据。比拟常见的是对单个字段进行分组，事实上，还能够对多个字段进行分组（昨天晚上的口试中就有一道须要对多个字段进行分组的题目）。 语法：GROUP BY field_1(,field_2,...,field_n)性能：将具备雷同 field_1(,field_2,...,field_n)字段的记录放到一个分组中。(6) H：HAVING，过滤分组。须要一提的是 HAVING 和 WHERE 的区别：WHERE 在数据分组前进行过滤，HAVING 在数据分组后进行过滤。 (7) O: ORDER BY，排序。与 GROUP 相似，sql反对多个字段进行order by排序，各字段之间用逗号”,”隔开。如： ...

一、什么是事务？事务是逻辑上的一组操作，要么全执行，要么全不执行。 事务最经典栗子也常常被拿进去的栗子就是银行转账了。比方小明要给小红转账1000元，这个转账会波及到两个要害操作：将小明的余额减1000元，将小红的余额减1000元。万一这两个操作之间忽然呈现谬误，导致小明余额缩小然而小红余额没有减少，这种状况是必定不容许的。事务就是保障这两个要害操作要么都胜利，要么都不胜利。 二、事务的个性（ACID） 原子性：事务最小的执行单位，不容许宰割。事务的原子性确保动作要么全副执行，要么全副不执行。一致性：执行事务的前后，数据保持一致。例如转账的业务中，无论事务是否胜利，转账者和收款人的总额应该是不变的。隔离性：并发拜访数据库时，一个用户的事务不应该被其余事务所影响，各并发事务之间数据库是独立的。持久性：一个事务被提交后，它对数据库中数据的扭转是长久的，即便数据库产生故障也不应该对其有影响。三、并发事务带来的问题在典型的应用程序中，多个事务并发运行，常常会操作雷同的数据来实现各自的工作（多个用户对同一数据进行操作）。并发尽管是必须的，然而可能会带来以下的问题： 脏读（Dirty read）：当一个事务正在拜访数据并且对其进行了批改，然而还没提交事务，这时另外一个事务也拜访了这个数据，而后应用了这个数据，因为这个数据的批改还没提交到数据库，所以另外一个事务读取的数据就是“脏数据”，这种行为就是“脏读”，根据“脏数据”所做的操作可能是会呈现问题的。批改失落（Lost of modify）：是指一个事务读取一个数据时，另外一个数据也拜访了该数据，那么在第一个事务批改了这个数据之后，第二个事务也批改了这个数据。这样第一个事务内的批改后果就被失落，这种状况就被称为批改失落。例如：事务1读取表中数据A=20，事务2也读取A=20，事务1批改A=A-1，事务2也批改A=A-1，最终后果都是19，然而事务1的批改记录失落了。不可反复读（Unrepeatableread）：指在一个事务内屡次读取同一数据，在这个事务还没完结时，另外一个事务也拜访了这个数据并对这个数据进行了批改，那么就可能造成第一个事务两次读取的数据不统一，这种状况就被称为不可反复读。幻读（Phantom read）：幻读与不可反复读相似，幻读是指一个事务读取了几行数据，这个事务还没完结，接着另外一个事务插入了一些数据，在随后的查问中，第一个事务读取到的数据就会比本来读取到的多，就如同产生了幻觉一样，所以称为幻读。不可反复读和幻读区别：不可反复读的重点是批改，幻读的重点是新增或者删除。 栗子1（同样的条件，你读取过的数据，再次读取的时候不一样了）：事务1中的A学生读取本人的工资是1000的操作还没完结，事务2的B学生就批改了A学生的工资为2000，A学生再次读取本人工资的时候就变成2000了，这就是不可反复读。 栗子2（同样的条件，第1次和第2次读取进去的记录条数不一样）：如果某工资表中工资大于3000的有4人，事务1读取了所有工资大于3000的人，总共查问到4条记录，这是事务2又查问了一条工资大于3000的记录，事务1再次读取查问到的记录就是5条了，这就是幻读。 四、事务隔离级别SQL规范定义了四个隔离级别： 读取未提交（READ-UNCOMMITTED）：最低的隔离级别，容许读取尚未提交的数据变更，可能造成脏读、不可反复读、幻读。读取已提交（READ-COMMITTED）：容许读取并发事务曾经提交的数据，能够防止脏读，然而可能造成不可反复、幻读。可反复读（REPEATABLE-READ）：对同一字段屡次读取的后果都是统一的，除非自身事务批改，能够防止脏读和不可反复读，然而可能造成幻读。可串行化（SERIALIZABLE）：最高的隔离级别，齐全遵从ACID的隔离级别，所以的事务顺次执行，能够防止脏读、不可反复读、幻读。隔离级别脏读不可反复读幻读读取未提交√√√读取已提交×√√可反复读××√可串行化×××MySQL InnoDB存储引擎默认的事务隔离级别是可反复读（REPEATABLE-READ），能够通过命令select @@tx_isolation;语句来查看，MySQL 8.0 该语句改为SELECT @@transaction_isolation; mysql> SELECT @@tx_isolation;+-----------------+| @@tx_isolation |+-----------------+| REPEATABLE-READ |+-----------------+MySQL InnoDB存储引擎的可反复读并不能防止幻读，须要利用应用加锁读来保障，这加锁读应用到的机制就是Next-Key Locks。 因为隔离级别越低，事务申请的锁越少，所以大部分数据库系统的隔离级别都是读取已提交（READ-COMMITTED），InnoDB 存储引擎默认应用 REPEATABLE-READ（可重读） 并不会有任何性能损失。 InnoDB存储引擎在分布式事务的状况下个别会用到可串行化隔离级别。 拓展一下(以下内容摘自《MySQL 技术底细：InnoDB 存储引擎(第 2 版)》7.7 章)： InnoDB存储引擎提供了对XA事务的反对，并通过XA事务来反对分布式事务的实现。分布式事务指的是容许多个独立的事务资源参加到一个全局的事务中。事务资源通常是关系型数据库系统，但也能够是其余类型的资源。全局事务要求在其中的所有参加的事务要么都提交，要么都回滚，这对事务的原有ACID要求又有了进步。另外，在应用分布式事务时，InnoDB 存储引擎的事务隔离级别必须设置为 SERIALIZABLE。四、理论状况演示MySQL命令行的默认配置中事务都是主动提交的，即执行SQL语句就会马上执行COMMIT操作。能够用命令START TRANSACTION开始一个事务。 咱们能够通过上面命令设置事务隔离级别。 SET [SESSION|GLOBAL] TRANSACTION ISOLATION LEVEL [READ UNCOMMITTED|READ COMMITTED|REPEATABLE READ|SERIALIZABLE]咱们再来看一下咱们在实际操作中应用到的一些并发管制语句： START TRANSACTION | BEGIN ：显示的开启一个事务。COMMIT：提交事务，使得对数据库做的所有批改成为永久性。ROLLBACK：回滚到完结用户的事务，并撤销正在进行的所有未提交的批改。（脏读）读取未提交 （防止脏读）读取已提交 不可反复读还是方才下面的读已提交的图，尽管防止了读未提交，然而却呈现了，一个事务还没有完结，就产生了 不可反复读问题。 可反复读 幻读演示幻读呈现的状况 sql 脚本 1 在第一次查问工资为 500 的记录时只有一条，sql 脚本 2 插入了一条工资为 500 的记录，提交之后；sql 脚本 1 在同一个事务中再次应用以后读查问发现呈现了两条工资为 500 的记录这种就是幻读。 ...

作者「蝉沐风」，一个认真写文章的技术人公众号@蝉沐风“不要应用SELECT *”简直曾经成为了MySQL应用的一条清规戒律，就连《阿里Java开发手册》也明确示意不得应用*作为查问的字段列表，更是让这条规定领有了权威的加持。 不过我在开发过程中间接应用SELECT *还是比拟多的，起因有两个： 因为简略，开发效率十分高，而且如果前期频繁增加或批改字段，SQL语句也不须要扭转；我认为过早优化是个不好的习惯，除非在一开始就能确定你最终理论须要的字段是什么，并为之建设失当的索引；否则，我抉择遇到麻烦的时候再对SQL进行优化，当然前提是这个麻烦并不致命。然而咱们总得晓得为什么不倡议间接应用SELECT *，本文从4个方面给出理由。 1. 不必要的磁盘I/O咱们晓得 MySQL 实质上是将用户记录存储在磁盘上，因而查问操作就是一种进行磁盘IO的行为（前提是要查问的记录没有缓存在内存中）。 查问的字段越多，阐明要读取的内容也就越多，因而会增大磁盘 IO 开销。尤其是当某些字段是 TEXT、MEDIUMTEXT或者BLOB 等类型的时候，成果尤为显著。 那应用SELECT *会不会使MySQL占用更多的内存呢？ 实践上不会，因为对于Server层而言，并非是在内存中存储残缺的后果集之后一下子传给客户端，而是每从存储引擎获取到一行，就写到一个叫做net_buffer的内存空间中，这个内存的大小由零碎变量net_buffer_length来管制，默认是16KB；当net_buffer写满之后再往本地网络栈的内存空间socket send buffer中写数据发送给客户端，发送胜利（客户端读取实现）后清空net_buffer，而后持续读取下一行并写入。 也就是说，默认状况下，后果集占用的内存空间最大不过是net_buffer_length大小罢了，不会因为多几个字段就占用额定的内存空间。 2. 减轻网络时延承接上一点，尽管每次都是把socket send buffer中的数据发送给客户端，单次看来数据量不大，可架不住真的有人用*把TEXT、MEDIUMTEXT或者BLOB 类型的字段也查出来了，总数据量大了，这就间接导致网络传输的次数变多了。 如果MySQL和应用程序不在同一台机器，这种开销非常明显。即便MySQL服务器和客户端是在同一台机器上，应用的协定还是TCP，通信也是须要额定的工夫。 3. 无奈应用笼罩索引为了阐明这个问题，咱们须要建一个表 CREATE TABLE `user_innodb` ( `id` int NOT NULL AUTO_INCREMENT, `name` varchar(255) DEFAULT NULL, `gender` tinyint(1) DEFAULT NULL, `phone` varchar(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `IDX_NAME_PHONE` (`name`,`phone`) USING BTREE) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;咱们创立了一个存储引擎为InnoDB的表user_innodb，并设置id为主键，另外为name和phone创立了联结索引，最初向表中随机初始化了500W+条数据。 InnoDB会主动为主键id创立一棵名为主键索引（又叫做聚簇索引）的B+树，这个B+树的最重要的特点就是叶子节点蕴含了残缺的用户记录，大略长这个样子。 如果咱们执行这个语句 SELECT * FROM user_innodb WHERE name = '蝉沐风';应用EXPLAIN查看一下语句的执行打算： ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。原创：万里数据库，花家舍 导读在多写（多节点写入）数据库（例如MySQL MGR的multi-primary mode）与利用之间，往往会加一层代理组件，通过算法调节不同节点负载，散发高并发读写申请。 要求代理工具须要具备申请转发、负载平衡、故障转移的性能。 在后端节点故障产生或者连贯因为客户端异样、网络问题断开时，须要及时将故障节点及时踢出负载平衡队列或者敞开异样连贯，做到故障转移。 这就是接下来介绍的次要内容，应用golang简略编写一个这样的工具，来深刻学习一下负载平衡代理的实现。 1、性能一览负载平衡 将利用端的连贯申请（负载）依照既定的平衡算法转发到不同的后端节点，服务程序建设利用（客户端）与数据库节点之间的通信并放弃至客户端断开连接。 故障转移 在后端节点呈现故障时，能及时的检测到故障，并将故障节点踢出负载平衡队列，不再将利用申请路由到故障节点，做到利用无感知。在故障复原后，可能检测到节点状态复原，将其再次退出到负载平衡队列。 2、实现细节外围性能申请转发 代理须要做到将申请散发到不同的后端节点下来，并放弃利用与对应节点的通信，直至其中一端退出（故障或者被动）。 负载平衡 对利用的负载，平衡的散发的不同的节点，须要对应的算法反对。目前通用的负载平衡算法有随机、轮询、加权轮询，代码实现了这三种算法。 此外还有动静判断后端节点负载状况，依据负载状况动静调整负载散发，这须要额定的负载监控工作，这里没有实现。 故障检测 负载平衡代理须要防止向生效的节点散发申请。故障类型无疑是很多的，如果八面玲珑的对每个故障类型都关照到，无疑减少了实现难度。 例如在分布式中，不牢靠的网络减少了检测故障难度，对于数据库实例，在分布式中很难判断节点到底是crash了还是网络中断导致的。 并且节点因为负载较高无奈及时响应申请，这时也是很难判断节点状态，此时进行重试可能会加剧节点的负载。 在这里并不是要含糊这种判断，而是理论状况切实是太简单了，我并不是相干领域专家，所以在实现故障检测时，只思考了几种确定性较高或者容易判断的状况。 过程实现其中， 转发 实现过程是在接管到申请后，定义一个后端节点的地址，并建设一个和这个地址的连贯。 在开启两个协程，一个负责将利用（客户端）发送的数据包传递给后端的连贯，另一个是将后端的返回的数据传递给利用，这样就在利用与后端节点之间搭建起了通信，使之像间接通信一样替换数据，外围的步骤能够参考上面代码的实现。 sConn, err := l.Accept()dTcpAddr, _ := net.ResolveTCPAddr("tcp4", addr)dConn, err := net.DialTCP("tcp", nil, dTcpAddr)go io.Copy(sConn, dConn)go io.Copy(dConn, sConn)在呈现连贯实现既定通信后断开连接，或者连贯因为故障退出，须要代理将客户端的申请连贯与转发向后端的连贯一起敞开。 这里应用的形式是获取连贯传输数据时的状态来判断，即io.Copy(sConn, dConn)在呈现谬误时，连贯就能够敞开了。这里借助channel的阻塞个性来向主线程告诉退出。所以对上述的。 go io.Copy(sConn, dConn)go io.Copy(dConn, sConn)代码进行批改后如下： // channel长度为1，任意时刻只写入一个bool值，在其中的值未被读取之前，处于阻塞状态 exitCH := make(chan bool, 1) // 把客户端的的申请转发给后端 go func(s net.Conn, d *net.TCPConn, ex chan bool) { _, err := io.Copy(sConn, dConn) if err != nil { Error.Println("Send data failure: ", err) } exitCH <- true }(sConn, dConn, exitCH) // 把响应的数据返回给客户端 go func(s net.Conn, d *net.TCPConn, ex chan bool) { _, err := io.Copy(dConn, sConn) if err != nil { Error.Println("Receive data failure: ", err) } exitCH <- true }(sConn, dConn, exitCH) // channel阻塞，读取连贯敞开状态 <-exitCH // channel收到信息（连贯终止）后，敞开连贯 _ = dConn.Close()负载平衡 算法的实现则是在每次向后端建设连贯的时候，这个后端地址是依据算法的不同，返回一个负载平衡算法举荐的后端节点的地址，而后应用这个地址建设一个连贯，并与利用搭建起通信（正如上一步骤介绍的那样）。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。[toc] 一、导读MySQL 8.0.19 开始反对对InnoDB引擎表数据进行采样以生成直方图统计信息。 直方图（Histogram）是关系型数据库中提供的一种根底的统计信息，最典型的用处是预计查问谓词的选择率，以便抉择优化的查问执行打算。 常见的直方图品种有：等宽直方图、等高直方图。 二、步骤2.1 SQL语句# 创立直方图ANALYZE [NO_WRITE_TO_BINLOG | LOCAL] TABLE tbl_name UPDATE HISTOGRAM ON col_name [, col_name] ... [WITH N BUCKETS]# 删除直方图ANALYZE [NO_WRITE_TO_BINLOG | LOCAL] TABLE tbl_name DROP HISTOGRAM ON col_name [, col_name] ...2.2 直方图案例创立直方图，更新就是等于创立，会进行从新采样 mysql> analyze table t1 update histogram on tcol01 with 2 buckets;+---------+-----------+----------+---------------------------------------------------+| Table | Op | Msg_type | Msg_text |+---------+-----------+----------+---------------------------------------------------+| test.t1 | histogram | status | Histogram statistics created for column 'tcol01'. |+---------+-----------+----------+---------------------------------------------------+1 row in set (6.38 sec)删除直方图 ...

MySQL中存储着Hive所有表格的元数据信息，一旦MySQL中的数据失落或损坏，会对整个数据仓库零碎造成不可挽回的损失，为防止这种状况的产生，咱们能够抉择每天对元数据进行备份，进而实现MySQL HA（High Availability高可用）。 MySQL全套视频学习材料：http://www.atguigu.com/download.shtml MySQL的HA计划不止一种，本文介绍较为罕用的一种——基于keepalived的MySQL HA。 MySQL的HA离不开其主从复制的技术。主从复制是指一台服务器充当主数据库服务器（master），另一台或多台服务器充当从数据库服务器（slave），从服务器（slave）主动向主服务器（master）同步数据。实现MySQL的HA，需使两台服务器互为主从关系。 Keepalived是基于VRRP（Virtual Router Redundancy Protocol，虚构路由器冗余协定）协定的一款高可用软件。Keepailived有一台主服务器（master）和多台备份服务器（backup），在主服务器和备份服务器下面部署雷同的服务配置，应用一个虚构IP地址对外提供服务，当主服务器呈现故障时，虚构IP地址会主动漂移到备份服务器。 具体操作如下： MySQL一主一从配置集群布局，如表1所示表1 一主一从集群布局 hadoop102 hadoop103 hadoop104 MySQL（master） MySQL（slave） 留神：MySQL的装置参考5.1.2 配置master批改hadoop103中MySQL的/usr/my.cnf配置文件。 [mysqld] 开启binloglog_bin = mysql-bin binlog日志类型binlog_format = row MySQL服务器惟一idserver_id = 1 重启hadoop103的MySQL服务 [atguigu@hadoop103 ~]$ sudo service mysql restart 进入MySQL客户端，执行以下命令，查看master状态，如图1所示 MySQL高可用配置图1 MySQL客户端查看master状态 配置slave批改hadoop104中MySQL的/usr/my.cnf配置文件 [mysqld] MySQL服务器惟一idserver_id = 2 开启slave中继日志relay_log=mysql-relay 重启hadoop104的MySQL服务 [atguigu@hadoop104 ~]$ sudo service mysql restart 进入hadoop104的mysql客户端 执行以下命令 mysql> CHANGE MASTER TO MASTER_HOST='hadoop103', MASTER_USER='root', MASTER_PASSWORD='123456', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=120; 启动slave mysql> start slave; 查看slave状态，如图2所示 MySQL高可用配置图2 MySQL客户端查看slave状态 ...

大家好，我是咔咔 不期速成，日拱一卒 通过上期文章晓得了在MySQL中存在三种join的算法，别离为NLJ、BNLJ、BNL，总结来说分为索引嵌套循环连贯、缓存块嵌套循环连贯、粗犷循环连贯。 另外还晓得了一个新的概念join_buffer，作用就是把关联表的数据全副读入join_buffer中，而后从join_buffer中一行一行的拿数据去被驱动表中查问。因为是在内存中获取数据，因而效率还是会有所晋升。 同时在上期文章中遇到了一个生疏的概念hash_join，在上期中没有具体阐明，本期会进行详述。 一、Multi-Range Read优化在介绍本期主题时先来理解一个知识点Multi-Range Read，次要的作用是尽量让程序读盘，在任何畛域只有是有程序的都会有肯定的性能晋升。 比方MySQL的索引，当初你应该晓得索引天生具备有序性从而防止服务器对数据再次排序和建设长期表的问题。 接下来应用一个案例来实操一下这个优化是怎么做的 创立join_test1、join_test2两张表 CREATE TABLE `join_test1` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `a` int(11) unsigned NOT NULL, `b` int(11) unsigned NOT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;CREATE TABLE `join_test2` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `a` int(11) unsigned NOT NULL, `b` int(11) unsigned NOT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;给两张表增加一些数据，用于案例演示 drop procedure idata;delimiter ;;create procedure idata()begin declare i int; set i=1; while(i<=1000)do insert into join_test1 (a,b) values ( 1001-i, i); set i=i+1; end while; set i=1; while(i<=1000000)do insert into join_test2 (a,b) values (i, i); set i=i+1; end while;end;;delimiter ;call idata();表join_test1的字段a上存在索引的，那么在查问时就会应用该索引。 ...

简介mydumper 是一款开源的 MySQL 逻辑备份工具，次要由 C 语言编写。与 MySQL 自带的 mysqldump 相似，然而 mydumper 更快更高效。mydumper 的一些长处个性：s 轻量级C语言开发反对多线程备份数据，备份后按表生成多个备份文件反对事务性和非事务性表一致性备份反对将导出的文件压缩，节约空间反对多线程复原反对已守护过程模式工作，定时快照和间断二进制日志反对按指定大小将备份文件切割数据与建表语句拆散下载安装装置形式十分多，以下介绍几种常见的形式。 Ubuntu 中自带了 myloader sudo apt-get install mydumper应用 deb 包装置，以 Ubuntu 为例 apt-get install libatomic1wget https://github.com/mydumper/m...$(lsb_release -cs)_amd64.deb dpkg -i mydumper_0.11.5-1.$(lsb_release -cs)_amd64.deb编译装置docker 装置依据理论平台状况，可抉择不同的装置形式，官网也提供了一些常见的装置文档，https://github.com/mydumper/mydumper 参数阐明mydumper 参数阐明-B, --database 要备份的数据库，不指定则备份所有库，个别倡议备份的时候一个库一条命令-T, --tables-list 须要备份的表，名字用逗号隔开-o, --outputdir 备份文件输入的目录-s, --statement-size 生成的insert语句的字节数，默认1000000-r, --rows 将表按行分块时，指定的块行数，指定这个选项会敞开 --chunk-filesize-F, --chunk-filesize 将表按大小分块时，指定的块大小，单位是 MB-c, --compress 压缩输入文件-e, --build-empty-files 如果表数据是空，还是产生一个空文件（默认无数据则只有表构造文件）-x, --regex 是同正则表达式匹配 'db.table'-i, --ignore-engines 疏忽的存储引擎，用都厚宰割-m, --no-schemas 不备份表构造-d, --no-data 不备份表数据-G, --triggers 备份触发器-E, --events 备份事件-R, --routines 备份存储过程和函数-W, --no-views 不备份视图--where 只导出符合条件的数据-k, --no-locks 不应用长期共享只读锁，应用这个选项会造成数据不统一--less-locking 缩小对InnoDB表的锁施加工夫（这种模式的机制下文详解）-l, --long-query-guard 设定阻塞备份的长查问超时工夫，单位是秒，默认是60秒（超时后默认mydumper将会退出）--kill-long-queries 杀掉长查问 (不退出)-b, --binlogs 导出binlog-D, --daemon 启用守护过程模式，守护过程模式以某个距离不间断对数据库进行备份-I, --snapshot-interval dump快照间隔时间，默认60s，须要在daemon模式下-L, --logfile 应用的日志文件名(mydumper所产生的日志), 默认应用规范输入--tz-utc 跨时区时应用的选项。容许备份timestamp,这样会导致不同时区的备份还原出问题，默认敞开。--skip-tz-utc 同上，默认值。--use-savepoints 应用savepoints来缩小采集metadata所造成的锁工夫，须要 SUPER 权限--success-on-1146 Not increment error count and Warning instead of Critical in case of table doesn't exist-h, --host 连贯的主机名-u, --user 备份所应用的用户-p, --password 明码-P, --port 端口-S, --socket 应用socket通信时的socket文件-t, --threads 开启的备份线程数，默认是4-C, --compress-protocol 压缩与mysql通信的数据-V, --version 显示版本号-v, --verbose 输入信息模式, 0 = silent, 1 = errors, 2 = warnings, 3 = info, 默认为 2myloader 参数阐明-d, --directory 备份文件的文件夹-q, --queries-per-transaction 每次事务执行的查问数量，默认是1000-o, --overwrite-tables 如果要复原的表存在，则先drop掉该表，应用该参数，须要备份时候要备份表构造-B, --database 还原到的数据库（指标库）-s, --source-db 被还原的数据库（源数据库），-s db1 -B db2，示意源库中的db1数据库，导入到db2数据库中。-e, --enable-binlog 启用还原数据的二进制日志-h, --host 主机-u, --user 还原的用户-p, --password 明码-P, --port 端口-S, --socket socket文件-t, --threads 还原所应用的线程数，默认是4-C, --compress-protocol 压缩协定-V, --version 显示版本-v, --verbose 输入模式, 0 = silent, 1 = errors, 2 = warnings, 3 = info, 默认为2罕用案例mydumper 导出示例# 集体理论中最罕用的备份语句mydumper -B test -o /home/mydumper/data/test -e -G -R -E -D -u root -p 123456 -h 192.168.0.191 -P 3306 -v 3 --long-query-guard 288000 --skip-tz-utc --no-locks --logfile /home/mydumper/log/test# 备份全副数据库 mydumper -u root -p 123456 -o /home/mydumper/data/all/# 备份全副数据库，排除零碎库，mydumper -u root -p 123456 --regex '^(?!(mysql|sys|performance_schema|information_schema))' -o /home/mydumper/data/all/# 备份全副数据库，蕴含触发器、事件、存储过程及函数mydumper -u root -p 123456 -G -R -E -o /home/mydumper/data/all/# 备份指定库mydumper -u root -p 123456 -G -R -E -B db1 -o /home/mydumper/data/db1# 备份指定表mydumper -u root -p 123456 -B db1 -T tb1,tb2 -o /home/mydumper/data/db1# 只备份表构造mydumper -u root -p 123456 -B db1 -d -o /home/mydumper/data/db1# 只备份表数据mydumper -u root -p 123456 -B db1 -m -o /home/mydumper/data/db1myloader 导入案例# 集体理论中最罕用的导入语句myloader -h 192.168.0.192 -P 33306 -u root -p 123456 -t 1 -v 3 -d /home/mydumper/data/test/0/ -B test# 从备份中复原指定库myloader -u root -p 123456 -s db1 -o -d /home/mydumper/data/all/0/# 导入时开启 binlogmyloader -u root -p 123456 -e -o -d /home/mydumper/data/db1/0/# 将源库的 db1 导入到备库的 db1_bak 库中myloader -u root -p 123456 -B db1_bak -s db1 -o -d /home/mydumper/data/db1/0/# 导入特定的某几张表## 先将 metadata 文件和须要独自导入的表的构造文件和数据文件导入到独自的文件夹中。此处默认库已建好，否则还须要复制建库相干语句。cp /home/mydumper/data/db1/0/metadata /backup/db1/0/cp /home/mydumper/data/db1/0/d1.t1-schema.sql /backup/db1/0/cp /home/mydumper/data/db1/0/d1.t1.sql /backup/db1/0/## 从新文件夹中导入数据myloader -u root -p 123456 -B db1 -d /backup/db1/0/## 以上就能够独自导入 db1.t1 表对于 -e 参数，须要略微留神下。默认状况下，myloader 是不开启 binlog 的，这样能够进步导入速度。如果导入实例有从库，且须要导入的后果同步到从库上，则须要应用 -e 关上 binlog 记录。导出之后的目录如下，以数据库 d1 ，其中有表 t1 为例： ...

热衷学习，热衷生存！ 积淀、分享、成长，让本人和别人都能有所播种！ 一、MySQL日志MySQL日志次要包含谬误日志、查问日志、慢查问日志、事务日志、二进制日志几大类。其中比拟重要的就是二进制日志binlog（归档日志）、事务日志redo log（重做日志）和undo log（回滚日志）。 日志关系如下图： 二、redo logredo log（重做日志）是InnoDB存储引擎独有的，它让MySQL有了解体复原的能力。 当MySQL实例挂了或者宕机了，重启的时候InnoDB存储引擎会应用rede log日志复原数据，保障事务的持久性和完整性。如下图： MySQL中数据是以页为复数存储，当你查问一条记录时，硬盘会把一整页的数据加载进去，加载进去的数据叫做数据页，会放到Buffer Pool中。后续的查问都是先从Buffer Pool中找，没有找到再去硬盘加载其余的数据页直到命中，这样子能够缩小磁盘IO的次数，进步性能。更新数据的时候也是一样，优先去Buffer Pool中找 ，如果存在须要更新的数据就间接更新。而后会把“在某个数据页做了什么批改”记录到重做日志缓存（redo log buffer）里，在刷盘的时候会写入redo log日志文件里。 如下图： 小贴士：每条redo记录由“表空间号+数据页号+偏移量+批改数据长度+具体批改的数据”组成。刷盘机会现实状况下，事务一提交就会进行刷盘操作，然而实际上是刷盘的机会是依据策略来决定的。 InnoDB存储引擎为redo log的刷盘策略提供了innodb_flush_log_at_trx_commit参数，它反对三种策略： 0：设置为0的时候，每次提交事务时不刷盘。1：设置为1的时候，每次提交事务时刷盘。2：设置为2的时候，每次提交事务时都只把redo log buffer写入page cache。innodb_flush_log_at_trx_commit参数默认为1，当事务提交的时候会调用fsync对redo log进行刷盘，将redo log buffer写入redo log文件中。 另外，Innodb存储引擎有一个后盾线程，每隔1秒，就会把会redo log buffer中的内容写入到文件系统缓存page cache，而后调用fsync刷盘。 如上图，所以说一个没有提交事务的redo log记录，也会被刷盘。 上面是各种刷盘策略的流程图。 innodb_flush_log_at_trx_commit = 0 如上图，如果宕机了或者MySQL挂了可能造成1秒内的数据失落。 innodb_flush_log_at_trx_commit = 1如上图，只有事务提交胜利，redo log记录就肯定在磁盘里，不会有工作数据失落。 如果执行事务的时候MySQL挂了或者宕机了，这部分日志失落了，然而因为事务没有提交，所以日志丢了也不会有损失。 innodb_flush_log_at_trx_commit = 2 如上图，当事务提交胜利时，redo log buffer日志会被写入page cache，而后后盾线程会刷盘写入redo log，因为后盾线程是1秒执行一次所以宕机或者MySQL挂了可能造成1秒内的数据失落。 日志文件组硬盘上存储的redo log日志文件不止一个，而是一个日志文件组的模式呈现的，每个的redo log文件大小都是一样的。它采纳的是环形数组模式，从头开始写，写到开端回到头循环写，如下图所示： 在日志文件组中有两个重要的属性，别离是witre pos、checkpoint wirte pos：是以后记录的地位，一边写一边后移。checkpoint：是以后要擦除的地位，也是后盾推移。每次刷盘redo log记录到日志文件组中，wirte log地位就会后移更新。 ...

在数字化转型的推动下，数据作为重要的生产因素，其价值被从新定义，越来越多企业开始器重数据资源的价值。 但随着数据量的一直增多、数据类型的不断丰富以及利用零碎的逐步减少，数据整体通用性和数据一致性治理老本大大增加，进而影响到整个零碎的应用。因而，如何通过简略的操作形式便可调用多种数据库的资源，尽量减少数据转换操作，成为当下最迫切的需要，尤其是利用湖仓一体架构解决多模数据的解决剖析，就此成为一种新的趋势。 针对传统数据仓库治理存在的问题，HashData采纳湖仓一体架构，可能实现数据仓库和数据湖的数据无缝买通和自在流动，缩小反复建设，最大化升高数据转换和迁徙老本。 背景及挑战近年，随着互联网以及物联网等技术的一直倒退，越来越多的数据被生产进去，数据管理工具也失去了飞速发展。这些数据类型多种多样，为了满足这些海量数据的存储、计算与剖析，传统做法是同时利用十几个不同的数据库产品来别离满足相应的需要。 传统数据仓库对数据模型有严格的要求，在数据导入到数据仓库前，数据模型就必须当时定义好，数据必须依照模型设计存储。所以，数据规模和数据类型的限度，导致传统数据仓库无奈撑持互联网时代的商业智能。 随着数字化过程放慢，企业须要更欠缺的配套服务来缩小数据迁徙复杂度，降低成本、保障数据安全。多元数据库的格局，极大的促成了社会经济的倒退，但同时也带来了数据库运维治理上的难题，如何更好的治理多元数据库，成为行业亟待解决的难题。 数据库多元化带来的治理难点 装置部署过程简单传统数据库环境筹备，须要用户自行筹备存储、网络、计算资源，协调系统、网络、数据库等各方专家，能力实现一套可用的数据库集群部署。数据库治理难度大传统数据库治理依赖于数据库厂商自带的管理工具，而今数据库越来越多样化，不同类型的数据库治理、监控、运维须要学习不同的管理工具，运维的学习老本和工具应用的切换老本晋升使得运维难度极大。容灾架构实现艰难数据库备份或高可用架构需自行手工搭建或编写脚本，实现难度极大，且出错概率较高。在生产数据库呈现故障时，备份容灾平台无奈疾速接管业务。对于数据库多元化带来的部署简单、治理艰难等问题，国内外的数据库行业相干厂商都提出了各自的解决方案。但这些解决方案都存在着一些有余，数据库高可用的装置部署仍旧是企业的一大危险。 湖仓一体赋能数据流通HashData云原生数据仓库零碎架构 在一个多元数据的时代，咱们致力于构建一个凋谢的数据存储、计算和连贯平台。HashData内置表的数据长久化到对象存储，可能提供SQL、Python、图计算、流式计算、机器学习和人工智能等多种剖析性能，同时还以连接器（connector）的形式让第三方开源计算框架可能十分不便和高效地拜访HashData的数据，包含Hive、Spark、Flink、Kafka等。 针对目前多元数据库运维治理带来的痛点，HashData云数据仓库提供了多种灵便的数据入库形式，反对MySQL、ORACLE、Python、Postgres、NAS、HDFS等多种数据源的数据导入，并主动实现数据格式转换，助力用户轻松上云，帮忙用户进步转换率、升高数据库迁徙老本。 各种数据源导入形式具备不同的特点。以目前应用宽泛的MySQL数据库为例，HashData兼容MySQL Data Wrapper(mysql_fdw)开源工具 。这个扩大工具能够将PostgreSQL数据库发动的对MySQL数据库的增删查改操作转为MySQL数据库能够解释执行的语句，在MySQL端运行并返回后果。 具体操作如下： 装置要求HashData数据仓库3x版本源码取得PostgreSQL源码9.4.24MySQL源码MySQL 5.7.28MySQL data wrapper能够应用的是Greenplum 6x的兼容版本环境筹备装置HashData数据库 (兼容GP6x)下载的源代码解压缩到同一目录下 # lsmysql-5 .7 .28-linux-glibc2 .12-x86_64 mysql_fdw_greenplum-master postgresql-9.4.24编译装置装置gccyum install gcc编译装置PostgreSQL # makemake[1]: 进入目录“/root/manual/postgresql-9.4.24/config”make[1]: 对“all”无需做任何事。make[1]: 来到目录“/root/manual/postgresql-9.4.24/config”All of PostgreSQL successfully made.Ready to install .# make install ...make -C config installmake[1]: 进入目录“/root/manual/postgresql-9.4.24/config”/usr/bin/mkdir -p '/usr/local/pgsql/lib/pgxs/config'/usr/bin/install -c -m 755 ./install-sh'/usr/local/pgsql/lib/pgxs/config/install-sh'/usr/bin/install -c -m 755 ./missing '/usr/local/pgsql/lib/pgxs/config/missing'make[1]: 来到目录“/root/manual/postgresql-9.4.24/config”PostgreSQL installation complete .编译装置mysql_fdw $ export PATH=/home/gpadmin/manual/postgresql-9.4.24/src/bin:$PATH$ export PATH=/home/gpadmin/manual/mysql-5.7.28-linux-glibc2.12-x86_64/bin:$PATH$ make USE_PGXS=1$ make USE_PGXS=1 install拷贝文件到指定目录 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。导语SHOW CREATE TABLE语句用于为指定表/视图显示创立的语句，本文将简要形容如何在MySQL源码里跟踪和学习此类语句的执行流程。 (注：应用版本为Percona-Server-8.0.25-15) 步骤筹备工作编译调试版本的 mysql server 程序，创立数据库实例后建设一张示例表： create table t1(c1 int);有了示例表, 在客户端执行如下语句，就能够在服务端开始咱们的语句跟踪了： show create table t1;断点设置在如下函数/办法中设置断点(gdb)： dispatch_sql_command # 对sql语句做词法/语法解析，失去理论要运行的sql命令mysql_execute_command # 依据lex->sql_command值调用对应办法执行查问操作Sql_cmd_show_noplan::executeSql_cmd_show_create_table::execute_inner # '执行'show create table指令mysqld_show_create # 由Sql_cmd_show_create_table::execute_inner调用，获取表创立信息store_create_info # 依据表属性拼接建表字串代码跟踪与浏览通过断点查看上下文代码，通过打印变量信息等伎俩，可大抵理解show create table t1的执行流程，以下列出几个执行中较要害的地位，并对源码内容做注解阐明： 断点地位1： Sql_cmd_show_create_table::execute_inner(THD *) sql_show.cc:408代码上下文： bool Sql_cmd_show_create_table::execute_inner(THD *thd) { // ... ... 注：为显示和阐明不便，局部代码已被省略，可自行参阅源码读取更全面信息 // 将指定表退出至session的table list，并初始化表的锁信息；相当于让session晓得，本次查问 // 将会用到这张表。 if (lex->query_block->add_table_to_list(thd, m_table_ident, nullptr, 0) == nullptr) return true; TABLE_LIST *tbl = lex->query_tables; // ... ... if (mysqld_show_create(thd, tbl)) return true; //断点地位 return false;}断点地位2:mysqld_show_create(THD *, TABLE_LIST *) sql_show.cc:1206代码上下文： ...

Part 1 - 背景 1.1 异步I/O 异步I/O是计算机操作系统对输入输出的一种解决形式：发动I/O申请的线程不期待I/O操作实现，就继续执行随后的代码，I/O后果用其余形式告诉发动I/O申请的程序。 与异步I/O绝对的是更为常见的“同步（阻塞）I/O”：发动I/O申请的线程不从正在调用的I/O操作函数返回（即被阻塞），直至I/O操作实现。 同步IO机制存在着肯定的弊病，例如：IO的实现都是在以后过程上下文的零碎调用中实现的，会阻塞以后过程，升高零碎的实时性，同时导致性能较低。 对于I/O密集型利用，同步I/O的弊病就会被放大，而异步I/O的劣势便体现进去：（1）由内核来操作I/O，利用不再阻塞在I/O，能够执行其余逻辑，此时利用运行和I/O执行变成了并行的关系；（2）能够批量地进行I/O操作，让设施的能力失去最大施展。 Linux内核提供的I/O机制大都是同步实现的，如惯例的read/write/send/recv等零碎调用。在引入io_uring之前，Linux零碎下的异步I/O机制的实现次要为两种： （1）POSIX AIO。这种计划是用户态实现的异步I/O机制，其核心思想为：创立一个专门用来解决IO的线程，用户程序将I/O操作交给该线程来进行。这种形式实现的异步I/O效率和扩展性都比拟差。 （2）LINUX AIO。Linux内核里也实现了一套异步I/O机制，被称为AIO。该机制的应用限度比拟大，比方只反对direct IO而无奈应用cache，且扩展性比拟差。 1.2 io_uring劣势 随着Linux 5.1的公布，Linux终于有了本人好用的异步I/O实现，并且反对大多数文件类型（磁盘文件、socket，管道等），彻底解决了长期以来Linux AIO的各种有余，这就是io_uring。 相比于Linux传统的异步I/O机制，io_uring的劣势次要体现在以下几个方面： （1）高效。一方面，io_uring采纳了共享内存的形式来传递参数，缩小了数据拷贝；另一方面，采纳ring buffer的形式来实现批量的I/O申请，缩小了零碎调用的次数。 （2）可扩展性强。io_uring具备超强的可扩展性，具体表现在： •反对的I/O设施类型多样化，不仅反对块设施的IO，还反对任何基于文件的IO，例如套接口、字符设施等； •反对的I/O操作多样化，不仅反对惯例的read/write，还反对send/recv/sendmsg/recvmsg/close/sync等大量的操作，而且可能很灵便地进行裁减。 （3）易用。io_uring提供了配套的liburing库，其对io_uring的零碎调用进行了大量的封装，使得接口变得简略易用。 （4）可伸缩。io_uring提供了poll模式，对于I/O性能要求较高的场景，容许用户就义肯定的CPU来取得更高的IO性能：低提早、高IOPS。 经测试，相比于libaio，在poll模式下io_uring性能晋升将近150%，堪比SPDK。在高QD的状况下，更是有赶超SPDK的趋势。 io_uring就是：一套全新的syscall，一套全新的async API，更高的性能，更好的兼容性，来迎接高IOPS，高吞吐量的将来。 Part 2 - io_uring根本实现 2.1 基本原理 io_uring实现异步I/O的形式其实是一个生产者-消费者模型： （1）用户过程生产I/O申请，放入提交队列（Submission Queue，简称SQ）。 （2）内核生产SQ中的I/O申请，实现后将后果放入实现队列（Completion Queue，简称CQ）。 （3）用户过程从CQ中收割I/O后果。 SQ和CQ是内核初始化io_uring实例的时候创立的。为了缩小零碎调用和缩小用户过程与内核之间的数据拷贝，io_uring应用mmap的形式让用户过程和内核共享SQ和CQ的内存空间。 另外，因为先提交的I/O申请不肯定先实现，SQ保留的其实是一个数组索引（数据类型 uint32），真正的SQE（Submission Queue Entry）保留在一个独立的数组（SQ Array）。所以要提交一个I/O申请，得先在SQ Array中找到一个闲暇的SQE，设置好之后，将其数组索引放到SQ中。 用户过程、内核、SQ、CQ和SQ Array之间的根本关系如下： 图1 io_uring机制的基本原理 2.2 io_uring的用户态 io_uring的实现仅仅应用了三个syscall：io_uring_setup, io_uring_enter和io_uring_register。它们别离用于设置io_uring上下文，提交并获取实现工作，以及注册内核用户共享的缓冲区。应用前两个syscall曾经足够应用io_uring接口了。 2.2.1 初始化 int io_uring_setup(int entries, struct io_uring_params *params); 内核提供了io_uring_setup零碎调用来初始化一个io_uring实例，创立SQ、CQ和SQ Array，entries参数示意的是SQ和SQArray的大小，CQ的大小默认是2 * entries。params参数既是输出参数，也是输入参数。 ...

前言为了让MySQL的利用更为便捷地迁徙到KunlunDB，咱们做了很多兼容MySQL的工作。 本篇章次要介绍KunlunDB当初曾经反对的MySQL罕用的公有DML语法，以及这些语法与原生MySQL的差别。 一、兼容MySQL的insert ignore语法性能： 疏忽违反惟一束缚的新元组。 示例： postgres -> create table t1(a int primary key, b int not null unique);CREATE TABLE# 违反惟一束缚，不进行插入postgres -> insert ignore into t1(a,b) values (4,4);INSERT 0 1postgres -> insert ignore into t1(a,b) values (4,4);INSERT 0 0和原生MySQL的差别： 只疏忽唯一性束缚，如果违反其余束缚（例如分区束缚、非null束缚），则报错。例如： postgres -> insert ignore into t1(a,b) values (4,NULL);ERROR: null value in column "b" violates not-null constraintDETAIL: Failing row contains (4, null)二、兼容MySQL的INSERT...ONDUPLICATE KEY UPDATE...语法性能：插入数据；如果违反了某个惟一束缚，则转变为更新操作，对其中一个抵触的元组进行更新。 示例： postgres -> create table t1 (a int primary key, b int not null unique);CREATE TABLEpostgres -> insert into t1 values(3,3), (4,4);INSERT 0 2# 插入的数据和已有的两个元组都抵触，但只更新了其中一个元组(3,3)postgres -> insert into t1 values(3,4) on duplicate key update b=2;INSERT 0 2postgres -> select * from t1; a | b---+--- 3 | 2 4 | 4和原生MySQL的差别： ...

为了帮忙各位小伙伴可能不便、疾速的理解到 PolarDB 开源数据库的相干的应用问题，社区每周将精选群内高质量的问题通过该栏目予以对立回答，心愿可能对大家有所帮忙。 PolarDB for PostgreSQL 问答精选 Q： create index 的表有几千万行，能够后盾执行这个命令吗？还是只能在前台等着它完结？ A：命令能够放后盾执行，例如通过 shell 的后台任务, 或者 PG 的工作插件, 或者 DBlink 的异步调用。 Q: 求教一个问题，pg_stat_all_tables 外面某个表没有看到有更新或者删除的 tuples，也没有 vacuum 和 analyze 的信息，然而用 pgstattuple 看这个表，实际上有很多闲暇的空间，表也十分大，用命令去执行 vacuum 是能够把空间释放出来的，这个可能是什么起因导致的？ A: 统计信息可能被清理了，或者没有开启统计计数器。还有一种状况是分区表，要看最小单元的总分区的统计信息，主表可能是没有统计数据的。 Q: patroni 在做故障切换时会做差别数据同步吗？ 比方有的数据主库有，还没同步到从库，这种状况怎么解决的？ A: 切换逻辑外面能够本人实现，patroni 就是个框架。 Q: 有没有方法将 wal_log 反向解析成 sql？相似 oracle 的 logminer？ A：walminer，须要把 wal level 设置为 logical。 PolarDB for PostgreSQL 已在 GitHub 开源，欢送返回理解和反对：https://github.com/ApsaraDB/P... 欢送扫码退出钉钉群与咱们一起交换 PolarDB for PostgreSQL，共建社区： PolarDB-X 问答精选 Q：PolarDB-X 的部署依赖块存储吗？ ...

作者：李鹏博 爱可生 DBA 团队成员，次要负责 MySQL 故障解决和 SQL 审核优化。对技术执着，为客户负责。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 -- 最近发现客户的一台 MySQL 5.7.32 实例的监控线程状态始终处于 Opening table 状态，且都是在对 information_schema.tables 表做相干查问，如图： 通过 show open tables ;语句发现 opened tables 并不算太多： 相干参数也没有太大的不合理性： 尽管 ulimit 设置不是很大，然而也不会对此产生什么影响 查看 MySQL Error 日志也没有发现与此相关的异样。 因而只能应用 pstack 工具对 MySQL 打堆栈来进行剖析，堆栈日志如下： 通过剖析堆栈日志发现，问题呈现在进行查问时会应用 Federated 存储引擎表对近程实例进行查问。 查看数据库应用 Federated 存储引擎的表，发现有两张表应用了 Federated 存储引擎： 通过在实例服务器上 Telnet Feferated 服务端的实例IP和端口发现是不通的： 所以揣测问题起因为：监控线程在查问 information_schema.tables 表时，当须要获取 Federated 存储引擎表的信息时须要连贯远端 Server ，而因为网络或其余起因无奈连贯时，就会导致本地监控线程处于 Opening table 状态。 ...

InnoDB 存储引擎反对多粒度锁（multiple granularity locking），也就是容许行锁和表锁共存。当容许行锁和表锁共存的时候，可能会存在上面这样一个问题： 例如我执行如下 SQL： 这段 SQL 执行实现后，给 id 为 1 的记录加了排他锁。 此时，在另外一个会话中，我如果想给这张表再来一个表级共享锁，如下： lock table user read;此时就会有一个问题，共享锁和排他锁是互斥的，要给表上共享锁，就得去检查一下表中的每一条记录都不存在排他锁，如果表中的数据量比拟大，这个操作效率就会比拟低。 为了解决这个问题，就引出了咱们明天的意向锁。为了使多粒度级别的锁定变得实用，InnoDB 应用了意向锁，留神，意向锁是一种表级锁，它示意事务稍后对表中的行须要哪种类型的锁（共享或独占）。 意向锁也分为两类： intention shared lock：动向共享锁 (IS) 示意事务打算在表中的各个行上设置共享锁。intention exclusive lock：动向排他锁 (IX) 示意事务打算对表中的各个行设置排他锁。例如，对于 SELECT ... LOCK IN SHARE MODE; 会主动设置 IS 锁，对于 SELECT ... FOR UPDATE 会主动设置 IX 锁，并且 IS 锁和 IX 锁不须要手动设置，这个是由零碎主动设置。 意向锁的加锁规定如下： 在事务能够获取表中行的共享锁之前，它必须首先获取表上的 IS 锁或更强的锁。在事务能够获取表中行的排他锁之前，它必须首先获取表上的 IX 锁。简而言之：IS 和 IX 是表锁，它们存在的意义在于，未来给表上表级的 S 锁或者 X 锁的时候，能够通过 IS 或者 IX 疾速判断出以后表中是否曾经有加锁记录了，仅此而已。所以 IS 和 IX 之间其实是兼容的，IX 之间也是兼容的，如下表： ...

为了帮忙各位朋友如何应用HHDBCS工具疾速治理数据库，恒辉社区会陆续推出数据库治理上手系列。 请参看如下的“Mysql治理系列--01.登录不同治理视图”，教你如何疾速浏览治理Mysql的数据对象和用户。https://www.bilibili.com/vide...

背景本地PC降级到Win10，须要从新搭建环境，特此记录MYSQL8如何装置配置。 步骤下载安装包倡议去MYSQL官网下载，本地是64位。 下载下来，解压进去并不是安装文件，而是硬盘版。 新建配置文件my.ini[mysqld]# 设置3306端口port=3306# 设置mysql的装置目录basedir=D:\Program Files\mysql-8.0.28-winx64# 设置mysql数据库的数据的寄存目录（data目录改教程不须要手动创立）datadir=D:\Program Files\mysql-8.0.28-winx64\data# 容许最大连接数max_connections=200# 容许连贯失败的次数。这是为了避免有人从该主机试图攻打数据库系统max_connect_errors=10# 服务端应用的字符集默认为UTF8character-set-server=utf8mb4# 创立新表时将应用的默认存储引擎default-storage-engine=INNODB# 默认应用“mysql_native_password”插件认证default_authentication_plugin=mysql_native_password[mysql]# 设置mysql客户端默认字符集default-character-set=utf8[client]# 设置mysql客户端连贯服务端时默认应用的端口port=3306default-character-set=utf8其中门路basedir和datadir须要依据本地状况批改。 初始化mysql以管理员身份关上一个控制台，并进入bin文件夹下。执行命令 mysqld --initialize --console胜利标记是可能生成明码： 再执行命令 mysqld --install 执行启动MYSQL服务的命令 net start mysql 到这里，MYSQL胜利配置，在服务中能看到MYSQL曾经胜利运行。 连贯测试应用命令测试连贯： mysql -u root -p

我的博客 工具市面上的SQL可视化工具不少，我个别罕用的次要就是这两个。 当然，IDEA也是集成了数据库可视化性能的。除了这些，还有DBeaver、SQLyog等等。 我比拟喜爱DataGrip，我就用这个演示了。不过这个的界面就没有Navicat柔美了，不过个人感觉功能强大许多。 写表 这里，我曾经创立好了一个Demo数据库。 咱们先来理解一下创立表的语法。 创立表USE Demo;# 语法如下# CREATE TABLE [IF NOT EXISTS] 表名(字段内容)CREATE TABLE IF NOT EXISTS class(   Id INT(4) COMMENT 'ID号',   Name VARCHAR(10) COMMENT '姓名');IF NOT EXISTS能够省略不写。 CREATE TABLE class(   Id INT(4) COMMENT 'ID号',   Name VARCHAR(10) COMMENT '姓名');记住CREATE TABLE用于创立表。 创立字段()外面是表的字段，写入字段的格局如下。 # 字段名 数值类型 COMMENT '字段备注'Id INT(4) COMMENT 'ID号',Name VARCHAR(10) COMMENT '姓名'如果数值类型要设置长度，咱们能够在前面接上()，外面填入长度值。COMMENT关键词是用于创立字段的对应备注，备注必须在其后。字段束缚与属性设置咱们能够通过某些关键词为字段设置束缚与某些属性。 Id INT(4) COMMENT 'ID号' PRIMARY KEY ,id INT(4) COMMENT 'ID号' PRIMARY KEY AUTO_INCREMENT NOT NULL  UNIQUE KEY 比方，PRIMARY KEY关键词能够将字段设置为主键。 ...

我的博客 范式？即标准！范式是“合乎某一种级别的关系模式的汇合，示意一个关系外部各属性之间的分割的合理化水平”。很艰涩吧？实际上你能够把它粗略地了解为一张数据表的表构造所合乎的某种设计标准的级别。 数据库范式也分为1NF，2NF，3NF，BCNF，4NF，5N个别在咱们设计关系型数据库的时候，最多思考到BCNF就够。 合乎高一级范式的设计，必然合乎低一级范式，例如合乎2NF的关系模式，必然合乎1NF。1NF-第一范式数据表的每一列都要放弃它的原子个性，也就是列不能再被宰割。比方这样： 进货它还能够被分出进货的数量，进货的单价等等属性。所以这样是不合乎第一范式的。 来自——>博客园 2NF-第二范式第二范式（2NF）是在第一范式（1NF）的根底上建设起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。即满足第一范式前提，当存在多个主键的时候，才会产生不合乎第二范式的状况！！！。比方有两个主键，不能存在这样的属性，它只依赖于其中一个主键，这就是不合乎第二范式。艰深了解是任意一个字段都只依赖表中的同一个字段。依赖在数据表中，属性（属性组）X确定的状况下，能齐全退出来属性Y齐全依赖于X。 齐全依赖齐全依赖是针对于属性组来说，当一组属性X能推出来Y的时候就说Y齐全依赖于X。 局部依赖一组属性X中的其中一个或几个属性能推出Y就说Y局部依赖于X。 3NF-第三范式首先，要满足第三范式（3NF）必须先满足第二范式（2NF）。 也就是说，要求一个数据库表中不蕴含已在其它表中已蕴含的非主键字段。 三范式肯定须要？咱们的三范式是个别标准。就是说，只是个别都会恪守这个标准。 然而！！！不是肯定须要恪守，比方有时候，数据不冗余也不是坏事。所以，咱们要依据须要来定义，建设在需要之上。 没有冗余的数据库未必是最好的数据库，有时为了进步运行效率，进步读性能，就必须升高范式规范，适当保留冗余数据。 其余范式BCNF-BC范式关系模式R<U,F>中，若每一个决定因素都蕴含码，则R<U,F>属于BCFN。 即： 所有非主属性对每一个码都是齐全函数依赖；所有主属性对每一个不蕴含它的码也是齐全函数依赖；没有任何属性齐全函数依赖于非码的任何一组属性。4NF-第四范式限度关系模式的属性之间不容许有非平庸且非函数依赖的多值依赖。 5NF-第五范式必须满足第四范式。表必须能够合成为较小的表，除非那些表在逻辑上领有与原始表雷同的主键。个别在咱们设计关系型数据库的时候，最多思考到BCNF就够。！！！

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 MySQL InnoDB Cluster(MIC) 想必大家曾经十分相熟，由三个组件组成，别离为：MySQL Shell、MySQL Router 、MySQL MGR 。 MySQL Shell 用来进行MGR的日常运维，MySQL Router 对下层利用提供一个简略的读写拆散入口，MySQL MGR 则是用来寄存实在数据的多个 MySQL 实例。对应的架构如下： 那如果想针对 MIC 做一个容灾性能，该怎么做？如果你始终应用 MySQL 8.0，并且放弃 MySQL 版本始终为最新，那答案是必定的（最新的 MySQL 8.0 小版本为 8.0.28），新名字为 MySQL InnoDB Cluster Set（MICS）。 这个新个性其实就是基于纯正的 MIC 做容灾。 比方北京上地一套 MIC 对外提供服务，东直门另外一套 MIC 用来做灾备，两套 MIC 通过专用复制通道clusterset_replication来同步数据。 截取官网的架构如下： MICS 尽管看起来挺好，然而限度很多，几个次要限度如下：MICS 的最大个性是高可用，而不是一致性。因为数据传输依赖传统的 MySQL 异步复制（不能应用半同步），无奈防止异步复制的缺点：数据提早、数据一致性、须要手动故障转移等等。从库不能是已有的 MIC ，必须新建。所以在搭建 MICS 前，得想方法解决已有数据的保留问题。MICS 外部 MIC 限度为单主模式，不能多主。MICS 外部只有一套 MIC 对外提供服务，其余只能作为备库。只反对 MySQL 8.0 。我来简略演示下搭建过程：（为了简略起见，没有蕴含 MySQL ROUTER 组件）筹备至多6台 MySQL 实例。（端口别离为3381、3382、3383、3384、3385、3386） MySQL Py > for i in range(3381,3387): -> dba.deploy_sandbox_instance(i,{"password":"root"}) -> A new MySQL sandbox instance will be created on this host in /root/mysql-sandboxes/3381 ...端口3381、3382、3383 搭建一套 MGR ，名字为 ytt-rc1 。 MySQL Py > \c root:root@localhost:3381 Creating a session to 'root@localhost:3381' ... Server version: 8.0.28 MySQL Community Server - GPL ... MySQL localhost:3381 ssl Py > rc1 = dba.create_cluster('ytt-rc1'); A new InnoDB cluster will be created on instance 'localhost:3381'. ... MySQL localhost:3381 ssl Py > rc1.add_instance("root:root@localhost:3382",{"recoveryMethod":"clone"}) ... MySQL localhost:3381 ssl Py > rc1.add_instance("root:root@localhost:3383",{"recoveryMethod":"clone"}) ...创立一套 MICS ，命名为：ytt-rc-set ，主库为 ytt-rc1 。 MySQL localhost:3381 ssl Py > rc1_set = rc1.create_cluster_set('ytt-rc-set') A new ClusterSet will be created based on the Cluster 'ytt-rc1'. * Validating Cluster 'ytt-rc1' for ClusterSet compliance. * Creating InnoDB ClusterSet 'ytt-rc-set' on 'ytt-rc1'... * Updating metadata... ClusterSet successfully created. Use ClusterSet.create_replica_cluster() to add Replica Clusters to it.查看 MICS 状态： 名字为 ytt-rc-set 、集群角色为 primary 、对应主实例为 127.0.0.1:3381 、状态为 healthy 。 MySQL localhost:3381 ssl Py > rc1_set.status() { "clusters": { "ytt-rc1": { "clusterRole": "PRIMARY", "globalStatus": "OK", "primary": "127.0.0.1:3381" } }, "domainName": "ytt-rc-set", "globalPrimaryInstance": "127.0.0.1:3381", "primaryCluster": "ytt-rc1", "status": "HEALTHY", "statusText": "All Clusters available."接下来为 ytt-rc-set 增加从库，从库必须不属于任何 MIC 。创立 MICS 治理用户，用来同步主库数据： ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。前情介绍：咱们都晓得登录MySQL数据库时，连贯层接入数据库须要通过mysql.user表中，用户名明码的验证能力登录数据库。 如果mysql.user中不存在此用户或者明码不正确，则会返回谬误提醒。如果mysql.user数据库表中没有对应的账号，咱们能不能登录数据库呢？ 明天咱们来介绍一下如何来应用Linux操作系统用户，通过验证插件映射MySQL内的账号，登录数据库治理的办法。 操作环境：操作系统：centos 7.6 MySQL版本：MySQL Enterprise Server 8.0.27 咱们边操作边介绍其工作过程。 1、首先建设对应的PAM文件PAM验证文件配置目录在linux上的/etc/pam.d/ 目录下 [root@localhost ~]# ls /etc/pam.d/atd crond gdm-autologin gdm-pin mysql-pam password-auth postlogin rhn_register smartcard-auth subscription-manager su-l vlockchfn cups gdm-fingerprint gdm-smartcard mysql-pam2 password-auth-ac postlogin-ac runuser smartcard-auth-ac subscription-manager-gui system-auth vmtoolsdchsh fingerprint-auth gdm-launch-environment liveinst other pluto ppp runuser-l sshd sudo system-auth-ac xserverconfig-util fingerprint-auth-ac gdm-password login passwd polkit-1 remote setup su sudo-i systemd-user编辑文件内容如下： [root@localhost ~]#touch /etc/pam.d/mysql-pam[root@localhost ~]# vim/etc/pam.d/mysql-pam#%PAM-1.0auth include password-auth account include password-auth1.1 什么是PAM？PAM全称Pluggable Authentication Modules可插入的验证模块，其用处是可能使应用程序与认证机制拆散。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。导语在数据检索的过程中，常常会有多个列的匹配需要，明天介绍下联结索引的应用以及最左匹配准则的案例。 最左匹配准则作用在联结索引中，如果表中有一个联结索引（tcol01,tcol02,tcol03），只有当SQL应用到tcol01、tcol02索引的前提下，tcol03的索引才会被应用；同理只有tcol01的索引被应用的前提下，tcol02的索引才会被应用。 上面咱们来列举几个例子来阐明。 步骤应用 mysql_random_data_load 创立测试数据建库和建表 CREATE DATABASE IF NOT EXISTS test;CREATE TABLE `test`.`t3` ( `id` int(11) NOT NULL AUTO_INCREMENT, `tcol01` tinyint(4) DEFAULT NULL, `tcol02` smallint(6) DEFAULT NULL, `tcol03` mediumint(9) DEFAULT NULL, `tcol04` int(11) DEFAULT NULL, `tcol05` bigint(20) DEFAULT NULL, `tcol06` float DEFAULT NULL, `tcol07` double DEFAULT NULL, `tcol08` decimal(10,2) DEFAULT NULL, `tcol09` date DEFAULT NULL, `tcol10` datetime DEFAULT NULL, `tcol11` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `tcol12` time DEFAULT NULL, `tcol13` year(4) DEFAULT NULL, `tcol14` varchar(100) DEFAULT NULL, `tcol15` char(2) DEFAULT NULL, `tcol16` blob, `tcol17` text, `tcol18` mediumtext, `tcol19` mediumblob, `tcol20` longblob, `tcol21` longtext, `tcol22` mediumtext, `tcol23` varchar(3) DEFAULT NULL, `tcol24` varbinary(10) DEFAULT NULL, `tcol25` enum('a','b','c') DEFAULT NULL, `tcol26` set('red','green','blue') DEFAULT NULL, `tcol27` float(5,3) DEFAULT NULL, `tcol28` double(4,2) DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB;建联结索引 ...

好久不见，《墨天轮最受欢迎的技术文档》系列文章回归啦！本期主题数据库监控篇，心愿可能帮忙到大家！此外，为感激大家反对，原文文末也给大家带来了返场福利，欢送大家进入原文参加~数据库监控是许多DBA敌人必备的技能，通过对一些要害指标的跟踪能够及时获取数据库以后运行性能和资源分配状况，由此剖析查明问题呈现的地位和确切工夫并进行调整，以排除潜在问题或解决理论问题。 本文整顿了墨天轮社区上一些数据库监控的根底指南（内容涵盖监控指标类型及SQL、监控体系的搭建等）、监控工具介绍和各行业实际案例分享，次要波及 Oracle、MySQL 以及 PostgreSQL 等数据库，欢送大家下载、补充。让咱们一起通过全方位监控进步性能和可用性！ 监控根底指南- OracleOracle 罕用性能监控SQL语句 Oracle 数据库监控指标 索引监控步骤 监控哪些外键未建索引 Oracle 定期清理告警日志文件脚本 - PostgreSQL、MySQL及其他openGauss 最佳参数实际+ openGauss 与 PostgreSQL 比照+ openGauss 罕用监控工具 PostgreSQL 日常保护、监控、排错、优化 MySQL 数据库监控指标 PostgreSQL 数据库监控指标 GaussDB 200 监控 mongodb集群监控和运维 基于 Prometheus + Grafana 监控 SQLServer 数据库  监控工具应用Oracle 轻量级实时监控工具-oratop Zabbix 监控 Oracle（配置应用阐明） Zabbix 监控常用命令 Oracle 工具：OEM 监控  实际案例分享大规模PostgreSQL集群监控实战——开源PG监控解决方案 Zabbix-金融行业监控零碎开源之路 天眼-数字化利用实时监控解决方案 京东APP性能优化及监控能力实战 云原生体系下的监控能力演进 如何从零疾速搭建一整套监控体系（日志采集+主机+数据库） 在这里给大家举荐【墨天轮会议文档专栏】，超多行业大会PPT都有收录：https://www.modb.pro/docTopic本文未对墨天轮社区内容作齐全统计，仅摘选局部精品内容，更多内容大家自行能够搜寻获取。 正当、适时的监控能够帮忙大家疾速查明数据库性能差、不稳固等问题的起因，甚至能够通过后期危险指标的呈现来预测将来的问题，心愿大家都能做好监控、防备于未然！ 本文所有内容已珍藏至合辑【墨天轮最受欢迎的技术文档-监控篇】，点击即可珍藏。 浏览原文：https://www.modb.pro/db/394465（文末福利派送中） 查看更多精彩内容尽在墨天轮，围绕数据人的学习成长提供一站式的全面服务，打造集新闻资讯、在线问答、流动直播、在线课程、文档阅览、资源下载、常识分享及在线运维为一体的对立平台，继续促成数据畛域的常识流传和技术创新。 关注官网公众号： 墨天轮、 墨天轮平台、墨天轮成长营、数据库国产化 、数据库资讯

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。导语在日常开发过程中难免会应用到第三方库或者须要将局部库拆散另外存储，如果将库与代码放在一起难免会造成工程宏大，此时就能够采纳将库与源码拆散的形式，在编译时依据状况来判断是否须要下载。 步骤上面来解析下具体操作步骤，以下以 oracle oci 库下载为例。 UNSET命令初始化本次编译用到的参数变量 #初始化oci库压缩包门路参数LOCAL_OCI_LIB_ZIP UNSET(LOCAL_OCI_LIB_ZIP CACHE) #初始化oci库解压门路参数LOCAL_OCI_LIB_DIR UNSET(LOCAL_OCI_LIB_DIR CACHE) #初始化oci库压缩包下载门路参数LOCAL_OCI_LIB_ZIP_DL_DIR UNSET(LOCAL_OCI_LIB_ZIP_DL_DIR CACHE)SET命令设置参数初始门路或名称 #设置oci库存放文件夹名称 SET(OCI_LIB_NAME "oci_x86_lib") # 设置oci库压缩包解压文件夹名称 SET(OCI_LIB_UNZIP_DIR_NAME ${OCI_LIB_NAME}) #设置oci库头文件寄存文件夹名称 SET(LOCAL_OCI_INCLUDE_DIR_NAME "oci_include") #设置oci库压缩包名称 SET(OCI_LIB_ZIP_NAME "oci_lib.tar.gz") #设置oci库近程下载地址URL SET(OCI_LIB_DOWNLOAD_URL "http://xxxxxx/oci_lib.tar.gz") #设置oci库近程下载超时工夫 SET(DOWNLOAD_OCI_LIB_TIMEOUT 600 CACHE STRING "Timeout in seconds when downloading oci_lib.")FIND_FILE命令在门路下查找对应名称文件或文件夹是否存在，判断库是否曾经下载或解压 #判断压缩包在文件夹ora_oci_lib下是否曾经存在 FIND_FILE(LOCAL_OCI_LIB_ZIP NAMES ${OCI_LIB_ZIP_NAME} PATHS "ora_oci_lib" NO_DEFAULT_PATH ) #判断压缩包在文件夹ora_oci_lib下是否曾经解压 FIND_FILE(LOCAL_OCI_LIB_DIR NAMES ${OCI_LIB_NAME} PATHS "ora_oci_lib" NO_DEFAULT_PATH ) #判断压缩包下载门路 FIND_FILE(LOCAL_OCI_LIB_ZIP_DL_DIR NAMES "" PATHS "ora_oci_lib" NO_DEFAULT_PATH )MESSAGE命令输入相应步骤的提示信息 #输入以后正进行的操作步骤信息 MESSAGE(STATUS "Checking dblink ${OCI_LIB_UNZIP_DIR_NAME} + ${LOCAL_OCI_LIB_ZIP} .....")判断以后压缩包是否存在，如果不存在则开始依据设定的URL地址进行下载 #判断压缩包是否曾经存在 IF(NOT LOCAL_OCI_LIB_ZIP) #不存在则进行下载操作，输入操作提示信息 MESSAGE(STATUS "Downloading ${OCI_LIB_ZIP_NAME} to ${LOCAL_OCI_LIB_ZIP_DL_DIR}") #从设定URL地址下载相应的压缩包 FILE(DOWNLOAD ${OCI_LIB_DOWNLOAD_URL} ${LOCAL_OCI_LIB_ZIP_DL_DIR}/${OCI_LIB_ZIP_NAME} TIMEOUT ${DOWNLOAD_OCI_LIB_TIMEOUT} STATUS ERR SHOW_PROGRESS ) #判断下载是否存在谬误 IF(ERR EQUAL 0) #如果下载无谬误则设置压缩包名称标记下载胜利 SET(LOCAL_OCI_LIB_ZIP "${LOCAL_OCI_LIB_ZIP_DL_DIR}/${OCI_LIB_ZIP_NAME}") ELSE() #下载谬误输入相干的提示信息 MESSAGE(STATUS "Download failed, error: ${ERR}") MESSAGE(FATAL_ERROR "You can try downloading ${OCI_LIB_DOWNLOAD_URL} manually" " using curl/wget or a similar tool" ) ENDIF() ENDIF()依据设定标记判断是否下载胜利，如果下载胜利则对压缩包文件进行初步的校验，无问题则进行解压缩操作 IF(LOCAL_OCI_LIB_ZIP ) #输入相应的提示信息校验解压门路等 MESSAGE(STATUS "Checking dblink ${OCI_LIB_UNZIP_DIR_NAME} + ${LOCAL_OCI_INCLUDE_DIR_NAME} + ${LOCAL_OTL_INCLUDE_DIR_NAME} ") IF(NOT EXISTS "${LOCAL_OCI_LIB_ZIP_DL_DIR}/${OCI_LIB_UNZIP_DIR_NAME}" OR NOT EXISTS "${LOCAL_OCI_LIB_ZIP_DL_DIR}/${LOCAL_OCI_INCLUDE_DIR_NAME}" OR NOT EXISTS "${LOCAL_OCI_LIB_ZIP_DL_DIR}/${LOCAL_OTL_INCLUDE_DIR_NAME}" ) #输入提示信息筹备进行解压缩 MESSAGE(STATUS "cd ${LOCAL_OCI_LIB_ZIP_DL_DIR}; tar xfz ${LOCAL_OCI_LIB_ZIP}") #获取已下载的压缩包大小做根本的判断 GET_FILE_SIZE(${LOCAL_OCI_LIB_ZIP} LOCAL_ZIP_SIZE) #如果压缩包大小为0则输入对应的错误信息 IF(LOCAL_ZIP_SIZE EQUAL 0) #移除损坏压缩包，重置相应的参数 FILE(REMOVE ${LOCAL_OCI_LIB_ZIP}) UNSET(LOCAL_OCI_LIB_ZIP) UNSET(LOCAL_OCI_LIB_ZIP CACHE) MESSAGE(FATAL_ERROR "${OCI_LIB_ZIP_NAME} is zero length. Deleting it.") ELSE() #下载文件根本无问题，进入解压门路开始解压压缩包 EXECUTE_PROCESS( COMMAND ${CMAKE_COMMAND} -E tar xfz "${LOCAL_OCI_LIB_ZIP}" WORKING_DIRECTORY "${LOCAL_OCI_LIB_ZIP_DL_DIR}" RESULT_VARIABLE tar_result ) #判断解压是否胜利 IF (tar_result MATCHES 0) #解压胜利设置胜利标记参数 SET(OCI_LIB_FOUND 1 CACHE INTERNAL "") ELSE() #解压失败输入相应谬误提示信息 MESSAGE(STATUS "Failed to extract files.\n" " Please try downloading and extracting yourself.\n" " The url is: ${OCI_LIB_DOWNLOAD_URL}") ENDIF() ENDIF() ENDIF() ENDIF() 至此第三方库曾经下载解压实现，后续能够依据本人源码，设置对应的链接门路进行编译 INCLUDE_DIRECTORIES 命令能够设置援用头文件包含门路 LINK_DIRECTORIES 命令能够设置援用第三方库文件所在门路编译实现后能够应用INSTALL命令将后续利用运行时须要应用的库，拷贝到指定的装置目录 CMAKE_INSTALL_PREFIX 为设置的装置门路 OCI_LIB_NAME为库搁置文件夹 # copy lib INSTALL( FILES ${allCopyFiles} DESTINATION ${CMAKE_INSTALL_PREFIX}/${OCI_LIB_NAME} )Enjoy GreatSQL :) ...

热衷学习，热衷生存！ 积淀、分享、成长，让本人和别人都能有所播种！ 一、什么是索引？索引有什么作用？索引是一种用于疾速查问和检索数据的数据接口。罕用的索引数据结构有：B树、B+树、Hash表。 索引的作用就相当于目录的作用。比方：咱们在查字典的时候如果没有目录，咱们就只能一页一页去查找字，速度很慢，如果有目录，咱们只须要查找字所在的页数，而后间接翻到那一页就能够了。 索引的长处毛病长处索引能够让咱们更快的检索出咱们须要查找的数据，这也是创立索引的最次要的起因。能够通过创立惟一索引，保障数据库行数据的唯一性。毛病创立索引和保护索引须要消耗更多的工夫。当对表中的数据进行增删改时候，如果数据有索引，那么索引也须要动静的批改，会升高SQL执行效率。索引须要应用物理文件贮存，会耗费肯定的空间。然而，应用索引肯定能进步查问性能吗？ 大多数状况下，索引查问都是比全表扫描的速度要快的，然而如果数据库的数据量不大，那么应用索引不肯定能带来很大的晋升。 二、索引的底层数据结构罕用的索引底层数据结构有三种：B树、B+树、Hash表。 Hash表哈希表就是键值对（key-value）的汇合，通过键（key）能够疾速查找到对应的值（value），查问速度靠近O(1)。 哈希表通过哈希算法（也叫散列算法）计算key对应的index，而后通过index就能够失去对应的value。哈希算法有一个Hash抵触的问题，也就是多个key最初失去的index雷同，通常应用链地址法后果Hash抵触的问题，就是将哈希抵触的数据寄存在链表中。比方JDK1.8之前你的HashMap就是通过链地址法来解决哈希抵触，JDK1.8当前HashMap为了缩小链表过长搜寻工夫过长引入了红黑树。 既然哈希表这么快，为什么MySQL没有应用其作为索引的数据结构呢？ 次要有以下两个起因： Hash抵触问题：咱们下面也提到过Hash 抵触了，不过对于数据库来说这还不算最大的毛病。Hash表不反对程序查问和范畴查问：这是Hash表最大的毛病，也是MySQL不将Hash表作为索引数据结构最重要的起因。B树&B+树B树也称B-树，全称为多路均衡查找树，B+树是B树的一种变体。 B树&B+树之间的差别B树的所有节点既寄存键key也存放数据data，而B+树只有叶子节点寄存key和data，非叶子节点只寄存key。B树的叶子节点都是独立的，而B+树的叶子节点都有一条援用链指向它相近的节点。B树的检索过程是相当于对范畴内的每个节点的关键词做二分查找法，可能还没到叶子节点检索就完结了，而B+树的检索效率就很稳固，任何查找都是从根节点到叶子节点的过程，叶子节点的程序检索很显著。为什么B+ 树比B 树更适宜作为索引？B+树的磁盘读写代价更低 B+树的data都寄存在叶子节点，非叶子节点只寄存key，而B树的分支节点既寄存data也寄存key，这将导致B+树的层高会小于B树，所以B+树均匀的IO次数会小于B树。 B+树的查问效率更稳固 B树查问可能在非叶子节点就完结了，而B+树因为data只寄存在叶子节点，所以查问必须从根节点到叶子节点，所以查问效率更稳固。 B+树更便于遍历 因为B+树的data都寄存在叶子节点，非叶子节点只寄存key，所以只需遍历叶子节点即可，而B树非叶子夜店也寄存data，要找到具体的数据须要进行二分查找。 B+树更善于范畴查问 B+树叶子节点寄存data，且data是按顺序排列的双向链表，所以范畴查问更快。而B树范畴只能二分查找。 B+树占用内存空间小 B+树非叶子节点不寄存data比拟小，在内存无限的状况下，相比于B树索引能够加载更多B+ 树索引。 三、索引类型主键索引（Primary Key）数据表的主键列应用的就是主键索引。 一张数据表有且只有一个主键，并且主键不能为null，不能反复。 在MySQL的InnoDB的表中，如果表没有设置主键时，InnoDB会主动先检查表中是否有惟一索引（Unique Key）且不存在为null的字段，如果有则抉择该字段为默认的主键，如果没有InnoDB会主动创立一个6Byte的自增主键。 主键索引如下图： 二级索引（辅助索引）二级索引又称为辅助索引，二级索引的叶子节点存储的数据是主键。当应用二级索引的时候，先通过二级索引查问到主键，而后通过主键获取数据。 当咱们创立所以的时候须要抉择索引类型，比方：惟一索引、一般索引、前缀索引、全文索引，这些都是属于二级索引。 惟一索引（Unique Key）：惟一索引也是一种束缚。惟一索引的属性列不容许呈现反复的数据，然而容许数据为Null，一张表容许创立多个惟一索引。应用惟一索引的目标大部分是为了保障该属性列的唯一性，而不是为了查问效率。一般索引（Index）：一般索引的惟一作用就是为了疾速查找数据，一张表容许创立多个一般索引，并容许数据反复和为null。前缀索引（Prefix）：前缀索引只实用于字符串类型的数据。前缀索引是对文本的前几个字符创立索引，相比一般索引建设的数据更小。全文索引（Full Text）：全文索引次要是为了检索大文本数据中的关键字信息，是目前搜索引擎数据库应用的一种技术。二级索引如下图： 四、聚簇索引和非聚簇索引聚簇索引聚簇索引是索引构造和数据寄存在一起的索引，主键索引属于聚簇索引。 在MySQL中，InnoDB引擎的表的.idb文件就蕴含了该表的索引和数据，该表的索引B+树非叶子节点寄存索引，叶子节点寄存索引和索引对应的数据。 聚簇索引的长处聚簇索引的查问速度十分快，因为B+树本就是一颗多均衡二叉树，叶子节点寄存索引和数据，非叶子节点寄存索引，且叶子节点也是有序的，定位到索引就能够失去数据。聚簇索引的毛病依赖有序的数据：因为B+树是多路均衡树，如果索引的数据不是有序的，那么就须要在插入时排序，如果数据是整数类型还好，否则相似字符串或者UUID这种又长又难比拟的数据，插入或者查找的速度必定慢。更新代价大：如果对索引列的数据批改时，那么对应的索引也须要批改，而且聚簇索引的叶子节点还寄存这数据，批改代价很大，所以对于主键索引来说，主键个别是不能够被批改的。非聚簇索引下面说到的二级索引（辅助索引）都是非聚簇索引，非聚簇索引叶子节点只存储主键值。首先通过二级索引找到主键值，再通过主键索引找到数据。 非聚簇索引的长处更新代价小：因为非聚簇索引的叶子节点值寄存索引不存放数据，所以更新代价小。非聚簇索引的毛病跟聚簇索引一样也是依赖有序的数据。可能会二次查问（回表）：这应该是非聚簇索引最大的毛病，当通过索引查问到对应的主键时，可能还须要依据主键再到表中查问。聚簇索引和非聚簇索引如下图： 非聚簇索引肯定要回表查问吗（笼罩索引）？举个栗子，用户筹备应用SQL查问用户名，而用户名字刚好创立了索引，查问SQL如下：SELECT name FROM TABLE WHERE name = 'zhangsan';那么这个索引的key自身就是name，查问对应的name间接返回就行了，无需返回表查问。即便是 MYISAM 也是这样，尽管 MYISAM 的主键索引的确须要回表， 因为它的主键索引的叶子节点寄存的是指针。然而如果 SQL 查的就是主键呢? SELECT id FROM TABLE WHERE id = 1;主键索引自身的 key 就是主键，查到返回就行了。这种状况就称之为笼罩索引了。 ...

简介：日志是MySQL数据库的重要组成部分，记录着数据库运行期间各种状态信息，次要包含谬误日志、查问日志、慢查问日志、事务日志、二进制日志几大类。在此重点关注二进制日志bin log和事务日志(包含redo log 和 undo log )。 一、概念redo log、undo log&bin log 重做日志（redo log）、回滚日志（undo log）、二进制日志（binlog）的基本概念。 redo log 是物理日志，undo log 和 binlog 是逻辑日志；binlog二进制日志是server层的无论MySQL用什么引擎都会有的，次要是作主从复制，工夫点复原应用；redo log重做日志是InnoDB存储引擎层的，用来保障事务平安；undo log回滚日志保留了事务产生之前的数据的一个版本，能够用于回滚，同时能够提供多版本并发管制下的读（MVCC），也即非锁定读。 crash-safe InnoDB 就能够保障即便数据库产生异样重启，之前提交的记录都不会失落，这个能力称为 crash-safe。 举个列子：当咱们批改的时候，写完内存了（buffer），但数据还没真正写到磁盘的时候。此时咱们的数据库挂了，咱们能够对数据进行复原。 二、bin log binlog 用于记录数据库执行的写入性操作(不包含查问)信息，以二进制的模式保留在磁盘中。binlog 是 mysql的逻辑日志，并且由 Server 层进行记录，应用任何存储引擎的 mysql 数据库都会记录 binlog 日志。能够简略的了解为它存储着每条变更的SQL语句。 能够通过binlog来对数据进行复原；binlog 能够用于主从复制中，从库利用主库上的 binlog 进行重播，实现主从同步。用于数据库的基于工夫点、位点等的还原操作。binlog 的模式分三种：Statement、Row、Mixed；binlog 是通过追加的形式进行写入的，能够通过max_binlog_size 参数设置每个 binlog文件的大小，当文件大小达到给定值之后，会生成新的文件来保留日志；逻辑日志：能够简略了解为记录的就是sql语句；物理日志：mysql 数据最终是保留在数据页中的，物理日志记录的就是数据页变更。 binlog应用场景 在理论利用中， binlog 的次要应用场景有两个，别离是 主从复制 和 数据恢复。 主从复制 ：在 Master 端开启 binlog ，而后将 binlog发送到各个 Slave 端， Slave 端重放 binlog 从而达到主从数据统一。数据恢复 ：通过应用 mysqlbinlog 工具来复原数据。 ...

有这么一个表： CREATE TABLE `tiny_url` ( `id` bigint NOT NULL AUTO_INCREMENT, `user_id` int NOT NULL, `short_uuid` varchar(255) NOT NULL, `video_id` int NOT NULL, `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `tinyurl_short_uuid` (`short_uuid`), UNIQUE KEY `tinyurl_user_id_video_id` (`user_id`,`video_id`)) ENGINE=InnoDB AUTO_INCREMENT=26 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci操作一：我在一个事务中应用应用 SQL: begin 先开启是一个事务，在抉择插入：insert into tiny_url (user_id,video_id,short_uuid) values (100,300,'ilikeyou') 操作二：并在另一个事务中应用另一个 SQL：insert into tiny_url (user_id,video_id,short_uuid) values (100,300,'ilikeyou too') ...

大型后盾零碎往往都采纳分布式架构，该架构要思考的外围问题之一是零碎高可用如何设计。PolarDB-X 在 4 月 1 日公布了 2.1.0 版本，该版本引入的 X-Paxos 多正本能力使得零碎的高可用能力有了质的晋升。本期分享将用 PolarDB-X 搭建一个高可用零碎，通过间接 kill 容器模仿节点故障，以察看 PolarDB-X 的主动复原状况。 PolarDB-X 云原生分布式数据库已在 GitHub 开源，欢送关注：https://github.com/ApsaraDB/g... 直播工夫 4 月 15 号（本周五）16:00～17:00 参加形式 钉钉扫描下图二维码退出 PolarDB-X 开源交换群 讲师介绍 吴学强（燧木） 阿里云 PolarDB-X 云原生分布式数据库技术负责人之一，毕业于浙江大学计算机学院，趣味宽泛，对操作系统、密码学、分布式系统等均有涉猎。2017 年退出 PolarDB-X 团队进行高并发低提早的 MySQL 分布式相干零碎开发工作，目前负责 PolarDB-X 的云原生底座打造、生态系统连贯、开源等凋谢生态构建工作。

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。导语有时候用 Postman 接口测试须要获取MySQL的查问后果做接口输入的校验，这里介绍下 Postman 通过 Restful API 接口拜访 MySQL 的工具xmysql的应用办法。 步骤一、应用nmp装置xmysql注：npm的装置和配置自行百度，这里次要讲xmysql，就不赘述了 C:\Users\wmp>node -vv12.16.3C:\Users\wmp>C:\Users\wmp> npm install -g xmysqlC:\Users\wmp\AppData\Roaming\npm\xmysql -> C:\Users\wmp\AppData\Roaming\npm\node_modules\xmysql\bin\index.js> es5-ext@0.10.59 postinstall C:\Users\wmp\AppData\Roaming\npm\node_modules\xmysql\node_modules\es5-ext> node -e "try{require('./_postinstall')}catch(e){}"+ xmysql@0.5.1added 131 packages from 68 contributors in 22.806s装置完输出xmysql能够查看具体参数，同时也示意装置胜利 C:\Users\wmp>xmysqlUsage: index [options]Options: -V, --version output the version number -h, --host <n> hostname of database / localhost by default -u, --user <n> username of database / root by default -p, --password <n> password of database / empty by default -d, --database <n> database schema name -r, --ipAddress <n> IP interface of your server / localhost by default -n, --portNumber <n> port number for app / 3000 by default -o, --port <n> port number for mysql / 3306 by default -S, --socketPath <n> unix socket path / not used by default -s, --storageFolder <n> storage folder / current working dir by default / available only with local -i, --ignoreTables <n> comma separated table names to ignore -a, --apiPrefix <n> api url prefix / "/api/" by default -y, --readOnly readonly apis / false by default -c, --useCpuCores <n> use number of CPU cores (using cluster) / 1 by default -h, --help output usage information Examples: $ xmysql -u username -p password -d databaseSchemaError: password for database is missingError: database name is missingC:\Users\wmp>连贯数据库：xmysql -h host_name -o port -u user_name -p user_password -d database_name ...

剖析类查问即使是TPC-H中的简略剖析查问，PostgreSQL的性能都要远远优于MySQL。 昆仑数据库继承并扩大了PostgreSQL在剖析类SQL查询处理方面的弱小能力，能够反对TPC-H和TPC-DS的所有查问。同时，一个昆仑数据库集群能够治理的数据规模远远大于 一个PostgreSQL 实例。一、测试环境服务器配置：PostgreSQL和MySQL别离部署在一台：亚马逊m5.4xlarge（CPU 8cores 16 Threads,内存 64G，存储gp3, 通用型SSD卷 3000IOPS ，125 MB/s 吞吐量）上。 软件版本： PostgreSQL：PostgreSQL 12.7 on x86_64-koji-linux-gn MySQL: percona 8.0.26-16 数据库参数配置： PostgreSQL：shared_buffers 8192MB MySQL: innodb_buffer_pool_size 8192MB 测试背景：PostgreSQL和MySQL采纳默认的装置配置，只调整了内存参数， 整个测试过程PostgreSQL没有任何优化行为。 二、测试数据表的信息： 1张事实表：lineorder 4张维度表：customer，part，supplier，dates 表占用操作系统存储空间：19G 数据查问：11条规范SQL查问测试语句（统计查问、多表关联、sum、简单条件、group by、order by等组合形式）。 具体SQL语句：附录1 TPC-H测试SQL。 三、测试后果 MySQL错误信息：ERROR 3 (HY000): Error writing file '/kunlun2/data10/6010/tmp/MYfd=332'(OS errno 28-No space left on device) 剖析及总结：通过比照同一SQL语句在PostgreSQL和MySQL执行打算，会发现MySQL的执行打算没有采纳最优的join秩序及并行操作，导致性能差。 譬如Q2.1 MySQL执行打算： 执行打算剖析：上述执行打算首先将几个维度表做join（dates和supplier和part),失去的后果再与事实表lineorder join,因此得出了一个超级大的两头后果集，数据量达到10的15次方的数量（查问打算第五行返回的 rows），最终导致临时文件耗尽磁盘空间而未能实现查问。 优化计划：通过在SQL语句中强制指定表join秩序：首先与part表join失去一个最小的数据子集，而后再与supplier和dates join,逐渐放大范畴，查问语句及查问打算的成果如下： explain format=tree selectsum(lo_revenue) as lo_revenue, d_year as year, p_brand from ((lineorderstraight_join part on lo_partkey = p_partkey) straight_join supplier on lo_suppkey = s_suppkey) straight_join dates ON lo_orderdate = d_datekey where p_category ='MFGR#12' and s_region = 'AMERICA' group by year, p_brand order by year,p_brand;在MySQL上指定join秩序， ...

昆仑分布式数据库应用MySQL做存储节点，称为kunlun-storage。Kunlun-storage目前最新版本基于percona-mysql-8.0.26开发，在此社区版本根底上，咱们补充了MySQL的XA事务和binlog 复制方面的容错和数据一致性破绽，减少了kunlun数据库集群须要的若干性能，并且加强了其性能。咱们也始终在合并上游版本，继续会集MySQL社区的最新成绩到kunlun-storage中。 在Kunlun-storage Fullsync机制开发实现之前，咱们始终在应用MySQL Group Replication（MGR）实现存储集群高可用。为了实现更好的数据写入性能包含更高的吞吐量和更短的延时，以及升高对存储系统和网络带宽的耗费，并且在高可用方面实现更加灵便的策略，咱们在kunlun-storage中设计并开发了Fullsync高可用机制。 Kunlun-storage Fullsync性能简介Kunlun-storage Fullsync详情和原理昆仑数据库的Fullsync机制是一种存储集群的高可用机制，它用于确保一个存储集群在产生节点故障、网络分区等问题时，该集群中存在可用的备机含有所有向用户确认提交胜利的事务的binlog，以便能够按需选举出新的主节点，确保集群继续能够写入，实现高可用。 昆仑数据库的Fullsync机制基于MySQL久经考验的Row Based Replication（RBR）binlog复制机制，实现了主备复制的强同步，也就是确保主节点上提交的每一笔事务 --- 包含显式一般事务（即begin 。。。Commit），autocommit的update/delete/insert语句，以及XA事务 --- 在实现外部的事务提交流程（即engine log和binlog flush&sync和engine commit 这三个阶段）之后，继续期待直到收到了足够数量的备机的确认（ACK）之后，才向客户端（在昆仑数据库中就是计算节点）确认这个事务胜利提交。 一个ACK是一个binlog文件标识和偏移值的组合，它代表的是这个地位之前的binlog都曾经被这个备机收到并且长久存储（刷盘）。这样，所有那些在主节点的binlog文件中其binlog存储在此地位之前的事务都失去了确认，它们的提交操作就都能够返回胜利状态给客户端了。 一个备机发送该ACK是向其主节点确认收到并长久化（刷盘）了一组事务的binlog到其relay log文件中。只有主节点收到这个确认，才向客户端返回事务提交胜利的确认状态，客户端收到此后果后能力发送下一条SQL语句给昆仑数据库。只有向客户端返回事务胜利提交（或prepare），昆仑分布式数据库才有任务保障这样的事务的改变不失落（即ACID的D，Durability）。 Kunlun-storage Fullsync的前提条件Kunlun-storage Fullsync机制须要一组特定的参数组合能力失常工作。Kunlun-storage自带的参数配置模版文件中含有通过咱们开发团队调优之后的参数设置，其中蕴含了fullsync性能须要的参数设置。 Kunlun数据库集群的所有存储节点实例都是应用其自带的参数模版创立的。具体来说包含一下参数： gtid_mode=on, enforce_gtid_consistency=1，log_slave_updates=ONbinlog_format=row, i.e. 应用Row based replication所有主备节点都应用binlog会话都应用binlog，即 sql_log_bin=true。如果把一个会话的 sql_log_bin设置为false则此会话中fullsync机制不工作然而其余会话中fullsync依然工作。enable_fullsync = ON 关上fullsync全局开关thread_handling=2或者0, 即kunlun-storage的fullsync机制实用于线程池（thread_handling=2)以及每个线程解决一个事务（thread_handling=0)的状况。Kunlun-storage Fullsync的功能设计与实现1. 主节点kunlun-storage的fullsync机制是一种after-commit的同步模式。在解决用户会话thd的工作线程thr 实现事务T提交或者prepare（XA prepare）并且还未向客户端确认胜利（即发送OK包）之前，主节点查看事务T的binlog是否曾经收到了足够数量的备机的ACK（备机的ACK 确认收到若干个事务的binlog） --- 此条件称为开释条件。 Fullsync_consistency_level定义了主节点须要让每个事务期待多少个备机的ack，如果是0就不期待任何ack；如果大于0则期待这么多个备机的ack。 在昆仑数据库集群中，clustermgr会依据集群节点数量为每个master节点设置正当的Fullsync_consistency_level，通常的设定办法是对于一个2*n+1个节点的storage shard，那么设置Fullsync_consistency_level=n，这样就达到了简略少数，所以同时有n个节点隐没的状况下，集群依然能够失常写入。clustermgr也能够反对其余策略，比方要求所有备机全副确认等。 如果开释条件满足那么thr间接返回胜利状态给客户端并且实现本次申请解决，否则工作线程thr就把会话对象thd放到fullsync ack期待队列，而后去解决其余连贯中收到的申请。 主节点收到ACK后会对期待队列中的会话做开释条件查看，满足开释条件条件的会话会被开释，也就是返回胜利状态给客户端。在期待备机ACK的过程中，用户回话并不占用工作线程。 如果超时（fullsync_timeout)未收到足够的ack来开释一个期待的会话时，kunlun-storage有两种策略，由全局变量disable_fullsync_on_slave_ack_timeout来管制： A. 如果disable_fullsync_on_slave_ack_timeout=1，那么fullsync会主动进化为异步。这样后续期待的事务将不再做fullsync期待。当主节点再次收到备机ack后，会主动启用fullsync机制。 B. 如果disable_fullsync_on_slave_ack_timeout=0，那么fullsync期待超时的会话，会返回谬误（谬误号9000） 给客户端，对于昆仑数据库集群来说，就是计算节点收到了这个谬误，会触发主备切换。 如果主节点宕机时有某个事务T没有收到任何备机的ack，导致切换后新的主节点短少原来曾经在旧主机M0上 提交的T事务的binlog，并且这个老主节点M0随后重新加入集群， kunlun-storage会对M0做flashback（闪回），把T的改变及其binlog从实例的存储引擎（innodb）和binlog文件中去掉。 因为T并没有返回给客户端所以昆仑数据库并没有向客户端承诺T提交胜利了，因而咱们齐全能够把T闪回，并没有影响事务的durability。 2. 备节点备机收到事件组（event group，即binlog事务，包含一般显式事务，XA事务第一阶段，XA事务第二阶段，DDL语句，autocommit语句这几种类型。下文简称EG）的终止binlog事件（XID_EVENT, XA_PREPARE_LOG_EVENT或者DDL事务）后，它会决定是否须要把收到的若干个EG写到relay log文件并且刷到长久存储系统中（即flush&fsync relay log），而后发送ACK给主节点来确认长久化了这些收到的EG。 ...

一、零碎概述1.1 用处XPanel管理系统次要用于治理Kunlun Databases Cluster，监控集群节点以后的QPS和计算机的cpu等信息。 1.2 性能概述DBA管理系统次要蕴含登陆，首页，系统管理，集群治理，计算机管理，操作记录六大模块。 1.3 运行环境该零碎运行后盾于apache+PHP Version 7.4.3环境，前端应用vue编写。 1.4代码获取路径从github上获取代码，git clone https://github.com/zettadb/Ku...；monitor文件放在具备web服务的环境下，接着批改config下的database.php文件,把相应的ip和port改成本人的ip和port；本机已装置nodejs时(未装置请自行装置下),KunlunXPanel文件用cmd或者本人的编辑器关上，到src的同级目录下找到开发环境文件.env.development，把VUE_APP_BASE_API的ip和port改成本人的ip和port，生成环境的话，到.env.production下改ip和port；执行npm install，而后npm run dev运行即可。二、集群治理性能介绍2.1 集群治理集群治理模块是该零碎的重点性能之一，次要蕴含集群展现和集群列表信息两大块。集群展现页面次要展现的是单个集群的部署图信息，针对单个集群的操作；集群列表信息页面次要对整体集群进行操作，具备备份集群、复原集群、新增集群，删除集群的性能。 2.1.1 集群列表2.1.1.1 集群展现集群展现次要展现单个集群部署图，展现的是单个集群所蕴含的shard和计算节点，存储节点默认暗藏，点击+号能够开展查看，如图1，图2所示。图1 图2 能够点击不同集群后面的redio按钮对不同集群进行切换，如图3所示。图3点击集群中图标能够对该集群进行如下操作：新增存储集群，抉择计算机和正本数必填，正本数默认为所选机器数，如图4，图5所示；图4 图5 新增计算节点，抉择计算机，确认保留即可新增，如图6所示；图6 新增存储节点，抉择计算机，确认即可，如图7，图8所示；图7 图8 重做备机存储节点，抉择重做的机器，和抉择须要重做的备机节点，重做替换即可，如图9所示；图9删除存储集群，点击删除即可，如图10，图11所示；图10图11 存储节点启用、禁用、重启、删除、进入(即能够点击某个节点进入按钮，查看节点的Current QPS，InnoDB Buffer Pool等)，如图12所示，如点击进入，如图13，图14所示，其余操作如此，此处省略；图12图13 图14 计算节点启用、禁用、重启、删除、进入(即能够点击某个节点进入按钮，查看节点的Max Connections， Buffer ，Version等)，如图14所示，如点击进入，如图16，图17所示。图15图16 图17 2.1.1.2集群列表信息集群列表信息页面能够新增集群，删除集群，备份集群，复原集群（备份和复原下章节讲述）四大功能模块。 新增集群新增集群，点击新增按钮，填入信息后点击确认即可新增集群如图18，图19所示。图18 图19 新增集群胜利后，如图20所示。其中抉择计算机，高可用模式，shard个数，正本数，集群名称，缓冲池大小这几项为必填项，其余为可选项，点击更多按钮能够填入可选项信息，如图21，图22所示。图20 图21 图22 抉择计算机，这里的计算机是从计算机管理中增加胜利的计算机，如果发现抉择计算机这里为空或者还没有本人想要抉择的计算机，可先到计算机管理中增加计算机后 再来新增集群。高可用模式，分mgr和rbr两种。Shard个数，默认为所选的机器数可批改。正本数，默认为3。集群名称，用户输出，必填项。删除集群删除集群，页面左上角通过集群名称搜寻到须要进行删除操作的集群信息，而后点击该行左边的删除按钮删除即可。如图23，图24，图25所示，删除集群胜利后，如图26所示。*注：删除集群操作后，数据永恒失落，请审慎操作。 图23 图24 图25 图26 END昆仑数据库是一个HTAP NewSQL分布式数据库管理系统，能够满足用户对海量关系数据的存储管理和利用的全方位需要。 利用开发者和DBA的应用昆仑数据库的体验与单机MySQL和单机PostgreSQL简直完全相同，因为首先昆仑数据库反对PostgreSQL和MySQL双协定，反对规范SQL:2011的 DML 语法和性能以及PostgreSQL和MySQL对规范 SQL的扩大。同时，昆仑数据库集群反对程度弹性扩容，数据主动拆分，分布式事务处理和分布式查询处理，强壮的容错容灾能力，欠缺直观的监测剖析告警能力，集群数据备份和复原等 罕用的DBA 数据管理和操作。所有这些性能无需任何利用零碎侧的编码工作，也无需DBA人工染指，不停服不影响业务失常运行。 昆仑数据库具备全面的OLAP 数据分析能力，通过了TPC-H和TPC-DS规范测试集，能够实时剖析最新的业务数据，帮忙用户发掘出数据的价值。昆仑数据库反对私有云和公有云环境的部署，能够与docker，k8s等云基础设施无缝合作，能够轻松搭建云数据库服务。 请拜访 http://www.zettadb.com/ 获取更多信息并且下载昆仑数据库软件、文档和材料。 KunlunDB我的项目已开源【GitHub：】https://github.com/zettadb【Gitee：】https://gitee.com/zettadb

设置表的CHARSET 指定CHARSET为utf8mb4 CHARSET=utf8mb4 COLLATE utf8mb4_unicode_ci #将TABLE_NAME替换成你的表名ALTER TABLE TABLE_NAME CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

一、前言上一篇咱们说了 腾讯一面：说一说 MySQL 中索引的底层原理，置信你对索引有个很清晰的意识了，这一篇咱们来说一说慢 SQL 的排查以及调优。为啥面试官要问这个问题，其实跟上一篇的索引底层原理有肯定关联关系的，个别慢 SQL 很大一部分起因对索引底层原理不够特地理解导致的，比方没建索引、索引生效、索引没满足最左前缀匹配准则导致慢 SQL，像腾讯这样数据量很大的公司，人家必定有专门的 DBA 去做优化的，面试官考查的次要是你排查问题的能力以及晓得索引的底层原理、以及晓得优化的方向，不至于让你进来把人家规规矩矩的数据库搞乱了。 咱们上面间接进入正题了，首先来说下怎么排查慢 SQL 的。 二、开启慢查问日志MySQL 中与慢 SQL 无关的几个重要零碎变量如下： 参数含意slow_query_log是否启用慢查问日志，ON 为启用，OFF 为未启用，默认为 OFF。开启会影响性能，MySQL 重启会生效。slow_query_log_file指定慢查问日志文件的门路和名字，缺省文件名 host_name-slow.log。long_query_time执行工夫超过该值才记录到慢查问日志，单位为秒，默认为 10。log_output日志输入地位，默认为 FILE，即保留为文件，若设置为 TABLE，则将日志记录到 mysql.show_log 表中，反对设置多种格局。执行如下语句看是否启用了慢查问日志，ON 为启用，OFF 为未启用，默认为 OFF。 SHOW VARIABLES LIKE '%slow_query_log%'; 能够看到，我这里是曾经开启了的。如果你的没有开启，能够应用如下两种形式来开启慢查问。 2.1 批改配置文件批改配置文件 vim /etc/my.cnf，在 [mysqld] 段落在退出如下配置： [mysqld]slow_query_log=1slow_query_log_file=/var/lib/mysql/data/slow.loglong_query_time=3log_output=FILE,TABLE须要重启 MySQL 才能够失效，命令为 service mysqld restart 2.2 设置全局变量如下关上慢查问日志，设置超时工夫为 3 秒，并且将日志记录到文件以及 mysql.show_log 表中。 SET GLOBAL slow_query_log = 1;SET GLOBAL slow_query_log_file='/var/lib/mysql/data/slow.log';SET GLOBAL long_query_time=3;SET GLOBAL log_output='FILE,TABLE';想要永恒失效得用下面那个配置文件里配置，否则数据库重启后，这些配置生效。 三、剖析慢查问日志3.1 获取慢 SQL 信息查看慢查问日志记录数： ...

明天来聊一个简略的话题，这是一个小伙伴在微信上问我的，对于初学者我十分能了解这类问题带来的困扰，各种尝试，各种搜寻，他人说的有条有理，然而就是解决不了本人的问题，明天我简略从两个方面来和大家聊聊这个问题，如果小伙伴们有其余的解决思路，也能够留言一起分享。 这个问题咱们能够从两方面来剖析： MySQL 自身的问题。Java 代码的问题。1. MySQL 自身问题MySQL 自身问题，这个其实很好验证，不就是工夫么，咱们执行如下 SQL 看看 MySQL 上的工夫跟我的电脑工夫是否是统一的： select now(); 能够看到，MySQL 的这个工夫跟我零碎的工夫其实就差了 8 小时，MySQL 自身的工夫都不对，那你未来插入/查问的工夫必定也不对。 这个查问大家留神，要么应用命令行操作，要么应用 Sqlyog、Navicat 或者 Sequel Pro 之类的数据库工具来操作，切勿应用 JDBC 来查问，具体起因一会看完第二大节就明确了。 呈现这个问题，多半是 MySQL 的时区不太对，咱们从新给其设置一下时区即可。 首先咱们通过如下指令来查看一下 MySQL 以后的时区： show variables like '%time_zone%'; 能够看到，MySQL 说它的时区是 SYSTEM，那 SYSTEM 又是啥呢？第一条说了 SYSTEM 是 UTC（协调世界时，又称世界规范工夫或世界协调工夫）。而咱们的北京工夫比 UTC 快了 8 小时，即 UTC+8。 所以咱们当初要把 MySQL 的时区先给改对，能够通过批改配置文件来实现（/etc/mysql/mysql.conf.d/mysqld.cnf），如下： 批改实现后，重启 MySQL，再来查看 MySQL 的时区： 能够看到，此时的 MySQL 时区就失常了。 那么此时再执行 select now(); 也就不会有问题了： 有的小伙伴可能嫌批改配置文件太麻烦了，那么也能够通过 SQL 来批改时区： ...

前言行锁在 InnoDB 中是基于索引实现的，所以一旦某个加锁操作没有应用索引，那么该锁就会进化为表锁。 一、行锁三剑客是什么？行锁三剑客指的是：InnoDB引擎下的记录锁（Record Locks），间隙锁（Gap Locks），临键锁（Next-Key Locks）。 二、记录锁（Record Locks）记录锁存在于包含主键索引在内的惟一索引中，锁定单条索引记录 -- id 列为主键列或惟一索引列 SELECT * FROM table WHERE id = 1 FOR UPDATE; id 为 1 的记录行会被锁住。须要留神的是： **id 列必须为惟一索引列或主键列，否则上述语句加的锁就会变成临键锁。同时查问语句必须为精准匹配（=），不能为 >、<、like等，否则也会进化成临键锁** 其余实现在通过 主键索引 与 惟一索引 对数据行进行 UPDATE 操作时，也会对该行数据加记录锁： -- id 列为主键列或惟一索引列 UPDATE SET age = 50 WHERE id = 1;三、间隙锁（Gap Locks）间隙锁基于非惟一索引，它锁定一段范畴内的索引记录。间隙锁基于上面将会提到的Next-Key Locking 算法，请务必牢记：应用间隙锁锁住的是一个区间，而不仅仅是这个区间中的每一条数据。 间隙锁测试：test表中，主键id,age在进行测试之前，咱们先来看看test表中存在的暗藏间隙： (-infinity, 1）(1, 5）(5, 7）(7, 11）(11, +infinity）场景一：只应用记录锁，不会产生间隙锁开启事务一，并执行主键为id=5的语句。事务2开启执行insert, 失常执行不受影响。场景二：产生间隙锁(主键索引)事务一依然是开启事务，然而执行的是范畴内的查问。事务二开启，而后执行插入语句，插入id=6.age =8.从下面咱们能够看到，(5, 7)、(7, 11) 这两个区间，都不可插入数据，其它区间，都能够失常插入数据。所以咱们能够得出结论：当咱们给 (5, 7)这个区间加锁的时候，会锁住 (5, 7)、(7, 11] 这两个区间。 ...

制裁下的俄罗斯写于3月28日，俄罗斯对乌克兰发动特地军事流动后，东方国家北约以美国为首迅速对俄罗斯采取各种制裁伎俩，制裁伎俩形形色色，令人叹为观止。人物制裁这个咱们尚且了解，这些官人、富商、贵人、企业与俄罗斯有间接的利益输送关系，金融制裁是天经地义，SWIFT相当于金融核弹严厉打击了俄罗斯经济，然而俄罗斯的猫、俄罗斯的狗、俄罗斯的树、驰名作曲家柴可夫斯基的《天鹅湖》也被制裁因为政治关系恶化也要承受制裁。这些形成不了威逼的小动物和艺术作品都要承受制裁，那么科技制裁就有根据理由了。 以后Facebook、Twitter、Netflix、Roku、Meta、Tiktok、英特尔、AMD、谷歌、苹果都对俄罗斯采取了束缚、限度口头。以Oracle、SAP、IBM等信息解决方案公司曾经曾经暂停了在俄罗斯联邦的所有业务和技术支持。最搞笑的是，Github以严格限度俄罗斯取得其维持侵略性军事能力所需的技术，封闭俄罗斯开发者，不准俄罗斯应用开源软件。开源无国界的信条，被证实了是有前置条件的。 制裁的定义，一方握有主动权，地位居于上游；一方只有被动权，地位居于上游，制裁就是上游方截断水源不让水往下流，上游只能靠本人打井钻水或者以前的储备，日常生活中要精打细算皱巴巴的过日子。会不会有一天，中国也会面临如俄罗斯以后遭逢的同样窘境？毋庸置疑，中国要做大要做强肯定会遇上相似的窘境。 其实，这些“制裁”在中国早已见前兆，中兴芯片断供事件、华为“孟晚舟事件”，还有字节跳动在美国的Tiktok事件等都能够视为上游对上游的截流。因为断芯片断供，中兴业绩一路下滑，亏损达到数十亿人民币。再回到Tiktok事件，2020年9月14日，Oracle曾经与TikTok的中国 母公司字节跳动达成协议，成为其“可信技术提供商”，TikTok能够持续经营，然而美国要在底层上管制你的数据资源。 科技制裁下的上游方是产品的使用者，科技产品如数据库，当产品曾经购买就像车曾经卖出去，上游进行服务和技术支持会怎么样？ 如果没有产生外围BUG事件，DBA照样日常驾驶。如果kernel panic，置信哪路大神过去都心有余而力不足了。 咱们在河流哪一个地位？那么，中国科技下游离上游有多远？如何丈量与上游的间隔，咱们预期什么时候可能成为上游？咱们的国产数据库何去何从？ 互联网的倒退历史是数据库的历史，因为数据库反对了底层的操作系统还有下层的利用。其实不准确，中国数据库诞生比中国互联网还要早，20世纪70年代中期中国银行引入理光-8（RIOCH-8）型主机零碎揭开了我国银行业电子化、信息化倒退的尾声，同期引入国外数据库，IBM、Oracle就是这样趁虚而入奠定根底。一些银行数据库老版本旧零碎延用至今，始终没有更新换代。 做数据库不是一个容易的事，老牌数据库达梦建设于2000年，齐全100%独力翻新，把Oracle利用迁徙到DM8利用有22年的教训，DM8的应用运行齐全仿照摸拟oracle，市场上做了那么多年，你看Oracle的市值和达梦的市值。南大通用也是实力出众的多数公司之一，一边独立研发，一边借鉴外国的技术参考，当年IBM曾经对三家国内公司发售informix源代码，别离是南大通用、北京华胜天成、福建星瑞格，只有南大通用惟一一家消化了informix的几千万行源代码，推陈翻新出事务的产品，当初gbase比拟DB2、比拟SQLServer、比拟Oracle又如何了。 达梦与gbase遇到的阻碍艰难演绎为以下三个起因： 国外数据库品牌意识曾经深入人心，国外数据库有十年以上的客户业务背书。弱小的开源力量，我既然能够轻松应用收费开源MySQL解决问题，为什么我还须要商用数据库。客户的担扰，数据库的稳固牢靠关系到业务的命根子平安，以后业务平安稳固，我为什么动一个换心脏的手术?难在哪里？国家可能帮忙你的只有第三个问题。上面的政策红利发放，国家会激励国产数据库的试水，投标考核优先国产的数据库，置信其中一条硬件条件事项包含是否100%源代码独立自主翻新，如果底层采纳国外的数据产品，那么解释与外围组件的依赖关系和辅助关系。国家提倡国产数据库，同时还是要尊重市场，尊重消费者的抉择，尊重客观事实。做心脏切换手术容易，然而你能保障新心脏可能像以前顺利运行，没有一点丁的问题吗？ 笔者参加过几个我的项目，甲方开出刻薄的投标条件，只有大厂可能入选，甲方置信大厂的技术实力能保障这一点。当初阿里替换Oracle，初生的OceanBase是工程化的产品，须要投入大量的人力，幸好阿里最不缺的工程师。客户偏向抉择大厂，外表看是基于产品的抉择，实际上是技术的抉择。 墨天轮以后收录有近200款数据库产品，当产品产生故障，有几个厂商可能有信念把问题解决，并给出root cause不低于一万字的报告？有多少个厂商能够给出将来三年的产品倒退门路图？有多少个厂商能够自信满满，用自已的产品解决客户的外围业务问题。 俄罗斯数据库产品虽说注销只有26家，然而俄罗斯很切实，咱们都有听过俄罗斯的故事，俄罗斯面包、俄罗斯牛奶、俄罗斯蜂蜜都不能掺假。俄罗斯的数据库多以开源的Apache、MIT和BSD宽松协定，原本就十分实在地裸露在阳光下，Clickhouse就是俄罗斯的杰作。相同中 国在工程尽管有不少的杰作，然而中 国科技产品更多是边缘翻新，甚至是贴牌翻新，次要依赖商业模式翻新，借助弱小的市场内需，通过各种营销伎俩疾速实现市场布局，例如小程序和APP利用的各种商城。数据库产品不一样，作为一个根底软件，它具备漫长的生命周期，兴许须要十多年能力变现，腾讯已经搞了一个TBase，在2019年底提交了首次代码之后，就再也没有代码更新了。一个可能性起因就是没有变现产生经济价值。 挺身入局 躬身实际中华民族的平凡振兴，终极目标是成为一个不依赖任何国家的寰球超级大国。其中一个标记在关键技术卡脖子方面实现自力更生，以确保经济平安。实现这个平凡指标，必须事业单元具备独立研发和自主翻新的能力，国产化代替，国家只能牵个头，国产与国外竞争共存，要害还须要国货自强，正如国家对汽车的反对，仍然引进日系车、德系车，引进后日系车、德系车始终在汽车市场居于主体位置。如果有一天，日系车和德系车等外资车全面退出中 国市场只剩下中 国车，世界百花齐放制裁后只有中 国花独立凋谢。长期与外资车互竞，国产车曾经今非昔比，尽管与BBA品牌有一段距离，然而汽车驾驶根本应用没有问题，纵然有些小问题也不会影响到生命安全。 国产车的现状是国产数据库奋斗的一个阶段性指标，参考Oracle产品的倒退，至多分为三个阶段： 截至 Oracle 9i 实现根本产品可用性，满足利用开发的根本工程性能个性需要。从 Oracle 10G 开始推出网格计算，通过多台节点服务器利用高速网络组成一个虚构的高性能服务器，负载在整个网格中平衡(，按需增删结点，防止单点故障，次要减少非功能性特色包含可靠性、容错性、可扩展性、互操作性、卓越运维、性能效率、劫难复原和业务连续性，通过大量的客户案例验证证实产品的稳定性和健壮性。自 Oracle 12C 开始，致力转向从基础设施工具提供应用转变成基础设施平台提供应用角色，集成多租户性能、区块链性能等等。国产数据库倒退路线不须要循序渐进遵循Oracle的轨迹，然而投入行业利用实际，以工具的形式嵌入金融、电信、能源、政府、教育、工业网的利用场景是避不可少的一个环节。进入后，寻找适合的业务场景，性能方面改善客户业务流程或者性能方面降本增效。 能够多想想：如何为数据库使用者提供外围价值以及如何以数据库使用者为核心。 数据库使用者能够分为两类，一个是客户，一个是用户。客户群体泛指业务员、领导、高层、录入员、流程工作者、数据分析师等偏差业务域的人员；用户群体泛指工程师等偏差技术域的人员，包含利用开发工程师、架构工程师、数据库工程师。 如果面向客户的形式嵌入关上场面，最好的状况是客户业务还没有信息化或者客户业务有一个很大亟待解决的痛点，最坏的状况那是一套稳固的衰弱的业务零碎，你如何验证你的产品性能和性能给客户业务降本增效、赋能收益？多相熟理解客户的业务，多理解客户业务域的流程问题，笔者的经验，陪客户喝喝酒，吃吃饭，吹吹牛也是干实事的，否则客户只违心提供给你一个小业务用的试点。 面向用户的形式，那就是咱们常说的技术布道，用开源的形式广纳天下良言，新的技术、新的框架、新的工具遍及公众，让用户承受新的解决方案。技术布道不会马上产生盈利价值，技术的最次要作用是造就市场，积攒使用者，为前期暴发做筹备。伎俩包含在出名的公共论坛广为宣传来减少产品曝光知名度，为用户应用提供多种手段的反对，并帮忙利用开发接入，针对行业痛点设计解决方案并举办研讨会，以展现产品和技术平台的潜在劣势。 达梦积攒了20多年面向客户的教训，当初达梦也面向用户开展技术布道，关上品牌影响力。至于面向用户畛域，TiDB是佼佼者，在积攒了大量的工程师口碑后，它当初也致力找商业的机会。俄产库给咱们警示，国家会动摇企业信心换心脏的信心，然而国 家不能减弱国外产品的力量，也不会对造成它们造成打击。 国 产数据库要做好足够的筹备，还是要好高鹜远，求实无能。别指望风口为你埋单，第一个问题和第二个问题还是须要本人解决，打铁还需本身硬，只有实力和品质的产品能力在市场下生存下来。用达梦的话，国产厂商应该做的事件，就是踏踏实实的把该补的课全副补上，产品要继续欠缺、手册要写粗疏、培训要发展、生态适配要做起来、迁徙计划要筹备好，丢掉空想，筹备战斗。面对政策风口发奋自强，这是咱们最好的态度。 原文链接：https://www.modb.pro/db/391247 申明：本文为墨天轮作者 大数据模型 原创内容，代表作者观点。如您对上述内容有意见和倡议，请在下方评论区指导和交换，或点击作者墨天轮主页留言。* 相干浏览 《如果你身处被“科技制裁”的俄罗斯》系列访谈(对话业内专家、达梦数据库、一线从业者)中国数据库风行度排行榜-墨天轮更多精彩请关注墨天轮社区，围绕数据人的学习成长提供一站式的全面服务，打造集新闻资讯、在线问答、流动直播、在线课程、文档阅览、资源下载、常识分享及在线运维为一体的对立平台，继续促成数据畛域的常识流传和技术创新。 关注官网公众号：墨天轮、 墨天轮平台、墨天轮成长营、数据库国产化 、数据库资讯

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。导语在日常工作中可能会存在误删数据的状况，明天就简略介绍下如何利用提早库进行数据库的疾速复原。 步骤1.环境筹备建设一个测试的主从库，写入一些测试数据，非本文要点，过程略。 2.设置提早同步在原有同步信息的根底上进行如下操作，设置提早同步1小时 # 设置提早1小时mysql> stop slave;mysql> CHANGE REPLICATION SOURCE TO SOURCE_DELAY=3600; mysql> start slave;mysql> show slave status\G;*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.5.160 Master_User: repl Master_Port: 3314 Slave_IO_Running: Yes Slave_SQL_Running: Yes Seconds_Behind_Master: 6536 SQL_Delay: 3600 -> 设置后，这里能够看到提早的信息 SQL_Remaining_Delay: NULL Retrieved_Gtid_Set: 4b4539dd-2fc1-11ec-949b-70b5e873a570:2-53662 Executed_Gtid_Set: 4b4539dd-2fc1-11ec-949b-70b5e873a570:1-36546,d2c64073-2cb5-11ec-b4d1-70b5e873a570:1-21 row in set, 1 warning (0.00 sec)3.假如在主库上进行了一个误删的操作# 误删一条id=9998的数据mysql> delete from t1 where id=9998;Query OK, 1 row affected (0.32 sec)# 主库曾经没有了mysql> select * from t1 where id=9998;Empty set (0.00 sec)# 从库还能查到数据mysql> select * from t1 where id=9998;+-----+------+------+------+------+| id | c1 | c2 | c3 | c4 |+-----+------+------+------+------+| 9998| 983 | xAP9 | mQeN | 8Eu2 |+-----+------+------+------+------+1 row in set (0.00 sec)4.解析主库的binlog文件这个步骤目标是找到主库执行删除操作时候相应的GTID值的上一个GTID值 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。MySQL 的表有很多种，对表的操作次要是增删改查，明天来浅谈一下这些操作的底层代码和流程，以下以 tmp table为例子，为了更好的阐明操作流程，该表没有建设 primary key。1.首先创立一张 tmp table，第三个参数 is_virtual=false 代表这不是虚构表，如果这个值设置为true那阐明这是虚构表，次要给存储过程建设长期表来存储参数的，这种虚构表没有handler，只能存储列信息和单行列值，不能寄存多行值，不能进行增删操作。 Table *table = create_tmp_table_from_fields(thd, *get_field_list(), false, options, table_alias);创立表过程中会做以下操作: 1、初始化表：table->init_tmp_table2、用传进来的create_field 信息创立表的列：make_field3、创立表增删改查用的操作句柄：setup_tmp_table_handler2、查找操作 table->file->ha_rnd_init(true) handler 初始化int rec = table->file->ha_rnd_next(table->record[0]) 从第一行开始查找，一次指针向下跳一行，table->record[0]用于存储查到的值对后果的判断： switch (rec) { case 0: { 查找胜利能够取出查到的值，此时该行值在table->field[col]，col代表第几列 break; } case HA_ERR_END_OF_FILE: if (table->file->ha_rnd_end()) return true; 查找到最初一行退出 break; default: 查找出错解决3、插入一行，这个操作绝对简略只有两步 for (ulonglong u = 0; u < upper_bound; ++u) if (table->field[i]->store(u, true)) return true; 首先循环把值u存入第i列的record[0]if (write_row()) return true;间接把值从record[0]写入表即可3、更新一行 if (table->file->ha_rnd_init(true)) return true; 初始化handler for (int i = 0; i < offset_table + 1; i++) { if (table->file->ha_rnd_next(table->record[1])) return true; 让指针跳到指定要更新的那一行，留神这里该行的值存在record[1] } memcpy(table->record[0], table->record[1], (size_t)table->s->reclength);把值从record[1]拷贝到record[0] (*value)->save_in_field(get_field(i), false); 把value值存入第i列的record[0]，留神此时别的列值还是表里查到的值，这样record[0]就是新的值 if (table->file->ha_update_row(table->record[1], table->record[0])) 更新数据，这里record[1]是旧的值即表里的值，record[0]是新的值即待更新的值 return true; if (table->file->ha_rnd_end()) return true; 完结本次handler4、删除一行 ...

自增id自增 id ：定义初始值，而后不停往上加步长。其下限取决于字节长度，如无符号整型 (unsigned int) 是 4 个字节，id下限就是 2^32-1。 表定义自增值id下限1、表定义的自增值达到下限后的逻辑是：再申请下一个 id 时，失去的值放弃不变。2、例子： create table t(id int unsigned auto_increment primary key) auto_increment=4294967295;insert into t values(null);//胜利插入一行 4294967295show create table t;/* CREATE TABLE `t` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=4294967295;*/insert into t values(null);//Duplicate entry '4294967295' for key 'PRIMARY'//第一个 insert 语句插入数据胜利后，这个表的 AUTO_INCREMENT 没有扭转（还是 4294967295），就导致了第二个 insert 语句又拿到雷同的自增 id 值，再试图执行插入语句，报主键抵触谬误。3、应该创立成 8 个字节的 bigint unsigned。4字节无符号42亿，有符号21亿，除非删除极其频繁，不然不可能用完，因为单表存储最多也就千万级，超过时就要分库分表了，而存储记录达千万（下限1亿吧），自增id达21亿时，阐明删除了20亿（其它起因导致id减少的可能比拟小），新增1条就会删除20条，这种场景极其常见。 InnoDB 零碎自增 row_id1、InnoDB 表不指定主键时会创立一个不可见的长度为 6 个字节的 row_id。2、特色：row_id 写入表中的值范畴，是从 0 到 2^48-1；当 dict_sys.row_id=2^48时，如果再有插入数据的行为要来申请 row_id，拿到当前再取最初 6 个字节的话就是 0，而后持续循环。如果表中曾经存在 row_id=N 的行，新写入的行就会笼罩原有的行。3、应该在 InnoDB 表中被动创立自增主键。 ...

引言 内容为慕课网的《高并发 高性能 高可用 Mysql 实战》视频的学习笔记内容和集体整顿扩大之后的笔记，这一节讲述三高架构的另外两个局部切换和扩大，扩大指的是分库分表加重数据库的压力，同时因为分库分表须要针对节点宕机问题引入了一些优化伎俩，而切换局部就是讲述节点宕机的切换问题的，最初咱们联合复制的主从切换讲述如何搭建一个三高的架构。 如果内容比拟难能够追随《Mysql是怎么样运行》集体读书笔记专栏补补课： 地址如下：从零开始学Mysql。 扩大分区表 Innodb的分区表是指将一个表拆分为多个表然而留神这个概念和分库分表的物理分表有差异，在Innodb中尽管曾经在存储引擎进行了划分，实际上分区表在Server层上还是被当成一个表对待。 分区表的构建能够看上面的案例： 为了验证Sever层把它当做一个表对待这里能够进入命令行通过上面的命令查看，在截图中能够看到尽管外表上是一个表然而实际上Innodb存储引擎把它们拆分为四个表： InnoDB分区存在上面的几种形式：范畴分区：通过数据的存储范畴进行划分分区。哈希分区：通过哈希值进行分区。List分区：针对字段取值的形式进行分区。 分区表有上面的特点： 升高Btree树层级，进步搜寻查问的效率。第一次拜访须要拜访所有分区。所有分区表独特应用一个MDL锁，这意味着对于分区表的锁表会同步解决因为对于server层来说分区表只是一张表，所以分区实际上没有进步性能。分库分表 分库分表依照严格来说应该分为分库和分表，分库的解决状况个别比拟少更多的是依据业务进行分表的操作，分表通常分为上面几种形式： 垂直分表：垂直分表指的是依据某表的数据依照某种规定冷热进行划分。 程度分表：程度分表通常依照数据行拆表，这种形式相似把实在的数据行拆分到多个表外面，避免单表数据过大，同时外部应用范畴值或者哈希值进行程度分表的数据查找，其中程度分表最为罕用。 留神本局部讲述的分表和下面的分区表是有区别的，在Server层这种分库分表会当作理论的拆分对待而不是同一个表。而分库的概念当初应用的状况不是特地多了，在分库概念中分为上面的内容： 垂直分库：数据扩散在多个数据库或者分到多个节点。 程度分库：将数据表依照非凡业务规定划分，是每一个库负责各自的次要业务。同时数据库的根本构造配置雷同。程度分库通常还有一种场景是较为新的数据和较为老的数据放到不同的库中进行查看，同样和上面的结构图相似。 分库分表有哪些优缺点呢？ 长处： 减少隔离性减少并发和隔离性：因为数据结构在server层被看作不同的库和块，和分区表尽管很像，然而实质上齐全不一样。毛病： 对于局部生效的特色会成倍的减少和呈现。单点事务不能够实现，须要引入分布式的锁进行管制。垂直分库分表之后不可能join查问，会多写很多SQL。对于范畴查问的SQL会存在问题Dble和Mycat简介：这两款中间件都是用于Mysql进行分库分表的市面上应用十分多的支流中间件，Mycat可能更为人熟知而Dble则是在Mycat的根底上更进一步优化和扩大。 根底运行原理： 剖析查问的SQL语句。把SQL的查问依照中间件算法散发到多个库和多个表进行查问，同时发送到数据节点将数据节点的数据进行汇集合并，最初返回给客户端。Dble：高性能的Mysql分库分表中间件，由国内一家叫做爱可生的公司进行开发，能够说是国产之光，我的项目齐全开源同时基于另一个开源我的项目Mycat进行优化和改进，同时这款工具次要是由JAVA编写，对于一些理论应用的问题能够由大部分的开发人员尝试解决。 Dble的设计构造如下，对于客户端来说和平时连贯Mysql的分片没有区别然而实际上这是因为Dble外部做了一系列的优化操作： Dble的根底概念： Schema：虚构数据库（和传统数据库的Schema不同）。ShardingTable：虚构表，通过虚构表把数据进行算法划分。ShardingNode：虚构节点，存在数据库的Database中，能够认为一个DB就是一个节点。dbGroup：理论的Mysql集群。Database：示意理论的Database。最初咱们通过一个简略的分表案例来看看Dble做了哪些操作： Dble的分库分表特点是无论分库还是分表都是应用分表来实现的。 在下面的图中能够看到，首先咱们的物理表被Dble当作一个shariding table对待，这里的虚构表在Dble外部首先会被散发到两个Mysql节点，对于Mysql1和Mysql2来说他们之间是没有任何关系的单方不晓得对方存在的（和上一篇提到的主主架构是不一样的），而Dble则在这两个节点当中的理论db创立了虚拟机节点进行程度分库，外部通过算法散发到不同的库中进行查问，这里的表看起来很小是因为外部实际上有可能还存在其余的虚构节点，而对于Dble来说是拆分合并到不同的Mysql中治理，这些虚构节点对于Mysql1和Mysql来说是离开保存的数据，对于Mysql自身来说和一般的数据没有显著感知和区别，真正的数据合并则由Dble实现。 Dble装置搭建和应用对于具体的操作应用能够参考官网所写的文档：Introduction · Dble manual (actiontech.github.io)，装置过程这里就略过了咱们重点从Dble的配置开始： 首先Dble有几个重要的配置文件： cluster.cnf:集群参数配置bootstrap.cnf:实例参数配置，包含JVM启动参数，Dble性能，定时工作，端口等user.xml:Dble 用户配置db.xml：数据库相干配置sharding.xml：数据拆分相干配置留神这些文件在装置好的Dble目录外面都是模板，除开局部须要依据本人的Mysql状况批改配置之外，只须要间接改名去掉_template即可。 接下来是批改db.xml文件，在这个文件中须要依据本人的数据库节点状况进行相干配置的批改，比方下方截图中的框线局部须要进行改变为本人的Mysql节点配置。 如果截图看不清也能够参考官网给的一个样板进行批改，须要改的中央都有相干的标识，比拟好了解。 <?xml version="1.0"?><Dble:db xmlns:Dble="http://Dble.cloud/"> <dbGroup name="dbGroup1" rwSplitMode="1" delayThreshold="100"> <heartbeat errorRetryCount="1" timeout="10">show slave status</heartbeat> <dbInstance name="instanceM1" url="ip4:3306" user="your_user" password="your_psw" maxCon="200" minCon="50" primary="true"> <property name="testOnCreate">false</property> <property name="testOnBorrow">false</property> <property name="testOnReturn">false</property> <property name="testWhileIdle">true</property> <property name="connectionTimeout">30000</property> <property name="connectionHeartbeatTimeout">20</property> <property name="timeBetweenEvictionRunsMillis">30000</property> <property name="idleTimeout">600000</property> <property name="heartbeatPeriodMillis">10000</property> <property name="evictorShutdownTimeoutMillis">10000</property> </dbInstance> <!-- can have multi read instances --> <dbInstance name="instanceS1" url="ip5:3306" user="your_user" password="your_psw" maxCon="200" minCon="50" primary="false"> <property name="heartbeatPeriodMillis">60000</property> </dbInstance> </dbGroup></Dble:db>接下来是批改user.xml局部，这部分须要留神有managerUser和shardingUser两个角色，一个是管理员负责管理Dble的用户，另一个sharingUser则须要建表权限对于客户端申请进行分库分表。 ...

大家好，我是七淅（xī）。 如题目所说，本文会联合我本人的亲身经历，介绍 3 局部内容： 线上单库单表变更到多库多表的各个实现计划计划优劣比照对于历史存在的单表，并且它们不须要变成多表，须要怎么解决先下个论断，没有百分百完满的计划，技术计划永远要联合产品业务来设计。 以下举例的计划也只是较为通用的做法，具体细节是能够依据业务场景进行变动调整的。 只有可能满足业务需要，就是好计划，不要为了秀技术而疏忽业务。 看完这篇文章，如果前面有人问你，对于变更到多库多表的计划问题，那你能够和他谈笑自若了。 好了，上面我说下我这边的业务背景，和大家解释分明为什么须要多库多表。前面会引申出计划的，莫急。 1. 业务背景有一个在线上运行着的数据库，假如是 user 库，库中只有 1 张单表。 当初有个新需要，该需要的性能有肯定的申请量和数据量。 其中数据量初期是百万级，思考到业务减少，增长到千万、上亿都是有可能的。所以从数据量上看，单库单表不适合。 Q1：如果只是数据量问题，那用单库多表行不行？ A1：行。 Q2：那为什么还用多库多表呢？ A2：因为一个数据库的连贯数量是无限的，怕翻车。 下面有介绍业务有肯定的申请量，放心一个库来解决的话，万一哪天网络不好/慢查/该表业务有突发性流动等状况呈现。 一不小心就把连接数占满了，那就间接翻车了。 加上我司对多库多表的基建比拟成熟，所以我这边就间接上多库多表了。 Q3：既然如此，后期先上单库多表，等量上来后再多库多表行不行？ A3：能够。然而到时再来一次太累了。 比方再来一次会经验以下事件： 每天须要看看数据监控有没有到瓶颈到时再次变更时，开发运维测试业务的排期和执行业务变动：说好的下个季度大推，后果提前到下一个月进行，此时数据库能不能扛住，扛不住革新工夫是否短缺？所以，咱们要不还是一步到位吧。 滴，七淅揭示你：看到这，如果有人问你单库多表和多库多表的应用场景，你应该晓得怎么施展了吧2. 历史数据处理我先说下对历史数据处理，篇幅较少。 这里的内容对应文章结尾的第三点：对于历史存在的单表，并且它们不须要变成多表，须要怎么解决 这里能够有两种解决形式。 咱们晓得，历史数据在 user 库，假如业务须要减少到 8 个库，并且新表须要在这 8 个库中 2.1 形式一新增 user_0、user_1、...、user_7 共 8 个库，应用 rename 命令，将 user 库的表迁徙到 user_0 库中，最初将 user 库删掉即可。 rename 命令其实就是重新命名，实现剪切数据的成果，而不是复制。当然要用复制的形式迁徙数据也是能够的，但咱们这边没用。 reanme 命令应用如下： rename table user.table_name to user_0.table_name; 2.2 形式二新增 user_0、user_1、...、user_7 共 8 个库，user 库数据不动，持续应用。 ...

三高Mysql - Mysql个性和将来倒退引言 内容为慕课网的《高并发 高性能 高可用 Mysql 实战》视频的学习笔记内容和集体整顿扩大之后的笔记，这一节次要讲讲Mysql5.8比拟罕用的几个新个性以及针对外部服务器的优化介绍，实践局部的内容比拟多简略看看了解一下即可。 如果内容比拟难能够追随《Mysql是怎么样运行》集体读书笔记专栏补补课： 地址如下：从零开始学Mysql。 Mysql8.0新个性Mysql为什么叫8.0？其实就是个数字游戏能够间接认为是5.8。 Mysql8.0有什么新个性： 窗口函数：rank() 列分隔，分为多个窗口在窗口外面能够执行特定的函数-- partition by 排名，案例指的是依照顾客领取金额排名。-- rank() 窗口函数select *, rank() over ( partition by customer_id order by amount desc) as rankingfrom payment;暗藏索引 临时暗藏某个索引。能够暗藏和显示索引，测试索引作用，多用于开发的时候评估索引的可用性。show index from payment;-- 暗藏索引alter table payment alter index fk_payment_rental Invisible;-- 显示索引alter table payment alter index fk_payment_rental Visible;降序索引 8.0 之前只有升序的索引，自8.0之后引入了降序索引的索引排序形式，用于进行某些非凡查问的状况下也能够走索引。通用表达式（CTE） CTE表达式事后定义简单语句中重复应用的两头后果能够简略认为是一个长期视图select b,d from (select a,b from table1) join (select a,b from table2)where cte1.a = cte2.c;-- 简化with cte1 as (select a,b from table1), cte1 as (select a,b from table2)select b,dfrom cte1 join cte2where cte.a = cte2.c; UTF8编码 ...

三高Mysql - 搭建“三高”架构之复制引言 内容为慕课网的《高并发 高性能 高可用 Mysql 实战》视频的学习笔记内容和集体整顿扩大之后的笔记，这一节讲述搭建Mysql三高架构中的复制，Mysql的复制在实战中实现比较简单，然而Mysql针对复制的外部优化却是始终在进行，这样阐明这是值得器重和学习的内容，所以本节针对复制这一特色介绍相干的实践内容。 如果内容比拟难能够追随《Mysql是怎么样运行》集体读书笔记专栏补补课： 地址如下：从零开始学Mysql。 什么是“三高”架构？三高架构比拟好了解，这里简略过一遍： 高并发：同时解决多条事务数高高性能：SQL 执行效率高高可用：零碎可用率达到99%以上。三高是目标不是伎俩 三高架构的关键在于三个关键字：复制，扩大，切换。 复制：数据冗余，binlog传送，并发量晋升，可用性进步。毛病是复制会加大服务器的性能开销。 扩大：扩大容量，数据库分片分表，性能和并发量晋升。毛病是升高可用性。 切换：主从库进步高可用，主从身份切换，并发量晋升。毛病是失落切换时刻的数据。 这三点对应CAP的实践，CAP中最多只能满足CP或者AP，CAP的理论知识这里略过，联合下面三点能够简略梳理。 三高实现实质： 三高的实质其实就是如何联合复制、扩大、切换三个办法实现三高，咱们须要思考上面的三个问题： 如何将数据进行冗余？如何无效扩大容量，进步并发性能？如何做主从备份切换，进步高可用？针对下面三个问题在回到结尾提到的三高最终Mysql的三高总结来说就是上面三点： 高并发：复制和拓展，扩散多节点 高性能：复制晋升速度，拓展容量 高可用：节点之间切换。 复制复制是Mysql中实现高可用的重要性能，复制类型分为三种：异步复制和半同步复制，组复制的模式以及新版本带来的GTID复制加强模式。 异步复制半同步复制组复制（Mysql5.7新个性）GTID 复制模式（Mysql5.6.5之后新增）（缩小复制故障）复制原理异步复制 异步复制是十分传统的Mysql复制形式也是实现形式最为简略的一种，异步复制和其名字的意义一样主库在写入binlog之后告诉从库数据曾经发送而后本人干本人的事件去了，此时从库会被动发动IO申请建设和主库的连贯，接着是binlog拷贝到本地写入到relay log中进行重放日志最终sql线程重放而后在最初达到数据统一的成果。 根本的解决步骤如下： 主节点执行备份线程，读取binlog文件并且发送给从库。从库的io线程和主库建设连贯，应用二进制转储线程读取到binlog文件，如果数据是同步的则睡眠期待主库发送同步信号，否则获取数据把binlog文件保留为relay log，留神从库不会立马执行主库发来的sql，而是会放入到redo log中。从库会通过sql线程定时读取最新的relay log文件，对于relay log重放，重放之后本人再记录一次binlog日志。（本人再记录一次次要是因为从库自身也有可能是其余子从库的主库，整个过程依照雷同的步骤解决）异步复制的问题： 读取binlog文件的时候主节点的状态？是否须要锁表？ 主节点此时仍然能够失常执行，不须要锁表，因为操作的是二进制的binlog文件。 重放relay log是啥意思？ relay log：中继日志，relay relay：中继。 重放：从新播放能够认为是重读 从库复制波及多少线程 两个，一个IO线程一个SQL线程，IO线程负责从主库获取binlog文件，SQL负责将中继日志进行重放。 为什么从库最初还须要记录一次binlog？ 因为从库也有可能存在本人的子节点，所以也须要依照同样的步骤复制给本人的子节点。 为什么须要relay log中继日志？ 如果备库间接连贯主库进行拷贝并且间接执行可能会存在问题，如果此时主库频繁的往binlog塞日志，那么很容易呈现主库和备库之间长时间连贯并且备库无奈失常工作。 异步复制流程图：依据流程图能够看到，在主库执行完sql之后会记录binlog文件并且commit事务，通过异步的形式把binlog发给其余分片上的从库，从库会依据主库的binlog重放relay log之后最终记录到binlog，而后和主库一样实现提交的动作保证数据同步。 问题：如果主库写入binlog然而此时忽然断电，然而Binlog曾经发送给从节点，此时会呈现什么状况？没有影响，因为记录binlog意味着曾经实现了事务的操作，即时断电主库也能够通过redo log和bin log复原数据，因为事务曾经提交了，发送给从库呈现新增数据也是失常的。异步复制有上面的特点： 对于网络提早具备肯定要求实现形式和原理简略。不能保障日志被送到备库可能会呈现日志失落。通过下面的特点介绍，能够发现异步复制的最大问题就在于异步两个字，因为网络环境的复杂性主库和备库之间是相互拆散的，为了确保数据的确送到了从库，Mysql在此基础上改良复制的流程，前面提到的半同步复制其实就在提交之前进行一次“确认”的操作。 半同步复制： 如下面所说的，半同步复制其实就在主库发送binlog文件之后没有立马提交事务，而是期待所有的从库接管到了binlog并且写入到relay log之后才进行事务提交，留神这里并不是等所有的从库提交再提交，而是确认承受到binlog转为relay log之后立马就进行提交。 半同步的复制是提早了主库肯定的提交工夫，确保主备数据同步。 问题 ： 半同步复制工夫期待过久怎么办？ ...

子查问某些状况下，当进行一个查问时，须要的条件或数据要用另外一个 select 语句的后果，这个时候，就要用到子查问。 例如： 为了给主查问（内部查问）提供数据而首先执行的查问（外部查问）被叫做子查问。 个别依据子查问的嵌入地位分为，where型子查问,from型子查问，exists型子查问。 1、where型子查问 where型子查问即把内层sql语句查问的后果作为外层sql查问的条件. 子查问要蕴含在括号内。 倡议将子查问放在比拟条件的右侧。 单行操作符对应单行子查问，多行操作符对应多行子查问。 单行操作符 左边子查问必须返回的是单个值，单行比拟运算符（=,>,>=,<,<=,<>） 多行操作符 左边子查问能够返回多行，但必须是单列，ALL, ANY,IN 其中，ALL和ANY运算符必须与单行比拟运算符（=,>,>=,<,<=,<>）联合应用 IN：等于任何一个ALL：和子查问返回的所有值比拟。例如：sal>ALL(1,2,3)等价于sal>1 && sal>2 && sal>3，即大于所有。ANY：和子查问返回的任意一个值比拟。例如：sal>ANY(1,2,3)等价于sal>1 or sal>2 or sal>3，即大于任意一个就能够。EXISTS：判断子查问是否有返回后果（不关怀具体行数和内容），如果返回则为TRUE，否则为FALSE。 子查问where型子查问查问比“孙红雷”的工资高的员工编号SELECT * FROM t_salaryWHERE basic_salary > (SELECT basic_salary FROM t_employee INNER JOIN t_salary ON t_employee.eid=t_salary.eid WHERE t_employee.ename='孙红雷'); 查问和孙红雷，李晨在同一个部门的员工SELECT * FROM t_employeeWHERE dept_id IN(SELECT dept_id FROM t_employee WHERE ename='孙红雷' OR ename = '李晨');SELECT * FROM t_employeeWHERE dept_id = ANY(SELECT dept_id FROM t_employee WHERE ename='孙红雷' OR ename = '李晨'); ...

本文为信息系统开发实训开发课程的操作阐明 第一步：下载软件https://dev.mysql.com/downloads/mysql/ 第二步：装置下载的文件解压缩到在C盘根目录上面以管理员身份运行cmd(c:\windows\system32),而后在控制台窗口中输出如下代码： cd c:\mysql-8.0.28-winx64\binmysqld.exe -install "Mysql"此窗口临时不要敞开。如果此处报“短少vcruntime140_1.dll”文件，请下载该文件并放到c:\mysql-8.0.28-winx64\bin文件夹中。 在c:\mysql-8.0.28-winx64\ 目录下建设data文件夹及my.ini配置文件。my.ini的配置如下所示[mysql]# 设置mysql客户端默认字符集default-character-set=utf8 [mysqld]#设置3306端口port = 3306# 设置mysql的装置目录basedir=F:\workspace\Dev\mysql# 设置mysql数据库的数据的寄存目录datadir=F:\workspace\Dev\mysql\data# 容许最大连接数max_connections=200# 服务端应用的字符集默认为8比特编码的latin1字符集character-set-server=utf8# 创立新表时将应用的默认存储引擎default-storage-engine=INNODB实现前3步操作后，再次通过管理员身份关上cmd窗口并执行上面的代码cd c:\mysql-8.0.28-winx64\binmysqld --initialize-insecure --console 5.执行实现后，启动mysql服务 net start mysql 第三步：批改明码应用控制台窗口登陆mysql mysql -u root -p明码为空，在输出明码时间接Enter即可 批改root明码ALTER user 'root'@'localhost' IDENTIFIED BY '123456';留神123456为设置的明码 设置 navicat连贯明码 ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '123456';留神123456为设置的明码

明天咱们来聊聊微信中的多表联结查问，应该是小表驱动大表还是大表驱动小表？ 1. in VS exists在正式剖析之前，咱们先来看两个关键字 in 和 exists。 假如我当初有两张表：员工表和部门表，每个员工都有一个部门，员工表中保留着部门的 id，并且该字段是索引；部门表中有部门的 id、name 等属性，其中 id 是主键，name 是惟一索引。 这里我就间接应用 vhr 中的表来做试验，就不独自给大家数据库脚本了，小伙伴们能够查看 vhr 我的项目(https://github.com/lenve/vhr)获取数据库脚本。假如我当初想查问技术部的所有员工，我有如下两种查问形式： 第一种查问形式是应用 in 关键字来查问： select * from employee e where e.departmentId in(select d.id from department d where d.name='技术部') limit 10;这个 SQL 很好了解，置信大家都能懂。查问的时候也是先查问里边的子查问（即先查问 department 表），而后再执行表面的查问，咱们能够看下它的执行打算： 能够看到，首先查问部门表，有索引就用索引，没有索引就全表扫描，而后查问员工表，也是利用索引来查问，整体上效率比拟高。 第二种是应用 exists 关键字来查问： select * from employee e where exists(select 1 from department d where d.id=e.departmentId and d.name='技术部') limit 10;这条 SQL 的查问后果和下面用 in 关键字的一样，然而查问过程却不一样，咱们来看看这个 SQL 的执行打算： ...