Mysql

文章最开始先给大家两条sql，请猜猜他们执行会有什么区别？ SELECT * from student s where age < 17 and name ='zhangsan12' and create_time < '2023-01-17 10:23:08' order by age LIMIT 1SELECT * from student s where age < 17 and name ='zhangsan12' and create_time < '2023-01-17 10:23:08' order by age LIMIT 2这两条sql看似只是limit的数值不同，然而第一个执行耗时3ms，第二个执行耗时66s，相差2000多倍。 故事的起因明天要讲的这件事和上述的两个sql无关，是数年前遇到的一个对于MySQL查问性能的问题。次要是最近刷到了一些对于MySQL查问性能的文章，大部分文章中讲到的都只是一些常见的索引生效场合，于是我回想起了当初被那个离奇的“索引生效”摆布的恐怖。 场景复现因为事件曾经过来多年，因而我只能凭借记忆在本地的数据库进行模仿。首先创立数据库school，数据表student： CREATE TABLE `student` ( `id` bigint NOT NULL AUTO_INCREMENT, `name` varchar(100) DEFAULT NULL, `age` int DEFAULT NULL, `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `student_age_IDX` (`age`) USING BTREE, KEY `student_create_time_IDX` (`create_time`) USING BTREE) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;构造简单明了，其中age和create_time应用BTREE构建了索引。 ...

作者：京东衰弱 孟飞1、 数据库性能优化的意义业务倒退初期，数据库中量个别都不高，也不太容易出一些性能问题或者出的问题也不大，然而当数据库的量级达到肯定规模之后，如果缺失无效的预警、监控、解决等伎俩则会对用户的应用体验造成影响，重大的则会间接导致订单、金额间接受损，因此就须要时刻关注数据库的性能问题。 2、 性能优化的几个常见措施数据库性能优化的常见伎俩有很多，比方增加索引、分库分表、优化连接池等，具体如下： 序号类型措施阐明1物理级别晋升硬件性能将数据库装置到更高配置的服务器上会有空谷传声的成果，例如进步CPU配置、减少内存容量、采纳固态硬盘等伎俩，在经费容许的范畴能够尝试。2利用级别连接池参数优化咱们大部分的利用都是应用连接池来托管数据库的连贯，然而大部分都是默认的配置，因此配置好超时时长、连接池容量等参数就显得尤为重要。 1、 如果链接长时间被占用，新的申请无奈获取到新的连贯，就会影响到业务。 2、 如果连接数设置的过小，那么即便硬件资源没问题，也无奈施展其效用。之前公司做过一些压测，但就是死活不达标，最初发现是因为连接数太小。3单表级别正当使用索引如果数据量较大，然而又没有适合的索引，就会拖垮整个性能，然而索引是把双刃剑，并不是说索引越多越好，而是要依据业务的须要进行适当的增加和应用。 缺失索引、反复索引、冗余索引、失控索引这几类状况其实都是对系统很大的危害。4库表级别分库分表当数据量较大的时候，只应用索引就意义不大了，须要做好分库分表的操作，正当的利用好分区键，例如依照用户ID、订单ID、日期等维度进行分区，能够缩小扫描范畴。5监控级别增强运维针对线上的一些零碎还须要进一步的增强监控，比方订阅一些慢SQL日志，找到比拟蹩脚的一些SQL，也能够利用业务内一些通用的工具，例如druid组件等。3、 MySQL底层架构首先理解一下数据的底层架构，也有助于咱们做更好优化。 一次查问申请的执行过程 咱们重点关注第二局部和第三局部，第二局部其实就是Server层，这层次要就是负责查问优化，制订出一些执行打算，而后调用存储引擎给咱们提供的各种底层根底API，最终将数据返回给客户端。 4、MySQL索引构建过程目前比拟罕用的是InnoDB存储引擎，本文探讨也是基于InnoDB引擎。咱们始终说的加索引，那到底什么是索引、索引又是如何造成的呢、索引又如何利用呢？这个话题其实很大也很小，说大是因为他底层的确很简单，说小是因为在大部分场景下程序员只须要增加索引就好，不太须要理解太底层原理，然而如果理解不透彻就会引发线上问题，因此本文均衡了大家的了解老本和常识深度，有肯定底层原理介绍，然而又不会太过深刻导致难以了解。 首先来做个试验： 创立一个表，目前是只有一个主键索引 CREATE TABLE t1( a int NOT NULL, b int DEFAULT NULL, c int DEFAULT NULL, d int DEFAULT NULL, e varchar(20) DEFAULT NULL, PRIMARYKEY(a) )ENGINE=InnoDB 插入一些数据： insert into test.t1 values(4,3,1,1,'d'); insert into test.t1 values(1,1,1,1,'a'); insert into test.t1 values(8,8,8,8,'h'); insert into test.t1 values(2,2,2,2,'b'); insert into test.t1 values(5,2,3,5,'e'); insert into test.t1 values(3,3,2,2,'c'); insert into test.t1 values(7,4,5,5,'g'); ...

应用上面的命令进行登录： mysql -h 主机名 -u 用户名 -p回车后输出明码即可。 根底命令查看版本select version();数据库操作创立create database [数据库名];删除drop database [数据库名];抉择在你连贯到 MySQL 数据库后，可能有多个能够操作的数据库，所以你须要抉择你要操作的数据库： use [数据库名];查看也就是查看以后有哪些数据库： show databases;以后查看以后选中操作的数据库是谁： select database();表操作查看有哪些表show tables;查看表构造desc [表名];删除表drop table [表名];创立表create table [表名] (列名 列类型,列名 列类型,...);例子create table myhobby( id INT NOT NULL AUTO_INCREMENT, label VARCHAR(40) NOT NULL, info VARCHAR(100) NOT NULL, date DATE, PRIMARY KEY ( id ) )ENGINE=InnoDB DEFAULT CHARSET=utf8;插入数据insert into [表名] ( field1, field2,...fieldN )values ( value1, value2,...valueN );如果数据是字符型，必须应用单引号或者双引号。 例子insert into myhobby ( label, info, date )values ( "喜爱吃水果"," 特地喜爱吃橘子",NOW() );或一次插入多条数据： ...

在 MySQL 中，COLLATE 和 CHARSET 是用来设置字符集和排序规定的参数。 CHARSET 用于设置字符集，字符集是用于编码字符的规定集。罕用的字符集包含 utf8 和 utf8mb4，别离用于编码一般的文本和蕴含 Emoji 等特殊字符的文本。 COLLATE 用于设置排序规定，排序规定是用于比拟和排序字符的规定集。罕用的排序规定包含 utf8_general_ci 和 utf8mb4_unicode_ci，别离用于不辨别大小写的比拟和辨别大小写的比拟。 例如，在创立表时，能够应用 CHARSET=utf8mb4 和 COLLATE=utf8mb4_unicode_ci 参数，来设置表的字符集为 utf8mb4，排序规定为辨别大小写的比拟。 示例代码： CREATE TABLE table_name ( column1 VARCHAR(255) CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci ); 在下面的代码中，列 column1 的字符集设置为 utf8mb4，排序规定设置为辨别大小写的比拟。 须要留神，在 MySQL 中，字符集和排序规定是离开设置的，所以须要同时指定字符集和排序规定能力正确处理字符。 常见的排序规定（COLLATE）包含 utf8_general_ci：不辨别大小写的比拟。utf8_unicode_ci：辨别大小写的比拟。utf8mb4_general_ci：不辨别大小写的比拟，反对 Emoji 等特殊字符。utf8mb4_unicode_ci：辨别大小写的比拟，反对 Emoji 等特殊字符。在 MySQL 中，排序规定是与字符集一起设置的，所以在应用排序规定时须要同时指定字符集。

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 通常对于MySQL运行慢、异样运行等等景象，须要通过收集过后的诊断报告以便前期重点剖析并且给出对应解决方案。对于MySQL来讲，目前收集诊断报告的办法大抵有以下几类： 手动写脚本收集。Percona-toolkit工具集里自带的pt-stalk。MySQL的sys库自带存储过程diagnostics。MySQL Shell 工具的util 组件（需降级到MySQL 8.0.31 最新版能力体验全副诊断程序）这些工具基本上都能够从不同水平收集OS 以及MySQL SERVER 的诊断数据，并且生成对应的诊断报告。 明天咱们来介绍MySQL Shell 最新版本8.0.31 的util组件带来的全新诊断报告收集性能。 util.debug属性有三个诊断函数：collect_diagnostics 用来收集单实例、正本集、InnoDB Cluster 的诊断数据。（<u>旧版本8.0.30 也能够用，不过性能不是很全面</u>）collect_high_load_diagnostics 用来循环屡次收集，并找出负载异样的诊断数据。collect_slow_query_diagnostics 用来对函数collect_diagnostics收集到的慢日志做进一步剖析。明天咱们先来介绍第一个函数collect_diagnostics 如何应用：函数collect_diagnostics 用来收集如下诊断数据并给出对应诊断报告： 无主键的表死索引的表MySQL谬误日志二进制日志元数据正本集状态（蕴含主库和从库）InnoDB Cluster 监控数据表锁、行锁等数据以后连贯会话数据以后内存数据以后状态变量数据以后MySQL 慢日志（需被动开启开关）OS 数据（CPU、内存、IO、网络、MySQL过程严重错误日志过滤等）函数collect_diagnostics 有两个入参：一个是输入门路；另一个是可选字典配置选项，比方能够配置慢日志收集、定制执行SQL 语句、定制执行SHELL命令等等。 以下是罕用调用示例：只传递参数1，给定诊断数据打包输入门路，诊断报告会整体打包为/tmp/cd1.zip。util.debug.collect_diagnostics('/tmp/cd1')激活慢日志抓取（必须条件：MySQL慢日志开关开启、日志输入格局为TABLE），诊断报告会整体打包为/tmp/cd2.zip，并且蕴含慢日志诊断报告。util.debug.collect_diagnostics('/tmp/cd2',{"slowQueries":True})定制执行SQL： 收集预置诊断报告同时也收集给定的SQL语句执行后果。util.debug.collect_diagnostics('/tmp/cd3',{"customSql":["select * from ytt.t1 order by id desc limit 100"]})定制执行SHELL命令： 收集预置诊断报告同时也收集给定的SHELL命令执行后果。util.debug.collect_diagnostics('/tmp/cd4',{"customShell":["ps aux | grep mysqld"]})收集所有成员诊断数据（正本集或者InnoDB Cluster）。util.debug.collect_diagnostics('/tmp/cd5',{"allMembers":True})别离执行以上5条命令，在/tmp目录下会生成如下文件： 以下5个打包文件即是咱们运行的5条命令的后果。 root@ytt-pc:/tmp# ll cd*-rw------- 1 root root 893042 1月 5 10:31 cd1.zip-rw------- 1 root root 818895 1月 5 10:55 cd2.zip-rw------- 1 root root 819183 1月 5 11:02 cd3.zip-rw------- 1 root root 835387 1月 5 11:06 cd4.zip-rw------- 1 root root 2040913 1月 5 11:31 cd5.zip要查看具体诊断报告，得先解压这些文件。先来看下cd2.zip 解压后的内容：对于收集的诊断数据，有tsv和yaml两种格局的报告文件。报告文件以数字0结尾，示意这个诊断报告来自一台单实例MySQL。 ...

【前言】作为中国的 “Fivetran/Airbyte”, Tapdata Cloud 自去年公布云版公测以来，吸引了近万名用户的注册应用。应社区用户上生产零碎的要求，Tapdata Cloud 3.0 将正式推出商业版服务，提供对生产零碎的 SLA 撑持。Tapdata 目前专一在实时数据同步和集成畛域，外围场景包含以下几大类： 实时数据库同步，如Oracle - Oracle, Oracle - MySQL, MySQL - MySQL 等数据入湖入仓，或者为古代数据平台供数，如： 惯例 ETL 工作（建宽表，数据荡涤，脱敏等）为 Kafka/MQ/Bitsflow 供数或下推具体场景则不可胜数，值此之际，咱们将以系列文章模式，为大家盘点 Tapdata Cloud 能够撑持的业务场景，以便大家更好地在业务中利用 Tapdata，本期为系列文章第一弹。（点击申请产品内测，领先体验 →） 以后，异构数据库数据实时同步的利用场景极为常见，一方面随着数据库技术的更新换代、国产化代替，以及数据利用场景的拓展，传统数据库难以满足需要，亟待进行数据迁徙与数据库降级；另一方面，历经几十年的数字化历程，企业数据孤岛越来越重大，将数据实时汇聚对立的需要也越发急切。 传统异构数据库同步的常见实现形式次要是：1、数据库厂商自身提供的迁徙/同步工具，像是 Oracle 的 OGG ；2、通过开源工具和本人编写 SQL 构建数据链路。而 Tapdata 则在这些模式之外，自研了一套齐全脱离简单执行逻辑的极简计划，并反对低代码、可视化操作。 一、Tapdata Cloud：低代码可视化实现异构数据库数据实时同步作为一款由 Tapdata 推出的异构数据库实时复制与同步 SaaS 服务，Tapdata Cloud 在产品能力上具备以下劣势： 更宽泛的数据源反对：反对多种常见数据库和 SaaS 数据源，在 MongoDB、MySQL、Oracle、SQL Server、DB2、Elastic、Kafka、Sybase、PostgreSQL、Redis、GaussDB、Doris 等支流及新兴的开源或商业数据库之余，还在一直扩大对包含 Gbase 8s、OceanBase、Tablestore、Kylingence 等在内的国产数据库反对；更实时：基于日志的数据库 CDC 技术，0入侵实时采集，毫秒级同步提早，助力平滑迁徙；低代码更高效：拖拽式的“零”代码配置操作，基于JS的低代码，轻松实现跨零碎跨类型的数据实时同步和解决；更灵便牢靠：基于云原生架构，更加弹性，更具平安保障性；更自主可控：纯国产自研，对国产数据库更敌对，高度适配国产化倒退需要。二、操作演示：以 Oracle → MySQL 的数据同步工作为例第一步：创立数据源 Oracle 连贯 【△ 查看操作详情视频】 第二步：创立数据指标 MySQL 连贯 ...

前言大家好，我是xicheng。当初持续更新MySQL，本篇讲InnoDB的数据目录。另外，InnoDB的常识脑图如下所示，大家坐稳了。 数据目录构造以MySQL8.0为例，不同版本可能会有出入。通过SHOW VARIABLES LIKE 'datadir'查看数据目录。InnoDB和MyISAM这两种存储引擎，创立一个数据库时，会在数据目录下创立一个与数据库同名的文件夹。 InnoDB表存储数据的形式为了治理页，用了表空间或者文件空间概念，它能够对应文件系统上一个或多个实在文件。每一个表空间能够被划分为很多个页。而表空间又被划分为几种不同的类型。详情请参考MySQL官网文档Tablespaces。 零碎表空间（system tablespace）InnoDB会在数据目录下创立一个名为ibdata1、大小为12M的文件，这个文件就是对应的零碎表空间在文件系统上的示意。 在一个MySQL服务器中，零碎表空间只有一份。 独立表空间（file-per-table tablespace）创立了多少个表，就有多少个独立表空间，用来存数据与索引。它在数据目录的库名文件夹下，叫 表名.ibd。 通用表空间（General tablespaces）独立于MySQL的数据目录。不便迁徙数据，特地是空间不够的状况。 undo表空间（Undo Tablespaces）Undo日志记录的汇合。 长期表空间（Temporary Tablespaces）会话长期表空间：存储了用户创立的长期表和优化器创立的外部长期表。全局长期表空间：存储对用户创立的长期表所做的更改的回滚段。 MyISAM存储数据的形式该存储引擎的数据和索引是离开寄存的。没有表空间。在数据目录下的库名文件夹中，每个表会存在2文件，别离叫表名.MYD, 表名.MYI。表名.MYD存数据，表名.MYI存索引。 其它文件与规定数据目录下还存储了一些其它文件：服务器过程文件，服务器日志文件，密钥文件等。为了防止数据库名和表名呈现某些特殊字符而造成文件系统不反对的状况，会把除数字和拉丁字母以外的所有字符在文件名里都映射成@编码值的模式作为文件名。例如InnoDB的表名为'test?'，对应的.ibd文件成了test@003f.ibd。 MySQL零碎数据库简介mysql存储了账户和权限，存储过程，日志，时区信息等。 information_schema存储了对于MySQL服务器所保护的所有其它数据库的信息。如数据库名，数据库的表，数据列数据类型与拜访权限等。 performance_schema收集数据库服务器性能参数。并且该库里的表的存储引擎均为PERFORMANCE_SCHEMA，而用户是不能创立存储引擎为PERFORMANCE_SCHEMA的表。 sys通过视图的模式把information_schema和performance_schema联合起来，让程序员能够更不便的理解MySQL服务器的一些性能信息。 结尾InnoDB的数据目录就讲完了，心愿大家能继续学习。下一篇MySQL文章讲InnoDB-统计数据。微信扫描下方二维码，或搜寻“xicheng”，关注公众号后回复【笔记】，有我筹备的 15 万字 Java 面试笔记。

作者：刘聪 爱可生华东交付服务部 DBA 成员，专职 MySQL 故障解决及相干技术支持。座右铭：好好学习，天天向上。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 一、问题形容客户须要做一套库的迁徙，因为库的数据量不大，40G左右，并且须要到近程机器下来做全量复原。所以第一工夫想到的天然是 mysqldump 工具来做。然而没想到会产生这种“惨案”。 mysqldump 备份失败，报错表不存在。 查看 MySQL 客户端去查看表信息以及表的物理文件包含环境信息（是否严格辨别大小写），整顿的景象如下： mysqldump 报错：table doesn't exist；show tables 察看：db 存在，报错的 table 也存在；select 查看表数据：报错 table doesn't exist ；察看物理文件：db.opt 文件不存在；报错的 table，idb 文件不存在，仅有 frm 文件；查看 mysql-error.log ：有 DROP database 的提醒，且记录了报错 table 的 frm 文件 was lost ;MySQL 环境信息：lower_case_table_names = 1 。 二、剖析诊断首先，咱们看一下 MySQL 官网提供的信息（官网链接：https://dev.mysql.com/doc/ref...）。 依据上面截图信息能够确定 Unix 平台上，lower_case_table_names 默认 = 0 ，是大小写敏感的。 从 mysqldump 报错所提醒的表名中蕴含了大写，不难推断出：是在 lower_case_table_names = 0 条件下，创立了该表，所以表名和物理文件名也都蕴含大写。而以后的 MySQL 环境是 lower_case_table_names = 1（也就是不管 sql 中是否明确了表名的大小写，均按小写去匹配），能够确定此环境变量有做过变更。 ...

场景形容：对立登录平台之前的操作步骤（用户利用绑定，用户角色绑定）比拟多，为晋升用户体验，对立批量操作，起初就加了一个用户组的概念（用户绑定用户组和角色，用户组绑定多个角色，角色绑定多个利用，这里波及到一些交并集操作），然而随之而来带来了一个问题，因为该零碎其实次要是面对B端用户，并发其实不高，很难遇到一些并发导致的问题，然而因为这个批量操作导致的大事务，事务工夫过长导致锁抵触的概率极大减少，所以就呈现了死锁问题。 而后我就查mysql死锁日志，show engine innodb status，该命令显示的内容长度有限度，能够设置SET GLOBAL innodb_status_output=ON;SET GLOBAL innodb_status_output_locks=ON;，默认输入到log-err，能够通过show variables like 'log_err%';查看设置的输入门路，如果是stderr，则示意规范谬误输入 而后我就看日志，发现了两个抵触的事务产生了死锁，次要是两张表，一张用户表open_app_user，主键id，执行的sql是update open_app_user set xx=xx where id = 14310 and version=5，另一张表是open_role_user，是用户和角色的关联表，就两个字段同时也是联结主键，role_id和user_id,执行的sql是delete from open_role_user where user_id=654321; 这里的delete from open_role_user where user_id = xx的业务逻辑是用户角色关系更新（可能是绑定或解绑），所以每个中央都须要依据user_id删除原来的记录再去新增，而这条sql是有问题的，这里须要阐明一下mysql的删除以及删除的加锁机制： InnoDB上删除一条记录，并不是真正意义上的物理删除，而是将记录标识为删除状态（删除状态的记录会在索引中寄存一段时间）。所以在RR隔离级别下，1、在非惟一索引的状况下，删除一条存在的记录是有gap锁，锁住记录自身和记录之前的gap，InnoDB会在记录上加next key锁(对记录自身加X锁，同时锁住记录前的GAP，避免新的满足条件的记录插入。2、在惟一索引和主键的状况下删除一条存在的记录，因为都是惟一值，进行删除的时候，是不会有gap存在以下是一段演示代码 //先执行删除的操作begin;delete from `open_role_user` where `user_id`=654321;//再执行以下语句查看mysql的加锁状况select * from performance_schema.data_locks;咱们看到删除应用非主键或惟一索引，mysql会加supremum pseudo-record一个gap锁和目前表里所有的记录都加一个record行锁 而后我换一条应用主键删除的sql：delete from open_role_user where role_id = 654321 and user_id=654321; 这时候就只加了一个record行锁了 对于应用非惟一索引或主键删除会相当于给整个表上锁，这时候抵触的概率是十分大的，而换成应用主键删除的话就只会锁住一行记录，这样是能无效缩小抵触状况的。 另外还有一种方法，就是把mysql默认的隔离级别RR可反复读改为RC读已提交，这次我执行 //先执行删除的操作begin;set session transaction isolation level read committed;delete from `open_role_user` where `user_id`=654321;而后这边加锁就只会加上符号where条件的记录的锁了，实际上许多大公司也都是用的RC级别，包含oracle默认的就是RC隔离级别，相比于RR，对于UPDATE or DELETE语句，RC只为它更新或删除的行（合乎where条件的记录）持有锁，大大降低了死锁的可能性，对高并发场景比拟敌对。对于UPDATE，如果行已被锁定，InnoDB 还会执行一个“半统一读”，会多进行一次判断，当 where 条件匹配到的记录与以后持有锁的事务中的记录不抵触时，就会提前开释 InnoDB 锁，尽管这样做违反了二阶段加锁协定，但却能够缩小锁抵触，进步事务并发能力，是一种很好的优化行为。 ...

本文曾经收录到Github仓库，该仓库蕴含计算机根底、Java根底、多线程、JVM、数据库、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服务、设计模式、架构、校招社招分享等外围知识点，欢送star~ Github地址：https://github.com/Tyson0314/... 前言SELECT COUNT(*)会不会导致全表扫描引起慢查问呢？ SELECT COUNT(*) FROM SomeTable网上有一种说法，针对无 where_clause 的 COUNT(*)，MySQL 是有优化的，优化器会抉择老本最小的辅助索引查问计数，其实反而性能最高，这种说法对不对呢 针对这个疑难，我首先去生产上找了一个千万级别的表应用 EXPLAIN 来查问了一下执行打算 EXPLAIN SELECT COUNT(*) FROM SomeTable后果如下 如图所示: 发现的确此条语句在此例中用到的并不是主键索引，而是辅助索引，实际上在此例中我试验了，不论是 COUNT(1)，还是 COUNT()，MySQL 都会用老本最小的辅助索引查问形式来计数，也就是应用 COUNT() 因为 MySQL 的优化曾经保障了它的查问性能是最好的！随带提一句，COUNT()是 SQL92 定义的规范统计行数的语法，并且效率高，所以请间接应用COUNT()查问表的行数！ 所以这种说法的确是对的。但有个前提，在 MySQL 5.6 之后的版本中才有这种优化。 那么这个老本最小该怎么定义呢，有时候在 WHERE 中指定了多个条件，为啥最终 MySQL 执行的时候却抉择了另一个索引，甚至不选索引？ 本文将会给你答案，本文将会从以下两方面来剖析 SQL 选用索引的执行老本如何计算实例阐明SQL 选用索引的执行老本如何计算就如前文所述，在有多个索引的状况下， 在查问数据前，MySQL 会抉择老本最小准则来抉择应用对应的索引，这里的老本次要蕴含两个方面。 IO 老本: 即从磁盘把数据加载到内存的老本，默认状况下，读取数据页的 IO 老本是 1，MySQL 是以页的模式读取数据的，即当用到某个数据时，并不会只读取这个数据，而会把这个数据相邻的数据也一起读到内存中，这就是有名的程序局部性原理，所以 MySQL 每次会读取一整页，一页的老本就是 1。所以 IO 的老本次要和页的大小无关CPU 老本：将数据读入内存后，还要检测数据是否满足条件和排序等 CPU 操作的老本，显然它与行数无关，默认状况下，检测记录的老本是 0.2。实例阐明为了依据以上两个老本来算出应用索引的最终老本，咱们先筹备一个表（以下操作基于 MySQL 5.7.18） CREATE TABLE `person` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `name` varchar(255) NOT NULL, `score` int(11) NOT NULL, `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `name_score` (`name`(191),`score`), KEY `create_time` (`create_time`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这个表除了主键索引之外，还有另外两个索引, name_score 及 create_time。而后咱们在此表中插入 10 w 行数据，只有写一个存储过程调用即可，如下: ...

第一次在思否上写货色，明天介绍一个本人开发的一个学习工具“Jitor校验器”，次要用于 MySQL 的入门学习。这是我写的一本教材的配套软件，不晓得会不会被看作广告，但这是一个完全免费的工具，应该思否会欢送的吧。 我还不晓得如何上传文件，只好请读者从百度网盘下载（提取码1234），这是一个绿色软件，解压到根目录下就能够间接运行，C盘、D盘都行，然而肯定要解压到根目录。 解压进去的“Jitor校验器”是这样的： 如果只是想体验一下，间接双击“《MySQL数据库利用实战教程》新书体验.bat”，用几分钟工夫就能够体验一把。 如果想要用这个软件进行学习，双击“Jitor启动.bat”运行软件，在首页上注册一个收费账号，就能够开始应用它，十分不便的，如果想得到更好的学习效果，能够购买配套的教材。 实训内容反对 MySQL 5.5 ~ 8.0 版，反对 Navicat，MySQL Workbench，和 dbForge 客户端。 上面简略介绍一下这个工具的应用，界面是这个样子的。 编辑 点击实训名称，能够关上实训，关上的实训是这个样子的。 编辑 每个实训是由一系列步骤组成的，做好一步能力做下一步。 第一步是实训内容介绍，也就是实训步骤列表。 第二步是初始化环境，每个实训都是独立的，因而初始的环境要求是不同的，如果实训内容是数据插入，那么初始化的内容就包含主动创立数据库和表。 第三步开始是实训的操作内容，依照要求操作就能够了。如果操作错了，例如数据库名、表名或列名、或者是数据类型错了，在【Jitor 校验第 n 步】的时候就会弹出错误信息，改过并通过校验后，能力做下一步。 在上方的进度条上，胜利通过的步骤用绿色示意，失败的步骤用红色示意。 例如这个实训第 4 步的错误信息： 为防止列的名称谬误，能够间接复制列名。这一步其余可能的错误信息还有：    在有的步骤，还能够通过一个链接关上网页来查看录入的数据。 这是网页的成果，读者无需编程，只是间接体验。  编辑 这样在一个入门的实训中，就体验了数据库的创立、表的创立、数据录入、数据批改、数据查问以及数据在网页上的展现这样一个残缺的过程，对数据库有一个直观的意识。 这个工具应用十分不便，无需再作解释，连忙下载来看看吧。  “Jitor校验器”是为教学而设计的，对一般读者有下述长处。 提供残缺的实训领导资料，实训资料具体而具备针对性，每一步的要求都写得明明白白，就像有个老师在身边领导。提供智能化的学习环境，实时失去操作是否胜利的反馈，谬误时弹出具体的出错信息。不便通过实训来验证知识点，例如每个实训的第二步会筹备好实训的环境，有许多代码能够间接复制，大大加重了非关键代码的录入量。不多写了，拜访 《MySQL数据库利用实战教程（微课版）》附录 E 有更多的信息。

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 在 GITHUB 上晃荡，发现一款开源的 MySQL Shell 插件，装置配置好后，能够额定减少 MySQL Shell 的组件多样性以及相似晚期 MySQL Utilities 工具集的各种性能（MySQL Utilities 曾经不再开发了！ ）。 插件地址：https://github.com/lefred/mys... 装置非常简单，创立对应的 MySQL Shell Plugins 目录，完了把插件整个拷贝到此即可。 mkdir -p ~/.mysqlsh/pluginsgit clone https://kgithub.com/lefred/mysqlshell-plugins.git ~/.mysqlsh/plugins我的OS环境是 Fedora Server 37 ，拷贝完对应目录后，提醒各种 Python 包依赖谬误，能够依据日志~/.mysqlsh/mysqlsh.log 内容提醒顺次解决，此处省略步骤。 解决好各种依赖包后，进入 MySQL Shell 命令行，能够看到呈现很多新的组件：audit、check、config 等等。这里就不贴这些内容了。 我来简略演示其中几个组件：第一，复制组件：replication。目前的拓扑是这样的：我本地搭了三个实例 127.0.0.1:3310 、127.0.0.1:3311 、127.0.0.1:3312 。这三个实例组建了一个正本集，3310是主，3311和3312是从。 MySQL localhost:3311 ssl Py > rs.status(){ "replicaSet": { "name": "rs1", "primary": "127.0.0.1:3310", ... "topology": { "127.0.0.1:3310": { "address": "127.0.0.1:3310", "instanceRole": "PRIMARY", "mode": "R/W", "status": "ONLINE" }, "127.0.0.1:3311": { "address": "127.0.0.1:3311", "instanceRole": "SECONDARY", "mode": "R/O", ... "status": "ONLINE" }, "127.0.0.1:3312": { "address": "127.0.0.1:3312", "instanceRole": "SECONDARY", "mode": "R/O", ... "status": "ONLINE" } }, "type": "ASYNC" }}这里我被动制作了一个谬误，完后连贯到其中一台从库上应用 replication.status() 获取本机复制状态：此时 SQL 线程进行，并且显示提早20秒。 ...

利用背景:利用A,springboot2+shardingJdbc5.1架构, 应用mysql数据库,其中有些订单表为分区表,按日分区。问题形容今日在生产环境保护分区表分区时，利用报了死锁。具体日志如下 找到DBA去排查时，基于他们的教训，他们也不抵赖这是利用的死锁，反而狐疑是咱们的利用代码或者JDBC有问题，这 ... 问题复现在排查相干材料后，我判定了是mysql的锁的机制的问题，于是我做了个测试 利用： session1 客户端： session2session1: 开启事务，并执行查问，持有 XXX 对象的 SHARED_READ 锁，简称SR锁。session2: 执行增加分区（DDL）命令，想要获取 XXX 对象的 EXCLUSIVE 锁，简称X锁.这个状态时，session2 在等 session1 开释锁。 sessin1: 继续执行 update 命令，会申请 XXX 对象的 SHARED_WRITE 锁，简称SW锁。这个状态时，session2 在期待获取 XXX 对象的X锁，session1 想要申请SW锁，必须等session2 开释掉锁。所以 session1 在等 session2 开释锁。 两个会话相互期待，产生死锁，MySQL数据库会主动回滚其中一个事务。session1 : session2: 此刻死锁曾经呈现，咱们来看下数据库里的死锁日志 测试的后果和我料想or咱们遇到的一样，是X锁和SW锁的互相互斥的机制导致的死锁，而这种死锁不会在mysql的死锁日志中记录 问题起因先给大家看一下mysql的锁的兼容矩阵 Request | Granted requests for lock | type | S SH SR SW SWLP SU SRO SNW SNRW X |----------+---------------------------------------------+S | + + + + + + + + + - |SH | + + + + + + + + + - |SR | + + + + + + + + - - |SW | + + + + + + - - - - |SWLP | + + + + + + - - - - |SU | + + + + + - + - - - |SRO | + + + - - + + + - - |SNW | + + + - - - + - - - |SNRW | + + - - - - - - - - |X | - - - - - - - - - - |依据mysql锁兼容矩阵图能够看出，X锁和任何锁是不兼容的（敲黑板，背下来）.咱们的测试场景下，session2 在期待获取 xxx 对象的X锁，session1 想要申请SW锁，必须等session2 开释掉锁。所以 session1 在等 session2 开释锁 , 进而产生死锁解决方案1、在session1中的查问，加上 for update, 使得session1 一开始就获取SW锁2、将session1的查问独立出以后事务3、优化 mysql, 将DDL操作改写成软提交形式, 获取不到锁后，开释曾经拿到的锁，而后一直重试 ...

应用 procedure 批量建表。 有几点大家须要留神： prepare_stmt 指令只能应用 会话变量 来预筹备 sql，无奈应用 declare 申明的 局部变量。procedure 中的创立的 @会话变量 倡议做清理，防止会话变量净化。SET @foo = NULL; 即可。DROP PROCEDURE IF EXISTS batchCreateTabPart;DELIMITER $$-- count 批量建表的数量CREATE PROCEDURE batchCreateTabPart(IN count INT UNSIGNED)BEGIN -- 存储过程局部变量定义 DECLARE i INT UNSIGNED; DECLARE suffix VARCHAR(8); -- 局部变量初始化 SET i = 0; SET suffix = ""; WHILE i < count DO IF i < 10 THEN SET suffix = CONCAT("0", i); ELSE SET suffix = i; END IF; SET @dropSql = CONCAT('DROP TABLE IF EXISTS `tb_part_', suffix, '`;'); PREPARE stmt FROM @dropSql; EXECUTE stmt; -- 拼接创立表 ddl SET @createSql = CONCAT('CREATE TABLE IF NOT EXISTS `tb_part_', suffix, "`( `id` bigint UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, `name` varchar(32) NOT NULL COMMENT '用户名', `age` tinyint UNSIGNED NOT NULL DEFAULT 0 COMMENT '年龄', `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP )ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='分示意例';"); PREPARE stmt FROM @createSql; EXECUTE stmt; SET i = i + 1; END WHILE; -- 删除过程中定义的用户会话变量 SET @dropSql = NULL; SET @createSql = NULL;END $$DELIMITER ;CALL batchCreateTabPart(100);DROP PROCEDURE IF EXISTS batchCreateTabPart;tab_part_00tab_part_01...tab_part_10...tab_part_99 ...

MVCCMultiversion Concurrency Control，象征多版本并发管制，也就是MySql InnoDB引擎解决幻读问题的计划MySql InnoDB默认隔离级别是可反复读，本文后续会围绕MVCC开展，简述MVCC解决该隔离级别问题的原理&形式 相干知识点链接数据库隔离级别 -> 内容如题MySql 共享锁 & 排他锁 -> 讲述SQL层面会用到的2种锁MySql 行级锁 & 表级锁 -> 讲述不同存储引擎的锁类型 快照读快照读又称为一致性读，指读取的是快照数据，MySql InnoDB 中不加锁的 SELECT 都属于快照读，即非阻塞读 SELECT * FROM table_name WHERE上文知识点中会提到，倒退出快照读是为了进步并发性能，快照读的实现是基于MVCC，防止了加锁操作从而升高了开销；在多版本控制中，快照读并不一定是最新版本的数据，可能是历史版本；快照读的前提是隔离级别可反复读，串行化级别下会进化成以后读 以后读以后读获取的是最新数据，读取时要保障其余并发事务不能批改以后记录，会对读取的记录进行加锁，加锁语句可在上述链接 共享锁 & 排他锁 中查看 以后读带来的问题事务A select * from table where column > 1 for update事务B insert into table(column) values (2);insert into table(column) values (3);事务A在事务B之前应用以后读获取数据，事务B在事务A之后进行数据写入，在主库中执行此命令可能不会有问题，然而如果事务B的数据在事务A完结之前写入结束，从库通过binlog同步，则在从库中事务A产生的改变可能对事务B的数据失效，导致主库从库数据不统一； 间隙锁对于上述问题，MySql 引入了间隙锁来解决，其原理为，在事务A加锁是时，MySql会对其搜寻的数据的间隙加上锁，即对所有column > 1的数据加锁，即便数据不存在，或者说，不容许任何事务对column > 1进行写入，此时就能阻止事务B的执行，从而保障了主库从库数据统一 间隙锁带来的问题在上述案例中，如果事务A迟迟不执行结束，会阻塞所有写入column > 1数据的事务，此时并发效率是非常低的，如果锁住的数据量过大，都会导致一系列问题，在高并发的环境下是无奈承受的，因为在MySql InnoDB中，默认是敞开间隙锁的，应用须要独自开启 innodb_locks_unsafe_for_binlog快照读解决的问题承接上述，在以后读带来的一些列问题，为了提高效率，MySql 引入了快照的概念；简述而言，在事务开始时，MySql 会给影响到的数据加一个版本号(trx_id)，这个版本号即为以后事务id，当后续有其余事务对数据进行操作，版本号会递增，在后面的事务查问时，只会匹配到版本号等于或小于以后事务id的数据，因而无奈读取到后续事务写入的数据，从而解决幻读，与不可反复读的问题；快照读的实现，次要依赖于版本链 & Undo & Read View ...

前言先前写过一篇文章聊聊如何利用redis实现多级缓存同步,外面讲到业务部门因数据库宕机，有技术提出当数据库宕机，切换到redis，明天咱们就来聊聊如何触发这个切换动作？ 1、计划一：利用异样机制伪代码如下： 首先这个计划是不可行的，因为每次申请，还是先走到数据库逻辑，而后等抛出异样，这个工夫会挺长的，业务上是无奈承受的 2、计划二：被动进行mysql探活实现思路： 能够利用数据库连接池检测无效连贯的思路 实现计划 1、形式一：利用druid连接池的ValidConnectionChecker进行扩大外围逻辑如下 @Slf4jpublic class MysqlConnectionCheck extends MySqlValidConnectionChecker { private ApplicationContext applicationContext; public MysqlConnectionCheck(ApplicationContext applicationContext) { this.applicationContext = applicationContext; } @Override public boolean isValidConnection(Connection conn, String validateQuery, int validationQueryTimeout) throws Exception { return checkMySQLCommunications(conn,validateQuery,validationQueryTimeout); } private boolean checkMySQLCommunications (Connection conn, String validateQuery, int validationQueryTimeout) { boolean validConnection = false; try { validConnection = super.isValidConnection(conn, validateQuery, validationQueryTimeout); } catch (Exception e) { } if(validConnection){ boolean b = MySQLCommunicationsHolder.isMySQLCommunicationsException.compareAndSet(true, false); if(b){ CommunicationsHealthEvent event = CommunicationsHealthEvent.builder().conn(conn).build(); applicationContext.publishEvent(event); } } return validConnection; }}在yml配置咱们自定义的检测器 ...

原文链接：何晓东 博客 场景是：从一堆学习记录中，去重并获取最近学习的几条课程ID，顺手就能想到这样的一条SQL语句： select distinct a from table order by updated_at desc limit 5如果列为 a 的数据有很多条，就会发现最终取到的那条数据可能不是 updated_at 最近的那条数据，因为 distinct 有一次默认的排序，而后生成一个长期表，而后 order by 无奈从最开始的原始数据中进行排序，仅排序两头表，无奈得出正确后果。改成 distinct a, updated_at 的话，实际上又失去了 distinct 的意义了。 计划一：应用子查问形式，将后果先排序，当做一个表，而后去重保留最新的一条数据 select distinct a from (select a from table order by updated_at desc) t limit 5计划二：借助 max 和 group by 个性间接取最大值，取值 select a, max(updated_at) from table group by a order by updated_at desc limit 5举荐应用计划二，可读性高很多

Hello，大家好随着业务的快速增长，业务体量变得越来越大，这个过程咱们会碰到各种问题，倒逼着咱们进行技术升级。那明天咱们来聊下，这个过程将会碰到对于数据的问题。数据增长带来的懊恼业务快速增长，业务表数据记录一直在减少，这就会带来两个问题。第一，数据库数据最终将会保留在本地磁盘中，数据记录越多，磁盘占用空间就会越多，对应残余可用空间就会越少。残余空间达到肯定的阈值之后，将会引发磁盘空间的继续报警，耗费贵重的数据库生产服务器的资源。第二，业务表记录越多，表查问的效率就会相应变低，另外表变更也会变的很麻烦。那解决这个问题，解决办法有很多，那 明天介绍其中一种形式，数据归档。数据归档数据归档的解决思路非常简单，就是将生产库的数据转移到领有雷同表构造的数据库中，通过缩小生产库记录数量，从而进步数据查问等操作的效率。数据归档的流程如图所示： 数据归档分为三个流程 创立一个新的数据库-归档库，而后在归档库创立与生产库雷同的表一直查问生产库数据记录，同步复制到归档库生产库删除曾经复制的数据记录 尽管数据数据归档流程非常简单，然而设计数据归档的计划，咱们必须想分明以下几个问题： 归档前：那些数据能够归档？归档库如何选型？归档中：数据归档的执行计划归档后：数据归档带来问题预案 归档之前首先咱们须要思考第一个问题，那些数据能够归档？表数据量很大，并且存在很显著的冷热数据，冷数据简直很少拜访。一个十分典型的例子，订单数据。咱们通常拜访最近的历史订单，而一年前的历史订单查看就会很少。又比方优惠券数据，还未过期的优惠券，可能须要被查问应用。而一年前过期的，或者说曾经被应用的优惠券，就会被很少拜访。所以，设计数据归档的之前，咱们须要思考，咱们归档的数据是否适宜被归档。第二，咱们须要思考归档数据库的选型。数据归档次要目标是为了节约贵重的生产服务器存储，数据须要通过压缩后才会存到数据库。所以，归档库须要抉择那些反对高压缩比的存储引擎。咱们目前归档库选型应用 TokuDB 引擎的 MySQL数据库，压缩比大概为6:1。归档之中下面流程咱们看到，数据归档无非就是查问数据，插入数据，而后删除数据。那咱们能够基于这个流程开发一个通用的归档脚本。Google 搜寻了一圈，在 Github 上找到了一个归档小工具，基本上实现了数据归档的主动运行，对立的归档任务调度治理、主动监控和预警、主动生成报表。在肯定水平上节约了生产力，进步了运维效率。github地址：github.com/dbarun/mysq…非凡归档需要一般来说，通用数据归档脚本能够满足大部分状况。然而如果数据归档有一些非凡的要求的话，那就须要本人开发。比如说，咱们有一个我的项目，数据归档的需要是批量查问 90 天前的数据，而后将这些数据插入到当年的归档表中。举个例子，如果以后数据记录创立工夫为 2020-12-31，这个记录将会归档到 archive_2020 表中。那如果这个数据记录创立工夫为 2021-01-01，那这个记录就会被归档到 archive_2021 表中。 那像这种有显著业务需要数据归档形式，那就须要咱们在我的项目中本人开发。归档注意事项第一，数据归档过程须要一直的读写生产库，这个过程将会大量应用的网络、IO。那为了避免对线上业务造成压力，数据归档个别只在业务低峰期执行。另外咱们须要尽可能调优数据，尽量升高对线上业务的影响。第二，数据归档之后，将会删除生产库的数据，这些数据删除之后，将会造成数据空洞。即数据删除之后，表空间并未及时的开释，当长时间没有新的数据填充，会造成空间节约的状况。所以数据删除之后，咱们须要及时优化数据空洞，开释这些被节约的空间。第三，如果数据归档中，影响了线上业务，那肯定要及时止损，完结数据归档，而后复盘问题，及时找到问题。归档之后数据归档之后，将会带来一些问题，咱们须要及时想好这些的预案。数据幂等被毁坏生产数据库，咱们能够应用惟一索引，避免插入反复数据。然而数据归档之后，局部数据被归档到归档库，这样生产库就又能够插入这些数据库，这就会造成业务上插入反复的数据。那这个问题，咱们能够应用 ID 发号器解决。生产数据库惟一索引存储 ID 发号生成的 ID，ID 发号器每天枯燥递增，那实践上就不会反复的 ID。归档查问库 RT 较高因为归档数据库应用高压缩比的存储引擎，这就会导致归档库查问 RT 变高，例如生产库查问是1ms 的rt，用 tokudb 会变成2ms。那这个问题，咱们就须要从业务下来思考，是否能够承受。如果你是后盾类查问业务，能够承受高 RT 的查问，那咱们齐全能够应用归档库。那如果你是前台类用户侧查问，查问 RT 要低，那就不能承受查问归档库。然而从另一方面来讲，如果业务上要求查问 RT 肯定要比拟低，那这些数据真的适宜被归档吗？归档数据缺失，造成业务影响数据归档之后，生产库就会缺失这部分数据，那如果业务上正好须要应用这些数据，那就会造成业务上异样。比如说，领取业务中，退款个别须要反对一年以内的订单。那如果退款的时候，正交易领取的数据正好被归档，那就会造成退款的时候找不到对应的领取数据，造成退款失败。那这个问题解决办法有两种，第一个解决办法，双重查问。如果生产数据库找不到业务数据，那就去归档库查找。这个解决办法适宜离线的业务。第二个解决办法，设计一个兼容计划，提供数据逆向接口，反向将归档数据库的记录从新还原到生产库。那这种解决办法，只适宜大量因为归档数据造成业务异样的业务场景。总结数据归档能够解决生产数据库因为数据量过多，从而引发磁盘空间预警，表查问、变更效率变低等问题。然而工作计划都存在双面性，数据归档可能引发数据幂等被毁坏、归档查问库 RT 较高、归档数据缺失，造成业务影响等问题。所以咱们设计数据归档的计划时，须要全面思考，提前准备预案，解决可能造成的业务问题

作者：京东批发 石磊 TiDB 作为开源 NewSQL 数据库的典型代表之一，同样反对 SQL，反对事务 ACID 个性。在通信协定上，TiDB 抉择与 MySQL 齐全兼容，并尽可能兼容 MySQL 的语法。因而，基于 MySQL 数据库开发的零碎，大多数能够平滑迁徙至 TiDB，而简直不必批改代码。对用户来说，迁徙老本极低，过渡天然。 然而，仍有一些 MySQL 的个性和行为，TiDB 目前临时不反对或体现与 MySQL 有差别。除此之外，TiDB 提供了一些扩大语法和性能，为用户提供更多的便当。 TiDB 仍处在疾速倒退的路线上，对 MySQL 性能和行为的反对方面，正按 路线图 的布局在前行。 兼容策略先从总体上概括 TiDB 和 MySQL 兼容策略，如下表： 通信协定SQL语法性能和行为齐全兼容兼容绝大多数兼容大多数截至 4.0 版本，TiDB 与 MySQL 的区别总结如下表： MySQLTiDB隔离级别反对读未提交、读已提交、可反复读、串行化，默认为可反复读乐观事务反对快照隔离，乐观事务反对快照隔离和读已提交锁机制乐观锁乐观锁、乐观锁存储过程反对不反对触发器反对不反对事件反对不反对自定义函数反对不反对窗口函数反对局部反对JSON反对不反对局部 MySQL 8.0 新增的函数外键束缚反对疏忽外键束缚字符集只反对 ascii、latin1、binary、utf8、utf8mb4减少/删除主键反对通过 alter-primary-key 配置开关提供CREATE TABLE tblName AS SELECT stmt反对不反对CREATE TEMPORARY TABLE反对TiDB 疏忽 TEMPORARY 关键字，依照一般表创立DML affected rows反对不反对AutoRandom 列属性不反对反对Sequence 序列生成器不反对反对三种计划比拟双写计划：同时往mysql和tidb写入数据，两个数据库数据齐全放弃同步 •长处：此计划最平安，作为兜底计划不需放心数据库回滚问题，因为数据完全一致，能够无缝回滚到mysql •毛病：新计划，调研计划实现，老本较高 读写拆散：数据写入mysql，从tidb读，具体计划是切换到线上当前，放弃读写拆散一周工夫左右，这一周工夫用来确定tidb数据库没有问题，再把写操作也切换到tidb •长处: 切换过程，mysql和tidb数据放弃同步，满足数据回滚到mysql计划 •毛病：mysql和tidb数据库同步存在延时，对局部写入数据要求实时查问的会导致查问失败，同时一旦整体切换到tidb，无奈回切到mysql 间接切换：间接一步切换到tidb ...

GET_LOCK()是一个 MySQL 函数，能够用来在数据库中获取一个互斥锁。这个函数的语法如下： GET_LOCK(str,timeout)其中，str 是要获取的互斥锁的名称，timeout 是在尝试获取锁的工夫限度，单位为秒。 要应用 GET_LOCK()函数，你须要在一条 SELECT 语句中应用它，例如： SELECT GET\_LOCK('my\_lock', 10);如果胜利获取了互斥锁，这条语句会返回 1，如果在给定的工夫内无奈获取锁，则会返回 0。 请留神，在应用 GET\_LOCK()函数后，你须要应用 RELEASE\_LOCK()函数来开释锁，免得造成死锁。 SELECT RELEASE\_LOCK('my\_lock');请留神，当一个会话获取了一个互斥锁后，其余会话将无奈获取该锁，直到它被开释为止。因而，请确保在应用完互斥锁后及时开释锁，以防止导致其余会话无奈持续工作。

名称值操作系统CentOS Linux release 7.8.2003 (Core)mysql5.7.27mysql包寄存门路/hom/software/mysql-5.7.27-linux-glibc2.12-x86_64.tar.gzmysql 下载链接https://downloads.mysql.com/a... mysql 装置参考：https://dev.mysql.com/doc/ref... 装置须要的rpm包，yum install libaio减少组 groupadd mysql减少用户 useradd -r -g mysql -s /bin/false-r 创立零碎用户账户。不会倡议用户主目录。-s 用户登录后应用的Shell类型解压mysql包,tar -zcvf /hom/software/mysql-5.7.27-linux-glibc2.12-x86_64.tar.gz创立软链接 cd /usr/localln -s /home/software/mysql-5.7.27-linux-glibc2.12-x86_64 mysql创立mysql-files 目录cd mysql mkdir mysql-files扭转mysql-files 目录拥有者和权限chown mysql:mysql mysql-fileschmod 750 mysql-files初始化数据库，此操作指定mysql用户操作chown -R mysql:mysql /home/software/mysql-5.7.27-linux-glibc2.12-x86_64 mysqlbin/mysqld --initialize --user=mysqlbin/mysql_ssl_rsa_setup启动数据库应用第8步，控制台打印的长期明码即可登录操作。

在过程中发现两种办法解决问题：一种是非托管C++创立的dll库，须要用静态方法调用。这种办法无奈在C#的reference中间接援用，而是要用动态调用的办法， 其余博客曾经介绍的很详尽，惟一须要补充的是，C#文件须要先： `using System.Runtime.InteropServices;`之后才能够调用[DllImport]办法。另一种办法是间接应用CLR，生成托管C++dll库。创立流程例程如下C++ dll： // CPPlibdemo.h#pragma onceusing namespace System;namespace CPPlibdemo { public ref class Class1 { // TODO: Add your methods for this class here. public: String ^getgreating(){ return "hello world"; } };}C#语言： using System;using System.Collections.Generic;using System.Linq;using System.Text;using System.Threading.Tasks;using CPPlibdemo;namespace ConsoleApplication5{ class Program { static void Main(string[] args) { Class1 clrdemo = new Class1(); Console.Write(clrdemo.getgreating()); Console.ReadLine(); } }}

CodeGeeX 让每个程序员都进入 AI 辅助编程时代。CodeGeeX 的 VS Code 插件公布后，取得了许多用户好评。有很多应用 IntelliJ IDEA 等 IDE 的开发者私信咱们，心愿能推出适配更多 IDE 的插件。明天，咱们给大家带来了反对 IntelliJ IDEA、PyCharm、GoLand、CLion 等 Jetbrain IDEs 的 CodeGeeX 插件版本。 目前插件曾经在 Jetbrain IDEs 的插件市场正式上线。应用前请确保您的 IDE 版本为 2021.1 或更高版本，装置扩大并全局启用。CodeGeeX for Jetbrains IDEs 有两种应用模式：主动模式和交互模式，以下将为您具体介绍： 主动模式 在该模式中，如您不想持续反复代码的编写，能够借用插件敲下 tab 键，它会帮您主动生成代码。CodeGeeX 将在您进行输出时，从光标处开始生成（右下角 CodeGeeX 图标转圈示意正在生成）。生成结束之后会以灰色显示，如果您对后果称心，按 “Tab” 即可插入生成后果。 交互模式 在该模式中，您能够通过敲入一行正文，使插件主动生成一段残缺的代码解决方案。通过 “Ctrl + \” 快捷键激活交互模式，CodeGeeX 将生成多个候选，并显示在右侧窗口中。点击候选代码上方的 “use code” 即可插入后果到为以后光标地位。 装置形式 以 IntelliJ IDEA 为例，介绍 CodeGeeX 插件的装置办法： 在 IntelliJ IDEA 菜单中，点击 Preference 选项；在左侧点击 Plugins, 并在上方选 Marketplace；在搜寻框中输出 codegeex，在搜寻后果当选 Install。One More Thing1.在公众号 <CodeGeeX> 聊天框输出 “Jetbrains ” 即可获取 CodeGeeX for Jetbrains IDEs 装置地址。2.CodeGeeX 团队同样开发了 VS Code 平台的插件，反对四种模式：主动模式、交互模式、翻译模式和提醒模式。具体介绍可参考 CodeGeeX 插件应用教程。 ...

1、问题形容HKEY_LOCAL_MACHINE\Software\Wow6432Node\XXXX中“Wow6432Node”在32位Windows上则不存在，怎么对立解决？2、问题剖析Either KEY_WOW64_32KEY or KEY_WOW64_64KEY can be specified. If both flags are specified, the function fails with ERROR_INVALID_PARAMETER. Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP: If both flags are specified, the function’s behavior is undefined. 批示 64 位注册表上的Windows应在 32 位注册表视图上运行。 此标记被 32 位或 32 位Windows。 无关详细信息，请参阅 拜访备用注册表视图。KEY WOW64 64KEY (0x0100)批示 64 位注册表上的Windows应在 64 位注册表视图上运行。 此标记被 32 位或 32 位Windows。 无关详细信息，请参阅 拜访备用注册表视图。此标记必须与此表中查问或拜访注册表值的其余标记联合应用 OR 运算符。Windows 2000： 不反对此标记。此标记必须与此表中查问或拜访注册表值的其余标记联合应用 OR 运算符。Windows 2000： 不反对此标记。 ...

一、符号应用举例//在select标签中应用，#用于示意占位符，把他独自作为某个值；而$用于示意字符串拼接<select id="selectUserByUserNameOrEmail" resultMap="BaseResultMap"> select * from #{tableName}</select>二、举例应用并辨别1.select from #{tableName} 和 select from ${tableName}①对于#号来说，因为它示意占位符，他是作为值存在的，因而它理论传输的语句select from ？，而这种语句是须要预编译的。假如我当初传递参数为字符串'user'，语句就变成select from 'user'，这样的语句是无奈执行的。②而对于$号来说，select * from ${tableName}，他是以字符串拼接的模式，因而他是可能执行的③那这样来说，是不是意味着$更好呢？其实并不是，咱们来看上面的语句2.select from auth_user where username = #{userName} 和 select from auth_user where username = %{userName}①从下面的例子咱们能够晓得$是对字符串进行拼接再执行SQL语句的，假如咱们执行下面的语句就会产生一个问题，我怎么晓得输出的userName是不是失常的呢，假如他是好人呢？如输出"username' or '1'= `1"语句就会变成 select * from auth_user where username = "username' or '1'= `1"也就是咱们常说的SQL注入，这样会导致咱们所有的用户信息都会裸露进去！！！ 三、日常应用1.仔细的同学可能发现了，第一个SQL语句须要的参数是咱们程序员已知的，而第二个SQL语句须要的参数是用户输出的。因而，咱们能够得出一个论断，个别#用于用户输出值的中央、$用于程序员本人赋值的中央 四、区别1.#号示意占位符；$示意拼接字符串2.#号应用的是PreparedStatement，他会进行预编译，能避免SQL注入；而$应用的是Statement 五、为什么预编译能避免SQL注入？1.解释：在应用占位符，或者说参数的时候，数据库曾经将sql指令编译过，那么查问的格局曾经订好了，也就是咱们说的我曾经明确你要做什么了，你要是将不非法的参数传进去，会有合法性检查，用户只须要提供参数给我，参数不会当成指令局部来执行，也就是预编译曾经把指令以及参数局部辨别开，参数局部不容许传指令进来2.了解：预编译的时候是先把这句话编译了，生成sql模板，相当于生成了一个我提前晓得你要查名字了，你把名字传给我，你当初想骗我，把字符串"username' or '1'= `1" 传进去，那么数据库去名字这一字段帮你找，发现没有这个人，天然也就无奈生成编译语句了

一、什么是Explain？1.应用explain能够模仿优化器执行SQL查问语句，从而晓得MySQL怎么解决你的SQL语句的，剖析你的查问语句和表构造的性能瓶颈。 二、Explain能做什么？读取表的程序哪些索引可能被应用数据读取操作的操作类型哪些索引可能被理论应用表之间的援用每张表有多少行被物理查问三、Explain应用的表1.blog_blog、blog_blogtype、user三个表，其中blog表应用外键一对一关联另外两个表，具体如下 四、Explain应用举例1.执行语句1（查问博客类型为随笔且作者名称为老胡的博客） EXPLAIN SELECT * FROM blog_blog blog WHERE blog.blog_type_id IN (SELECT id FROM blog_blogtype blogtype WHERE type_name = '随笔')AND blog.author_id = (SELECT id FROM USER WHERE user_name = '老胡')2.执行后果(局部截图） 3.id、table字段：通过这两个字段咱们能够判断出你的每一条SQL语句的执行程序和表的查问程序。在截图中，id优先级更高，因而第一个查问的是user表；当id雷同时，怎么看程序呢？自上而下，如这里的id都是1，则自上而下查问的第二个查问的表是blog，第三个表是blogtype 4.type字段（画重点）：上面的代码从左到右，越凑近右边越优良 NULL > system > const > eq_ref > ref > ref_or_null > index_merge > range > index > ALL①NULL：MySQL可能在优化阶段合成查问语句，在执行阶段用不着再拜访表或索引，比方咱们晓得MySQL底层是B+树，叶子节点的第一个就是最大的id值，那么咱们很容易查问到最大的id（当id为主键时会默认创立主键索引），所以不必拜访表或索引 //因为存在主键索引，则type为NULLEXPLAIN SELECT MAX(id) FROM blog_blog //因为该字段不存在索引，则type为AllEXPLAIN SELECT MAX(title) FROM blog_blog因而咱们得出结论：NULL的前提是曾经建设了索引 ②SYSTEM ：只有一行记录（等于零碎表），这是const类型的特列，平时不大会呈现，能够疏忽。 ③const ：示意通过索引一次就找到了，const用于比拟primary key或uique索引，因为只匹配一行数据，所以很快，如主键置于where列表中，MySQL就能将该查问转换为一个常量。 ...

举荐算法是会常常遇到的技术。次要解决的是问题是：如果你喜爱书 A，那么你可能会喜爱书 B。 本文咱们应用 MySQL ，基于数据统计，拆解实现了一个简略的举荐算法。 首先，创立一个 用户喜爱的书数据表，所示意的是 user\_id 喜爱 book\_id。 CREATE TABLE user_likes ( user_id INT NOT NULL, book_id VARCHAR(10) NOT NULL, PRIMARY KEY (user_id,book_id), UNIQUE KEY book_id (book_id, user_id));CREATE TABLE user_likes_similar ( user_id INT NOT NULL, liked_user_id INT NOT NULL, rank INT NOT NULL, KEY book_id (user_id, liked_user_id));插入4条测试数据 INSERT INTO user_likes VALUES (1, 'A'), (1, 'B'), (1, 'C');INSERT INTO user_likes VALUES (2, 'A'), (2, 'B'), (2, 'C'), (2,'D');INSERT INTO user_likes VALUES (3, 'X'), (3, 'Y'), (3, 'C'), (3,'Z');INSERT INTO user_likes VALUES (4, 'W'), (4, 'Q'), (4, 'C'), (4,'Z');代表的含意为：用户 1 喜爱A、B、C，用户 2 喜爱 A、B、C、D，用户 3 喜爱 X、Y、C、Z，用户 4 喜爱 W、Q、C、Z。 ...

一、前情提要1.因为本文章中很多时候会波及到工夫复杂度和数据结构，倡议对这方面常识不理解的同学先去学习下数据结构。 二、为什么不应用数组？（增、删、改、查）？1.在减少元素时，咱们须要对插入地位前面所有的元素向后挪动一位，要插入的地位越靠前，须要复制的数据也就越多，这就是为什么不应用数组的起因。2.至于删、改、查操作，在不思考空洞的状况下（间接设置为Null），删除是比拟快的；对于批改和查问操作来说，在晓得下标的状况下，数组的批改和查问的工夫复杂度都是O(1),在不晓得下标的状况下，一般数组的工夫复杂度为O（n），有序数组中二分查找时间复杂度为O（logn）。 三、为什么不应用链表（增、删、改、查）？1.在减少元素时，咱们以双链表来举例，假如采纳尾插的话，工夫复杂度只有O（1），还是比拟不便的。2.至于删、改、查操作，他们都须要找到须要“操作”的节点元素，如删除元素时咱们须要让删除节点的前一个节点指向删除节点的后一个节点、批改元素时咱们须要查找到批改的元素，这三种操作的工夫复杂度都是O（n），这就是为什么不应用链表的起因。 四、为什么不应用哈希表（增、删、改、查）？1.在减少元素时，咱们并不需要像数组那样对元素向后挪动，而是放入链表中，也就是咱们通常所说的解决哈希抵触的链地址法，不思考哈希抵触的状况下，哈希表工夫复杂度为（1）2.至于删、改、查操作，在不思考哈希抵触的状况下，和数组相似，在晓得下标的状况下，他们的工夫复杂度为O（1）3.那么为什么不实用哈希表呢？因为在应用MySQL的过程中，常常会应用范畴查问，因为哈希表的所有 key 都会通过哈希函数计算，而后再存放数据，原本可能有序的 key，但通过哈希函数计算出来的值就不是有序的了，所以这个时候，如果要在哈希表中进行范畴查找，就只能对整个哈希表进行遍历了，只有符合条件范畴的数据，才取出来。当咱们数据库中的数据越来越多，达到几百万甚至几千万条的时候，这个时候，对整个表的遍历是十分耗时的。 五、为什么不应用AVL树、红黑树?1.每个节点最多有两个子节点的树叫二叉树，常见的有二叉搜寻树、AVL树、红黑树等。但他们都有雷同的问题，当有大量数据的时候，他的树的高度会十分高2.MySQL存储的数据最终是要落地到磁盘的，MySQL 应用程序读取数据时，须要将数据从磁盘先加载到内存后能力持续操作，所以这两头会产生磁盘 IO，而如果树太高，每遍历一层结点时，就须要从磁盘读取一次数据，也就是产生一次 IO，如果数据在树高为 20 的中央，那查找一次数据就得产生20次IO，这对应用程序几乎就是灾难性的，耗时太长了。 六、为什么应用B树而不是用B+树？1.B树的特点是无论叶子结点和非叶子结点，它都存有索引值和数据；B+树的特点是只有叶子结点才会寄存索引值和数据。对于非叶子节点来说，B+树能存储更多的索引值（因为B+树并不需要存储数据）2.B+树的叶子节点之间应用链表的模式进行连贯，所以当进行范畴查问的时候，很容易就能够通过链表指针查问到想要的数据了

https://blog.csdn.net/weixin_...

前言MySQL是Java程序员面向高级的必备技能，很多敌人在面试时常常在这里折戟沉沙，饮恨不已。熟练掌握MySQL常识，在实践中具备很强的操作性，尤其是在互联网行业，不仅要写好代码、实现性能，而且还要在高并发的状况下可能失常运行。 所以小编明天给大家分享这份《MySQL笔记》文档，这份文档将从根底篇、性能优化篇、架构设计篇、这三个局部给大家解说，同时心愿对各位大哥敌人们有点作用，也心愿你们会喜爱！最初，有须要这份纯手打的《MySQL笔记》文档的敌人们【间接点击此处】即可获取~ MySQL目录：废话少说，先让大家看看这份文档的目录，由目录即可看出内容很全 次要内容这篇《MySQL笔记》，次要分为三个局部：根底篇、性能优化篇、架构设计篇；所以接下来，小编就每篇认真的开展来具体的为大家解说一下这本书的知识点！ 一、根底篇作为最为风行的开源数据库软件之一，MySQL 数据库软件曾经是广为人知了。然而为了关照对 MySQL 还不相熟的读者，这章咱们将对 MySQL 做一个简略的介绍。次要内容包含MySQL 各功能模块组成，各模块协同工作原理，Query 解决的流程等。 第1章：MySQL根本介绍 作为最为风行的开源数据库软件之一，MySQL 数据库软件曾经是广为人知了。然而为了关照对 MySQL 还不相熟的读者，这章咱们将对 MySQL 做一个简略的介绍。次要内容包含MySQL 各功能模块组成，各模块协同工作原理，Query 解决的流程等 MysQLServer简介MySQL与其余数据库的简略比拟MySQ的次要实用场景小结 第2章：MySQL架构组成 麻雀虽小，五脏俱全。MySQL 尽管以简略著称，但其内部结构并不简略。本章从 MySQL物理组成、逻辑组成，以及相干工具几个角度来介绍 MySQL 的整体架构组成，心愿可能让读者对 MySQL 有一个更全面深刻的理解。 MySQL物理文件组成MySQLServer零碎架构MySQL自带工具应用介绍小结 第3章：MySQL存储引擎简介 MySQL存储引擎概述MyISAM存储引擎简介Innodb存储引擎简介NDECluster存储引擎简介其余存储引擎介绍小结 第4章：MySQL平安治理 对于任何一个企业来说，其数据库系统中所保留数据的安全性无疑是十分重要的，尤其是公司的有些商业数据，可能数据就是公司的基本，失去了数据的安全性，可能就是失去了公司的所有。本章将针对 MySQL 的平安相干内容进行较为具体的介绍。 数据库系统平安相干因素MySQL权限零碎介绍MySQL拜访受权策略平安设置注意事项小结 第5章：MySQL备份与复原 数据库的备份与复原始终都是 DBA 工作中最为重要的局部之一，也是根本工作之一。任何正式环境的数据库都必须有残缺的备份打算和复原测试，本章内容将次要介绍 MySQL数据库的备份与复原相干内容。 数据库备份应用场景逻辑备份与复原测试物理备份与复原则式备份策略的设计思路小结 二、性能优化篇第6章：影响MySQLServer性能的相干因素 大部分人都统一认为一个数据库利用零碎（这里的数据库利用零碎概指所有应用数据库的零碎）的性能瓶颈最容易呈现在数据的操作方面，而数据库利用零碎的大部分数据操作都是通过数据库管理软件所提供的相干接口来实现的。所以数据库管理软件也就很天然的成为了数据库利用零碎的性能瓶颈所在，这是以后业界比拟广泛的一个认识。但咱们的利用零碎的性能瓶颈真的齐全是因为数据库管理软件和数据库主机本身造成的吗？咱们将通过本章的内容来进行一个较为深刻的剖析，让大家理解到一个数据库利用零碎的性能到底与哪些地方无关，让大家寻找出各自利用零碎的呈现性能问题的根本原因，而尽可能分明的晓得该如何去优化本人的利用零碎。 第7章：MySQL数据库锁定机制 为了保证数据的统一完整性，任何一个数据库都存在锁定机制。锁定机制的优劣间接应想到一个数据库系统的并发解决能力和性能，所以锁定机制的实现也就成为了各种数据库的核心技术之一。本章将对 MySQL 中两种应用最为频繁的存储引擎 MyISAM 和 Innodb 各自的锁定机制进行较为具体的剖析。 第8章：MySQL数据库Query的优化 在之前“影响 MySQL 利用零碎性能的相干因素”一章中咱们就曾经剖析过了 Query 语句对数据库性能的影响十分大，所以本章将专门针对 MySQL 的 Query 语句的优化进行相应的剖析。 第9章：MySQL数据库Schema设计的性能优化 ...

作者：杨奇龙 网名“北在北方”，资深 DBA，次要负责数据库架构设计和运维平台开发工作，善于数据库性能调优、故障诊断。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 一 背景死锁，其实是一个很有意思也很有挑战的技术问题，大略每个DBA和局部开发同学都会在工作过程中遇见 。 本次分享的死锁案例是 更新不存在的记录加上 X GAP lock 和 insert 的意向锁抵触。心愿可能对想理解死锁的敌人有所帮忙。 二 案例剖析2.1 业务逻辑业务逻辑: 业务须要并发不同数据(insert+update)，首先是更新记录，如果发现更新的 affect rows 为0，而后就执行插入，如果插入失败，再执行更新。因而存在并发的状况下，两个事务都执行了更新，affect rows 为0，而后有进行并发插入雷同记录的状况。 2.2 环境阐明数据库版本 8.0.30 事务隔离级别 REPEATABLE-READ create table dl(id int auto_increment primary key,c1 int not null ,c2 int not null,c3 int not null,unique key uc1(c1),unique key uc2(c2));insert into dl(c1,c2,c3) values(2,0 ,2),(5,5,5);2.3 测试用例 2.4 死锁日志------------------------LATEST DETECTED DEADLOCK------------------------*** (1) TRANSACTION:TRANSACTION 1422661, ACTIVE 51 sec insertingmysql tables in use 1, locked 1LOCK WAIT 4 lock struct(s), heap size 1128, 3 row lock(s), undo log entries 1MySQL thread id 3149, OS thread handle 140261085611776, query id 3267 localhost msandbox updateinsert into dl(c1,c2,c3) values(3,2,2)*** (1) HOLDS THE LOCK(S):RECORD LOCKS space id 50 page no 5 n bits 72 index uc1 of table `test`.`dl` trx id 1422661 lock_mode X locks rec but not gapRecord lock, heap no 4 PHYSICAL RECORD: n_fields 2; compact format; info bits 0*** (1) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 50 page no 6 n bits 72 index uc2 of table `test`.`dl` trx id 1422661 lock_mode X locks gap before rec insert intention waitingRecord lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 0*** (2) TRANSACTION:TRANSACTION 1422664, ACTIVE 45 sec insertingmysql tables in use 1, locked 1LOCK WAIT 3 lock struct(s), heap size 1128, 2 row lock(s), undo log entries 1MySQL thread id 3152, OS thread handle 140261086668544, query id 3268 localhost msandbox updateinsert into dl(c1,c2,c3) values(3,2,2)*** (2) HOLDS THE LOCK(S):RECORD LOCKS space id 50 page no 6 n bits 72 index uc2 of table `test`.`dl` trx id 1422664 lock_mode X locks gap before recRecord lock, heap no 3 PHYSICAL RECORD: n_fields 2; compact format; info bits 0*** (2) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 50 page no 5 n bits 72 index uc1 of table `test`.`dl` trx id 1422664 lock mode S waitingRecord lock, heap no 4 PHYSICAL RECORD: n_fields 2; compact format; info bits 0*** WE ROLL BACK TRANSACTION (2)2.5 死锁剖析sess1 在 T3 时刻执行了更新，affect rows 为0，在c2的(2，5) 区间中加了X,GAP锁。 ...

事件是这样的上面是我敌人的面试记录： 面试官：讲一下你实习做了什么。敌人：我在实习期间做了一个存储用户操作记录的性能，次要是从MQ获取上游服务发送过去的用户操作信息，而后把这些信息存到MySQL外面，提供给数仓的共事应用。敌人：因为数据量比拟大，每天大略有四五千多万条，所以我还给它做了分表的操作。每天定时生成3张表，而后将数据取模别离存到这三张表里，避免表内数据过多导致查问速度升高。 这表述，如同没什么问题是吧，别急，接着看： 面试官：那你为什么要分三张表呢，两张表不行吗？四张表不行吗？敌人：因为MySQL每张表最好不超过2000万条数据，否则会导致查问速度升高，影响性能。咱们每天的数据大略是在五千万条左右，所以分成三张表比拟稳当。面试官：还有吗？敌人： 没有了…… 你干嘛，哎呦面试官：那你先回去等告诉吧。 讲完了，看出什么了吗，你们感觉我这位敌人答复的有什么问题吗？前言很多人说，MySQL每张表最好不要超过2000万条数据，否则就会导致性能降落。阿里的Java开发手册上也提出：单表行数超过 500 万行或者单表容量超过 2GB，才举荐进行分库分表。但实际上，这个2000万或者500万都只是一个大略的数字，并不适用于所有场景，如果自觉的认为表数据只有不超过2000万条就没问题了，很可能会导致系统的性能大幅降落。理论状况下，每张表因为本身的字段不同、字段所占用的空间不同等起因，它们在最佳性能下能够寄存的数据量也就不同。那么，该如何计算出每张表适宜的数据量呢？别急，缓缓往下看。本文适宜的读者浏览本文你须要有肯定的MySQL根底，最好对InnoDB和B+树都有肯定的理解，可能须要有一年以上的MySQL学习教训（大略一年？），晓得 “InnoDB中B+树的高度个别放弃在三层以内会比拟好” 这条理论知识。本文次要是针对 “InnoDB中高度为3的B+树最多能够存多少数据” 这一话题进行解说的。且本文对数据的计算比拟严格（至多比网上95%以上的相干博文都要严格），如果你比拟在意这些细节并且目前不太分明的话，请持续往下浏览。浏览本文你大略须要破费10-20分钟的工夫，如果你在浏览的过程中对数据进行验算的话，可能要花费30分钟左右。 本文思维导图 基础知识疾速回顾家喻户晓，MySQL中InnoDB的存储构造是B+树，B+树大家都相熟吧？个性大略有以下几点，一起疾速回顾一下吧！注：上面这这些内容都是精髓，看不懂或者不了解的同学倡议先珍藏本文，之后有常识根底了再回来看。 一张数据表个别对应一颗或多颗树的存储，树的数量与建索引的数量无关，每个索引都会有一颗独自的树。 聚簇索引和非聚簇索引：主键索引也是聚簇索引，非主键索引都是非聚簇索引。除格局信息外，两种索引的非叶子节点都是只存索引数据的，比方索引为id，那非叶子节点就是存的id数据。叶子节点的区别如下： 聚簇索引的叶子节点个别状况下存的是这条数据的所有字段信息。所以咱们 select * from table where id = 1 的时候，都是要去叶子节点拿数据的。非聚簇索引的叶子节点存的是这条数据所对应的主键和索引列信息。比方这条非聚簇索引是username，而后表的主键是id，那该非聚簇索引的叶子节点存的就是 username 和 id，而不存其余字段。相当于是先从非聚簇索引查到主键的值，再依据主键索引去查数据内容，个别状况下要查两次（除非索引笼罩），这也称之为 回表 ，就有点相似于存了个指针，指向了数据寄存的实在地址。 B+树的查问是从上往下一层层查问的，个别状况下咱们认为B+树的高度放弃在3层以内是比拟好的，也就是上两层是索引，最初一层存数据，这样查表的时候只须要进行3次磁盘IO就能够了(实际上会少一次，因为根节点会常驻内存)，且可能寄存的数据量也比拟可观。如果数据量过大，导致B+数变成4层了，则每次查问就须要进行4次磁盘IO了，从而使性能降落。所以咱们才会去计算InnoDB的3层B+树最多能够存多少条数据。 MySQL每个节点大小默认为16KB，也就是每个节点最多存16KB的数据，能够批改，最大64KB，最小4KB。扩大：那如果某一行的数据特地大，超过了节点的大小怎么办？ MySQL5.7文档的解释是： 对于 4KB、8KB、16KB 和 32KB设置 ，最大行长度略小于数据库页面的一半 。例如：对于默认的 16KB页大小，最大行长度略小于 8KB ，默认32KB的页大小，则最大行长度略小于16KB。 而对于 64KB 页面，最大行则长度略小于 16KB。 如果行超过最大行长度， 则将可变长度列用内部页存储，直到该行合乎最大行长度限度。就是说把varchar、text这种长度可变的存到内部页中，来减小这一行的数据长度。 文档地址：MySQL :: MySQL 5.7 Reference Manual :: 14.12.2 File Space Management MySQL查问速度次要取决于磁盘的读写速度，因为MySQL查问的时候每次只读取一个节点到内存中，通过这个节点的数据找到下一个要读取的节点地位，再读取下一个节点的数据，直到查问到须要的数据或者发现数据不存在。必定有人要问了，每个节点内的数据难道不必查问吗？这里的耗时怎么不计算？这是因为读取残缺个节点的数据后，会存到内存当中，在内存中查问节点数据的耗时其实是很短的，再配合MySQL的查问形式，工夫复杂度差不多为 O(log2N)O(log_2N)O(log2N) ，相比磁盘IO来说，能够忽略不计。 MySQL InnoDB 节点的贮存内容在Innodb的B+树中，咱们常说的节点被称之为 页(page)，每个页当中存储了用户数据，所有的页合在一起组成了一颗B+树（当然理论会简单很多，但咱们只是要计算能够存多少条数据，所以权且能够这么了解）。页 是InnoDB存储引擎治理数据库的最小磁盘单位，咱们常说每个节点16KB，其实就是指每页的大小为16KB。这16KB的空间，外面须要存储 页格局 信息和 行格局 信息，其中行格局信息当中又蕴含一些元数据和用户数据。所以咱们在计算的时候，要把这些数据的都计算在内。页格局每一页的根本格局，也就是每一页都会蕴含的一些信息，总结表格如下： ...

前言PostgreSQL 在数据库层面不能像 MySQL 一样设置主动创立 create_time/update_time，自动更新 update_time下文中 create_at 等价于 create_time须要本人创立触发器实现相似成果本文测试环境# 服务端Ubuntu LTS 20.04 PostgreSQL 15.1# 客户端Windows 10pgAdmin4 6.16PostgreSQL 的数据类型：https://www.postgresql.org/do...PostgreSQL 的触发器：https://www.postgresql.org/do...实现步骤创立表CREATE TABLE document ( id int NOT NULL, title varchar(1000) NOT NULL, keyword varchar(200)[] NOT NULL, create_at timestamptz NOT NULL DEFAULT CURRENT_TIMESTAMP, update_at timestamptz NOT NULL DEFAULT CURRENT_TIMESTAMP, update_at_change timestamptz NOT NULL DEFAULT CURRENT_TIMESTAMP, CONSTRAINT document_pkey PRIMARY KEY (id));创立函数/* 两种状况视本人的需要抉择 *//* 主键雷同就更新 update_at*/CREATE OR REPLACE FUNCTION update_at_func() RETURNS TRIGGER AS $update_at_func$ BEGIN NEW.update_at := current_timestamp; RETURN NEW; END;$update_at_func$ LANGUAGE plpgsql;/*字段内容有实在扭转时更新 update_at_change */CREATE OR REPLACE FUNCTION update_at_change_func() RETURNS TRIGGER AS $update_at_change_func$ BEGIN IF ROW(NEW.*) IS DISTINCT FROM ROW(OLD.*) THEN NEW.update_at_change := current_timestamp; RETURN NEW; ELSE RETURN OLD; END IF; END;$update_at_change_func$ LANGUAGE plpgsql;前面一种形式参考的这篇问答：https://stackoverflow.com/que...创立触发器CREATE OR REPLACE TRIGGER update_at_document BEFORE UPDATE ON document FOR EACH ROW EXECUTE FUNCTION update_at_func(); CREATE OR REPLACE TRIGGER update_at_change_document BEFORE UPDATE ON document FOR EACH ROW EXECUTE FUNCTION update_at_change_func();数据测试upsert 插入数据INSERT INTO "document" (id, title, keyword) VALUES (1, 'hello', ARRAY['w', 'o', 'r', 'l', 'd']) ON CONFLICT ("id") DO UPDATE SET title = EXCLUDED.title, keyword = EXCLUDED.keyword;再执行一遍是下面 sql 语句，应该能够看到 update_at 产生了变动，update_at_change 没有产生了变动。执行以下 sql 批改字段内容，应该能够看到 update_at 和 update_at_change 都产生了变动。INSERT INTO "document" (id, title, keyword) VALUES (1, 'hello', ARRAY['w', 'o', 'r', 'l', 'd']) ON CONFLICT ("id") DO UPDATE SET title = EXCLUDED.title, keyword = EXCLUDED.keyword;本文出自 qbit snap

作者：毛辰飞 背景在mysql中设计表的时候，mysql官网举荐不要应用uuid或者不间断不反复的雪花id(long形且惟一)，而是举荐间断自增的主键id，官网的举荐是auto_increment，那么为什么不倡议采纳uuid，应用uuid到底有什么害处？明天咱们就来剖析这个问题，探讨一下外部的起因。 数据展现user\_auto\_key，user\_uuid，user\_random_key，别离示意主动增长的主键，uuid作为主键，随机key作为主键，其它咱们齐全放弃不变。依据控制变量法，咱们只把每个表的主键应用不同的策略生成，而其余的字段齐全一样，而后测试一下表的插入速度和查问速度： 注：这里的随机key其实是指用雪花算法算进去的前后不间断不反复无规律的id:一串18位长度的long值 能够看出在数据量100W左右的时候,uuid的插入效率垫底，并且在后续减少了130W的数据，uuid的工夫又直线降落。 工夫占用量总体能够打出的效率排名为：auto\_key>random\_key>uuid，uuid的效率最低，在数据量较大的状况下，效率直线下滑。 起因剖析比照一下mysql对于两者索引的应用状况. 自增的主键的值是程序的,所以Innodb把每一条记录都存储在一条记录的前面。当达到页面的最大填充因子时候(innodb默认的最大填充因子是页大小的15/16,会留出1/16的空间留作当前的批改)： ①下一条记录就会写入新的页中，一旦数据依照这种程序的形式加载，主键页就会近乎于程序的记录填满，晋升了页面的最大填充率，不会有页的节约 ②新插入的行肯定会在原有的最大数据行下一行,mysql定位和寻址很快，不会为计算新行的地位而做出额定的耗费 ③缩小了页决裂和碎片的产生 因为uuid绝对程序的自增id来说是毫无法则可言的,新行的值不肯定要比之前的主键的值要大,所以innodb无奈做到总是把新行插入到索引的最初,而是须要为新行寻找新的适合的地位从而来调配新的空间。这个过程须要做很多额定的操作，数据的毫无程序会导致数据分布散乱，将会导致以下的问题： ①：写入的指标页很可能曾经刷新到磁盘上并且从缓存上移除，或者还没有被加载到缓存中，innodb在插入之前不得不先找到并从磁盘读取指标页到内存中，这将导致大量的随机IO ②：因为写入是乱序的,innodb不得不频繁的做页决裂操作,以便为新的行调配空间,页决裂导致挪动大量的数据，一次插入起码须要批改三个页以上 ③：因为频繁的页决裂，页会变得稠密并被不规则的填充，最终会导致数据会有碎片 在把随机值（uuid和雪花id）载入到聚簇索引(innodb默认的索引类型)当前,有时候会须要做一次OPTIMEIZE TABLE来重建表并优化页的填充，这将又须要肯定的工夫耗费。 自增ID的毛病： 那么应用自增的id就齐全没有害处了吗？并不是，自增id也会存在以下几点问题： ①. 他人一旦爬取你的数据库,就能够依据数据库的自增id获取到你的业务增长信息，很容易剖析出你的经营状况 ②. 对于高并发的负载，innodb在按主键进行插入的时候会造成显著的锁争用，主键的上界会成为争抢的热点，因为所有的插入都产生在这里，并发插入会导致间隙锁竞争 ③. Auto_Increment锁机制会造成自增锁的争夺,有肯定的性能损失

数据表设计的时候应用一个字段来存储多对多关系，比方表 user 中有一个字段叫 category, category存储的是 "1,3,9" 这样的类型的数据，实际上是 category 的 id 用逗号分隔开来的。 向 user 表录入 100万的数据，同时建设 user_category 表，每个user有 3 个分类，那么category表里有300万条记录。 CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(50) DEFAULT NULL, `category` varchar(50) DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1;CREATE TABLE `user_category` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_id` int(11) DEFAULT NULL, `category_id` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `category_id` (`category_id`), KEY `user_id` (`user_id`) ) ENGINE=InnoDB AUTO_INCREMENT=1;当初比拟一下在百万级的数据量上应用 join 链接外键查问和find_in_set查问的性能 ...

作者： 刘腾飞 汇量后端开发工程师 阿里云开源OLAP研发团队 EMR-StarRocks介绍阿里云EMR在年初推出了StarRocks服务，StarRocks是新一代极速全场景MPP（Massively Parallel Processing）数据仓库，致力于构建极速和对立剖析体验。EMR StarRocks具备如下特点: 兼容MySQL协定，可应用MySQL客户端和罕用BI工具对接StarRocks来剖析数据采纳分布式架构： 对数据表进行程度划分并以多正本存储集群规模能够灵便伸缩，反对10 PB级别的数据分析反对MPP框架，并行减速计算反对多正本，具备弹性容错能力反对向量化引擎和CBO反对弹性扩缩容反对明细模型、聚合模型、主键模型和更新模型更多详细信息能够参考https://help.aliyun.com/docum... Flink-CDC概念介绍 CDC的全称是Change Data Capture，面向的场景包含数据同步、数据散发、数据采集，Flink CDC 次要面向数据库的变更，能够将上游数据和Schema的变更同步到上游数据湖和数据仓库中。2020年7月，Flink CDC我的项目提交了第一个Commit，去年8月，Flink社区公布了CDC2.0，通过两年工夫的打磨，在商业化应用上曾经十分成熟。本文次要以Mysql CDC为例，介绍StarRocks+Flink CDC实时入仓中用户遇到的痛点，以及在Flink和StarRocks层面进行的对应优化和解决方案。 应用CDC将一张Mysql表中的数据导入到StarRocks的表中，首先须要在StarRocks上建设用来承接Mysql数据的指标表，而后在Flink上别离创立Mysql表和StarRocks表在Flink中Sink和Source表的映射，而后执行一条insert into sink_table from source_table语句。执行完Insert into之后，会生成一个CDC工作，CDC工作首先向指标表同步源表的全量数据，实现后持续基于Binlog进行增量数据的同步。通过一个工作，实现数据的全量+增量同步，对于用户来讲是十分敌对的。然而在应用的过程中，仍然发现了一些痛点。 实时写入场景的用户痛点SQL开发工作量大对于一些还没有实现数仓建设的新业务，或是刚刚开始依靠StarRocks进行OLAP平台建设的用户而言，在StarRocks中建表以承载Mysql同步过去的数据是第一步。在一些简单的业务中，Mysql中的表往往有几十上百张，每张表又有数十个字段，要把它们对应的StarRocks表的建表语句全副编写进去是一个很大的工作量。第一个痛点StarRocks建表的工作量大。 Flink字段的数据类型映射关系简单易错在StarRocks中建表是第一步，建表实现之后，为了启动CDC工作，还须要在Flink中建设Mysql对应的Source表，以及StarRocks对应的Sink表，其中Flink建表时，每个字段的字段类型与Mysql、与StarRocks的映射关系须要严格留神，对于动辄几十上百个须要字段的表，每个字段都须要查找对应在Flink的类型映射关系，尤其令开发人员苦楚。因而，第二个痛点是上下游表与Flink字段的数据类型映射关系简单，容易出错。 Schema变更操作繁琐第三个痛点来自于业务数据Schema的变动，据Fivetran公司考察，约有60%的公司数据Schema每个月都会发生变化，30%的公司数据Schema每周都会发生变化。对于Mysql表中字段的增删改，用户心愿在不影响CDC工作的状况下，将Schema变动同步到上游的StarRocks。目前罕用的计划，是在手动进行工作后，更改StarRocks和Mysql的Schema，更改Flink侧的Sink和Source表构造，通过指定savepoints的形式再次启动工作。Schema变更的操作繁琐，无奈自动化是第三个痛点。 数据同步工作占用资源多第四个痛点，是在表的数量多、实时增量数据量大的场景下，CDC工作占用的内存和cpu资源较高，出于节省成本的思考，用户心愿尽可能的在资源利用方面进行优化。 接下来，咱们来看针对这些痛点，EMR-StarRocks在与Flink深度联合方面做了哪些优化，提供了什么样的解决方案。 CTAS&CDASEMR-StarRocks与Flink团队推出的CTAS&CDAS性能次要是针对前三个痛点研发的一个解决方案。通过CTAS&CDAS，能够应用一条SQL语句，实现StarRocks建表、Flink-CDC工作创立、实时同步Schema变更等本来须要多项繁冗操作的工作，令开发和运维的工作量大大降低。 CTAS介绍CTAS的全称是create table as，语法结构如下： CREATE TABLE IF NOT EXISTS runoob_tbl1 with ('starrocks.create.table.properties'=' engine = olap primary key(runoob_id) distributed by hash(runoob_id ) buckets 8','database-name'='test_cdc','jdbc-url'='jdbc:mysql://172.16.**.**:9030','load-url'='172.16.**.**:8030','table-name'='runoob_tbl_sr','username'='test','password' = '123456','sink.buffer-flush.interval-ms' = '5000') as table mysql.test_cdc.runoob_tbl /*+ OPTIONS ( 'connector' = 'mysql-cdc', 'hostname' = 'rm-2zepd6e20u3od****.mysql.rds.aliyuncs.com', 'port' = '3306', 'username' = 'test', 'password' = '123456', 'database-name' = 'test_cdc', 'table-name' = 'runoob_tbl' )*/;通过CTAS的语法结构能够看到，除了集群信息和DataBase信息外，还有一个非凡配置“starrocks.create.table.properties”，这是因为Mysql与StarRocks的表构造有一些不同，如Key Type、分区、Bucket Number等非凡配置，因而用它来承接StarRocks建表语句中字段定义前面的内容。 ...

本文整顿自韵达科技业务中台总监李波澜，在 2022 阿里巴巴开源凋谢周上的分享。本篇内容次要分为三个局部： 1. 企业背景 2. 利用实际 3. 将来瞻望。 一、背景：企业介绍 业务诉求 韵达次要面向国内外提供快递、快运、供应链、仓储服务等，目前领有 4 万多家快递服务网点，3000 多家快运服务网点，200 多家加盟商，以及 100 多家分拣核心，其中包含 4200 条快递支线，1000 多条快运支线，150 家城市配送站，业务笼罩了 100 多家重点城市，遍布寰球 30 万个国家和地区，领有 200 万平米仓储面积，从业人员 30 多万。 韵达每日订单量高达几千万，每个订单有多种标签信息，因而数据量微小。其中上游业务方有各大电商平台、订单核心、大客户、智橙网、财务核心、店配团、物流团等。 打标平台次要提供了订单标签根底服务、查问统计服务、音讯推送、 CSV 文件推送、订单标签解决等。其中数据存储是外围业务，数据量较大，而且是高并发拜访场景。数据存储波及到 Kafka、 CSV、Redis、MySQL 分库分表。 上游次要为业务赋能，有韵图、智能外联、大掌柜、数据中台、结算团、韵达超市、揽派零碎等一共 30 多个零碎。二、利用实际：架构降级 外围能力 韵达原先的业务架构存在较多痛点： 1、数据无奈充分发挥业务价值：传统的分库分表计划短少数据全局视角，对简单查问的限度较多，须要人工进行解决。2、历史数据清理繁琐：数据并不需要长期存储，对于业务场景而言个别只需存储 1 年。但因为分表较多，数据清理较麻烦，同时为了防止对在线业务产生影响，常常须要在业务低峰期比方凌晨，与 DBA 团队单干对历史数据做手动清理。3、随着业务回升导致性能衰减：数据减少当前查问能力降落。另外，计算存储资源固定，难以扩容。 因而，韵达采纳了阿里云开源 PolarDB-X 云原生分布式数据库对业务架构进行了降级，使架构性能失去了极大的晋升：1、经营老本升高：反对灵便设置历史数据的存储周期，能够升高存储老本。通明分布式使得应用、运维方面的老本也得以降落。高兼容 MySQL 语法对开发团队而言，学习老本也失去了升高。2、进步弹性扩大能力：计算存储拆散架构提供了弹性能力，可随时扩缩容，资源能够按需分配，进步了资源利用率。3、高可用能力晋升：引入了强统一协定，克服了主备脑裂问题。另外，多正本技术的加持使得数据更加安全可靠。 上图为降级后的基于分布式数据库的业务架构。与老架构的次要差异在于，将原先基于 MySQL 的人工分库分表应用 PolarDB-X 进行了替换，架构上并未有大调整。 此外，开发团队并不需要了解 CN 节点，也不须要与 CN 节点打交道，他们看到的只是一个 PolarDB-X 数据库，能够了解为一个大型的 MySQL 实例，不存在额定的学习老本。 ...

起因事件是这样的，服务商有一批数据，当初的数据量大抵为 2 千万条（单表），每天都会减少数据（减少多少暂不晓得），然而呢给咱们提供的查问不是一张数据表而是一张视图，咱们再依据这个数据对外提供一个查问服务。因为是视图查问的时候就比较慢，咱们也没有权限进行表的优化，所以就须要将数据同步到咱们本地数据库，在本地进行数据表的优化（加索引等等的），然而数据量是 2 千万多，就须要一个工具来把远端数据同步到本地，而后在 github 上发现了 Datax，就依照文档 依赖关系LinuxJDK(1.8 以上，举荐 1.8)Python(2或3都能够)jdk 装置JDK1.8 华为镜像下载地址 解压重命名解压重名为 java1.8 并挪动到 /usr/local 目录下 /usr/local/java1.8 运行环境配置vim ~/.bashrc# 写入一下内容export JAVA_HOME=/usr/local/java1.8export JRE_HOME=${JAVA_HOME}/jreexport CLASSPATH=.:${JAVA_HOME}/lib:${JRE_HOME}/libexport PATH=${JAVA_HOME}/bin:$PATH# 执行 sourcesource ~/.bashrc# 查看版本java -versionjava version "1.8.0_181"Java(TM) SE Runtime Environment (build 1.8.0_181-b13)Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)Python 装置Python 在 Ubuntu 零碎上曾经默认装置了，能够应用命令 python -V 或 python3 -V 查看以后版本。 能够应用命令 apt install python3 装置 Python3。也能够本人应用编译的形式装置。 datax 装置DataX Github 地址 Datax 下载地址 能够间接下载工具包，不须要再编译装置，能够间接应用。 ...

MySQL 是一种关联数据库管理系统，关联数据库将数据保留在不同的表中，而不是将所有数据放在一个大仓库内。这样就减少了速度并进步了灵活性。 MySQL 的 SQL “结构化查询语言”，SQL 是用于拜访数据库的最罕用标准化语言。 MySQL 软件采纳了 GPL（ GNU 通用公共许可证），因为其体积小、速度快、总体领有成本低，尤其是开放源码这一特点，许多中小型网站为了升高网站总体领有老本而抉择了 MySQL 作为网站数据库。 本期技术周刊一起理解下 MySQL ，欢送大家浏览 ～ 文章举荐《10 分钟教你写一个数据库》作者：艾小仙 明天教大家借助一款框架疾速实现一个数据库，这个框架就是 Calcite，上面会带大家通过两个例子疾速教会大家怎么实现，一个是能够通过 SQL 语句的形式能够间接查问文件内容，第二个是模仿 Mysql 查问性能，以及最初通知大家怎么实现 SQL 查问 Kafka 数据。 《学习 MySQL 必须把握的 13 个关键字，你 get 了吗？》作者：Java 架构师 三范式： 第一范式：每个表的每一列都要放弃它的原子性，也就是表的每一列是不可分割的；第二范式：在满足第一范式的根底上，每个表都要放弃唯一性，也就是表的非主键字段齐全依赖于主键字段；第三范式：在满足第一范式和第二范式的根底上，表中不能产生传递关系，要打消表中的冗余性；《Mysql 数据库的批量插入或更新（Upsert）》作者：songofhawk 这个问题曾经困扰我一段时间了，对于大量数据的插入或更新，批量操作必定比每条记录调用一次快得多，新数据能够用 insert 批量插入，老数据能够用 replace into 批量更新。但如果不晓得数据是否存在（是否有惟一 key 和数据库中已有记录反复）想在一批数据库中，插入新记录，更新老记录怎么办？ 之前甚至想过封装一个函数，先用 select ... in 批量查问，而后分两组插入和更新，但一方面通用性不佳，另一方面这不是一个原子操作，对于并发的状况，有可能查问的时候记录不存在，插入的时候就曾经存在了。 认真 google 了一下，才发现这种“存在 update，不存在 insert ”的动作，有个专有名词，叫做“upsert”，相当形象。解决方案呢，不同数据库各有本人的解决方案和方言，Mysql 叫做 on duplicate key update，PostgreSql 中叫做 on confict do update。 ...

mysql8下载： https://mirrors.tuna.tsinghua... zip包装置的，启动服务时，提醒：服务没有响应管制性能 msi装置的，提醒requires viusal studio 2019 x64 redistributable 解决方案： 装置viusal studio 2019 x64 下载地址： 链接：https://pan.baidu.com/s/1cjUu... 提取码：8rx1

墨天轮社区于9月起继续举办【聊聊故障解决那些事儿】DBA专题征文活动，每月进行评优发奖，激励大家记录工作中遇到的数据库故障处理过程，不仅用于自我复盘与剖析，同时也能帮忙其余的同仁们避坑。 上月为大家梳理了9月的优质投稿，这里为大家整顿出了10月的14篇优质投稿文章，主题涵盖Oracle、MySQL等数据库的慢SQL优化、OGG 21c应用总结以及服务器爆满、主从复制提早、报错剖析等故障剖析、处理过程，分享给大家： 作品展现应用 OGG 21c 遇到的几个问题Oracle 11g中，同一条sql，第一次执行很快，紧接着执行就比较慢？记一次MySQL的慢SQL剖析一起oracle_fdw未下推导致PostgreSQL服务器空间爆满的问题剖析额定的相等连贯条件 导致预估行数不准的问题钻研ASH报告发现：os thread startup 期待事件 剖析对于数据库服务器内存使用率高问题剖析思路问答榜上引发的Oracle并行的探索（一）RAC DG删除备库redo时报ORA-01623基于华为云装置Oracle 11G RAC 节点2执行root.sh 报错故障解决报告–MYSQL5.7 online DDL BUG记一次MySQL主从复制提早问题剖析Oracle11GR2节点1忽然宕机，剖析思路及步骤Oracle数据块钻研及坏块解决办法这些文章除了选题是大家日常可能会遇到的故障解决状况，其文章构造逻辑也非常清晰，均蕴含问题景象（具体报错等）、问题定位与剖析 、 问题解决、问题总结等几个方面。 墨天轮技术社区的【聊聊故障解决那些事儿】DBA专题征文活动仍在进行中，仍有不少对于Oracle、MySQL、PG以及国产数据库相干的故障解决实操文章投稿，欢送大家点击此处查阅全副文章。 也欢送大家踊跃投稿，将你工作中遇到的数据库故障处理过程记录下来，不仅用于自我复盘与剖析，同时也能帮忙其余的同仁们避坑。

1 背景与指标1.1 背景国内财务泰国每月月初账单工作生成，或者重算账单数据，数据同步计划为mysql通过binlake同步ES数据，在同步过程中发现计费事件表，计费后果表均有提早，ES数据与Mysql数据不统一，导致业务页面查问数据不精确，局部外围计算通过ES校验失败 1.2指标解决binlake到JMQ积压同步ES提早问题 2 以后业务流程2.1 流程图现有业务根本流程如下图，蕴含经营端和内部数据接入，整体操作到数据存储流程 2.2 数据流 3 问题剖析3.1 问题景象jmq积压，报警 国内站截图如下 3.2 筛查剖析遍及：JMQ默认生产者发送音讯QPS受到主题的broker数量影响，(8w/s)/broker 3.2.1 MQ积压剖析1）剖析起因一、ES写入量大，导致ES写入QPS瓶颈 ES写入瓶颈须要进行压测，能力确定理论是否达到瓶颈； 通过查问集群负载，写入队列有无积压，cpu高不高，来定位 以下为调整MQ批量生产大小后的ES监控 写入队列无积压，CPU不高，写入QPS没有达到瓶颈 2）剖析起因二、ES写入慢导致生产积压 ES解析服务解析慢，瓶颈在ES解析处 依据以后零碎CPU、负载信息定位是否服务器性能满负荷，是否扩容 无报警信息，整体运行安稳，根本排除业务资源达到瓶颈问题引起写入慢 MQ生产端生产慢，瓶颈在生产并发处 以后主题分片数3，队列数为15，默认最大并发数为15*10，报警过后入队数500~700/s 定位问题，为MQ生产慢，其根本原因为受到ES-Parse业务零碎处理速度影响 3.3 长期解决计划开启mq并行生产策略，写入QPS显著减少 4 如何晋升生产速率，晋升写入ES速率造成问题起因外围点是MQ积压，业务零碎生产慢，MQ入队数大于出队数，导致积压 4.1 原理剖析4.1.1 存储流程解析第一步：binlake订阅mysql binlog 第二步：发MQ，JMQ数据传输 第三步：生产JMQ数据，ES Paser数据解析， 第四步：数据存储 4.1.2 binlake基本原理 4.1.3 binlake发送MQ过程 4.1.4 JMQ生产原理JMQ生产默认就是批量生产 生产原理如下图 批量生产与并行生产原理如下图 通过剖析，在未开启并行生产前提下，以后主题最大处并发的生产解决能力即是队列数 4.2 晋升生产速率的几种计划4.2.1MQ减少生产速度办法扩容，减少并发生产能力 针对MQ默认状况下，所有扩容都能解决问题，增大分片数，减少队列数 须要额定资源，申请扩容新的broker，同时思考减少生产端实例 减少批量大小 首先保障，业务零碎(ES-Parse)生产MQ音讯，解决10条和解决100条速度根本一样 实际：国内财务针对此办法进行代码逻辑革新 开启并行数 实践上减少（并行数/批量数）的倍数并发解决能力 要求数据无序，针对乱序，数据存储，不影响业务 ...

字符串名称调用示例示例后果形容LEFTLEFT('abc123', 3)abc从给定字符串右边取指定长度的子串RIGHTRIGHT('abc123', 3)123从给定字符串左边取指定长度的子串LENGHLENGTH('abc')3求给定字符串占用的字节数LOWERLOWER('ABC')abc转换给定字符串为小写格局UPPERUPPER('abc')ABC转换给定字符串为大写格局LTRIMLTRIM(' abc')abc去除给定字符串的右边空格RTRIMRTRIM('abc ')abc去除给定字符串的左边空格SUBSTRINGSUBSTRING('abc123', 2, 3)bc1从给定字符串的指定地位截取指定长度的子串CONCATCONCAT('abc', '123')abc123将给定的各个字符串拼接成一个新字符串CHAR_LENGTHCHAT_LENGTH('狗仔')2求给定字符串的字符数量日期和工夫名称调用示例示例后果形容NOWNOW()2022-11-06 20:36:20返回以后日期和工夫CURDATECURDATE()2022-11-06返回以后日期CURTIMECURTIME()20:36:20返回以后工夫DATE_ADDDATE_ADD('2022-11-06 20:36:20', INTERVAL 2 DAY)2022-11-08 20:36:20将给定的日期和工夫值增加指定的工夫距离；示例中增加了2天DATE_SUBDATE_SUB('2022-11-06 20:36:20', INTERVAL 2 DAY)2022-11-04 20:36:20将给定的日期和工夫值减去指定的工夫距离DATEDIFFDATEDIFF('2022-11-06', '2022-11-11')-5返回两个日期之间的天数(正数示意前一个参数代表的日期比后一个参数示意的日期小)DATE_FORMATDATE_FORMAT(NOW(), '%m-%d-%Y')06-11-2022用给定的格局显示日期和工夫DATEDATE('2022-11-06 : 20:36:20')2022-11-06将给定日期和工夫值的日期提取进去YEARYEAR('2022-11-06 20:36:20')2022提取年份MONTHMONTH('2022-11-06 20:36:20')11提取月份DAYDAY('2022-11-06 20:36:20')6提取日HOURHOUR('2022-11-06 20:36:20')20提取小时MINUTEMINUTE('2022-11-06 20:36:20')36提取分钟SECONDSECOND('2022-11-06 20:36:20')20提取秒DATE_ADD和DATE_SUB函数的工夫距离的单位工夫单位形容MICROSECOND毫秒SECOND秒MINUTE分钟HOUR小时DAY天WEEK星期MONTH月QUARTER季度YEAR年日期和工夫的格局符格局符含意%b简写的月份名称(Jan、Feb、...、Dec)%D带有英文后缀的月份中的日期(0th、1st、2nd、...、31st)%d数字格局的月份中的日期(00、01、02、...、31)%f微秒(000000 ~ 999999)%H24小时制的小时(00 ~ 23)%h12小时制的小时(01 ~ 12)%i数值格局的分钟(00 ~ 59)%M月份名(January、February、...、December)%m数值模式的月份(00 ~ 12)%p上午或下午(AM代表上午，PM代表下午)%S秒(00 ~ 59)%s秒(00 ~ 59)%W星期名(Sunday、Monday、...、Saturday)%w周内第几天(0=星期日，1=星期一，...，6=星期六)%Y4位数字模式的年(例如2022)%y2位数字模式的年(例如22)数值名称调用示例示例后果形容ABSABS(-1)1取绝对值RANDRAND()0.3680035624355111返回一个随机数CEILCEIL(2.3)3返回一个不小于给定值的最小整数FLOORFLOOR(2.3)2返回一个不大于给定值的最大整数参考小孩子4919的Mysql是怎么应用的，不便查阅.

这个问题曾经困扰我一段时间了，对于大量数据的插入或更新，批量操作必定比每条记录调用一次快得多，新数据能够用 insert 批量插入，老数据能够用 replace into 批量更新。但如果不晓得数据是否存在（是否有惟一key和数据库中已有记录反复）想在一批数据库中，插入新记录，更新老记录怎么办？之前甚至想过封装一个函数，先用 select ... in 批量查问，而后分两组插入和更新，但一方面通用性不佳，另一方面这不是一个原子操作，对于并发的状况，有可能查问的时候记录不存在，插入的时候就曾经存在了。认真 google 了一下，才发现这种“存在update，不存在insert”的动作，有个专有名词，叫做“upsert”，相当形象。解决方案呢，不同数据库各有本人的解决方案和方言，Mysql 叫做 on duplicate key update，PostgreSql 中叫做 on confict do update。 根本用法INSERT INTO t1 (a,b,c) VALUES (1,2,3)ON DUPLICATE KEY UPDATE c=c+1;假如a、b是联结主键或者惟一索引，下面这句话意味着，当数据库中不存在 a=1 且 b=2 的记录，就插入一条 a=1,b=2,c=3 的新记录；如果存在，就把原记录的字段 c，更新为 c+1。如果 a 是独自的组成惟一键字段，那么判断是否存在的时候，就只思考字段a，如果 a=1 的记录存在，也只会更新字段 c，疏忽字段 b。 复用数值通常状况下，咱们 update 的字段，会比 insert 少一点，然而数据是一样的，这时候，再写一遍 values，岂但显得多余，而且容易出错，那么就能够用上面的语法： INSERT INTO t1 (a,b,c) VALUES (1,2,3)ON DUPLICATE KEY UPDATE c = VALUES(c);于是insert 或 update 字段 c ，后果就是同一个值了。 ...

virtualbox 配置mysql Host '主机名称' is not allowed to connect to this MySQL server 前言一句话总结：可能是防火墙的起因（即便防火墙可能是敞开的） 景象形容我在virtualbox里新建了两台虚拟机，主机1和主机2，我想在主机2中近程拜访主机1的mysql，曾经确认在主机1中开了账号并且容许所有IP拜访，但依然没法近程拜访. 尝试连贯就报谬误：Host '主机名称' is not allowed to connect to this MySQL server 解决方案（之一）特地揭示，请勿在有别人应用的机器上应用该命令，如开发环境、测试环境、甚至是线上环境#敞开防火墙策略iptables -F

2022 年云栖大会上，PolarDB-X 公布 2.2.0 版本，这是一个重要的里程碑版本，重点推出合乎分布式数据库金融规范下的企业级和国产化适配，共包含八大外围个性，全面晋升 PolarDB-X 分布式数据库在金融、通信、政务等行业的普适性。 架构简介PolarDB-X 采纳 Shared-nothing 与存储拆散计算架构进行设计，零碎由 4 个外围组件组成。 计算节点（CN, Compute Node）计算节点是零碎的入口，采纳无状态设计，包含 SQL 解析器、优化器、执行器等模块。负责数据分布式路由、计算及动静调度，负责分布式事务 2PC 协调、全局二级索引保护等，同时提供 SQL 限流、三权分立等企业级个性。存储节点（DN, Data Node）存储节点负责数据的长久化，基于多数派 Paxos 协定提供数据高牢靠、强统一保障，同时通过 MVCC 保护分布式事务可见性。元数据服务（GMS, Global Meta Service）元数据服务负责保护全局强统一的 Table/Schema, Statistics 等零碎 Meta 信息，保护账号、权限等平安信息，同时提供全局授时服务（即 TSO）。日志节点（CDC, Change Data Capture）日志节点提供齐全兼容 MySQL Binlog 格局和协定的增量订阅能力，提供兼容 MySQL Replication 协定的主从复制能力。开源地址：[https://github.com/ApsaraDB/g...]版本阐明梳理下PolarDB-X 开源脉络： 2021年10月，在云栖大会上，阿里云正式对外开源了云原生分布式数据库PolarDB-X，采纳全内核开源的模式，开源内容蕴含计算引擎、存储引擎、日志引擎、Kube等。2022年1月，PolarDB-X 正式公布 2.0.0 版本，继 2021 年 10 月 20 号云栖大会正式开源后的第一次版本更新，更新内容包含新增集群扩缩容、以及binlog生态兼容等个性，兼容 maxwell 和 debezium 增量日志订阅，以及新增其余泛滥新个性和修复若干问题。2022年3月，PolarDB-X 正式公布 2.1.0 版本，蕴含了四大外围个性，全面晋升 PolarDB-X 稳定性和生态兼容性，其中蕴含基于Paxos的三正本共识协定。2022年5月，PolarDB-X正式公布2.1.1 版本，重点推出冷热数据新个性，能够反对业务表的数据依照数据个性别离存储在不同的存储介质上，比方将冷数据存储到Aliyun OSS对象存储上。2022年9月份， PolarDB-X 数据库高分通过分布式数据库金融规范验证，共进行了 337 个检测项的验证工作，波及：架构、运维、平安、容灾、性能等。经专家评审后，PolarDB-X 断定合乎的检测项为323项，整体测试后果体现优异。2022年10月份，PolarDB-X 正式公布2.2.0版本，这是一个重要的里程碑版本，重点推出合乎分布式数据库金融规范下的企业级和国产化适配，共包含八大外围个性，全面晋升 PolarDB-X 分布式数据库在金融、通信、政务等行业的普适性。01 国产ARM适配目前市场上对于国产服务器的适配有比拟强的需要，常见的需要就是兼容CPU ARM架构，除了数据库能失常运行在ARM架构上，还须要联合国产ARM架构优化数据库的性能。 ...

简要介绍本文次要用于领导在openEuler 20.03 sp1 操作系统上部署mysql数据库。 MySQL 是一款平安、跨平台、高效的，并与 PHP、Java 等支流编程语言紧密结合的数据库系统。 本案例应用x86_64架构虚拟机，通过评估工具x2openEuler评估MySQL 5.7.21软件移植到openEuler操作系统的兼容性，再施行数据搬迁。 倡议应用版本为MySQL 5.7.21。 阐明: 本文档实用于MySQL 5.7.21，其余版本的MySQL移植步骤也可参考本文档。 案例环境服务器 我的项目阐明服务器磁盘容量CPU华为鲲鹏920处理器Raid卡SAS3508网络卡SAS3508 SAS3508 SAS3508磁盘容量500GB以上OS 软件版本备注OSCentos 7.6.1810以后mysql集群服务器OSopenEuler 20.03 SP1以后mysql集群服务器软件包 软件版本mysql55.7.21mysql5-common5.7.21mysql5-embedded5.7.21mysql5-embedded-devel5.7.21mysql5-errmsg5.7.21mysql5-libs5.7.21mysql5-server5.7.21mysql5-test5.7.21软件兼容性评估openEuler社区提供了 x2openEuler 工具 ，针对曾经编译好的二进制程序，进行次要实现软件包、接口级评估，明确应用软件是否须要移植适配，是否有依赖的软件包待引入；同时评估软件调用的接口原型在两个零碎中是否有差别。 注：曾经编译好的二进制程序，难以保障全副兼容新OS，重大时会引发才内存危险，往往这种问题很难通过验证的形式辨认进去，迁徙前针对软件兼容性评估尤为重要。 获取mysql的RPM包并解压到/opt/mysql目录下wget -P /opt https://downloads.mysql.com/archives/get/p/23/file/mysql-5.7.21-1.el7.x86_64.rpm-bundle.tarcd /opt/mkdir mysqltar -xf mysql-5.7.21-1.el7.x86_64.rpm-bundle.tar -C mysql下载x2openEuler工具到/opt/mysql下载x2openEuler工具到/opt/mysql部署工具cd /opt/mysqlrpm -ivh x2openEuler-2.0.0-1.x86_64.rpm留神：装置rpm时须要应用root用户，且目前须要网络（用于下载安装依赖） 留神：依据提醒装置依赖包如bzip2-devel等 su x2openEulerx2openEuler redis-db -init顺次录入redis数据库的ip:127.0.0.1 端口：6379 数据库索引号（0-16）：0 明码（工具会对明码加密解决）：如果redis明码没有设置或者为空时，间接回车即可 x2openEuler init source_centos7.6-openEuler20.03-LTS-SP1.tar.gz备注：x2openEuler应用rpm装置实现后会在/opt/x2openEuler目录下带有source_centos7.6-openEuler20.03-LTS-SP1.tar.gz这个默认资源包 须要反对centos8.2到openEuler20.03-LTS-SP1的评估，则需获取对应的动态资源包导入，如对应的资源包为source_centos8.2-openEuler20.03-LTS-SP1.tar.gz，导入此包命令：x2openEuler init source_centos8.2-openEuler20.03-LTS-SP1.tar.gz，请示状况抉择对应的资源包 扫描mysqlx2openEuler scan /opt/mysql/留神要剖析的移植文件须要有可能让x2openEuler用户能够读取的权限扫描实现后会在/opt/x2openEuler/output目录生成html格局的报告评估后果剖析软件兼容性评估报告分三块内容展现软件兼容性，别离是依赖包兼容性、C/C++接口兼容性、java接口兼容性，依赖包兼容性反映了软件包装置过程中的间接依赖，非100%表明无奈正确装置；接口兼容性反映的是单个软件运行过程中对其余软件包、动静库或零碎接口的调用变动，非100%表明在某个性能调用时可能会触发异样，未调用到时可能体现失常；局部后果倡议人工复核，最终软件包应用建优先级倡议 openEuler已移植包>openEuler上人工重编译包>centos软件包。 报告剖析关上html报告，逐行剖析，得出结论：在openEuler上间接应用centos的mysql包存在危险，危险如下：1个待确认接口表明mysql系列软件包会调用到libaio.so.1.0.1，其函数参数数量从4变为5，间接影响了性能，在某个性能调用时可能会触发异样；另外，报告显示须要确认3个依赖软件包，通过人工确认属于mysql系列包自闭环的依赖，故软件包装置无影响 剖析后果倡议倡议：因为函数调用危险，倡议间接应用在openEuler官网编译移植过的mysql-5.7.21系列软件包https://repo.openeuler.org/openEuler-20.03-LTS-SP1/everything/x86_64/Packages/mysql5-5.7.21-3.oe1.x86_64.rpmhttps://repo.openeuler.org/openEuler-20.03-LTS-SP1/everything/x86_64/Packages/mariadb-common-10.3.9-9.oe1.x86_64.rpmhttps://repo.openeuler.org/openEuler-20.03-LTS-SP1/everything/x86_64/Packages/mysql5-common-5.7.21-3.oe1.x86_64.rpmhttps://repo.openeuler.org/openEuler-20.03-LTS-SP1/everything/x86_64/Packages/mysql5-server-5.7.21-3.oe1.x86_64.rpmhttps://repo.openeuler.org/openEuler-20.03-LTS-SP1/everything/x86_64/Packages/mysql5-errmsg-5.7.21-3.oe1.x86_64.rpmhttps://repo.openeuler.org/openEuler-20.03-LTS-SP1/everything/x86_64/Packages/mecab-0.996-2.oe1.x86_64.rpm装置数据库mysql装置mysql并配置明码装置mariadb及mysql相干服务。rpm -ivh mysql5-5.7.21-3.oe1.x86_64.rpm mariadb-common-10.3.9-9.oe1.x86_64.rpm mysql5-common-5.7.21-3.oe1.x86_64.rpm mysql5-server-5.7.21-3.oe1.x86_64.rpm mecab-0.996-2.oe1.x86_64.rpm mysql5-errmsg-5.7.21-3.oe1.x86_64.rpm 启动mysql。systemctl start mysqld ...

mysql 报错： 1 of SELECT list is not in GROUP BY clause 解决： SET GLOBAL sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY','')); 这个设置，重启后，会生效。 mysql8 间接在装置的根目录新建 my.ini 内容为： [mysqld]sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION重启之后，就能够了。

1、先查看零碎是否装置有mysql rpm -qa | grep -i mysql2、查看有没有安装包 yum list mysql*3、装置mysql客户端 yum -y install mysql4、装置mysql服务端 yum -y install mysql-server第4步可能会报错，起因是CentOS7自带有MariaDB，如确定要装置mysql。则执行以下命令: sudo rpm -Uvh http://dev.mysql.com/get/mysql-community-release-el7-5.noarch.rpm而后持续第4步 5.装置一些开发库 yum -y install mysql-devel6.启动mysql 服务 service mysqld start7.创立管理员 mysqladmin -u root password 明码8.进入mysql mysql -u root -p而后输出明码 至此mysql装置结束。 9.附录-mysql齐全卸载 1.查看是否装置rpm -qa | grep -i mysql 2.删除第一步中的所有文件, rpm -ev --nodeps 文件名rpm -ev --nodeps mysql-community-release-el7-5.noarchrpm -ev --nodeps mysql-community-common-5.6.51-2.el7.x86_64rpm -ev --nodeps mysql-community-libs-5.6.51-2.el7.x86_64rpm -ev --nodeps mysql-community-devel-5.6.51-2.el7.x86_64rpm -ev --nodeps mysql-community-client-5.6.51-2.el7.x86_64rpm -ev --nodeps mysql-community-server-5.6.51-2.el7.x86_643.查找文件find / -name mysql ...

SELECT a.*, e.userName as chatUser, e.content as content, e.chatTime as chatTime FROM gp_group AS a LEFT JOIN ( SELECT b.* FROM chat_content b LEFT JOIN ( SELECT MAX(c.id) AS id, c.groupUnid FROM chat_content c GROUP BY c.groupUnid ) AS d ON d.groupUnid = b.groupUnid WHERE b.id = d.id ) AS e ON a.id = e.groupUnid where 1=1 <if test="qo.status != null" > and a.status = #{qo.status} </if> order by e.chatTime desc

为什么Mysql会抖一下是因为Mysql更新数据只写到redo的log里，达到阈值后会刷脏页，占用CPU资源。脏页是指内存页数据和磁盘页数据不统一的状况。产生场景 redolog写满到阈值后，需将对应的内存页数据刷到磁盘上。 须要尽量避免，否则所有更新操作都会被hang主内存不足，刷脏页到磁盘上。常态，最须要关怀的。资源闲暇时，刷页。也会时不时的刷下脏页。资源闲暇期刷脏页，零碎不会有压力。Mysql失常敞开的时候，刷脏页到磁盘。敞开时刷脏页，失常操作，也不会关怀性能。影响性能的几种状况 一次刷脏页太多。日志写满了，更新全副梗塞住。刷脏控制策略设置innodb_io_capacity 参数，可通过fio工具测试磁盘IO的IOPS注意事项比方查问操作，触发刷脏页时，会判断旁边的页是不是脏页，是的话一起刷掉，而且还能够向下传递。将相邻的脏页一起刷掉。 这也就会导致SQL操作时的rt可能被预期的更慢。能够通过参数innodb_flush_neighbors来管制，设置为1则会查找街坊脏页，设置为0则不查找街坊脏页。对于机械硬盘，倡议innodb_flush_neighbors设置为1，对于SSD，倡议设置为0。因为SSD的IOPS比机械硬盘高很多。为什么表数据删掉一半，表文件大小不变参数innodb_file_per_table管制着表数据寄存为值,ON示意表数据放在.idb后缀文件中。OFF示意零碎共享空间，默认值为ON。而且如果为OFF，则即便删除表，表空间也不会开释。举荐设置为ON。 delete 记录和表都不会开释表空间，会使得被开释的页被复用，也就是会产生空洞。 那如何去去掉空洞呢？ 重建表。 应用alter table A engine=InnoDB命令。其隐含意思是alter table t engine=innodb,ALGORITHM=inplace;analyze table t 只是对表的索引信息做从新统计，没有批改数据optimize table 等于 recreate+analyzeCOUNT(*) 这么慢，我怎么办？几种获取总数的形式 count(*) 会扫描全表，可能会影响性能。 Mysql做了优化，不取值，按行累加count(字段) 示意满足条件的数据里，参数"字段"不为NULL的数量count(id) 因为主键id不能为空，会按主键行累加count(1) innodb遍历整个表，但不取值，返回给server后，server放入一个1，按行累加依照效率排序的话，count(字段)<count(主键 id)<count(1)≈count(*)，所以我倡议你，尽量应用 count(*) 写Binlog后，commit前解体掉怎么保证数据残缺。解体复原的判断规定 如果 redo log 外面的事务是残缺的，也就是曾经有了 commit 标识，则间接提交；如果 redo log 外面的事务只有残缺的 prepare，则判断对应的事务 binlog 是否存在并残缺。 binglog残缺则提交事务，否则回滚事务。redo log 和 binlog 是怎么关联起来的?它们有一个独特的数据字段，叫 XID。解体复原的时候，会按程序扫描 redo log： 如果redo log中有commit则间接提交如果redo log中只有prepare，但没有commit，则带着XID去binlog中寻找，在binlog中通过checksum判断binlog是否残缺为什么还要两阶段提交呢？罗唆先 redo log 写完，再写 binlog。解体复原的时候，必须得两个日志都残缺才能够。是不是一样的逻辑？如果必须要举一个场景，来阐明这么做的必要性的话，那就是事务的持久性问题。对于 InnoDB 引擎来说，如果 redo log 提交实现了，事务就不能回滚（如果这还容许回滚，就可能笼罩掉别的事务的更新）。而如果 redo log 间接提交，而后 binlog 写入的时候失败，InnoDB 又回滚不了，数据和 binlog 日志又不统一了。 ...

随着企业数字化需要的减少，数据库行业倒退日益壮大，企业对DBA岗位的需要也处于逐渐减少中。咱们梳理了墨天轮平台上2022年最新的一批数据库经典面试题，次要蕴含PostgreSQL、MySQL和Oracle、数据仓库等方面的内容，心愿可能帮忙到各位正在或行将求职DBA的敌人们。 PostgreSQL2022年 PostgreSQL 面试题和答案（26道）52道 PostgreSQL 面试题（含10大常见题）2022年最常见的15道 PostgreSQL 面试题（附答案）2022年 PostgreSQL 面试题问答（含10大常见问题）MySQL、Oracle2022年求职者应该理解的37个 MySQL 面试题和答案2022年最高频的50个 MySQL 面试题（附答案）2022年MySQL最新面试题-MySQL数据库优化127道高级 Oracle DBA 面试概念题如果大家想获取更多Oracle、MySQL数据库相干的面试题，为大家举荐咱们去年整顿公布的《DBA面试资源合集》一文，蕴含墨天轮平台上超多优质的DBA面试资源的文章、文档（Oracle偏多），除了面试题还蕴含一些面试注意事项和教训案例，文章一经收回受到了很多敌人的喜爱，并且编辑部也在进行继续的补充更新。 SQL题20道经典的 SQL 编码面试题（附答案）面试中常见的 10 大SQL查问干货 | 快来get一份超实用的 SQL 面试终极指南（附习题）2022年 数据分析师 SQL 面试指南数据迷信面试：最常见的5道 SQL JOIN 题目及解答其余求职者应该筹备好答复的7个 Redis 面试题Redis大厂面试题总结（2022最新版 附答案）12个数据湖面试经典问题 （附答案）数仓题库：2022年最热门的 Delta Lake 面试题（附答案）2022年最常见的 Apache HBase 面试问题 本文未对墨天轮社区内容作齐全统计，仅摘选局部精品，更多内容大家能够自行搜寻“数据库面试”获取。此外，社区还设有“招聘”专区，欢送大家浏览。 墨天轮，围绕数据人的学习成长提供一站式的全面服务，打造集新闻资讯、在线问答、流动直播、在线课程、文档阅览、资源下载、常识分享及在线运维为一体的对立平台，继续促成数据畛域的常识流传和技术创新。 关注官网公众号： 墨天轮、 墨天轮平台、墨天轮成长营、数据库国产化 、数据库资讯

作者：林浩 DBA ，专一于 MySQL ，善于问题剖析解决。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 前段时间遇到一个 mysql 客户端 crash 的问题，这个 mysql 客户端是本人源码编译产生的。 为了解决这个问题，查阅了很多材料，波及终端 ncurses 编程、过程的地址空间（堆和栈）、cmake、gcc 编译等，遇到不少“陷阱”，好在算是比拟好的解决了这个问题。 环境：centos8.4 gcc8.4.1 mysql8.0.21 x86_64问题形容：对 mysql8.0.21 源码进行 make，因为一开始没装置 ncurses 库，在链接时遇到谬误 undefined reference to，起初装置了该库，再次 make 胜利。于是将 mysqld 启动，再用 mysql -u root -p 连贯，输好明码回车后 mysql 客户端产生 Segmentation fault。 第一次 make 时有编译正告（第二次 make 时不会有，因为.o 文件在第一次 make 时曾经生成），摘要如下： /opt/resource/mysql-8.0.21/extra/libedit/libedit-20190324-3.1/src/terminal.c: In function ‘terminal_set’:/opt/resource/mysql-8.0.21/extra/libedit/libedit-20190324-3.1/src/terminal.c:877:6: warning: implicit declaration of function ‘tgetent’; did you mean ‘getenv’? [-Wimplicit-function-declaration] i = tgetent(el->el_terminal.t_cap, term); ^~~~~~~ getenv/opt/resource/mysql-8.0.21/extra/libedit/libedit-20190324-3.1/src/terminal.c:899:15: warning:implicit declaration of function ‘tgetflag’; did you mean ‘tigetflag’? [-Wimplicit-function-declaration] Val(T_am) = tgetflag("am"); ^~~~~~~~ tigetflag/opt/resource/mysql-8.0.21/extra/libedit/libedit-20190324-3.1/src/terminal.c:908:15: warning:implicit declaration of function ‘tgetnum’; did you mean ‘tigetnum’? [-Wimplicit-function-declaration] Val(T_co) = tgetnum("co"); ^~~~~~~ tigetnum/opt/resource/mysql-8.0.21/extra/libedit/libedit-20190324-3.1/src/terminal.c:917:19: warning:implicit declaration of function ‘tgetstr’; did you mean ‘tigetstr’? [-Wimplicit-function-declaration] char *tmp = tgetstr(strchr(t->name, *t->name), &area); ^~~~~~~ tigetstr/opt/resource/mysql-8.0.21/extra/libedit/libedit-20190324-3.1/src/terminal.c:917:19: warning:initialization of ‘ char * ’ from ‘ int ’ makes pointer from integer without a cast[-Wint-conversion]剖析过程： ...

大家好，我是不才陈某~ 作为在后端圈开车的多年老司机，是不是常常听到过，“mysql 单表最好不要超过 2000w”,“单表超过 2000w 就要思考数据迁徙了”，“你这个表数据都马上要到 2000w 了，难怪查问速度慢” 这些名言民语就和 “群里只探讨技术，不开车，开车速度不要超过 120 码，否则主动踢群”，只听过，没试过，哈哈。 上面咱们就把车速踩到底，干到 180 码试试……. 试验试验一把看看… 建一张表 CREATE TABLE person(id int NOT NULL AUTO_INCREMENT PRIMARY KEY comment '主键',person_id tinyint not null comment '用户id',person_name VARCHAR(200) comment '用户名称',gmt_create datetime comment '创立工夫',gmt_modified datetime comment '批改工夫') comment '人员信息表';插入一条数据 insert into person values(1,1,'user_1', NOW(), now());利用 mysql 伪列 rownum 设置伪列起始点为 1 select (@i:[email protected]+1) as rownum, person_name from person, (select @i:=100) as init;set @i=1;运行上面的 sql，间断执行 20 次，就是 2 的 20 次方约等于 100w 的数据；执行 23 次就是 2 的 23 次方约等于 800w , 如此上来即可实现千万测试数据的插入，如果不想翻倍翻倍的减少数据，而是想大量，大量的减少，有个技巧，就是在 SQL 的前面减少 where 条件，如 id > 某一个值去管制减少的数据量即可。 ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 MySQL Shell 是兼容 MySQL 传统命令行客户端的超级代替版，反对 SQL 、JavaScript 、Python 三种语言环境。工具本身蕴含了很多组件，使得 DBA 们治理 MySQL 更加便捷高效。 明天咱们来介绍 MySQL Shell 的组件：MYSQLX 组件的两个检索函数在具体应用上的一些区别。 MYSQLX 组件蕴含很多预置的类库， 其中与MySQL 交互最间接的就是 Session 类库。Session 类库里又蕴含一系列内置函数来解决数据：其中函数 run_sql 和 sql 都能够间接和 MySQL 服务端交互来运行 SQL 语句。那到底有什么区别呢？ 咱们接下来具体介绍这两个。（Python 环境写法：run_sql、sql；JavaScript环境下：runSQL、sql） 第一、函数run_sql 如何应用：先连上 X 端口 33060，代替默认语言环境为 Python ，变量 c1 即为 Session 对象（<Session:[email protected]:33060>）。 [email protected]:/home/ytt# mysqlsh mysqlx:/[email protected]:33060/ytt --pyMySQL Shell 8.0.30...Creating an X protocol session to '[email protected]:33060/ytt'Fetching schema names for autocompletion... Press ^C to stop.Your MySQL connection id is 9 (X protocol)Server version: 8.0.30 MySQL Community Server - GPLDefault schema `ytt` accessible through db.MySQL localhost:33060+ ssl ytt Py > c1=db.get_session()MySQL localhost:33060+ ssl ytt Py > c1<Session:[email protected]:33060>执行 run_sql 创立表t1： run_sql 能够运行任何 MySQL 兼容的 SQL 语句。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。前文回顾实现一个简略的Database1(译文） 实现一个简略的Database2(译文） 实现一个简略的Database3(译文） 实现一个简略的Database4(译文） 实现一个简略的Database5(译文） 实现一个简略的Database6(译文） 译注：cstsck在github保护了一个简略的、相似sqlite的数据库实现，通过这个简略的我的项目，能够很好的了解数据库是如何运行的。本文是第七篇，次要是对B-tree的介绍 Part 7 B-Tree简介B-tree是SQLite用来示意表和索引的数据结构，所以B-tree是十分核心的想法。这个主题次要是介绍B-tree数据结构，所以不会有任何的代码。 为什么说对于数据库来说，树是十分好的数据结构呢？ 查找特定的value很快（对数工夫花销，loga N）插入一行或者对查问到的数据删除很快（再均衡应用常量工夫）遍历一个范畴内的value很快（不像hash map）B-tree不同于二叉树（“B”可能代表发明人的名字，但也能够代表“Balanced”）。这里是一个B-tree例子： B-Tree 例子(https://en.wikipedia.org/wiki...) 不像二叉树每个节点只能有两个子节点，B-tree的每个节点能够有两个以上的子节点。每个节点最多能够有 m 个子节点，其中 m 叫做树的“order”（或者叫“阶”）。为了放弃树的尽量均衡，咱们还要求节点必须至多有 m / 2 个子节点（四舍五入）。 但还有一些例外： 叶子节点没有子节点根节点的子节点数能够少于 m，但至多要有两个如果根节点也是叶子节点（树只有一个节点），那它有0个子节点下面的形容的是一个B-tree，SQLite用它来存储索引。为了存储表数据，SQLites应用一种B-tree的变体，称为B+tree。 B-treeB+ tree发音“Bee Tree”“Bee Plus Tree”用来存储索引表外部节点是否存储key是是外部节点是否存储value是否每个节点的子节点数少多外部节点 vs 叶子节点雷同构造不同构造在咱们开始实现索引之前，我将只探讨B+tree，但这里将其称为 B-tree 或者 btree。 有子节点（children）的节点被称为“外部”节点（internal node），外部节点和叶子节点在结构上不同： m阶tree外部节点叶子节点存储key和指向子节点的指针key和valuekey的数目最多m-1个越多越好指针的数目keys + 1无value的数目无与key的数目雷同Key的用处用来路由与value成对存储存储value?否是这里通过一个例子来看一下，当插入一个元素时，B-tree是怎么产生构造变动的。为了让事件看起来更容易了解，这棵B-tree的阶（order）设置为3(m=3)，也就是说： 每个外部节点最多有三个子节点(m)每个外部节点最多有两个key每个外部节点至多两个子节点（m-1）每个外部节点至多一个key一棵空树只有一个节点：根节点。根节点最开始也作为叶子节点，有0个键值对（key/value）： 空的btree如果咱们插入两个键值对（超过两个键值对，节点须要决裂，参考下面规定），他们会按程序排序寄存在叶子节点中。 一个节点的btree咱们假如了节点的容量是两个键值对儿。当咱们插入另外一个的时候，就不得不决裂叶子节点了，决裂后的两个节点每个寄存之前一半的键值对。决裂后的两个节点都变成了外部节点，同时也变成了一个新的节点的子节点，这个新的节点变成了根节点。 两层的btree 图中的外部节点（也是根节点）有一个key和两个指针指向子节点（就是那两条线）。如果咱们想查找一个key，key小于或等于5，咱们查看左子树。如果查找的key大于5，就查看右子树。 当初，筹备插入一个新的key "2"。首先，咱们查找它将位于哪个叶节点（如果它在树中存在的话），这样就达到了左侧叶子节点。这个节点是满的，所以把这个叶子节点进行决裂（split），并在父节点创立新的条目。 四节点的btree 当初持续减少key，18 和 21 。当初又到了不得不决裂的状况，然而在父节点中曾经没有空间来减少新的键值对儿了。 外部节点没有空间 解决办法就是决裂根节点为两个外部节点，而后创立一个新的根节点作为两个外部节点的父节点。 三层的btree 树只是在咱们决裂根节点的时候才会减少深度。每个叶子节点都有雷同的深度和靠近雷同的数量的键值对儿，所以树可能保持平衡和疾速的进行查找。 我临时先不探讨从树中删除键的操作，推延到实现插入操作当前。 当咱们实现这个数据结构时，每个节点都对应一个page。根节点将在page0中存在。节点中的子节点指针将简略的应用蕴含子节点的page number。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。前文回顾实现一个简略的Database1(译文） 实现一个简略的Database2(译文） 实现一个简略的Database3(译文） 实现一个简略的Database4(译文） 实现一个简略的Database5(译文） 译注：cstsck在github保护了一个简略的、相似sqlite的数据库实现，通过这个简略的我的项目，能够很好的了解数据库是如何运行的。本文是第六篇，次要是实现数据长久化游标 Part 6 游标形象跟上一节相比，这一节篇幅绝对要简短的多。咱们只是略微重构一下，这样就能够让开始实现B-tree更简略一些。 在代码中新增加一个Cursor对象，它用来代表表中的一个地位（location）。 你可能心愿对游标执行的操作： 在表结尾时创立一个游标在表结尾时创立一个游标拜访游标指向的行将游标挪动到下一行这就是咱们将要实现的游标的一些行为。而后，咱们还想做到： 删除游标指向的一行数据批改游标指向的一行数据应用给定的ID搜寻一张表，并创立一个游标指向这个ID所在的行_译注：这里简略介绍一下游标，Cursor本来就有箭头、光标的意思，用来批示事物以示关注。游标是数据的一种拜访机制，一种解决数据的办法，例如查问返回的后果是一行或者多行的后果集（这曾经是SQL被解决后的后果集），咱们须要对后果集进行查问，sql语句就不论用了，因为这曾经是返回的后果集了，这个时候就须要用游标来遍历这个返回的后果集了。能够了解游标是一个指向Row的指针，拜访一行后，游标就会指向下一行。例如 fetchone()、fetchall() 等函数就是通过游标来拜访后果集的，返回具体一行或者多行的数据。上面是游标图示： 不磨叽了，上面就是Cursor类型构造： +typedef struct {+ Table* table;+ uint32_t row_num;+ bool end_of_table; // Indicates a position one past the last element+} Cursor;依据当初咱们的表数据结构，只须要行号即可辨认表中的地位。 游标对它所属的表还有一个援用（所以咱们的游标函数还能够仅仅把游标作为参数）。 最初，它还有一个boolean类型的属性叫做 end_of_table 。这样咱们就能够用来示意表结尾之后的地位（在这里咱们可能会插入一个新行）。 table_start() 和 table_end() 创立一个新的游标: +Cursor* table_start(Table* table) {+ Cursor* cursor = malloc(sizeof(Cursor));+ cursor->table = table;+ cursor->row_num = 0;+ cursor->end_of_table = (table->num_rows == 0);++ return cursor;+}++Cursor* table_end(Table* table) {+ Cursor* cursor = malloc(sizeof(Cursor));+ cursor->table = table;+ cursor->row_num = table->num_rows;+ cursor->end_of_table = true;++ return cursor;+}咱们的 row_slot() 函数要变成 cursor_value() 了，它返回一个指针类型，指向游标形容的地位： ...

最近的工作中实现了一个定时统计性能：须要按指定程序，从源表中取出数据，通过分组合并，插入指标表。 源表数据量相当大，有几千万行，显然不适宜一次性取出（如果是一次性的脚本，在大内存的机器上也是能够思考的，但定时工作每次启动都占用数十GB内存就太夸大了），须要分页查问。 但最后的实现中，采纳了一个封装好的分页库，单纯的全表查问，纯正依赖limit子句限度后果集窗口，形成的SQL语句相似这样： select * from A order by x, y limit 30000, 10000其中字段 x 和字段 y 是有联结索引的，每页返回 10000 条。 后果惨不忍睹，每页查问须要40秒能力返回，而这样的查问须要循环几千次，整整半天工夫都没执行完。 解决方案也很简略，应用自定义的分页机制，基于字段 x 筛选实现分页： select * from A where x > 30000 order by x, y limit 10000留神：这里的 30000，只是示例，每次要把上一页最初一条的 x 值记下来，当做下一页"x > ?" 的判断条件。python + sqlalchemy 的代码示例如下： PAGE_SIZE = 10000last_x = 0 # 这里假如 x 永远是大于零的整数，如果不是，初始化一个最小值while last_x == 0 or len(records > 0): # last_x == 0 这个条件，相当于判断是否第一次循环，这里其实有 do...while 语句更好，惋惜 python 没有 records = A.query.filter(A.x > last_x).order_by(A.x, A.y).limit(PAGE_SIZE) last_x = records[-1].x # do something

 ## 一：navicat软件装置 navicat装置下载地址：https://www.navicat.com.cn/do... 二：navicat激活1：navicat激活工具下载链接：https://pan.baidu.com/s/1gwgmBWo-voH46TMMFYbbyA 提取码：nhgn2：navicat激活(1)：运行 NavicatCracker.exe (2)：断网(3)：抉择装置目录 (4)：点击Patch!-》是 (5)： 点击Generate->copy （6）：将复制的密钥放到navicat中激活，而后抉择手动激活  #### (7)：复制申请码 (8)：将复制的申请码复制到激活工具中而后点击Generate Activation Code (9)：将激活工具生成的激活码复制到navicat中点击激活即可   至此navicat激活胜利

咱们应用alter table add column语句向现有表中增加新列。 简介alter table table_nameadd [column] column_name column_definition [first|after existing_column];阐明： alter table子句后指定表名；column关键字是可选的，能够省略它；能够通过first关键字将新列增加为表的第一列，也能够应用after existing_column子句在现有列之后增加新列，如果没有明确指定会将其增加为最初一列；若要向表中增加两个或更多列，应用上面语法： alter table table_nameadd [column] column_name column_definition [first|after existing_column],add [column] column_name column_definition [first|after existing_column],...;举例创立一个表create database test;use test;create table if not exists vendor ( id int auto_increment primary key, name varchar(255));增加新列并指定地位alter table vendoradd column phone varchar(15) after name;增加新列但不指定新列地位alter table vendoradd column vendor_group int not null;插入记录insert into vendor(name, phone, vendor_group)values('IBM', '(408)-298-2987', 1);insert into vendor(name, phone, vendor_group)values('Microsoft', '(408)-298-2988', 1);同时增加两列alter table vendoradd column email varchar(100) not null,add column hourly_rate decimal(10, 2) not null;留神：email和hourly_rate两列都是not null，然而vendor表曾经有数据了，在这种状况下，MySQL将应用这些新列的默认值。查看vendor表中的数据select id, name, phone, vendor_group, email, hourly_ratefrom vendor;查问后果： ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。用一个扼要、清晰的步骤来解析一下DML操作产生的binlog event。次要是 TABLE_MAP_EVENT 和 UPDATE_ROWS_EVENT 类型的event。应用语法简略易上手的Golang来编码。数据库应用的是MySQL 5.7.34版本， Golang 1.15版本。 获取binlog event获取binlog个别是模仿成从库封装通信 package 向主库发送binlog dump命令（COM_BINLOG_DUMP或者COM_BINLOG_DUMP_GTID）来获取binlog。在这篇文章中，是封装的 COM_BINLOG_DUMP 向数据库申请的指定位点的 event。 模仿操作产生event查看主动自交参数： mysql> show variables like 'autocommit';+---------------+-------+| Variable_name | Value |+---------------+-------+| autocommit | ON |+---------------+-------+1 row in set (0.00 sec)简略的表构造： mysql> create table test (id int primary key, name char(10), addr varchar(10), birthdate date);Query OK, 0 rows affected (0.03 sec)筹备数据： mysql> insert into test value (1, 'tom', 'Hollywood', '1940-02-10');Query OK, 1 row affected (0.02 sec)mysql> insert into test value (2, 'Jerry', 'Hollywood', '1940-02-10');Query OK, 1 row affected (0.01 sec)mysql> select * from test;+----+-------+-----------+------------+| id | name | addr | birthdate |+----+-------+-----------+------------+| 1 | tom | Hollywood | 1940-02-10 || 2 | Jerry | Hollywood | 1940-02-10 |+----+-------+-----------+------------+2 rows in set (0.01 sec)查看binlog： ...

写在后面Xmind文件获取：GitHub 继续更新中，别忘了 star 喔~@TOC「Java学习+面试指南」思维导图，计算机自学指南，包含Java根底、JVM、数据库、mysql、redis、计算机网络、算法、数据结构、操作系统等，后盾技术栈/架构师之路/全栈开发社区，阿里，腾讯，百度，美团，头条等春招/秋招/校招/面试 思维导图（png格局可下载放大） mysql事务四大个性(ACID)原子性 要么全副实现，要么齐全不起作用一致性 多个事务对同一个数据读取的后果是雷同的隔离性 各并发事务之间数据库是独立的持久性 数据的扭转是长久的读脏读 A读，B读，A回滚，B不正确不可反复读 A读1，B写2，A读2幻读 A读2条，B删了1条，A读1条四个隔离级别READ-UNCOMMITTED(读取未提交) 容许读取尚未提交的数据 3READ-COMMITTED(读取已提交) 容许读取并发事务曾经提交 阻止脏读REPEATABLE-READ(可反复读) 屡次读取后果都是统一 阻止脏读和不可反复读SERIALIZABLE(可串行化) 顺次一一执行隔离机制的实现基于锁机制和并发调度（MVVC（多版本并发管制），通过保留批改的旧版本信息）Mysql 默认采纳的 REPEATABLE_READ隔离级别，分布式事务SERIALIZABLE(可串行化)Oracle 默认采纳的 READ_COMMITTED隔离级别锁Read Uncommitted 不须要加共享锁，不会跟被批改的数据上的排他锁抵触Read Committed 加共享锁，语句执行完当前开释共享锁Repeatable Read 须要加共享锁，必须期待事务执行结束当前才开释共享锁SERIALIZABLE 锁定整个范畴的键，并始终持有锁，直到事务实现粒度表级锁 开销小，加锁快锁定粒度大，收回锁抵触的概率最高，并发度最低MYISAM与INNODB行级锁 开销大，加锁慢锁定粒度最小，产生锁抵触的概率最低，并发度也最高INNODB页级锁 开销和加锁工夫界于表锁和行锁之间一次锁定相邻的一组记录并发度个别类别共享锁读锁 能够同时加上多个排他锁写锁 只能够加一个其余的排他锁，共享锁都相斥锁乐观锁 数据库中的锁机制多写的场景下乐观锁 应用版本号机制或CAS算法实现写比拟少的状况下（多读场景）基础知识三大范式第一范式 列不可再分第二范式 非主键齐全依赖主键，不能局部依赖第三范式 非主键只依赖主键，不依赖非主键权限表user 用户账号信息，全局db 账号各数据库的操作权限table_priv 表级操作权限column_priv 列级操作权限host 给定主机binlogstatement 批改数据的sql：缩小日志量、解决io，需保留上下文，函数之类无奈被复制row 记录每一行的改变：全部记下来，信息多日志量大mixed 一般用statement，无奈应用用rowMySQL主从复制，Master把它的二进制日志传递给slaves来达到master-slave数据统一的目标数据恢复：通过应用 mysqlbinlog工具来使复原数据数据类型整数类型 TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，别离示意1字节、2字节、3字节、4字节、8字节整数加上UNSIGNED示意无符号指定长度：INT(11)只影响显示字符，须要和UNSIGNED ZEROFILL才有意义int(20) 显示字符的长度。20示意最大显示宽度为20，但仍占4字节存储，存储范畴不变，int(1)和int(20)存储和计算均一样不影响外部存储，只是影响带 zerofill 定义的 int 时，后面补多少个 0，易于报表展现实数类型 DECIMAL能够用于存储比BIGINT还大的整型，能存储准确的小数。而FLOAT和DOUBLE是有取值范畴的，并反对应用规范的浮点进行近似计算。计算时FLOAT和DOUBLE相比DECIMAL效率更高一些，DECIMAL你能够了解成是用字符串进行解决。FLOAT类型4字节，DOUBLE类型8字节字符串类型 VARCHAR VARCHAR用于存储可变长字符串，它比定长类型更节俭空间。VARCHAR应用额定1或2个字节存储字符串长度。列长度小于255字节时，应用1字节示意，否则应用2字节示意。VARCHAR存储的内容超出设置的长度时，内容会被截断。CHAR CHAR是定长的，依据定义的字符串长度调配足够的空间。CHAR会依据须要应用空格进行填充不便比拟。CHAR适宜存储很短的字符串，或者所有值都靠近同一个长度。CHAR存储的内容超出设置的长度时，内容同样会被截断。长度固定，所以存取速度要比varchar快很多，甚至能快50%长度固定，所以会占据多余的空间，是空间换工夫的做法综合 对于常常变更的数据来说，CHAR比VARCHAR更好，因为CHAR不容易产生碎片。对于十分短的列，CHAR比VARCHAR在存储空间上更有效率。应用时要留神只调配须要的空间，更长的列排序时会耗费更多内存。尽量避免应用TEXT/BLOB类型，查问时会应用长期表，导致重大的性能开销。性能角度（char更快）和节俭磁盘空间角度（varchar更小chart(10)和varchar(10)示意存储数据的大小，即示意存储多少个字符 char(10)示意存储定长的10个字符，有余10个就用空格补齐，占用更多的存储空间varchar(10)示意存储10个变长的字符，存储多少个就是多少个空格也按一个字符存储，这一点是和char(10)的空格不同的，char(10)的空格示意占位不算一个字符明码散列，盐，用户身份证号等固定长度的字符串应该应用char而不是varchar来存储，这样能够节俭空间且进步检索效率。日期和工夫类型 尽量应用timestamp，空间效率高于datetime，用整数保留工夫戳通常不不便解决。如果须要存储微秒，能够应用bigint存储。关键字in 和 existsin 表面和内表作hash 连贯exists ...

综述首先须要了解以下概念： B+Tree、聚簇索引、二级索引、稠密索引mysql page的构造其次，总体而言能够将获取数据的类型分为： 命中了索引，能够间接从聚簇索引下面获取数据，或者通过二级索引定位到聚簇索引，接着获取数据；齐全没有命中索引，mysql须要扫描所有数据页（也就是聚簇索引B+树的叶子节点）；具体而言，就是剖析where条件的具体写法，也就是常说的索引生效的状况： 查问过程不合乎B+树索引构造： 条件中有or；应用!=，<, > 等范畴查问；应用is null和is not null；全文匹配的like，只有%写在最初面才能够走索引。在索引列上搞骚操作： 在索引列上进行计算；在索引列上进行隐式转换；在索引中应用函数；不确定的状况下能够应用explain语句，剖析索引应用状况，次要看type和extra字段。 type字段： 没有join操作，type能够是all、index、range、const有join操作，type能够是eq_ref和refextra字段：当type是index的时候，阐明用到了索引，extra能够有3个值： using where：等同于type=all，where是在取完所有数据之后才过滤；using index：能够间接在索引树上实现检索，无需拜访理论的行数据。mysql的数据也并非所有状况下都在叶子节点，当数据类型是blob或text且超过page size的一半（通常是8k，默认的page size是16k，这个值能够配置为4k，8k，16k，32k，64k），blob字段的值会被放到其余页，索引页只留下blob的前768个字节。 所谓的回表默认状况下，mysql会用id作为聚簇索引；在没有id或者id不惟一的状况下，才会应用unique key作为索引。假如有二级索引且有id作为聚簇索引，mysql会创立两颗B+树，查问二级索引会先去二级索引的B+树的叶子节点找到id，再去聚簇索引查到具体的数据页，就是俗称的回表。

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。前情提要以后读快照读什么是MVCC 三个暗藏字段Undo Log回滚日志MVCC版本链ReadView读视图不同隔离级别下MVCC剖析 READ-COMMITTED隔离级别REPEATABLE-READ隔离级别前情提要事务有四大个性ACID别离是：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability） 其中隔离性是通过数据库的锁加上MVCC(多版本并发管制)来保障的。 在介绍MVCC之前先来理解一下以后读和快照读。 以后读以后读读取的是记录的最新版本。同时在读取的时候还要保障其余的并发事务不能更改以后记录，那么以后读会对它要读取的记录进行加锁。不同的操作会加上不同类型的锁，如：SELECT ... LOCK IN SHARE MODE(共享锁)，SELECT ... FOR UPDATE、UPDATE、INSERT、 DELETE(排他锁)。 快照读简略的不加锁的SELECT就是快照读，快照读读取的是快照生成时的数据，不肯定是最新的数据，它是不加锁的非阻塞读。而不同隔离级别下，创立快照的机会也不同： READ-COMMITTED(读已提交)：事务每次SELECT时创立ReadViewREPEATABLE-READ(可反复读)：事务第一次SELECT时创立ReadView，后续始终应用在MySQL默认隔离级别(REPEATABLE-READ)下，快照读保障了数据的可反复读。 什么是MVCCMVCC全称Multi-Version Concurrency Control，即多版本并发管制。它是一种并发管制的办法，它能够保护一个数据的多个版本，用更好的形式去解决读写抵触，做到即便有读写抵触也能不加锁。MySQL中MVCC的具体实现，还须要依赖于表中的三个暗藏字段、Undo Log日志以及ReadView。 三个暗藏字段mysql> SHOW CREATE TABLE stu \G;*************************** 1. row *************************** Table: stuCreate Table: CREATE TABLE `stu` ( `id` int NOT NULL, `name` varchar(10) NOT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci1 row in set (0.00 sec)mysql> SELECT * FROM stu;+----+--------+| id | name |+----+--------+| 1 | m || 2 | f |+----+--------+当创立了上述这张表后，咱们在查看表构造时只能看到id、name字段，实际上除了这两个字段外，InnoDB引擎还主动为咱们增加了三个暗藏字段，见下表： ...

网摘sql优化口诀 全值匹配我最爱，最左前缀要恪守 带头大哥不能死，两头兄弟不能断 索引列上少计算，范畴之后全生效 LIKE符号写最右，笼罩索引不写星 不等空值还有or，索引生效要少用 var引号不能丢，SQL高级也不难 分组之前必排序，肯定要上索引啊案例:千万级数据应用limit实现分页优化 https://www.jianshu.com/p/c62...1.应用笼罩索引 CREATE TABLE `user` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `name` varchar(32) NOT NULL DEFAULT '' COMMENT '姓名', `age` tinyint(4) NOT NULL COMMENT '年纪', `sex` tinyint(4) NOT NULL COMMENT '性别', `email` varchar(32) NOT NULL DEFAULT '' COMMENT '邮箱', `ctime` int(11) NOT NULL COMMENT '创立工夫', PRIMARY KEY (`id`), KEY `index_email` (`email`(7)), KEY `index_id_email` (`id`,`email`)) ENGINE=InnoDB AUTO_INCREMENT=131604 DEFAULT CHARSET=utf8mb4;mysql> select SQL_NO_CACHE id,email from user limit 100000,10;+--------+-------------+| id | email |+--------+-------------+| 100001 | [email protected] || 100002 | [email protected] || 100003 | [email protected] || 100004 | [email protected] || 100005 | [email protected] || 100006 | [email protected] || 100007 | [email protected] || 100008 | [email protected] || 100009 | [email protected] || 100010 | [email protected] |+--------+-------------+10 rows in set, 1 warning (0.02 sec) mysql> select SQL_NO_CACHE id,email,name from user limit 100000,10;+--------+-------------+-------+| id | email | name |+--------+-------------+-------+| 100001 | [email protected] | 张xx || 100002 | [email protected] | 张xx || 100003 | [email protected] | 张xx || 100004 | [email protected] | 张xx || 100005 | [email protected] | 张xx || 100006 | [email protected] | 张xx || 100007 | [email protected] | 张xx || 100008 | [email protected] | 张xx || 100009 | [email protected] | 张xx || 100010 | [email protected] | 张xx |+--------+-------------+-------+10 rows in set, 1 warning (0.03 sec) mysql> explain select SQL_NO_CACHE id,email from user limit 100000,10;+----+-------------+-------+------------+-------+---------------+----------------+---------+------+--------+----------+-------------+| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |+----+-------------+-------+------------+-------+---------------+----------------+---------+------+--------+----------+-------------+| 1 | SIMPLE | user | NULL | index | NULL | index_id_email | 134 | NULL | 131052 | 100.00 | Using index |+----+-------------+-------+------------+-------+---------------+----------------+---------+------+--------+----------+-------------+1 row in set, 2 warnings (0.01 sec) mysql> explain select SQL_NO_CACHE id,email,name from user limit 100000,10;+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+-------+| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+-------+| 1 | SIMPLE | user | NULL | ALL | NULL | NULL | NULL | NULL | 131052 | 100.00 | NULL |+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+-------+1 row in set, 2 warnings (0.00 sec) Using index:应用到了笼罩索引 mysql> show profiles;+----------+------------+---------------------------------------------------------------------+| Query_ID | Duration | Query |+----------+------------+---------------------------------------------------------------------+| 204 | 0.00040800 | select SQL_NO_CACHE id,email from user limit 100,10 || 205 | 0.00039600 | select SQL_NO_CACHE id,email from user limit 100,10 || 206 | 0.00645100 | explain select SQL_NO_CACHE id,email from user limit 100,10 || 207 | 0.00036400 | explain select SQL_NO_CACHE email from user limit 100,10 || 208 | 0.00053500 | explain select SQL_NO_CACHE id,email,name from user limit 100,10 || 209 | 0.00698800 | select SQL_NO_CACHE id,email from user limit 100,10 || 210 | 0.00067400 | select SQL_NO_CACHE id,email,name from user limit 100,10 || 211 | 0.00045100 | select SQL_NO_CACHE id,email,name from user limit 100,10 || 212 | 0.00032900 | select SQL_NO_CACHE id,email from user limit 100,10 || 213 | 0.02265800 | select SQL_NO_CACHE id,email from user limit 100000,10 || 214 | 0.03214000 | select SQL_NO_CACHE id,email,name from user limit 100000,10 || 215 | 0.00046200 | explain select SQL_NO_CACHE id,email from user limit 100000,10 || 216 | 0.00040000 | explain select SQL_NO_CACHE id,email,name from user limit 100000,10 || 217 | 0.01920500 | select SQL_NO_CACHE id,email from user limit 100000,10 || 218 | 0.03084100 | select SQL_NO_CACHE id,email,name from user limit 100000,10 |+----------+------------+---------------------------------------------------------------------+察看 query_id是217和218的两条sql,就是方才执行得出的,工夫失去显著晋升,且用到了index_id_email索引,应用到笼罩索引，数据间接从索引中就能够获取到,不须要回表从主键索引里获取数据, 笼罩索引是指，索引上的信息足够满足查问申请，不须要再回到主键索引上去取数据。因为笼罩索引能够缩小树的搜寻次数，显著晋升查问性能，所以应用笼罩索引是一个罕用的性能优化伎俩。应用SQL_NO_CACHE强制不走mysql查问缓存 ...

1.插入缓冲2.两次写3.自适应哈希索引4.异步io5.刷新邻近页 mysql 文件介绍日志文件1.error.log 谬误日志:mysql> show variables like "log_error";+---------------+---------------------------------------------+| Variable_name | Value |+---------------+---------------------------------------------+| log_error | /Users/itech8/data/apps/logs/mysql/error.log |+---------------+---------------------------------------------+1 row in set (0.01 sec) 2.慢查问日志, 默认慢查问日志工夫设置的是10秒mysql> show variables like "long_query_time";+-----------------+-----------+| Variable_name | Value |+-----------------+-----------+| long_query_time | 10.000000 |+-----------------+-----------+1 row in set (0.01 sec) 慢查问日志文件地位:mysql> show variables like "slow_query_log%";+---------------------+------------------------------------------------------------------+| Variable_name | Value |+---------------------+------------------------------------------------------------------+| slow_query_log | OFF || slow_query_log_file | /Users/itech8/data/apps/appdata/mysql/itech8deMacBook-Air-slow.log |+---------------------+------------------------------------------------------------------+2 rows in set (0.00 sec) 慢查问日志剖析mysqldumpslow Users/itech8/data/apps/appdata/mysql/itech8eMacBook-Air-slow.log获取执行工夫最长的10条记录mysqldumpslow -s -al -n 10 Users/itech8data/apps/appdata/mysql/itech8eMacBook-Air-slow.log 也能够将慢查问日志放到table中,默认文件中SET Global log_output='TABLE' 3.全局查问日志 mysql> show variables like "general_log%";+------------------+-------------------------------------------------------------+| Variable_name | Value |+------------------+-------------------------------------------------------------+| general_log | OFF || general_log_file | /Users/itech8/data/apps/appdata/mysql/itech8deMacBook-Air.log |+------------------+-------------------------------------------------------------+2 rows in set (0.00 sec)开启全局日志mysql> set global general_log=on;Query OK, 0 rows affected (0.00 sec) 4.二进制日志/etc/my.conf下增加log-bin=mysql-bin-logbinlog_format=mixed max_bin_size:记录单个二进制文件的最大值:mysql-bin-log.00001 内容超过max_bin_size设置的最大值,产生一个新的二进制文件,后缀+1binlog_cache_size:事务未提交,所有未提交的二进制日志会被记录到一个缓存中,等该事务提交时间接将缓冲的二进制日志写入二进制文件中 用途:复制-故障复原-sql审计 sync_binlog=[n]示意每写缓冲多少次就同步到磁盘,sync_binlog=1示意同步磁盘的形式来实时写二进制文件,不必操作系统的缓冲,默认值是0 innodb_support_xa binlog_formatstreamant、raw、mixed pid文件mysql启动实例的时候会将本人的过程id写入文件mysql> show variables like "pid_file";+---------------+-------------------------------------------------------------------+| Variable_name | Value |+---------------+-------------------------------------------------------------------+| pid_file | /Users/itech8/data/apps/appdata/mysql/itech8deMacBook-Air.local.pid |+---------------+-------------------------------------------------------------------+1 row in set (0.00 sec) 套接字socket文件地位mysql> show variables like "socket";+---------------+-----------------+| Variable_name | Value |+---------------+-----------------+| socket | /tmp/mysql.sock |+---------------+-----------------+1 row in set (0.00 sec) 表构造和innodb存储引擎文件.frminnodb的表空间文件默认配置下会有一个初始大小10mb的ibdata1文件,能够用多个文件组成一个表空间,例如:ibdata1和ibdata2组成一个表空间,假如两个文件在不同磁盘上,磁盘负载被均匀因而能够进步数据库整体性能 若innodb_data_file_path:所有的表数据都会记录到该共享表空间中 若innodb_file_per_table:每个表都会产生一个独立的表空间,表名:.ibd,单个表默认大小是96kb,这些独自的表空间,仅存储该表的数据,索引,和插入缓冲Bitmap信息,其余信息还是放在默认共享表空间中 innodb的重做日志文件默认状况下,innodb存储引擎数据目录下都会有这两个文件ib_logfile0和ib_logfile1,这是innodb引擎的重做日志文件(redo log file) 每次存储引擎下至多有1个重做日志文件组,每个组下卖弄至多有2个重做日志文件,如默认的ib_logfile0和ib_logfile1,能够将不同的文件组放在不同的磁盘上,进步重做日志的高可用性, redo log file和回滚日志文件 undo log file 表 1.索引组织表如果创立表时候没有显示定义表主键,那么innodb会依据以下形式抉择或者创立主键a.首先判断表中是否有非空的惟一索引（union not null） 如果有,则该列为主键,当表中有多个非空惟一索引时候,innodb会抉择建表时候第一个定义的非空惟一索引为主键,留神,主键的抉择依据的是定义索引的程序,而不是建表时候列的程序CREATE TABLE `z` ( `a` int(11) NOT NULL, `b` int(11) DEFAULT NULL, `c` int(11) NOT NULL, `d` int(11) NOT NULL, UNIQUE KEY `b` (`b`), UNIQUE KEY `d` (`d`), UNIQUE KEY `c` (`c`)) ENGINE=InnoDB DEFAULT CHARSET=utf8; INSERT INTO `z` (`a`, `b`, `c`, `d`)VALUES (1, 1, 1, 1), (2, 2, 2, 2);能够看到主键是d 列 mysql> select _rowid,a,b,c,d from z;+--------+---+------+---+---+| _rowid | a | b | c | d |+--------+---+------+---+---+| 2 | 2 | 3 | 2 | 2 || 4 | 1 | 2 | 3 | 4 |+--------+---+------+---+---+2 rows in set (0.00 sec)b.如果不合乎上述条件,innodb会主动创立一个6字节大小的指针 innodb 逻辑存储构造 tablespce表空间又段,区,页组成 段:索引段-B+tree的非叶子节点, 数据段:B+tree的叶子节点,回滚段 区:间断页组成的空间,任何状况下,每个区的大小都为1MB,为保障去的连续性,innodb一次从磁盘申请4-5个区,默认innodb存储的引擎页大小是16kb,即一个区一共16个间断的页 页:是innodb磁盘治理最小的单位,默认每个页的大小是16kb,也能够通过参数innodb_page_size设置每页的大小是4k,8k,16k 常见的数据页类型:数据页,undo页,零碎页,事务数据页等等 行：innodb 是按行存放数据的,每页寄存的行记录最多容许寄存 16kb/2-200行记录,即7992行 索引和算法B+tree 索引不能找到一个给定键值的具体行,B+tree树索引能找到的常识被查找数据行所在的页,而后数据库通过把页读入内存中,再在内存中查找，失去要查找的数据 1,2,3,4,5,6,7,8,9,10 1.tinyint和Enum 2.索引和算法 二叉查找树->均衡二叉树->Btree->B+tree 二叉查找树:左子树的键值总是小于根的键值,右子树的键值总是大于根的键值2-3-6-7-8 6 / \ 3 7 / \ \2 5 8 插入新值9,为了保持平衡,须要旋转一次,有时候须要旋转屡次,因而保护一颗均衡二叉树须要开销的 6 / \ 3 7 / \ / \2 5 8 9 查找8 先找到根节点6 ,6小于8,因而查找右子树,须要查找3次,程序查找的话则须要6次定义:均衡二叉树(AVL)查找效率高,满足二叉树的定义外,而且任意节点的两个子树高度最大差为1 B+tree所有数据寄存在叶子节点上,并且是程序寄存的,如果用户从右边的叶子节点是程序遍历,能够失去所有键值的程序排序,叶子节点之间是个双向链表指针 B+tree 索引分为聚簇索引和辅助索引,其外部都是B+tree,高度均衡的,叶子节点存放数据,B+tree索引,外部其实是B+tree在mysql中的实现B+tree在数据库中是高扇出性,个别在DB中B+树的高度在2-3层左右。也就意味着只须要2-3次的IO操作即可。而当初的磁盘每秒差不多在100次IO左右，2-3次意味着查问工夫只需0.02-0.03秒。汇集索引,InnoDB存储引擎表是索引组织表，即表中数据装置主键程序寄存。而汇集索引就是依照每张表的主键结构一颗B+,并且叶节点寄存着整张表的行记录数据，因而也将汇集索引的叶子节点称为数据页。聚簇索引的这个个性也决定了索引组织表中的数据也是索引的一部分,同B理论的数据页只能依照一颗B+树进行排序，因而每张表只能领有一个汇集索引。 在很多状况下,查问优化器十分偏向于采纳汇集索引,因为汇集索引可能让咱们在索引的叶节点上间接找到数据。 数据库索引为啥不必b树:因为B树不论叶子节点还是非叶子节点,都会保留数据,这样导致在非叶子节点中能保留的指针数量变少（有些材料也称为扇出）指针少的状况下要保留大量数据,只能减少树的高度,导致IO操作变多,查问性能变低; 什么时候应用B+树索引个别的教训是对于拜访表中很少一部分行时，应用B+树索引才有意义。而对于像性别，地区，类型等字段，它们可取值的范畴很小（低选择性），个别不举荐应用B+树索引；【此时个别用什么索引呢？】反之，如果某个字段的取值范畴很广，简直没有反复（高选择性），则此时应用B+树索引是最合适的，例如email字段，在一些利用中通常都不容许反复呈现。因而，当拜访高选择性字段并从表中取出很少一部分行时，对这个字段增加B+树索引是十分有必要的。然而如果呈现了拜访字段是高选择性，然而取出的行数据占表中大部分的数据时，这时MySQL数据库就不会应用B+树索引了。 联结索引:对表上的多个列进行索引 笼罩索引:从辅助索引中就能够失去查问的记录,而不须要查问聚簇索引中的记录,应用笼罩索引的益处是辅助索引不蕴含整行记录的所有信息,所以其大小要小于笼罩索引,因而能够大量缩小IO操作 参考资料:1.MySQL索引背地的数据结构及算法原理http://blog.codinglabs.org/articles/theory-of-mysql-index.html

前言在记录这次线上问题之前，咱们先来回顾一些基础知识。 数据库系统的锁数据库系统应用锁是为了反对对共享资源进行拜访，提供数据的完整性和一致性。 锁类型InnoDB存储引擎中实现了如下两种规范的行级锁： 共享锁（S Lock），容许事务读一行数据排他锁（X Lock），容许事务删除或者更新一条数据如果一个事务t1曾经取得了行r的共享锁，那么另外的事务t2也能够立刻取得行r的共享锁。因为读取并没有扭转r行的数据，成为这种状况为锁兼容（Lock Compatible）。然而若有其余事务t3想取得行r的排他锁，则必须期待t1，t2开释行r上共享锁，这种状况被称为锁不兼容。 如果想要查问数据的最新版本，能够应用以后读。以后读须要加锁，能够加读锁（select...lock in share mode），也能够加写锁（select...for update）。

利用JAVA向Mysql插入一亿数量级数据—效率测评这几天钻研mysql优化中查问效率时，发现测试的数据太少（10万级别），利用 EXPLAIN 比拟不同的 SQL 语句，不可能失去比拟无效的测评数据，大多不置可否，不敢通过这些数据下定论。 所以通过随机生成人的姓名、年龄、性别、电话、email、地址 ，向mysql数据库大量插入数据，便于用大量的数据测试 SQL 语句优化效率。、在生成过程中发现应用不同的办法，效率天差万别。 1、先上Mysql数据库，随机生成的人员数据图。别离是ID、姓名、性别、年龄、Email、电话、住址。 下图一共三千三百万数据： 在数据量在亿级别时，别点上面按钮，会导致Navicat继续加载这亿级别的数据，导致电脑死机。~觉着本人电脑配置不错的能够去试试，可能会有惊喜 2、本次测评一共通过三种策略，五种状况，进行大批量数据插入测试 策略别离是： Mybatis 轻量级框架插入（无事务）采纳JDBC间接解决（开启事务、无事务）采纳JDBC批处理（开启事务、无事务）测试后果： Mybatis轻量级插入 -> JDBC间接解决 -> JDBC 批处理。JDBC 批处理，效率最高第一种策略测试：2.1 Mybatis 轻量级框架插入（无事务）Mybatis是一个轻量级框架，它比hibernate轻便、效率高。 然而解决大批量的数据插入操作时，须要过程中实现一个ORM的转换，本次测试存在实例，以及未开启事务，导致mybatis效率很个别。 这里试验内容是： 利用Spring框架生成mapper实例、创立人物实例对象循环更改该实例对象属性、并插入。//代码内无事务 private long begin = 33112001;//起始id private long end = begin+100000;//每次循环插入的数据量 private String url = "jdbc:mysql://localhost:3306/bigdata?useServerPrepStmts=false&rewriteBatchedStatements=true&useUnicode=true&amp;characterEncoding=UTF-8"; private String user = "root"; private String password = "0203"; @org.junit.Test public void insertBigData2() { //加载Spring，以及失去PersonMapper实例对象。这里创立的工夫并不对最初后果产生很大的影响 ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml"); PersonMapper pMapper = (PersonMapper) context.getBean("personMapper"); //创立一个人实例 Person person = new Person(); //计开始工夫 long bTime = System.currentTimeMillis(); //开始循环，循环次数500W次。 for(int i=0;i<5000000;i++) { //为person赋值 person.setId(i); person.setName(RandomValue.getChineseName()); person.setSex(RandomValue.name_sex); person.setAge(RandomValue.getNum(1, 100)); person.setEmail(RandomValue.getEmail(4,15)); person.setTel(RandomValue.getTel()); person.setAddress(RandomValue.getRoad()); //执行插入语句 pMapper.insert(person); begin++; } //计完结工夫 long eTime = System.currentTimeMillis(); System.out.println("插入500W条数据耗时："+(eTime-bTime)); }本想测试插入五百万条数据，然而理论运行过程中太慢，中途不得不终止程序。最初失去52W数据，大概耗时两首歌的工夫（7~9分钟）。随后，利用mybatis向mysql插入10000数据。 ...

宝塔配置 MySQL 队列调度执行以下操作前提前进入网站根目录，如 cd /www/wwwroot/xxx.com执行 artisan 命令前请参照 开发教程 → 开发应用问题 → 如何运行 php artisan xxx 命令① 生成数据库队列表迁徙文件 在执行该步骤前，请先查看迁徙文件 database/migrations/xxxx_xx_xx_xxxxxx_create_jobs_table.php 是否存在，如果已存在间接跳过第①步php artisan queue:tablephp artisan queue:failed-table这一步会生成数据库迁徙文件 database/migrations/xxxx_xx_xx_xxxxxx_create_jobs_table.php 和 database/migrations/xxxx_xx_xx_xxxxxx_create_failed_jobs_table.php② 执行数据库迁徙文件 php artisan migrate③ 批改配置文件 .env 配置队列驱动为数据库 QUEUE_DRIVER=databaseQUEUE_CONNECTION=database④ 运行队列过程测试运行 如果队列中有工作，以下命令会主动执行一个工作，查看是否报错，无报错示意配置胜利Laravel5 php artisan queue:work database --sleep=3 --tries=3Laravel9 php artisan queue:work database --once --sleep=3 --tries=3⑤ 配置过程守护插件 装置守护过程 supervisor 增加守护过程 启动命令：/usr/bin/php/www/wwwroot/xxx.com/artisan queue:listen database --sleep=3 --tries=3过程数量：能够依据零碎的并发数填写，能够默认填 1装置查看实现后查看确保过程状态为 已启动

前言大家好，我是xicheng。当初持续更新MySQL，本篇讲InnoDB的表空间，该部分类容比拟干燥繁琐，但又是MySQL后续内容的根底。所以大家能够先学习了解整体框架，等后续篇章用到的时候，再回过头查阅，进一步加深了解。另外，InnoDB的常识脑图如下所示，大家坐稳了。 表空间表空间（tablespace）由段（sagment）组成，段由区（extent）组成，区由页（page）组成，页由行组成。如下图所示。 所有数据都寄存在表空间中。如果用户手动启用了参数innodb_file_per_table，则每张表的数据能够独自放在一个表空间中。 段逻辑上的概念，⼀个索引会⽣成2个段，⼀个叶⼦节点段（寄存叶⼦节点的区），⼀个⾮叶⼦节点段（寄存⾮叶⼦节点的区）。 在刚开始向表中插⼊数据的时候，段是从某个碎⽚区（并不是所有页都是存储一个段的数据的区）以⻚为单位来调配存储空间的。 当某个段曾经占⽤了32个碎⽚区⻚⾯之后，就会以残缺的区为单位来调配存储空间（原先占用的碎片区的页不会被复制到新的区中来）。 常见的段由数据段，索引段，回滚段等。 区构造对于16KB的页，物理地位间断的64个页就是一个区（extend），大小1MB。256个区被划分为1个组。 每个组中第一个区的固定页如下图所示。 第一组中第0区开始的3个⻚的类型是固定的： FSP_HDR（16KB）：整个表空间的⼀些整体属性以及本组所有的区，整个表空间只有⼀个该类型的⻚⾯。IBUF_BITMAP（16KB）：本组所有的区的所有⻚⾯对于INSERT BUFFER的信息。INODE（16KB）：存储了许多 INODE 的数据结构。其余各组最开始的 2 个⻚⾯的类型是固定的： XDES （ extent descriptor）：本组 256 个区的属性。IBUF_BITMAP：存储本组所有的区的所有⻚⾯对于 INSERT BUFFER 的信息。在表中数据量⼤的时候，为某个索引调配空间的时候就不再依照⻚为单位调配了，⽽是依照区为单位调配。区分类闲暇的区：FREE，还没有⽤到这个区中的任何⻚⾯。 有残余空间的碎⽚区：FREE_FRAG，示意碎⽚区中还有可⽤的⻚⾯。 没有残余空间的碎⽚区：FULL_FRAG，示意碎⽚区中的所有⻚⾯都被使⽤，没有闲暇⻚⾯。 从属于某个段的区：FSEG。 区的XDES Entry构造 为了不便管理区而设计的。共40个字节，分为4个局部。 SegmentID（8字节）：段惟一编号，示意就是该区所在的段（前提是该区已被调配给某段了，否则该字段无意义）。ListNode（12字节）：PreNodePageNumber（4字节，前一页的页号）和PreNodeOffset（2字节，前一页的页号在页内的偏移量）指向前⼀个XDESEntry。NextNodePageNumber（4字节，后一页的页号）和NextNodeOffset（2字节，后一页的页号在页内的偏移量）指向后⼀个XDESEntry。State：区的状态。参见“InnoDB表空间-区分类”条目。PageStateBitmap：128个⽐特位。每2个⽐特位对应区中的⼀个⻚。第⼀个位示意对应的⻚是否是闲暇的（1闲暇。0不闲暇），第⼆个⽐特位还没有⽤（1没用。0用了）。XDES Entry链表 通过List Node把FREE区对应的XDES Entry链接成一个链表，叫FREE链表。同一段中所有页面是闲暇的区的XDES Entry会被加到这个链表。 通过List Node把FREE_FRAG区对应的XDES Entry链接成一个链表，叫FREE_FRAG链表。同一段中还有闲暇页面区的XDES Entry会被加到这个链表。 通过List Node把FULL_FRAG区对应的XDES Entry链接成一个链表，叫FREE_FRAG链表。同一段中没有闲暇页面区的XDES Entry会被加到这个链表。 每个XDES Entry链表会有一个List Base Node节点，会被放在段的INODE Entry。其中。 ListLength：该链表总节点数。FirstNodePageNumber和FirstNodeOffset：该链表的头节点在表空间中的地位。LastNodePageNumber和LastNodeOffset：该链表的尾节点在表空间中的地位。段的INODE Entry 为了方便管理段而设计的。共192字节，被分为如下几个局部。 Segment ID（8字节）：该INODE Entry对应的段号。NOT_FULL_N_USED（4字节）：NOT_FULL链表的各XDES Entry节点对应的区曾经使⽤了多少⻚⾯。⼀个区中有64个⻚⾯，如果不标记曾经使⽤了多少⻚⾯的话，每次向段中插⼊数据的时候都要从第⼀个⻚⾯进⾏遍历寻找闲暇⻚⾯，有了这个字段之后就能够疾速定位闲暇⻚⾯。3个List Base Node（别离都为16字节）：别离为段的FREE链表、NOT_FULL链表、FULL链表定义了ListBaseNode。Magic Number：标记这个INODE Entry是否曾经被初始化了（值是97937874，表明曾经初始化，否则没有被初始化）。Fragment Array Entry：段是由零散的页面和残缺的区组成。每个Fragment Array Entry构造都对应着⼀个零散的⻚⾯，这个构造⼀共4个字节，示意⼀个零散⻚⾯的⻚号。页类型FSP_HDR类型表空间的第一个页面，也是第一个组的第一个页面，页号为0，存储表空间的整体属性及第一个组内内256区对应的XDES Entry构造。如下表所示。 名称形容占用空间（字节）作用File Header⽂件头部38页的通用信息File Space Header表空间头部112表空间的⼀些整体属性信息XDES Entry区形容信息10240存储本组256个区对应的属性信息Empty Space尚未使⽤ 空间5986⻚构造的填充File Trailer⽂件尾部8校验⻚是否残缺File Space Header如下表所示。 ...

作者：姚嵩 外星人... 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 摘抄：https://dev.mysql.com/doc/ref... https://dev.mysql.com/doc/ref... https://dev.mysql.com/doc/ref... https://dev.mysql.com/doc/ref... https://dev.mysql.com/doc/ref... 背景：客户反馈查问返回的后果不合乎预期，读取时想要实现⼤⼩写辨别； 简介：排序规定 collation 是⼀个字符集的字符进⾏⽐较的⼀组规定； ⾄少会有两个规定： 1) 是否辨别⼤⼩写； 2) 编码； 常⽤的规定是是否辨别⼤⼩写。 字符集和排序规定的默认抉择： 如果你仅指定字符集，⽽不指定排序规定，则排序规定为字符集默认的排序规定； 如果你仅指定排序规定，不指定字符集，则字符集为排序规定对应的字符集； 例外项⻅： "设置对象的字符集和排序规定" 中 "阐明"列中蕴含的内容。 查看字符集与其默认的排序规定： SHOW CHARACTER SET ; 或者 select * from INFORMATION_SCHEMA.CHARACTER_SETS ; 查看字符集蕴含的排序规定： SHOW COLLATION WHERE Charset = 'utf8mb4'; -- 这⾥的utf8mb4是具体的字符集 查看数据库的默认字符集和排序规定： USE db_name; SELECT @@character_set_database, @@collation_database; 或者 SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME = 'db_name'; 设置对象的字符集和排序规定： 对象字符集排序规定阐明servercharacter_set_servercollation_server如果create database时未带上字符集和排序规定，则使⽤server中申明的作为默认值；database建库时的CHARACTER SET ⼦句；character_set_database建库时的COLLATE ⼦句；collation_database如果create table时未带上字符集和排序规定，则使⽤数据库中申明的作为默认值；如果load data时未带上character set⼦句，则使⽤character_set_database作为默认值；如果在创立routine时未带上字符集和排序规定，则使⽤数据库中申明的作为默认值；table建表时的CHARACTER SET ⼦句；建表时的COLLATE ⼦句；如果未在单个列上指定字符集和排序规定，则将表中申明的作为默认值；column建表时字段定义上的CHARACTER SET ⼦句；建表时字段定义上的 COLLATE ⼦句； 字符串SELECT _utf8mb4'abc' ;SELECT 'abc' COLLATE utf8_general_ci;如果未指定字符集但指定了排序规定，则字符集使⽤ character_set_connection；如果未指定字符集和排序规定，则使⽤character_set_connection和collation_connection作为默认值；阐明：如果客户是查问表中的数据，那么寻找数据时是否疏忽⼤⼩写，取决于对应字段上的COLLATE⼦句中定义的排序规定； ...

作者：杨奇龙 网名“北在北方”，资深 DBA，次要负责数据库架构设计和运维平台开发工作，善于数据库性能调优、故障诊断。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 一、前言提到 limit 优化，大多数 MySQL DBA 都不会生疏，能想到各种应答策略，比方提早关联，书签式查问等等，之前我也写过一篇优化的文章：https://mp.weixin.qq.com/s/2n... ，有趣味的敌人能够温习一下。 二、MySQL 8.0 对limit 的改良对于 limit N 带有 group by ，order by 的 SQL 语句 (order by 和 group by 的字段有索引能够应用)，MySQL 优化器会尽可能抉择利用现有索引的有序性，缩小排序--这看起来是 SQL 的执行打算的最优解，然而实际上成果其实是背道而驰，置信很多 DBA 遇到的相干案例中 sql 执行打算抉择 order by id 的索引进而导致全表扫描，而不是利用 where 条件中的索引查找过滤数据。MySQL 8.0.21 版本之前，并没有什么参数来管制这种行为，然而自 MySQL 8.0.21 之后提供一个优化器参数 prefer_ordering_index ，通过设置 optimizer_switch 来开启或者敞开该个性 。 比方: SET optimizer_switch = "prefer_ordering_index=off";SET optimizer_switch = "prefer_ordering_index=on";三、实际出真知测试环境 MySQL 社区版 8.0.30 结构测试数据 CREATE TABLE t (id1 BIGINT NOT NULL PRIMARY KEY auto_increment, id2 BIGINT NOT NULL,c1 VARCHAR(50) NOT NULL,c2 varchar(50) not null,INDEX i (id2, c1));insert into t(id2,c1,c2) values(1,'a','xfvs'),(2,'bbbb','xfvs'),(3,'cdddd','xfvs'),(4,'dfdf','xfvs'),(12,'bbbb','xfvs'),(23,'cdddd','xfvs'),(14,'dfdf','xfvs'),(11,'bbbb','xfvs'),(13,'cdddd','xfvs'),(44,'dfdf','xfvs'),(31,'bbbb','xfvs'),(33,'cdddd','xfvs'),(34,'dfdf','xfvs');3.1 默认开启参数mysql (test) > SELECT @@optimizer_switch LIKE '%prefer_ordering_index=on%';+------------------------------------------------------+| @@optimizer_switch LIKE '%prefer_ordering_index=on%' |+------------------------------------------------------+| 1 |+------------------------------------------------------+1 row in set (0.00 sec)查问非索引字段 ，id2 上有索引 ，order by 主键 id1 ，explain 查看执行打算 type index 阐明应用索引扫描应用 using where 过滤后果集。这个是优化器的自认为的最优抉择，然而实际上遇到数据汇合比拟大的表，该执行打算就不是最优解，反而导致慢查。 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。本文起源：社区原创投稿；作者：王庆勋。客户的一些利用零碎应用的JDK1.7版本，在将数据库迁徙到MySQL8.0的过程中，发现有些MySQL connector/J的版本无奈连贯到MySQL8.0。本文形容了在Linux JDK1.7环境下，测试不同版本Connector/J的办法，也可用于为MySQL接口的国产数据库产品抉择Connector/J版本。 MySQL Connector/J阐明MySQL通过MySQL Connector/J为用Java语言开发的客户端应用程序提供连贯，MySQL Connector/J是一个实现Java数据库连贯(JDBC) API的驱动程序。 MySQL Connector/J是一个JDBC 4型驱动程序。Type 4标记意味着驱动程序是MySQL协定的纯Java实现，不依赖于MySQL客户端库。 MySQL Connector/J有两个版本: Connector/J 5.1是第4类纯Java JDBC驱动程序，合乎JDBC 3.0、4.0、4.1和4.2标准。它提供了与MySQL所有性能的兼容性，包含5.6、5.7和8.0。Connector/J 5.1提供了易于开发的个性，包含向驱动程序管理器主动注册、标准化的有效性查看、分类的SQLExceptions、对大量更新计数的反对、对java.time包的本地和偏移日期工夫变量的反对、对JDBC-4.x XML解决的反对、对每个连贯客户端信息的反对以及对NCHAR、NVARCHAR和NCLOB数据类型的反对。Connector/J 8.0是用于Java 8平台的第4类纯Java JDBC 4.2驱动程序。它提供了兼容MySQL 5.6、5.7和8.0的所有性能。强烈推荐MySQL连接器/J 8.0与MySQL服务器8.0、5.7和5.6一起应用。请降级到MySQL连接器/J 8.0。Connector/J不同版本的JDBC、MySQL Server和Java的信息: Connector/J 版本Driver Type实现的 JDBC 版本MySQLServer 版本反对的 JRE版本5.143.0, 4.0, 4.1, 4.25.6, 5.7, 8.01.5.x, 1.6.x, 1.7.x, 1.8.x8.044.25.6, 5.7, 8.01.8.x可知，要反对JRE1.7版本，需选用连接器Connector/J的版本为5.1 ，而5.1的最新版本为5.1.49 。 测试Connector/J 5.1的不同版本装置配置jdk1.7查看以后jdk版本[[email protected] ~]# java -versionjava version "1.8.0_111"Java(TM) SE Runtime Environment (build 1.8.0_111-b14)Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode)[[email protected] ~]# javac -versionjavac 1.8.0_111装置jdk1.7yum install -y java-1.7.0-openjdk.x86_64 java-1.7.0-openjdk-devel.x86_64批改JAVA_HOME批改/etc/profile文件:export JAVA_HOME=/usr/lib/jdk1.8.0_111改为：export JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.261-2.6.22.2.el7_8.x86_64 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。本文起源：原创投稿；作者：YeJinrong/叶金荣测试效率晋升36% ~ 100%，相当可观本文目录 并行构建索引测试进一步提高索引构建效率并行构建索引的限度MySQL 8.0.31于2022.10.11公布了，比我预计的日期早了一周，先赞一个。 看了下 release notes ，新增的货色不算多，感觉MySQL官网对8.0版本曾经进入维稳的后半段了，英文不好的同学能够戳此查看 徐轶韬老师针对8.0.31做的疾速解读。另外，依据 徐老师的最新推文，也理解到MySQL针对8.0版本缩短了规范反对（Premier Support）时长，从原来的2023.4缩短到了2025.4，不过延长反对（Extended Support）的期限没有扭转，依然是2026.4。 本次公布的8.0.31新个性中，我留神到有一句不太起眼的阐明： InnoDB: InnoDB now supports parallel index builds, which improves index build performance. In particular, loading sorted index entries into a B-tree is now multithreaded. Previously, this action was performed by a single thread.只有这么简略的一句，没更多扩大解释阐明。简言之，就是反对并行构建索引，晋升索引构建性能。 并行构建索引测试还是间接做个测试看看吧。 利用sysbench构建一个有400万行记录的测试表，只有一个主键索引时，表空间物理文件大小为1044381696 Bytes，增加完测试索引后，表空间物理文件大小涨到1434451968 Bytes，减少了37.35%。 mysql> CREATE TABLE `t1` ( `id` int NOT NULL AUTO_INCREMENT, `k` int NOT NULL DEFAULT '0', `c` char(120) NOT NULL DEFAULT '', `pad` char(60) NOT NULL DEFAULT '', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=latin1;mysql> select count(*) from t1;+----------+| count(*) |+----------+| 4000000 |+----------+1 row in set (0.35 sec)接下来，我别离针对GreatSQL 8.0.25-16、MySQL 8.0.31做重建索引的测试，每个数据库跑10次，计算其每次耗时，去掉最大最小偏差值，取剩下的8次求平均值。都先采纳默认设置，最初失去的后果如下表： ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。前文回顾实现一个简略的Database1(译文） 实现一个简略的Database2(译文） 实现一个简略的Database3(译文） 实现一个简略的Database4(译文） 译注：cstsck在github保护了一个简略的、相似SQLite的数据库实现，通过这个简略的我的项目，能够很好的了解数据库是如何运行的。本文是第五篇，次要是实现数据长久化 Part 5 长久化到磁盘“Nothing in the world can take the place of persistence.” – Calvin Coolidge(美国第30任总统) 咱们数据库能让你插入数据并读取进去，然而只能在程序始终运行的时候才能够。如果你kill掉程序后再次重启当前，你所有的数据就失落了。 咱们冀望的行为是这样的，上面是一个spec测试： it 'keeps data after closing connection' do result1 = run_script([ "insert 1 user1 [email protected]", ".exit", ]) expect(result1).to match_array([ "db > Executed.", "db > ", ]) result2 = run_script([ "select", ".exit", ]) expect(result2).to match_array([ "db > (1, user1, [email protected])", "Executed.", "db > ", ])end像SQLite一样，咱们会把数据长久化，保留整个数据库到一个繁多的文件中。 咱们曾经实现了将行序列化为页面大小的内存块。为数据库减少长久化的性能，咱们能够简略的把这些内存中的块（blocks）写入到文件，在下次程序启动时，再把这些数据块读取到内存。 为了让实现更简略点，咱们创立了一个叫做pager的形象。咱们向pager申请的数据页page号为x（page number x），而后pager会返给咱们一个内存块。申请会首先查看内存中的数据，如果内存中没有（缓存未命中，cache miss），pager就会从磁盘上拷贝数据到内存中（通过读取数据库文件）。 ...

具体更新一条记录 UPDATE t_user SET name = 'xiaolin' WHERE id = 1; 的流程如下: 执行器负责具体执行，会调用存储引擎的接口，通过主键索引树搜寻获取 id = 1 这一行记录： 如果 id=1 这一行所在的数据页原本就在 buffer pool 中，就间接返回给执行器更新；如果记录不在 buffer pool，将数据页从磁盘读入到 buffer pool，返回记录给执行器。执行器失去聚簇索引记录后，会看一下更新前的记录和更新后的记录是否一样： 如果一样的话就不进行后续更新流程；如果不一样的话就把更新前的记录和更新后的记录都当作参数传给 InnoDB 层，让 InnoDB 真正的执行更新记录的操作；开启事务， InnoDB 层更新记录前，首先要记录相应的 undo log，因为这是更新操作，须要把被更新的列的旧值记下来，也就是要生成一条 undo log，undo log 会写入 Buffer Pool 中的 Undo 页面，不过在内存批改该 Undo 页面后，须要记录对应的 redo log。InnoDB 层开始更新记录，会先更新内存（同时标记为脏页），而后将记录写到 redo log 外面，这个时候更新就算实现了。为了缩小磁盘I/O，不会立刻将脏页写入磁盘，后续由后盾线程抉择一个适合的机会将脏页写入到磁盘。这就是 WAL 技术，MySQL 的写操作并不是立即写到磁盘上，而是先写 redo 日志，而后在适合的工夫再将批改的行数据写到磁盘上。至此，一条记录更新完了。在一条更新语句执行实现后，而后开始记录该语句对应的 binlog，此时记录的 binlog 会被保留到 binlog cache，并没有刷新到硬盘上的 binlog 文件，在事务提交时才会对立将该事务运行过程中的所有 binlog 刷新到硬盘。事务提交，剩下的就是「两阶段提交」的事件了，接下来就讲这个。

一、先理解一下MySQL查问的执行过程MySQL在查问时，它是由很多子工作组成的，每个子工作都会耗费肯定的工夫，如果要想优化查问，实际上要优化其子工作，能够打消一些子工作、缩小子工作的执行次数、让子工作执行的更快。 MySQL查问的执行过程：从客户端到服务器、而后在服务器进行解析、生成执行打算、执行、返回后果给客户端。 执行是最重要的阶段，包含调用存储引擎检索数据、调用后的数据处理、排序、分组等； 查问须要在不同的中央破费工夫，包含网络、CPU计算、生成统计信息、生成执行打算、锁期待等，尤其是向底层存储引擎检索数据的调用操作，这些调用须要在内存操作、CPU操作和内存不足时导致的IO操作上破费工夫。依据存储引擎不同，可能还会产生大量的上下文切换以及零碎调用。 不必要的额定操作、不必要的反复操作、某些操作执行的太慢都是查问慢的起因，优化查问的目标就是缩小和打消这些操作所破费的工夫。 二、是否查问了不须要的数据有些查问会查问很多不须要的数据，查问之后，程序中并未应用，这样岂但会给MySQL服务器带来额定的累赘，还会减少网络开销，也会耗费应用服务器的CPU和内存资源，简而言之，吃多少拿多少。 千万不要有“把数据都查出来，用Java代码过滤”的想法。 禁止应用select * 进行查问。 三、掂量查问开销的几个重要指标1、响应工夫响应工夫能够分为服务工夫和排序工夫。 服务工夫指数据库解决这个查问真正破费的工夫；排队工夫指服务器因为期待某些资源而没有真正执行查问的工夫，比方期待IO操作、期待行锁。2、扫描的行数和返回的行数较短的行的访问速度更快，内存中的行比磁盘中的行的访问速度要快得多。 现实状况下扫描的行数和返回的行数是雷同的。但这种状况并不多见，比方关联查问的时候，服务器必须扫描更多的行能力失去后果，因而，越多的表关联，性能越低。 3、扫描的行数和拜访类型MySQL能够通过多种形式查问并返回后果集，速度从慢到快，扫描的行数由多到少，顺次为全表扫描、索引扫描、范畴扫描、惟一索引扫描、常数援用。 最罕用的优化形式是为查问减少一个适合的索引，索引能够让MySQL以最高效、扫描行数起码的形式找到须要的记录。 4、个别能够通过explain的Extra列查看查问的优劣个别MySQL可能应用以下三种形式利用where条件，从好到坏顺次为： 在索引中应用where条件过滤不匹配的记录，这是在存储引擎层实现的；应用索引笼罩扫描，也就是Extra中呈现Using index，间接从索引中过滤不须要的记录并返回命中的后果，这是在MySQL服务器层实现的，无须再回表查问记录；Extra中呈现Using where，这是在MySQL服务器层实现的，MySQL须要先从数据表读取记录，而后过滤。Extra中呈现Using where时，能够通过如下形式优化： 应用索引笼罩扫描，把所有须要的列都放到索引中，这样就不必回表查问了；扭转表构造，比方应用汇总表；重写sql，让MySQL优化器可能以更优化的形式执行这个sql；

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。文章导读： 什么是Undo Log？Undo:意为撤销或勾销，以撤销操作为目标，返回某个状态的操作。 Undo Log:数据库事务开始之前，会将要批改的记录放到Undo日志里，当事务回滚时或者数据库解体时，能够利用UndoLog撤销未提交事务对数据库产生的影响。 Undo Log是事务原子性的保障。在事务中更新数据的前置操作其实是要先写入一个Undo Log 如何了解Undo Log事务须要保障原子性，也就是事务中的操作要么全副实现，要么什么也不做。但有时候事务执行到一半会呈现一些状况，比方： 状况一：事务执行过程中可能遇到各种谬误，比方服务器自身的谬误，操作系统谬误，甚至是忽然断电导致的谬误。状况二：DBA能够在事务执行过程中手动输出ROLLBACK语句完结以后事务的执行。以上状况呈现，咱们须要把数据改回原先的样子，这个过程称之为回滚。每当咱们要对一条记录做改变时(这里的改变能够指INSERT、DELETE、UPDATE)，都须要"留一手"——把回滚时所需的货色记下来。比方: 你插入一条记录时，至多要把这条记录的主键值记下来，之后回滚的时候只须要把这个主键值对应的记录删掉就好了。(对于每个INSERT, InnoDB存储引擎会实现一个DELETE)你删除了一条记录，至多要把这条记录中的内容都记下来，这样之后回滚时再把由这些内容组成的记录插入到表中就好了。(对于每个DELETE,InnoDB存储引擎会执行一个INSERT)你批改了一条记录，至多要把批改这条记录前的旧值都记录下来，这样之后回滚时再把这条记录更新为旧值就好了。(对于每个UPDATE，InnoDB存储引擎会执行一个相同的UPDATE，将批改前的行放回去)MySQL把这些为了回滚而记录的这些内容称之为撤销日志或者回滚日志(即Undo Log)。留神，因为查问操作(SELECT）并不会批改任何用户记录，所以在杳询操作行时，并不需要记录相应的Undo日志 此外，Undo Log会产生Redo Log，也就是Undo Log的产生会随同着Redo Log的产生，这是因为Undo Log也须要持久性的爱护。 Undo Log的性能提供数据回滚-原子性当事务回滚时或者数据库解体时，能够利用Undo Log来进行数据回滚。多个行版本控制(MVCC)-隔离性即在InnoDB存储引擎中MVCC的实现是通过Undo来实现。当用户读取一行记录时，若该记录曾经被其余事务占用，以后事务能够通过Undo读取之前的行版本信息，以此实现非锁定读取。Undo Log的存储构造回滚段与undo页InnoDB对Undo Log的治理采纳段的形式，也就是回滚段（rollback segment）。每个回滚段记录了1024个Undo Log segment，而在每个Undo Log segment段中进行Undo页的申请。 在InnoDB1.1版本之前（不包含1.1版本），只有一个rollback segment，因而反对同时在线的事务限度为1024。尽管对绝大多数的利用来说都曾经够用。 从1.1版本开始InnoDB反对最大128个rollback segment，故其反对同时在线的事务限度进步到了128*1024。 mysql> show variables like 'innodb_undo_logs';+------------------+-------+| Variable_name | Value |+------------------+-------+| innodb_undo_logs | 128 |+------------------+-------+尽管InnoDB1.1版本反对了128个rollback segment，然而这些rollback segment都存储于共享表空间ibdata中。从lnnoDB1.2版本开始，可通过参数对rollback segment做进一步的设置。这些参数包含: innodb_undo_directory:设置rollback segment文件所在的门路。这意味着rollback segment能够寄存在共享表空间以外的地位，即能够设置为独立表空间。该参数的默认值为“./”，示意以后InnoDB存储引擎的目录。 innodb_undo_logs:设置rollback segment的个数，默认值为128。在InnoDB1.2版本中，该参数用来替换之前版本的参数innodb_rollback_segments。 innodb_undo_tablespaces:设置形成rollback segment文件的数量，这样rollback segment能够较为均匀地散布在多个文件中。设置该参数后，会在门路innodb_undo_directory看到undo为前缀的文件，该文件就代表rollback segment文件。 回滚段与事务1.每个事务只会应用一个回滚段（rollback segment），一个回滚段在同一时刻可能会服务于多个事务。 2.当一个事务开始的时候，会制订一个回滚段，在事务进行的过程中，当数据被批改时，原始的数据会被复制到回滚段。 3.在回滚段中，事务会一直填充盘区，直到事务完结或所有的空间被用完。如果以后的盘区不够用，事务会在段中申请扩大下一个盘区，如果所有已调配的盘区都被用完，事务会笼罩最后的盘区或者在回滚段容许的状况下扩大新的盘区来应用。 4.回滚段存在于Undo表空间中，在数据库中能够存在多个Undo表空间，但同一时刻只能应用一个Undo表空间。 5.当事务提交时，InnoDB存储引擎会做以下两件事件：1.将Undo Log放入列表中，以供之后的purge(荡涤、革除)操作2.判断Undo Log所在的页是否能够重用(低于3/4能够重用)，若能够调配给下个事务应用 回滚段中的数据分类未提交的回滚数据(uncommitted undo information)：该数据所关联的事务并未提交，用于实现读一致性，所以该数据不能被其余事务的数据笼罩。 ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 MySQL 8.0 最新小版本（8.0.31）反对规范SQL 的intersect（交加）和except（差集）操作。 交加： 也就是返回两个后果集的相交局部，也即左侧和右侧同时存在的记录。 差集：也就是返回两个后果集中左侧存在同时右侧不存在的记录。 之前在做其余数据库往MySQL迁徙的时候，常常遇到这样的操作。因为MySQL 始终以来不反对这两类操作符，个别得想方法避开或者是通过其余办法来实现。 比方在MySQL 5.7.x 中，想要实现如下两个需要： 第一、求表t1和表t2的交加，并且后果要去重； 第二、求表t1和表t2的差集，并且后果也要去重。 简略创立表t1、表t2，并且插入几条样例数据： <mysql:5.7.34:(ytt)> create table t1(c1 int);Query OK, 0 rows affected (0.02 sec)<mysql:5.7.34:(ytt)> create table t2 like t1;Query OK, 0 rows affected (0.02 sec)<mysql:5.7.34:(ytt)> insert t1 values (10),(20),(20),(30),(40),(40),(50);Query OK, 7 rows affected (0.00 sec)Records: 7 Duplicates: 0 Warnings: 0<mysql:5.7.34:(ytt)> insert t2 values (10),(30),(30),(50),(50),(70),(90);Query OK, 7 rows affected (0.02 sec)Records: 7 Duplicates: 0 Warnings: 0 <mysql:5.7.34:(ytt)> select * from t1;+------+| c1 |+------+| 10 || 20 || 20 || 30 || 40 || 40 || 50 |+------+7 rows in set (0.00 sec)<mysql:5.7.34:(ytt)> select * from t2;+------+| c1 |+------+| 10 || 30 || 30 || 50 || 50 || 70 || 90 |+------+7 rows in set (0.00 sec)咱们来实现这两个需要： ...

1 MySQL 锁简介1.1 什么是锁锁是计算机用以协调多个过程间并发拜访同一共享资源的一种机制。MySQL中为了保证数据拜访的一致性与有效性等性能，实现了锁机制，MySQL中的锁是在服务器层或者存储引擎层实现的。 1.2 锁用来解决什么问题锁是用来解决并发事务的拜访问题，咱们曾经晓得事务并发执行时可能带来的各种问题，最大的一个难点是：一方面要最大水平地利用数据库的并发拜访，另外一方面还要确保每个用户能以统一的形式读取和批改数据，尤其是一个事务进行读取操作，另一个同时进行改变操作的状况下。 一个事务进行读取操作，另一个进行改变操作,咱们前边说过，这种状况下可能产生脏读、不可反复读、幻读的问题。 怎么解决脏读、不可反复读、幻读这些问题呢？其实有两种可选的解决方案： 计划一：读操作MVCC，写操作进行加锁 该计划性能较好，但可能会读到旧版本记录 计划二：读写操作都加锁 该计划性能个别，然而每次都能够读取到最新的记录，比方在银行场景中，对安全性要求十分高 2 锁的分类MySQL 中锁有很多，依照模式、粒度等能够分为如下几种类型 3 乐观乐观锁3.1 乐观锁1、概念 乐观锁，顾名思义，就是十分乐观，乐观锁认为数据个别状况下不会造成抵触，所以在数据提交更新的时候才会去检测。 2、实现 乐观锁是根本版本号机制实现的，数据表中减少一个 version 字段，读取数据时将 version 一起读出。数据每更新一次，version 字段值 + 1。当批改须要提交时，将读取时的版本号与数据库以后版本号做比拟，如果统一，阐明在此期间无人批改这条记录，不统一则阐明曾经被批改了，提交失败。 3、实用场景 乐观锁实用于读操作多，写操作少的场景 3.2 乐观锁1、概念 乐观锁是相比拟乐观锁而言的，就是比拟乐观，乐观锁认为数据每次操作都会被批改，所以在每次操作数据时都会加上锁。 2、实现 乐观锁通过共享锁和排他锁实现（上面会讲到这两种锁） 3、实用场景 实用于并发量不大，写操作多，读操作少的场景 4 共享排他锁4.1 共享锁1、概念 共享锁，又称读锁，简称 S 锁。当事务对数据加上读锁后，其余事务只能对该数据加读锁，不能加写锁。 2、实现 共享锁加锁办法：select …lock in share mode 4.2 排他锁1、概念 排他锁，又称为写锁，简称 X 锁，当事务对数据加上排他锁后，其余事务无奈对该数据进行查问或者批改 MySQL InnoDB引擎默认 update，delete，insert 都会主动给波及到的数据加上排他锁，select 语句默认不会加任何锁类型。 2、实现 排他锁加锁形式：select …for update 5 粒度锁5.1 全局锁1、概念 ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。一、MySQL的dd表介绍 二、代码跟踪 三、常识利用 四、总结 一、MySQL的dd表介绍MySQL的dd表是用来寄存表构造和各种建表信息的，客户端建的表都存在mysql.table和mysql.columns表里，还有一个表mysql.column_type_elements比拟非凡，用来寄存SET和ENUM类型的字段汇合值信息。看一下上面这张表的mysql.columns表和mysql.column_type_elements信息。为了缩短显示长度，这里只展现几个重要的值。 #建表：CREATE TABLE t1(id int not null auto_increment primary key,col1 number,col2 VARCHAR(100),col3 pls_integer,col4 enum('x','y') default 'x',col5 set('x1','y1')) partition by hash(id) partitions 3;SET SESSION debug='+d,skip_dd_table_access_check';mysql> select name,ordinal_position,type,default_value_utf8,options,column_type_utf8 from mysql.columns where table_id=383;+-------------+------------------+-----------------------+--------------------+-------------------+------------------+| name | ordinal_position | type | default_value_utf8 | options | column_type_utf8 |+-------------+------------------+-----------------------+--------------------+-------------------+------------------+| col1 | 2 | MYSQL_TYPE_NEWDECIMAL | NULL | interval_count=0; | decimal(65,0) || col2 | 3 | MYSQL_TYPE_VARCHAR | NULL | interval_count=0; | varchar(100) || col3 | 4 | MYSQL_TYPE_LONG | NULL | interval_count=0; | int || col4 | 5 | MYSQL_TYPE_ENUM | x | interval_count=2; | enum('x','y') || col5 | 6 | MYSQL_TYPE_SET | NULL | interval_count=2; | set('x1','y1') || DB_ROLL_PTR | 8 | MYSQL_TYPE_LONGLONG | NULL | NULL | || DB_TRX_ID | 7 | MYSQL_TYPE_INT24 | NULL | NULL | || id | 1 | MYSQL_TYPE_LONG | NULL | interval_count=0; | int |+-------------+------------------+-----------------------+--------------------+-------------------+------------------+8 rows in set (0.00 sec)mysql.columns表阐明如下： ...

MacBook装置MysqlMysql官网下载地址: https://dev.mysql.com/downloa... 官网下载 MySQL Community Server 社区版抉择对应的版本和零碎下载: mysql-5.7.22-macos10.13-x86_64.dmg 点击装置 留神装置过程会弹出 明码 须要记住明码在设置里最上面找到mysql 关上后启动，这里我把开机主动启动给去掉了 #Mysql命令增加到环境变量里vim ~/.zshrc #最初退出 export MYSQL_HOME=/usr/local/mysqlexport PATH=$MYSQL_HOME/bin:$PATH#使配置失效 source ~/.zshrc#查看mysql版本mysql —version#批改明码mysql -u root -p#输出之前保留的明码#设置新密码 如:123456SET PASSWORD FOR 'root'@'localhost'=PASSWORD('123456');#设置近程连贯受权grant all privileges on *.* to 'root'@'%' identified by '123456';flush privileges;#批改mysql配置 查看编码show variables like '%char%';#新版本的mysql 装置目录下没有默认配置文件了 /usr/local/mysql/support-files 能够从其余中央复制一份过去mysql配置文件sudo vim /etc/my.cnf#查看配置cat my.cnf# For advice on how to change settings please see# http://dev.mysql.com/doc/refman/5.7/en/server-configuration-defaults.html# *** DO NOT EDIT THIS FILE. It's a template which will be copied to the# *** default location during install, and will be replaced if you# *** upgrade to a newer version of MySQL.[client]default-character-set = utf8mb4[mysql]default-character-set = utf8mb4[mysqld]character-set-client-handshake = FALSEcharacter-set-server = utf8mb4collation-server = utf8mb4_unicode_ciinit_connect='SET NAMES utf8mb4'basedir = /data/soft/mysql-5.7.16datadir = /data/datas/mysql/data# Remove leading # and set to the amount of RAM for the most important data# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.# innodb_buffer_pool_size = 128M# Remove leading # to turn on a very important data integrity option: logging# changes to the binary log between backups.# log_bin# These are commonly set, remove the # and set as required.# basedir = .....# datadir = .....# port = .....# server_id = .....# socket = .....port = 3306server_id = 212binlog-ignore-db = mysql,sys,information_schema,performance_schemalog-bin = mysql-binmax_binlog_size = 500Mbinlog_cache_size = 2Mmax_binlog_cache_size = 4Mexpire_logs_days = 30max_connections = 500max_connect_errors = 10000table_open_cache = 256long_query_time = 1slow-query-logslow_query_log_file = /data/datas/mysql/data/slow_query_log_file.log# Remove leading # to set options mainly useful for reporting servers.# The server defaults are faster for transactions and fast SELECTs.# Adjust sizes as needed, experiment to find the optimal values.# join_buffer_size = 128M# sort_buffer_size = 2M# read_rnd_buffer_size = 2M sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES #timezone='UTC'#批改完后重启mysql服务#再次查看编码show variables like '%char%';

概述本文档领导和帮忙KunlunBase用户评测和验证KunlunBase的各项重要性能。用户遵循本文档操作即可装置好KunlunBase集群并且体验和应用到KunlunBase的各次要性能，把本文档作为应用KunlunBase 的疾速入门手册。KunlunBase的残缺的文档请拜访 doc.kunlunbase.com用户也可依据本文档来评测和验证KunlunBase各项性能工作失常。KunlunBase团队在进行KunlunBase产品研发过程中，会继续对其各项性能开发测试程序，并且应用自动化测试零碎每天运行所有测试程序，以便及时发现和解决问题，确保KunlunBase各项性能工作失常。同时，咱们会应用mysql和PostgreSQL 的测试集来针对 KunlunBase的存储节点和计算节点进行功能测试。对于KunlunBase的自动化测试零碎的日常测试后果，请拜访www.kunlunbase.com 查看。 KunlunBase 集群架构KunlunBase 是一个分布式关系数据库管理系统，面向TB和PB级别海量数据处理，反对高吞吐量和低延时的极致性能来解决海量数据的高并发读写申请。它反对程度弹性扩容，提供强壮的事务ACID保障，高效易用的分布式查询处理，高可扩展性，高可用性和通明的分库分表数据处理性能，业务层和终端用户无感知的程度扩大能力，是典型的 NewSQL分布式数据库系统。 KunlunBase的上述技术能力确保用户能够在业务持续增长时，随时不停服减少服务器节点来扩充数据存储和解决&计算能力，并且在服务器节点产生故障或者断电时，不失落数据，并且不进行数据读写服务。确保用户业务继续以最高品质运行。 应用软件开发者只须要依照应用单节点关系数据库雷同的办法应用昆仑数据库，就能够失去所有上述NewSQL数据库的长处，齐全不须要思考数据的存储和治理的任何细节。用户能够应用PostgreSQL和MySQL两种连贯协定连贯到KunlunBase集群的计算节点并执行DDL和DML SQL语句。KunlunBase反对规范SQL，PostgreSQL的DDL 语法，以及PostgreSQL和MySQL 的公有DML 语法。因而，本来应用PostgreSQL和MySQL的应用程序不须要批改就能够应用KunlunBase。 KunlunBase反对 所有SQL 数据分析性能，能够执行TPC-H 和TPC-DS的所有 OLAP 剖析SQL语句，因而，用户能够把各类业务零碎中的数据继续流入KunlunBase集群，并且应用KunlunBase 集群对这些继续更新的数据做OLAP 剖析和数据挖掘，以便迅速发现变动和趋势，抓住转瞬即逝的商机，及时应答突发状况，取得微小的竞争劣势。 即便用户的数据量只有若干GB，也能够应用KunlunBase而获益。KunlunBase的fullsync性能比MySQL 自带的semisync（半同步）和group replication具备更高的可靠性 --- 这两种技术如果主备节点同时断电那么用户数据可能失落或者不统一，而fullsync 确保这种状况下不会失落用户数据。此时只部署一个存储集群（例如 一主两备）即可。当用户数据和业务负载持续上升时，能够随时按需减少更多的存储集群和计算节点，从而扩充数据存储和查问能力。 同时，用户能够通过读写拆散扩大KunlunBase的解决能力。通过应用读写拆散技术从备机查问数据，并安顿专属的计算节点用于OLAP剖析查问，能够确保OLAP剖析工作齐全不会影响OLTP 业务的性能。 应用KunlunBase为KunlunBase 初始化服务器（BootStrap)通过初始化（bootstrap）的服务器才能够装置KunlunBase集群。初始化服务器实现后，用户就能够应用XPanel集群管理工具装置KunlunBase集群。 本节介绍如何初始化计算机服务器。 应用脚本初始化服务器下载脚本git clone https://gitee.com/zettadb/clo...cd cloudnative/cluster填写配置文件，具体参数阐明参考http://www.kunlunbase.com:818...填写完配置文件后，开始初始化服务器 python setup_cluster_manager.py --config=cluster_and_node_mgr.json --action=install bash -e clustermgr/install.sh创立KunlunBase集群以下操作皆须要在初始化服务器后进行 XPanel进入xpanel web端：http://host:17000/KunlunXPanel a. host就是下载docker镜像并运行的服务器对应ip，能够通过ifconfig查看 b. 示例中的17000就是在运行docker镜像时映射的商品 首次进入，账号和明码都是super_dba, 元数据节点用主的ip和端口就行 随后会须要批改明码，批改完明码后，进入到xpanel主界面 减少计算机列表 a. 查看须要减少的计算机是否存在列表中，不存在则进行该步骤，存在则跳过 b. 目前只能一个一个增加，该列表里的对应的服务器必须装置有node_mgr,且配置正确 c. 系统管理 -- 用户治理 -- 新增 -- 填写对应的参数 -- 确认 ...

作者：李锡超 一个爱笑的江苏苏宁银行 数据库工程师，次要负责数据库日常运维、自动化建设、DMP平台运维。善于MySQL、Python、Oracle，喜好骑行、钻研技术。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 1. 问题景象：9月15日，收到告警提醒测试环境某零碎的 MySQL MGR 集群存在异样。 日志内容如下： // 10.x.y.97 节点MySQL 谬误日志提醒节点 10.x.y.95 不可达：2022-09-15T19:26:14.320181+08:00 0 "Warning" "MY-011493" "Repl" Plugin group_replication reported: "Member with address 10.x.y.95:3306 has become unreachable." // 随后mgraliver(MGR 探针)日志提醒进行了切换："2022-09-15 19:26:16" : Exception: Invalid primary_member_ip: or secondary_node_list:""10.x.y.96", "10.x.y.97"" ."2022-09-15 19:26:16" : Exception: MGR is likely to be switching, Sleep 1 sec and continue ."2022-09-15 19:27:01" : Exception: MGR running with WARN. ONLINE nodes Pri:10.x.y.96 Sec:10.x.y.97 diff from conf_node:10.x.y.95,10.x.y.96,10.x.y.97 .即告警提醒利用零碎 MySQL MGR 产生了切换，由故障前的三节点 MGR 集群，切换为包含 Pri:10.x.y.96 Sec:10.x.y.97 两个节点集群。 ...

作者：王祥 爱可生 DBA 团队成员，次要负责 MySQL 故障解决和性能优化。对技术执着，为客户负责。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 背景最近在应用脚本新建了一批利用用户，发现一个奇怪的问题，有局部用户存下以下问题：利用应用该明码能失常拜访，但应用 mysql 客户端登录手动输出明码无奈登录。通过与失常用户比照发现存在登录异样的用户应用了特殊字符"$"。 问题复现在测试环境应用脚本生成一批用户 #新建用户脚本简化后如下#!/bin/bashpw="abc$2UY"mysql --login-path=root -e"create user [email protected]'%' identified by '$pw'"mysql --login-path=root -e"grant insert,update,delete,select on *.* to [email protected]'%'"#测试应用mysql客户端登录[[email protected] ~]# mysql -h127.0.0.1 -uapp -p #手动输出明码无奈登录Enter password:ERROR 1045 (28000): Access denied for user 'app'@'127.0.0.1' (using password: YES)[[email protected] ~]# mysql -h127.0.0.1 -uapp -p'abc$2UY' #应用单引号无奈登录mysql: [Warning] Using a password on the command line interface can be insecure.ERROR 1045 (28000): Access denied for user 'app'@'127.0.0.1' (using password: YES)[[email protected] ~]# mysql -h127.0.0.1 -uapp -pabc$2UY #不加单引号或应用双引号都能够登录mysql: [Warning] Using a password on the command line interface can be insecure.Welcome to the MySQL monitor. Commands end with ; or \g.Your MySQL connection id is 15389Server version: 8.0.18 MySQL Community Server - GPLCopyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.Oracle is a registered trademark of Oracle Corporation and/or itsaffiliates. Other names may be trademarks of their respectiveowners.Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.mysql>问题剖析失常的话上述登录形式都是能够失常登录数据库的，那为什么局部能够局部不能够呢？首先能够确认一下存入数据库的明码是否正确。咱们能够手动新建一个用户明码与 app 用户明码保持一致。而后比拟 mysql.user 表中 authentication_string 字段是否统一。 ...

1.数据库的容量测试相干性能测试举荐应用sysbench，详情可参考：https://github.com/akopytov/s... 相干的sysbench选项能够参考：https://github.com/akopytov/s...容量测试能够在装置sysbench后应用以下命令进行sysbench oltp_point_select \ --tables=[共有几张数据表] \ --table-size=[每张数据表要灌的数据量，举荐至多为 10000000] \ --db-driver=[pgsql/mysql] \ --pgsql-host=[host] \ --pgsql-port=[port] \ --pgsql-user=[userNmae] \ --pgsql-password=[userPwd] \ --pgsql-db=[dbName] \ prepare2.写入性能测试case以后sysbench对于写入性能相干的测试case有 read_write、update_index、update_non_index、write_only、insert命令能够参考sysbench oltp_${case} \--tables=${tables} \--table-size=${tb_size} \--db-ps-mode=disable \--db-driver=[pgsql/mysql] \--pgsql-host=${host} \--report-interval=[距离s报告一次后果] \--pgsql-port=${port} \--pgsql-user=${user} \--pgsql-password=${pwd} \--pgsql-db=${db} \--threads=${threads} \--time=${tim} \--rand-type=uniform run 3.查问性能 ，多表 join以后sysbench对于查问性能相干的测试case有 read_only、point_select 相干命令能够参考第二步以后版本sysbench并不反对多表join，因而咱们须要自定义lua测试脚本 以下是简略范例，能够依据需要自行批改vim oltp_mutli_join.luarequire("oltp_common")function thread_init()drv = sysbench.sql.driver()con = drv:connect()endfunction thread_done()con:disconnect()endfunction event()local tableNum1local tableNum2local rstableNum1 = math.random(1,sysbench.opt.tables)tableNum2 = math.random(1,sysbench.opt.tables)local table1 = "sbtest" .. tableNum1local table2 = "sbtest" .. tableNum2local id = math.random(1,sysbench.opt.table_size)-- db_query("begin")rs = db_query("SELECT a.k FROM " .. table1 .. " a left join " .. table2 .. " b ON a.id = b.id WHERE a.id= " .. id)-- db_query("commit")end在自定义脚本中，必须要提供thread_init() thread_done() event()这三个函数 ...

2022.10.10——2022.12.31 期间，报名参加社区我的项目捉虫流动，只有提交无效issue 或 PR，就能取得相应积分，兑换精美社区定制周边礼品，GreatSQL 社区期待您的参加！ 报名形式流动报名：社区用户需先在流动帖内应用社区账号，回复您的“Gitee 用户名+报名我的项目捉虫流动”，即报名胜利。 扫描/辨认下方二维码，即可跳转至流动帖进行报名： 流动流程：回复流动帖报名 → 提交 issue/PR → 审核通过获取积分 → 积分奖品兑换 → 奖品快递发放 流动工夫：2022.10.10——2022.12.31 参加规定提 issue 请先拜访 我的项目仓库 GreatSQL 或 文档仓库 GreatSQL-Doc，发现库中存在的谬误，返回对应的我的项目仓库或文档仓库提交 issue，提交前请先搜寻该问题是否已有记录。 提 PR 请确定须要解决的问题，须要有对应的 issue 。我的项目仓库问题 Fork GreatSQL，文档仓库问题 Fork GreatSQL-Doc，批改实现后即可提交 PR 期待审核。除了本人提交的 issue ，其余尚未失去解决的 issue 也可认领并提交 PR。 Gitee 各仓库地址：GreatSQL 我的项目仓库：https://gitee.com/GreatSQL/Gr...GreatSQL-Doc 文档仓库：https://gitee.com/GreatSQL/Gr...积分规定我的项目仓库 GreatSQL 问题：P01 装置运维问题 ： 每个 issue 1 分、每个 PR 3 分。 产品装置过程中遇到的，报错、正告等导致无奈实现装置的问题；产品运维应用过程中呈现的导致产品无奈失常应用的问题；发现 GreatSQL 我的项目存在的新 bug（MySQL 官网遗留 bug 除外）；P02 安全漏洞问题： 每个 issue 5 分、每个 PR 8 分。 ...

前言大家好，我是xicheng。最近天气变凉，留神身材。当初持续更新MySQL的InnoDB的相干文章，InnoDB的常识脑图如下所示，大家坐稳了。 InnoDB页简介默认是16KB。大小只能在第一次初始化MySQL数据目录时指定。是InnoDB用于存放数据与索引的页。 InnoDB数据页大体构造 名称中文名大小（字节）简略形容File Header文件头38页的一些通用信息Page Header页头56数据页专有的一些信息Infimum + SupreMum最小记录和最大记录26两个虚构的行记录User Records用户记录不确定理论存储的行记录内容Free Space闲暇空间不确定页中尚未应用的空间Page Directory页目录不确定页中某些记录的绝对地位File Trailer文件尾部8测验页是否残缺如下图所示 File Header用来记录页的一些头信息。针对各种类型的页都通用File Header属性如下表所示。*为重点把握的属性。 名称占用空间（字节）形容*FIL_PAGE_SPACE_OR_CHKSUM4⻚的校验和（checksum值）*FIL_PAGE_OFFSET4⻚号*FIL_PAGE_PREV4上⼀个⻚的⻚号*FIL_PAGE_NEXT4下⼀个⻚的⻚号。通过该属性与FIL_PAGE_PREV属性，实现了B+树中，叶子结点是由双向链表形成，能疾速遍历的个性。FIL_PAGE_LSN8⻚⾯被最初批改时对应的⽇志序列地位*FIL_PAGE_TYPE2该⻚的类型。具体页类型在下表中展现FIL_PAGE_FILE_FLUSH_LSN8仅在零碎表空间的⼀个⻚中定义，代表⽂件⾄少被刷新到了对应的LSN值FIL_PAGE_ARCH_LOG_NO_OR_SPACE_ID4⻚属于哪个表空间页类型，*为重点把握的页类型。 类型名称十六进制形容FIL_PAGE_TYPE_ALLOCATED0x0000最新调配，还没使⽤*FIL_PAGE_UNDO_LOG0x0002Undo⽇志⻚*FIL_PAGE_INODE0x0003段信息节点*FIL_PAGE_IBUF_FREE_LIST0x0004Insert Buffer 闲暇列表FIL_PAGE_IBUF_BITMAP0x0005Insert Buffer 位图*FIL_PAGE_TYPE_SYS0x0006零碎⻚FIL_PAGE_TYPE_TRX_SYS0x0007事务零碎数据FIL_PAGE_TYPE_FSP_HDR0x0008表空间头部信息FIL_PAGE_TYPE_XDES0x0009扩大形容⻚FIL_PAGE_TYPE_BLOB0x000ABLOB⻚*FIL_PAGE_INDEX0x45BF索引⻚，也就是咱们所说的数据⻚Page Header上文列举出了很多种类型的页。其中数据页的属性如下表所示。 状态名称大小（字节）形容PAGE_N_DIR_SLOTS2在⻚⽬录中的槽数量，在Page Directory中会讲到PAGE_HEAP_TOP2还未使⽤的空间最⼩地址，也就是说从该地址之后就是Free SpacePAGE_N_HEAP2本⻚中的记录的数量（包含最⼩和最⼤记录以及标记为删除的记录）PAGE_FREE2第⼀个曾经标记为删除的记录地址（各个已删除的记录通过next_record也会组成⼀个单链表，这个单链表中的记录能够被从新利⽤）PAGE_GARBAGE2已删除记录占⽤的字节数PAGE_LAST_INSERT2最初插⼊记录的地位PAGE_DIRECTION2记录插⼊的⽅向PAGE_N_DIRECTION2⼀个⽅向间断插⼊的记录数量PAGE_N_RECS2该⻚中记录的数量（不包含最⼩和最⼤记录以及被标记为删除的记录）PAGE_MAX_TRX_ID8批改以后⻚的最⼤事务ID，该值仅在⼆级索引中定义PAGE_LEVEL2以后⻚在B+树中所处的层级PAGE_INDEX_ID8索引ID，示意以后⻚属于哪个索引PAGE_BTR_SEG_LEAF10B+树叶⼦段的头部信息，仅在B+树的根⻚面定义PAGE_BTR_SEG_TOP10B+树⾮叶⼦段的头部信息，仅在B+树的根⻚面定义Infimum Record和Supremum Record每个数据页都有两个虚构的行记录，用来限定记录的边界。Infimum比该页的任何主键值都小。Supremum比该页的任何主键值都大。如下图所示。 User Record和Free SpaceUser Record是理论存储行记录的内容。Free Space是闲暇空间，是个链表数据结构。当一条记录被删除后，该空间会被退出到闲暇链表中。 Page Directory数据页的Page Directory用于在页内疾速查找某条记录。分组流程 初始状况下⼀个数据⻚⾥只有最⼩记录和最⼤记录两条记录，它们分属于两个分组。最⼩记录所在的分组只能有1条记录，最⼤记录所在的分组领有的记录条数只能在1-8条，剩下的分组中记录的条数范畴只能在是4-8条之间。将每个组的最初⼀条记录的地址偏移量依照从小到大的顺序存储到Page Directory里。Page Directory的这些地址偏移量被称为槽。之后每插⼊⼀条记录，都会从⻚⽬录中找到主键值⽐本记录的主键值⼤并且差值最⼩的槽，而后把该槽对应的记录的n_owned值+1，示意本组内⼜增加了⼀条记录，直到该组中的记录数等于8个为止。在⼀个组中的记录数等于8个后再插⼊⼀条记录时，会将组中的记录拆分成两个组，⼀个组中4条记录，另⼀个5条记录。这个过程会更新以后组对应的槽，且另外会新增⼀个槽来记录这个新增分组中最⼤的那条记录的偏移量。示例 初始状况如下图所示，下图中行记录中属性的含意参见“InnoDB与其它存储引擎--InnoDB的行--COMPACT”。该页有2个组。第1组，也就是Infimum Record所在的组只有1条记录。第2组，也就是Supreme Record所在的组有7条记录。插入1条主键值为2的记录：槽1所指的记录的主键值比待插入记录大，且差值最小。将该组的主键最大记录的n_owned +1。也就是将Supreme Record记录的n_owned +1。而后调整next record指针，调整heap no。后果如下图所示。插入1条主键值为3的记录。槽1所指的记录的主键值比待插入记录大，且差值最小。此时，槽1对应的组曾经有8条记录了。则将该组拆分为2组。更新这2组的heap_no，next_record，槽等信息。进一步简化后的示意图如下所示。⻚中查找指定主键值的记录流程 通过⼆分法比拟槽所指记录的主键值与待查键值的大小，来确定待查记录所在的槽。确定槽后，从槽所指的记录开始，通过记录的next_record属性遍历该槽所在的组中的各个记录，至到找到指定主键的记录，或者遍历残缺个组为止。File Trailer所有页类型的File Trailer都雷同，一共有8个字节，分成2个局部。 前4个字节代表⻚的校验和（checksum），这个局部和FileHeader中FIL_PAGE_SPACE_OR_CHKSUM绝对应的。具体通过InnoDB的checksum函数来运算两者，将运算后果进行比拟。如果后果雷同，才代表页面被残缺的刷新到了磁盘。（因为刷盘是先刷File Header，后刷File Trailer） 后4个字节与File Header中的FIL_PAGE_LSN雷同，这个局部也是为了校验⻚的完整性的。 结尾MySQL数据页就讲完了，心愿大家能继续关注上来。下一篇MySQL文章讲InnoDB-表空间。 微信扫描下方二维码，或搜寻“xicheng”，关注公众号后回复【笔记】，有我筹备的15万字Java面试笔记。　感激各位人才的点赞、珍藏和评论，干货文章继续更新中，下篇文章再见！

首先，让咱们来看看MySQL的整个组织框架 MySQL中有很多个数据库（database），每个数据库中都有很多张表（table），每张表中id，name，age则是用来形容数据的字段 那么，接下来，让咱们来看看对于数据库，表，字段的各种操作是怎么样的 数据库显示所有数据库SHOW DATABASES 这个操作通常是咱们关上MySQL之后的第一个指令 （当然，如果你十分分明MySQL中有哪些数据库，那能够间接跳到第三步，或者你想创立一个新的数据库，则应用接下来的指令） 创立数据库CREATE DATABASE database1 创立名为database1的数据库 当咱们再次查看所有数据库时，便发现曾经有了咱们方才创立的数据库了 当咱们试图创立曾经存在的数据库时，MySQL会报出数据库曾经存在的谬误 但当咱们下面语句中退出if not exists，即 数据库不存在则创立，如果没有满足not exists的条件，那么database1就不会创立 因而，如果database1已存在，则不会创立，也不会进行报错 create database if not exists database1 应用数据库USE DATABASE database1 应用名为database1的数据库 当咱们试图应用不存在的数据库时MySQL则会报出不出名数据库'database2'的谬误 删除数据库DROP DATABASE database1 删除名为database1的数据库 那如果数据库不存在咱们还进行删除，则MySQL又会进行报错 其实解决形式就跟下面的创立数据库一样，咱们加上if exists条件就行 不同的是 创立的时候，咱们的前置条件是if not exists 删除的时候，咱们的前置条件是if exists 表字段

十年经典再更新时隔十年，《高性能MySQL》再次出版，这是该系列的第四个版本。过来十年，《高性能MySQL 第三版》曾经成为除了文档之外，MySQL相干开发者、DBA等从业者的必读书目，在豆瓣上也收到了9.3分的好评。另一方面，在这十年间，MySQL技术、数据库技术以及数据库的生态都产生了很大的变动，最新版的图书也相应做了大量的更新、精简与订正。这次仍旧由我和宁海元、张新铭等一起实现翻译。如果，英文浏览没有大的阻碍的敌人，依然举荐浏览英文原版，目前在京东、亚马逊等平台都能够买到。如果，想读中文版的敌人，这次出版的《高性能MySQL 第四版》则是十分不错的抉择。本文，概述了第四版的一些更新与扭转，以及MySQL在中国这十年的倒退。另外，文末有一个“回复SQL，抽奖支付赠书”的流动，感兴趣的间接跳到最初局部。新书在京东上曾经上线。 MySQL在中国的这十年过来十年也是中国MySQL疾速倒退的十年。在2022年，CSDN的中国开发者调查报告中的数据，在中国，有73%的开发者都在应用MySQL，稳居第一名，且遥遥领先其余数据库。一方面是中国互联网在过来十年的疾速倒退背地，须要海量的、低成本的数据库存储计划，另一方面，更重要的，随着中国开发者、DBA能力加强，从原来的用好开源，逐渐成长为开源背地的重要的贡献力量。无论是，阿里、腾讯、华为、百度、去哪儿等公司，都在通过各种形式，一方面输入本人的最佳实际，另一方面也在向MySQL代码库奉献本人的力量。随着，中国厂商在MySQL技术应用和商业上的深刻，以阿里云、腾讯云、华为云为代表的中国技术厂商曾经成为MySQL社区重要力量：在2018年，阿里云数据库RDS团队，因为多源复制、FlashBack等性能取得了MySQL Community Awards，彭立勋作为代表在Percona Live承受颁奖：参考2018年，在5.7.17版本，由翟卫祥奉献的对于Group Commit和GTID的优化：参考；2021年，在8.0.24版本中，由翟卫祥修复的对于InnoDB Recovery阶段性能问题：参考。除此之外，翟卫祥其实是比拟频繁的呈现在MySQL Release Note的人。也因为这些奉献，翟卫祥也在2019年也取得了MySQL Community Contributor of the Year的奖项：参考。2019年，腾讯游戏CROS DBA团队的陈福荣（Vin Chen）、梁飞龙（Felix Liang）也取得MySQL Community Contributor Award：参考。2022年，彭祥在往年成为MariaDB Foundation的Board Members，他也是阿里云RDS业务的负责人。2022年7月，在最新的8.0.30版本中，来自腾讯CDB团队的Yuxiang Jiang和Zhou Xinjing修复了局部对于InnoDB、PS相干的Bug：参考。另外，在MySQL Bug零碎上，也常常可能看到国内厂商的身影，次要是阿里云和腾讯。在国内社区，诸如丁奇、彭立勋、周彦伟、杨建荣、韩锋、杨奇龙、叶金荣、沃趣科技、盖国强、何登成等都十分沉闷，通过ACMUG、DBAplus、墨天轮等平台推广数据库的最佳实际。另外，国内各个大厂也都还有暗藏着十分多的“扫地僧”级别的高手，出头露面比拟少，诸如ba0tiao、江神、Jimmy（这里无奈一一列举）也是中国MySQL社区十分重要力量。MySQL凭借着其弱小的影响力，也影响着一系列的产品的倒退。在云时代，MySQL仍旧是配角。在2014年AWS推出的Aurora、2017年阿里云推出的PolarDB、2018年腾讯云公布CynosDB（TDSQL-C前身）都首先抉择了兼容MySQL。而泛滥新的数据库，诸如OceanBase、TiDB、PolarDB-X、ClickHouse、AnalyticDB等都或者抉择兼容MySQL或者应用MySQL相似的SQL方言。而各个云厂商，凭借着MySQL凋谢、开源，基于其构建的RDS、或者云原生数据库都赚的盆满钵满，通常，都可能占到其数据库支出的50%以上。这也从经济基础上，保障了各个云厂商依旧会动摇不易的在MySQL方向投入大量人力，推动MySQL的倒退。到目前为止，MySQL数据库也成为了“开源技术”和“云厂商”之间，在技术利益十分宏大的时候，仍旧可能较为“谐和”相处的案例之一。兼容MySQL的分布式数据库寰球的MySQL数量约为800万个，大量的运行场景曾经催生更加垂直和高要求的产品。兼容MySQL的分布式数据库就是其最重要的一个方向。从需要上来说，随着数据的快速增长，在越来越多的场景下，MySQL单机架构曾经无奈满足需要，分布式数据库在过来10年也在疾速倒退。2010年，阳振坤在淘宝外部开始研发OceanBase，自2015年后，开始逐渐在内部摸索商业化，同时兼容MySQL和Oracle；TiDB于2015年正式公布，兼容MySQL协定；2020年，在云栖大会上，阿里云数据库负责人李飞飞也发表，DRDS正式降级为PolarDB-X，并于2021年正式开源，也是兼容MySQL协定。2018年，ShardingSphere公布（前身为Sharding-JDBC），也是兼容MySQL的。在中国当下，分布式数据库的竞争是异样强烈。在往年（2022年）的4月份，TiDB公布了6.0版本，将TiFlash也正式开源，之后也很快上线TiDB Cloud，上线了阿里云心选商城。OceanBase也于往年的8月公布了4.0版本，单机部署最小反对4核8G；剖析能力实现了由全场景向量化能力笼罩；OceanBase Cloud也会很快上线。另外，PolarDB-X也在继续的加强，公布包含了与MySQL兼容性比拟好的AUTO_INCREMENT、数据热点诊断、冷热数据存储拆散、Flashback Query等性能。另外，ShardingSphere、TDSQL等也在疾速倒退。另外，在往年9月，TiDB和OceanBase都不谋而合的在美国硅谷开始做产品推广，这个竞争曾经逐渐从国内延长到了海内。这也是该行业疾速倒退与凋敝的体现。自此，中国的数据库曾经逐渐从最早的用好开源、奉献开源，缓缓走向自主研发、独立品牌的模式，也从国内竞争开始走向更大的国内市场，这是中国数据库在商业模式、技术能力、生态建设都更加弱小的体现。 新的版本，新的技术MySQL 5.1是十年前的支流版本，期间经验了5.5、5.6、5.7，到当初8.0逐渐成为以后的支流版本。在最新的“第四版”公布时，MySQL最新的版本为8.0.20，所以，书中很多案例与测试也都在该版本中通过了测试与验证。这次出版的《高性能MySQL 第四版》则新增了过来十年MySQL各个新版本个性。新的版本背地代表的是新的技术。例如，从5.6开始引入、5.7和8.0版本中逐渐成熟的GTID技术，大大提高了MySQL复制时的数据一致性、以及可运维性，也使得MySQL在整个数据流生态中，变得更加易用；随着，NoSQL的风行以及局部利用或者模块中Schema Free设计的呈现，MySQL在最近的版本中，始终在一直加强对JSON的反对，包含操作JSON函数反对、性能优化、表达式函数反对等，使得在MySQL中也能够十分自在、高效的治理JSON数据。性能治理始终是该书目标重点局部，最新版本的MySQL也在一直的欠缺Performance Schema（简称“PS”），帮忙用户更加零碎的进行性能治理与优化。在第四版中新增的第三章则零碎的介绍了PS，能够帮忙读者零碎的理解如何通过PS查看数据库/InnoDB外部的运行指标，从而观测性能并针对性的进行优化。云数据库曾经成为数据库畛域最重要的方向。本书也减少了对于云数据库的篇幅，并以AWS Aurora、谷歌云数据库、云主机自建数据库为代表，介绍了以后云数据库的应用、能力以及限度等。随着云计算、IoT、互联网等技术倒退，数据量也始终在快速增长，本书也减少了对于如果扩大MySQL的章节与篇幅，包含通过只读节点进行的读扩大，以及如何通过拆分的形式进行写扩大等。另外，本书另一个重要特点是做了大量删减，全书也从原来的第三版约800页精简到约350页：删除了所有的MyISAM引擎相干的内容。MyISAM引擎是最早版本MySQL的原生引擎，但因为其架构缺点、不反对事务、性能等起因，自8.0版本开始彻底被InnoDB替换。 删除了大量对于如何配置MySQL的内容。随着工夫的推移，当初的MySQL文档曾经十分详尽的形容了这部分操作。本书则侧重于原理、应用、最佳实际等。  删除或大大简化了诸如分区表、调度事件、全文索引、Query Cache等个性的介绍。尽管，在十年前这些都还算是MySQL的“高级个性”,但当初曾经为大家所相熟，而且文档曾经了十分具体的形容，本书则不再介绍这些内容。当然，仍旧保留了最重要的局部，包含MySQL架构与根底原理、可靠性治理、SQL优化、索引设计与优化、硬件与软件适配优化、表构造设计规范与原理、复制技术、备份与复原、垂直与程度扩大、云数据库等。整体上，仍旧十分举荐大家购买与浏览。本书，在翻译出版过程中也失去了很多数据库畛域敌人的反对，包含沃趣科技陈栋、云和恩墨盖国强、OceanBase的阳振坤、周彦伟等，尤其是，阿里云数据库负责人、ACM/IEEE Fellow李飞飞 特意拨冗领导并撰写举荐序言，这里援用如下：随着互联网行业以及云计算产业的高速倒退， MySQL成为世界范畴内以及中国数据库畛域最风行的开源数据库。在简直所有大型互联网业务场景中， MySQL都是业务架构的外围组件之一。宽泛的利用也推动了MySQL在过来十年的高速倒退，MySQL社区相继推出了5.6、5.7、8.0版本，从性能、可扩展性、安全性、稳定性、可维护性、易用性等维度都有了十分大的倒退。《高性能MySQL 第三版》是2012年公布的，最新版本的《高性能MySQL 第四版》在上一版的内容上连续了之前的经典内容，包含架构设计、优化、高可用等内容，同时新增了云数据库、扩展性等过来10年倒退的相干内容，另外，也减少MySQL过来10年里的最新版本包含5.7、8.0版本的最新的个性和内容。MySQL作为当下最风行的开源数据库，本书从实际的角度涵盖了数据库系统的架构设计、锁、性能治理、高可用等内容，除了作为MySQL的参考书之外，也能够作为数据库系统原理和设计的一个实现参考。随着云数据库的风行，这本书的最新版也做了相应的调整，例如，将数据库的装置、配置、监控搭建等根底操作内容(云数据库封装并提供了大部分这些能力)做了大幅度的缩减。因而，本书也非常适合面向云数据库系统开发者的一本MySQL参考书籍。如本书的名字所述，本书在内核设计、性能优化方面，仍旧是着墨最多的局部，深刻介绍了锁治理、并发管制、Performance Schema应用、索引优化等内核机制，能够帮忙企业的DBA、或者想深刻理解MySQL优化的开发者，以及云数据库开发者更高效的应用和拓展MySQL。本书的译者是云数据库畛域和MySQL数据库的资深专家，有着很强的技术能力和行业实际以及业务洞察，同时也具备十分杰出的业务架构设计和商业化教训。在深刻了解原著的根底上，联合本人的洞察和教训提供了杰出的专业化中文版本，是MySQL畛域不可多得的一本必读书目。抽奖赠书最初，这里将拿出10本书（来自电子工业出版社的赠书），收费赠送大家，能够通过后盾公众号后盾回复，如下SQL参加抽奖，即可取得赠书：抽奖规定复制SQL+填写邮箱，发送至公众号后盾，立刻抽奖 SELECT book FROM 9z.cloudWHERE email='[email protected]' -- your email 最终中奖后果一周后颁布，并通过邮件发送至幸运儿邮箱，未收到邮件的中奖小伙伴可私信本号后盾～ 对于本文作者周振兴周振兴曾是阿里资深数据库技术专家（花名：苏普），在淘宝、阿里云数据库团队总计供职12年，是阿里去IOE核心成员，是阿里外围零碎从集中式到分布式架构的开创者，有丰盛的MySQL性能优化、Troubleshooting教训，曾负责阿里云明星产品PolarDB产品治理负责人，阿里云数据库产品与经营总监等职责。目前，在新的数据库守业征程当中。立刻点击关注，获取更多精彩内容～

最近遇到一个问题：mysql 建表的时候，一个大的文本，是varchar还是text。mysql 新版varchar 最大长度曾经反对到65535了，跟text一样。在占用存储长度上，如果varchar(M) M < 255 的话，varchar用一个字节保留长度，text始终用2字节保留长度。mysql 官网给的区别：1，如果该字段创立索引，text必须自定索引前缀长度，varchar能够不必。（ps：varchar理论应用中，最好也指定前缀长度）2，text 没有 default 值。还有一个就是：Instances of BLOB or TEXT columns in the result of a query that is processed using a temporary table causes the server to use a table on disk rather than in memory because the MEMORY storage engine does not support those data types带text字段的sql，如果须要用到长期表的时候，只能在磁盘创立，不能在内存创立。这个应该是最大的区别了，会影响到性能。其余的应该没啥了，如果遇到再来补充。 只有 select 子句中蕴含 blob 类型字段，就会影响 MySQL 对于排序操作的优化。select 字段列表里包含 blob 类型字段（text 系列字段、blob 系列字段都属于 blob 类型字段），排序时只能应用 <sort_key, rowid> 这种类型的排序，要先查从存储引擎查出排序字段和主键 ID，而后再依据主键 ID 去存储引擎查问须要返回给用户的其它字段，这有点相似回表的意思。blob 类型字段不能应用 <sort_key, addon_fields>、<sort_key, packed_addon_fields> 这 2 种对于排序的优化。 ...

一、建设数据库数据库名称：业务零碎名称_子系统名，同一模块应用的表名尽量应用对立前缀库名，表名，字段名，索引名，视图名都要求小写默认应用CHARSET为utf8mb4,COLLATE抉择utf8mb4_general_ci二、建表每个表应用innodb引擎减少created_ad,updated_at,deleted_at 三个字段，示意创立工夫，更新工夫，以及删除工夫，deleted_at为0位没有删除，非0为删除工夫。三、索引为每一个表设计一个自增的id主键，类型bigint，主键。四、常用字段命名

前文回顾 实现一个简略的Database1(译文） 实现一个简略的Database2(译文） 实现一个简略的Database3(译文） 译注：cstsck在github保护了一个简略的、相似SQLite的数据库实现，通过这个简略的我的项目，能够很好的了解数据库是如何运行的。本文是第四篇，次要是应用rspec对目前实现的性能进行测试并解决测试呈现BUG 译注：cstsck在github保护了一个简略的、相似sqlite的数据库实现，通过这个简略的我的项目，能够很好的了解数据库是如何运行的。本文是第四篇，次要是应用rspec对目前实现的性能进行测试并解决测试呈现BUG Part 4 咱们的第一个测试（和BUG）咱们曾经取得插入数据到数据库并打印所有数据的能力。当初来测试一下目前microseconds已有的性能。<br/>我要应用rspec来写我的测试，因为我对rspec很相熟，它的语法也相当易读。<br/>_译注：rsepec 是一个基于Ruby的测试框架，语法非常简单，能够很不便的测试各种可执行程序，判断输入_<br/>我定义一个短小的help来发送一个帮忙命令列表到数据库，而后对输入进行断言。 describe 'database' do def run_script(commands) raw_output = nil IO.popen("./db", "r+") do |pipe| commands.each do |command| pipe.puts command end pipe.close_write # Read entire output raw_output = pipe.gets(nil) end raw_output.split("\n") end it 'inserts and retrieves a row' do result = run_script([ "insert 1 user1 [email protected]", "select", ".exit", ]) expect(result).to match_array([ "db > Executed.", "db > (1, user1, [email protected])", "Executed.", "db > ", ]) endend这个简略的测试是确认咱们的输出可能获取返回后果。并确保能通过测试： ...

背景前几天因工作须要，组长给我安顿了一个数据荡涤的工作。 工作：把 A 表的数据洗到 B 表。我的第一反馈，什么是「洗」？洗数据是什么？洗钱我倒是晓得。 不过我不能慌啊，于是问了问组长。 我：组长，把 A 表的数据洗到 B 表是什么意思？ 组长一脸无奈，手捂住脸，恨铁不成钢，而后调整过去，还是很急躁地跟我讲的，大略意思就是咱们当初 B 表须要 A 表的数据， A 表中和 B 表中字段含意一样，然而值可能不一样，这就须要咱们进行解决，在将 A 表数据搞到 B 表的过程中，把数据搞正确。 基于我理解能力无限，过后并不是很懂所谓的「洗数据」，而且这个 A 表的字段也和 B 表的字段没怎么对上，A 的字段显著多于 B 的字段，某些字段命名也和 B 不一样，然而表白的意思是一样的，该如何洗？ 于是疯狂搜寻如何洗数据！ 我这里就举个例子来阐明，别离给出 A 表和 B 表，当然我只列出了一部分字段，当初假如就这么多字段。 A 表A 表字段：name, province_id, city_id, area_id, tech_id, crop_id, field_id, create_time, update_time, xxx, yyy, zzz, ... A 表的字段是多于 B 表的，我须要将 A 表的数据洗到 B 表，只解决我须要的字段，不须要的就不必理。 A 表中有 2 万多条记录，B 表我本人插入的有 200 多条记录。 ...

前文回顾 实现一个简略的Database1(译文）实现一个简略的Database2(译文）实现一个简略的Database3(译文） 译注：cstsck在github保护了一个简略的、相似sqlite的数据库实现，通过这个简略的我的项目，能够很好的了解数据库是如何运行的。本文是第三篇，次要是实现数据库的实现内存中的数据结构并存储数据 Part 3 在内存中，只追加的单表数据库咱们从一个小型的，有许多限度的数据库开始。当初数据库将： 反对两个操作：插入一行并打印所有行数据驻留在内存中（没有长久化到磁盘）反对单个、硬编码的表咱们的硬编码表将用来存储用户数据，看起来就行上面展现的这样： columntypeidintegerusernamevarchar(32)emailvarchar(255)这是一个简略的计划，然而它将让咱们的数据库可能反对不同的数据类型和不同大小的文本数据类型。插入语句当初看起来像上面这样： insert 1 cstack [email protected]这象征咱们须要降级prepare_statement()函数来解析参数： if (strncmp(input_buffer->buffer, "insert", 6) == 0) { statement->type = STATEMENT_INSERT; + int args_assigned = sscanf( + input_buffer->buffer, "insert %d %s %s", &(statement->row_to_insert.id), + statement->row_to_insert.username, statement->row_to_insert.email); + if (args_assigned < 3) { + return PREPARE_SYNTAX_ERROR; + } return PREPARE_SUCCESS; } if (strcmp(input_buffer->buffer, "select") == 0) {咱们把这些解析出的的参数存储到Statement对象中的一个新的数据结构Row中。 +#define COLUMN_USERNAME_SIZE 32 +#define COLUMN_EMAIL_SIZE 255 +typedef struct { + uint32_t id; + char username[COLUMN_USERNAME_SIZE]; + char email[COLUMN_EMAIL_SIZE]; +} Row; + typedef struct { StatementType type; + Row row_to_insert; // only used by insert statement } Statement;当初咱们须要copy这些数据到其余一些代表table的数据结构中。SQLite为了反对疾速查找、插入和删除操作而应用B-tree。咱们将从一些简略的开始。像B-tree，它把行数据分组成页（pages），然而为了替换把这些页（pages）组织成一颗树的这种办法，这里咱们把页来组织成数组（array）。 ...

作者：王向 爱可生 DBA 团队成员，负责公司 DMP 产品的运维和客户 MySQL 问题的解决。善于数据库故障解决。对数据库技术和 python 有着浓重的趣味。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 前言在不久前有位客户在进行数据迁徙时发现。本人应用pt-archiver备份时总是会少一条数据；如源数据库中某表数据为2333，导入目标数据库后select后果只有2332。 于是本篇文章就此开展，因为这个问题在先前钻研过，我这里就间接先上论断后试验了。 论断在pt-archiver中有这样一个参数--[no]safe-auto-increment官网文档中作用如下： 指定不应用自增列(AUTO_INCREMENT)最大值对应的行进行归档默认开启，该选项在进行归档革除时会额定增加一条WHERE子句以避免工具删除单列升序字段具备的具备AUTO_INCREMENT属性最大值的数据行，为了在数据库重启之后还能应用到AUTO_INCREMENT对应的值，避免引起无奈归档或革除字段对应最大值的行。 简略总结以下外面蕴含的信息： pt-archiver工具对自增列(AUTO_INCREMENT)最大值默认行为是： 会在进行归档革除时额定增加一条WHERE子句避免对，自增列(AUTO_INCREMENT)字段的最大值如“max(id)”,的数据行进行爱护。其行为是不归档也不删除此行。 为什么要爱护这一行数据？ 为了避免AUTO_INCREMENT值重置 避免AUTO_INCREMENT值重置的意义？ 避免数据抵触，一旦AUTO_INCREMENT值重置，将会呈现雷同自增id。势必会导致下一次的归档失败，影响归档的继续进行。间接影响业务 综上所述，pt-archiver工具默认开启safe-auto-increment参数是很有必要的。能够避免某些意外产生。 那么什么状况下须要敞开safe-auto-increment参数？ 确定本人要对本表的全量数据进行归档时，应开启此参数--nosafe-auto-increment归档局部数据时蕴含自增列(AUTO_INCREMENT)字段的最大值时，应开启此参数--nosafe-auto-increment确定只归档数据不做删除数据的状况下。能够始终开启此参数--nosafe-auto-increment如果应用的是MySQL8.0版本请疏忽下面3条间接--nosafe-auto-increment，因为MySQL8不会重置AUTO_INCREMENT问题重现1.筹备好源库数据如下 mysql> select count(*) from sbtest1; +----------+ | count(*) |+----------+| 100000 | +----------+ 1 row in set (0.08 sec)2.进行归档 [[email protected] ~]# pt-archiver --source u=root,p=xxx,h=127.0.0.1,P=3306,D=test,t=sbtest1 --destu=root,p=xxx,h=10.186.61.9,P=3306,D=test,t=sbtest1 --where="1=1" --progress=1000 --statistics --bulk-insert --bulk-delete --txn-size=1000 --limit=1000 --no-delete --no-check-charset --skip-foreign-key-checks TIME ELAPSED COUNT 2021-09-09T23:23:38 0 0 2021-09-09T23:23:38 0 1000 2021-09-09T23:23:38 0 2000 2021-09-09T23:23:38 0 3000 2021-09-09T23:23:38 0 4000 2021-09-09T23:23:38 0 5000 2021-09-09T23:23:38 0 6000 ...1 2021-09-09T23:23:46 7 2394000 2021-09-09T23:23:46 7 95000 2021-09-09T23:23:46 7 96000 2021-09-09T23:23:46 8 97000 2021-09-09T23:23:46 8 98000 2021-09-09T23:23:46 8 99000 2021-09-09T23:23:46 8 99999 Started at 2021-09-09T23:23:38, ended at 2021-09-09T23:23:46 Source: D=test,P=3306,h=127.0.0.1,p=...,t=sbtest1,u=root Dest: D=test,P=3306,h=10.186.61.9,p=...,t=sbtest1,u=root SELECT 99999 INSERT 99999 # 只有99999行3.查看新表的行数 ...

作者：王向 爱可生 DBA 团队成员，负责公司 DMP 产品的运维和客户 MySQL 问题的解决。善于数据库故障解决。对数据库技术和 python 有着浓重的趣味。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 前言在不久前有位客户在进行数据迁徙时发现。本人应用pt-archiver备份时总是会少一条数据；如源数据库中某表数据为2333，导入目标数据库后select后果只有2332。 于是本篇文章就此开展，因为这个问题在先前钻研过，我这里就间接先上论断后试验了。 论断在 pt-archiver 中有这样一个参数--[no]safe-auto-increment官网文档中作用如下： 指定不应用自增列(AUTO_INCREMENT)最大值对应的行进行归档默认开启，该选项在进行归档革除时会额定增加一条WHERE子句以避免工具删除单列升序字段具备的具备AUTO_INCREMENT属性最大值的数据行，为了在数据库重启之后还能应用到AUTO_INCREMENT对应的值，避免引起无奈归档或革除字段对应最大值的行。 简略总结以下外面蕴含的信息： pt-archiver工具对自增列(AUTO_INCREMENT)最大值默认行为是： 会在进行归档革除时额定增加一条WHERE子句避免对，自增列(AUTO_INCREMENT)字段的最大值如“max(id)”,的数据行进行爱护。其行为是不归档也不删除此行。 为什么要爱护这一行数据？ 为了避免AUTO_INCREMENT值重置 避免AUTO_INCREMENT值重置的意义？ 避免数据抵触，一旦AUTO_INCREMENT值重置，将会呈现雷同自增id。势必会导致下一次的归档失败，影响归档的继续进行。间接影响业务 综上所述，pt-archiver工具默认开启safe-auto-increment参数是很有必要的。能够避免某些意外产生。 那么什么状况下须要敞开safe-auto-increment参数？ 确定本人要对本表的全量数据进行归档时，应开启此参数--nosafe-auto-increment归档局部数据时蕴含自增列(AUTO_INCREMENT)字段的最大值时，应开启此参数--nosafe-auto-increment确定只归档数据不做删除数据的状况下。能够始终开启此参数--nosafe-auto-increment如果应用的是MySQL8.0版本请疏忽下面3条间接--nosafe-auto-increment，因为MySQL8不会重置AUTO_INCREMENT问题重现1.筹备好源库数据如下 mysql> select count(*) from sbtest1; +----------+ | count(*) |+----------+| 100000 | +----------+ 1 row in set (0.08 sec)2.进行归档 [[email protected] ~]# pt-archiver --source u=root,p=xxx,h=127.0.0.1,P=3306,D=test,t=sbtest1 --destu=root,p=xxx,h=10.186.61.9,P=3306,D=test,t=sbtest1 --where="1=1" --progress=1000 --statistics --bulk-insert --bulk-delete --txn-size=1000 --limit=1000 --no-delete --no-check-charset --skip-foreign-key-checks TIME ELAPSED COUNT 2021-09-09T23:23:38 0 0 2021-09-09T23:23:38 0 1000 2021-09-09T23:23:38 0 2000 2021-09-09T23:23:38 0 3000 2021-09-09T23:23:38 0 4000 2021-09-09T23:23:38 0 5000 2021-09-09T23:23:38 0 6000 ...1 2021-09-09T23:23:46 7 2394000 2021-09-09T23:23:46 7 95000 2021-09-09T23:23:46 7 96000 2021-09-09T23:23:46 8 97000 2021-09-09T23:23:46 8 98000 2021-09-09T23:23:46 8 99000 2021-09-09T23:23:46 8 99999 Started at 2021-09-09T23:23:38, ended at 2021-09-09T23:23:46 Source: D=test,P=3306,h=127.0.0.1,p=...,t=sbtest1,u=root Dest: D=test,P=3306,h=10.186.61.9,p=...,t=sbtest1,u=root SELECT 99999 INSERT 99999 # 只有99999行3.查看新表的行数 ...

一、目前mysql反对以下的几个办法来应用正则表达式标识阐明NOT REGEXP不合乎此正则REGEXP字符串是否匹配正则表达式REGEXP_LIKE()字符串是否匹配正则表达式REGEXP_INSTR()子串匹配正则表达式的起始索引REGEXP_REPLACE()替换匹配正则表达式的子字符串REGEXP_SUBSTR()返回匹配正则表达式的子字符串二、示例1、查找蕴含1个a SELECT * FROM ad_log.user where name rlike "a{1}"; 2、查找蕴含2个a SELECT * FROM ad_log.user where name rlike "a{2}";

一张表，外面有 ID 自增主键，当 insert 了 17 条记录之后， 删除了第 15,16,17 条记录，再把 Mysql 重启，再 insert 一条记 录，这条记录的 ID 是 18 还是 15 ？如果表的类型是MyISAM，那么是18。因为MyISAM表会把自增主键的最大ID记录到数据文件里，重启MySQL自增主键的最大ID也不会失落。如果表的类型是InnoDB，那么是15.因为InnoDB只是把自增主键的最大ID记录到内存中，所以重启数据库是对象表进行OPTIMZE操作，都会导致最大ID失落。MySQL的技术特点是什么？MySQL数据库软件是一个客户端或服务器零碎，其中包含：反对各种客户端程序和库的多线程SQL服务器、不同的后端、宽泛的应用程序编程接口和管理工具。Heap表是什么？HEAP表存在于内存中，用于长期高速存储。 BLOB或TEXT字段是不容许的。只能应用比拟运算符 =, <, >, =>, =<HEAP表不反对AUTO_INCREMENT索引不可为NULLMySQL服务器默认端口是什么？3306与Oracle相比，Mysql的劣势是什么？ mysql是开源软件，随时可用，无需付费。Mysql是便携式的带有命令提示符的GUI应用mysql查问浏览器反对治理如果辨别FLOAT和DOUBLE？浮点数以8位精度存储在FLOAT中，并且有四个字节。浮点数存储在DOUBLE中，精度为18位，有8个字节。

随着数据的日益增多，在架构上不得不分库分表，进步零碎的读写速度，然而这种架构带来的问题也是很多，这篇文章就来讲一讲跨库/表分页查问的解决方案。 架构背景笔者已经做过大型的电商零碎中的订单服务，在企业初期时业务量很少，单库单表根本扛得住，然而随着时间推移，数据量越来越多，订单服务在读写的性能上逐步变差，架构组也尝试过各种优化计划，比方后面介绍过的：冷热拆散、查问拆散各种计划。虽说晋升一些性能，然而在每日百万数据增长的状况下，也是无济于事。 最终通过架构组的探讨，抉择了分库分表；至于如何拆分，分片键如何抉择等等细节不是本文重点，不再赘述。 在分库分表之前先来拆解一下业务需要： C端用户须要查问本人所有的订单后盾管理员、客服须要查问订单信息（依据订单号、用户信息.....查问）B端商家须要查问本人店铺的订单信息针对以上三个需要，判断下优先级，当然首先须要满足C端用户的业务场景，因而最终选用了uid作为了shardingKey 当然抉择uid作为shardingKey仅仅满足了C端用户的业务场景，对于后盾和C端用户的业务场景如何做呢？很简略，只须要将数据异构一份寄存在ES或者HBase中就能够实现，比较简单，不再赘述。 假如将订单表依据hash(uid%2+1)拆分成了两张表，如下图： 假如当初须要依据订单的工夫进行排序分页查问（这里不探讨shardingKey路由，间接全表扫描），在单表中的SQL如下： select * from t_order order by time asc limit 5,5;这条SQL非常容易了解，就是翻页查问第2页数据，每页查问5条数据，其中offest=5 假如当初t_order_1和t_order_2中的数据如下： 以上20条数据从小到大的排序如下： t_order_1中对应的排序如下： t_order_2中对应的排序如下： 那么单表构造下最终后果只须要查问一次，后果如下： 分表的架构下如何分页查问呢？上面介绍几种计划 1. 全局查问法在数据拆分之后，如果还是上述的语句，在两个表中间接执行，变成如下两条SQL： select * from t_order_1 order by time asc limit 5,5;select * from t_order_2 order by time asc limit 5,5;将获取的数据而后在内存中再次进行排序，那么最终的后果如下： 能够看到上述的后果必定是不对的。 所以正确的SQL改写成如下： select * from t_order_1 order by time asc limit 0,10;select * from t_order_2 order by time asc limit 0,10;也就是说，要在每个表中将前两页的数据全副查问进去，而后在内存中再次从新排序，最初从中取出第二页的数据，这就是全局查问法 ...