Mysql

下载mysql下载地址 装置mysql 我选的第一个 呈现确认框，点确认 下载数据库操作工具navicathttps://www.ghxi.com/navicat16.html dbeaver navicat 连贯数据库 点测试连贯，连贯胜利 ，而后点确定

SELECT GROUP_CONCAT( COLUMN_NAME SEPARATOR " " ) FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'bioshop_bi_uat' AND TABLE_NAME = 'dwd_receivable'

@[toc]后面跟小伙伴们分享的索引相干的内容，基本上都是在 where 子句中应用索引，实际上，索引也还有另外一个大的用途，那就是在排序中应用索引，明天咱们就来聊聊这个话题。 1. 排序的两种形式MySQL 中想给查问后果排序，咱们只须要来一个 order by 即可，SQL 很简略，底层实现起来整体上来说，有两种不同的思路： filesort，有时候咱们也将之称为文件排序，这个名字有时候会给咱们一些误会，让人认为是在磁盘上进行排序的，然而实际上并不一定，数据量比拟小的时候，间接在内存中进行排序就行了，只有当在内存中无奈实现排序的时候，才会用到磁盘文件。索引排序，因为 InnoDB 中的索引是依照 B+Tree 的模式将数据组织在一起的，B+Tree 中数据自身就是有序的，所以如果可能利用好索引，排序的事件就会事倍功半。一共就这两种排序的形式，小伙伴们也发现了，如果咱们的索引设计比拟正当，最终可能依照第 2 种形式进行排序，那必定是最好不过了。 不过这里须要留神一个细节，第二种排序形式快有一个前提，那就是不须要回表，如果查问的过程中须要回表，那么第二种形式就不肯定快了。起因也简略： 如果不须要回表，也就是咱们想要查问的数据都在索引树上，索引树上的数据自身又都是依照顺序存储的，那么查到数据间接返回即可，自身就是有序的。如果查问的时候，索引树上并没有咱们想要的字段，那么就须要回表，小伙伴们晓得，回表基本上都是随机 IO 了，因为回表的时候，主键值并不一定间断，此时效率就会低一些。那么这个时候第二种排序形式的性能就不肯定强于第一种了，当然，这并无固定论断，还是要联合具体情况剖析，这里我只是通知小伙伴们有各种可能的状况。2. 索引排序如果咱们想用上索引排序，那么须要满足哪些条件呢？ 还是以咱们上篇文章的数据为例，假如我有如下表构造： CREATE TABLE `user` ( `id` int unsigned NOT NULL AUTO_INCREMENT, `username` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL, `age` int DEFAULT NULL, `address` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL, `gender` varchar(2) COLLATE utf8mb4_unicode_ci DEFAULT NULL, PRIMARY KEY (`id`), KEY `user_prop_index` (`username`,`age`,`address`)) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;这个表中有一个联结索引，联结索引的字段蕴含 username、age 和 address 三个。 ...

1. 背景介绍前段时间，客户线上 MySQL 版本从 5.7.29 降级到 8.0.25。 降级实现之后，放业务申请进来，没到一分钟就开始呈现慢查问，而后，慢查问越来越多，业务 SQL 呈现沉积。 整个过程继续了大略一个小时，直到给某条业务 SQL 对应的表加上索引，问题才失去解决。 有一个比拟奇怪的景象是：问题继续的过程中，服务器的零碎负载、CPU 使用率、磁盘 IO、网络都处于低峰期间的程度，也就是说，问题很可能不是因为硬件资源不够用导致的。 那么，根本原因到底是什么？让咱们一起来揭晓答案~ 2. 起因剖析客户线上环境有一个监控脚本，每分钟执行一次，这个脚本执行的 SQL 如下： select ... from sys.innodb_lock_waits w inner join information_schema.innodb_trx b  on b.trx_id = w.blocking_trx_id inner join information_schema.innodb_trx r  on r.trx_id = w.waiting_trx_id;对几个监控脚本的日志、SAR 日志、MySQL 的慢查问日志 & 谬误日志，以及死锁的源码，进行了全方位无死角的剖析，发现了可疑之处。 通过测试验证，最终确认罪魁祸首是 sys.innodb_lock_waits 视图援用的某个基表。 这个基表的名字和 MySQL 5.7 中不一样了，它的行为也产生了变动，就是这个行为的变动在某些场景下阻塞了业务 SQL，导致大量业务 SQL 执行变慢。 揭发这个邪恶的基表之前，咱们先来看一下 sys.innodb_lock_waits 视图的定义： MySQL 5.7 中简化的视图定义CREATE VIEW sys.innodb_lock_waits AS  SELECT ... FROM information_schema.innodb_lock_waits w  JOIN information_schema.innodb_trx b    ON b.trx_id = w.blocking_trx_id  JOIN information_schema.innodb_trx r    ON r.trx_id = w.requesting_trx_id  JOIN information_schema.innodb_locks bl    ON bl.lock_id = w.blocking_lock_id  JOIN information_schema.innodb_locks rl    ON rl.lock_id = w.requested_lock_id  ORDER BY r.trx_wait_startedMySQL 8.0 中简化的视图定义CREATE VIEW sys.innodb_lock_waits (...) AS  SELECT ... FROM performance_schema.data_lock_waits w   JOIN information_schema.INNODB_TRX b     ON b.trx_id = w.BLOCKING_ENGINE_TRANSACTION_ID  JOIN information_schema.INNODB_TRX r    ON r.trx_id = w.REQUESTING_ENGINE_TRANSACTION_ID  JOIN performance_schema.data_locks bl    ON bl.ENGINE_LOCK_ID = w.BLOCKING_ENGINE_LOCK_ID  JOIN performance_schema.data_locks rl    ON rl.ENGINE_LOCK_ID = w.REQUESTING_ENGINE_LOCK_ID   ORDER BY r.trx_wait_started5.7 中 sys.innodb_lock_waits 波及 3 个基表： information_schema.innodb_lock_waitsinformation_schema.innodb_locksinformation_schema.innodb_trx8.0 中 sys.innodb_lock_waits 也波及 3 个基表： performance_schema.data_lock_waitsperformance_schema.data_locksinformation_schema.INNODB_TRX揭晓答案：引发问题的罪魁祸首就是 8.0 中的 performance_schema.data_locks 表。从两个版本的视图定义比照能够看到，performance_schema.data_locks 的前身是 information_schema.innodb_locks。咱们 再来看看这两个表的行为有什么不一样？MySQL 5.7 中，information_schema.innodb_locks 蕴含这些数据： InnoDB 事务已申请但未取得的锁。InnoDB 事务已持有并且阻塞了其它事务的锁。官网文档形容如下： The INNODB_LOCKS table provides informationabout each lock that an InnoDB transactionhas requested but not yet acquired, and each lock that a transaction holdsthat is blocking another transaction.MySQL 8.0 中，performance_schema.data_locks 蕴含这些数据： InnoDB 事务已申请但未取得的锁。InnoDB 事务正在持有的锁。官网文档形容如下： The data_locks tableshows data locks held and requested从官网文档的形容能够看到两个表的不同之处： ...

共事提了个需要，如下测试表，有code、cdate和ctotal三列，select * from tt; 当初要失去code的惟一值，但同时带着cdate和ctotal两个字段。 提起"惟一值"，想到的就是distinct。distinct关键字能够过滤多余的重复记录只保留一条。 distinct反对单列去重和多列去重，如果是单列去重，扼要易懂，即雷同值只保留1个，如下所示，select distinct code from tt;多列去重则是依据指定的去重列信息进行，即只有所有指定的列信息都雷同，才会被认为是反复的信息，如下所示，code、cdate和ctotal都雷同，才会返回记录，因而不是字面上的了解，即只有code是distinct的，cdate和ctotal无需关注。实际上当distinct利用到多个字段的时候，其利用的范畴是其前面的所有字段，而不只是紧贴着它的一个字段，即distinct同时作用了三个字段，code、cdate和ctotal，并不只是code字段，select distinct code, cdate, ctotal from tt;而且distinct只能放到所有字段的后面，如果像这种，distinct之前有其它字段，则会提醒谬误， select cdate, ctotal, distinct code from tt;SQL 谬误 [1064] [42000]: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'distinct code from tt' at line 1然而如上SQL应用distinct关键字，并没有满足需要，即失去code的惟一值，但同时带着cdate和ctotal两个字段，能够看到有很多雷同的code。 除了distinct，group by子句也能够去重，从需要的了解上，如果依照code做group by，应该就能够失去惟一的code了，然而理论执行，提醒这个谬误， select code, cdate, ctotal from tt group by code;SQL 谬误 [1055] [42000]: Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'test.tt.code' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by很常见的谬误，因为sql_mode中含only_full_group_by规定， ...

摘要：随着数据智能时代的到来，多云多源架构下的数据管理是企业必备的基础设施，咱们认为数据存取、数据集成与散发、数据安全与数据品质是根底，也是走向多云多源架构的终点。本议题介绍云原生的多云多源数据管理NineData，重点介绍MySQL、ClickHouse相干的数据管理和复制技术。  2023首届云数据库技术沙龙 MySQL x ClickHouse 专场，在杭州市海智核心胜利举办。本次沙龙由NineData、菜根倒退、良仓太炎共创联结主办。本次，玖章算术技术副总裁陈长城（天羽），为大家分享一下《多云多源下的数据复制技术揭秘-NineData》的技术内容。 本文内容依据演讲录音以及PPT整顿而成。 陈长城（天羽），玖章算术技术副总裁，前阿里云资深技术专家，在数据库畛域深耕15年，主导了阿里数据库基础架构演进（IOE到分布式、异地多活、容器化存计拆散）和云原生数据库工具体系建设。 我接下来这个分享主题：多云多源下的数据复制技术揭秘-NineData，次要是波及到产品和技术解读，对大家来讲，了解会更加轻松一些。 大家好。我是陈长城，来自玖章算术团队。咱们团队的使命是让每个人用好数据和云。咱们团队中很多是来自阿里、华为和IBM等资深技术专家。咱们的 CEO 叶正盛曾负责阿里云数据库事业部产品治理和解决方案事业部的总经理。而我集体之前在阿里工作了十多年，次要负责整个基础架构 PASS 层的演进，以及云原生数据库的工具体系建设。 接下来，我先介绍本次的分享议程。首先是探讨多云时代和数据时代下，企业数字化转型所遇到的时机和挑战。随后，我将介绍NineData的产品平台，重点介绍NineData的数据复制技术，以及分享两个典型的客户案例。 首先，咱们来看一下Gartner的报告。该报告显示，80%以上的企业会抉择多云或混合云。从Percona报告显示，超过70%的企业会抉择应用多种数据库来应答多源数据的状况。在行业的剖析报告中，咱们发现，如果企业可能无效应用多源基础架构和新的数据架构，它们的创新能力和整体盈利能力将会显著晋升。然而，在这个新的多云和数据时代下，企业还是面临着一些问题，例如数据孤岛、多源数据管理复杂度以及开发效率等，目前是急需解决的。 如果明天去看企业整个数据治理和数据管理，各方面波及的问题是十分多的。从 NineData 角度登程，咱们应该思考如何解决这些问题。 咱们是这样思考的，在整个企业数据管理过程中，通过内置平安能力来晋升企业的开发效率和安全性。这包含企业数据库的设计、开发、变更和公布的残缺生命周期中实现平安。同时，应用多源数据复制技术促成数据流动；通过数据备份技术和在线查问技术爱护企业的数据资产，进步冷数据的数据价值；通过翻新技术办法，既能爱护数据资产，也能进步数据的价值。此外，咱们能够通过构造比照、数据比照和多环境数据比照等技术手段来进步企业的数据品质。 上面我的第二个话题，探讨的是整个NineData数据管理平台的次要架构。底层是一个基于多云和多源的基础架构设计，而咱们的外围四大功能模块，如备份、复制、比照和SQL开发，曾经在之前介绍过了。接下来，我会从多源和多云这两个角度来介绍整个平台。 从多云架构来看，NineData最次要的目标是帮忙企业对立治理扩散在多云或混合云的各种数据源。为此，咱们设计了灵便的云原生架构、弹性架构、网络结构等，让企业可能治理扩散在各个云厂商和线下的数据源。同时，咱们通过专属集群的技术，可能让企业独享自身的资源。包含咱们能够把企业的worker节点搁置在企业本地或VPC外部，实现数据的外部闭环，进步企业数据安全和worker执行效率。 咱们能够看到，NineData 作为一个云原生的 SAAS 产品，按需拉起、弹性伸缩是最根本的能力。 针对企业的网络方面，因为很多客户不违心或不心愿裸露数据库的公网端口，特地是对于要害数据。因而，咱们设计了一个数据库网关，通过这种设计，用户只需起一个咱们的数据库网关，就可能连贯咱们的核心治理节点，从而建设反向拜访通道，可能把散落在各地、以及包含外部的数据源的对立治理。此外，咱们的NineData worker也能够放到用户本地，实现数据链路的外部闭环，而治理链路就能够通过核心的控制台治理实例级别的工作，整个数据通道都在用户本地外部，实现对立治理。 在多源方面，咱们次要设计了一个数据的对立接入层。为了接入泛滥数据源，咱们对整个数据源进行了形象，并对其属性配置、连贯检查和平安认证等方面做了一个包连贯治理在内的对立形象。这样能够将所有的数据源对立接入，并基于上述四大次要功能模块，都应用雷同的数据源进行接入，实现一次接入所有性能都可用。对于用户来说，将所有的数据源注册后，最重要的是可能实现对立治理。 因而，我接下来会介绍 SQL 开发的相干内容。NineData 心愿可能通过咱们的产品进行企业在线数据的治理、查问以及整个数据开发到变更公布的生命周期的可能进行对立治理。因而，NineData 个人版更像相似于 MySQL Workbench，或者是Navicat这种的客户端工具等，只不过咱们是一个 SAAS 版的性能。将来，咱们也会推出客户端版本。对于企业版，咱们心愿可能通过可视化的界面来晋升企业效率，进行数据库设计、开发和变更公布，同时在整个生产过程中内置平安和权限能力。 如何晋升集体和团队的效率？实际上，在企业外部有多个环境，这些环境心愿可能进行构造同步等操作。不同环境之间可能存在不同级别的要求。例如，对于麻利的业务，您可能心愿缩小治理，以便更快地翻新。而对于一些外围业务，您会更加重视稳定性和权限治理。 对此，NineData 制订了许多 SQL开发标准，涵盖了各种状况，例如大批量数据变更如何判断是否会影响生产数据库的稳定性，并进行隔离和阻断；对于表构造变更，如何判断Online DDL是否会减少大的负载等。此外，咱们反对用户定义平安执行策略，并提供了超过90个开发标准模板，反对用用户应用模板，或者自定义的形式。 NineData SQL开发始终致力于晋升用户的效率。目前，智能化如业界十分火的ChatGPT，咱们也是基于这种大模型的技术，去增强了NineData的整个产品能力，晋升面向用户的效率能力。次要体现在用户只须要基于一个数据源，通过实时对话的模式就能够疾速查问所需数据。例如，用户能够轻松查找薪资超过肯定数额的员工。同时，对于数据库同学而言，NineData也反对SQL语句的优化和表构造的优化。欢送大家体验，还是会十分惊喜。 接下来我将重点介绍NineData在数据复制方面的一些技术。在多源多云的数据复制方面，次要的挑战在于数据库的类型十分多，以及每种数据库背地的数据类型、数据结构也是独立设计的。因而，如何实现数据间的联动，使其可能自在流动，是一个很大的挑战。同时，许多云厂商提供了丰盛的数据源，但它们之间存在轻微或者大的差异。在客户业务倒退过程中，许多企业的数据中心和国际化业务等，可能须要波及逾越长距离的数据拓扑。 如图下方所示，是一个典型的数据复制链路拓扑，当您配置完源和指标之后，NineData 就会让整个链路开始运行。一开始会有一个预查看，查看您的网络连接、账号密码等是否正确。接下来会进行迁徙构造，抓取和写入全量数据和增量数据。咱们的产品设计理念是心愿它能反对多源和多种数据源接入，并具备很好的可扩展性。当新的数据源接入时，它可能很不便地接入。方才咱们介绍了许多不同的数据源，它们之间存在一些渺小的差异。因而，为了确保整个同步链路可能长期稳固地运行，咱们也是重点去建设其可观测性和可干涉性。 在整个传输内核模块中，最根本的能力是确保一致性，这也是咱们的底线。另外，还须要具备高吞吐量和低延时能力。接下来，前面的分享也会围绕这几个点进行开展。 对于NineData整个模块的架构，咱们方才曾经进行了简略的介绍。相比业界其余产品，咱们会在性能采集、异样解决、数据一致性等方面进行大量投入。 首先，咱们来看一下吞吐能力。以全量性能为例，假如咱们在源端有一些数据须要解决，其中有许多表，而且它们的数据量都不同。如果咱们同时启动三个并发线程进行解决，那么可能会呈现一些数据量小的表曾经解决完了，然而一些数据量较大的表依然在期待单个线程进行解决的状况。如果表级并发，就会相似的问题。因而，为了进步整个效率，咱们必须加强表内的并发能力。具体来说，咱们须要思考表的切片是否平均。为此，咱们制订了一项策略，即默认组件反对一键拆分，顺次通过主键、非空惟一键、可空惟一键、一般键等这种程序反对拆分，以尽力最平衡的形式实现并发解决。 那么在源端的抓取性能可能达到良好的时候，并且它能够线性扩大之后，吞吐量的瓶颈可能不在通道上，而在指标库的写入上。因而，在指标库的写入姿态就是十分重要。如果每条SQL都须要在指标端进行解析，那么性能必定会很差。因而，咱们须要采纳一些批量提交的形式。同时在解决压缩开关时，须要留神CPU的数量。在CPU数量较少的状况下，启用压缩会对性能产生较大的影响。在咱们的测试中，如果CPU数量可能超过四核，则开不开压缩的影响将比拟小。 在应用过程中，您可能会遇到一些问题。例如，在平时进行并发写入时，在源端如果您将100G的数据写入，在指标端它可能会变成150G。这是因为如果单个表乱序提交的话，就可能会产生一些数据空洞。为此，NineData在切片大小和并发程序方面进行了一些优化。 因为整个全量复制是单端写入而且疾速流入指标，这个数据就被淘汰了。所以整个JVM的参数上做一些针对性的优化，也是基于整个全量数据复制的模型自身具备这种特点。 第二个局部是低延时，那么如何构建低延时呢？咱们从两个角度思考，一个是整个通道的性能角度，包含一些如Batch、热点数据的合并等。其中热点数据的合并，如果一条记录从A1改到A2，再改到A3，个别同步模型是全轨迹批改，但开启热点能力后，它可能间接映射A3，不会插入A1或update A2，通过这种能力间接以终态的数据写入，在内存中把这个队列间接合并掉。在性能层面，还有一些技术利用。例如，咱们能够是在redis的复制链路中，缩小队列的序列化代价，从而让整个队列的耗费降到最低。 在整个治理层面，对于整个低提早的零碎也十分重要，这是在咱们多年的实际中得出的教训。举两个例子，一个是数据库呈现提早，然而数据服务端的日志曾经被革除；作为咱们云原生的产品，咱们会怎么做呢？咱们会拉取用户的接口，查看是否存在被上传到OSS或者其余对象存储的日志。如果有，咱们会主动获取并接续上之前的记录，从而防止从新进行全量拉取，缩小延时。 此外，咱们还会记录平安位点。假如有16个并发写入指标库，每个并发都提交不同的库表和记录。在记录位点时，咱们应该记录这16个中最慢的那个，以防止数据失落。这意味着其余15个并发运行得更快。如果产生异样宕机并重新启动的时候，就会呈现这样的问题：疾速运行的几个线程会从新回放它们已经运行过的数据。导致用户感觉这个是数据回退了。 因而，咱们当初曾经做了两个优化。首先是表级位点，每张表都会有一个本人最新的位点。如果在回放过程中，这张表的位点已经被应用过，咱们会将其摈弃，以防止位点回退。第二个优化是针对失常的运维操作，它会使队列中的所有数据都提交实现，使得16个线程达到一个统一的位点，而后再敞开过程。通过这种能力，咱们实现了一个洁净的cleandown，用户重新启动后就不会遇到须要回放数据，这是十分优雅的形式之一。 在保障一致性方面是比拟重要的，有两个关键点须要思考。首先，是数据自身的一致性问题。举个例子，假如咱们有T1到T5这五个事务，其中B1是订单状态，从B1创立订单，到B3可能是用户付款，这时会产生一个物流订单L。如果咱们采纳失常的行级同步形式，订单和物流订单会别离存储在不同的表中，也就是不同的队列中。然而因为行级的并发性，无奈保障它们的程序性。因而，B1和L可能同时呈现在指标库中，也就是说在创立订单时，物流订单也曾经被创立了。对于在线业务来说，这必定是违反业务逻辑，无奈反对在线业务的失常运行。 因而，咱们构建了一个事务一致性能力，用户能够开启事务能力。当用户开启事务能力时，咱们会查看T3这个事务中的每条记录与之前所有事务是否存在依赖关系。如果存在，T3将期待其余事务都提交结束后再提交，确保数据的一致性。因而，第一次提交只会提交T1到T4，T3会期待T2提交结束后再提交。这是一种保证数据一致性的同步机制。 第二个问题波及到reader解析端的一致性。具体来说，以表构造为例，如果咱们遇到了表构造的变更，个别的解决办法是查看源端的表构造。然而，因为数据日志中大部分只有数据和表名，短少构造和类型等信息，因而咱们须要回查数据源来获取构造信息，并拼接出最终的后果。然而，很可能在回查时源端曾经产生了第二次DDL，导致咱们获取到的是曾经又被批改过的DDL，从而拼接出的数据不统一和呈现谬误。 因而，咱们开发了一种DDL解析能力，即在DDL解析实现后，间接在同步线程解析线程中进行重放。同时，咱们记录每个变更的版本，重放的同时生成新版本，旧版本不删除。这样，任何表在任何时刻都能够随时查到其Meta构造，而不须要像其余业界实际一样，须要从头开始从新回放一遍，这种形式对于问题诊断的难度很高，无奈获取最新的或过后Meta的状态。 在数据比照方面，咱们NineData将其作为一个重要的产品能力对外展现，因为咱们认为数据比照对整个数据品质的影响十分重要。因而，在构造比照、数据比照以及勘误SQL生成等方面，咱们在性能上做得十分全面。其次，咱们会思考数据比照对用户的源库和指标库带来的负载。这些负载对于许多生产人员来说十分重要。因而，咱们制订了许多策略，例如：仅对不统一的数据进行复检，能够管制并发和限流，设置抽样比例和条件过滤，仅对某一范畴内的数据进行比拟等等。同时，在性能方面，咱们也做了一些工作。因为如果拉出源和指标的所有数据，就会消耗大量计算资源和带宽，因而咱们须要做比拟优雅地计算的下推。 在可扩展性方面，如何在NineData外面反对疾速的新增数据源？意味着咱们须要疾速反对构造和数据类型的转换，以及疾速将通道产品化，这些都是咱们的目前重要的思考因素。咱们的整个设计思路就心愿说，把原来的各种源到指标的这种N乘M的这种拓扑办法，可能通过N加M的这种形式来实现。 咱们先讲一下数据类型，因为数据类型可能会对于最终一致性，大家会更加的在意，业界无论是在FiveTran、Airbvte、NIFI、NineData等方面的开源我的项目或者还是商用我的项目中，都定义了很多两头类型。明天，NineData 也是定义了一些两头类型，因为两头类型形象得越好，它的品种就越少，这意味着新增的数据源咱们须要开发convert 的工作量就越少。因而，如何更好地形象到更少的样本集里，是整体更好的形象办法。 第二个插件化的事件，是咱们提供了一个叫做关系数据提交框架。要实现足够的插件化，意味着咱们底层须要在各个中央都提供一些框架来晋升整体的复用能力。例如，当所有数据进入咱们的writer时，提交时都要思考DDL和DML是否须要期待。确保表构造曾经变更反对完，再把后续的DML放过来。此外，库级别和表级别都会有一些DDL的内存构造用于实现锁抵触的排序。其实，表级别外面是放在同一张表中的DML，这意味着咱们能够进行攒批来优化SQL使得写入次数更少。在行级别操作中，如果是同一个UK，那么能够进行热点合并，如后面所述。这样的框架形象能力使得前面接入的数据源能够人造地具备这些能力。同时，在数据流动过程中，还能够去构建事务依赖拓扑关系，以判断数据是否能够提交，以及后面的数据是否曾经实现。 明天是MySQL和ClickHouse技术专场，咱们也是在这两方面进行了大量的实际。因为MySQL与ClickHouse在数据类型方面差别还是比拟大的，ClickHouse反对的引擎类型也很多。首先来看下引擎的抉择，咱们也调研了包含MaterializeMySQL和相似Airbyte等业界实现。咱们认为，尽管ReplacingMergeTree能够实现，它也是MaterializeMySQL外部应用的引擎，尽管MaterializeMySQL在查问方面做了一些封装，然而如果没有足够的查问封装，因为不同厂商的两头同步工具在version和sign等值方面存在差别，最终会使得用户的查问后果可能不同。 这个CollapsingMergeTree的sign能够取-1或1，针对你的增删改查操作，增量复制中能够天然地进行映射。因而，咱们第一次是实现了这个CollapsingMergeTree，通过它能够将数据同步到预期指标。在实践中，咱们发现一些客户仍在应用ReplacingMergeTree，因而咱们也对此进行了反对，这样就提供了两种形式。 在ClickHouse中数据类型绝对较多，可能比相似MySQL的云原生类型更多。因而，在进行类型映射时有许多抉择，同时也有许多默认值。如果您不将其指定为"NA"，则可能会呈现一些初始值，例如对于"point"类型，它可能是"00"。这些行为可能会导致用户在源和指标数据比照时，发现数据存在差别。 在提交过程中，通道的性能上，相似于Airbyte的做法会将所有增量数据合成一个文件，因为ClickHouse引擎中的许多增删改都是变成间接减少，因而这种形式绝对简略。但这种形式会带来较大的提早。因而，在实现过程中，咱们思考应用SQL的形式进行提交，来了多少条就立刻转集批提交，能够动静地管制，例如超过1000条或0.5秒”，能够几百毫秒就提交。此外，ClickHouse的Jdbc在解析每条语句时性能较差，因而咱们进行了一些优化，采纳批量提交的形式来进步性能。 接下来，我将介绍“可观测性”和“可干涉能力”这两个方面。因为各个类型特地多，例如，在同步过程中，用户可能会在指标端、新的写入等可能会遇到一些问题，导致这个两边写数据抵触等。因而，咱们在可观测性方面不仅会将根本状态齐全走漏给用户，还会提供每个线程提交的语句。例如，如果有16个线程正在运行，咱们会显示这16个线程别离在执行哪条SQL，或者工作是否被DDL卡住等信息。能够通过相似于MySQL Processlist的形式查看每个线程正在执行哪些操作，曾经执行了多长时间等信息。 在“可干涉能力”方面，咱们也作为重点建设，因为在同步过程中，用户可能须要增加新的对象到同步链路中，或者遇到一些异常情况须要进行干涉。或者须要进行重写并提交操作等，这种问题也是常常会遇到的。 ...

业务场景个别在我的项目开发中会有很多的统计数据须要进行上报剖析，个别在剖析过后会在后盾展现进去给经营和产品进行分页查看，最常见的一种就是依据日期进行筛选。这种统计数据随着工夫的推移数据量会缓缓的变大，达到百万、千万条数据只是工夫问题。 瓶颈再现创立了一张user表，给create_time字段增加了索引。并在该表中增加了100w条数据。 咱们这里应用limit分页的形式查问下前5条数据和后5条数据在查问工夫上有什么区别。 查问前10条基本上不耗费什么工夫 咱们从第50w+开始取数据的时候，查问耗时1秒。 SQL_NO_CACHE <br/>这个关键词是为了不让SQL查问走缓存。同样的SQL语句，不同的分页条件，两者的性能差距如此之大，那么随着数据量的增长，往后页的查问所耗时间按理睬越来越大。 问题剖析回表咱们个别对于查问频率比拟高的字段会建设索引。索引会进步咱们的查问效率。咱们下面的语句应用了SELECT * FROM user，然而咱们并不是所有的字段都建设了索引。当从索引文件中查问到符合条件的数据后，还须要从数据文件中查问到没有建设索引的字段。那么这个过程称之为回表。 笼罩索引如果查问的字段正好创立了索引了，比方 SELECT create_time FROM user，咱们查问的字段是咱们创立的索引，那么这个时候就不须要再去数据文件外面查问，也就不须要回表。这种状况咱们称之为笼罩索引。 IO回表操作通常是IO操作，因为须要依据索引查找到数据行后，再依据数据行的主键或惟一索引去聚簇索引中查找具体的数据行。聚簇索引个别是存储在磁盘上的数据文件，因而在执行回表操作时须要从磁盘读取数据，而磁盘IO是绝对较慢的操作。 LIMTI 2000,10 ？你有木有想过LIMIT 2000,10会不会扫描1-2000行，你之前有没有跟我一样，感觉数据是间接从2000行开始取的，后面的基本没扫描或者不回表。其实这样的写法，一个残缺的流程是查问数据，如果不能笼罩索引，那么也是要回表查问数据的。 当初你晓得为什么越到前面查问越慢了吧！ 问题总结咱们当初晓得了LIMIT 遇到前面查问的性能越差，性能差的起因是因为要回表，既然曾经找到了问题那么咱们只须要缩小回表的次数就能够晋升查问性能了。 解决方案既然笼罩索引能够避免数据回表，那么咱们能够先查进去主键id（主键索引），而后将查出来的数据作为长期表而后 JOIN 原表就能够了，这样只须要对查问进去的5条后果进行数据回表，大幅缩小了IO操作。 优化前后性能比照咱们看下执行成果： 优化前：1.4s优化后：0.2s查问耗时性能大幅晋升。这样如果分页数据很大的话，也不会像一般的limit查问那样慢。

摘要：MySQL在充分利用多核计算资源方面比拟欠缺，无奈同时满足在线业务和剖析型业务的客户需要，而独自部署一套专用的剖析型数据库意味着额定的老本和简单的数据链路。本次主题将介绍腾讯云数据库为满足此类场景而在HTAP for MySQL产品方面进行的尝试。 2023首届云数据库技术沙龙 MySQL x ClickHouse 专场，在杭州市海智核心胜利举办。本次沙龙由NineData、菜根倒退、良仓太炎共创联结主办。本次，腾讯TEG数据库产品部高级技术专家陆洪勇，为大家分享一下《HTAP for MySQL 在腾讯云数据库的演进》的一些技术内容。 本文内容依据演讲录音以及PPT整顿而成。 陆洪勇，腾讯TEG数据库产品部高级技术专家，曾在 SAP 做过多年HANA数据库内核的设计与研发，阿里云 Polardb 数据库内核的设计与研发。目前在腾讯云数据库做 HTAP for MySQL 相干产品的设计与开发。 明天我来讲一下，HTAP for MySQL 在腾讯云数据库的演进。次要介绍的内容如下：首先介绍一下产品背景，而后会介绍产品的两个重要性能，第一个是并行查问，第二个是列存索引，这也是MySQL能力晋升的最重要的两个方面。 这个产品实际上是咱们所提到的私有云，私有云的概念大家都比拟相熟。其中一个产品是 Tencent DB for MySQL，这是一个基于 MySQL 开源的托管产品。相似的产品还有阿里云的 RDS。这是一个典型的、传统的 MySQL 主从复制架构，通过 binlog 进行数据复制。每个节点都有本人的日志和数据。 另一个产品是咱们的云原生数据库产品 TDSQL-C，它有两个根本特点：资源池化和极致弹性。在这个产品中，咱们应用了分布式共享存储来存储数据，而 CPU 和内存等资源也将实现相应的池化，后续咱们还会陆续推出相应的产品。极致弹性能力在于应用了共享存储，所以咱们每一个只读节点，能够很容易的挂载上来。同时，共享存储也很容易进行扩容和缩容，这是咱们产品的根本背景介绍。 首先，咱们通过对大量重点客户在大盘上的剖析，发现客户存在两大痛点。其中，第一个痛点极其重要，即稳定性问题。第二个痛点是慢查问，这是一个十分令人头疼的事件。慢查问的起因有很多，比方用户没有为某些查问创立索引或者索引未命中。另一个更为广泛的起因是MySQL单核解决能力在数据量较大时的瓶颈。 针对这些问题，业界提出了几种解决方案。第一种是进步多核解决能力，包含多节点并行查问和MPP。第二种是进步指令执行效率，其中一种办法是向量化执行，包含SIMD指令，另一种办法是JIT编译，目前在一些商业数据库用的还比拟多一点。第三种是进步信息密度，因为行存数据库中数据之间的相似性较低，因而须要进行一些压缩或批量解决是比拟难的，另一个解决方案是应用列式存储。 在业界中，部署模式也存在相似的三种。其中一种是两头键模式，即在MySQL集群中构建一个中间件，通过中间件进行分布式查问剖析和并发执行，最终的执行片段会下压到每一个的MySQL节点下来，这样MySQL可能把剖析型能力可能解决，其中阿里云Polardb-X产品就是比拟典型的例子。另一种是专有的AP零碎，该零碎建设在MySQL之外独自建设一个剖析型零碎，包含ClickHouse是比拟好的一个计划，通过 binlog 或者其余的模式进行日志同步，相当于提供专用的日志剖析，将失常数据或TP数据通过MySQL，剖析的话就通过AP进行解决。咱们的产品其实是想在MySQL自身构建并行查问和AP能力，使用户可能无需感知咱们的底层操作，不会对业务造成侵入，同时取得十分大的性能晋升。 首先，在下面的这个过程中，咱们进行了并行查问的演进，而上面一排是对于列式存储和引擎的演变。这两个性能是独立开发的。而后，在去年的六七月份，咱们将这两个技术交融，使得咱们的私有云产品上，MySQL和云原生产品具备了并行查问和列存框架。这样一来，用户能够享受到极大的执行效率晋升。  这个框架的交融之后，咱们的两个团队能够继续扩大各自的能力，所以前面的扩大很容易被整合进这个框架外面。例如，咱们在列存做的向量化解决和delta store等，都能够很容易地被排汇到这个执行框架中。只有将这些性能合入到框架中，用户就能够充沛体验到这些带来的性能劣势。  在2021年底，咱们做了一个列存索引的性能，相当于创立了一个  InnoDB的索引，数据能够通过异步传输同步到列存中，以实现数据及时同步。前面咱们会有一个具体框架，能够看下咱们是怎么做的。 首先，咱们来介绍一下并行查问， 咱们举了一个示例，从TPCH中选取了一个简略的查问语句进行测试。在MySQL一般执行下，该查问须要约64秒的工夫。而在应用并发查问后，四个DOP、四个worker只须要16秒的工夫。能够看到并行查问的效率晋升是线性的，达到了四倍。这是MySQL原有的执行打算，咱们能够看到每个worker线程都有一个sender节点，用于数据发送。最终数据会在gather层进行汇总。这是一个典型的并行执行打算。上面是并发查问的状态，能够通过 show process 进行查看。 这里咱们介绍一个具体的实现计划。在MySQL中，有一个比拟艰难的计划须要打算切分，这是因为在传统的数据库中，如我之前从事的HANA数据库，生成的打算与数据是拆散的，因而plan在传输到其余worker线程时很容易实现。然而MySQL是比拟难的，次要在于传统开发模式导致了打算和数据的耦合，使得间接进行plan拷贝十分艰难。前面咱们简略介绍下包含业界罕用的三种计划。而后咱们看一下这样简略的一个plan，举个例子，比方咱们table scan上有一个聚合数据的表，通过打算切分后，咱们会在worker线程上增加一个并行执行的节点，而后再下层增加一个receiver节点来汇聚后果。如果有更多的worker，切分的数量也会相应减少。 第一个计划是将来自SQL的逻辑打算和物理打算顺次生成，而后将物理打算拷贝到并行worker现场上。这须要对每一个MySQL执行打算外面波及的数据结构全副做克隆操作，且工作量微小，据咱们理解，以后私有云上TOP厂商中，至多有两家采纳了这种计划。不过这种计划存在一些问题，其中厂商投入了大量人力和物力，而另外对MySQL的代码进行了大量的入侵。在前期，你很难跟上社区的，因为社区在一直做代码重构。 第二种计划实际上是一种更常见的商业数据库计划。当SQL语句达到时，它将生成一个逻辑打算，并通过拷贝一些环境数据到worker线程，从而生成一个执行打算。这是一个很自然而然的操作。咱们目前采纳了这种计划，并通过它实现了比其余友商更好的成果，而且只用了他们1/4的人力和工夫。这并不是吹牛，如果有机会大家能够试一试。咱们之所以可能采纳这种计划，而其余友商采纳了其余的计划，一方面是因为咱们从社区中取得了一些教训和技术红利，另一方面是因为咱们参加了社区的构建。社区在一直重构SQL构层，将逻辑打算和物理打算拆散，通过 iterator机制拆分得更清晰，这为咱们提供了根底，使咱们可能实现这项工作。 第三种计划应用较少。当SQL生成逻辑打算并生成执行打算时，对于须要执行不同的物理打算片段，该计划通过反向编写成SQL语句的形式来实现。而后，将SQL语句发送到不同的worker线程上，这些线程可能是ClickHouse。因为ClickHouse无奈间接执行MySQL执行打算，因而将SQL语句发送过来，就可能执行了。咱们之前也已经尝试过应用反写SQL的形式，然而与第一个计划相比，工作量并不见得小，因为基本上必须要把整个执行打算反向一遍。因而，咱们采纳第二种计划实现了十分好的成果。 咱们能够看一下，在TPCH 100G上的性能体现。在DoP为16的状况下，咱们基本上有十倍以上的性能晋升。咱们还有一些能力临时不反对，因而没有进一步晋升。然而，基本上可能达到线性晋升，因为当初是16DoP，咱们有大概十倍的性能晋升，这样的成果非常明显。 通过咱们的并行查问的介绍后，咱们想简要提一下咱们投入最大的产品——列存索引，咱们冀望这个产品将来可能为用户带来更好的成果和应用体验。在列存索引的友商市场上，咱们进行了剖析比拟了Oracle、SQL Server、 TiFlash、MySQL HeatWave等多款产品，综合各家之长，并联合咱们本身技术，咱们胜利设计了列层索引架构。 列层索引架构，相当于这是一个RW节点，这是一个只读节点，在只读节点上为每张表创立了一个列存的索引，然而咱们晓得 InnoDB 一个索引最多只反对16个列。相比之下，咱们的索引扩展性十分强，反对最多256列。咱们也意识到，在剖析型数据处理过程中，大宽表是常态，因而在将来可能须要反对更多的列。 当数据插入时，咱们会通过一个redo log以物理复制的形式将数据同步（同步和异步均可）到列存索引中。而后，咱们通过Delta Store进行并行的回放，实现高效的数据插入。 在这个框架中，咱们有一个OLAP执行器，这个就是MySQL本身的执行器，然而咱们应用的是对立的优化器，能够调度执行打算，使得哪一部分在列存执行，哪一部分在行存执行。因为列存索引一直演进，其性能可能会一直扩大，因而当整个的plan过去的时候，不能齐全在咱们的列存执行，那咱们就有一些须要在行存执行，所以以后咱们须要混合的执行框架，以实现更好的成果。 在计算过程中，咱们也会用到并行计算，刚刚提到的并行计算是MySQL自身，那咱们在列存外部的话，咱们也在构建这样的一个能力。在将来，我冀望可能通过们的优化器对查问语句进行整体优化，在咱们这里执行整个剖析过程，以提高效率和准确性。此外，咱们还将引入AVX512向量化执行，进一步提高性能。 这是简略过一下语句例子，比如说这是一个 Nested Loop Join，如果当初只有这个第一条语句table scan和filter能到列层外面去执行，那咱们这个执行框架是怎么做的呢？首先一条语句来了之后，它会通过这个优化器会生成混合的一个执行打算。执行打算就会把这个精细化，放到这个执行调度里边去。而后会把其中波及到列存执行的plan，通过这个下压接口层下压到Cstore的执行器，执行器外面咱们会并行执行，也会进行一些原数据。例如索引数据和毛糙索引，以过滤掉一些大数据块，从而晋升效率。此外，咱们还有SIMD 的指令的执行，最终会把后果返回到行存，从而会失去最终的后果。从这里咱们能够看出，咱们是一个混合的执行框架。 在咱们的执行引擎框架中，咱们应用了SIMD指令，即单指令多数据，这是引擎中一个十分重要的局部。咱们有两张图，第一张图显示了咱们采纳了SIMD指令和没有采纳SIMD指令但采纳了批处理 （即一次解决4096行数据）的性能比拟。咱们从TPCH中抽取了一部分数据，大略能够看到咱们晋升了 5 倍左右的性能，这阐明SIMD指令的成果非常明显。SIMD应用的是英特尔本人的指令集，例如对于一个INT8类型的计算，如果应用一般的指令，一条指令只能执行 INT8 加 INT8。然而如果应用英特尔512的AVX512指令，一条指令就能够计算64行数据，因而效率晋升是十分高的。 另外一点，就是咱们不采纳SIMD的指令，采纳了批处理形式一次解决4096行数据，另一种比照形式就是一行一行的执行，咱们发现采纳批处理形式能够使性能晋升约五倍左右。两者再联合的话，性能晋升将更为显著，预计至多能够晋升25倍以上。下面的测试，咱们在TPCH 100G的测试场景下进行。 接下来，看下通过联合列存索引和并行查问的plan状况，这是TPCH Q3一个语句。在这个打算中下面是一个聚合层（协调者），底下是有多个 worker 线程。最底下是列存执行的一个打算，而下面则是行存执行的打算。这个打算十分好地体现了咱们将行列存储的长处相结合，并退出了并行查问的能力。这样做的后果就是咱们具备了整合多方长处的能力。 咱们在列存中有一个十分重要的一点，那就是Delta Store。为什么咱们须要Delta Store呢？当你进行一个并行回放的时候，数据是通过REDO Log同步到列存中的。而Delta Store可能提供高效的数据插入，因为它能够在内存中一直地open only将数据往后插入。这样做的益处是，它可能进步行级并发，同时咱们还有一个insert / delete mask，这使得咱们在列存中具备了MVCC的能力。联合咱们在MySQL上的SCN机制，咱们就可能提供残缺的事务视图，从而实现完整性的事务查问。当数据插满后，咱们会将其解冻并把它download到磁盘下来进行压缩，当一些数据会永恒的被被删掉了，或者说这个数据永远所有人都能看到了，咱们会进行一些空洞的compaction。而后再 merge到 main store外面去，其实有点像 LSMtree 的架构。 当初我再讲一下，咱们这个产品中并行查问局部曾经上线了，在私有云上曾经能够应用。而列存索引这部分目前正在外部灰度和一些大客户的试用中，获得了十分好的成果。只管还没有正式推出，但咱们在PQ查问的根底上，咱们又有至多三倍以上的性能晋升，这是在还没有齐全退出向量化的状况下。而如果在向量化加持之后，咱们冀望会有更大的性能晋升。 目前这个阶段的话，咱们正在做一些工作，例如并行查问在MySQL这一部分，咱们可能会做MPP。列存的话，咱们有可能会开发本人的MPP，以及包含反对大型的存储。最初，我想重点谈谈咱们的对立内核的技术空间，因为咱们晓得，私有云和公有云是不同的技术架构。私有云应用共享存储，而公有云应用分布式存储。然而咱们曾经将并行查问扩大到了公有云上，这意味着咱们私有云和公有云都应用了同一个并行框架。接下来，咱们会将列存能力扩大到公有云上。这意味着咱们一套能力能够在两个零碎上齐全复用。目前来看，咱们可能是友商中第一个实现这种对立内核的机制。 明天我的分享就到这儿，谢谢。 本次大会围绕“技术进化，让数据更智能”为主题，汇聚字节跳动、阿里云、玖章算术、华为云、腾讯云、百度的6位数据库领域专家，深刻 MySQL x ClickHouse 的实践经验和技术趋势，联合企业级的实在场景落地案例，与宽广技术爱好者一起交换分享。

如果你的查问中用到了索引，这是一个提高，如果可能更进一步，用到了笼罩索引，那么就更牛了！当咱们设计一个索引的时候，如果可能从一个更加全面的角度去设计这个索引，不仅思考到 where 中的条件，还可能思考到整个 SQL，那么无疑这个索引的设计将是十分胜利的。 当然不能为了笼罩而笼罩。1. 什么是笼罩索引要了解什么是笼罩索引，咱们须要先来回顾一下 InnoDB 中索引树的数据结构。 假如我有如下数据： id(主键)usernameageaddressgender1ab99深圳男2bw95天津男3cx93深圳男4bc80上海女5bg85重庆女6ac98广州男7bw99海口女8ck90深圳男9cc92武汉男10af88北京女当初我给 username、age 以及 address 三个字段建设一个联结索引，那么这个联结索引的 B+Tree 可能是这个样子： 下面这个索引树是一个非汇集索引或者也能够说是一个二级索引，这种索引区别于咱们之前文章跟大家聊的汇集索引（再聊 MySQL 聚簇索引），在汇集索引中，叶子结点就是这一行的数据，然而在二级索引中，叶子结点中保留的是主键值。 所以，当咱们搜寻的时候，如果应用的是二级索引，那么最终拿到的是主键值，有了主键值之后，咱们还须要再去到聚簇索引中进行搜寻，能力拿到残缺的数据，这个过程咱们也称之为回表。很显著，如果进行了回表操作的话，那么执行效率显然就要降落一截，那么是否用到了二级索引就会回表呢？其实不然！如果是笼罩索引的话，就不须要回表。 那么什么是笼罩索引呢？ 小伙伴们察看下面的索引树，大家发现在这个索引树中，离叶子结点最近的树枝上有 username、age 以及 address，而叶子结点上有 id，所以如果我想要查问的字段是 id、username、age 以及 address 中的任意一个或者任意几个的话，那么就不须要再去聚簇索引上查问了，以后这个 B+Tree 上间接就有现成的，间接返回即可，这个就是笼罩索引。 2. 实际当初假如我有如下一张表： CREATE TABLE `user` ( `id` int unsigned NOT NULL AUTO_INCREMENT, `username` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL, `age` int DEFAULT NULL, `address` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL, `gender` varchar(2) COLLATE utf8mb4_unicode_ci DEFAULT NULL, PRIMARY KEY (`id`), KEY `user_prop_index` (`username`,`age`,`address`)) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;能够看到，这张表中有一个名为 user_prop_index 的索引，这个索引中一共存在三个字段，别离是 username、age 以及 address，当初咱们来看如下 SQL 的执行打算： ...

后面一篇文章，松哥和大家聊了 MySQL 中的索引合并，尽管 MySQL 提供了索引合并机制来晋升 SQL 执行的效率，然而在具体实际中，如果能防止产生索引合并是最好的，毕竟这是没方法的方法，是一个下下策。产生索引合并大概率是因为咱们索引在设计的时候就有问题，设计好联结索引，咱们就能在肯定水平上防止产生索引合并问题。 1. 联结索引1.1 什么是联结索引联结索引就是数据表中的多个字段，独特组成一个索引。因为 InnoDB 中索引的数据结构是一个 B+Tree，当是一个联结索引的时候，排序的时候会首先依照联结索引的第一个字段排序，如果第一个字段的值雷同，则依照第二个字段排序，如果第二个字段的值也雷同，则依照第三个字段排序，以此类推。 举一个简略的例子，假如我有如下数据： idusernameageaddressgender1ab99深圳男2ac98广州男3af88北京女4bc80上海女5bg85重庆女6bw95天津男7bw99海口女8cc92武汉男9ck90深圳男10cx93深圳男当初我给 username 和 age 字段建设联结索引，那么 B+Tree 在排序的时候，会首先依照 username 排序，当 username 雷同的时候，再依照 age 进行排序。画进去的 B+Tree 如下图： 如上图，bw 雷同的时候，依照 age 进行排序。 如果咱们想要在 MySQL 中，让联结索引施展最大作用，就要充分考虑到联结索引中各字段的程序。 1.2 联结索引程序要思考哪些因素？在设计联结索引的时候，咱们最容易想到的准则是查问条件影响了联结索引中各个字段的程序，要依据查问条件来设计联结索引中各个字段的程序。 实际上，除了下面提到的查问条件之外，联结索引的程序还会影响到查问的排序和分组等，所以，设计联结索引的程序能够算是一个真真正正的技术活。 2. 案例剖析松哥这里还是应用官网的案例吧，小伙伴们在公众号后盾回复 mysql官网案例 能够获取到这个数据库脚本的下载地址。 在 MySQL 的官网案例中，有一个领取表 payment，如下图： 小伙伴们从图中能够看到，这个表中有一个 customer_id 和一个 staff_id，当初假如我想要依照这两个来进行搜寻，例如执行如下 SQL： select * from payment where customer_id=1 and staff_id=2;查问条件有两个，我想建设一个联结索引，那么到底是把 customer_id 放在后面还是把 staff_id 放在后面呢？ 一个比拟罕用的法令是看字段的选择性，选择性高的字段应该是放在后面。有的小伙伴可能还不分明什么是字段的选择性，能够参考松哥之前的文章：前缀索引，在性能和空间中寻找均衡。 那么怎么获取各个字段的选择性呢？这个很好计算，一个 SQL 搞定，如下： ...

1. 连贯治理应用数据库时，不可避免的要建设很多个连贯。如果单纯用命令执行切换用户的话，切实是一件麻烦事。那么这种麻烦事就交给HHDECS好了。点击连贯治理，一键切换。而且能在不同数据库之间随便切换 2. 应用高级模式，创立新用户桌面软件首先就是要不便用户，所以此项性能也根本算一步实现。点击连贯治理，抉择高级视图右键“用户汇合”，抉择增加输出用户名及明码，设置权限即可。 3. 应用备份及复原性能，将数据转移至其余连贯首先登入连贯，右键抉择备份在弹出框中，点击浏览，抉择相应文件夹，点击确认。期待备份实现点击连贯治理，抉择须要转移的连贯登入。右键抉择复原，抉择方才备份的文件夹，点击确定，期待复原实现即可。

本文已收录至Github，举荐浏览 Java随想录微信公众号：Java随想录 摘要Join是MySQL中最常见的查问操作之一，用于从多个表中获取数据并将它们组合在一起。Join算法通常应用两种根本办法：Index Nested-Loop Join（NLJ）和Block Nested-Loop Join（BNL）。本文将探讨这两种算法的工作原理，以及如何在MySQL中应用它们。 什么是Join在MySQL中，Join是一种用于组合两个或多个表中数据的查问操作。Join操作通常基于两个表中的某些独特的列进行，这些列在两个表中都存在。MySQL反对多种类型的Join操作，如Inner Join、Left Join、Right Join、Full Join等。 Inner Join是最常见的Join类型之一。在Inner Join操作中，只有在两个表中都存在的行才会被返回。例如，如果咱们有一个“customers”表和一个“orders”表，咱们能够通过在这两个表中共享“customer_id”列来组合它们的数据。 SELECT *FROM customersINNER JOIN ordersON customers.customer_id = orders.customer_id;下面的查问将返回所有存在于“customers”和“orders”表中的“customer_id”列雷同的行。 Index Nested-Loop JoinIndex Nested-Loop Join（NLJ）算法是Join算法中最根本的算法之一。在NLJ算法中，MySQL首先抉择一个表（通常是小型表）作为驱动表，并迭代该表中的每一行。而后，MySQL在第二个表中搜寻匹配条件的行，这个搜寻过程通常应用索引来实现。一旦找到匹配的行，MySQL将这些行组合在一起，并将它们作为后果集返回。 工作流程如图： 例如，上面这个语句： select * from t1 straight_join t2 on (t1.a=t2.a);在这个语句里，假如t1 是驱动表，t2是被驱动表。咱们来看一下这条语句的explain后果。 能够看到，在这条语句里，被驱动表t2的字段a上有索引，join过程用上了这个索引，因而这个语句的执行流程是这样的： 从表t1中读入一行数据 R；从数据行R中，取出a字段到表t2里去查找；取出表t2中满足条件的行，跟R组成一行，作为后果集的一部分；反复执行步骤1到3，直到表t1的开端循环完结。这个过程就跟咱们写程序时的嵌套查问相似，并且能够用上被驱动表的索引，所以咱们称之为“Index Nested-Loop Join”，简称NLJ。 NLJ是应用上了索引的状况，如果查问条件没有应用到索引呢？ MySQL会抉择应用另一个叫作“Block Nested-Loop Join”的算法，简称BNL。 Block Nested-Loop JoinBlock Nested Loop Join（BNL）算法与NLJ算法不同的是，BNL算法应用一个相似于缓存的机制，将表数据分成多个块，而后一一解决这些块，以缩小内存和CPU的耗费。 例如，上面这个语句： select * from t1 straight_join t2 on (t1.a=t2.b);字段b上是没有建设索引的。 这时候，被驱动表上没有可用的索引，算法的流程是这样的： 把表t1的数据读入线程内存join_buffer中，因为咱们这个语句中写的是select *，因而是把整个表t1放入了内存；扫描表t2，把表t2中的每一行取出来，跟join_buffer中的数据做比照，满足join条件的，作为后果集的一部分返回。这条SQL语句的explain后果如下所示： ...

作者：卢文双 资深数据库内核研发 序言： 以前对 MySQL 测试框架 MTR 的应用，次要集中于 SQL 正确性验证。近期因为工作须要，深刻理解了 MTR 的方方面面，发现 MTR 的能力不仅限于此，还反对单元测试、压力测试、代码覆盖率测试、内存谬误检测、线程竞争与死锁等性能，因而，本着分享的精力，将其总结成一个系列。 次要内容如下： 入门篇：工作机制、编译装置、参数、指令示例、举荐用法、增加 case、常见问题、异样调试进阶篇：高阶用法，包含单元测试、压力测试、代码覆盖率测试、内存谬误检测、线程竞争与死锁源码篇：剖析 MTR 的源码语法篇：单元测试、压力测试、mysqltest 语法、异样调试因为集体程度无限，所述不免有谬误之处，望雅正。 本文是第二篇进阶篇。 本文首发于 2023-05-01 21:03:44MTR 系列基于 MySQL 8.0.29 版本（编译状况也在 8.0.32 版本验证过），且次要在 Ubuntu 22.04 X86_64 验证（局部指令也在 Ubuntu 20.04 X86_64、Ubuntu 22.04 ARM64、MacOS M1 做了验证），如有例外，会特地阐明。 前言上一篇文章《MySQL 测试框架 MTR 系列教程（一）：入门篇》介绍了 mtr 的原理、目录构造、参数及常见用法，侧重于最常见的 SQL 正确性验证，但 mtr 能做更多的事件，比方 内存谬误、线程竞争、代码覆盖率、压力测试等，本文次要介绍这些内容，波及的相干工具如下： valgrind ：用于内存调试、内存透露检测以及性能剖析。Sanitizier ：谷歌发动的开源工具集。 ASAN/AddressSanitizier ：查看内存地址相干问题，包含内存透露、开释后应用、反复开释、堆溢出、栈溢出等等问题。LSAN/LeakSanitizer ：查看内存透露问题。它是集成在 Address Sanitizer 中的一个绝对独立的工具，它工作在查看过程的最初阶段。MSAN/MemorySanitizer ： 查看应用未初始化内存的问题。TSAN/ThreadSanitizer ： 查看线程数据竞争和死锁问题。UBSAN/UndefinedBehaviorSanitizer ： 检测未定义行为（应用空指针、有符号整数溢出等）。gcov ： 代码覆盖率测试。gprof ： 性能剖析工具。单元测试压力测试本文将逐个介绍对各个工具的反对状况。 ...

@[toc]在后面的文章中，松哥和小伙伴们分享了 MySQL 中，InnoDB 存储引擎的数据结构，小伙伴们晓得，当咱们应用索引进行搜寻的时候，每一次的搜寻都是在某一棵 B+Tree 中搜寻的，如果应用了二级索引的话，可能还会波及到回表。 那么当初问题来了，如果咱们的搜寻条件中蕴含两个字段，且这两个字段都有独立的索引，那么 MySQL 会怎么解决？明天咱们就来探讨下这个话题。 1. 问题重现为了不便小伙伴们了解，我先通过 SQL 来把我的问题反复一下。 我应用的测试数据是 MySQL 官网提供的测试数据，相干的介绍文档在： https://dev.mysql.com/doc/employee/en/相应的数据库脚本在： https://github.com/datacharmer/test_db小伙伴们能够自行下载这个数据库脚本并导入到本人的数据库之中。 在官网提供的案例中，有一个这样的表： CREATE TABLE `film_actor` ( `actor_id` smallint unsigned NOT NULL, `film_id` smallint unsigned NOT NULL, `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`actor_id`,`film_id`), KEY `idx_fk_film_id` (`film_id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3;在这个表中有两个索引，其中一个是主键索引，主键索引是一个联结索引，还有一个是依据 film_id 建设的一般索引。当初假如我有如下 SQL 须要执行： select * from film_actor where film_id=1 or actor_id=1;那么问题来了，这个查问会用到索引吗？ 想晓得有没有用到索引，用 explain 关键字看一下就晓得了： explain select * from film_actor where film_id=1 or actor_id=1;执行后果如下： ...

一、零碎环境操作系统：Centos 7已装置环境：MySQL 8.0.26 二、开始操作2.1 敞开SELinux为了进步 Linux 零碎的安全性，在 Linux 上通常会应用 SELinux 或 AppArmor 实现强制访问控制（Mandatory Access Control MAC）。对于 MySQL 数据库的强制拜访控制策略通常是激活的，如果用户采纳默认的配置，并不会感到强制拜访控制策略对 MySQL 数据库的影响，一旦用户批改了 MySQL 数据库的默认配置，例如默认的数据目录或监听端口，MySQL 数据库的流动就会被 SELinux 或 AppArmor 阻止，导致数据库无奈启动。 因而，为了此次操作顺利执行，咱们须要把SELinux 关了。 setenforce 0 2.2 批改MySQL 配置文件批改配置文件前先进行备份，这是一个好习惯。 cp /etc/my.cnf /etc/my.cnf_oldvi /etc/my.cnf 批改以下的配置信息： datadir=/opt/mysql/mysqlsocket=/opt/mysql/mysql/mysql.socklog-error=/opt/mysql/log/mysqld.logpid-file=/opt/mysql/run/mysqld/mysqld.pid2.3 创立新的数据目录依据上一步的配置文件，创立对应的目录： mkdir /opt/mysqlcp -ar /var/lib/mysql/ /opt/mysql/mkdir /opt/mysql/log/touch /opt/mysql/log/mysqld.logmkdir -p /opt/mysql/run/mysqld/并批改其权限： chown -R mysql:mysql /opt/mysql/chmod 777 /opt/mysql/2.4 验证重启 MySQL 数据库： service mysqld stopservice mysqld start往数据库增加数据，查看是否切换到了新数据目录： 或者在SQL 执行界面执行以下语句： show VARIABLES like 'datadir' ...

本文首发自「慕课网」，想理解更多IT干货内容，程序员圈内热闻，欢送关注"慕课网"！ 作者：李辉 | 慕课网讲师 理解 MySQL 的数据类型是开发人员在应用 MySQL 数据库的时候，必备的根底技能之一。也正因为此，这部分常识也是面试官面试的时候每每提及的高频问题，所以尽量不要在这个中央栽跟头。 明天咱们就一起探讨下MySQL面试中的高频问题：在数据建模设计时应用十分频繁的字符串类型 – VARCHAR。 为了在浏览时不引起歧义，咱们先做一个简略的约定： MySQL 数据库版本 5.7应用 InnoDB 存储引擎默认隔离级别是 Repeatable Read默认应用 UTF8 编码1. VARCHAR (50) 中的 50 到底是能存 50 个字还是 50 个字节？ 咱们先做个简略的试验： mysql> create database imooc_mysql_interview;Query OK, 1 row affected (0.00 sec)mysql> use imooc_mysql_interviewDatabase changedmysql> create table varchar_test(col_1 varchar(8));Query OK, 0 rows affected (0.01 sec)mysql> insert into varchar_test values('ABCDEFGH'),('数一数是不是八个');Query OK, 2 rows affected (0.01 sec)Records: 2 Duplicates: 0 Warnings: 0mysql> select * from varchar_test;+--------------------------+| col_1 |+--------------------------+| ABCDEFGH || 数一数是不是八个 |+--------------------------+2 rows in set (0.00 sec)从上述试验的后果可知，显然是能存 8 个字符而不是 8 个字节，也就是说 VARCHAR 的括号中的数字代表的是字符。如果存的是字节，因为中文、英文和 emoji 在 utf-8 中的字节数都不一样，势必会给编程造成肯定的困扰。 ...

mysql_markdown是一款基于GO语言命令行工具，他能生成数据库构造文档，生成的文件为.md（markdown）格局。咱们能够通过Typora工具（一款好用的markdown编辑器）将md文件转成word，html，pdf等格局的文件。 一：下载mysql_markdown_win工具链接：https://pan.baidu.com/s/1hwgh43BcckWvbrzzJ45FCg 提取码：o4on 二：mysql_markdown_win应用.\mysql_markdown_win.exe -h 数据库地址 -u 用户名 -p 明码 -d 数据库名称 -P 端口执行后成果如下 这时候就会在当前目录生成对应数据库名的md文件

前提mysql必须有以下配置 binlog_format = rowbinlog_row_image = full # 默认是full实战假如有一张用户表，构造如下 create table tb_user( id bigint primary key not null auto_increment, username varchar(100) not null, pwd varchar(100) not null, sex varchar(10) not null);数据sql如下： insert into tb_user (username, pwd, sex)values ('张三', '123456', '男'), ('李四', '111111', '女'), ('kk', '1111', '鸡');小明一天不小心执行了delete全表的操作 delete from tb_user where id != 0;把数据全副删除了 生成回滚sql小明都想好跑路的国家了，小董出手相助，祭出明天要介绍的工具ra，github地址：https://github.com/DHBin/ra 下载地址：https://github.com/DHBin/ra/tags 数据库工具反对binlog数据闪回、binlog转sql等等反对mysql数据库版本：5.5.x5.6.x5.7.x8.0.xUsage: ra [command]Available Commands: flashback 数据闪回 help Help about any command tosql 通过binlog日志生成sqlFlags: -h, --help help for ra -v, --version version for raUse "ra [command] --help" for more information about a command.步骤一：查看以后的binlog文件名 ...

作者：京东物流 籍磊 1.前言当谈到MySQL的执行打算时，会有很多同学想：“我就感觉应用其余的执行计划比EXPLAIN语句输入的计划强，凭什么优化器做的决定与我得不一样？”。这个问题在MySQL 5.6之前或者本人很难解决，然而当初MySQL5.6及更高的版本中引入了Optimizer Trace。 2.optimizer_trace开启形式及表构造当上面这行代码执行的时候会将会使用户可能不便地查看优化器生成执行打算的整个过程。 SET SESSION optimizer_trace=”enabled=on”;optimizer\_trace的开关默认是敞开的，咱们能够应用上行代码查看optimizer\_trace状态。 SHOW variables LIKE'optimizer_trace'; 其中one\_line值是用来管制输入格局的，如果值为on，那所有的信息会在同一行中展现（这样并不便于咱们浏览），默认为off。当咱们的optimizer\_trace的enabled为on时，输出想要查看优化过程的查问语句，在该语句执行完之后，就能够到information\_schema数据库下的optimizer\_trace表中查看具体的执行打算生成过程，当然也能够间接对想要的查问语句应用EXPLAIN。 optimizer_trace表有四列，每列正文我补充在下方create语句中： CREATE TEMPORARY TABLE `OPTIMIZER_TRACE` ( `QUERY` longtext NOT NULL COMMENT '咱们输出的查问语句', `TRACE` longtext NOT NULL COMMENT '优化过程的json文本', `MISSING_BYTES_BEYOND_MAX_MEM_SIZE` int(20) NOT NULL DEFAULT '0' COMMENT '执行打算生成的过程中产生的超出字数限度的文本数', `INSUFFICIENT_PRIVILEGES` tinyint(1) NOT NULL DEFAULT '0' COMMENT '是否有权限查看执行打算的生成过程，0有权限，1无权限') ENGINE=InnoDB DEFAULT CHARSET=utf83.optimizer_trace实际咱们当初依据一个例子来看看optimizer_trace的实际。 explain select * from ship_data.check_table where outbound_no ='ESL48400163536608' and yn=0 and update_user ='jilei18';SELECT * FROM information_schema.OPTIMIZER_TRACE;上述sql的执行打算如下： OPTIMIZER\_TRACE表中的信息，这里能够留神到MISSING\_BYTES\_BEYOND\_MAX\_MEM\_SIZE的值为1023，阐明TRACE中并没有显示出全副的优化过程： ...

试验筹备CREATE TABLE `c` ( `a` int(11) NOT NULL, PRIMARY KEY (`a`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;INSERT INTO `c` VALUES ('10');INSERT INTO `c` VALUES ('11');INSERT INTO `c` VALUES ('13');INSERT INTO `c` VALUES ('20');设置事务级别 反复读（repeatable-read）set global tx_isolation = 'repeatable-read';查问语句select * from c where a <= 13 for updateprimary keyTABLE LOCK table `test`.`c` trx id 1226827 lock mode IXRECORD LOCKS space id 492 page no 3 n bits 72 index PRIMARY of table `test`.`c` trx id 1226827 lock_mode XRecord lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 8000000a; asc ;; 1: len 6; hex 00000012b815; asc ;; 2: len 7; hex e50000025b0110; asc [ ;;Record lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 8000000b; asc ;; 1: len 6; hex 00000012b815; asc ;; 2: len 7; hex e50000025b011f; asc [ ;;Record lock, heap no 4 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 8000000d; asc ;; 1: len 6; hex 00000012b815; asc ;; 2: len 7; hex e50000025b012e; asc [ .;;Record lock, heap no 5 PHYSICAL RECORD: n_fields 3; compact format; info bits 0 0: len 4; hex 80000014; asc ;; 1: len 6; hex 00000012b815; asc ;; 2: len 7; hex e50000025b013d; asc [ =;;(-∞,10](10,11](11,13](13,20] ...

一、安装包筹备 二、装置流程1、查看/tmp长期目录权限因为mysql装置过程中，会通过mysql用户在/tmp目录下新建tmp_db文件 chmod -R 777 /tmp2、装置前，依赖查看rpm -qa|grep libaio rpm -qa|grep net-tools 在确保Linux联网状态下可通过以下命令装置依赖 rpm install libaiorpm install net-tools3、MySQL装置流程3.1 将安装程序拷贝到/opt目录下 3.2 安装程序程序rpm -ivh mysql-community-common-8.0.31-1.el7.x86_64.rpmrpm -ivh mysql-community-client-plugins-8.0.31-1.el7.x86_64.rpmrpm -ivh mysql-community-libs-8.0.31-1.el7.x86_64.rpmrpm -ivh mysql-community-client-8.0.31-1.el7.x86_64.rpmrpm -ivh mysql-community-icu-data-files-8.0.31-1.el7.x86_64.rpmrpm -ivh mysql-community-server-8.0.31-1.el7.x86_64.rpm留神：如在装置过程中报一下谬误，执行以下命令卸载 mysql-libsyum remove mysql-libs 3.3 查看mysql装置版本mysql --versionmysqladmin --versionrpm -qa|grep -i mysql3.4 服务的初始化为了保障数据库目录与文件的所有者为mysql登录用户，如果你是以root用户运行MySQL服务，须要执行以下命令初始化： mysqld --initialize --user=mysql阐明：--initialize选项默认以“平安”模式来初始化，则会为root用户生成一个密钥并将改密钥标记为过期，登录后你须要设置一个新的密钥，生成的长期密钥会往日志中记录一份 查看密钥： cat /var/log/mysqld.log3.5 启动MySQL，查看状态启动： systemctl start mysqld.servicce敞开： systemctl stop mysqld.servicce重启： systemctl restart mysqld.servicce查看状态： systemctl status mysqld.servicceps：加不加.servicce后缀都能够；mysqld这个可执行文件就代表这mysql服务程序，运行这个可执行文件能够间接启动一个服务器过程。 查看过程： ps -ef|grep mysql3.6 查看MySQL服务是否自启动查看MySQL服务是否自启动命令 systemctl list-unit-files|grep mysqld.servicceMySQL开机自启动 ...

“AI不会代替他们，但善用AI的人会” 慢 SQL 常常会让应用程序响应变慢，轻者影响用户体验，重大的时候可能会导致服务不可用。如果，每次遇到慢 SQL 都求助于 DBA，一方面效率很低，另一方面也会很没面子。所以，咱们一起来看看如何应用AI能力给出超过个别DBA的 SQL 优化倡议。NineData（ www.ninedata.cloud ）面向每个开发人员提供了收费的 SQL 开发性能，同时也提供了收费的 AI SQL 优化性能。 咱们看看，如何应用 NineData 的 AI 性能实现 SQL 优化。 1. 创立数据源登录进入控制台，并创立一个永恒收费的数据源，用于优化 SQL（如果曾经有数据源了则能够跳过这一步）。 登录进入NineData控制台 创立一个永恒收费的数据源 2. 一个简略的案例接着只须要在“ SQL 窗口”，输出想要优化的 SQL，并点击“智能优化”，急躁期待就好了。具体的： 点击右侧导航“SQL 开发->SQL 窗口”，进入一个数据源的 SQL 窗口 接着输出须要优化的 SQL，选中 SQL 并点击“SQL 智能优化”按钮即可 例如，咱们在零碎中发现了如下的慢 SQL 须要优化： SELECT *FROM t_userWHERE region_id = '0571'; NineData零碎中发现了如下的慢 SQL 须要优化 很快，就取得如下的优化倡议： NineData智能SQL优化 能够看到，在智能优化倡议中，包含了常见的索引增加倡议，也有容易疏忽的“SELECT * ”优化，还有更加简单一些笼罩索引倡议，曾经具备了个别 DBA 的 SQL 智能优化能力。 3.一个较简单的案例再看一个更加简单的案例吧： SELECT *FROM t_userWHERE region_id = '0571'AND YEAR(birth_date) >= 2012ORDER BY reg_dateLIMIT 10点击智能优化按钮： ...

什么是MySQLMySQL是一个关系型数据库，它采纳表的模式来存储数据。你能够了解成是Excel表格，既然是表的模式存储数据，就有表构造（行和列）。行代表每一行数据，列代表该行中的每个值。列上的值是有数据类型的，比方：整数、字符串、日期等等。 数据库的三大范式第一范式1NF 确保数据库表字段的原子性。最全面的Java面试网站 比方字段 userInfo: 广东省 10086' ，按照第一范式必须拆分成 userInfo: 广东省 userTel: 10086两个字段。 第二范式2NF 首先要满足第一范式，另外蕴含两局部内容，一是表必须有一个主键；二是非主键列必须齐全依赖于主键，而不能只依赖于主键的一部分。 举个例子。假设选课关系表为student_course(student_no, student_name, age, course_name, grade, credit)，主键为(student_no, course_name)。其中学分齐全依赖于课程名称，姓名年龄齐全依赖学号，不合乎第二范式，会导致数据冗余（学生选n门课，姓名年龄有n条记录）、插入异样（插入一门新课，因为没有学号，无奈保留新课记录）等问题。 应该拆分成三个表：学生：student(stuent_no, student_name, 年龄)；课程：course(course_name, credit)；选课关系：student_course_relation(student_no, course_name, grade)。 第三范式3NF 首先要满足第二范式，另外非主键列必须间接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的状况。 假设学生关系表为Student(student_no, student_name, age, academy_id, academy_telephone)，主键为"学号"，其中学院id依赖于学号，而学院地点和学院电话依赖于学院id，存在传递依赖，不合乎第三范式。 能够把学生关系表分为如下两个表：学生：(student_no, student_name, age, academy_id)；学院：(academy_id, academy_telephone)。 2NF和3NF的区别？ 2NF根据是非主键列是否齐全依赖于主键，还是依赖于主键的一部分。3NF根据是非主键列是间接依赖于主键，还是间接依赖于非主键。本文曾经收录到Github仓库，该仓库蕴含计算机根底、Java根底、多线程、JVM、数据库、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服务、设计模式、架构、校招社招分享等外围知识点，欢送star~ Github地址 如果拜访不了Github，能够拜访gitee地址。 gitee地址 事务的四大个性？事务个性ACID：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。 原子性是指事务蕴含的所有操作要么全副胜利，要么全副失败回滚。一致性是指一个事务执行之前和执行之后都必须处于一致性状态。比方a与b账户共有1000块，两人之间转账之后无论胜利还是失败，它们的账户总和还是1000。隔离性。跟隔离级别相干，如read committed，一个事务只能读到曾经提交的批改。持久性是指一个事务一旦被提交了，那么对数据库中的数据的扭转就是永久性的，即使是在数据库系统遇到故障的状况下也不会失落提交事务的操作。事务隔离级别有哪些？先理解下几个概念：脏读、不可反复读、幻读。 脏读是指在一个事务处理过程里读取了另一个未提交的事务中的数据。不可反复读是指在对于数据库中的某行记录，一个事务范畴内屡次查问却返回了不同的数据值，这是因为在查问距离，另一个事务批改了数据并提交了。幻读是当某个事务在读取某个范畴内的记录时，另外一个事务又在该范畴内插入了新的记录。对幻读的正确理解是一个事务内的读取操作的论断不能撑持之后业务的执行。假如事务要新增一条记录，主键为id，在新增之前执行了select，没有发现id为xxx的记录，但插入时呈现主键抵触，这就属于幻读，读取不到记录却发现主键抵触是因为记录实际上曾经被其余的事务插入了，但以后事务不可见。不可反复读和脏读的区别是，脏读是某一事务读取了另一个事务未提交的脏数据，而不可反复读则是读取了前一事务提交的数据。 事务隔离就是为了解决下面提到的脏读、不可反复读、幻读这几个问题。 MySQL数据库为咱们提供的四种隔离级别： Serializable (串行化)：通过强制事务排序，使之不可能互相抵触，从而解决幻读问题。Repeatable read (可反复读)：MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行，解决了不可反复读的问题。Read committed (读已提交)：一个事务只能看见曾经提交事务所做的扭转。可防止脏读的产生。Read uncommitted (读未提交)：所有事务都能够看到其余未提交事务的执行后果。查看隔离级别： select @@transaction_isolation;设置隔离级别： set session transaction isolation level read uncommitted;生产环境数据库个别用的什么隔离级别呢？生产环境大多应用RC。为什么不是RR呢？ ...

4月22日，2023首届云数据库技术沙龙 MySQL x ClickHouse 专场，在杭州市海智核心胜利举办。本次沙龙由玖章算术、菜根倒退、良仓太炎共创联结主办。围绕“技术进化，让数据更智能”为主题，汇聚字节跳动、阿里云、玖章算术、华为云、腾讯云、百度的6位数据库领域专家，深刻 MySQL x ClickHouse 的实践经验和技术趋势，联合企业级的实在场景落地案例，与宽广技术爱好者一起交换分享。 MySQL x ClickHouse专场合影 玖章算术CEO叶正盛，是本次云数据库技术沙龙的发起人。作为寰球顶级数据库与云计算领域专家，曾负责阿里云数据库产品治理与解决方案部总经理，阿里云技术架构组与产品决策委员会核心成员。帮忙阿里云构建了云原生数据库产品体系，并胜利进入 Gartner DBMS 魔力象限寰球领导者地位，实现中国根底软件的重大突破。是阿里巴巴去 IOE、异地多活、云计算屡次技术改革的核心技术专家。独创了寰球当先的云原生数据传输、数据管理、数据库备份、数据库主动驾驶服务等多款云计算数据库产品。 叶正盛承受浙江广电的媒体采访 叶正盛总结了过来20年软件研发教训，他认为：继续的学习云数据库技术是程序员的外围竞争力，也是一般程序员走向技术专家的必修课。置信通过云数据库技术沙龙的继续举办，能够连贯开发者和技术专家之间的沟通桥梁，让每个人都能用好数据和云。 尽管本次云数据库技术沙龙是在周六，因为调休只有1天劳动，然而很多同学还是早早到场加入交换。同样，对于未能达到现场的同学，咱们也带来了技术沙龙的高清图一起来理解吧~ 云数据库技术沙龙吸引了不少参会者 提前1小时到场的第1、2名参会同学 观众陆续签到入场 提前到场的演讲嘉宾开启技术狂飙模式 收场环节云数据库技术沙龙主持人周振兴，NineData.cloud 联结创始人，Oracle ACE（MySQL 方向），数据库畛域畅销书《高性能 MySQL》第三、四版的译者。周振兴也是本次技术沙龙的发起人之一，在沙龙收场次要介绍了云数据库技术沙龙的初衷。 周振兴示意：从本地数据库向云数据库进化，是以后数据库畛域最重要的趋势，云数据库沙龙心愿构建一个开发者与云数据库技术链接的桥梁。 云数据库技术沙龙主持人周振兴做收场介绍 重点演讲游致远，火山引擎 ByteHouse 资深研发工程师 第一位议程嘉宾：游致远，火山引擎 ByteHouse 资深研发工程师，负责 ByteHouse 云数仓版引擎计算模块。之前先后就任于网易、菜鸟团体、蚂蚁团体，有多年大数据计算引擎、分布式系统相干研发经验。 游致远次要介绍了《ByteHouse 云数仓版查问性能优化和 MySQL 生态欠缺》。本次沙龙重点介绍了 ByteHouse 云原生版的整体架构，并重点介绍 ByteHouse 在查问上的优化（如优化器、MPP 执行模式、调度优化等）和对MySQL生态的欠缺（基于社区 MaterializedMySQL 性能）。最初结合实际利用案例总结优化的成果。 陆洪勇，腾讯TEG数据库产品部高级技术专家 第二位议程嘉宾：陆洪勇，腾讯TEG数据库产品部高级技术专家，曾在 SAP 做过多年HANA数据库内核的设计与研发，阿里云 Polardb 数据库内核的设计与研发。目前在腾讯云数据库做 HTAP for MySQL 相干产品的设计与开发。 陆洪勇本次次要介绍了《HTAP for MySQL 在腾讯云数据库的演进》。MySQL 在充分利用多核计算资源方面比拟欠缺，无奈同时满足在线业务和剖析型业务的客户需要，而独自部署一套专用的剖析型数据库意味着额定的老本和简单的数据链路。此次也是重点介绍腾讯云数据库为满足此类场景而在 HTAP for MySQL 产品方面进行的尝试。 ...

@[toc]咱们在我的项目的具体实际中，有时候会遇到一些比拟非凡的字段，例如身份证号码。 松哥之前有一个小伙伴做黑龙江省的政务服务网，里边有一些波及到用户身份证存储的场景，因为存储的数据大部分都是当地的，此时如果想给身份证号码建设索引的话，小伙伴们晓得，身份证前六位是地址码，在这样的场景下，给身份证字段建设索引的话，前六位的区分度是很低的，甚至前十位的区分度都很低（因为出世年份毕竟无限，一个省份上千万人口，出世年份反复率是很高的），不仅节约存储空间，查问性能还低。 那么有没有方法解决这个问题呢？咱们明天就来聊一聊前缀索引，聊完之后置信大家本人就有答案了。 1.什么是前缀索引有时候为了晋升索引的性能，咱们只对字段的前几个字符建设索引，这样做既能够节约空间，还能缩小字符串的比拟工夫，B+Tree 上须要存储的索引字符串更短，也能在肯定水平上升高索引树的高度，进步查问效率。 MySQL 中的前缀索引有点相似于 Oracle 中对字段应用 Left 函数来建设函数索引，只不过 MySQL 的这个前缀索引在查问时是外部主动实现匹配的，并不需要应用 Left 函数。 不过前缀索引有一个缺点，就是有可能会升高索引的选择性。 2.什么是索引选择性对于索引的选择性（Index Selectivity），它是指不反复的索引值（也称为基数 cardinality)和数据表的记录总数的比值，取值范畴在 (0,1] 之间。索引的选择性越高则查问效率越高，因为选择性高的索引能够让 MySQL 在查找时过滤掉更多的行。 那有小伙伴要问了，是不是选择性越高的索引越好呢？当然不是！索引选择性最高为 1，如果索引选择性为 1，就是惟一索引了，搜寻的时候就能间接通过搜寻条件定位到具体一行记录！这个时候尽管性能最好，然而也是最费空间的，这不合乎咱们创立前缀索引的初衷。 咱们一开始之所以要创立前缀索引而不是惟一索引，就是心愿可能在索引的性能和空间之间找到一个均衡，咱们心愿可能抉择足够长的前缀以保障较高的选择性（这样在查问的过程中就不须要扫描很多行），然而又心愿索引不要太过于占用存储空间。 那么咱们该如何抉择一个适合的索引选择性呢？索引前缀应该足够长，以便前缀索引的选择性靠近于索引的整个列，即前缀的基数应该靠近于残缺列的基数。 首先咱们能够通过如下 SQL 失去全列选择性： SELECT COUNT(DISTINCT column_name) / COUNT(*) FROM table_name;而后再通过如下 SQL 失去某一长度前缀的选择性： SELECT COUNT(DISTINCT LEFT(column_name, prefix_length)) / COUNT(*) FROM table_name;在下面这条 SQL 执行的时候，咱们要留神抉择适合的 prefix_length，直至计算结果约等于全列选择性的时候，就是最佳后果了。 3.创立前缀索引3.1 一个小案例举个例子，咱们来创立一个前缀索引看看。 松哥这里应用的数据样例是网上找的一个测试脚本，有 300W+ 条数据，做 SQL 测试优化是够用了，小伙伴们在公众号后盾回复 mysql-data-samples 获取脚本下载链接。 咱们来大抵上看下这个表构造： 这个表有一个 user_uuid 字段，咱们就在这个字段上做文章。 Git 小伙伴们应该都会用吧？不同于 Svn，Git 上的版本号不是数字而是一个 Hash 字符串，然而咱们在具体利用的时候，比方你要做版本回退，此时并不需要输出残缺的的版本号，只须要输出版本号前几个字符就行了，因为依据后面这一部分就能确定出版本号了。那么这张表里边的 user_uuid 字段也是这意思，如果咱们想给 user_uuid 字段建设索引，就没有必要给残缺的字符串建设索引，咱们只须要给一部分字符串建设索引。 ...

索引是 MySQL 数据库中优化查问性能的重要工具，通过对查问条件和表数据的索引，MySQL能够疾速定位数据，进步查问效率。然而，在理论的数据库开发和保护中，咱们常常会遇到一些状况，导致索引生效，从而使得查问变得十分迟缓，甚至无奈应用索引来优化查问，这会重大影响零碎的性能。那么，是什么起因导致了索引生效呢？ 常见的状况有： 索引中断数据类型不匹配查问条件应用函数操作前含糊查问OR 查问建设索引时应用函数索引区分度不高上面我通过理论的例子来具体说说。假如当初咱们有一张人物表，建表语句如下： CREATE TABLE `person` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `name` varchar(64) NOT NULL, `score` int(11) NOT NULL, `age` int(11) NOT NULL, `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4;1、联结索引中断在应用联结索引进行查问时，如果联结索引中的某一个列呈现了索引中断的状况，那么整个联结索引都会生效，无奈持续应用索引来优化查问。 例如：对于联结索引 （name, score），如果条件中如果只有 score，则会导致索引生效。 CREATE INDEX idx_name_score ON person (`name`,`score`);select * from person where score = 90而上面的状况都会应用索引： select * from person where name = '31a'select * from person where score = 90 and name = '31a'select * from person where name = '31a' and score = 902、数据类型不匹配如果咱们在查问条件中应用了一个不匹配索引的数据类型的值，那么 MySQL 将无奈应用该索引来优化查问，从而导致索引生效。 ...

在上篇文章中，松哥和小伙伴们分享了 MySQL 的聚簇索引，也顺便和小伙伴们剖析了为什么在 MySQL 中主键不应该应用随机字符串。然而主键不必随机字符串用什么？主键自增？主键自增就是最佳计划吗？有没有其余坑？明天咱们就来探讨下这个话题。 1. 为什么不必 UUID通过上篇文章的介绍，咱们晓得在 MySQL 中，主键索引就是聚簇索引，MySQL 表中的数据是依据主键值汇集在一起的，聚簇索引是一棵 B+Tree，这棵树中的数据是有序的。 所以，如果咱们应用 UUID 字符串作为主键，那么就会导致每次数据插入的时候，都须要在 B+Tree 中寻找到适宜它本人的地位，找到之后就有可能要移动前面的节点（就像在数组中插入一条记录），移动前面的节点，就有可能波及到页决裂，插入效率就会升高。 另一方面，在非聚簇索引中，叶子结点保留的是主键值，主键如果是一个很长的 UUID 字符串，就会占据较大的存储空间（绝对 int 而言），那么同一个叶子结点可能保留的主键值数量就会缩小，进而可能会导致树变高，树变高，意味着查问的时候 IO 次数减少，查问效率升高。 基于下面的剖析，咱们在 MySQL 中尽量不应用 UUID 作为主键，不必 UUID，可能会有小伙伴想到，那我应用主键自增行不行？ 对于下面提到的两个应用 UUID 作为主键的问题，应用主键自增显然都能够解决。主键自增，每次只须要往树的开端增加就行了，基本上不会波及到页决裂问题；主键自增意味着主键是数字，占用的存储空间相对来说就比拟小，对非聚簇索引的影响也会小一些。 那么主键自增就是最佳计划吗？主键自增有没有一些须要留神的问题？ 2. 主键自增的问题以下内容，有一个独特的大前提，就是咱们的表设置了主键自增。 一般来说，主键自增是没有什么问题的。然而，如果在高并发环境下，就会有问题了。 首先最容易想到的就是在高并发插入的时候产生的尾部热点问题，并发插入时，大家都须要去查问这个值而后计算出本人的主键值，那么主键的上界就会成为热点数据，并发插入时这里会产生锁竞争。 为了解决这个问题，咱们就须要抉择适宜本人的 innodb_autoinc_lock_mode。 2.1 数据插入的三种模式首先，咱们在向数据表中插入数据的时候，一般来说有三种不同的模式，别离如下： insert into user(name) values('javaboy') 或者 replace into user(name) values('javaboy') ，这种没有嵌套子查问并且可能确定具体插入多少行的插入叫做 simple insert，不过须要留神的是 INSERT ... ON DUPLICATE KEY UPDATE 不算是 simple insert。load data 或者 insert into user select ... from ....，这种都是批量插入，叫做 bulk insert，这种批量插入有一个特点就是插入多少条数据在一开始是未知的。insert into user(id,name) values(null,'javaboy'),(null,'江南一点雨')，这种也是批量插入，然而跟第二种又不太一样，这种里边蕴含了一些主动生成的值（本案例中的主键自增），并且可能确定一共插入多少行，这种称之为 mixed insert，对于后面第一点提到的 INSERT ... ON DUPLICATE KEY UPDATE 也算是一种 mixed insert。将数据插入分为这三类，次要是因为在主键自增的时候，锁的解决计划不同，咱们持续往下看。 ...

ClickHouse 在执行剖析查问时的速度劣势很好的补救了 MySQL 的有余，然而对于很多开发者和DBA来说，如何将MySQL稳固、高效、简略的同步到 ClickHouse 却很艰难。本文比照了 NineData、MaterializeMySQL（ClickHouse自带）、Bifrost 三款产品，看看他们在同步时的差别。 比照后果概述整体上，NineData（官网：www.ninedata.cloud ）的数据复制性能在性能、性能体现最突出。其次是Bifrost和ClickHouse自带的MaterializeMySQL。NineData在增量DDL的解决、字段映射的准确性、无主键表、以及功能丰富度上最强（数据校验、过滤、限流等），具体的对比方下图： 构造映射比照在做了具体比照之后，对于根底类型，只有NineData思考的更加残缺，例如MySQL的datetime须要映射到ClickHouse的DateTime64，否则则可能呈现数据失落。如果应用Biforst或MaterializeMySQL等其余产品均映射到datetime可能会造成肯定水平的数据精度失落。 此外，在比照了MySQL全副数据类型之后，发现NineData反对更残缺，例如对JSON类型、几何数据、地理信息仅NineData反对。此外，对于根底类型，也只有NineData思考更加粗疏，应用Biforst或MaterializeMySQL等其余产品则可能导致精度失落，从而造成数据失落。 具体的对比方下图： 无主键表反对NineData对记录做了非凡的标记解决，所以很好的反对了无主键表的数据同步。而MaterializeMySQL、Biforst均不反对。 具体的对比方下图： 增量DDL对于数据增量同步，反对好各种类型的DDL是保障同步链路继续稳固的要害，NineData在无主键表DDL反对、字段删除、字段名批改等非凡操作均做了适配解决，能够很好的保障复制链路的问题。同时，NineData还提供了可视化的谬误修复和跳过性能，能够最大限度的保障链路继续稳固。 具体的对比方下图： 限流、比照、过滤等除了后面介绍的个别性能之外，为了晋升数据品质、保障稳固，NineData还反对了包含数据比照、运行中的限流、数据过滤等性能。具体的阐明如下： 同步性能比照这里应用 sysbench工具生成了5000万行记录进行全量性能比照，再生成约1800万次DML（约5GB Binlog）进行增量性能比照。 比照中，全量同步 NineData 性能为36.2W RPS（每秒同步记录数）为最高；增量同步则是 ClickHouse 自带的同步工具 MaterializeMySQL 最高，须要留神，MaterializeMySQL 在错误处理上比较简单，如果报错则须要全副从新同步。 具体的比照如下： 全量同步通过sysbench生成10张表，每张表500W记录（5000W行），数据文件大小约为12G： 增量同步通过sysbench生成5G大小的BinLog日志（约1800W次DML），再进行增量同步： 总结NineData（https://www.ninedata.cloud/） 在性能上当先其余同步工具，特地是字段类型的全面适配和增量复制期间DDL的反对度，并且在动静限流、数据比照、监控等能力上也反对的最欠缺。 所以，如果想把MySQL的数据实时同步到ClickHouse，举荐应用NineData，不仅应用简略（SaaS），并在满足性能和性能的前提下，实现了字段类型的无损转换和数据的实时复制，很好的解决MySQL 同步数据到ClickHouse的问题。 补充阐明以后各个云厂商尽管都提供ClickHouse托管服务，然而另一方面云厂商又都在倒退本人的数仓产品，在同步性能反对上通常仅对自家的数仓产品反对比拟好，而对ClickHouse同步反对都很单薄。此外，开源工具Canal也因为不能很好的反对构造同步，应用和保护起来并不不便。

MySQL 8 绝对于 MySQL 5.7，在分区性能上有以下几点改良： 主动分区修复（Automatic Partition Repair）：在 MySQL 8 中，如果分区表中的某个分区呈现了损坏，MySQL 8 会主动将损坏的分区替换成新的分区，从而进步了分区表的可靠性。空间分区索引（Spatial Partitioning Index）：MySQL 8 反对了空间分区索引，使得在空间分区表上查问时，能够充分利用空间索引进行优化，进步查问性能。多值分区键（Multi-Value Partition Key）：MySQL 8 反对应用多个列作为分区键，从而更灵便地实现分区策略。子分区（Subpartition）：MySQL 8 反对对已分区的分区表进行子分区，从而更细粒度地治理数据。等值分区（Equal-Value Partition）：MySQL 8 反对将某个分区分成多个相等的子分区，这些子分区能够有雷同的分区键，这样能够更平衡地调配数据，进步查问性能。列分区（Column Partitioning）：MySQL 8 引入了列分区，能够按列的值进行分区，从而更好地反对某些特定的业务场景。综上所述，MySQL 8 的分区性能绝对于 MySQL 5.7 有了很大的改良，使得分区表的设计更加灵便、高效和牢靠。

为什么是再次了解呢？因为松哥之前写过相干的文章介绍过聚簇索引，然而感觉还不够，因而明天想再来和小伙伴们聊一聊这个话题。 1. 什么是聚簇索引数据库的索引从不同的角度能够划分成不同的类型，聚簇索引便是其中一种。 聚簇索引英文是 Clustered Index，有时候小伙伴们可能也会看到有人将之称为汇集索引等，与之绝对的是非聚簇索引或者二级索引。 聚簇索引并不是一种独自的索引类型，而是一种数据的存储形式。在 MySQL 的 InnoDB 存储引擎中，所谓的聚簇索引实际上就是在同一个 B+Tree 中保留了索引和数据行：此时，数据放在叶子结点中，聚簇聚簇，意思就是说数据行和对应的键值紧凑的存在一起。 假如我有如下数据： id(主键)usernameageaddressgender1ab99深圳男2ac98广州男3af88北京女4bc80上海女5bg85重庆女6bw95天津男7bw99海口女8cc92武汉男9ck90深圳男10cx93深圳男那么它的聚簇索引大略就是这个样子： 那么大家能够看到，叶子上既有主键值（索引）又有数据行，节点上则只有主键值（索引）。 小伙伴们想想，MySQL 表中的数据在磁盘中只可能保留一份，不可能保留两份，所以，在一个表中，聚簇索引只可能有一个，不可能有多个。 2. 聚簇索引和主键有的小伙伴搞不清楚这两者之间的关系，甚至将两者划等号，这是一个微小的误区。 在有的数据库中，反对开发者自在的抉择应用哪一个索引作为聚簇索引，然而 MySQL 中是不反对这个个性的。 在 MySQL 中，如果表自身就有设置主键，那么主键就是聚簇索引；如果表自身没有设置主键，则会抉择表中的一个惟一且非空的索引来作为聚簇索引；如果表中连惟一非空的索引都没有，那么就会主动抉择表中的隐式主键来作为聚簇索引。对于 MySQL 中表的隐式主键，松哥会在未来的文章中和大家介绍。 不过一般来说，还是倡议大家本人来为表设置主键，因为隐式主键是自增的，自增的都会存在一个问题：在自增值上会存在十分高的锁竞争问题，主键的上界会称为热点数据，因为所有的插入操作都要主键自增，又不能反复，所以会产生锁竞争进而导致性能升高。依据下面的介绍，咱们能够总结出 MySQL 中聚簇索引和主键索引的关系如下： 聚簇索引不肯定是主键索引。主键索引肯定是聚簇索引。3. 聚簇索引优缺点先来说长处： 互相关联的数据咱们能够将之保留在一起。例如有一个用户订单表，咱们能够依据 用户 ID + 订单 ID 来汇集所有数据，用户 ID 可能会反复，订单 ID 则不会反复，这样咱们就可能将一个用户相干的订单数据都保留在一起，如果须要查问一个用户的所有订单，就会十分快，只须要大量的磁盘 IO 就能够做到。不须要回表，因而数据访问速度更快。在聚簇索引中，索引和数据都在同一棵 B+Tree 上，因而从聚簇索引中获取到的数据比从非聚簇索引上获取数据更快（非聚簇索引须要回表）。对于第一点的案例，如果咱们想依据用户 ID 查问到这个用户所有的订单 ID，那么此时都不必去到叶子结点了，因为支节点上就有咱们须要的数据，所以间接利用笼罩索引的个性，就能够读取到须要的数据。这些就是聚簇索引一些常见的长处，咱们在日常的表设计中，其实应该充分利用好这些长处。 再来看看毛病： 小伙伴们发现，后面咱们说的聚簇索引的劣势次要是聚簇索引缩小了 IO 次数，从而进步了数据库的性能，然而有的 IO 密集型利用，可能间接上一个足够大的内存，把数据都读取到内存中操作，此时聚簇索引就没有啥劣势了。随机主键会导致页决裂问题，主键程序插入的话，相对来说效率会高一些，因为在 B+Tree 中只须要一直往后面追加即可；然而主键如果是非程序插入的话，效率就会低很多，因为可能会波及到页决裂问题。以下面那张图为例，假如每个节点能够保留三条数据，当初咱们要插入一个主键是 4.5 的记录，那么就须要把主键为 5 的值往后挪动，进而导致主键为 8 的节点也要往后挪动。页决裂会导致数据插入效率升高并且占用更多的存储空间。非聚簇索引（二级索引）查问的时候须要回表。因为一个索引就是一棵索引树，数据都在聚簇索引上，所以如果应用非聚簇索引进行搜寻，非聚簇索引的叶子上存储的是主键值，先找到主键值，而后拿着主键值再来聚簇索引上搜寻，这样一共就查问了两棵索引树，这就是回表。4. 最佳实际看了下面的介绍，置信小伙伴曾经理解了，在应用聚簇索引的时候，主键最好不要应用 UUID 这种随机字符串，应用 UUID 随机字符串至多存在两方面的问题： ...

作者：徐文梁 爱可生DBA成员，一个执着于技术的数据库工程师，次要负责数据库日常运维工作。善于MySQL,redis，其余常见数据库也有涉猎，喜爱垂钓，看书，看风光，结交新敌人。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 问题背景:前段时间，客户反馈 Zabbix 实例的 history_str 表数据量很大，导致磁盘空间使用率较高，想要清理该表，征询是否有好的倡议。想着正好最近学习了相干的知识点，正好能够测验一下学习成绩，通过实际的测验，最终考试合格，客户也比较满意，于是便有了此文。 问题沟通:通过理论查看环境及与客户沟通，得出以下信息: 1.现场是双向主从复制架构，未设置从库read_only只读。 2.history_str表的ibd数据文件超460G。 3.history_str表的存量数据能够间接清理。 4.现场实例所在的服务器是虚拟机，配置较低。 因而，综合思考后倡议客户新建雷同表构造的表而后对原表进行drop操作，然而表数据量比拟大，须要思考以下危险: 1.drop大表可能会导致实例hang住，影响数据库失常应用。 2.drop大表操作导致主从延时。 3.删除大文件造成磁盘io压力较大。 最终计划:在思考以上的根底上，最终给出如下计划: 1.在主库执行如下命令建设雷同表构造表并进行rename操作: create table history_str_new like history_str;rename table history_str to history_str_old, history_str_new tohistory_str;2.在主库和从库执行以下操作，建设硬链接文件: ln history_str_old.ibd history_str_old.ibd.hdlk 3.实现第二步后，倡议距离一两天再进行操作，让history_str_old表数据从innodb buffer pool中冷却，而后业务低峰期在主从库别离执行如下操作，倡议先操作从库,从库验证没问题后再在主库操作: set sql log bin=0; //长期敞开写操作记录binlogdrop table history_str_old;//执行drop操作set sql log bin=l; //复原写操作记录binlog 4.删除history_old.ibd.hdlk文件，开释空间，能够通过linux的truncate命令实现，参考脚本如下: #!/bin/bash################################################################################ 第一个参数为须要执行操作的文件的文件名称 #### 第二个参数为每次执行操作的缩减值，单位为MB #### 第三个参数为每次执行后的睡眠工夫，单位为S ################################################################################ fileSize=`du $1|awk -F" " '{print $1}'`fileName=$1chunk=$2sleepTime=$3chunkSize=$(( chunk * 1024 ))rotateTime=$(( fileSize / chunkSize ))declare -a currentSizeecho $rotateTime function truncate_action(){for (( i=0; i<=${rotateTime}; i++ ))doif [ $i -eq 0 ];thenecho "开始进行truncate操作，操作文件名为:"$fileNamefi if [ $i -eq ${rotateTime} ];thenecho "执行truncate操作完结！！！"fi truncate -s -${chunk}M $fileNamecurrentSize=`du -sh $fileName|awk -F" " '{print $1}'`echo "以后文件大小为: "$currentSizesleep $sleepTimedone} truncate_action示例:sh truncateFile.sh history_str_old.ibd.hdlk 256 1，示意删除history_str_old.ibd.hdlk文件，每次截断大小为256M，而后sleep距离为1s。 ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 特分享进去最近在整顿 MySQL 热备工具的试验题目时遇到的 REDO 日志归档问题！ MySQL 的 REDO 日志归档性能在 8.0.17 版本后公布，目标是为了解决应用 MySQL 热备工具比方 mysqlbackup 、xtrabackup 等备份 REDO 日志的速度慢于业务生成 REDO 日志的速度而导致的备份数据不统一问题（未及时备份的 RRDO 日志被提前笼罩写入！）。 MySQL的 REDO 日志归档性能开启非常简单，只需对参数innodb_redo_log_archive_dirs简略设置即可。 set persist innodb_redo_log_archive_dirs='redo_archive1:/redo_mysql/3306'其中 redo_archive1 是一个标签，能够轻易起名字；/redo_mysql/3306 用来指定REDO 日志归档寄存的地位。 我在应用的过程中，遇到几个细节问题：1. REDO 日志归档的目录权限、属主等肯定要设置正确，要不然可能会有以下几种谬误输入 (MySQL 客户端提醒谬误，热备工具可能提醒正告！)：谬误1：ERROR 3844 (HY000): Redo log archive directory '/redo_mysql/3306' does not exist or is not a directory后期须要创立的目录与相干权限设定如下： # 归档目录得提前建！[root@ytt-pc ~]# mkdir -p /redo_mysql/3306 # 设置归档目录拜访权限，只容许属主齐全拜访。[root@ytt-pc ~]# chmod -R 700 /redo_mysql/3306/接下来应用MySQL管理员用户或者具备system_variables_admin权限的用户来在线设置此变量： ...

作者：雷文霆 爱可生华东交付服务部 DBA 成员，次要负责Mysql故障解决及相干技术支持。喜好看书，电影。座右铭，每一个未曾起舞的日子，都是对生命的辜负。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 一、背景某客户的业务中有一张约4亿行的表，因为业务扩大，表中open_id varchar(50) 须要扩容到 varchar(500).变更期间尽量减少对主库的影响(最好是不要有任何影响->最终争取了4个小时的窗口期)。 二、库表信息环境：Mysql 8.0.221主1从 基于Gtid复制 1.第一个问题，这是一张大表吗? 是的，请看 此表的ibd 文件280G + count长时间无返回 + 应用备库看了一下确认行数>4亿 以下语句也能够查看：show table status from dbname like 'tablename'\G # Rows 的值不准，有时误差有2倍SELECT a.table_schema,a.table_name,concat(round(sum(DATA_LENGTH/1024/1024)+sum(INDEX_LENGTH/1024/1024),2) ,'MB')total_size,concat(round(sum(DATA_LENGTH/1024/1024),2),'MB') AS data_size,concat(round(sum(INDEX_LENGTH/1024/1024),2),'MB') AS index_size FROM information_schema.TABLES a WHERE a.table_schema = 'dbname' AND a.table_name = 'tablename'; #看下此表的数据量既然是大表，咱们应该应用什么形式做变更呢？三、计划抉择下文中的 M 示意主库，S1 为从1 ，S2 为从2形式长处毛病可行性OnlineDDL原生，应用两头长期表ALGORITHM=COPY时，会阻塞DML，举荐版本>MySQL5.75星Gh-ost应用binlog+回放线程代替触发器第三方工具，依据不同的参数导致执行工夫较长4星Pt-osc版本兼容性好,应用触发器放弃主副表统一第三方工具，且应用限度较多3星M-S1-S2工夫可预估级联复制，人工操作1星为什么咱们没有抉择前3种计划？依据理论状况评估，本次业务侧的需要是此表24h都有业务流量，且不承受超过4小时的业务不可用工夫 OnlineDDL的形式，ALGORITHM=COPY时，期间会阻塞DML(只读)，最初主副表rename操作时(不可读写)，直到DDL实现(其中须要的工夫不确定)。 Gh-ost的形式，举荐的模式为连贯从库，在主库转换，此模式对主库影响最小，可通过参数设置流控。致命的毛病是此工具的变更工夫太长，4亿的表，测试环境应用了70个小时。最初咱们还须要下发切换命令及手动删除两头表*_del。如果是1主2从还是比拟举荐这种形式的，因为还有一个从库能够保障数据安全。 Pt-osc 和Gh-ost都属于第三方，Pt-osc 对大表的操作和OnlineDDL有一个独特的毛病就是失败回滚的代价很大。 如果是低版本如MySQL<5.7能够应用，实践上OnlineDDL是在MySQL5.6.7开始反对，刚开始反对的不是很好，可适当取舍。 最初咱们抉择了，DBA最青睐(xin ku)的一种形式，在M-S1-S2级联复制下进行。 四、如何进行操作新建一个S1的从库，构建M-S1-S2级联复制应用OnlineDDL在S2上进行字段扩容 (长处是期间M-S1的主从不受影响)扩容实现后，期待提早同步M-S1-S2 (升高S2与M的数据差别,并进行数据验证)移除S1,建设M-S2的主从关系(使S2持续同步M的数据)备份S2复原S1，建设M-S2-S1级联复制利用停服，期待主从数据统一(长处是差别数据量的同步工夫很短)最终S2成为主库，S1为从库(利用须要批改前端连贯信息)利用进行回归验证以上内容看上去很简单，实质上就是备份复原。读者可将其做为备选计划。分享一下具体步骤?环境配备:开启Gtid,留神M,S1 binlog保留时长,磁盘残余空间大于待变更表的2倍show global variables like 'binlog_expire_logs_seconds'; # 默认604800set global binlog_expire_logs_seconds=1209600; # 主库和级联主库都须要设置1.搭建 1主2从的级联复制，M -> S1 -> S2 ，装置MySQL留神本次环境lower_case_table_names = 0 2.在S2 上做字段扩容。 预估 10个小时`参数设置:`set global slave_type_conversions='ALL_NON_LOSSY'; # 避免复制报错SQL_Errno: 13146，属于字段类型长度不统一无奈回放set global interactive_timeout=144000;set global wait_timeout =144000;`磁盘IO参数设置:`set global innodb_buffer_pool_size=32*1024*1024*1024;# 减少buffer_pool 避免Error1206The total number of locks exceeds the lock table size 资源有余set global sync_binlog=20000;set global innodb_flush_log_at_trx_commit=2;set global innodb_io_capacity=600000;set global innodb_io_capacity_max=1200000; # innodb_io_capacity须要设置两次show variables like '%innodb_io%'; # 验证以上设置screen 下执行:time mysql -S /data/mysql/3306/data/mysqld.sock -p'' dbname -NBe "ALTER TABLE tablename MODIFY COLUMN open_id VARCHAR(500) NULL DEFAULT NULL COMMENT 'Id' COLLATE 'utf8mb4_bin';"查看DDL进度:SELECT EVENT_NAME, WORK_COMPLETED, WORK_ESTIMATED FROM performance_schema.events_stages_current;3.扩容实现后，期待提早同步M-S1-S2 数据同步至主从统一,比照主从Gtid4.移除S1,建设M-S2的主从关系S1 (可选)stop slave;reset slave all;systemctl stop mysql_3306S2stop slave;reset slave all;# MASTER_HOST='M主机IP' CHANGE MASTER TO MASTER_HOST='', MASTER_USER='', MASTER_PASSWORD=', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_CONNECT_RETRY=10;start slave; (flush privileges;# 验证数据可失常同步)5.备份S2复原S1，建设M-S2-S1级联复制物理备份S2,重做S2->S1 级联主从rm -rf binlog/*rm -rf redolog/*xtrabackup --defaults-file=/data/mysql/3306/my.cnf.3306 --move-back --target-dir=/data/actionsky/xtrabackup_recovery/datachown -R mysql. data/chown -R mysql. binlog/*chown -R mysql. redolog/*systemctl start mysql_3306set global gtid_purged='';reset slave all;# MASTER_HOST='S2主机IP' ,已扩容变更完的主机CHANGE MASTER TO MASTER_HOST='', MASTER_USER='', MASTER_PASSWORD='', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_CONNECT_RETRY=10;`MySQL8.0版本须要在下面语句中增加 GET_MASTER_PUBLIC_KEY=1; #避免 Last_IO_Errno: 2061 message: Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection.`start slave;6.利用停服，期待主从数据统一主库停服+可设置read_only+flush privileges，比照主从Gtid7.最终S2成为主库，S1为从库利用更改配置连贯新主库。S2上:stop slave;reset slave all;set global read_only=0;set global super_read_only=0;`show master status\G 察看是否有新事务写入`收尾：还原第2步的参数设置。set global interactive_timeout=28800;set global wait_timeout =28800;set global innodb_buffer_pool_size=8*1024*1024*1024;set global slave_type_conversions='';set global sync_binlog=1;set global innodb_flush_log_at_trx_commit=1;set global innodb_io_capacity=2000;set global innodb_io_capacity_max=4000;补充场景: 基于磁盘IO能力的测试间接在主库上批改，且无流量的状况下：场景1，磁盘是NVME的物理机，4亿数据大概须要5个小时(磁盘性能1G/s)。场景2，磁盘是机械盘的虚拟机，此数据量大概须要40个小时(磁盘性能100M/s)。五、总结应用级联，对于业务侧来说，工夫老本次要在利用更改连贯和回归验证。如果从库无流量，不须要期待业务低峰。OnlineDDL可通过批改参数，提高效率，其中双一参数会影响数据安全，举荐业务低峰期操作。Gh-ost 适宜变更工夫拮据的场景，业务低峰期操作，可调整参数加快进度，自定义切换的工夫。以上形式均不举荐多个DDL同时进行，即并行DDL。大表操作和大数据量操作，须要咱们贴合场景找到适合的变更计划，不须要最优，须要适合。福利工夫：分享一个速查表 ...

DQL是数据查询语言（Data Query Language）的缩写，是一种用于从数据库中检索数据的编程语言。DQL是SQL（结构化查询语言）的子集，用于查问关系型数据库，例如MySQL、Oracle和SQL Server等。 DQL提供了多种查问操作，如SELECT、FROM、WHERE、GROUP BY、HAVING、ORDER BY等。应用这些操作，能够依据特定的条件检索所需的数据，并依照特定的程序进行排序和分组。 DQL还反对多表查问和子查问，能够从多个表中联结检索数据，并在子查问中应用嵌套查问语句进行检索。  根底的查问语法select ... from ... select [distinct] ... from ... [where ...] [group by ...] [having ...] [order by ...] [limit ...]  查问语句的执行程序先执行from子句: 基于表进行查问操作再执行where子句: 进行条件筛选或者条件过滤再执行group by子句: 对剩下的数据进行分组查问。再执行having子句: 分组后，再次条件筛选或过滤而后执行select子句: 目标是抉择业务需要的字段进行显示再执行order by子句: 对抉择后的字段进行排序最初执行limit子句: 进行分页查问，或者是查问前n条记录 筹备数据在学习接下来的查问的语法之前，咱们提前准备几张表，并向这张表中插入一些数据，不便咱们之后的查问操作。  student表 CREATE TABLE stu ( sid CHAR(6), sname VARCHAR(50), age INT, gender VARCHAR(50));INSERT INTO stu VALUES('S_1001', 'liuYi', 35, 'male');INSERT INTO stu VALUES('S_1002', 'chenEr', 15, 'female');INSERT INTO stu VALUES('S_1003', 'zhangSan', 95, 'male');INSERT INTO stu VALUES('S_1004', 'liSi', 65, 'female');INSERT INTO stu VALUES('S_1005', 'wangWu', 55, 'male');INSERT INTO stu VALUES('S_1006', 'zhaoLiu', 75, 'female');INSERT INTO stu VALUES('S_1007', 'sunQi', 25, 'male');INSERT INTO stu VALUES('S_1008', 'zhouBa', 45, 'female');INSERT INTO stu VALUES('S_1009', 'wuJiu', 85, 'male');INSERT INTO stu VALUES('S_1010', 'zhengShi', 5, 'female');INSERT INTO stu VALUES('S_1011', 'xxx', NULL, NULL); emp表 ...

通常来说，装置好Mysql后，应用HHDBCS和本机IP，就能够间接连入数据库。 但有时候在装置胜利的状况下，却连贯不上Mysql。此时能够点击测试，会弹出提示框： 由提醒可知，被Mysql回绝拜访了。咱们能够通过CMD来解决这个问题。应用管理员模式进入CMD；在登入mysql后，更改 “mysql” 数据库里的 “user” 表里的 “host” 项，从"localhost"改称"%" mysql -u root –p123456mysql>use mysql;mysql>update user set host = ‘%’ where user = ‘root’;mysql>select host, user from user;mysql>FLUSH RIVILEGES 呈现如下对话框，便是批改胜利。将连贯选项复原默认，点击连贯，便可胜利连贯Mysql。

在 MySQL 中，varchar(n) 类型的字段的索引长度取决于应用的字符集和排序规定。在 utf8 字符集下，每个字符须要最多 3 个字节来编码，而在 utf8mb4 字符集下，每个字符须要最多 4 个字节来编码。 假如咱们应用的是 utf8mb4 字符集和 utf8mb4_general_ci 排序规定，那么一个 varchar(100) 的字段的最大索引长度为 333 个字节（100 4 0.83）。这里的 0.83 是因为 utf8mb4_general_ci 排序规定下，索引须要应用一个额定的字节来存储字符集规定，因而索引长度会稍微缩小。 如果咱们应用的是 utf8 字符集和 utf8_general_ci 排序规定，那么一个 varchar(100) 的字段的最大索引长度为 250 个字节（100 3 0.83）。这里的 0.83 同样是因为 utf8_general_ci 排序规定下，索引须要应用一个额定的字节来存储字符集规定。因而，能够看出，在雷同的 varchar(n) 字段下，应用 utf8mb4 字符集和 utf8mb4_general_ci 排序规定时，索引长度会比应用 utf8 字符集和 utf8_general_ci 排序规定时多出一些字节。 这个谬误通常呈现在 MySQL 或 MariaDB 数据库中，示意试图创立一个超过索引长度限度的索引。解决这个问题的办法取决于你应用的数据库版本和配置。上面是一些可能的解决方案： ① 新数据库版本：在一些较老的 MySQL 或 MariaDB 版本中，索引长度限度较低。降级到新版本可能会减少索引长度限度。
② 更改表格字符集和排序规定：在一些字符集和排序规定中，每个字符须要更多的字节来编码。例如，在 utf8mb4 字符集和 utf8mb4_general_ci 排序规定下，每个字符须要 4 个字节来编码。更改为较短的字符集和排序规定（例如 utf8 或 utf8_general_ci）可能会缩小索引长度。
③ 更改字段类型：如果你的表格中有一些较长的字段，能够思考将它们的类型更改为较短的类型。例如，将 varchar(255) 更改为 varchar(50) 能够缩小索引长度。
④ 应用前缀索引：前缀索引只应用字段值的前几个字符来创立索引。这能够缩小索引长度。例如，CREATE INDEX idx_name ON mytable (name(20)); 只会应用 name 字段的前 20 个字符来创立索引。
⑤ 手动创立索引：如果主动生成的索引长度太长，能够思考手动创立索引并指定较短的索引长度。须要留神的是，更改数据库配置或表格构造可能会影响现有的数据。在执行任何更改之前，请务必备份你的数据。 ...

前言 本专栏内容将会具体解说MySQL数据库技术。数据库技术是Java开发中必不可少的一部分常识内容。也是十分重要的技术。 本系列教程由浅入深, 全面解说数据库体系。 非常适合零根底的小伙伴来学习。全文大概 【1092】字， 不说废话，只讲能够让你学到技术、明确原理的纯干货！本文带有丰盛案例及配图，让你更好的了解和使用文中的技术概念，并能够给你带来具备足够启迪的思考 一. 什么是表表 : 数据在数据库中是以一个一个表格模式存在并且组织的。 有行， 有列。 二. 表构造操作 1.数据表的创立（CREATE） 创立表语法格局如下： CREATE TABLE 表名（列名 数据类型 [束缚],列名 数据类型 [束缚],....列名 数据类型 [束缚] //最初一列的开端不加逗号）[charset=utf8] //可依据须要指定表的字符编码集 案例 ：创立合乎上面字段名， 字段类型的表 列名数据类型阐明subjectIdINT课程编号subjectNameVARCHAR（20）课程名称subjectHoursINT课程时长创立表案例语句：#根据上述表格创立数据表 CREATE TABLE subject( subjectId INT, subjectName VARCHAR(20), subjectHours INT)charset=utf8;2.数据表的批改（ALTER） 批改表语法如下： ALTER TABLE 表名 操作; 2.1 向现有表中增加列 在表构造曾经确定后， 如果想要减少一列能够应用上面语句进行更改： #在课程表根底上增加gradeId 列ALTER TABLE subject ADD gradeId int;2.2 批改表中的列 在表构造确定后，有的时候字段长度定的短了，能够用上面语句更改字段类型和长度： #批改课程表中课程名称长度为10个字符ALTER TABLE subject MODIFY subjectName VARCHAR(10);2.3 删除表中的列 #删除课程表中 gradeId 列ALTER TABLE subject DROP gradeId;留神：删除列时，每次只能删除一列 ...

前言本系列文章会带各位小伙伴学习数据库技术。数据库技术是Java开发中必不可少的一部分常识内容。也是十分重要的技术。 本系列教程由浅入深, 全面解说数据库体系，非常适合零根底的小伙伴来学习。 全文大概 【1466】字，只讲能够让你学到技术、明确原理的纯干货！本文带有丰盛案例及配图，让你更好的了解和使用文中的技术概念，并能够给你带来具备足够启迪的思考 一. 什么是数据库 1.数据库软件MDBS（数据库管理系统）在上节课教大家从MySQL官网下载并且装置的mysql-installer-community-5.7.28.0.msi就是数据库软件MDBS。它装置在操作系统上并且运行， 是用来治理数据库（DataBase）的软件。 2.数据库（DataBase）数据库是保留有组织数据的容器，也是存储数据的仓库，所有的表都放在数据库中。 咱们通常讲的数据库就是这个， 而不是数据库软件。 3.表（Table）某种特定类型的结构化清单，数据库中的每一个表的名字都是惟一的。雷同的数据库中不能两次应用雷同的表名，不同的数据库中能够应用雷同的表名。艰深的讲表就是有行有列以表格模式， 也就是二维表模式进行组织存储数据。 表有行和列组成，列中存储着表中某局部的信息 3.1 列（Column）表中的某一个字段，所有表都是由一个或多个列组成的。数据库中每个列都有相应的数据类型。 3.2 行（Row）表中的一个记录，表中的数据都是按行存储的，垂直的列为表列，程度行为表行。 二. 数据类型（DataType）所答应的数据的类型，数据库中每个列都有相应的数据类型。不同数据类型的列，存储不同格局的数据。 MySQL反对多种类型，大抵能够分为三类：数值、日期/工夫和字符串(字符)类型。对于咱们束缚数据的类型有很大的帮忙。 1.数值类型类型 大小 范畴（有符号） 范畴（无符号） 用处 INT 4 字节 (-2 147 483 648，2 147 483 647) (0，4 294 967 295) 大整数值 DOUBLE 8 字节 （-1.797E+308,-2.22E-308） (0,2.22E-308,1.797E+308) 双精度浮点数值 DOUBLE(M,D) 8个字节，M示意长度，D示意小数位数 同上，受M和D的束缚 DOUBLE(5,2) -999.99-999.99 同上，受M和D的束缚 双精度浮点数值 DECIMAL(M,D) DECIMAL(M,D) 依赖于M和D的值，M最大值为65 依赖于M和D的值，M最大值为65 小数值 2.日期类型类型 大小 范畴 格局 用处 DATE 3 ...

4月22日下午14:00，云数据库技术和NineData主办的「MySQL x ClickHouse」技术沙龙，将在杭州市海智核心3号楼1102报告厅举办。 本次沙龙以“技术进化，让数据更智能”为主题，汇聚字节跳动、阿里云、玖章算术、华为云、腾讯云等泛滥数据库厂商的技术大咖， 围绕MySQL x ClickHouse的实践经验，与宽广技术爱好者交换分享。 MySQL 是毫无争议的最受欢迎的数据库，在事实世界中反对了有数大大小小的业务场景；ClickHouse 是最近几年增长最疾速的开源剖析型数据库，因为其对于性能的极致谋求，使其即便是单机的状况下，也有着十分优良的性能体现。而这也十分好地补救了 MySQL 在简单剖析查问上的性能短板。 这次，咱们就一起来看看 MySQL x ClickHouse会碰撞出怎么的火花。更多对于「MySQL x ClickHouse」技术沙龙： https://www.ninedata.cloud/cdb 去年3月25日，“云数据库技术”公众号正式开启，至今，共公布了83篇原创，心愿帮忙开发者更好的理解各个不同云厂商的数据库技术。当初，强制口罩的日子终于过来，于是，打算在杭州--这个代表勃勃生机、代表漂亮江南的中央，开启咱们的第一次线下团聚。

之前松哥写过一个 MySQL 系列，然而过后是基于 MySQL5.7 的，最近有空在看 MySQL8 的文档，发现和 MySQL5.7 相比还是有不少变动，同时 MySQL 又是小伙伴们在面试时一个十分重要的知识点，因而松哥打算最近再抽空和小伙伴们聊一聊 MySQL，讲讲原理，讲讲优化，我会从最根本最简略的开始，和大家梳理 MySQL 中常见的面试知识点。 本文咱们就先从最简略的索引开始吧～ 1. 什么是索引说到索引，最常见的例子就是查字典，当咱们须要查问某一个字的含意时，失常操作都是先依据字典的索引，找到该字在哪一页，而后间接翻到该页就行了。如果没有这个索引的话，那么咱们就得一页一页的翻字典，直到找到该字。很显著，绝对于第一种计划，第二种计划效率就要低很多了。 数据库中的索引也是相似的。 索引，咱们也称之为 index 或者 key，当数据量比拟少的时候，索引对于查问产生的成果并不显著，所以索引经常被人所疏忽，然而当数据量比拟大的时候，一个优良的索引对查问产生的影响就是非常明显的了。在咱们所把握的各种 SQL 优化策略中，索引对 SQL 优化产生的成果算是最好的了，用好索引，SQL 性能可能会晋升好几个数量级。 这里有的小伙伴可能会有一个纳闷，很多索引优化策略都是针对传统的机械硬盘的，然而当初咱们大部分都是固态硬盘（SSD），很多针对机械硬盘的优化策略在 SSD 上仿佛并没有必要，那还有必要去思考索引优化吗？答案当然是有！无论是用什么样的磁盘，索引优化的整体准则都是不变的，只不过在 SSD 上，如果你的索引没有创立好，那么它对查问的影响不像对机械硬盘那么蹩脚。2. 索引的数据结构2.1 B+Tree 和 B-Tree小伙伴们晓得，因为 MySQL 中的存储引擎设计成了可插拔的模式，任何机构和集体如果你有能力，都能够设计本人的存储引擎，而 MySQL 的索引是在存储引擎层实现的，而不是在服务器层实现的，所以不同存储引擎的索引工作形式都不一样，甚至，雷同类型的索引，在不同的存储引擎中实现计划都不同。 本文松哥次要和小伙伴们介绍咱们日常开发中最最常见的 InnoDB 存储引擎中的索引。 小伙伴们晓得，InnoDB 存储引擎的索引数据结构是一个 B+Tree，至于什么是 B+Tree，这并非本文的重点，我这里不啰嗦，不理解 B+Tree 的小伙伴能够自行搜寻一下学习一下。 假如我有如下数据： usernameageaddressgenderab99深圳男ac98广州男af88北京女bc80上海女bg85重庆女bw95天津男bw99海口女cc92武汉男ck90深圳男cx93深圳男当初我给 username 和 age 字段建设联结索引，那么最终数据在磁盘上的存储构造是 B+Tree，为了小伙伴可能更好的了解 B+Tree 和 B-Tree，我画了如下两张图： 这两张图看懂了，InnoDB 存储引擎的索引我感觉基本上都搞懂了 80% 了，松哥来和大家略微梳理一下这张图： 首先这两张图都是一个多路均衡查找树，即，不是二叉树，是多叉树。绿色的方块示意指向下一个节点的指针；红色的方块示意指向下一个叶子节点的指针（B-Tree 中不存在该局部）；带暗影的矩形则示意索引数据。B+Tree 非叶子节点只保留关键字的索引和指向下一个节点的指针（绿色区域），所有的数据最终都会保留到叶子节点。因而在具体的搜寻过程中，所有数据都必须要到叶子节点能力获取到，因而每次数据查问所需的 IO 次数都一样，这也就意味着 B+Tree 的查问速度比较稳定。 ...

本文曾经收录到Github仓库，该仓库蕴含计算机根底、Java根底、多线程、JVM、数据库、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服务、设计模式、架构、校招社招分享等外围知识点，欢送star~ Github地址 如果拜访不了Github，能够拜访gitee地址。 gitee地址 前言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。最全面的Java面试网站实例阐明为了依据以上两个老本来算出应用索引的最终老本，咱们先筹备一个表（以下操作基于 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 行数据，只有写一个存储过程调用即可，如下: ...

前言从明天开始就带各位小伙伴学习数据库技术。 数据库技术是Java开发中必不可少的一部分常识内容。也是十分重要的技术。本系列教程由浅入深, 全面解说数据库体系。 非常适合零根底的小伙伴来学习。a 全文大概 【1800】字，不说废话，只讲能够让你学到技术、明确原理的纯干货！本文带有丰盛案例及配图，让你更好的了解和使用文中的技术概念，并能够给你带来具备足够启迪的思考...... 一. MySQL数据库装置与配置1. 拜访与下载官方网站：https://www.mysql.com/下载地址：https://dev.mysql.com/downloads/mysql/ 1.1 版本抉择 1.2 下载页面 2. MySQL服务器装置接下来咱们就运行mysql-installer-community-5.7.28.0.msi，进入到具体的装置步骤中。 2.1 勾选协定批准协定，点击下一步。 2.2 抉择装置类型抉择装置类型，点击下一步。 2.3 配置依赖环境留神：装置须要依赖环境，如需装置的性能短少对应环境，需先装置环境。 2.4 短少依赖提醒下一步的时候会提醒短少环境，此处的提醒是说你冀望装置的产品中短少依赖。大家要留神，这里不肯定提醒短少的是数据库服务器装置的依赖，也有可能是提醒短少其余性能组件的依赖。 2.5 装置依赖此处发现没有 mysql server，阐明它对应的依赖短少，能够先执行装置这些能够装置的，之后装置完依赖后，再重新安装其余模块。咱们此处的操作是先装置依赖，而后后退再次装置。 2.6 筹备装置下载安装后面提醒的vc2013。如果你是运行在64位零碎上，倡议32和64位的程序都装置上。而后在上图所示的中央后退，从新next就能够看到，而后就能够持续装置mysql server了。 2.7 装置前查看查看是否存在失败项。 2.8 设置配置信息进行第一步配置，除了须要设置明码外，前面的步骤基本上都是下一步。 2.9 设置类型与网络类型与网络配置。 2.10 设置管理员明码设置 root 明码, 也就是超级管理员明码, 我个别设置123456, 这样比拟好记不容易忘。 2.11 设置SQL服务创立SQL服务与窗口。 2.12 装置插件 2.13 初始化设置利用配置，让配置失效。 2.14 实现装置finish后回到以后页面持续配置。 2.15 连贯服务器测试连贯服务器，先点击 check查看, 后下一步。 2.16 测试及配置实现执行完此步骤 下一步 finish 配置实现。 3. MySQL服务器卸载●控制台卸载。●找到mysql的装置目录进行删除。●programdata 删除mysql留神：如果卸载后，如有未删除的MySQL服务，可采纳手动删除。以管理员身份关上命令行，输出 sc delete MySQL57 回车。 4. MySQL服务器配置环境变量●Windows ●创立MYSQL_HOME：C:\Program Files\MySQL\MySQL Server 5.7●追加PATH：%MYSQL_HOME%\bin;●MacOS / Linux ●终端中输出cd ~ 进入目录，并查看.bash_profile是否存在，有则追加，无则创立●创立文件 touch .bash_profile●关上文件 open .bash_profile●输出export PATH=${PATH}:/usr/local/mysql/bin 保留并退出终端5. MySQL目录构造介绍外围文件介绍 ...

上一篇，提到了我为什么要写MySQL系列教程的起因。这一篇，咱们就来开始MySQL系列学习的第一篇，MySQL的装置。MySQL的装置有很多中形式，本文重点实际在Centos操作系统上实现源码的装置。这里也总结一下，我集体晓得的一些装置形式。 1、如果是在Mac操作系统，你能够间接到官方网站下载.dmg格局的安装包进行装置，也能够应用包治理命令(port、brew)进行装置。同时也你能够应用docker进行装置。 2、如果你是Windows，你能够间接到官方网站下载.msi格局的安装包进行装置，也能够应用一些集成环境，例如PHPStudy。同时你也能够应用docker进行装置。 3、如果你是Linux，你能够应用包管理工具(yum)装置，或者应用.rpm包装置，同时你也能够应用二进制文件装置，或者应用docker进行装置。 不同的装置形式，优缺点其实也有所不同。 1、例如你用包治理命令装置，这种形式非常简单，包管理工具个别会主动帮你解决依赖问题，不须要手动的解决这些问题。同时卸载也比拟不便。 2、如果你是Linux装置，采纳的.rpm格局，这种略微麻烦一些，须要你手动的解决包依赖，同时你卸载也比拟繁琐，你要手动的去卸载一些依赖包。也不举荐应用这种形式。 3、因为docker、k8s的宽泛应用，当初风行的装置形式，应该是这种了。间接写好.dockerfile文件，能够实现跨平台的装置。 4、本章次要是学习MySQL的装置，因而咱们采纳二进制的形式进行装置，相熟整个装置流程。 本系列教程采纳的是MySQL8.0的版本。这一点可能须要大家留神一下。对于MySQL8.0的装置，本文演示两种装置形式，一种是二进制形式装置，另外一种是采纳docker装置。 Linux装置Linux我采纳的是centos7的版本，本地搭建的一个虚拟机。你须要依据本人的状况，去搭建这样的一套学习环境，这里就演示装置虚拟机的过程了。如果遇到什么问题，你也能够独自找我，帮助解决。我下载的centos7，内置了MariaDB，因而咱们实现须要把MariaDB卸载了。 卸载mariadb你能够应用如下的命令，查看本地是否装置了MariaDB。如果没有显示上面的文件，示意没有装置，省略掉上面的卸载命令即可。 # 查看MariaDB是否装置[root@192 yum.repos.d]# rpm -qa|grep mariadbmariadb-libs-5.5.68-1.el7.x86_64# 卸载MariaDB[root@192 yum.repos.d]# rpm -e --nodeps mariadb-libs-5.5.68-1.el7.x86_64# 检测卸载后果，输入的内容是空则示意卸载胜利[root@192 yum.repos.d]# rpm -qa|grep mariadb下载二进制文件要下载二进制文件，能够间接到MySQL官网进行下载，具体的地址是。在界面上依据下图的示例，进行下载即可。你也能够应用上面的链接进行下载，这也是我本地应用的链接地址。 cd ~ && wget https://cdn.mysql.com//Downloads/MySQL-8.0/mysql-8.0.30-el7-x86_64.tar下载好之后，把该文件复制到/usr/local目录上面，而后对其解压。 # cp mysql-8.0.30-el7-x86_64.tar /usr/local# 解压tar -xvf mysql-8.0.30-el7-x86_64.tar# 查看解压文件-rw-r--r--. 1 7161 31415 492490461 7月 7 2022 mysql-8.0.30-el7-x86_64.tar.gz-rw-r--r--. 1 7161 31415 22006040 7月 7 2022 mysql-router-8.0.30-el7-x86_64.tar.gz-rw-r--r--. 1 7161 31415 305543348 7月 7 2022 mysql-test-8.0.30-el7-x86_64.tar.gz通过解压，咱们会失去下面的3个压缩包，重点咱们关注mysql-8.0.30-el7-x86_64.tar.gz这个文件即可，其余的两个，咱们暂且不论。 解压好之后，咱们再对mysql-8.0.30-el7-x86_64.tar.gz文件进行解压。 # 解压tar -xvf mysql-8.0.30-el7-x86_64.tar.gz# 对文件夹进行重命名mv mysql-8.0.30-el7-x86_64 mysql# 查看文件目录cd mysql && lldrwxr-xr-x. 2 7161 31415 4096 7月 7 2022 bindrwxr-xr-x. 2 7161 31415 55 7月 7 2022 docsdrwxr-xr-x. 3 7161 31415 4096 7月 7 2022 includedrwxr-xr-x. 6 7161 31415 201 7月 7 2022 lib-rw-r--r--. 1 7161 31415 287624 7月 7 2022 LICENSEdrwxr-xr-x. 4 7161 31415 30 7月 7 2022 man-rw-r--r--. 1 7161 31415 666 7月 7 2022 READMEdrwxr-xr-x. 28 7161 31415 4096 7月 7 2022 sharedrwxr-xr-x. 2 7161 31415 77 7月 7 2022 support-files# 创立数据目录(肯定留神data目录是放在mysql目录下的)mkdir data用户权限对MySQL的基本操作，咱们就先执行到这里，接下来创立MySQL用户组、用户。 ...

作者：李锡超 一个爱笑的江苏苏宁银行 数据库工程师，次要负责数据库日常运维、自动化建设、DMP平台运维。善于MySQL、Python、Oracle，喜好骑行、钻研技术。本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 研发同学反馈某零碎性能测试环境MySQL数据库相干的业务零碎运行失常，但存在大量正告日志，需配合剖析起因。 一、异常现象mysql谬误日志文件中存在大量如下信息： 2023-01-10T01:07:23.035479Z 13 [Warning] [MY-013360] [Server] Plugin sha256_password reported: ''sha256_password' is deprecated and will be removed in a future release. Please use caching_sha2_password instead'要害环境信息 二、初步剖析当看到如上正告日志时，依据经验主义，第一反馈应该是客户端的版本过低，其受权认证插件是服务端将要废除的版本，所以产生了以上告警信息。特地是一些常见的客户端的工具，可能会因为更新频率，会很容易触发该问题。 尝试复现依据初步剖析倡议，将初步剖析倡议与研发同学沟通后，通过常见的数据库工具拜访数据库，看是否是否复现该谬误。但通过数据库外面常见的数据库用户，通过不同的工具拜访数据库，均未在拜访时刻触发该异样。由此，第一次尝试复现失败。难道是因为其它起因？ 再第一次尝试拜访的过程，通过实时察看数据库谬误日志。在用客户端尝试拜访的过程中，没有复现该谬误。然而依然看到对应的正告日志在继续输入到谬误日志文件。且频率较高、间隔时间固定，由此也证实在谬误不是数据库工具人工拜访的。 利用零碎运行失常，又不是客户端导致的！作为DBA的你，应该如何进一步剖析呢？ 初放小招因为所处测试环境，针对该谬误，能够执行如下操作启用MySQL的个别日志： -- 开明个别日志：show variables like 'general_log';set global general_log=on;show variables like 'general_log';-- 查看个别日志门路：show variables like 'general_log_file';启用日志后，察看谬误日志，发现个别日志中如下记录： 提醒：发现异常后，立刻敞开个别日志，防止产生过多日志耗尽磁盘空间： -- 开明个别日志：show variables like 'general_log';set global general_log=off;show variables like 'general_log';即用户dbuser2 在问题时刻从10.x.y.43 服务器发动了拜访数据库的申请。确认异样拜访的用户和服务器后，查看数据库mysql.user表、skip-grant-tables等配置，发现数据库并不存在该用户，且没有跳过受权表等配置。应用该用户将无奈登录到数据库。 将信息反馈至研发同学，很快就确认了是因为局部利用配置不合理，应用了不存在的数据库用户，并定时连贯数据库执行工作。于是研发同学批改配置后，正告日志不再产生。 那么该问题剖析到此，能够完结了么？ 批改配置后，正告日志不在产生！但既然是不存在的用户，拜访时为什么还提醒认证插件将废除呢？ 三、源码剖析带着问题，首先想到的是：既然数据库用户为存在于mysql.user表，登录也会产生正告，难道这个用户是mysql的外部用户，被硬编码了么！于是取到对应版本源码，通过如下命令进行确认： cd mysql-8.0.27/grep -rwi "dbuser2" *其拜访后果为空，即不存在猜测的“外部用户”。 ...

作者：京东批发  李泽阳 最近在浏览《认知沉睡》这本书，外面有句话十分感动我：通过本人的语言，用最简略的话把一件事件讲清楚，最好让外行人也能听懂。 兴许这就是大道至简，只是咱们习惯了繁缛和简单。 心愿借助明天这篇文章，能用大白话说分明这个绝对比拟底层和简单的MVCC机制。 在开始之前，先抛出一个问题：咱们都晓得，目前（MySQL 5.6以上）数据库已广泛应用InnoDB存储引擎，InnoDB绝对于MyISAM存储引擎其中一个益处就是在数据库级别锁和表级别锁的根底上反对了行锁，还有就是反对事务，保障一组数据库操作要么胜利，要么失败。基于此，问题来了，在InnoDB默认隔离级别（可反复读）下，一个事务想要更新一行数据，如果刚好有另外一个事务领有这个行锁，那么这个事务就会进入期待状态。既然进入期待状态，那么等到这个事务获取到行锁要更新数据的时候，它读取到的值是什么呢？ 具体的问题见下图，咱们设定有一张表user，初始化语句如下，试想在这样的场景下，事务A三次查问的值别离是什么？ create table `user` (`id` bigint not null,`name` varchar(50) default null,PROMARY KEY (`id`)) ENGINE = InnoDB;insert into user(id,name) values (1,'A'); 想要把这件事件答复正确，咱们先来铺垫一下基础知识。 提到事务，首先会想到的就是ACID（Atomic原子性、Consist一致性、Isolate隔离性、Durable持久性），明天咱们次要关注隔离性，当有多个事务同时执行产生并发时，数据库可能会呈现脏读、不可反复读和幻读等问题，为了解决这些问题，“隔离级别”这位大哥上场，蕴含：读未提交、读已提交、可反复读和串行。 但咱们都晓得，隔离级别越高，执行效率越低。毕竟大哥就是大哥，级别越高，越审慎，常在河边走哪能不湿鞋。 咱们通过一个例子简略说一下这四种隔离级别： • 读未提交：一个事务还未提交，它的变更就能被其余事务看到。V1为B，V2为B，V3为B。 • 读已提交：一个事务提交之后，变更后果对其余事务可见。V1为A，V2和V3为B。 • 可反复读：一个事务执行过程中看到的数据与事务启动时统一。V1为A，V2为A，V3为B。 • 串行：不论读和写，加锁就完了，就是干！V1和V2均为A，V3为B。 事务是怎么实现的呢？实际上，事务执行时，数据库会创立一个视图，读未提交间接返回最新值，没有视图概念；串行是间接加锁防止并发拜访；读已提交是在每个SQL语句开始执行时创立的视图。可反复读的视图是在事务启动的时候创立的，整个事务都会应用这个视图。这样的话，下面四种不同隔离级别下的V1、V2、V3值便对号入座，有了后果。 **MySQL是怎么实现的呢？**咱们以MySQL默认的可反复读隔离级别为例，实际上每条行记录在更新时都会记录一条回滚日志，也就是大家常说的undo log。通过回滚操作，都能够失去前一个状态的值。假如name值从初始值A被顺次更新为B、C、D，咱们看一下回滚日志： 以后值是D，然而在查问这条记录的时候，不同时刻启动的事务会有不同的视图，看到的值也就不一样。在视图1、2、3、4外面，记录的name值别离是A、B、C、D。同一条行记录在数据库中能够存在多个版本，这就是多版本并发管制（MVCC）。对于视图1，如果想要将name值回到A，那么就要顺次执行图中所有回滚操作。 到这里，你曾经接触到了MVCC的概念，兴许你曾经对文章最开始的问题有了一点点想法，别着急，咱们先来简略总结下MVCC的特点： MVCC的呈现使得一条行记录在不同隔离级别下不同的事务操作会造成一条不同版本的链路，从而实现在不加锁的前提下使不同事务的读写操作可能并发平安执行，这个版本链就是通过回滚日志undo log实现的。用大白话说，你这个事务想要查问一条行记录，MVCC会通过你这个事务所在视图确认版本链中哪个版本的行数据对你可见。方才咱们提到，四种隔离级别下，只有读已提交和可反复读会用到视图。对于读已提交，MVCC会在每次查问前都会生成一个视图，可反复读隔离级别只会在第一次查问时生成一个视图，之后在这个事务中的所有查问操作都会重复使用这个视图。行业上，将创立视图的那一刻称为快照，晃你一下子，让你激灵激灵，别产生脏读，变脏喽～ 想要解决文章最开始的那个问题，咱们还得开展说说版本链是如何造成的和快照的原理，稍有干燥，先忍一下，急躁看上来，乖～ 对于InnoDB存储引擎来说，主键索引（也称为聚簇索引）记录中除了失常的字段数据外，还蕴含两个暗藏列： （1）trx\_id：每次一个事务想要对主键索引进行更新、删除和新增时，都会把这个事务的事务id赋值给trx\_id字段。留神事务id严格递增，且查问操作不会调配事务id，即trx_id = 0; （2）roll\_point：每次一个事务对主键索引进行更新时，都会把旧的版本写入到undo日志中，roll\_point相当于一个指针，通过它能够找到这条记录批改前的信息。 咱们以可反复读隔离级别为例，为了尚未提交的更新后果对其余事务不可见，InnoDB在创立视图时，有以下四局部组成： • m_ids：示意生成视图时，以后零碎中“沉闷”的读写事务的事务id列表，这里的沉闷大白话就是事务尚未提交； • min\_trx\_id：示意在生成视图时，以后零碎中沉闷的读写事务中最小的事务id，即m_ids中的最小值； • max\_trx\_id：示意生成视图时零碎应该调配给下一个事务的id值； • creator\_trx\_id：示意生成该视图的事务id。 概念比拟多，举个例子，当初有事务id别离是1、2、3三个事务，1和2事务尚未提交，3事务已提交，这个时候如果来了一个新事务，那么它创立的视图对应这几个参数别离为：m\_ids蕴含1、2，min\_trx\_id为1，max\_trx_id为4。 要害的知识点来了，如何依据某个事务生成的视图，判断版本链上的某个版本对这个事务可见呢？ 遵循上面步骤： 1、版本链上的不同版本trx\_id值如果与这个视图的creator\_trx_id值雷同，阐明以后事务在拜访它本人批改过的记录，所以被拜访的版本对以后事务可见。一家人还是意识一家人的～ 2、版本链上的不同版本trx\_id值小于这个视图的min\_trx_id值，阐明这个版本的事务在以后事务生成视图之前就曾经提交了，所以被拜访的版本对以后事务可见。 3、版本链上的不同版本的trx\_id值大于或等于这个视图的max\_trx_id值，阐明这个版本的事务在以后事务之后才开启，所以被拜访版本对以后事务不可见。 ...

1. 深度分页1.1. 定义早些年在企业表格类的页面中，咱们总能见到分页的那种表格设计。当分页的页数太多，还设计了“跳转到x页”的性能。 咱们这里讲的“深度分页”，就是指当分页太多（假如有几十万页），当拜访第几万页时，必然会查问很慢。因为针对通常对于分页的搜寻，都是将几万页的数据查出来，而后取差集，只返回当前页的数据。只为了返回一页的数据，却查问的很深刻，带来的性能代价很大。 1.2. 需要上杜绝1. 少分页首先，咱们先想想这样的需要设计是否正当，谁会在一个表格中跳到第几万页查看数据。咱们如果想要找到想要的内容，应该是通过搜寻，而非每页都点进去去看。 所以看看百度、谷歌搜索引擎的设计，都是最多只展现10页。 2. “翻页”代替“跳页”那如果有些场景，我就须要查看所有页面的内容呢？例如：贴吧的评论等。ok，就算有这种状况，也不应该存在“跳页”的需要，能够设计成一页一页的“翻页”。 例如咱们身边很多app的设计：下拉刷新更多。每下拉一次，就多展现一页数据。 总结来看，切实想不到须要深度“跳页”的需要，那就应该在需要上杜绝。如果为了一个没必要的需要，须要对研发、服务器投入大量的资源耗费，是很节约的。 1.3. 技术实现上面是从 mysql 和 elasticsearch 的维度讲讲深度分页的实现。这里先总结一下： mysql：深度分页，包含跳页也能做，能够通过缩小回表进步性能elasticsearch：人造不倡议跳页，但提供了翻页的优化计划2. mysql深度分页优化2.1. 缩小回表优化前表格查问，基本上查问的字段都要求很多。依照通常分页查问的场景，假如失常分页查问的sql如下： select * from table_name where userId = 'xxx' limit 10000, 10就算咱们基于 userId 创立一般索引，因为 select * ，咱们仍然要先基于一般索引查问 10010 条数据，而后回表查问 10010 次，但最初再将前 10000条数据丢掉，只取10条。 优化后优化的sql是： select * from table_name where id in (select id from table_name where userId = 'xxx' limit 10000, 10)这里建设子查问，子查问中只查问了主键，能够走一般索引间接查到。而最终的回表查问，只是查 10 条数据。所以，防止了 10000 次的回表，而且防止了 10000 次 select * 带来的 io 节约。 ...

MySQL 提供了 mysqldump 命令来实现导出数据库，命令用法如下： mysqldump -u root -p[password] [database_name] > [backup].sql在 Linux 服务器中联合 crontab 定时命令实现定时备份数据库，同时反对压缩、备份日志、定期清理等性能。 1. 备份执行脚本新建 mysql 的备份命令脚本 $ vi db_backup.sql复制以下内容： #!/bin/bash# 数据库名称database_name="mydb"mysql_password=""# 备份文件保留地址backup_dir="/mydata/backup/mydb"# 备份文件名前缀backup_prefix="demo"# 备份文件的有效期，单位为daybackup_days="30"dd=`date +%Y-%m-%d-%H-%M-%S`backup_file="$backup_dir/$backup_prefix-$dd.sql"if [ ! -d $backup_dir ]; then mkdir -p $backup_dir; fimysqldump -u root -p$mysql_password $database_name > $backup_file# 压缩sql文件gzip -f $backup_file# 写创立备份日志echo "create $backup_dir/$database_name-$dd.dupm" >> $backup_dir/log.txt# 革除过期的文件find $backup_dir -name "$backup_prefix*.sql.gz" -mtime +$backup_days -exec rm {} \;至此，执行该脚本，能够生成压缩的数据库.sql文件 2. 定时工作应用 crontab 命令定期执行脚本 # 编辑 cron 脚本文件$ sudo crontab -e在关上的配置文件中追加以下内容： ...

1 引言在日常工作中，咱们会遇见一些慢SQL，在剖析这些慢SQL时，咱们通常会看下SQL的执行打算，验证SQL执行过程中有没有走索引。通常咱们会调整一些查问条件，减少必要的索引，SQL执行效率就会晋升几个数量级。咱们有没有思考过，为什么加了索引就会能进步SQL的查问效率，为什么有时候加了索引SQL执行反而会没有变动，本文就从MySQL索引的底层数据结构和算法来进行详细分析。 2 索引数据结构比照索引的定义：索引(Index)是帮忙MySQL高效获取数据的排好序的数据结构。 索引中常见的数据结构有以下几种： Hash表二叉树红黑树B-TreeB+TreeHash表 通过索引的key进行一次hash计算，就能够疾速获取磁盘文件指针，对于指定索引查找文件十分快，然而对于范畴查找没法反对，有时候也会呈现Hash抵触的状况。 二叉树 二叉树的特点：右边子节点的数据小于父节点数据，左边子节点的数据大于父节点数据。如下图所示，如果col2是索引，查找索引为65的行元素，只须要查找两次，就能够获取到行元素所在的磁盘指针地址。 但如果是一个依照程序递增的值，例如为col1建设索引，不再适宜应用二叉树建设索引，因为此时应用二叉树建设索引将会变成一个链式索引，此时的索引构造如下图所示，如果查找6节点须要6次遍历能力找到。 红黑树 红黑树是一种二叉均衡树，能够进步查问效率，此时若再查找6节点只须要遍历3次就能找到了。但红黑树也有毛病，当存储大数据量时，树的高度就会变的不可控， 数量越大，树的高度越高，查问的效率将会大大降低。 B-Tree B-Tree是一种多路二叉树，所具备的特点：1 叶节点具备雷同的深度，叶节点的指针为空；2 所有索引元素不反复；3 节点中的数据索引从左到右递增排列。 B+Tree B+Tree是B-Tree的变种，所具备的特点：1 非叶子节点不存储data，只存储索引(冗余)，能够放更多的索引；2 叶子节点蕴含所有索引字段；3 叶子节点用指针连贯，进步区间拜访的性能。 与红黑树相比，B-Tree和B+Tree两种数据结构都更加矮胖，存储雷同数量级的索引数据时，层级更低。 B-Tree和B+Tree之间一个很大的不同，是B+Tree的节点上不贮存value，只贮存key，而叶子节点上贮存了所有key-value汇合，并且节点之间都是有序的。这样的益处是每一次磁盘IO可能读取的节点更多，也就是树的度(Max.Degree)能够设置的更大一些，因为每次磁盘IO读取的磁盘页数是肯定的。例如，每次磁盘IO可能读取1页=4kb，那么省去value的状况下同样一页数据可能读取更多的key，这样就大大减少了磁盘的IO次数。 此外，B+Tree也是排好序的数据结构，数据库中><或者order by等都能够间接依赖这一个性。 MySQL中对于索引应用的次要数据结构也是B+Tree，目标也是在读取数据时可能缩小磁盘IO。 3 千万级数据如何用B+树索引疾速查找MySQL 官网对非叶子节点(如最上层 h = 1的节点，B+Tree高度为3) 的大小是有限度的，最大的大小是16K，能够通过以下SQL语句查问到，当然这个值是能够调的，既然官网给出这个阈值阐明再大的话会影响磁盘IO效率。 从执行后果，能够看到大小为 16384，即 16K大小。 如果：B+Tree的表都存满了。主键索引的类型为BigInt，大小为8B，指针存储了下个节点的文件地址，大小为6B。最初一层，如果 寄存的数据data为1K 大小，那么 第一层最大节点数为： 16k / (8B + 6B) ≈ 1170 (个)；第二层最大节点数也应为：1170个；第三层最大节点数为：16K / 1K = 16 (个)。则，一张B+Tree的表最多寄存 1170\_1170\_16 ≈ 2千万。 所以，通过剖析，咱们能够得出，B+Tree构造的表能够包容千万数据量的查问。而且一般来说，MySQL会把 B+Tree 根节点放在内存中，那只须要两次磁盘IO就行。 ...

在微服务和云原生愈发风行的明天，数据的散布也愈发脱离单库单机而更加简单，应用的数据库类型也会更多，但业务的简单仍然会带来了大量的数据查问和导出需要，而很多时候咱们很难为数据量的大部分零碎创立残缺的BI数仓零碎，这时候你是不是感觉为这些需要查问和导出数据就会是一个十分困难且耗时的工作？Syncany-SQL就是这样一个工具，来在不依赖数据库的状况下实现不同库表、不同机器和不同数据库类型间间接关联查问和聚合计算后间接导出到罕用文件的工具。 间接在本地运行MySQL语法结构的SQL的执行引擎，只应用查看查问从罕用MySQL、MongoDB、PostgreSQL、sqlserver、elasticsearch、influxdb、clickhouse、sqlite数据库加载数据及读取execl、csv、json和一般文本文件后，在内存中实现join和聚合运算，单条SQL的执行后果能够长期保留在内存中以便作为后续SQL的输出表持续解决，并且INSERT INTO语句执行指定”仅插入 I“、”存在更新否则插入 UI“、”存在更新否则插入其余删除 UDI“、”删除后插入 DI“四种合并数据模式，针对大数据量也能够分批执行。 整个程序共有两个我的项目组成，其中 https://github.com/snower/syncany-sql 负责解析SQL https://github.com/snower/syncany 负责执行 个性Join关联查问，反对在不同库表、不同机器和不同数据库类型之间Join查问Having在内存中执行，反对简单条件过滤，只蕴含聚合计算字段过滤时运行在聚合运算之前，否则在聚合计算之后执行齐全在内存中实现Group By分组聚合计算和distinct去重聚合运算Order By排序，如果排序齐全是主表字段则应用数据库实现，否则内存中实现排序反对子查问Where或join on条件反对简略子查问(仅反对and，比拟操作符仅反对==、!=、>、>=、<、<=、in)，其条件会被发送到数据库执行Insert Into除反对失常写入数据库表外可间接写入到execl、json和csv中Insert Into反对指定数据合并类型，共反对4中合并算法 （插入 I，更新否则插入 UI，更新否则插入其余删除 UDI，先删除再插入 DI）能够在设定每批数量后反对按批次执行WHere、Join on和Having条件值都反对子查问返回反对set设置变量值，反对select info给变量赋值，执行拜访变量反对应用罕用MySQL函数限度Where和Join on条件仅可应用==、>、>=、<、<=、!=、in简略条件且仅可用andJoin仅反对Left Join模式，且关联条件中仅被关联表能增加常量条件，被关联表字段不能够是计算值，主表可是计算条件值Join查问及子查问各表必须有别名！！！特地留神：为何会有应用限度，来源于数据库加载数据的根本流程为简化数据库拜访接口，每种数据库实现仅反对简略查问条件和排序来加载数据JOIN关联查问应用IN查问从数据库加载数据后在内存中实现计算装置可应用pip间接装置 pip3 install syncanysql# 执行胜利后，执行echo "select now(), 'hello world';" | syncany-sql# 看到正确输入即为装置胜利因大多数状况应用数据库Driver很少，所以默认不装置数据库Driver，须要根据本人应用的数据库类型自行装置数据库Driver pip3 install pymongo>=3.6.1pip3 install PyMySQL>=0.8.1pip3 install openpyxl>=2.5.0pip3 install psycopg2>=2.8.6pip3 install elasticsearch>=6.3.1pip3 install influxdb>=5.3.1pip3 install clickhouse_driver>=0.1.5pip3 install redis>=3.5.3pip3 install pymssql>=2.2.7配置配置文件反对json和yaml格局，默认加载当前目录的"config.[json|yaml]”和用户目录下"~/.syncany/config.[json|yaml]"文件，当前目录配置文件优先级高于用户目录，合并配置项后为最终加载配置。 具体介绍可查问示例配置文件信息 https://github.com/snower/syncany-sql/blob/main/docs/configure.md 配置实现后，命令行启动时会主动加载配置文件，并且增加的数据库信息将会在真正应用到的时候才会发动连贯，并不会在程序启动就会尝试连贯配置的数据库。 ！！！特地留神的是，SQL中应用的数据库名称是配置文件中为每个数据库连贯指定的名称，而不是数据库中真正的名称。如：# 咱们在配置文件中增加了以下数据库配置databases: - name: test_db driver: mysql host: '127.0.0.1' port: 3306 user: 'root' passwd: '123456' db: 'test' charset: 'utf8mb4' # 编写SQL是，如果咱们须要查问127.0.0.1的test库，咱们应该这样编写SQL select * from test_db;示例查问Nginx日志-- 查问访问量最高的3个IPSELECT seg0 AS ip, COUNT(*) AS cnt FROM `file://data/access.log?sep= ` GROUP BY seg0 ORDER BY cnt DESC LIMIT 3;查问JSON文件# 一个查问json文件的例子 https://github.com/snower/syncany-sql/tree/main/examples/demoSELECT a.site_id, b.name AS site_name, IF(c.site_amount > 0, c.site_amount, 0) AS site_amount, MAX(a.timeout_at) AS timeout_at, MAX(a.vip_timeout_at) AS vip_timeout_at, now() as `created_at?`FROM (SELECT YIELD_DATA(sites) AS site_id, IF(vip_type = '2', GET_VALUE(rules, 0, 'timeout_time'), '') AS timeout_at, IF(vip_type = '1', GET_VALUE(rules, 0, 'timeout_time'), '') AS vip_timeout_at FROM `data/demo.json` WHERE start_date >= '2021-01-01') a JOIN `data/sites.json` b ON a.site_id = b.site_id JOIN (SELECT site_id, SUM(amount) AS site_amount FROM `data/orders.json` WHERE status <= 0 GROUP BY site_id) c ON a.site_id = c.site_idGROUP BY a.site_id;更多罕用例子可查看 https://github.com/snower/syncany-sql/tree/main/examples ...

1、JDBC Connection实例是线程平安的吗？Connection实例是线程平安的吗？能不能只创立一次，共享Connection对象？ 答案是不能的， Connection不是线程平安的，他会在多线程环境下，导致数据库操作的凌乱，特地是在事务存在的状况下：可能一个线程刚开启事务con.setAutoCommit(true)，而另一个线程间接提交事务con.commit();对于独自查问的状况，仿佛不会呈现数据错乱的状况。是因为在JDBC中，应用了锁进行同步**源码：**com.mysql.cj.jdbc.CallableStatement#executeQueryconnection自身是线程不平安的，并且connection创立开销比拟大，所以个别应用数据库连接池来对立的治理connection对象，例如druid连接池，c3p0连接池等等 数据库连接池在应用数据库连接池时，一个线程中所有DB操作都是应用同一个Connection实例吗？在Spring环境中，获取connection源码如下所示：源码：org.springframework.jdbc.datasource.DataSourceUtils#doGetConnection 非事务场景：在非事务创立中(同时没有应用Spring事务管理器)，每一次拜访数据库，都是在DataSource中取出一个Connection实例，调用结束之后偿还资源，因而屡次调用，应该是不同的Connection实例 事务场景：在应用事务的状况下，实际上是在ConnectionHolder中获取的Connection。而ConnectionHolder是在TransactionSynchronizationManager中获取的resources属性的值，即connection对象信息 源码：org.springframework.transaction.support.TransactionSynchronizationManager#doGetResource而ThreadLocal<Map<Object,Object>>线程上下文共享。即Connection对于与Thread绑定。因而在事务中无论操作多少次DB，事实上都是操作的同一个Connection对象 2、MySQL架构设计SQL接口：SQL的规范来承受SQL解析器：了解这个SQL语句要干什么事件查问优化器：抉择一个最优的查问门路执行器：执行器就会去依据咱们的优化器生成一套执行打算，而后不停的调用存储引擎的各种接口去实现SQL语句的执行打算存储引擎：存储引擎其实就是执行SQL语句的，他会依照肯定的步骤去查问内存数据，更新磁盘数据，查问磁盘数据，等等，执行诸如此类的一系列的操作，MySQL的架构设计中，SQL接口，SQL解析器，查问优化器其实都是通用的，他就是一套组件而已，然而存储引擎的话，他是反对各种各样的存储引擎的，比方咱们常见的InnoDB、MyISAM、Memory等等 3、InnoDB内存构造 4、Buffer PoolBuffer Pool: 缓冲池，简称BP。其作用是用来缓存表数据与索引数据，缩小磁盘IO操作，提供效率Buffer Pool由缓存数据页和对缓存数据页进行形容的管制块组成，管制块中存储着对应缓存页的所属的表空间、数据页的编号、以及对应缓存页在Buffer Pool中的地址等信息Buffer Pool默认大小是128M，以Page页为单位，Page页默认大小16kb，而管制块的大小为数据页的5%，大略是800字节留神：Buffer Pool大小为128M指的就是缓存页的大小，管制块则个别占5%，所以每次会多申请6M的内存空间用于寄存管制块 如何判断一个页是否在Buffer Pool中缓存？MySQL中有一个哈希表数据结构，它应用表空间号+数据页号，作为一个key，而后缓存页对应的管制块作为value 当须要拜访某个页的数据时，先从哈希表中依据表空间号+页号看看是否存在对应的缓存页如果有，则间接应用；如果没有，就从free链表中选出一个闲暇的缓存页，而后把磁盘中对应的页加载到缓存页的地位Page页Buffer Pool的底层采纳链表数据结构治理Page。在InnoDB拜访表记录和索引时会在Page页中缓存，当前应用能够缩小磁盘IO操作，晋升效率 Page分类Page页依据状态分为三种类型 : free page : 闲暇page，未被应用clean page : 被应用page，数据没有被批改过dirty page : 脏页，被应用page，数据被批改过，页中数据和磁盘数据产生了不统一 Page如何治理针对下面所说的三种page类型，InnoDB通过三种链表构造来保护和治理 free list : 示意闲暇缓冲区，治理free page Buffer Pool的初始化过程中，是先向操作系统申请间断的内存空间，而后把它划分成若干个管制块&缓存页的键值对 free链表是把所有闲暇的缓存页的管制块作为一个个的节点放到一个链表中，这个链表便称之为free链表 基节点：free链表中只有一个基节点是不记录缓存页信息(独自申请空间)，它外面就寄存了free链表头节点地址，尾节点地址，还有free链表以后有多少个节点磁盘加载过程 : 从free链表中取出一个闲暇的管制块(对应缓存页)把该缓存页对应的管制块的信息填上(例如：页所在的表空间、页号之类的信息)把该缓存页对应的free链表节点(即：管制块)从连贯中移除。示意该缓存页曾经被应用flush list : 示意须要刷新到磁盘的缓冲区，治理dirty page，外部page按批改工夫排序InnoDB引擎为了进步解决效率，在每次批改缓存页后，并不是立即把批改刷新到磁盘上，而是在将来的某个工夫点进行刷新操作，所以须要应用到flush链表存储脏页，但凡被批改过的缓存页对应的管制块都会作为节点退出到flush链表脏页即存在于flush链表，也在LRU链表中，然而两种互不影响，LRU链表负责管理page的可用性和开释，而flush链表负责管理脏页的刷盘操作LRU list : 示意正在应用的缓冲区，治理clean page和dirty page一般LRU算法LRU = Least Recently Used(最近起码应用) : 就是开端淘汰法，新数据从链表头部减少，开释空间的从开端淘汰 当要拜访某个页时，如果不在Buffer Pool，须要把该页加载到缓冲池，并且把缓存页对应的管制块作为节点增加到LRU链表的头部当要拜访某个页时，如果在Buffer Pool中，则间接把该页对应的管制块挪动到LRU链表的头部当须要开释空间时，从开端淘汰待持续。。。，喜爱的话，点赞加关注哈！

事务为了达成一个目标，须要进行一系列的操作，而这一系列的操作合在一起就是事务。 事务的个性事务都具备ACID，即原子性(Automicity)，一致性(Consistency)，隔离性(Isolation)，持久性(Durability)。原子性：事务中的一系列操作要么都胜利，要么都失败。一致性：事务执行时从一个状态转换成另一个状态，然而整个数据的完整性保持稳定。隔离性：事务与事务之间相互隔离。持久性：事务实现后对数据的扭转是永恒的。 通过一个例子来了解事务的个性比方一次购买行为，购买时须要扣除购买人的余额，而后给商家增加收入，最初商品发货。这一整个过程就能够称为一个事务，如果购买的过程中出现异常比方在扣除购买人余额后呈现了异样导致前面的流程无奈进行，则会呈现购买人余额扣除但商家未收到转账，所以一个事务要保障原子性。单方余额的总数在更改前后不变，保障了其一致性。事务完结后数据在库中保留保障了持久性。 事务的隔离级别这里的事务隔离级别是基于MySQL的InnoDB引擎。事务的隔离级别别离有，读未提交，读提交，可反复读，串行。其中读未提交其实就是不加事务，仅仅执行一条更新插入就是读未提交。间接讲述概念并不能很好的了解这几种级别，上面过几个例子来进行阐明。有这么一张表： CREATE TABLE `t` ( `id` int NOT NULL, `a` int DEFAULT NULL, `t_modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `a` (`a`), KEY `t_modified` (`t_modified`)) ENGINE=InnoDB;INSERT INTO t VALUES(1,1,'2018-11-12 00:00:00');INSERT INTO t VALUES(2,2,'2018-11-14 00:00:00');INSERT INTO t VALUES(3,3,'2018-11-18 00:00:00');同时有以下两个会话： session Asession Bset session transaction isolation level READ COMMITTED; begin; select * from t where id=2;(2,2,'2018-11-14 00:00:00') update t set a=4 where id=2;select * from t where id=2;(2,4,'2018-11-14 00:00:00') commit; sessionA开启了一个事务，应用的级别是读提交，set session transaction isolation level READ COMMITTED能够将以后会话的隔离级别设置为读提交，第一次查问时记录还没有变动，此时sessionB批改了id=2的这行数据，事务中再次查问失去了最新后果，在一个事务中能读取到其余事务提交的后果这就是读提交。此时会带来不可反复读与幻读的问题。在下面的例子呈现的就是不可反复读，一个事务内的数据前后读取值不统一。至于幻读临时按下不表，让咱们再看一个例子。 ...

binlog日志是什么MySQL的架构能够分为server层与引擎层，引擎层相似于插件像是InnoDB等，binlog就是由server层提供的日志服务。 binlog的格局binlog反对的格局次要有statement，row，mixed三种。 statementstatement中存储的是SQL语句，这样的存储形式更加节俭空间，然而也会带来相应的问题。毛病:因为存储的是SQL语句所以在主从同步时很可能会有不同的执行后果导致主从数据不统一，例如delete时语句抉择的索引不同等。 rowrow格局中存储的是数据自身，正因为如此占用的空间更多，然而可能保证数据的准确性。 mixedmixed模式下，当statement格局中的语句存在导致主从数据不统一的危险时则会主动切换为row。能够通过show warning查看。 对三种日志格局的抉择row格局存储的时数据自身，所以在复原数据时就很不便。statement尽管占用空间少然而个别的生产环境中所采纳的都是主从构造，因而数据的一致性尤其重要。 常用命令查看binlog命令查看以后应用的binlog格局 show global variables like '%binlog_format%';查看第一个binlog文件内容show binlog events;查看指定文件内容show binlog events in 'mysql.000002';查看正在写入的文件show master status\G获取binlogshow binary logs; 设置binlog格局命令设置以后库binlog格局set binlog_format='statement/row/mixed';设置全局binlog格局 set global binlog_format='statement/row/mixed';

FIND_IN_SET()前言及背景最近在开发中遇到了一个需要:依据查问参数查问对应字段中蕴含该参数的数据。数据表中该字段的设计为多个数据用逗号隔开； 比方member_id = '1,2,3',查问参数为1/2/3都能够命中这条数据。也就是说相似于咱们JAVA中List的contains()函数。find_in_set的应用。 咱们设计一个测试表，并插入几条数据察看一下: 建表语句: CREATE TABLE `t_find_test` (  `id` int NOT NULL AUTO_INCREMENT,  `member_id` varchar(255) DEFAULT NULL COMMENT '会员id 多个用,宰割',  `business_type` tinyint(1) DEFAULT NULL COMMENT '业务类型',  `modify_name` varchar(255) DEFAULT NULL COMMENT '编辑人',  `modify_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新工夫',  `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创立工夫',  PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;插入数据 INSERT INTO `demo_test`.`t_find_test` (`id`, `member_id`, `business_type`, `modify_name`, `modify_time`, `create_time`) VALUES (1, '1,2,3', 9, 'root', '2023-03-25 17:22:28', '2023-03-25 17:21:51');INSERT INTO `demo_test`.`t_find_test` (`id`, `member_id`, `business_type`, `modify_name`, `modify_time`, `create_time`) VALUES (2, '3,4,5', 5, 'test', '2023-03-25 17:23:07', '2023-03-25 17:23:07');数据截图: ...

墨天轮数据社区创建至今，始终秉持着“乐知乐享，同心共济”的理念，望为泛滥数据技术畛域的从业者和爱好者提供一个凋谢、业余、和煦的交换空间。咱们深知优良内容的重要性，因而继续联动各行业专家提供优质的内容，帮忙宽广用户更快、更好地把握技术常识并认知行业倒退现状。 为了为大家带来更多元、更有价值的内容，咱们想邀请对行业倒退有本人的独到见解、并热衷于文字创作的敌人成为墨天轮社区“特约作者”。咱们将投入更多的资源来反对您的创作，独特探讨行业前沿和发展趋势，为行业注入更多的生机和创新力。 你须要做围绕指定主题撰写原创深度解读文章。可基于给到的参考观点或自行开展阐述，单篇文章字数要求在2000字以上。文章需具备主题离题、内容残缺、逻辑清晰、剖析透彻等根本要求，可全面开展阐述，也可围绕某个观点深刻开展，可能为读者带来肯定的学习参考价值。 1、内容维度：蕴含行业解读/技术洞见/热点分析/趣味科普等 2、形式：官网将不定期依据行业热议、有价值的内容制订主题，并定向邀请特约作者参加，作者也可随时被动提供选题，经审核通过后开始撰稿。 咱们心愿你能够1、  至多精通一门数据库相干技术（蕴含数据库、中间件、信创、云服务等），并于本人善于畛域内进行内容深耕，乐于分享。 2、  曾撰写过行业热点或深度技术解读文章稿件，文笔佳、内容具备肯定深度。 3、  有公众号、技术博客、社群等读者根底更佳。 你能取得除了分享你的专业知识和教训，你还能够凭实力取得丰富稿酬、专属权利与处分。 1、单篇稿酬 （1）文章经录用正式公布后，作者即可取得根底稿费：300元/篇。同时将依据单篇文章的月度浏览量取得叠加处分，最高可取得1000元。 （2）若文章不合乎稿件要求、或经屡次反馈修改意见后作者仍未调整导致文章未公布，将视稿件最终品质给到肯定数额的费用。 2、荣誉及权利 （1）专属身份标识 所有特约作者均可取得”墨天轮特约作者“荣誉勋章（虚构）。 （2）流量搀扶 所撰文章可取得网站首页举荐、公众号、社群等多渠道曝光，向更宽泛的读者传递您的见解，并与其余作者和读者一起探讨交换。 （3）年度大会参会资格 所有特约作者可收费参加一年一度的数据技术嘉年华流动。 （4）实物处分 依据作者理论实现的邀稿数量可取得额定实物处分。 前期也将视状况举办作者交流会，分享写作心得与教训等。 如何报名？能够通过以下两种形式提交个人资料报名，咱们将在5个工作日内与您获得联系并反馈申请后果。 形式一：点击【墨天轮社区“特约作者”报名表】填写报名表单 形式二：增加墨天轮小助手-小墨（微信号：modb666），备注”特约作者“，将与您具体沟通。 ❗留神：提交作者姓名等个人信息时，若有作品或公众号/技术博客地址，还望同步提交。 如果您是数据技术畛域的从业者、爱好者、观察者，如果您擅于创作、酷爱创作，那么，请退出咱们，成为墨天轮社区“特约作者”！ 欲了解更多可浏览墨天轮数据社区，围绕数据人的学习成长提供一站式的全面服务，打造集新闻资讯、在线问答、流动直播、在线课程、文档阅览、资源下载、常识分享及在线运维为一体的对立平台，继续促成数据畛域的常识流传和技术创新。

1.概念MVCC (Multiversion Concurrency Control)，多版本并发管制。顾名思义，MVCC是通过数据行的多个版本治理实现数据库的并发管制。这项技术使得在InnoDB的事务隔离级别下执行一致性读操作有了保障。换言之，就是为了查问一些正在被另一个事务更新的行，并且能够看到它们被更新之前的值，这样在做查问的时候就不必期待另一个事务开释锁。 MVCC没有正式的规范，在不同的DBMS中MVCC的实现形式可能是不同的，也不是广泛应用的。本文解说InnoDB中MVCC的实现机制（MySQL其它的存储引擎并不反对它）。 2.快照读和以后读MVCC在MySQL InnoDB中的实现次要是为了进步数据库并发性能，用更好的形式去解决读-写抵触，做到即便有读写抵触时，也能做到不加锁，非阻塞并发读，而这个读指的就是快照读，而非以后读。以后读实际上是一种加锁的操作，是乐观锁的实现。而MVCC实质是采纳乐观锁思维的一种形式。 2.1 快照读快照读又叫一致性读，读取的是快照数据。不加锁的简略的SELECT都属于快照读，即不加锁的非阻塞读。比方这样： SELECT * FROM player WHERE ...之所以呈现快照读的状况，是基于进步并发性能的思考，快照读的实现是基于MVCC，它在很多状况下，防止了加锁操作，升高了开销。既然是基于多版本，那么快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。快照读的前提是隔离级别不是串行级别，串行级别下的快照读会进化成以后读。 2.2 以后读以后读读取的是记录的最新版本（最新数据，而不是历史版本的数据)，读取时还要保障其余并发事务不能批改以后记录，会对读取的记录进行加锁。加锁的SELECT，或者对数据进行增删改都会进行以后读。比方： SELECT * FROM student LOCK IN SHARE MODE; #共享锁SELECT * FROM student FOR UPDATE; #排他锁INSERT INTO student values ... #排他锁DELETE FROM student WHERE ... #排他锁UPDATE student SET ... #排他锁3.MVCC实现3.1 暗藏字段对于应用InnoDB存储引擎的表来说，它的聚簇索引记录中都蕴含两个必要的暗藏列。 trx_id：每次一个事务对某条聚簇索引记录进行改变时，都会把该事务的事务id赋值给trx_id暗藏列。 roll_pointer：每次对某条聚簇索引记录进行改变时，都会把旧的版本写入到undo日志中，而后这个暗藏列就相当于一个指针，能够通过它来找到该记录批改前的信息。 3.2 Undo Log版本链举例: student表数据如下 SELECT * FROM student ;/*+----+--------+--------+| id | name | class |+----+--------+--------+| 1 | 张三 | 一班 |+----+--------+--------+1 row in set (0.07 sec)*/假如插入该记录的事务id为8，那么此刻该条记录的示意图如下所示: ...

环境假如峰值QPS为10000，所有的QPS都间接拜访数据库在无慢查问的场景下，均匀查问耗时10ms提供服务的实例一共10台计算过程承上述情况，单个数据库链接可提供的QPS为 1000 / 10 = 100在现实负载平衡的状况下，每台服务实例分担的QPS为 10000 / 10 = 1000则每台实例最多须要1000 / 100 = 10 个链接即可 业务高峰期问题若业务偶发性超出以后零碎所接受的最大范畴，且解决时效性要求高，则能够思考间接拉起新实例，扩充服务与数据库通道，缓解申请压力以集体教训来说，个别单实例的链接数配置为16，即6台实例可大概提供10000QPS，若呈现业务压力问题，应首先分割DBA或通过日志排查是否呈现了慢查问如果是慢查问所致，即便减少实例也只是占用了更多的数据库链接，甚至可能影响到其余利用，须要结合实际状况，确定解决计划，不能自觉扩增实例，引发连锁反应

场景形容业务零碎因须要晋升查问效率，思考应用全文索引进行查问，故建设全文索引全文索引建设后，应用索引查问效率显著晋升，然而过了几天后，查问变得十分迟缓，查问一次数据须要10秒以上应用 alter table xxx engine=innodb 重建表之后，查问效率又复原到刚建设索引时的速度通过 profile 发现，耗时次要耗费在 FULLTEXT initialization 这个步骤 问题剖析通过排查业务零碎性能得悉，应用全文索引的表每天更新量微小，通过查看系统文件能够得悉在重建表之前，FTS_XXXX_DELETED.ibd的容量为268M，这个文件对应INNODB_FT_DELETED表 想在数据库中查看该表，须要开启innodb_ft_aux_table参数 重建表后 查阅官网文档能够理解这些文件&表的作用FULLTEXT IndexINFORMATION_SCHEMA INNODB_FT_DELETED至此大抵起因演绎为 全文索引所在列，每天更新量十分大，而全文索引中的update，理论是 insert + delete 操作，delete的数据会寄存在INNODB_FT_DELETED表中，而全文索引的索引数据不会扭转MySql这样设定的起因是为了防止数据删除后保护索引的微小代价，每当进行查问的时候，会优先过滤INNODB_FT_DELETED中的数据，再进行查问当进行了 OPTIMIZE TABLE 操作后，能力remove这部分数据踩坑总结全文索引并不适宜大数据量更新或删除的场景，可能导致查问效率更慢，且解决时须要DBA手动重建表，生产环境危险大

在春暖花开，万物复苏的 3 月，响应社区小伙伴们的召唤，咱们泽拓科技将举办往年第一次线下社区技术交流活动。 咱们真挚邀请数据库技术社区的同行前来加入，与咱们独特探讨数据管理工作中解决的艰难和播种的心得体会，以及国产分布式数据库 KunlunBase 如何保障在产生节点软硬件故障或者网络故障时，数据不丢不乱，服务继续在线，带着这些问题，咱们走进本次主题沙龙。同时咱们为大家筹备了精美茶歇 & 流动礼品，期待与大家见面交换。 MeetUP 工夫3月25日 14:00—17:00 MeetUP 地点深圳市宝安区万骏经贸大厦17楼 MeetUP 议程 议程详情14：00-14：40 讲师：赵伟（泽拓科技创始人 & CEO） 主题：《KunlunBase 全局死锁检测和解锁》 内容概括：KunlunBase 基于事务锁做分布式事务写入操作的并发管制，因而全局死锁天然就会产生，这与 MySQL Innodb 的本地死锁相似。不过与之不同的是，每个 Kunlun-storage 存储节点无奈检测到这种全局死锁，因而须要在集群层面做全局死锁检测和解除。 本次分享介绍 KunlunBase 中全局死锁产生的机理以及 KunlunBase 如何检测和解除全局死锁。 14：40-15：20 讲师：吴夏（summerxwu）（泽拓科技数据库技术专家） 主题：《KunlunBase 全局一致性复原》 内容概括：KunlunBase 分布式数据库将数据扩散在多个 storage shard 中存储，通过分布式事务来保障每个 shard 中数据的一致性状态。在劫难复原的场景下，同样须要保障复原进去的 KunlunBase 实例其每个 shard 上数据同样维持一致性状态。 本次分享介绍 KunlunBase 全局一致性复原技术的原理及实现。 15：40-16：20 讲师：李雨德（OPPO资深技术专家） 主题：《云原生时代 OPPO 数据库实际》 内容概括：OPPO 自 2018 年开始进行云原生技术的实际，受限于云原生技术的专业性要求高，停顿较缓。自 2019 年下半年开始，更多专业人才的退出，OPPO 云化步子开始放慢，目前简直所有的数据库都运行在自建的 Kubernetes 集群上，总容器数量超百万，数据库实例数万。 本次分享介绍 OPPO 数据库在 Kubernetes 上摸索实际的一些应用运维教训，抛砖引玉，欢送大家探讨发问。 ...

办法一，申明一个内部变量，每行数据为它自增。SET @orderNo = 0;SELECT id, title, @orderNo := @orderNo + 1 orderNo FROM sx_points ORDER BY title; 办法二，应用(@i:=@i+1)SELECT id, title,(@i:=@i+1) orderNo FROM sx_points,(SELECT @i:=0) b　-- 在调用过程须要留神一个事项，就是在from 前面须要为变量归零重置(SELECT @i := 0) b，否则可能会呈现累计成果。SELECT id, title,(@i:=@i+1) orderNo FROM sx_points

本文曾经收录到Github仓库，该仓库蕴含计算机根底、Java根底、多线程、JVM、数据库、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服务、设计模式、架构、校招社招分享等外围知识点，欢送star~ Github地址：https://github.com/Tyson0314/Java-learning 为什么须要加锁如果有多个并发申请存取数据，在数据就可能会产生多个事务同时操作同一行数据。如果并发操作不加管制，不加锁的话，就可能写入了不正确的数据，或者导致读取了不正确的数据，毁坏了数据的一致性。因而须要思考加锁。 表级锁和行级锁有什么区别？MyISAM 仅仅反对表级锁，一锁就锁整张表，这在并发写的状况下性十分差。 InnoDB 不光反对表级锁，还反对行级锁，默认为行级锁。行级锁的粒度更小，仅对相干的记录上锁即可（对一行或者多行记录加锁），所以对于并发写入操作来说， InnoDB 的性能更高。 表级锁和行级锁比照 ： 表级锁： MySQL 中锁定粒度最大的一种锁，是针对非索引字段加的锁，对以后操作的整张表加锁，实现简略，资源耗费也比拟少，加锁快，不会呈现死锁。其锁定粒度最大，触发锁抵触的概率最高，并发度最低，MyISAM 和 InnoDB 引擎都反对表级锁。行级锁： MySQL 中锁定粒度最小的一种锁，是针对索引字段加的锁，只针对以后操作的记录进行加锁。 行级锁能大大减少数据库操作的抵触。其加锁粒度最小，并发度高，但加锁的开销也最大，加锁慢，会呈现死锁。共享锁和排他锁有什么区别？不论是表级锁还是行级锁，都存在共享锁（Share Lock，S 锁）和排他锁（Exclusive Lock，X 锁）这两类： 共享锁（S 锁） ：又称读锁，事务在读取记录的时候获取共享锁，容许多个事务同时获取（锁兼容）。排他锁（X 锁） ：又称写锁/独占锁，事务在批改记录的时候获取排他锁，不容许多个事务同时获取。如果一个记录曾经被加了排他锁，那其余事务不能再对这条事务加任何类型的锁（锁不兼容）。排他锁与任何的锁都不兼容，共享锁仅和共享锁兼容。 S 锁X 锁S 锁不抵触抵触X 锁抵触抵触因为 MVCC 的存在，对于个别的 SELECT 语句，InnoDB 不会加任何锁。不过， 你能够通过以下语句显式加共享锁或排他锁。 # 共享锁SELECT ... LOCK IN SHARE MODE;# 排他锁SELECT ... FOR UPDATE;意向锁有什么作用？如果须要用到表锁的话，如何判断表中的记录没有行锁呢？一行一行遍历必定是不行，性能太差。咱们须要用到一个叫做意向锁的东东来疾速判断是否能够对某个表应用表锁。 意向锁是表级锁，共有两种： 动向共享锁（Intention Shared Lock，IS 锁）：事务有动向对表中的某些加共享锁（S 锁），加共享锁前必须先获得该表的 IS 锁。动向排他锁（Intention Exclusive Lock，IX 锁）：事务有动向对表中的某些记录加排他锁（X 锁），加排他锁之前必须先获得该表的 IX 锁。意向锁是有数据引擎本人保护的，用户无奈手动操作意向锁，在为数据行加共享 / 排他锁之前，InooDB 会先获取该数据行所在在数据表的对应意向锁。 意向锁之间是相互兼容的。 ...

作者：秦福朗 爱可生 DBA 团队成员，负责我的项目日常问题解决及公司平台问题排查。酷爱互联网，会摄影、懂厨艺，不会厨艺的 DBA 不是好司机，didi~ 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 read_only：我都只读了，你还能写进来？ xxx：binlog，我写了哦~ 背景业务运行中，高可用治理平台报错MySQL数据库的从库GTID与主库不统一了，从库踢出高可用集群，开启了read_only与super_read_only的从库怎么会GTID不统一呢？ 发现问题首先查看show master status与show slave status，发现从库的确多了一个GTID，而后拿着GTID去binlog里找问题： 发现从库binlog被写入FLUSH TABLES 语句，产生新的GTID号。 本地测试本地测试发现在开启read_only与super_read_only的实例外面执行 FLUSH TABLES 是能够写入binlog，产生新GTID的。 经业务反馈，这个工夫点ClickHouse在从库同步数据，应该就是ClickHouse在某些状态下工作会对MySQL数据库实例下发FLUSH TABLES语句。 官网的确在一个不起眼的中央说这个语句会写入binlog： Some forms of the FLUSH statement are not logged because they could cause problems if replicated to a replica: FLUSH LOGS and FLUSH TABLES WITH READ LOCK. For a syntax example, see Section 13.7.6.3, “FLUSH Statement”. The FLUSH TABLES, ANALYZE TABLE, OPTIMIZE TABLE, and REPAIR TABLE statements are written to the binary log and thus replicated to replicas. This is not normally a problem because these statements do not modify table data. ...

作者：莫善 某互联网公司高级 DBA。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 1 前言在数据库的运维工作中常常会遇到业务的改表需要，这可能是DBA比拟头疼的需要，其中增加惟一索引可能又是最头疼的需要之一了。 MySQL 5.6 开始反对 Online DDL，增加[惟一]索引尽管不须要重建表，也不阻塞DML，然而大表场景下还是不会间接应用Alter Table进行增加，而是应用第三方工具进行操作，比拟常见的就属pt-osc和gh-ost了。本文就来总结梳理一下增加惟一索引的相干内容。 本文对ONLINE DDL探讨的也是基于MySQL 5.6及当前的版本。2 增加惟一索引的计划简介这部分内容仅介绍ONLINE DDL、pt-osc和gh-ost三种计划，且仅做简略介绍，更加具体的内容请参考官网文档。2.1 ONLINE DDL首先咱们看一下官网对增加索引的介绍： OperationIn PlaceRebuilds TablePermits Concurrent DMLOnly Modifies Metadata Creating or adding a secondary indexYesNoYesNo惟一索引属于非凡的二级索引，将援用官网介绍增加二级索引的内容做例子。能够看到ONLINE DDL采纳In Place算法创立索引，增加索引是不阻塞DML，大抵流程如下： 同步全量数据。遍历主键索引，将对应的字段（多字段）值，写到新索引。同步增量数据。遍历期间将批改记录保留到Row Log，期待主键索引遍历结束后回放Row Log。也不是齐全不阻塞DML，在Prepare和Commit阶段须要获取表的MDL锁，但Execute阶段开始前就曾经开释了MDL锁，所以不会阻塞DML。在没有大查问的状况下，持锁工夫很短，根本能够忽略不计，所以强烈建议改表操作时避免出现大查问。由此可见，表记录大小影响着加索引的耗时。如果是大表，将重大影响从库的同步提早。益处就是能发现反复数据，不会丢数据。 2.2 pt-osc# ./pt-online-schema-change --versionpt-online-schema-change 3.0.13# 创立一张与原表构造统一的新表，而后增加惟一索引。同步全量数据。遍历原表，通过【INSERT IGNORE INTO】将数据拷贝到新表。同步增量数据。通过触发器同步增量数据。触发器映射的SQL语句INSERT 触发器REPLACE INTOUPDATE 触发器DELETE IGNORE + REPLACE INTODELETE 触发器DELETE IGNORE由此可见，这个形式不会校验数据的反复值，遇到反复的数据后，如果是同步全量数据就间接疏忽，如果是同步增量数据就笼罩。 这个工具临时也没有相干辅助性能保障不丢数据或者在丢数据的场景下终止增加惟一索引操作。 pt-osc有个参数【--check-unique-key-change】能够禁止应用该工具增加惟一索引，如果不应用这个参数就示意容许应用pt-osc进行增加索引，当遇到有反复值的场景，好好筹划一下怎么跑路吧。2.3 gh-ost# ./bin/gh-ost --version1.1.5# 创立一张与原表构造统一的新表，而后增加惟一索引。同步全量数据。遍历原表，通过【INSERT IGNORE INTO】将数据拷贝到新表。同步增量数据。通过利用原表DML产生的binlog同步增量数据。binlog语句映射的SQL语句INSERTREPLACE INTOUPDATEUPDATEDELETEDELETE由此可见，这个形式也不会校验数据的反复值，遇到反复的数据后，如果是同步全量数据就间接疏忽，如果是同步增量数据就笼罩。 值得一提的是，这个工具能够通过hook性能进行辅助，以此保障在丢数据的场景下能够间接终止增加惟一索引操作。 hook性能后文会着重介绍。2.4 小总结由上述介绍可知，各计划都有优缺点 计划是否丢数据倡议ONLINE DDL不丢数据适宜小表，及对从库提早没要求的场景pt-osc可能丢数据，无辅助性能能够防止丢数据的场景不适宜增加惟一索引gh-ost可能丢数据，有辅助性能能够防止局部丢数据的场景适宜增加惟一索引3 增加惟一索引的危险依据下面的介绍能够得悉gh-ost是比拟适宜大表加惟一索引，所以这部分就着重介绍一下gh-ost增加惟一索引的相干内容，次要是心愿能帮忙大家避坑。 ...

本文曾经收录到Github仓库，该仓库蕴含计算机根底、Java根底、多线程、JVM、数据库、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服务、设计模式、架构、校招社招分享等外围知识点，欢送star~ Github地址：https://github.com/Tyson0314/Java-learning 事务的四大个性？事务个性ACID：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。 原子性是指事务蕴含的所有操作要么全副胜利，要么全副失败回滚。一致性是指一个事务执行之前和执行之后都必须处于一致性状态。比方a与b账户共有1000块，两人之间转账之后无论胜利还是失败，它们的账户总和还是1000。隔离性。跟隔离级别相干，如read committed，一个事务只能读到曾经提交的批改。持久性是指一个事务一旦被提交了，那么对数据库中的数据的扭转就是永久性的，即使是在数据库系统遇到故障的状况下也不会失落提交事务的操作。数据库的三大范式第一范式1NF 确保数据库表字段的原子性。 比方字段 userInfo: 广东省 10086' ，按照第一范式必须拆分成 userInfo: 广东省 userTel: 10086两个字段。 第二范式2NF 首先要满足第一范式，另外蕴含两局部内容，一是表必须有一个主键；二是非主键列必须齐全依赖于主键，而不能只依赖于主键的一部分。 举个例子。假设选课关系表为student_course(student_no, student_name, age, course_name, grade, credit)，主键为(student_no, course_name)。其中学分齐全依赖于课程名称，姓名年龄齐全依赖学号，不合乎第二范式，会导致数据冗余（学生选n门课，姓名年龄有n条记录）、插入异样（插入一门新课，因为没有学号，无奈保留新课记录）等问题。 应该拆分成三个表：学生：student(stuent_no, student_name, 年龄)；课程：course(course_name, credit)；选课关系：student_course_relation(student_no, course_name, grade)。 第三范式3NF 首先要满足第二范式，另外非主键列必须间接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的状况。 假设学生关系表为Student(student_no, student_name, age, academy_id, academy_telephone)，主键为"学号"，其中学院id依赖于学号，而学院地点和学院电话依赖于学院id，存在传递依赖，不合乎第三范式。 能够把学生关系表分为如下两个表：学生：(student_no, student_name, age, academy_id)；学院：(academy_id, academy_telephone)。 2NF和3NF的区别？ 2NF根据是非主键列是否齐全依赖于主键，还是依赖于主键的一部分。3NF根据是非主键列是间接依赖于主键，还是间接依赖于非主键。事务隔离级别有哪些？先理解下几个概念：脏读、不可反复读、幻读。 脏读是指在一个事务处理过程里读取了另一个未提交的事务中的数据。不可反复读是指在对于数据库中的某行记录，一个事务范畴内屡次查问却返回了不同的数据值，这是因为在查问距离，另一个事务批改了数据并提交了。幻读是当某个事务在读取某个范畴内的记录时，另外一个事务又在该范畴内插入了新的记录。对幻读的正确理解是一个事务内的读取操作的论断不能撑持之后业务的执行。假如事务要新增一条记录，主键为id，在新增之前执行了select，没有发现id为xxx的记录，但插入时呈现主键抵触，这就属于幻读，读取不到记录却发现主键抵触是因为记录实际上曾经被其余的事务插入了，但以后事务不可见。不可反复读和脏读的区别是，脏读是某一事务读取了另一个事务未提交的脏数据，而不可反复读则是读取了前一事务提交的数据。 事务隔离就是为了解决下面提到的脏读、不可反复读、幻读这几个问题。 MySQL数据库为咱们提供的四种隔离级别： Serializable (串行化)：通过强制事务排序，使之不可能互相抵触，从而解决幻读问题。Repeatable read (可反复读)：MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行，解决了不可反复读的问题。Read committed (读已提交)：一个事务只能看见曾经提交事务所做的扭转。可防止脏读的产生。Read uncommitted (读未提交)：所有事务都能够看到其余未提交事务的执行后果。查看隔离级别： select @@transaction_isolation;设置隔离级别： set session transaction isolation level read uncommitted;生产环境数据库个别用的什么隔离级别呢？生产环境大多应用RC。为什么不是RR呢？ ...

一、前言在理论工作中，可能有些刚工作不久的同学会误删了生产或测试环境的数据，这时怎么复原Mysql中误删的数据呢？ 大部分同学都晓得能够通过binlog来复原数据，然而具体如何操作可能还不是很分明，接下来就来介绍下如何通过binlog日志来复原数据 二、筹备工作这里我应用的是windows的Mysql5.7版本 2.1 开启binlog日志首先查看以后mysql是否已开启binlog，命令如下 show variables like 'log_bin';如果未开启，批改配置文件my.ini 或 my.cnf，增加开启binlog配置，如下 [mysqld]log-bin=mysql-binbinlog-format=ROWserver_id=1重启Mysql2.2 创立测试数据并备份创立一个数据库test，并创立table1表，表构造如下 CREATE TABLE `table1` ( `id` int(11) NOT NULL, `name` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;插入5条数据，如下 INSERT INTO `test`.`table1`(`id`, `name`) VALUES (1, '111');INSERT INTO `test`.`table1`(`id`, `name`) VALUES (2, '222');INSERT INTO `test`.`table1`(`id`, `name`) VALUES (3, '333');INSERT INTO `test`.`table1`(`id`, `name`) VALUES (4, '444');INSERT INTO `test`.`table1`(`id`, `name`) VALUES (5, '555');OK，到这里咱们的table1表里曾经有5条测试数据了。 当初应用mysqldump工具对test库进行备份，备份文件名为test.sql，命令如下 mysqldump -uroot -p test --master-data=2 --single-transaction > test.sql2.3 模仿误删操作接下来持续往table1表中增加3条数据，如下 ...

《高性能MySQL》第四版公布后，收到了很多读者的反馈，其中关注最多的是作为一个初学者，应该如何可能较为零碎的学习MySQL，从而应答日常工作或者取得更好的职业倒退。于是和多个业内敌人探讨后，整顿了一些MySQL学习的举荐资源，供初学者参考。 本文分成几局部，包含业界专家的教训、举荐书籍、视频/音频资源、其余资源或者学习形式、MySQL学习沟通群、抽奖赠书等。 业界专家的教训 发问：刚刚入行时，有哪些材料给你了帮忙？ 正式接触 MySQL 是2011年底，过后的公司的数据库版本次要是 5.5 版本和大量 5.1 版本。因为之前学Oracle的教训是查看官网文档，学习MySQL 材料次要是 “官网文档” 和过后的淘宝DBA团队组织的技术大学的技术分享，学习MySQL技术的技术个性和经典案例。 其实就当初而言，MySQL 官网文档仍然是最好的学习材料和教材, 外面十分具体的阐明 MySQL的基础架构，redo，undo，读写逻辑，字段类型，锁，存储引擎，主从复制，MGR ，性能优化等等。把官网文档通读一遍，基本上能超过60-70%左右的DBA，为什么不是更高呢？因为学习技术是为了应用技能。 发问：进一步理解 MySQL/数据库，哪些材料给了你帮忙？ 换个答复的形式，哪些因素帮忙我晋升数据库技能程度？总结起来大略三个方面： 把握基础知识之后，会有 “纸上来得终觉浅，绝知此事要躬行”” 的想法。基于对各种MySQL 技术知识点和 性能个性的了解，搭建单节点,主备模式环境 做各种功能测试，并且将知识点的验证或者剖析过程下来写博客，比方死锁，能将常见的20个死锁常见剖析过程总结下来，置信死锁问题再也难不倒你了。如果是第一条是模拟考，那么实在的业务场景则是实战演练，在海量的业务场景下，层出不穷的业务问题和技术难点驱动 DBA 对 数据库的应用和限度理解的更多。比方：truncat表 如何复原?如果有500g binlog，如何减速 binlog 利用？如何删除3T的大表？秒杀场景下数据库设计和优化？如何排查业务拜访db RT异样?为什么业务写完立刻查问过后查不到?和优良的共事或者优良的人同行，比方有解决不了的纳闷能够征询内核开发。发问：当初回头来看，哪些材料你感觉是最举荐的，别离对于初退学，和深刻学习的人来说？ 对于初学者而言，首要指标是 夯实根底，学好根底/理论知识。 官网文档《高性能MySQL》《MySQL性能调优与架构设计》《MySQL技术底细:InnoDB存储引擎》对于深刻学习的人来说， 独自的数据库学习是没有意义的，必须服务好具体的业务场景能力施展其价值。举荐： 《数据密集型利用零碎设计》《性能之巅》《漫画算法》学习和总结各种业务场景下的数据库架构设计 ，数据库高可用，容灾，强红包，秒杀，直播弹幕等等。 对于初学者，倡议本人手动装置常见的架构，比方最简略的一主一备，作为验证环境。找一些操作案例较多的博客或公众号文章，照着作者的思路执行。 而后再本人设计一些执行案例，先本人推导后果，再执行验证，在验证过程中加深了解或者勘误。 内核学习也能够延用这个办法，在验证过程中构想如果是本人实现这个性能的，会怎么写，而后通过浏览源码了解作者的设计思路。就是看源码要带着问题去看，找只有次要流程，GDB去调试单步执行。 举荐的重要学习材料包含： MySQL 官网文档《MySQL 技术底细：InnoDB 存储引擎》MySQL 周边组件的文档与源码，如percona toolkit、MHA等初学者：丁奇 45 讲、MySQL 官网文档深刻学习：次要还是积攒、排错，云数据库相干还是须要看下技术相干的论文。 举荐书籍与资源MySQL作为以后最风行的关系型数据库，相干的书籍也十分多，这里列举根本举荐如下： 文档是最全面和权威的参考，而其余三本都是，依据豆瓣网友打分进行举荐的。第一本《MySQL是怎么运行的》实用于齐全的初学者，内容由浅到深。第二本《高性能MySQL》则从“优化”为入口，十分零碎介绍了MySQL的架构、优化，是一本十分好的进阶书籍。第三本是《MySQL技术底细 InnoDB存储引擎》，这本书深刻的介绍了MySQL外围组件InnoDB存储引擎，涵盖了数据库的事务原理、调度、物理存储、锁等常识。 另外，其实MySQL畛域还有很多书籍并重各有不同，这里不一一举荐了。 1、《MySQL是怎么运行的》 这本书于2020年出版，是一本比拟新的书籍，整个书籍也是围绕其题目开展《MySQL是怎么运行的：从根儿上了解 MySQL》。这本书最大的特点是，全书有十分清晰的脉络，能够说是由“入门到精通”，书中放弃了肯定的完整性（这个能够去看MySQL文档），而是十分接地气的从零开始，用了很多形象的比喻介绍MySQL数据库的各个概念。 同时，该书籍在每个章节对相干的概念也都进入了十分深刻的探讨，例如，对于索引的介绍，从什么事索引、索引的物理构造开始介绍，而后，开始介绍MySQL的索引在查问、排序等场景的应用，最初，再介绍一些常见的索引优化技巧，包含一般索引、前缀索引、笼罩索引等。 总得来说，这本书是最近几年，面向于初学者十分不错的一本书。 2、《高性能MySQL》 《高性能MySQL》则从“优化”为入口，将MySQL相干的知识点聚合在一起，包含了查问性能优化（SQL优化）、高性能索引、库表构造（Schema）优化等，也包含了服务器配置（硬件和软件）优化、架构优化（包含了复制、只读节点、分片）等，还介绍了局部云服务商的MySQL等内容，是一本非常适合进阶浏览的书籍。 ...

Index Condition PushdownIndex Condition Pushdown，即索引下推(ICP)，是针对应用索引查问策略的优化不开启索引下推时，MySQL通过存储引擎遍历索引，定位数据返回给服务器，再由服务器进行Where条件的判断开启索引下推，且某一部分的WHERE条件能够应用索引中的列来判断时，服务器会将这部分Where条件下推到存储引擎，由存储引擎应用索引判断索引下推能够缩小存储引擎拜访数据表的次数，以及MySQL服务器拜访存储引擎的次数实用条件须要整表扫描的状况，如range, ref, eq_ref, ref_or_null，实用于InnoDB和MyISAM引擎（5.7版本后能够用于分区表查问）对于InnoDB只实用于二级索引，因为InnDB的聚簇索引会将整行数据读到InnDB的缓冲区，这样无奈缩小IO次数，失去了优化的意义援用子查问的条件不能下推调用存储过程的条件不能下推，存储引擎无奈调用位于MySQL服务器中的存储过程触发条件不能下推相干示例此处翻译官网文档，假设有一张人员信息表，并定义联结索引（zipcode，lastname，firstname），此时运行如下查问 SELECT * FROM peopleWHERE zipcode='95054'AND lastname LIKE '%etrunia%'AND address LIKE '%Main Street%';若没有应用索引下推，存储引擎会从索引中匹配zipcode='95054'的行返回至服务器，由服务器来判断lastname LIKE '%etrunia%'和address LIKE '%Main Street%'若应用索引下推，存储引擎会在索引中判断是否合乎lastname LIKE '%etrunia%'和address LIKE '%Main Street%'，仅返回匹配的行至服务器相干配置SET optimizer_switch = 'index_condition_pushdown=off';SET optimizer_switch = 'index_condition_pushdown=on';集体思考能够将索引下推了解为，在遍历索引时携带该索引反对的列查问条件，在索引中实现数据过滤，这样能够缩小查问的整体交互次数，晋升性能

上周三，TDengine 正式公布了基于 TSBS 的时序数据库（Time Series Database，TSDB）性能基准测试报告，该报告采纳 TSBS 平台中针对 DevOps 的场景作为根底数据集，在雷同的 AWS 云环境下对 TDengine 3.0、TimescaleDB 2.6 和 InfluxDB 1.8 进行了比照剖析。为了便于大家更好地浏览和了解，基于报告内容，咱们将从写入、查问及测试过程如何复现等几大维度输入系列文章。本篇文章将为大家解读三大时序数据库在写入性能上的差别点。 在《TSBS 是什么？为什么 TDengine 会抉择它作为性能比照测试平台？》一文中，咱们对测试场景和根本配置曾经进行了具体介绍，本篇文章便不再赘述，还没有理解过的小伙伴能够点击上文链接查看。 五大场景下，TDengine 写入性能实现全面超过不同场景下写入性能的比照（metrics/sec. 数值越大越好） 如上图所示，咱们能够看到在全副五个场景中，TDengine 的写入性能全面超过了 TimescaleDB 和 InfluxDB。在场景二中 TDengine 写入性能最大达到了 TimescaleDB 的 6.74 倍，在差距最小的场景五中，TDengine 也是 TimescaleDB 的 1.52 倍。相比 InfluxDB，TDengine 在场景五中写入性能达到 InfluxDB 的 10.63 倍，在差距最小的场景一中也有 3.01 倍，具体的倍率关系请参见下表。 TDengine 与 InfluxDB、TimescaleDB 的写入性能比照 此外，咱们还留神到，随着设施数规模的减少，所有零碎写入基本上出现降落趋势。TimescaleDB 在小规模数据状况下写入性能不迭 InfluxDB，然而随着设施数量的减少，其写入性能超过了 InfluxDB。 在数据齐全落盘后，咱们又比拟了一下三个零碎在不同场景下的磁盘空间占用状况。 磁盘空间占用（数值越小越优） 能够看到，TimescaleDB 在所有的场景下数据规模均显著地大于 InfluxDB 和 TDengine，并且这种差距随着数据规模减少疾速变大——TimescaleDB 在场景四和场景五中占用磁盘空间是 TDengine 的 25 倍。在后面三个场景中，InfluxDB 落盘后数据文件规模与 TDengine 十分靠近（在场景二中，TDengine 的数据落盘规模比 InfluxDB 大了 1%）,然而在场景四/五两个场景中，InfluxDB 落盘后文件占用的磁盘空间却达到了 TDengine 的 4 倍以上。 ...

一、为什么须要做数据一致性校验在数据的服务生命周期过程中，常常会因为数据迁徙、主从复制、数据集成等起因产生数据流动及复制。在数据复制过程中，因为人为误操作、软件bug或硬件故障等起因，无奈齐全躲避复制数据的准确性。如何无效保障复制数据的一致性变得至关重要。 以后市面上专门用于解决“数据一致性校验”的工具比拟匮乏。很多企业仍然在应用：人工抽检的原始解决方案，数据一致性导致的业务故障频发。 举一个客户遇到CASE，客户是一个电商SAAS服务提供商。如同其余SAAS服务，出于老本优化及大租户稳固隔离的业务诉求，常常会波及用户数据的跨机搬迁。以后，客户并没有对应的数据一致性校验工具，所以，每次迁徙实现，都是人工抽外围表进行数据量的检测。正应了“常在河边走,哪有不湿鞋”的俗语，有一次迁徙一个大商家数据的时候，在没有残缺数据一致性校验的状况下，间接切换商家业务，最终呈现因迁徙数据【订单】不统一，导致的商家业务故障，给大商家造成比拟大的业务影响及品牌影响。 二、一个好的工具应该具备哪些能力同行们血淋淋的教训通知咱们，领有一个好的数据一致性校验工具是必不可少的【关键时刻能救命～】。那么到底咱们须要怎么样的工具呢。小编认为一款校验工具至多应该具备如下六个特质。 1. 能做构造一致性校验利用表存储数据，简直成为大部分数据存储的通用规范。所以表构造是否正确迁徙间接影响迁徙数据的一致性。同时，数据库提供了诸多非表对象，包含视图、存储过程、函数、触发器等。用户个别基于这些对象实现轻量的业务逻辑，所以非表对象的是否胜利迁徙也会间接影响业务的迁徙。由此，小编认为，具备构造一致性的疾速校验是校验工具的根底能力。 2. 欠缺的数据一致性校验除了构造，数据无疑是另一要害的校验内容。数据存储反对丰盛的数据类型，差异化的数据类型默认值、数据格式、字符集以及时区等。因而，是否反对欠缺的数据类型，屏蔽源及指标数据源在数据范畴、数据格式、字符集及时区上的差别，也成为数据校验工具的外围能力。 3. 疾速定义不统一内容数据校验的目标是为了验证数据一致性，并针对不统一数据进行疾速补救。所以，可能定位并提供具体不统一的内容也是数据校验工具的重要特质。 4. 疾速勘误数据的能力当数据校验定位到不统一内容后，是否可能提供数据勘误脚本帮忙用户疾速修复不统一数据也是校验工具必不可少的根底能力。 5. 校验速度要快，“天下文治唯快不破”小编认为校验速度够快也是外围要求。尤其在数据迁徙、数据集成场景，在这种场景下，数据校验会影响业务停机工夫，或者上游数据生产基线【例如，报表生产工夫】，对校验工夫要求较刻薄。 6. 对数据库的性能影响要可控校验工具个别都会高并发读取数据库的数据，此时，数据库同时承当着线上的业务利用。如何无效均衡数据校验速度以及数据库稳定性是校验工具应该解决的重要命题。 三、市面上都有哪些常见的计划1. NineData官网地址：https://www.ninedata.cloud/ NineData 是玖章算术旗下的多云数据管理平台，它是一款即开即用的数据管理SAAS服务。以后 NineData 曾经反对数十种常见同异构数据源（MySQL、SQLServer、CK等）之间的构造比照、数据比照及数据勘误能力。NineData 构造及数据比照作为独立服务，能够灵便反对IDC、云主机自建及云托管数据源的数据一致性校验及疾速修复。从应用体验、产品能力、稳定性及性能等维度综合来看，NineData 是一款综合实例比拟强、比拟难得的校验工具。 2. Percona-toolkitpercona-toolkit是由数据库厂商percona提供的工具集，其中: pt-table-checksum、 pt-table-sync 提供了MySQL主从复制一致性校验及修复的能力。Pt-table-checksum次要通过在MySQL主中运行checksum query，而后利用MySQL主从复制，query流转到slave中，进行check比照。因为，须要借助MySQL主从复制的能力，percona-toolkit只能利用主从复制场景。其劣势在于，以后工具应用比拟宽泛，成熟度比拟高。 3. 云厂商迁徙校验工具配合数据迁徙工具，局部云厂商会提供对应的一致性校验能力。以后云厂商提供的校验能力，个别只反对数据校验，不反对构造校验，且数据勘误能力比拟弱。因为厂商的校验工具是跟迁徙工具配合应用，所以，对于不应用迁徙工具的数据源，以后不能提供数据校验能力。同时，其对云数据库的迁徙反对较好，然而对于云主机上自建数据库以及IDC自建数据库反对不好或不反对。 四、NineData，即开即用的数据一致性校验服务正如后面所述的举荐指数来看，NineData提供的构造比照、数据比照性能的确是综合实力比拟强，也比拟举荐的一款产品。除了根底的全量比照外，NineData还提供了疾速比照、周期性比照及不统一复检等多种比照状态。 疾速比照，相较于全量比照，疾速比照次要用以校验窗口期比拟短的状况。疾速比照会对数据量、数据分布进行校验，同时会随机抽样肯定的比例进行校验。周期性比照， 自定义比照频率及比照形式，NineData会主动周期性调度比照工作进行构造及数据比照。小编了解这个性能应该用于长期数据复制场景的数据比照，例如主从复制、数据容灾、数据多活或数据仓库实时集成等场景。不统一复检， 即针对上一次比照后果中不统一数据进行从新复检。这个性能次要利用于数据勘误、主从复制【主从提早】场景下，进行疾速的复检。接下来，带大家感触下这个产品的应用体验。 1. 配置比照工作整个工作配置过程很简略，次要分为三个步骤： 抉择数据源，即配置比照的源实例及指标实例；抉择比照对象，即配置须要比照的对象，比照对象能够抉择库、表｜非表、列；配置映射关系及过滤条件，即配置比照表的映射关系；或者通过配置SQL过滤条件，能够只对要害数据进行比照。 2. 比照后果NineData会提供欠缺的比照后果，其会定位不统一内容。针对不统一内容，提供疾速勘误脚本。 五、最初数据作为企业的外围资产，数据的准确性对于业务可靠性及企业品牌口碑。为此，还是举荐大家在线上主从环境、数据迁徙、数据复制等场景中，配套应用牢靠的数据校验工具。平台工具 NineData 以其欠缺的校验能力、产品体验、校验速度、稳定性及数据源环境的宽泛适配性成为了市面上比拟出彩的校验工具，举荐大家应用。

对于 KunlunBaseKunlunBase 是业内惟一同时反对 MySQL 和 PostgreSQL 数据库连贯协定和 SQL 语法的分布式 HTAP 数据库系统，聚焦于解决各行业的应用软件、Web 零碎和 SaaS 云服务在存储、治理和利用海量关系型数据中存在的各种问题，并致力于提供撑持高并发高负载的事务处理和数据读写服务，进而助力应用软件开发商、服务商，一起为最终用户最大限度地发明价值。此次 KunlunBase 1.1版本公布丰盛了 DBA 罕用性能，欠缺了 MySQL 兼容性，并且实现了较大的 OLAP 剖析查问性能晋升。对于咱们泽拓科技（深圳）有限责任公司致力于研发行业当先的分布式数据库管理系统，解决各行业在海量数据存储、治理和利用方面面临的技术难题。公司由出名投资机构投资，开创团队次要来自 Oracle、腾讯、阿里、华为等巨头的数据库研发团队，人均有十多年数据库系统内核研发教训和技能。团队具备丰盛的数据库系统利用开发和运维治理教训，深刻理解一线数据库系统用户的需要和痛点。团队敏锐地把握住信创和新基建的国家策略需要，以及各行业宽泛的海量数据存储、治理和利用需要，心愿为国内外各行业用户提供优质的产品和技术服务。同时欢送大家微信扫一扫↓二维码退出技术社群，独特探讨更多问题及主题。咱们会在直播完结时，咱们会以抽奖模式在社群送出三份精美礼品。END

原始博文链接 前言本篇译自Mysql官网参考手册（5.7）的锁和事务章节，集体认为翻译价值还能够，因而翻译如下。浏览须要有一些InnoDB的基本概念，如有须要能够先浏览后面的章节。翻译程度无限，有不当之处还请指出。 InnoDB Locking and Transaction Model要实现大规模、高并发或高牢靠的数据库利用，或者要从不同的数据库系统移植大量的代码，又或者是要优化MySQL的性能，理解InnoDB的锁和事务的模型是十分重要的。 本章节探讨了几个您应该须要相熟的、与InnoDB锁和InnoDB事务模型相干的几个话题。 14.7.1 “InnoDB锁” 形容了InnoDB所应用的各种锁的类型。14.7.2 “InnoDB事务模型” 形容了各个事务隔离级别的性质以及各个级别所应用的锁策略。同时探讨了autocommit、一致性非锁定读取（consistent non-locking reads）和锁定读取（Locking reads）的利用。14.7.3 “InnoDB中由不同的SQL语句设置的锁” 探讨了InnoDB中各种不同语句设置的锁的类型。14.7.4 “幻读行” 形容了InnoDB如何采纳next-key锁来防止幻读。14.7.5 “InnoDB中的死锁” 提供一个死锁示例，探讨了死锁的发现和回滚，同时提供了一些在InnoDB中缩小和解决死锁的tips。InnoDB Locking本章节形容了InnoDB所应用的锁的类型。 Shared and Exclusive Locks（共享锁和排他锁）Intention Locks（意向锁）Record Locks（单个记录锁）Gap Locks（间隙锁）Next-Key LocksInsert Intention Locks（插入意向锁）AUTO-INC LocksPredicate Locks for Spatial IndexesShared and Exclusive LocksInnoDB实现了规范行级锁，有两种类型，别离是共享锁（S锁）和排他锁（X锁）。 一把共享（S）锁容许持有锁的事务读取一行。一把排他（X）锁容许持有锁的事务更新或删除一行。如果事务T1在行r上持有一把共享锁，那么来自其余事务T2的对行r的获锁申请将以如下形式解决： 对获取行r共享锁的申请能够被立刻通过。这样的后果就是T1和T2在行r上同时各自持有一把共享锁。对获取行r排他锁的申请无奈被立刻通过。如果事务T1在行r上持有一把排他锁，来自其余事务T2对行r的获取任意一种锁申请都无奈被立刻通过。事务T2必须期待事务T1开释它在行r上的锁。 Intention LocksInnoDB反对多颗粒度的锁定，容许行锁和表锁共存。举例来说，相似LOCK TABLES ... WRITE的语句将在指定的表上获取一把排他锁（X锁）。为了可能在多颗粒度上实现锁定，InnoDB应用意向锁。意向锁是表级锁，用于申明事务稍后须要对表中的一行获取的哪种类型的锁（共享或排他）。有两种意向锁： 一把动向共享（IS）锁表明一个事务试图对表中的某行设置共享锁。一把动向排他（IX）锁表明一个事务试图对表中的某行设置排他锁。例如，SELECT ... LOCK IN SHARE MODE设置了一把IS锁，SELECT ... FOR UPDATE设置了一把IX锁。 意向锁协定如下： 在事务可能获取表中某一行的共享锁之前，它必须在相应的表上获取一把IS锁或者更强的锁。在事务可能获取表中某一行的排他锁之前，它必须在相应的表上获取一把IX锁。表级锁类型的兼容性总结如下表： XIXSISX不兼容不兼容不兼容不兼容IX不兼容兼容不兼容兼容S不兼容不兼容兼容兼容IS不兼容兼容兼容兼容如果一个事务申请的锁与现有的锁兼容，那么申请将被容许，如果抵触则将被回绝。事务将期待直到曾经存在的不兼容的锁被开释。如果一个获锁申请与已存在的锁抵触，且可能会引发死锁，将会呈现一个异样。 意向锁不会阻塞除了全表申请（例如LOCK TABLES ... WRITE）之外的操作。意向锁次要的目标是表明某个事务正在或正将要锁定表中的某一行。 一个意向锁的事务数据以相似如下的模式呈现在显示InnoDB状态命令（SHOW ENGINE engine_name {STATUS | MUTEX}）和InnoDB监控的输入中： ...

GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。GreatSQL是MySQL的国产分支版本，应用上与MySQL统一。作者： bruce文章起源：GreatSQL社区原创什么是events_statements_current表在MySQL中，PFS下有一张内存表: events_statements_current，看到这个名称"xxx_current"，小白如我可能会认为这张表中的数据就是以后零碎的沉闷(active)语句。该表的形容如下(有局部省略): mysql> desc events_statements_current;+-------------------------+------------------------------------------------+------+-----+---------+-------+| Field | Type | Null | Key | Default | Extra |+-------------------------+------------------------------------------------+------+-----+---------+-------+| THREAD_ID | bigint unsigned | NO | PRI | NULL | || EVENT_ID | bigint unsigned | NO | PRI | NULL | || END_EVENT_ID | bigint unsigned | YES | | NULL | || EVENT_NAME | varchar(128) | NO | | NULL | || SOURCE | varchar(64) | YES | | NULL | || TIMER_START | bigint unsigned | YES | | NULL | || TIMER_END | bigint unsigned | YES | | NULL | || TIMER_WAIT | bigint unsigned | YES | | NULL | || LOCK_TIME | bigint unsigned | NO | | NULL | || SQL_TEXT | longtext | YES | | NULL | || DIGEST | varchar(64) | YES | | NULL | || DIGEST_TEXT | longtext | YES | | NULL | || CURRENT_SCHEMA | varchar(64) | YES | | NULL | |...| MYSQL_ERRNO | int | YES | | NULL | || RETURNED_SQLSTATE | varchar(5) | YES | | NULL | || MESSAGE_TEXT | varchar(128) | YES | | NULL | |...+-------------------------+------------------------------------------------+------+-----+---------+-------+44 rows in set (0.01 sec)间接应用以后语句表的问题间接做个小试验，终端1： ...

启动选项和配置文件启动选项长模式#启动服务端时，禁止客户端应用TCP/IP网络进行通信mysqld --skip-networking或mysql --skip_networking或mysqld --skip-networking#启动客户端时，设置默认存储引擎mysqld --default-storage-engine=MyISAM短模式#客户端连贯mysql服务器mysql -h[主机] -P[端口] -u[用户] -p[明码]配置文件配置文件门路#windows下：[MySQL装置门路]\my.ini defaults-extra-file#linux下：/etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf defaults-extra-file配置文件内容配置文件中都是分组配置的，以下时程序和配置分组的对应关系 mysql：[mysql]、[client] mysqld：[mysqld]、[server] mysqld_safe：[mysqld]、[server]、[mysql_safe] mysqld.server：[mysqld]、[server]、[mysqld.server] client：[client]、[mysql] mysqldump：[client]、[mysqldump] mysqladmin：[client]、[mysqladmin] 配置文件优先级优先级排序,低优先级会最初读取，所以低优先级文件会笼罩高优先级的文件内容/etc/my.cnf > /etc/mysql/my.cnf > /usr/etc/my.cnf > ~/.my.cnf 如果同一个配置吹呈现在不同组之中，上面的配置笼罩下面的配置如果设置了--defaults-file，那么defaults-file的优先级最高，就算没有对应的门路，也不会去其余门路找配置文件，会间接抛出异样。命令行优先级大于配置文件零碎变量查看零碎变量mysql> show variables like 'max_%';+----------------------------+----------------------+| Variable_name | Value |+----------------------------+----------------------+| max_allowed_packet | 67108864 || max_binlog_cache_size | 18446744073709547520 || max_binlog_size | 1073741824 || max_binlog_stmt_cache_size | 18446744073709547520 || max_connect_errors | 100 || max_connections | 151 || max_delayed_threads | 20 || max_digest_length | 1024 || max_error_count | 1024 || max_execution_time | 0 || max_heap_table_size | 16777216 || max_insert_delayed_threads | 20 || max_join_size | 18446744073709551615 || max_length_for_sort_data | 4096 || max_points_in_geometry | 65536 || max_prepared_stmt_count | 16382 || max_relay_log_size | 0 || max_seeks_for_key | 18446744073709551615 || max_sort_length | 1024 || max_sp_recursion_depth | 0 || max_user_connections | 0 || max_write_lock_count | 18446744073709551615 |+----------------------------+----------------------+22 rows in set (0.00 sec)设置零碎变量通过启动选项设置通过命令行增加启动参数设置零碎变量 ...

呈现的场景业务上面临高并发解决，因为数据可能频繁进行写入与更新，因而应用的是insert on duplicate key update语句，在高并发场景下，导致死锁报错起因剖析死锁的实质是多个事务期待对方所持有的资源开释，且不会开释本身所持有的资源，导致事务之间循环期待通过查阅文档以及数据库剖析，在on duplicate key时，会在前一个索引值到以后值加临界锁，而多个事务相互期待对方的锁开释，是造成死锁的起因lock_mode X locks gap before rec insert intention waiting举例说明在以下构造中，value字段存在惟一索引事务A // step1 执行到此处时，因为value=3已存在，此时会对(1，3]加临键锁insert into table(value) values(3) on duplicate key update value = 7;// step3 执行到此处时，因为3~5的区间已被锁住，须要期待事务2开释临键锁insert into table(value) values(4) on duplicate key update value = 7;事务B // step2 执行到此处时，因为value=5已存在，此时会对(3，5]加临键锁insert into table(value) values(5) on duplicate key update value = 8;// step4 执行到此处时，因为1~3的区间已被锁住，须要期待事务1开释临键锁insert into table(value) values(2) on duplicate key update value = 8;当执行程序依照step1~step4执行时，便会造成死锁 相干陈说性知识 & 官网文档 & 集体了解InnoDB LockingMySql的锁

utf8_general_ci不辨别大小写，若业务需要区别大小写时，不可应用此字符集 联结惟一索引任意一列的值为NULL时，即便其余的字段雷同，也不会引起惟一索引抵触 Data truncated for column 'target_id' at row 1字段属性设置不正确，或插入 or 更新参数超长 now() 和 sysdate()以下两个语句能够了解now是一个常量，sysdate是一个变量now失去一个动态值，所以在查问中，优化器能辨认出对应的数据区间，而sysdate的形式在优化器中没法间接辨认到对应的值，所以每次调用都会从新获取 取模select MOD(234, 10)

MySQL 是一种风行的关系型数据库管理系统，用于存储和治理结构化数据。MySQL 数据源是指通过连贯 MySQL 数据库获取数据的数据源。MySQL 数据源可用于各种应用程序和工具，如 Web 应用程序、报告工具和 ETL 工具，以读取、写入和转换 MySQL 数据库中的数据。MySQL 数据源通常应用规范的 JDBC 接口进行拜访。 目前码匠曾经实现了与 MySQL 数据源的连贯，反对书写 SQL 语句，也反对通过图形化界面对数据进行增、删、改、查， 同时还反对将数据绑定至各种组件，并通过简略的代码实现数据的可视化和计算等操作，能让您疾速、高效地搭建利用和外部零碎。 在码匠中集成 MySQL步骤一：新建数据源连贯，抉择 MySQL 数据源，并依据提醒填写相应配置。 步骤二：新建 MySQL 查问，码匠中反对 SQL 模式和 GUI 模式，让您可能更加灵便便捷地操作数据。 步骤三：书写/抉择查询方法并展现/应用查问后果。 在码匠中应用 MySQL操作数据：在码匠中能够对 MySQL 数据进行增、删、改、查的操作，在 SQL 模式下能够自定义查问语句，在 GUI 模式下则有以下操作，即便对 SQL 语法不相熟也能疾速上手： 插入插入，抵触后更新更新删除批量插入批量更新应用数据：这两种模式下，用户能够在左侧的查问面板内查看数据结构，并通过{{yourQueryName.data}}来援用查问后果：对于码匠码匠低代码平台是一款实用于企业级利用开发的全栈低代码开发平台，旨在通过极简化开发流程，实现疾速构建利用的目标。平台采纳可视化拖拽式开发、主动生成代码、疾速迭代等低代码开发理念，使得开发者能够通过简略的操作，疾速搭建出功能丰富的利用，同时保障了利用的可扩展性和可维护性。码匠低代码平台反对多种开发语言和多种云厂商，开发者能够抉择最适宜本人团队的语言和云服务，同时平台也提供了一系列的性能组件和集成插件，开发者能够依据本人的需要进行抉择和定制。通过应用码匠低代码平台，企业能够疾速响应市场需求，升高开发成本和危险，进步开发效率和品质。 仍有疑难：https://majiang.co/docs/database/mysql立刻试用：https://majiang.co/

pdf下载：明码7281专栏目录首页：【专栏必读】（考研复试）数据库系统概论第五版（王珊）专栏学习笔记目录导航及课后习题答案详解 留神：此局部内容和软件工程的知识点重合较多，更多请点击【收费分享】软件工程外围知识点 本章较扩散，各节导航如下 （数据库系统概论|王珊）第七章数据库设计-第二节：需要剖析（数据库系统概论|王珊）第七章数据库设计-第三节：概念结构设计（数据库系统概论|王珊）第七章数据库设计-第四节：逻辑结构设计（数据库系统概论|王珊）第七章数据库设计-第五、六节：物理结构设计和数据库的施行和保护一：数据库设计定义数据库设计(database design)：数据库设计是指对于一个给定的应用环境，结构(设计)优化的数据库逻辑模式和物理构造，并据此建设数据库及其利用零碎，使之可能无效地存储和治理数据，满足各种用户的利用需要，包含信息管理要求和数据操作要求。数据库设计的指标是为用户和各种利用零碎提供一个信息基础设施和高效的运行环境 信息管理要求：数据库中应该存储和治理哪些数据对象数据操作要求：对数据对象须要进行哪些操作二：数据库建设及特点数据库建设：是指数据库利用零碎从设计、施行到运行与保护的全过程（能够比照软件生命周期） （1）数据库建设基本规律特点之一：三分技术、七分治理、十二分根底数据 技术：技术很重要，也是最容易实现的，因为技术在肯定期间内是很稳固的治理：治理相比技术更为重要，这对数据库设计有间接影响数据：根底数据的位置和作用是认为最容易疏忽的，数据便是数据库这幢大楼的一砖一瓦（2）构造（数据）设计和行为（解决）设计相结合特点之二：设计中要把数据库结构设计和对数据的解决设计亲密联合起来 必须强调设计过程中数据库设计和利用零碎设计的亲密联合，并将其作为数据库设计的重要特点数据库设计中肯定要把构造个性和行为个性联合起来三：数据库设计办法次要有： 新奥尔良办法：将数据库设计分为若干阶段和步骤基于 E-R 模型的设计办法：概念设计阶段宽泛采纳基于 3NF 的设计办法：逻辑阶段可采纳的无效办法ODL（Object Definition Language）办法：面向对象的数据库设计办法计算机辅助设计：ORACLE Designer 2000、SYBASE PowerDesigner四：数据库设计根本步骤（1）6个阶段数据库设计分为如下6个阶段： 需要剖析概念结构设计逻辑结构设计物理结构设计数据库施行数据库运行和保护 需要剖析和概念结构设计能够独立于任何数据库管理系统进行逻辑结构设计和物理结构设计与选用的数据库管理系统密切相关（2）具体形容需要分析阶段：进行数据库设计首先必须精确理解与剖析用户需要(包含数据与解决)。需要剖析是整个设计过程的根底，也是最艰难和最消耗工夫的一步 概念构造设计阶段：概念结构设计是整个数据库设计的要害，它通过对用户需要进行综合、演绎与形象，造成一个独立于具体数据库管理系统的概念模型 逻辑构造设计阶段：逻辑结构设计是将概念构造转换为某个数据库管理系统所反对的数据模型，并对其进行优化 物理构造设计阶段：物理结构设计是为逻辑数据模型选取一个最适宜应用环境的物理构造(包含存储构造和存取方法) 数据库施行阶段：在数据库施行阶段，设计人员使用数据库管理系统提供的数据库语言及其宿主语言，依据逻辑设计和物理设计的后果建设数据库，编写与调试应用程序，组织数据入库，并进行试运行 数据库运行和维护阶段：数据库利用零碎通过试运行后即可投入正式运行。在数据库系统运行过程中必须一直地对其进行评估、调整与批改 在此阶段，应该把数据库的设计和对数据库中数据处理的设计紧密结合起来（3）所应用的工具每个阶段都要用到各种工具，各种图，这一点在软件工程中有具体介绍 五：数据库设计过程中的各级模式数据库设计的不同阶段会造成数据库的各级模式 需要分析阶段：综合各个用户的利用需要概念构造设计阶段：造成概念模式（E-R图）逻辑构造设计阶段：将E-R图转化为具体的数据库产品所反对的数据模型，比方关系模型造成逻辑模式，而后依据用户解决的要求、安全性的思考，在根本表的根底上再建设必要的视图，造成数据的外模式物理构造设计阶段：造成内模式

yearning 是一款 sql 审核平台，界面和性能都还不错，举荐 2.3.5 版本。 docker-composer.yml version: '3'services: yearning: image: chaiyd/yearning:v2.3.5 container_name: yearning environment: MYSQL_USER: yearning MYSQL_PASSWORD: ukC2ZkcG_ZTeb MYSQL_ADDR: yearning-mysql MYSQL_DB: yearning SECRET_KEY: dbcjqheupqjsuwsm IS_DOCKER: is_docker ports: - 8889:8000 # 首次应用请先初始化 command: /bin/bash -c "./Yearning install && ./Yearning run" links: - yearning-mysql depends_on: - yearning-mysql restart: always yearning-mysql: image: mysql:5.7 container_name: yearning-mysql environment: MYSQL_ROOT_PASSWORD: ukC2ZkcG_ZTeb MYSQL_DATABASE: yearning MYSQL_USER: yearning MYSQL_PASSWORD: ukC2ZkcG_ZTeb command: - --character-set-server=utf8mb4 - --collation-server=utf8mb4_general_ci volumes: - ./data/mysql:/var/lib/mysql# 默认账号：admin，默认明码：Yearning_adminyearning 依赖 mysql，这里创立一个 mysql 给 yearning 独自应用，如果你有本地或其余容器 mysql 也能够批改 yearning 的 MYSQL_* 配置链接 ...

【前言】作为中国的 “Fivetran/Airbyte”, Tapdata 是一个以低提早数据挪动为外围劣势构建的古代数据平台，内置 60+ 数据连接器，领有稳固的实时采集和传输能力、秒级响应的数据实时计算能力、稳固易用的数据实时服务能力，以及低代码可视化操作等。典型用例包含数据库到数据库的复制、将数据引入数据仓库或数据湖，以及通用 ETL 解决等。援用随着 Tapdata Connector 的一直增长，咱们最新推出《Tapdata Connector 实用指南》系列内容，以文字解析辅以视频演示，还原技术实现细节，模仿理论技术及利用场景需要，提供能够“珍藏跟练”的实用专栏。本期实用指南以 SQL Server → BigQuery 为例，演示数据入仓场景下，如何将数据实时同步到 BigQuery。数据规模仍在继续扩充的明天，为了从中取得可操作的洞察力，进一步实现数据分析策略的现代化转型，越来越多的企业开始把眼光投注到 BigQuery 之上，心愿通过 BigQuery 来运行大规模要害工作利用，从而达到优化经营、改善客户体验并升高总体领有老本的目标。 作为自带 ETL 的实时数据平台，咱们也看到了很多从传统外部数据仓库向 BigQuery 的数据迁徙需要。 一、BigQuery 的云数仓劣势作为一款由 Google Cloud 提供的云原生企业级数据仓库，BigQuery 借助 Google 基础架构的弱小解决能力，能够实现海量数据超疾速 SQL 查问，以及对 PB 级数据进行平安并可扩大的剖析。同时也因其人造具备的无服务器架构、低成本等个性，备受数据分析师和数据工程师的青眼，在数据存储和解决上体现出更杰出的便利性。 BigQuery 在企业中通常用于存储来自多个零碎的历史与最新数据，作为整体数据集成策略的一部分，也常作为既有数据库的补充存在。其劣势在于： 在不影响线上业务的状况下进行疾速剖析：BigQuery 专为疾速高效的剖析而设计, 通过在 BigQuery 中创立数据的正本, 能够针对该正本执行简单的剖析查问, 而不会影响线上业务。数据集中存储, 进步剖析效率：对于分析师而言，应用多个平台耗时费劲，如果将来自多个零碎的数据组合到一个集中式数据仓库中，能够无效缩小这些老本。安全性保障：能够管制对加密我的项目或数据集的拜访，并施行身份拜访治理。可扩展性：反对依据公司的规模、性能和老本要求定制数据存储。敌对兼容：作为 Google Cloud 的一部分，它与 Google 系产品更兼容，对相干用户更敌对。为了实现上述劣势，咱们须要首先实现数据向 BigQuery 的同步。 二、SQLServer → BigQuery 的数据入仓工作点击查看残缺演示（*本演示视频版本为 Tapdata 本地部署版本） 版本指路： 点击登录 Tapdata Cloud申请试用 Tapdata 本地部署版 ...

前言说起三大范式，我脑海里第一反馈就是这几句话： 当实体 A 与实体 B 之间的关系是一对一时，会把实体 A 的主键作为 实体 B 的外键。当然关系是一对一时，反过来也能够，即把 实体B 的主键当做实体 A 的外键；当实体 A 与实体 B 之间的关系是一对多时，会把 A 的主键当做实体 B 的外键；当实体 A 与实体 B 之间的关系是多对多时，通常会思考建一张新表来保留这两个实体之间的关系。然而有时候实体与实体之间的关系并不是非常容易的看进去，所以靠这些了解并不足以设计出符合规范的表构造。在读了相应的材料后，发现自己对三大范式的了解是十分肤浅的、浮浅的，所以就写了这篇博客来记录本人对三大范式重新认识的过程。 什么是范式（NF）？在了解三大范式之前，须要明确什么是范式（NF）？ 依照教材中的定义，范式是： 合乎某一种级别的关系模式的汇合，示意一个关系外部各属性之间的分割的合理化水平。能够了解为：一张数据表的表构造所合乎的某种设计标准的级别。 三大范式定义以下是三大范式的定义： 第一范式：合乎 1NF 的关系中的每个属性都不可再分。第二范式：2NF 在 1NF 的根底之上，打消了非主属性对于码的局部函数依赖。第三范式：3NF 在 2NF 的根底之上，打消了非主属性对于码的传递函数依赖。说实话，我一开始看到第二范式和第三范式的定义时，感到十分蛊惑： 什么是非主属性？什么是码？范式的定义为什么和函数无关？然而在了解了这些概念之后，才意识到意识到这几条定义是如此的准确。 在了解“非主属性”和“码”之前，须要先彻底搞明确什么是“函数依赖”，因为“非主属性”和“码”的概念是建设在“函数依赖”的概念之上的。 什么是函数依赖？若在一张表中，在属性（或属性组）X的值确定的状况下，必然能确定属性Y的值，那么就能够说Y函数依赖于X，写作 X → Y。光看概念可能不太好了解什么是函数依赖，还是须要通过一个例子来了解。 学生表如下： 学号姓名性别年龄1420233906罗辑男211420233907云天明男221420233908章北海男231420233909程心女20这张学生表有四个属性：学号、姓名、性别、年龄。咱们晓得一个学号对应一个学生，如果你的班主任问你 1420233906 是谁，你就能够通知他 1420233906 是罗辑，除此之外，你还能通知你的班主任，罗辑是男的，21 岁。 换句话说： 在学号确定的状况下，就必然能确定姓名的值，即姓名函数依赖于学号，写作姓名 → 学号；在学号确定的状况下，就必然能确定性别的值，即性别函数依赖于学号，写作性别 → 学号；在学号确定的状况下，就必然能确定年龄的值，即年龄函数依赖于学号，写作年龄 → 学号；还能在学生表中找到其余的函数依赖关系吗？答案是否定的。 如果学生表中，只有这四条记录，如同是能够通过姓名来确定学号、性别、年龄的值。然而在大多数班中必定存在同名同姓的学生，例如张伟： 学号姓名性别年龄1420233906罗辑男211420233907云天明男221420233908章北海男231420233909程心女201420233909张伟男211420233910张伟男22尽管同叫张伟，但却是两个不同的学生。当数学老师叫张伟时，两个张伟可能同时站起来。即在姓名确定的状况下，无奈确定学号的值，无奈确定性别的值也无奈确定年龄的值。同理： 在性别确认的状况下，无奈确定其余任意一个属性的值；在年龄确认的状况下，无奈确定其余任意一个属性的值；再来看一个更难的例子： 学号姓名系名系主任课名分数1420233906罗辑机电工程系艾AA高等数学991420233907罗辑机电工程系艾AA大学英语981420233908罗辑机电工程系艾AA大学物理971420233909程心经济系维德高等数学881420233909程心经济系维德毛概881420233910程心经济系维德大学英语88在这张表中存在哪些函数依赖关系呢？ 学号 → 姓名学号 → 系名（一个学生只属于一个系）系名 → 系主任（一个系只有一个系主任）学号 → 系主任（一个学生只属于一个系、一个系只有一个系主任，即在学号确定的状况下，必然能够确认该学生所属系的系主任）（学号，课名） → 分数然而以下函数依赖关系则不成立： ...

pdf下载：明码7281专栏目录首页：【专栏必读】（考研复试）数据库系统概论第五版（王珊）专栏学习笔记目录导航及课后习题答案详解 在（数据库系统概论|王珊）第二章关系数据库-第二节、第三节：关系操作和关系完整性这一节中对数据库的三大完整性已有介绍，而本章的内容就是如何在SQL语言中实现这些完整性规定 一：数据库完整性概述（1）数据库完整性的基本概念数据库完整性：数据库的完整性是指数据的正确性和相容性 正确性：数据是合乎事实世界语义、反映以后理论情况的。例如性别只能是男或女相容性：是指数据库同一对象在不同关系表中的数据是合乎逻辑的。比如说年龄个别都在1-100岁，当然也有超过一百岁的，反正没有两百岁，三百岁成仙的人类（2）数据库完整性和安全性的区别完整性：是为了避免数据库中存在不合乎语义的数据，也就是避免数据库中存在不正确的数据。因而，完整性检查和管制的防备对象是不合语义的、不正确的数据，避免它们进入数据库 安全性：是爱护数据库避免歹意毁坏和非法存取。因而，安全性管制的防备对象是非法用户和非法操作，避免他们对数据库数据的非法存取 （3）为保护完整性DBMS必须要实现的性能1.提供定义完整性约束条件的机制 完整性约束条件：是数据库中数据必须满足的语义条件规定SQL规范应用了一系列概念来形容完整性，包含关系模型的实体完整性、参照完整性和用户定义完整性2.提供完整性检查的办法 完整性检查：检查数据是否满足完整性规定的机制3.进行守约解决 二：实体完整性实体完整性：若属性A是根本关系$R$的主属性，则属性A不能取空值 （1）定义实体完整性定义方法：关系模型的实体完整性在CREATE TABLE中用PRIMARY KEY定义。留神 如果主码仅有一个属性（单属性）：能够定义为列级约束条件也能够定义为表级约束条件如果主码有多个属性：留神仅能定义为表级约束条件演示： 如下有几个典型的例子 将Student表中的Sno属性定义为码(1)在列级定义主码CREATE TABLE Student( Sno CHAR(9) PRIMARY KEY， Sname CHAR(20) NOT NULL， Ssex CHAR(2) ， Sage SMALLINT， Sdept CHAR(20));(2)在表级定义主码CREATE TABLE Student( Sno CHAR(9)， Sname CHAR(20) NOT NULL， Ssex CHAR(2) ， Sage SMALLINT， Sdept CHAR(20)， PRIMARY KEY (Sno)); (3)将SC表中的Sno，Cno属性组定义为码CREATE TABLE SC( Sno CHAR(9) NOT NULL， Cno CHAR(4) NOT NULL， Grade SMALLINT， PRIMARY KEY (Sno，Cno) /*只能在表级定义主码*/); （2）实体完整性检查和守约解决每当插入或对主码列进行更新操作时，DBMS依照实体完整性规定主动进行查看，包含 查看主码值是否惟一，如果不惟一则回绝插入或批改查看主码的各个属性是否为空，只有有一个为空就回绝插入或批改其中查看记录中主码值是否惟一有两种办法 ...

表构造CREATE TABLE `users` ( `id` int NOT NULL AUTO_INCREMENT, `profile` json NOT NULL COMMENT "材料 object", `favor` json NOT NULL "珍藏 array", PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;插入数据能够应用 JSON_OBJECT / JSON_ARRAY 来组装 JSON 数据 INSERT INTO `users`(`profile`, `favor`) VALUES(JSON_OBJECT("name", "big", "age", 18, "hobby", JSON_ARRAY("football", "game")), JSON_ARRAY(1, 2)),(JSON_OBJECT("name", "cat", "age", 20, "hobby", JSON_ARRAY("basketball", "game")), JSON_ARRAY(2, 3)),(JSON_OBJECT("name", "sqrt", "age", 24, "hobby", JSON_ARRAY("game")), JSON_ARRAY(2));查问数据key 应用 $.key1.key2 的形式读取arr 应用 $[index] 的形式读取{"key1": {"key2": [1, 2, 3]}} 读取 $.key1.key2[0]JSON_CONTAINS 即能够做等值查找，也能够对数组做元素蕴含查找 ...

日志服务数据入湖日志服务（SLS）是云原生观测剖析平台，为Log/Metric/Trace等数据提供大规模、低成本、实时平台化服务。一站式提供数据采集、加工、剖析、告警可视化与投递性能。阿里云提供了企业级的数据湖解决方案，存储层基于阿里云对象存储OSS构建。日志服务反对开箱即用的OSS投递入湖性能，实现数据的端到端的入湖。 本文次要介绍如何借助日志服务将关系型数据库MySQL数据入湖和实际，并介绍数据在入湖之前能够日志服务能够提供哪些开箱即用的性能。 入湖流程日志服务中数据库MySQL入湖流程次要包含数据导入和数据投递两局部，日志服务在其中充当了数据通道和数据处理（ETL）的角色，借助日志服务的角色性能，能够为入湖提供更多附加的价值。 MySQL数据导入MySQL作为一种关系型数据库，往往存储了企业外围的业务数据。典型的电商属性的企业零碎会有供应商表、库存表、订单表、用户表等数据；社区属性的企业零碎会有用户表、文章表、评论表等。随着业务的倒退数据量往往变得十分宏大，MySQL作为一种OLTP数据库，善于事务的解决，在海量数据下，对商务经营查问剖析统计能力的需要并不敌对，往往须要将数据导入到OLAP中进行剖析统计。 日志服务提供了一站式数据接入能力，反对各类数据源的接入，本文次要介绍MySQL数据如何进行接入。 随着企业上云的数量越来越多，很多的企业间接应用了云上数据库，比方阿里云提供的RDS数据库，也有一些企业仍然应用自建数据库，日志服务的MySQL数据导入提供了对两种部署状态的数据库的反对。 自建数据库自建数据库次要包含在ECS上自建的数据库或者客户环境部署的数据库，对于ECS自建数据库，往往是部署在VPC网络下，日志服务提供了间接通过VPC链接ECS自建数据库的能力。对于云下环境部署的数据库，出于平安思考个别不会提供公网的拜访链接，能够应用SLS的Logtail插件进行MySQL数据的导入，对于Logtail采集MySQL数据能够参考《采集MySQL查问后果》，这了不在赘述。 RDS数据库对于RDS数据库，日志服务数据接入提供了原生的网络连通能力，反对间接在VPC网络下的连通，不走公网流量，VPC形式是比拟举荐的应用形式。 控制台数据导入流程登录SLS控制台，在Project列表页面，抉择已有的Project或者创立新的Project。在日志库标签页，抉择已有Logstore或者单击+图标创立新的Logstore。在日志库的数据接入 > 数据导入，单击+图标。抉择MySQL数据导入。 1.在数据源配置页面，配置相干信息。输出信息结束后，也能够点击预览查看预览后果。留神：如果是VPC网络下，倡议抉择与VPC网络雷同的区域以防止公网流量。 2.到相应的Logstore查看MySQL数据库是否正确接入，接入后能够抉择开启索引。 3.工作治理和报表展现。 数据入湖将数据接入到日志服务后，日志服务以Logstore作为数据接入形象层，屏蔽了数据源的复杂性，Logstore数据以对立的形式入湖。具体应用办法能够参考：《SLS投递OSS性能降级：打造更顺畅的日志入湖体验》。 日志服务的提供了全托管的数据投递性能和便捷的Wizard反对创立投递工作。仅需填写大量的字段即可实现入湖操作。 并提供了对立的工作治理页面和报表展现页面。 日志服务性能日志服务提供了一站式的数据接入、加工、剖析、告警可视化、数据投递等性能，在入湖之前还能够对数据进行更多价值的开掘，上面举些列子来看下日志服务可用做些什么。 高性能、全功能查问剖析能力日志服务除了提供海量数据的存储之外，也提供了高性能数据的查问剖析能力，反对秒级解决十亿级数据。 反对灵便的剖析语法，反对SQL92语法，与MySQL的数据查问无缝切换。应用参考剖析概述。对于数据量微小的状况，日志服务提供了独享SQL，反对千亿级数据的高性能剖析。适宜剖析性能要求高的场景、大规模业务数据分析场景、长周期数据分析场景。能够无效的补救MySQL剖析数据能力有余。提供了丰盛的内置机器学习函数，能够通过机器学习函数调用机器学习算法，剖析某一字段或若干字段在一段时间内的特色。反对Scheduled SQL，反对对海量数据的Roll Up。应用能够参考Scheduled SQL。数据加工日志服务提供可托管、可扩大、高可用的数据加工服务。数据加工服务可用于数据的规整、富化、流转、脱敏和过滤。通过数据加工能够实现数据规整、数据分派、数据交融等场景下数据处理。 可视化日志服务提供了丰盛的可视化性能，反对创立仪表盘、统计报表、和第三方可视化工具。通过SQL查问出的后果，抉择适合的统计图表类型来展现剖析后果。 仪表盘作为图表的聚合容器，反对主动刷新、报表订阅、设置告警等性能。能够作为企业大盘来应用。 反对丰盛的图表类型，包含表格、线图、流图以及灵便的变量配置和自定义事件等性能。 告警日志服务提供了一站式的告警监控、降噪、事务管理、告诉分派的智能运维平台。商务经营人员（市场、客户经营、财务人员）能够通过告警性能对各种数据库或者指标（例如用户数、活跃度、广告点击率、商品转化率）等进行继续监控；辨认指标的变动状况或者异样并相应，以晋升经营效率、缩小业务危险或财务危险。 参考日志服务（SLS）：https://www.aliyun.com/produc...投递OSS性能降级：打造更顺畅的日志入湖体验：https://developer.aliyun.com/...导入MySQL数据：https://help.aliyun.com/docum...采集MySQL查问后果：https://help.aliyun.com/docum...数据加工概述：https://help.aliyun.com/docum...日志服务告警：https://help.aliyun.com/docum...开启SQL独享版：https://help.aliyun.com/docum...日志服务机器学习语法与函数：https://help.aliyun.com/docum...原文链接 本文为阿里云原创内容，未经容许不得转载。

SQL 语句优化是一个既相熟又生疏的话题。面对千奇百怪的 SQL 语句，尽管数据库自身对 SQL 语句的优化始终在继续改良、晋升，然而咱们不能齐全依赖数据库，应该在给到数据库之前就替它做好各种筹备工作，这样能力让数据库来有精力做它本人善于的事件。 就拿 MySQL 来讲，一条 SQL 语句从客户端收回到数据库端返回后果个别会经验几个阶段：词法解析、语法解析、语义解析、逻辑优化、物理优化、最终执行并返回后果。那么这几个阶段，咱们 DBA 能参加的也就是两个阶段：逻辑优化以及少许物理优化。所以在咱们 DBA 这侧，对 SQL 语句的优化简略来讲就是让咱们本人写的 SQL 语句能更好的适应数据库内置的优化规定，进一步让 SQL 语句在每个解决阶段能扫描更少的记录数量、字段数量来改善查问成果。 逻辑优化能够了解为基于N多数据库内置规定的预处理，规定定义越全面，对 SQL 语句优化的就越极致。比方应用表关联代替子查问、分组聚合条件上推、在特定条件下用内连贯来替换外连贯、视图上推到基表等等一系列优化措施。 物理优化能够了解为数据库依照以后 SQL 语句波及到的表统计信息、列统计信息、索引个数、索引优劣、以后运行负载、以后硬件资源等可变因素来决定如何生成最优执行门路的办法。 一般来讲，咱们拿到一条“不是很优化”、“烂的”、“慢的” 等 SQL 语句（至于怎么拿到这条语句，不在本篇探讨范畴），应该依照以下几个步骤来逐渐剖析：一、定位该SQL 语句波及到的表构造，确认是磁盘表还是视图，如果是磁盘表，那么该思考以下几点：这些表是否对立为InnoDB引擎（MySQL 5.7 以及以前一些老旧版本可能会有非InnoDB引擎表），如果不是，转换表引擎为InnoDB。因为MySQL从5.5 版本开始，所有针对存储层的优化都是针对InnoDB引擎的。极个别表为长期表。查看长期表相干参数是否设置正当；或者说是否把长期表替换为磁盘表。查问每张表的字段类型，看有无不合理的局部。查问每张表的记录数，查看是否过大须要后续拆分。查问每张表的统计信息，查看是否及时做了更新。针对这些表构造做进一步剖析，查看索引设计是否正当？大抵会有以下几种后果：（1）. 都没有索引，有的连主键都没有。 （2）. 都有主键或者惟一索引，然而没有二级索引。 （3）. 有主键或者惟一索引，也有一些二级索引，并且二级索引可选择性也比拟优化。 （4）. 有主键或者惟一索引，也有一些二级索引，然而这些二级索引可选择性很差。 二、如果有些表是视图，须要思考以下几点：该视图外部的算法有两种，一种是长期表（TEMPTABLE）、另外一种是合并（MERGE ）。能够针对这两种算法来别离测试视图整体性能哪个较优化。该视图外部如果有很简单的解决逻辑，想方法把这部分内容简化或者从数据库剥离转交给利用解决，防止数据库将其劣势放大。该视图如果非必须，可拆解为基表与下层SQL 语句做合并解决，这样效率较之前更优化（比方视图外部多表关联与下层基表再次关联，拆分后，优化器就会有更多更优的表关联程序）。三、到了这一步，如果是多张表关联，此处检查表关联键：表关联键为主键和外键，也即两表用来关联的字段在一张表惟一并且在另一张表被援用，这时须要补充额定的过滤条件来缩小扫描记录数。表关联键为非主键，也即两表用来关联的字段都不惟一， 须要优化为惟一键值关联。表关联键字段编码不统一，须要人为转换字段编码并改为统一。四、基于以上几点，表构造剖析这块曾经大抵结束。接下来从SQL 语句层面来剖析，比方这条SQL语句是否批改为更加优化的形式。能够思考以下两点：SQL语句自身很简略，没有必要做批改。 比方这条语句自身是20张表的内联查问，那它不够优化并不是因为写的不好，而是表关联个数切实太多。 SQL语句自身很简单，仔细分析后，能够简化这条语句的写法。 简单SQL语句又能够分为很多类别，比方多张子表关联、多张表嵌套子查问、多个子查问合并输入、多个聚合类操作等等。每种都有不同的优化办法，后续我会一一介绍。 五、那么后面几点做完后，进一步剖析优化后SQL 语句的执行打算（如果有条件模仿生产环境压力模型），个别思考如下几点：改写后的语句执行打算很优化，走最合适的索引、语句自身也改的很简洁，那么这条语句改写实现。改写后的语句执行打算没有走适合的索引，能够思考在表上建设适合的索引。如果建新索引后，这条语句执行成果很好，那么改写实现。改写后的语句走了适合的索引，执行成果仍然不现实，这时可能有以下几种起因：（1）. 这条语句走的索引在不同过滤条件下，运行成果忽好忽坏。 比方日期字段，过滤条件为昨天的查问记录数为100条，过滤条件为前天的查问记录数则变为1W条。 （2）. 这条语句走的索引较优，然而表记录数切实太大，走索引过滤的记录数也很多，须要从表构造这层做些优化。比方后面几期讲过的分区表、拆分表等办法；或者是从业务层面限度这条语句来扫描更少的记录数等等。 通过以上几个步骤，个别的语句基本上都能达到比拟优化的后果。后续我将逐渐介绍各种优化办法以及在MySQL里如何付诸于实际。 对于 MySQL 的技术内容，你们还有什么想晓得的吗？连忙留言通知小编吧！

在仪表板大屏等理论业务利用场景中，浏览端的分辨率会不同，如果分辨率差距太大，仅仅缩放统计图和图片，文字不缩放，会呈现文字重叠或显示太小的问题。所以用户心愿统计图的标签字体或者窗格中的文字字体大小能跟谁窗格大小进行同比例缩放。大分辨率下显示如下： (file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml16028\wps1.jpg)在老一些的电脑上查看分辨率低了会显示错位通过字体追随窗格大小同比例缩放性能，能够在不同分辨率下显示窗格内容里的字体大小追随窗格同比例缩放显示，如下图同样的在统计图中的标签文字也能够追随比例缩放，这样防止了不同分辨率文字叠加错位显示的问题。

pdf下载：明码7281专栏目录首页：【专栏必读】（考研复试）数据库系统概论第五版（王珊）专栏学习笔记目录导航及课后习题答案详解 名词解释数据：是数据库中存储的根本对象，是形容事物的符号记录数据库：是永恒存储在计算机内的，有组织的、可共享的大量数据的汇合数据库管理系统：是位于用户与操作系统之间的一层数据管理软件，和操作系统一样都是计算机的根底软件数据库系统：是在计算机中引入数据库后的零碎形成。包含DB,DBMS,APP,DBA数据模型：计算机是不可能间接解决事实世界中的具体事物的，所以人们必须当时把具体事物转化为计算机可能解决的数据。因而数据模型是对事实世界数据特色的形象，也即数据模型是用来形容数据、组织数据和对数据进行操作的概念模型（信息模型）：是按用户的观点来对数据和信息建模，用于数据库设计逻辑模型：是按计算机系统的观点对数据建模，次要用于数据库管理系统的实现物理模型：对数据最底层的形象，它形容数据在零碎外部的示意办法和存取方法，或在磁盘或磁带上的存储形式和存取方法，是面向计算机系统的实体 ：客观存在并能够互相区别的事物。实体能够是具体的人、事、物，也能够是形象的概念或分割属性：实体所具备的某一个性。一个实体能够由若干属性刻画码 ：惟一标识实体的属性实体型： 用实体名及其属性汇合来形象和刻画同类实体实体集： 同一类型实体的汇合分割 ：实体外部的分割通常是指组成实体的各属性之间的分割，实体之间的分割通常是指不同实体集之间的分割关系 ：一个关系对应一张表元组 ：表中一行或者是一条记录叫做一个元组属性 ：表中一列叫做一个属性，给每一个属性起一个名称叫做属性名码 ：用于惟一确定一个元组域 ：属性的取值范畴重量 ：元组的每一个属性值，关系的每一个重量都不能够再分关系模式 ：对关系的形容，必须是规范化的模式：是数据库中整体数据的逻辑构造和特色的形容，是所有用户的公共数据视图，综合了所有用户的需要，对应概念模式外模式：是数据库用户（包含程序员和最终用户）可能看见和应用的部分的逻辑构造和特色的形容，是数据库用户的数据视图，是与某一利用无关的数据的逻辑形容内模式：是数据物理构造和存储形式的形容，是数据在数据库外部的示意形式简答题【答案】 数据：是数据库中存储的根本对象，是形容事物的符号记录数据库：是永恒存储在计算机内的，有组织的、可共享的大量数据的汇合数据库管理系统：是位于用户与操作系统之间的一层数据管理软件，和操作系统一样都是计算机的根底软件数据库系统：是在计算机中引入数据库后的零碎形成。包含DB,DBMS,APP,DBA【答案】 数据库系统具备一个很大的特点，那就是整体结构化。数据的构造用 数据模型形容，无序程序定义和解释数据库系统中数据的共享度高，冗余度低，易裁减数据库系统数据独立性高（物理独立性和逻辑独立性），也即程序和数据之间互相独立，互不影响数据由DBMS对立治理和管制，他能够提供安全性、完整性、并发等诸多服务【答案】 区别：文件系统面向某一应用程序，共享性差，冗余度大，数据独立性差，记录内有构造，整体无构造，由应用程序本人管制。数据库系统面向事实世界，共享性高，冗余度小，具备较高的物理独立性和肯定的逻辑独立性，整体结构化，用数据模型形容，由数据库管理系统提供数据的安全性、完整性、并发管制和恢复能力 分割：文件系统与数据库系统都是计算机系统中治理数据的软件。解析文件系统是操作系统的重要组成部分;而DBMS是独立于操作系统的软件。然而DBMS是在操作系统的根底上实现的;数据库中数据的组织和存储是通过操作系统中的文件系统来实现的 【答案】 数据定义性能（提供数据定义语言DDL）数据组织、存储和治理性能数据操纵性能（提供数据操纵语言DML）数据库的事务管理和运行治理数据库的建设和保护性能【答案】 定义：是依照用户的观点对数据和信息建模，用于数据库设计作用：概念模型实际上是事实世界到机器世界的一个两头档次。概念模型用于信息世界的建模，是事实世界到信息世界的第一层形象，是数据库设计人员进行数据库设计的无力工具，也是数据库设计人员和用户之间进行交换的语言【答案】 实体：客观存在并能够互相区别的事物实体型：用实体名及其属性汇合来形象和刻画同类实体实体集：同一类型实体的汇合分割：实体外部的分割通常是指组成实体的各属性之间的分割，实体之间的分割通常是指不同实体集之间的分割【答案】 数据模型的概念：数据模型是对事实世界数据特色的形象，也即数据模型是用来形容，组织数据和操纵数据的三个因素：数据结构，数据操纵和数据完整性束缚【答案】 ①：层次模型 ②：网状模型 【答案】 【答案】 【答案】 物理独立性：用户的应用程序与存储在磁盘上的数据库中数据是独立的。当数据的物理存储扭转时，应用程序不扭转逻辑独立性 ：用户应用程序与数据库的逻辑构造是互相独立的。数据的逻辑构造扭转了，用户的程序也能够不变 应用题

基本概念与根底操作基本概念单表查问多表查问1 基本概念数据类型完整性束缚根底语句1.1 数据类型字符串 数据类型大小形容char(n),character(n)0~255 byte定长为n的字符串varchar(n),charactervarying(n)0~65535 byte最大长度为n的字符串tinyblob0~255 byte二进制短字符串blob0~65535(64K) byte二进制长文本数据mediumblob0~16777215(8M) byte二进制中等长度文本数据longblob0~4294967295(4G) byte二进制大文本数据clob0~65535(64K) byte字符串大对象tinytext0~255 byte短文本字符串text0~65535(64K) byte长文本字符串mediumtext0~16777215(8M) byte中长文本字符串longtext0~4294967295(4G) byte大文本字符串数字 数据类型大小形容tinyint1byte(Byte)-127~128 / 0~255smallint2byte(Short)-32768~32767 / 0~65535mediumint3byte(Integer)-8388608~8388607 / 0 ~ 16777215int,integer4byte(Integer)-2147483648~2147483647 / 0~4294967295bigint8byte(Long)-9223372036854775808~9223372036854775807 / 0~18446744073709551615numeric(p,d),decimal(p,d),dec(p,d)-----定点数，p位数 ， d位小数float4bytefloat(p,d)同定点数double8bytedouble(p,d)同定点数日期 数据类型大小格局形容date3byteYYYY-MM-DD1000-01-01~9999-12-31time3byteHH:MM:SS-838:59:59~838:59:59timestamp4byteYYYY-MM-DD HH:MM:SS1970-01-01 00:00:00/2038datetime8byteYYYY-MM-DD HH:MM:SS1000-01-01 00:00:00~9999-12-31 23:59:59year---------------1.2 完整性束缚列完整性约束条件列规定，限度退出表的数据，保证数据的有效性、正确性和完整性 # 可对约束条件命名[ CONSTRAINT < 束缚名 > ] < 束缚类型 >束缚名称形容关键字其余主键束缚每行数据的惟一标识，非空且惟一PRIMARY KEYauto_increment自增长(数字 惟一)外键束缚用来让两个表建设连贯，保证数据的一致性和参照完整性FOREING KEYREFERENCES指明参照哪些表的主键非空束缚该列数据不能为nullNOT NULL-----惟一束缚该列数据各不相同UNIQUE-----查看束缚该列的值满足对立的条件CHECK-----默认束缚默认值DEFAULT-----外键束缚建表时： [CONSTRAINT 束缚名] FOREING KEY(<column_name> )REFERENCES 主表名(<column_name>);建表后： ALTER TABLE <table_name> ADD[CONSTRAINT 束缚名] FOREING KEY(<column_name>)REFERENCES 主表名(<column_name>);删除束缚： ALTER TABLE 从表名 DROP FOREING KEY 束缚名;1.3 根底语句数据库 ...

MySql装置配置/根底操作1.Windows环境1.1 下载官网地址抉择第一个无test版本 1.2 配置创立mysql文件夹 并将下载的文件解压到该文件夹下在解压的文件内创立配置文件 my.ini在my.ini文件内写入配置信息 [mysqld]#设置3306端口port=3306#设置mysql的装置目录basedir=#设置mysql数据库的数据的寄存目录datadir=\data#容许最大连接数max_connections=200#容许连贯失败的次数。这是为了避免有人从该主机试图攻打数据库系统max_connect_errors=10#服务端应用的字符集默认为UTF8character-set-server=utf8#创立新表时将应用的默认存储引擎default-storage-engine=INNODB#默认应用“mysql_native_password”插件认证default_authentication_plugin=mysql_native_password[mysql]#设置mysql客户端默认字符集default-character-set=utf8[client]#设置mysql客户端连贯服务端时默认应用的端口port=3306default-character-set=utf8basedir与datadir的data前为解压后文件的门路增加环境变量 Path中增加解压文件夹的bin文件门路1.3 初始化不设置明码初始化 mysqld --initialize-insecure --user=mysql胜利会在文件夹下生成data文件夹装置mysql服务，默认服务名为mysql mysqld -install胜利会提醒Service successfully installed.启动服务 net start mysql胜利会提醒MySQL 服务曾经启动胜利。启动数据库 mysql -u root -p胜利进入mysql批改明码 mysql>alter user user() identified by "你要批改的明码";重置明码 # 暂停服务net stop mysql# 跳过验证开启服务mysqld --console --skip-grant-tables --shared-memory# 新终端无明码登录 - 间接回车mysql -u root -p# 重置明码use mysqlmysql> update user set authentication_string='' where user='root';mysql> quit# 敞开所有终端 新建终端net start mysqlmysql -u root -p# mysql 退出quit# 敞开服务net stop mysql2 Linux环境

应用开源实时监控零碎 HertzBeat 对 Mysql 数据库监控告警实际，5分钟搞定！Mysql 数据库介绍MySQL是一个开源关系型数据库管理系统，由瑞典MySQL AB 公司开发，属于 Oracle 旗下产品。MySQL 是最风行的开源关系型数据库管理系统之一，在 WEB 利用方面，MySQL是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件之一。HertzBeat 介绍HertzBeat 是一款开源，易用敌对的实时监控零碎，无需Agent，领有弱小自定义监控能力。集监控-告警-告诉为一体，反对对应用服务，数据库，操作系统，中间件，云原生等监控，阈值告警，告警告诉(邮件微信钉钉飞书短信 Slack Discord Telegram)。其将Http,Jmx,Ssh,Snmp,Jdbc等协定标准可配置化，只需配置YML就能应用这些协定去自定义采集任何您想要采集的指标。您置信只需配置YML就能立即适配一个K8s或Docker等新的监控类型吗？HertzBeat 的弱小自定义，多类型反对，易扩大，低耦合，心愿能帮忙开发者和中小团队疾速搭建自有监控零碎。在 HertzBeat 5分钟搞定对 Mysql 数据库监控操作前提，您已领有 Mysql 环境和 HertzBeat 环境。Mysql [装置部署文档] https://www.runoob.com/mysql/...HertzBeat [装置部署文档] https://hertzbeat.com/docs/st...在开源监控零碎 HertzBeat 监控页面增加对 Mysql 数据库监控点击新增 Mysql 监控门路：菜单 -> 数据库监控 -> Mysql数据库 -> 新增Mysql数据库监控 配置新增监控 Mysql 数据库所需参数在监控页面填写 Mysql 服务IP，监控端口(默认3306)，账户明码等，最初点击确定增加即可。 其余参数如采集距离，超时工夫等能够参考帮忙文档 https://hertzbeat.com/docs/he... 实现✅,当初咱们曾经增加好对 Mysql数据库 的监控了，查看监控列表即可看到咱们的增加项。 点击监控列表项的操作->监控详情图标 即可浏览 Mysql数据库 的实时监控指标数据。 点击监控历史详情TAB 即可浏览 Mysql数据库 的历史监控指标数据图表。 ...

一、概念事务 个别指的是逻辑上的一组操作，或者作为单个逻辑单元执行的一系列操作，一个事务中的所有操作会被封装成一个不可分割的执行单元，这个单元的所有操作要么全副执行胜利，要么全副执行失败，只有其中任意一个操作执行失败，整个事务就会执行回滚操作。二、事务的个性以及类型介绍2.1 事务个性 原子性（atomicity）事务的原子性指的是形成事务的所有操作要么全副执行胜利，要么全副执行是失败。 一致性（consistency）事务的一致性指的是事务执行之前和执行之后，数据始终处于统一的状态。 隔离性（isolation）事务的隔离性指的是并发执行的两个事务之间互不烦扰，也就是说，一个事务执行的过程中是无奈看到其余事务运行过程的中间状态的。 留神：MySQL是通过锁个MVCC机制来保障事务的隔离性。持久性（duration）事务的持久性指的是一旦事务被提交后，此事务对数据的更改操作会被长久化到数据库中，并且不会被回滚。 2.2 两种事务类型介绍本地事务分布式事务本地事务通常基于关系型数据库管制的事务能够称作为传统事务或者本地事务。本地事务的执行流程 客户端开始事务操作之前，须要开启一个连贯回话；开始回话之后，客户端发动开启事务的指令；事务开始后，客户端发送各种SQL语句解决数据；失常状况下，客户端会发动提交事务的指令，如果产生异常情况，客户端会发动回滚事务命令；上述流程实现后，敞开会话。✔本地事务是有资源管理器在本地进行治理的。本地事务的毛病在于： 不具备分布式事务的解决能力一次事务过程只能连贯一个反对事务的数据库，既不能用于多个事务性数据库。三、并发事务会带来的哪些问题? 更新失落（脏写）当两个会在两个以上的事务同时操作同一行数据，并给予最后选定的值更新该行数据时，视为事务之间是无奈感知彼此的存在的，所以会呈现最初的更新操作会笼罩之前其余事务实现的更新操作。 举个例子： 张三的账户为100元，以后有两个事务：事务1和事务2，事务1是将张三账户余额减少100元，事务2是将张三余额减少200，起初事务1和事务2同时读到张三的账户余额都是100元，而后事务1和事务2别离更新张三月，假如事务1先于事务2提交，然而最近两个事务都提交后张三的余额为300元（失常状况应该是400元），也就是说：后提交的事务2笼罩了事务1的更新操作，这就是所谓的更新失落，更新失落（脏写）实质上是写操作的抵触，然而解决脏写的形式是让每个事务串行形式执行，保障事务依照肯定的程序执行写操作。 脏读一个事务读取到另一个事务未提交的数据。比方：事务1正在对张三的余额减少100元，在这个事务没提交之前，另一个事务2读取了正在批改的这条数据，如果没有事务的管制下，第二条事务就会读取到没有被提交的脏数据，并且对脏数据丛下一步的解决，此时就会产生未提交数据的依赖关系，通常这种景象被称为 脏读，也就是说：脏读是一个事务读取了另一个事务没提交的数据。 脏读实质上是读写操作的抵触，解决办法是先写后读，也就是写完之后再读。不可反复读一个事务读取了某些数据，在一段时间后，这个事务再次读取之前读过的数据，此时发现读取的数据产生了变动，或者其中某些数据记录曾经被删除，这种景象被称为：不可反复读，即同一个事务，应用同样的查问语句，在不同时刻读取到的后果不统一。 不可反复读的实质上也是读写操作抵触，解决办法是先读后写，也就是读完之后再写。幻读一个事务依照雷同的查问条件从新读取之前读过的数据，此时发现其余事务插入了满足以后查问条件的新数据，数据后果集变多，这种景象称为幻读，即一个事务两次读取一个范畴的数据记录，两次读到的后果不同。 幻读的实质上也是读写操作抵触，解决办法是先读后写，也就是读完之后再写。那到这里，很多小伙伴就有疑难，同样实质都是读写操作抵触，解决办法是先读后写，不可反复读和幻读到底有何区别?，我上面见简略解释一下： 1️ 不可反复读的重点在于更新和删除操作，而幻读的重点在于插入操作。2️ MySQL应用锁机制实现事务的隔离级别时，在可反复读隔离级别中，SQL语句第一个读取到数据后，会将相应的数据加锁，使得其余事务无奈批改和删除这些数据，通过锁的形式实现可反复读。然而这种办法无奈对新数据的插入加锁，如果事务1读取了数据，或者批改和删除了数据，事务2还能够进行插入操作，导致事务1莫名其妙地多了一条之前没有的数据，这就是幻读。3️ 所以，幻读是无奈通过锁机制来防止，须要应用串行化的事务隔离级别，然而这种事务隔离级别会大大降低数据库的并发能力。 ✔MySQL是通过MVCC（多版本并发管制）机制来防止不可反复读和幻读的。四、MySQL事务的隔离级别 应用上面的命令能够查问全局级别和会话级别的事务隔离级别： # 默认数据库的事务隔离级别为：可反复读（REPEATABLE-READ）SELECT @@global.tx_isolation;SELECT @@session.tx_isolation;SELECT @@tx_isolation; 五、多版本并发管制MVCCMulti-Version Concurrency Control多版本并发管制，MVCC是一种并发管制的办法，个别在数据库管理系统中，实现对数据库的并发拜访。MVCC比锁的劣势能够将MVCC看成行级别锁的一种斗争，它在许多状况下防止了应用锁，同时能够提供更小的开销。依据实现的不同，它能够容许非阻塞式读，在写操作进行时只锁定必要的记录。 MVCC的实现原理MVCC的是通过保留数据澡某个工夫点的快照来实现的，也就是说，不论事务执行多长的工夫，每个事务看到的数据都是统一的。依据事务的开始工夫不同，每个事务对同一张表，同一时刻看到的数据可能是不一样的。InnonDB次要通过为每一行记录增加两个额定的暗藏的值来实现MVCC，这两个值一个记录这行数据何时被创立，另外一个记录这行数据何时过期（或者被删除）。然而InnoDB并不存储这些事件产生时的 理论工夫 ，相同它只存储这些事件产生时的零碎 版本号（version） 。这是一个随着事务的创立而一直增长的数字。每个事务在事务开始时会记录它本人的零碎版本号。每个查问必须去查看每行数据的版本号与事务的版本号是否雷同。 《高性能MySQL》书籍中介绍到： MVCC只在REPEATABLE READ和READ COMMITTIED两个隔离级别下工作，其余两个隔离级别都和MVCC不兼容，因为READ UNCOMMITTED总是读取最新的数据行，而不合乎以后事务版本数据行，而SERIALIZABLE串行化隔离级别则会对所有读取的行都加锁。 接下来举个例子阐明在可反复读事务隔离级别下，MVCC机制是如何实现增删改查操作的。 查问操作（SELECT）在查问操作中，InnoDB存储引擎跟依据以下两个条件查问对应的行记录，只有满足对应条件才会被返回： 1️ 只查找不晚于以后事务版本的数据行，也就是说，InnoDB存储引擎只会查找版本号小于或者等于以后事务版本的数据行，这些数据行要么在该事务开始前就存在，要么就是事务自身插入或者更新的行。2️ 对于数据删除，数据行删除的版本要么还没有被定义，要么大于以后事务的版本号，只有这样能力确保事务读到的行，在事务开始前并没有被删除。 举个例子，存在 事务A 和 事务B 两个事务，事务A中存在两套雷同的SELECT语句，事务B存在一条UPDATE语句，事务A 的第一条查问语句在事务B提交之前执行，第二条查问语句在 事务B 提交之后执行，事务A 如下所示： -- 事务A操作START TRANSACTION;SELECT * FROM account WHERE id = 1; //在事务B提交之前执行SELECT * FROM account WHERE id = 1; //在事务B提交之后执行COMMIT;事务B： ...

作者：杨文 DBA，负责客户我的项目的需要与保护，会点数据库，不限于MySQL、Redis、Cassandra、GreenPlum、ClickHouse、Elastic、TDSQL等等。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 1、Linux大内存页个性Linux下的大页分为两种类型：规范大页（Huge Pages）和通明大页（Transparent Huge Pages）。 大页的产生：大多数操作系统采纳了分段或分页的形式进行治理。分段是粗粒度的治理形式，而分页则是细粒度治理形式，分页形式能够防止内存空间的节约。相应地，也就存在内存的物理地址与虚拟地址的概念。通过后面这两种形式，CPU必须把虚拟地址转换程物理内存地址能力真正拜访内存。为了进步这个转换效率，CPU会缓存最近的虚拟内存地址和物理内存地址的映射关系，并保留在一个由CPU保护的映射表中。为了尽量进步内存的访问速度，须要在映射表中保留尽量多的映射关系。Linux的内存治理采取的是分页存取机制，为了保障物理内存能失去充沛的利用，内核会依照LRU算法在适当的时候将物理内存中不常常应用的内存页主动替换到虚拟内存中，而将常常应用的信息保留到物理内存。通常状况下，Linux默认状况下每页是4K，这就意味着如果物理内存很大，则映射表的条目将会十分多，会影响CPU的检索效率。因为内存大小是固定的，为了缩小映射表的条目，可采取的方法只有减少页的尺寸。因而Hugepage便因而而来。也就是突破传统的小页面的内存治理形式，应用大页面2M,4M等。如此一来映射条目则显著缩小。TLB缓存命中率将大大提高。 2、HugePages：2.1、概念介绍：1）HugePages是从Linux Kernel 2.6后被引入的。目标是应用更大的内存页面（memory page size） 以适应越来越大的零碎内存，让操作系统能够反对古代硬件架构的大页面容量性能。在Linux下，page size默认是4K，如果应用HugePages，默认是2M； 2）page table和TLB： page table 映射表：物理内存和swap的对应关系、拜访内存是先读page table、依据表里的映射关系操作； TLB：cpu cache组件、缓存局部page table以进步转换速度； 2.2、配置 HugePages 优缺点：1）长处： 不须要内存页替换；加重快表压力；加重换页表的负载；进步内存的性能，升高CPU负载；2）毛病：传统大页很难手动治理, 而且通常须要对代码进行重大更改能力无效地应用。 2.3、HugePages 应用倡议：1）如果您的零碎常常碰到因为 swap 引发的性能问题，零碎毫无疑问须要启用HugePage。 2）OS内存十分大的零碎也须要启用HugePage。 2.4、应用 HugePages 注意事项：如果未调整 HugePages ，可能会引发上面的问题： 数据库性能低下；呈现内存不足或者适度应用替换空间；数据库实例不能被启动；关键性零碎服务故障；2.5、应用状况与配置查看：1）确认HuagePage是否配置： cat /proc/sys/vm/nr_hugepages2）查看大页的应用状况： $ grep Huge /proc/meminfoHugePages_Total: 150HugePages_Free: 150HugePages_Rsvd: 0HugePages_Surp: 0Hugepagesize: 2048 kB2.6、HugePages配置：1）设置 memlock(内存锁)： vim /etc/security/limits.conf在文件最初增加信息：mysql soft memlock unlimitedmysql hard memlock unlimited2）批改/etc/sysctl.conf： vi /etc/sysctl.conf增加/批改信息：kernel.shmmax = 17179869184kernel.shmall = 41943043）查看 mysql 用户的组信息： ...

记录mysql问题明天在用应用mysql group by 查问的时候呈现报错SELECT `id`, `open_id`, sum( `pay_amount` ) AS pay_amount, sum( `pay_num` ) AS pay_num FROM `table` WHERE ( `app_id` = '30133' ) GROUP BY `open_id` ORDER BY `pay_amount` DESC LIMIT 10查问会报出SELECT list is not in GROUP BY clause and contains...剖析得出 mysql5.7之后数据库默认模式改为 only_full_group_by模式，在执行SQL外面有些反复行group by的时候mysql 不晓得抉择哪一行。解决方案： 应用any_value()包含具体提醒的列名，使mysql不再纠结于具体哪一列优化SQL，对于每一个分组的元素 清晰的告知mysql 要如何抉择#这样就okSELECT ANY_VALUE(id) AS `id`, `open_id`, sum( `pay_amount` ) AS pay_amount, sum( `pay_num` ) AS pay_num FROM `table` WHERE ( `app_id` = '30133' ) GROUP BY `open_id` ORDER BY `pay_amount` DESC LIMIT 10

重新认识MySQL客户端/服务器架构MySQL的装置bin目录下的可执行文件bin目录下有好几种启动MySQL的可执行文件 启动MySQL服务器程序UNIX里启动服务器程序mysqld 能够启动一个服务器过程mysqld_safe 启动脚本,间接调用mysqld,顺便启动一个监控线程,在服务器过程挂了的时候，帮忙重启。mysql.server 启动脚本,间接调用mysql_safe,在调用mysql.server时在后边指定start参数就能够启动服务器程序。 mysql.server startmysqld_multi 对每一个服务器过程的启动和进行进行监控 启动MySQL客户端程序mysql -h主机名 -u用户名 -p明码本上是一个过程间通信的过程 客户端与服务器连贯的过程TCP/IP如果应用TCP/IP网络来连贯到服务器过程,就须要在启动客户端程序时在-h前面应用IP地址来作为须要连贯的服务器过程所在主机的主机名。 服务器解决客户端的申请启动选项和零碎变量启动选项和配置文件在命令行上应用选项例如,启动时禁止应用TCP/IP网络通信。 mysql --skip-networking指定启动选项时须要加上--前缀。另外如果选项名是由多个单词形成的,他们之间能够由短划线-连接起来。比方,skip-networking和skip_networking示意的含意是雷同的。还有一个例子是启动时设置表的存储引擎 书上还强调了一下选项的长模式和短模式,例如--host -h主机名这样式儿的 配置文件应用选项因为启动时命令行选项只在本次起作用,所以放在配置文件中永恒失效 配置文件门路这块对于类unix的门路进行形容 配置文件内容分组进行配置,各个启动命令也有能读取的组的限度。注:如果同一个启动选项即呈现在命令行中,又呈现在配置文件中,那么以命令行的启动选项为准。 零碎变量简介在服务器程序运行过程中能对其造成影响的变量。 查看零碎变量show variables like 'default_storage_engine'设置零碎变量通过启动选项设置服务器运行过程中设置设置不同作用范畴的零碎变量书上提到了两个概念或者说是两个范畴,一个是global,另一个是session。 GLOBL:全局变量,影响服务器的整体操作SESSION:会话变量,影响某个客户端连贯的操作 服务器启动时,会将每个全局变量初始化为其默认值。服务器会为每个客户端连贯保护一组会话变量,客户端的会话变量在连贯时应用相应全局变量的以后值初始化。如果在设置零碎变量的语句中省略了作用范畴,默认的作用范畴就是SESSION(这次的客户端连贯)。 查看不同作用范畴的零碎变量同样也是应用show varaibles like 'default_storage_engine' 状态变量为了检测服务器程序的运行状况而存在的变量,由此而知,它们的值是由服务器程序来设置的。show status like 'thread%' 状态变量也有global和session两个作用范畴。 字符集和比拟规定字符集和比拟规定介绍字符集简介将二进制数据转换为字符所用的这套转换规则就是字符集 比拟规定简介a-0x01 b-0x02 下面的字符如果以二进制数据本身的比拟规定来进行比拟的话,那么大多数时候是不合乎场景需要的。 'a'和'A'进行比拟时: 将两个大小写不同的字符全副转换为大写或者小写再比拟这两个字符对应的二进制数据。 字符集和比拟规定的利用各级别的字符集和比拟规定客户端和服务器通信过程中应用的字符集比拟规定的利用总结字符集比拟规定在MySQL中,一个字符集能够有若干种比拟规定,其中有一个默认的比拟规定,一个比拟规定必须对应一个字符集查看MySQL反对的字符集和比拟规定语句:show (charcter set|charset)[like 匹配的模式] show collation [like 匹配的模式]MySQL有四个级别的字符集和比拟规定 1 服务器级别2 数据库级别3 表级别4 列级别从发送申请到接管后果过程中产生的字符集转换比拟规定的作用通常体现在比拟字符串大小的表达式和对某个字符串进行排序中 InnoDB记录存储构造尽管书上曾经讲得非常艰深了,奈何我学的还是十分吃力,找了一篇博客,感觉还不错。 https://draveness.me/mysql-in... 简介将数据划分为若干个页,以页作为磁盘和内存之间交互的工作单位,InnoDB中页的大小个别为16KB. Compact格局Redundant行格局两者的异同最大的不同就是compact在行记录的第一局部倒序寄存了一行数据中列的长度(Length),而Redundant中存的是每一列的偏移量(Offset) 行溢出数据当InnoDB应用Compact或者Redundant格局存储极长的VARCHAR或者BLOB这类大对象时,咱们并不会间接将所有的内容都寄存在数据页节点中,而是将行数据中的前768个字节存储在数据页中,前面会通过偏移量指向溢出页。 当应用新的记录格局Compressed或者Dynamic时都会只在行记录中保留20个子节的指针,理论的数据都会寄存在溢出页面中。 InnoDB数据页构造不同类型的页为了不同的目标设计了许多种不同类型的页,比方寄存头部信息的页,寄存Insert Buffer信息的,寄存index信息的页,寄存undo日志信息的页等 数据页构造的疾速浏览数据页代表的这块16KB大小的存储空间能够被划分多个局部,不同的局部有不同的性能 File HeaderPage HeaderInfimum+supremum 两个虚构的行记录 最大记录和最小记录User Records 实在存储行记录内容Free SpacePage Directory 页中的某些记录的绝对地位File Tailer ...

介绍MySQL从5.0版本开始反对存储过程和函数。存储过程和函数可能将简单的 SQL 逻辑封装在一起，应用程序毋庸关注存储过程和函数外部简单的 SQL 逻辑，而只须要简略地调用存储过程和函数即可。一句话总结：存储过程是一组为了实现特定性能的 SQL 语句汇合。 关键字：封装、重用 根本语法根本语法包含存储过程的创立、调用、查看、与删除。 创立存储过程： CREATE PROCEDURE 存储过程名称 ([ 参数列表 ])BEGIN -- SQL语句END ;调用存储过程： CALL 名称 ([ 参数 ]);查看存储过程： 1. 查问某个存储过程的定义SHOW CREATE PROCEDURE 存储过程名称;2. 查问指定数据库的存储过程及状态信息SELECT * FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_SCHEMA = 'xxx';删除存储过程： DROP PROCEDURE [ IF EXISTS ] 存储过程名称；简略的例子后面提到了，存储过程是为了实现特定工作的 SQL 汇合，能够只有一条 SQL 语句，也能够有多条。即存储过程能够非常简单也能够非常复杂，上面就通过一个简略的例子来阐明存储过程的根本应用。 创立一个查问用户表所有数据的存储过程： CREATE PROCEDURE `p_user`()LANGUAGE SQLNOT DETERMINISTICCONTAINS SQLSQL SECURITY DEFINERCOMMENT '查问用户表的所有数据'BEGIN SELECT * FROM tb_user;END调用该存储过程： CALL p_user();后果： 查看该存储过程： SHOW CREATE PROCEDURE p_user; ...

概述索引是MySQL的数据结构，关系着MySQL如何存储数据，查问数据；而如何操作数据，解决多线程时操作数据带来的问题，则须要通过事务来实现。 InnoDB引擎反对事务，MyISAM引擎不反对事务ACID事务是由一组SQL语句组成的逻辑处理单元,事务具备以下4个属性,通常简称为事务的ACID属性 原子性(Atomicity)：事务是一个原子操作单元,其对数据的批改,要么全都执行,要么全都不执行。一致性(Consistent) ：在事务开始和实现时,数据都必须保持一致状态。隔离性(Isolation)：数据库系统提供肯定的隔离机制,保障事务在不受内部并发操作影响的“独立”环境执行。持久性(Durable)：事务实现之后,它对于数据的批改是永久性的。用大白话说： 原子性：事务里的所有操作，要么是commit全副提交胜利，要么是rollback全副回滚。一致性：集体认为更多在于业务操作，如A用户向B用户转账100，必须是A-100, B+100，不能呈现A转账胜利，B未收到状况。隔离性：A事务在操作数据时，不受B事务影响。这点会在本文具体阐明。持久性：对数据的所有胜利操作，都会落到磁盘上。事务隔离级别InnoDB中，一共有四种隔离级别：读未提交、读已提交、可反复读、可串行化。默认为可反复读。 它们别离会对应一些并发问题，如表格所示： 隔离级别脏读不可反复读幻读读未提交有可能有可能有可能读已提交不可能有可能有可能可反复读不可能不可能有可能可串行化不可能不可能不可能脏读：事务A读取到了事务B曾经批改但尚未提交的数据，还在这个数据根底上做了操作。此时，如果B事务回滚，A读取的数据有效。不可反复读：一个事务在读取某些数据后的某个工夫，再次读取以前读过的数据，却发现其读出的数据曾经产生了扭转、或某些记录曾经被删除了。幻读：一个事务按雷同的查问条件从新读取以前检索过的数据，却发现其余事务插入了满足其查问条件的新数据，这种景象就称为幻读。上面将对这些问题做具体解释读未提交在该隔离级别下，事务A能够读到事务B尚未提交的数据。 设置形式： set tx_isolation='read-uncommitted';如以下事务A先进行查问用户数据, 此时jack的余额为10 事务B批改jack的余额为20 begin;update account set balance = balance + 10 where id = 1;留神：此时事务B并未提交事务A再次查问，发现jack的余额已变为为20 若此时事务A用该数据进行业务解决，比方购买商品，实现之后，事务B产生回滚。那么就相当于事务A用了谬误的数据进行了业务。 读已提交在该隔离级别下，事务A能够读到事务B曾经提交的数据。 设置形式： set tx_isolation='read-committed';如以下事务A先进行查问用户数据, 此时jack的余额为10 事务B批改jack的余额为20 begin;update account set balance = balance + 10 where id = 1;留神：此时事务B并未提交事务A再次查问，jack的余额依然为10 此时事务B提交数据，事务A再次查问，发现jack的余额变为了20 此时就会带来一个新的问题：在事务A中，明明没有对该条数据做任何批改，但屡次查问发现数据始终变动，就会给人带来纳闷：我到底应该用哪个数据实现业务呢？ 可反复读在该隔离级别下，事务A每次查问的数据都和第一次查问的数据雷同。 设置形式： set tx_isolation='repeatable-read';如以下事务A先进行查问用户数据, 此时jack的余额为10 事务B批改jack的余额为20, 并且提交数据 begin;update account set balance = balance + 10 where id = 1;commit;留神：此时事务B曾经提交了事务A再次查问，jack的余额依然为10 ...

基础知识SQLStructured Query Language数据操纵和数据定义等多种性能的数据库语言，可分为以下四类 DDL Data Definition Language 数据定义语言 create drop alter truncate 等DMLData Manipulation Language数据操作语言 insert update delete 等DQLData Query Language数据查询语言 selectDCLData Control Language 数据管制语言 grant revoke 等MDLmeta data lock，直译为元数据锁 从MySQL 5.5开始引入MDL加锁是零碎自动控制MDL读读共享，读写互斥，写写互斥对表DML & DQL时，零碎会主动加MDL读锁；对更DDL时，会加MDL写锁；其意义在于，增删改查只操作表内的数据，不影响表构造，故只须要读取元数据信息（即表构造信息），此时增删改查能够并行，只是不能批改表构造；而加写锁时，只有获取锁的线程能够读写元数据（即批改表构造信息），其余线程不能批改构造也不能执行增删改查操作； MDL 可能引起的问题承上可知，执行DDL时会阻塞该表的增删查改操作，如果表数据量过大，或者表的读写十分频繁时，可能会引发性能问题，DDL持续时间过长，就会长工夫阻塞后续操作，导致大量线程期待锁的开释，导致程序解体 Online DDLMySQL 5.6引入了Online DDL，来解决上述MDL可能引发的问题，Online DDL具体执行过程如下 获取MDL写锁（即阻塞该表的增删查改操作）将MDL写锁降级成MDL读锁（让该表的增删查改操作失常执行）执行真正的DDL操作（即批改表构造），此过程十分耗时，但此时持有的是MDL读锁，并不会阻塞增删改查操作（即做到并行）实现DDL操作后，将MDL读锁降级为MDL写锁开释MDL锁为什么DDL不锁表，而是阻塞了所有该表的SQL由上述信息可知，执行DDL时，并非锁住整个表，而是在第1步与第4步中的MDL写锁阻塞了该表的增删查改操作 仍可能引发的问题Waiting for table metadata lock由上述信息可知，执行DDL须要获取MDL写锁，若有一个执行工夫很长的事务，始终不开释MDL读锁，则DDL就须要长时间期待，具体场景能够自行查阅官网文档以及其余博客，此处不再赘述

前言SELinux是什么平安增强型 Linux（SELinux）是一种采纳平安架构的 Linux® 零碎，它可能让管理员更好地管控哪些人能够拜访零碎。它最后是作为 Linux 内核的一系列补丁，由美国国家安全局（NSA）利用 Linux 平安模块（LSM）开发而成。 SELinux工作原理SELinux 定义了每个人对系统上的利用、过程和文件的访问控制。利用安全策略（一组告知 SELinux 哪些能拜访，哪些不能拜访的规定）来强制执行策略所容许的拜访。 当利用或过程（称为主体）收回拜访对象（如文件）的申请时，SELinux 会查看拜访向量缓存（AVC），其中缓存有主体和对象的拜访权限。 开启 SELinux 能够晋升零碎的安全性，但同时也会带来一些问题。在特定场景有的人会抉择敞开 SELinux 以换取更好的兼容性。 在GreatSQL的装置手册里，就有敞开 SELinux 这一步。 #敞开selinux$ setenforce 0$ sed -i '/^SELINUX=/c'SELINUX=disabled /etc/selinux/config不禁让人好奇，这个 SELinux 平安模块，如果不敞开会产生什么问题，在应用时有哪些须要留神的中央。于是我特意尝试了一下，看看会呈现哪些问题。 问题发现为了发现问题，我特意抉择在用户目录（/root）下载、加压 GreatSQL 二进制压缩包，而后再挪动到指定目录应用。 cd /rootwegt https://***.***/greatsql.tar.gztar -xvf greatsql.tar.gzmv /root/greatsql /usr/local/装置过程一切顺利，数据库失常启动了，然而在配置 systemd 过程守护的时候呈现了问题。 greatsql.service文件： vim /usr/lib/systemd/system/greatsql.service[Unit]Description=GreatSQL ServerAfter=network.targetAfter=syslog.target[Install]WantedBy=multi-user.target[Service]User=greatsqlGroup=greatsql# Have mysqld write its state to the systemd notify socketType=notify# Disable service start and stop timeout logic of systemd for mysqld service.TimeoutSec=0# Start main serviceExecStart=/usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf $MYSQLD_OPTS # Use this to switch malloc implementation#EnvironmentFile=-/etc/sysconfig/mysql# Sets open_files_limitLimitNOFILE = 10000Restart=on-failureRestartPreventExitStatus=1# Set environment variable MYSQLD_PARENT_PID. This is required for restart.Environment=MYSQLD_PARENT_PID=1PrivateTmp=false用 systemctl start greatsql 启动数据库的时候报错以下谬误。 ...

前言索引优化这四个字说实话我认为其实挺难了解的。看到这四个字我脑门上是：？？？？ 索引还要优化吗？调优SQL一般来说不就是看它有没有走索引，没走索引给它加上索引就好了吗？ 嗯，所以你是怎么给它加索引的？ 看SQL应该怎么走索引撒！ 那SQL是怎么走索引的呢？又是怎么判断这条SQL会不会走索引呢？ 我：…, 咱明天就来剖析剖析！ 要是你还不理解MySQL底层的数据结构，倡议你先看看MySQL数据结构最左前缀法令咱们个别要优化的都是简单SQL,而简单SQL个别走的都是联结索引，说到联结索引的匹配规定，就逃不开这个：最左前缀法令 什么是最左前缀法令？最左前缀法令即为：索引的匹配从最右边的字段开始，匹配胜利能力往右持续匹配下一个字段。 不了解？没关系，咱们先来看看这个联结索引：name_age_position 联结索引是以三个字段name,age,position组成，并且创立该索引时字段程序为name、age、positon。 那么该索引就会以这样的形式排序（索引就是排好序的高效的数据结构） name字段从小到大排序name字段的值雷同时，age字段从小到大排序age字段的值雷同时，postion字段从小到大排序如上图所示，从zhangsan18到zhangsan100是程序的，而name都为zhangsan18的三个结点中，age又是从小到大排序，age雷同时position也是从小到大排序。 请你肯定要把这个数据结构牢记于心，忘了就看看当初通过这个联结索引再来解析一下最左前缀法令：在索引匹配时，必须先可能匹配name字段(最右边的)，能力持续匹配age字段(下一个), age字段匹配胜利了能力匹配position字段。 为什么？ 因为联结索引中的最右边字段是有序的，而第二个字段是在第一个字段雷同的状况下有序，第三个字段是在第二个字段雷同的状况下有序。 如果你想要用age字段间接在联结索引中查找数据，对不起，找不到，因为age字段中联结索引中是无序的。 你把第一行name字段遮掉看看age字段的状况：18,18,20,15,25,16,33。无序的对吧。 还是有点蛊惑？没关系，咱们再来通过案例剖析剖析。 什么是走索引？就是看索引会不会起到作用，可能起到作用就叫走了索引，没有起到作用就叫没走索引。案例剖析表构造： CREATE TABLE `employees` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(24) NOT NULL DEFAULT '' COMMENT '姓名', `age` int(11) NOT NULL DEFAULT '0' COMMENT '年龄', `position` varchar(20) NOT NULL DEFAULT '' COMMENT '职位', `hire_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '入职时\r\n间', PRIMARY KEY (`id`), KEY `idx_name_age_position` (`name`,`age`,`position`) USING BTREE) ENGINE=InnoDB AUTO_INCREMENT=100001 DEFAULT CHARSET=utf8 COMMENT='员工记录表';sql1 ...

概述explain是MySQL中的一个关键字，能够用于模仿优化器执行SQL语句，剖析你的SQL的性能瓶颈。 应用时只需将该关键字加在sql头部，如 explain select * from employees where name = 'zhangsan'案例explain返回的后果有许多字段，咱们又当如何了解呢？ 以下有张员工记录表，联结索引：name_age_position CREATE TABLE `employees` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(24) NOT NULL DEFAULT '' COMMENT '姓名', `age` int(11) NOT NULL DEFAULT '0' COMMENT '年龄', `position` varchar(20) NOT NULL DEFAULT '' COMMENT '职位', `hire_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '入职工夫', PRIMARY KEY (`id`), KEY `idx_name_age_position` (`name`,`age`,`position`) USING BTREE) ENGINE=InnoDB AUTO_INCREMENT=100001 DEFAULT CHARSET=utf8 COMMENT='员工记录表'; 执行sql explain select * from employees where name = 'zhangsan'explain后果 ...

前言在日常工作中，MySQL无外乎是咱们最相熟的数据库了，了解MySQL的数据结构和索引特点，可能帮忙咱们写出查问效率更高，逻辑更为明确的SQL，也能给咱们设计表构造时带来思路。 数据结构索引对于MySQL的优化咱们第一想到的总是索引，那么，什么是索引呢？ 索引是一种帮忙MySQL高效获取数据的排好序的数据结构，如果是你，你会选用什么样的数据结构作为MySQL的底层存储？ 如何抉择数据结构基于咱们日常应用MySQl的状况，能够大抵总结一下此数据结构的特点 查问效率高反对数据量大，在千万级以上数据量时也要放弃查问的稳定性对范畴查问敌对首先第一点：查问效率高，在泛滥的数据结构中，查问效率最高的必须是树了。 而反对查问的树有： 二叉搜寻树红黑树B树B+树二叉搜寻树先不管它是否反对其余点，咱们晓得，平时咱们的插入数据都是主键都是自增有序的，当二叉搜寻树遇到这状况会产生什么？ 此时，二叉搜寻树进化成了链表。所以，该构造被咱们pass掉了。 红黑树简略来说红黑树是颗均衡树，当遇到某一边过长时将进行均衡，就像这样 所以它解决了进化为链表的问题，然而当数据量过大时，比方数据量达到1千万，他的树高为 2^n = 1千万，n大略是24。 也就是查问数据时，可能会有0~24次IO，时快时慢，所以这个数据结构，也不行。 B树由上可知，树的高度决定了IO的次数，也就是查问效率。那么，该如何缩小高度？ 以上的树结构每个结点都只存了一个元素，如果咱们能让一个结点存多个元素，是不是就能显著升高层高了？ 这就是B树了 插入过程如图 和二叉树比照，树的高度的确会减小，每一个结点可能寄存的元素越多，树的高度就减小的越多。 但它仍旧有些别的毛病： 范畴查问，显然，这棵树对范畴查问的确不敌对，比方从3到7，还是得一次一次的查出来。在MySQL中，每行记录可不是只有1,2,3这种数字，还有很多其余的数据，一个结点的空间是无限的，每行记录越大，一个结点能寄存的元素(记录)就越少，数据结构相似这样 针对于以上两个问题，咱们来看看B+树又是怎么解决的？ B+Tree先来看看B+Tree的构造 B+tree相比于B-tree，有三个不同点： 叶子结点有相互指向的指针，便于进行范畴查问，比方3-7，首先定位到3，而后从左往右遍历即可叶子结点寄存所有数据，其余非叶子节点冗余叶子结点的地位(用于定位)，比方图中的4非叶子结点不存放数据，只寄存索引，如此一个结点就寄存更多的元素，就像这样 在MySQL中，一个结点的默认大小为16kb，指向其余结点的指针为6b,假如咱们以主键(long类型)为索引，那么主键占用的空间为8b 如此，一个非叶子结点能够寄存的元素个数为：16kb/(6b+8b)=1170 假如每行记录的大小为1kb，则一个叶子结点能够放16kb/1kb=16行记录 假如一颗3层的B+树，那么能够存放数据的行数为1170 1170 16 = 2.2千万 每行记录越小，则能够存放数据的行数越大，假如一行数据只有512b，则3层B+树能够寄存4.4千万数据，这也是为什么垂直分表可能进步查问效率的起因之一。综合以上状况，千万级数据量的表，查问数据也最多只有经验3次IO，而且根节点其实常驻在MySQL内存中。 HashHash也是MySQL中的一种数据结构 它的特点如下： 对索引的key进行一次hash计算就能够定位出数据存储的地位仅能满足 “=”，“IN”不反对范畴查问Hash抵触存储引擎在日常工作中，罕用的存储引擎有两种，InnodDB和MyISAM InnoDB汇集索引：叶子结点存储残缺的数据，主键索引即数据文件 磁盘上以两个文件存储表信息 table.frm: 表构造文件table.idb: 索引数据文件比非汇集索引效率更高：缩小了一次回表MyISAM非汇集索引：叶子结点存储的是指向数据的磁盘地址，索引和数据拆散。 磁盘上以三个文件存储表信息 table.frm: 表构造文件息table.MYI: 索引文件tbale.MYD: 数据文件二级索引在开发时，咱们不仅会通过主键查问数据，也会通过其余字段查问数据，如username,此时也应该给username字段建设索引。 此类除主键索引之外的索引，称为二级索引或者辅助索引。 二级索引同样是颗B+树，与主键索引不同的是：二级索引的叶子节点并非存储残缺的数据，而是存储主键。 为什么二级索引存储的是主键而非残缺数据？ 一致性：如果二级索引也存储残缺的数据，那么批改数据后就会很麻烦，须要批改主键索引又要批改二级索引。节俭磁盘空间二级索引又分为一般索引和惟一索引。一般索引中比拟特地的是联结索引，这也是平时开发打交道最多的索引。 联结索引联结索引指由多个字段组成的索引，如name+age+positon形成这样一颗索引树，索引同样是从小到大排列，先排序第一个字段，第一个字段雷同时排序第二个字段，以此类推。 基本上，大部分的索引优化准则都是基于联结索引建表时如果不设置主键会怎么？下面说到，MySQL会以主键形成一颗索引树存储数据记录，反过来讲：数据的存储依赖于主键索引。那么，如果咱们不设置主键会产生什么？ 首先，MySQL会找表中是否有惟一索引，如果有，就以惟一索引作为主键。如果没有惟一索引，那么将增加暗藏字段rowid作为主键。查找算法以下图索引树为例，查找id=30的行记录的过程是怎么的呢？ 图中空白局部存储的为下个结点的磁盘地址，如根结点[15-56]之间的空白点存储的就是指向最右边子结点的磁盘地址。 1、首先，将根结点加载到内存中(后续根结点常驻内存) ...

从管易云到MySQL通过接口配置买通数据 数据源平台:管易云管易云是金蝶旗下专一提供电商企业管理软件服务的子品牌，先后开发了C-ERP、EC-OMS、EC-WMS、E店管家、BBC、B2B、B2C商城网站建设等产品和服务，涵盖电商业务全流程。写入指标:MySQLmysql是一个关系数据库管理系统（RDBMS），所谓的关系型数据库，是建设在关系模型根底上的数据库，借助于汇合代数等数学概念和办法来解决数据库中的数据。配置集成计划在轻易云平台进行集成计划的配置时，为了实现疾速搭建，轻易云平台还提供了现有的市场计划进行复制参考。用户能够在创立集成计划的时候在第四步抉择援用市场计划，参考市场支流所进行的字段配置实现集成计划的自定义化疾速配置，即使是第一次应用轻易云平台的用户也能轻松搭建属于本人的数据同步计划。向导式配置，让配置更加清晰，首先确定该方计划的对接内容，第二歩获取筛选数据源平台的数据，第三步数据源与写入指标造成映射关系配置。实现配置后一键启用 管易云接口明细API：_gy.erp.items.get_NAME：_商品查问_METHOD：_POST_申请参数接口字段字段名称预设值形容start_date批改工夫开始段2021-01-16 10:42:21 end_date批改工夫完结段2021-02-16 10:42:21 code商品代码 page_size分页大小{{PAGINATION_PAGE_SIZE}}默认为10page_no页号{{PAGINATION_START_PAGE}}默认1响应参数接口字段字段名称预设值形容create_date创立工夫 modify_date批改工夫 combine是否为组合商品 del是否已停用 length长 width宽 height高 simple_name商品简称 category_code分类代码 category_name分类名称 supplier_code供应商代码 item_unit_code商品单位代码 item_unit_name商品单位名称 pic_url图片地址 shelf_life保质期 warning_days预警天数 combine_items组合明细 custom_attr自定义属性 item_add_attribute商品附加属性 item_brand_code品牌代码 item_brand_name品牌名称 skussku skus.id规格ID skus.code规格代码 skus.name规格名称 skus.note备注 skus.weight分量 skus.volume体积 skus.package_point打包积分 skus.sales_point销售积分 skus.sales_price规范售价 skus.purchase_price规范进价 skus.agent_price代理售价 skus.cost_price成本价 skus.stock_status_code库存状态代码 skus.tax_no税号 skus.tax_rate税率 skus.origin_area原产地 skus.supplier_outerid供应商货号 skus.bar_code商品条码 MySQL接口明细调用接口：_execute_接口名称：_EXECUTE语句_办法：_POST_申请参数字段字段名称类型配置值header表头object header.no编码string{{skus_code}}header.name名称string{{skus_name}}header.brand品牌字表object header.brand.inserted_id主表主键IDstringinserted_idheader.brand.name品牌string{{item_brand_name}}header.brand.custom_attr定制属性arraycustom_attrheader.brand.custom_attr.inserted_id主表主键IDstringinserted_idheader.brand.custom_attr.color色彩string{{custom_attr.color}}header.brand.custom_attr.insertinsertobject header.brand.custom_attr.insert.header插入表头stringINSERT INTO base_goods (no, name ) VALUES ( :no, :name )header.brand.custom_attr.insert.brand插入品牌stringINSERT INTO base_goods_brand (goods_id, name ) VALUES ( :inserted_id, :name )header.brand.custom_attr.insert.custom_attr定制属性stringINSERT INTO base_goods_custom_attr (goods_id, color ) VALUES ( :inserted_id, :color )header.brand.custom_attr.insert.updateupdateobject header.brand.custom_attr.insert.deletedeleteobject header.brand.custom_attr.insert.executeexecuteobject 零碎对接总览全新的API数据集成模式，赋能企业业务翻新 传统企业集成次要采纳点对点或ESB集成形式，基于全新API策略中台的API新型集成形式通过解耦系统资源，升高零碎间对接难度，实现疾速业务需要响应，晋升对接效率，助力企业满足疾速业务交付需要，实现业务翻新。通过构建API生态，助力能力凋谢与共享 基于API策略中台梳理并整合外部API资源与IT资产，可实现外部资源共享，满足外部开发人员资源应用需要，例如：MySQL与管易云之间数据集成；并将API资源对外可控凋谢，打造面向开发者的生态服务，为您买通本身和上下游合作伙伴，发明共赢价值链。发展API策略中台，重塑IT 帮忙您基于外部资源构建不同业务能力核心，打造企业对立API策略中台，赋能企业倒退，实现对业务频繁变动的疾速响应。同时您在能力核心根底上构建新业务时，无需从“零”组建各业务模块，晋升开发效率，重塑IT组织及交付能力。 ...