Mysql

在很多人眼中，「开源」是一个时尚且有情怀的词汇，始终随同有理想主义色调，因而不少公司开始给本人贴上“开源”标签。但一个优良的开源我的项目远远不止是简略的公开源代码，而是须要将其当作公司策略进行贯彻，能力架设起颠扑不破的信赖桥梁。 PingCAP 从第一行代码开源，六年里积攒了一些教训和教训，在《开源常识科普》栏目中，咱们将与大家分享和交换在开源成长门路中的思考和感触，以及参加开源我的项目的正确姿态。本期话题就从开源的根底——开源许可证开始，心愿对大家理解开源、参加开源有肯定帮忙。 近年来，开源正在变得越来越火，咱们常常会看到 “某企业发表开源”、“某开源大会召开”、“某开源我的项目取得融资”。集体开发者与企业比以往任何时候都更违心参加到开源我的项目的建设和奉献中，开源在国内 IT 畛域取得了前所未有的热度，也取得了产业界和投资圈的宽泛关注。但总有些人听到开源一词时，就会误以为 “开源软件是收费的，因而我能够不受限制地随便应用”。在开源诞生之初，自由软件是过后的支流提法，回顾开源的发展史，从自由软件到开源静止实现了十分大的逾越，前者更多的是一种精力的提倡，而后者着眼于软件的协同凋谢，因而会有十分谨严的开源许可证的规定和限度。开源软件能走到明天的倒退水平，就是因为有了这么一套听从开源精力的规定体系，才可能衰弱倒退。开源精力的载体之一就是开源许可证，明天咱们就来扒一扒开源许可证与开源的关系，以及它背地折射出的问题。 什么是开源许可证？（“Open Source License”）首先须要明确的是，开源软件源代码的著作权既没有被放弃也没有过期，其批改和发行等依然要受到著作权法或者开源软件许可证的制约。 咱们接触到的开源软件个别都有对应的开源许可证（Open Source License）对软件的应用、复制、批改和再公布等进行限度。许可证即受权条款，开源许可证就是保障开源软件这些限度的法律文件，目标在于标准受著作权爱护的软件的应用或者散发行为。开源许可证是开源软件生态系统的根底，能够促成软件的协同开发。 常见开源许可证常见的开源许可证次要有 Apache、MIT、BSD、GPL、LGPL、MPL、SSPL 等，能够大抵分为两大类：宽松自由软件许可协定（“Permissive free software licence”）和著佐权许可证（“copyleft license”）。 Permissive free software licence 是一种对软件的应用、批改、流传等形式采纳最低限度的自由软件许可协定条款类型。这种类型的软件许可协定将不保障原作品的派生作品会持续放弃与原作品完全相同的相干限度条件，从而为原作品的自在应用、批改和流传等提供更大的空间。而 Copyleft License 是在无限空间内的自在应用、批改和流传，且不得违反原作品的限度条款。如果一款软件应用 Copyleft 类型许可协定规定软件不得用于商业目标，且不得闭源，那么后续的衍生子软件也必须得遵循该条款。两者最大的差异在于：在软件被批改并再发行时， Copyleft License 依然强制要求公开源代码（衍生软件须要开源），而 Permissive free software licence 不要求公开源代码（衍生软件能够变为专有软件）。其中，Apache、MIT、BSD 都是宽松许可证，GPL 是典型的强著佐权（copyleft ）许可证，LGPL、MPL 是弱著佐权（copyleft ）许可证。SSPL 则是近年来 MongoDB 创立的一个新许可证，存在较大争议，凋谢源代码促进会 OSI 甚至认为 SSPL 就不是开源许可协定。此外，还有一类是 Creative Commons（CC）常识共享协定。严格意义上说该协定并不能说是真正的开源协定，它们大多是被应用于设计类的工程上。CC 协定品种繁多，每一种都受权特定的权力。大多数的比拟严格的 CC 协定会申明 “署名权，非商业用途，禁止衍生” 条款，这意味着你能够自在的分享这个作品，但你不能扭转它和对其免费，而且必须申明作品的归属。这个许可协定十分的有用，它能够让你的作品流传进来，但又能够对作品的应用保留局部或齐全的管制。起码限度的 CC 协定类型当属 “署名” 协定，这意味着只有人们能保护你的声誉，他们对你的作品怎么应用都行。起源：https://moqod.com/mobile-web-... 能够看出，不同许可证之间的差别十分大，你可能会困惑，搞得这么简单的目标是什么呢？这就不得不从开源的历史讲起了。开源这个词最后其实是指开源软件（OSS）。开源软件是源代码能够任意获取的计算机软件，任何人都能查看、批改和散发他们认为适合的代码。在开源畛域中，存在着两大阵营：FSF（Free Software Foundation，自由软件基金会) 和 OSI（Open Source Initiative，凋谢源代码促进会），他们对开源有着不同的理念。FSF 是开源泰斗 RMS 创建的重要的开源软件基金会 (1985/10/04), FSF 创建之初次要是为了筹集资金来建设 GNU 的内核 Hurd 我的项目及工具链，尽管 GNU 我的项目自身没有实现，然而该过程中发明出的大量软件工具，日后成为了 GNU/Linux 的重要组成部分。为了贯彻 RMS 对 “自在” 和 “开源” 的了解，FSF 建设了开源畛域的第一个 “copyleft” 属性的许可证 - GPL (GNU Public License) 。OSI 由开源界泰斗 Bruce Perens 和 Eric S. Raymond (ESR) 在 1998 年组建，目标是在原教旨主义开源 (最早的开源静止发动和推动者们) 与软件工业/商业之间强烈矛盾中，寻求更均衡的体系和治理机制。OSI 组织批准过的许可大略有 80 种，包含 Apache License v2、GPL v2、MIT/BSD 等。FSF 与 OSI 是推广和保护开源秩序的非盈利组织，保护着 “开源” 的定义以及次要的开源软件协定递交、探讨与审核。只有条款被审核通过是合乎凋谢源代码定义的，就能够称之为开放源码受权条款，采纳开放源码条款分布受权的软件即是开放源码软件，若一份商业产品中蕴含有开放源码软件，其包装上能够标上开放源码促进会的证实标章，意识这个标章的消费者就能够晓得产品中有应用到开放源码软件，进而因为开放源码软件特有的长处而购买产品。 ...

作者简介 韩明聪 ，TiDB Contributor，上海交通大学 IPADS 实验室博士研究生，钻研方向为系统软件。本文次要介绍了如何在 TiDB 中应用纯 SQL 训练一个机器学习模型。 前言家喻户晓，TiDB 5.1 版本减少了很多新个性，其中有一个个性，即 ANSI SQL 99 规范中的 Common Table Expression （CTE）。一般来说，CTE 能够被用作一个 Statement 作用于长期的 View，将一个简单的 SQL 解耦，进步开发效率。然而，CTE 还有一个重要的应用形式，即 Recursive CTE，容许 CTE 援用本身，这是欠缺 SQL 性能的最初一块外围的拼图。 在 StackOverflow 中有过这样一个探讨 “Is SQL or even TSQL Turing Complete” ，其中点赞最多的回复中提到这样一句话： “ In this set of slides Andrew Gierth proves that with CTE and Windowing SQL is Turing Complete, by constructing a cyclic tag system , which has been proved to be Turing Complete. The CTE feature is the important part however – it allows you to create named sub-expressions that can refer to themselves, and thereby recursively solve problems. ” ...

MySQL遇见GROUP BY clause and contains nonaggregated column解决办法报错如下： Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'chinese.tenant_message.id' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by问题呈现的起因： MySQL 5.7.5及以上性能依赖检测性能。如果启用了ONLY_FULL_GROUP_BY SQL模式（默认状况下），MySQL将回绝抉择列表，HAVING条件或ORDER BY列表的查问援用在GROUP BY子句中既未命名的非汇合列，也不在性能上依赖于它们。（5.7.5之前，MySQL没有检测到性能依赖关系，默认状况下不启用ONLY_FULL_GROUP_BY。无关5.7.5之前的行为的阐明，请参见“MySQL 5.6参考手册”。） 解决办法二胜利的步骤 关上 sudo vim /etc/my.cnf滚动到文件底部复制并粘贴 [mysqld]sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION 保留并退出输出模式 service mysqld stopservice mysqld start重启MySQL。 分享一份数据库的配置# For advice on how to change settings please see# http://dev.mysql.com/doc/refman/5.7/en/server-configuration-defaults.html[client]default-character-set = utf8mb4[mysql]default-character-set = utf8mb4[mysqld]character-set-client-handshake = FALSEcharacter-set-server=utf8mb4collation-server = utf8mb4_unicode_ciinit_connect='SET NAMES utf8mb4'max_connect_errors=1000innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:5G## Remove leading # and set to the amount of RAM for the most important data# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.# innodb_buffer_pool_size = 128M## Remove leading # to turn on a very important data integrity option: logging# changes to the binary log between backups.# log_bin## Remove leading # to set options mainly useful for reporting servers.# The server defaults are faster for transactions and fast SELECTs.# Adjust sizes as needed, experiment to find the optimal values.# join_buffer_size = 128M# sort_buffer_size = 2M# read_rnd_buffer_size = 2Mdatadir=/var/lib/mysqlsocket=/var/lib/mysql/mysql.sock# Disabling symbolic-links is recommended to prevent assorted security riskssymbolic-links=0log-error=/var/log/mysqld.logpid-file=/var/run/mysqld/mysqld.pidsql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION刘建集体介绍 ...

数据一致性问题假如有一个商品表goods，蕴含id、商品名称、库存字段： CREATE TABLE `goods` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(100) DEFAULT NULL, `stock` int(11) DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `idx_name` (`name`)) ENGINE=InnoDB插入数据： INSERT INTO `goods` VALUES ('1', 'iphone', '1000');A、B两个用户同时购买一件id=1的商品： t1: 用户A查问到库存量=1000；t2: 用户B查问到库存量=1000；t3: 用户A下单，将库存量批改为999；t4: 用户B下单，将库存量批改为999；此时，库存量的数据产生不统一问题。 解决办法：乐观锁和乐观锁两种计划。 乐观锁计划查问商品时，通过select...for update对该商品记录加锁，其它用户将阻塞期待拜访该记录： beginselect * from goods where id = 1 for update; //加锁update goods set stock = stock - 1 where id = 1; //下单commit因为加锁阻塞其它用户的拜访，对并发拜访不敌对。 乐观锁计划(举荐)查问商品时不加锁，在更新时，比拟mem.cur_val=db.val： 若相等，则间接用cu_val更新db；否则，从新获取mem.cur_val，再次比拟mem.cur_val=db.val；select stock from goods where id = 1; //失去mem.cur_valbegin//仅当stock=cur_val时才更新update goods set stock = stock - 1 where id = 1 and stock = cur_val；commit乐观锁因为不阻塞其它用户的拜访，并发度较高，适宜读取频繁的场景。 ...

介绍下插入缓冲(insert buffer)与两次写(double write). 插入缓冲为什么须要插入缓冲？ Innodb存储引擎中行记录是依照汇集索引维度顺序存储的，Innodb的表也称为索引表；因为行记录只能依照一个维度进行排序，所以一张表只能有一个汇集索引。在InnoDB，主键是行惟一标识，通常应用程序中行记录的插入程序是依照主键递增的程序进行插入的，因而，插入汇集索引个别是程序的，不须要磁盘的随机读取。然而对于非汇集索引叶子节点的插入不再是程序的了，次要是因为B+树的个性决定了非汇集索引插入的离散性(这里再进一步说明下，非汇集索引的根节点存的是索引列的值，它们是有序的，而根节点下的叶子节存的是主键的值，它们是无序的。又因为行记录是依照汇集索引维度顺序存储的，为了保住插入后的有序性，咱们就必须随机离散地拜访非汇集索引页以找到叶子节点的主键值)，这里就须要离散地拜访非汇集索引页，显然，随机读取是会导致插入操作性能降落。 这样，InnDB设计了Insert Buffer性能：对于非汇集索引的插入或更新操作，不是每一次直接插入到索引页中，而是先判断插入的非汇集索引页是否在缓冲池中，若在，则直接插入；若不在，则先放入到一个Insert Buffer对象中，而后再以肯定频率和状况进行Insert Buffer和辅助索引叶子节点的merge操作，这时通常能将多个插入合并到一个操作中，这就大大提高了对于非汇集索引插入的性能。 不过，Insert Buffer的应用须要同时满足两个条件： 索引是辅助索引索引不是惟一的(数据库并不去查找索引页来判断插入的记录是否惟一，如果进行了判断会有离散读的状况产生)Change BufferChange Buffer是对Insert Buffer的降级。如果没有应用Change Buffer，要对不在缓冲池里的非惟一索引页进行批改，那流程是怎么的呢？ 先把须要批改的索引页从磁盘加载到缓冲池，一次磁盘随机读操作；批改缓冲池中的页，一次内存操作；写入redo log，一次磁盘程序写操作；能够看到会呈现两磁盘操作(有一次还是随机的),一次内存操作。那如果应用了Change Buffer又是怎么的流程呢？ 在写缓冲中记录这个操作(insert的操作而非update操作)，一次内存操作；写入redo log，一次磁盘程序写操作；换句话就是：对页进行了写操作，并不会立即将磁盘页加载到缓冲池，而仅仅记录缓冲变更(buffer changes)，等将来数据被读取时，再将数据合并(merge)复原到缓冲池中的技术。写缓冲的目标是升高写操作的磁盘IO，晋升数据库性能。这里只会呈现一次磁盘的程序操作与一次内存操作，所以性能会很高。要留神的是，Change Buffer比拟适宜的业务是写多读少，或者不是写后立即读取。 Double WriteInsert Buffer对于InnoDB来说是性能上的晋升，那Double Write则是数据页可靠性的保障。来看张图： 通过memcpy函数将脏页先复制到内存中的doublewrite buffer。通过doublewrite buffer分两次，每次1MB程序写入共享表空间的物理磁盘上，而后调用fsync函数同步磁盘。实现doublewrite buffer页的写入后，再将doublewrite buffer中的页离散写入各个表空间文件中。如果第2步呈现了问题，也就是doublewrite写入失败，innodb会载入磁盘原始数据和redo日志比拟，并从新刷到doublewrite buffer。如果第3步出了问题，innodb能够从共享表空间中的doublewrite中找到该页的一个正本，将其复制到表空间文件，再利用重做日志。 参考的文章：写缓冲(change buffer)，这次彻底懂了！！！InnoDB要害个性之double write【mysql】Innodb三大个性之double write

CREATE DEFINER=root@% PROCEDURE updateMerchantOrderNo()BEGIN #Routine body goes here...declare orderstr text;declare ordernum int; /**订单个数**/declare i int default 1;declare orderno text;declare updateSql text;set orderstr = "ddd";# 数组长度 = 逗号个数select length(orderstr) - length(REPLACE(orderstr,",","")) + 1 into @ordernum;/* 执行查看订单数量*/select @ordernum;while i <= @ordernum DOset @orderno = substring_index(SUBSTRING_INDEX(orderstr,",",i), ",", -1);/*执行查看解析进去的订单号*/select @orderno;/*结构更新语句*/set @updateSql = CONCAT("UPDATE `kettle`.`orders` SET `merchant_order_no` = concat(",@orderno,",'-cancel',DATE_FORMAT(NOW(),'%h%i%s')) where `merchant_order_no` = ", @orderno);/*显示sql语句*/select @updateSql;/*执行sql语句*/update `kettle`.`orders` set `merchant_order_no` = CONCAT(@orderno,'-cancel',DATE_FORMAT(NOW(),'%h%i%s'))where `merchant_order_no` = @orderno;set i = i + 1;end while;END ...

简介： 本文次要是通过对PFS引擎的内存治理源码的浏览，解读PFS内存调配及开释原理，深刻分析其中存在的一些问题，以及一些改良思路。 一 引言MySQL Performance schema(PFS)是MySQL提供的弱小的性能监控诊断工具，提供了一种可能在运行时查看server外部执行状况的特办法。PFS通过监督server外部已注册的事件来收集信息，一个事件实践上能够是server外部任何一个执行行为或资源占用，比方一个函数调用、一个零碎调用wait、SQL查问中的解析或排序状态，或者是内存资源占用等。 PFS将采集到的性能数据存储在performance_schema存储引擎中，performance_schema存储引擎是一个内存表引擎，也就是所有收集的诊断信息都会保留在内存中。诊断信息的收集和存储都会带来肯定的额定开销，为了尽可能小的影响业务，PFS的性能和内存治理也显得十分重要了。本文次要是通过对PFS引擎的内存治理的源码的浏览，解读PFS内存调配及开释原理，深刻分析其中存在的一些问题，以及一些改良思路。本文源代码剖析基于MySQL-8.0.24版本。 二 内存治理模型PFS内存治理有几个要害特点： 内存调配以Page为单位，一个Page内能够存储多条record 系统启动时事后调配局部pages，运行期间依据须要动静增长，但page是只增不回收的模式 record的申请和开释都是无锁的 1 外围数据结构PFS_buffer_scalable_container是PFS内存治理的外围数据结构，整体构造如下图： Container中蕴含多个page，每个page都有固定个数的records，每个record对应一个事件对象，比方PFS_thread。每个page中的records数量是固定不变的，但page个数会随着负载减少而增长。 2 Allocate时Page抉择策略PFS_buffer_scalable_container是PFS内存治理的外围数据结构波及内存调配的要害数据结构如下： PFS_PAGE_SIZE // 每个page的大小, global_thread_container中默认为256PFS_PAGE_COUNT // page的最大个数，global_thread_container中默认为256class PFS_buffer_scalable_container { PFS_cacheline_atomic_size_t m_monotonic; // 枯燥递增的原子变量，用于无锁抉择page PFS_cacheline_atomic_size_t m_max_page_index; // 以后已调配的最大page index size_t m_max_page_count; // 最大page个数，超过后将不再调配新page std::atomic<array_type *> m_pages[PFS_PAGE_COUNT]; // page数组 native_mutex_t m_critical_section; // 创立新page时须要的一把锁}首先m_pages是一个数组，每个page都可能有free的records，也有可能整个page都是busy的，Mysql采纳了比较简单的策略，轮训挨个尝试每个page是否有闲暇，直到调配胜利。如果轮训所有pages仍然没有调配胜利，这个时候就会创立新的page来裁减，直到达到page数的下限。 轮训并不是每次都是从第1个page开始寻找，而是应用原子变量m_monotonic记录的地位开始查找，m_monotonic在每次在page中调配失败是加1。 外围简化代码如下： value_type *allocate(pfs_dirty_state *dirty_state) { current_page_count = m_max_page_index.m_size_t.load(); monotonic = m_monotonic.m_size_t.load(); monotonic_max = monotonic + current_page_count; while (monotonic < monotonic_max) { index = monotonic % current_page_count; array = m_pages[index].load(); pfs = array->allocate(dirty_state); if (pfs) { // 调配胜利返回 return pfs; } else { // 调配失败，尝试下一个page， // 因为m_monotonic是并发累加的，这里有可能本地monotonic变量并不是线性递增的，有可能是从1 间接变为 3或更大， // 所以以后while循环并不是严格轮训所有page，很大可能是跳着尝试，换者说这里并发拜访下大家一起轮训所有的page。 // 这个算法其实是有些问题的，会导致某些page被跳过疏忽，从而加剧扩容新page的几率，前面会详细分析。 monotonic = m_monotonic.m_size_t++; } } // 轮训所有Page后没有调配胜利，如果没有达到下限的话，开始扩容page while (current_page_count < m_max_page_count) { // 因为是并发拜访，为了防止同时去创立新page，这里有一个把同步锁，也是整个PFS内存调配惟一的锁 native_mutex_lock(&m_critical_section); // 拿锁胜利，如果array曾经不为null，阐明曾经被其它线程创立胜利 array = m_pages[current_page_count].load(); if (array == nullptr) { // 抢到了创立page的责任 m_allocator->alloc_array(array); m_pages[current_page_count].store(array); ++m_max_page_index.m_size_t; } native_mutex_unlock(&m_critical_section); // 在新的page中再次尝试调配 pfs = array->allocate(dirty_state); if (pfs) { // 调配胜利并返回 return pfs; } // 调配失败，持续尝试创立新的page直到下限 }}咱们再详细分析下轮训page策略的问题，因为m_momotonic原子变量的累加是并发的，会导致一些page被跳过轮训它，从而加剧了扩容新page的几率。 ...

MySQL5.5(不含5.5)增加或删除索引的效率很低下，具体过程如下： 首先创立一张新的长期表，表构造为通过命令alter table新定义的构造。而后把原表中数据导入到长期表。接着删除原表。最初将长期表重命名为原来的表。如果表大的话，这相过程是相当长的。InnoDB从1.0.x版本后应用Fast Index Creation(疾速索引创立)的形式，简称FIC，具体如下，创立索引：对创立索引的表加一个S锁，不会重建表。因为是S锁所以不会影响读(但会阻塞写)。删除索引：只须要更新外部实图，将辅助索引的空间标记为可用，同时删除数据库外部视图上对该表的索引定义。 须要阐明下，FIC只限定于辅助索引，对于主键的创立和删除同样须要重建一张表。

MVCC是Repeatable Read隔离级别才有的，Read Commited没有，所有RC会呈现不可反复读的问题。上面对于MVCC的细节进行下转载： InnoDB的MVCC，通过在每行记录前面保留两个暗藏的列来实现：一个保留了行的创立工夫，一个保留行的过期工夫（删除工夫），当然，这里的工夫并不是工夫戳，而是零碎版本号，每开始一个新的事务，零碎版本号就会递增。在RR隔离级别下，MVCC的操作如下： select操作。InnoDB只查找版本早于（蕴含等于）以后事务版本的数据行。能够确保事务读取的行，要么是事务开始前就已存在，或者事务本身插入或批改的记录。行的删除版本要么未定义，要么大于以后事务版本号。能够确保事务读取的行，在事务开始之前未删除。insert操作。将新插入的行保留以后版本号为行版本号。delete操作。将删除的行保留以后版本号为删除标识。update操作。变为insert和delete操作的组合，insert的行保留以后版本号为行版本号，delete则保留以后版本号到原来的行作为删除标识。转载于：mysql的MVCC（多版本并发管制）

脏读：在不同的事务下，以后事务能够读到另外事务未提交的数据。不可反复读：在第一个事务中的两次读数据之间，因为另一个事务对数据进行了批改，导致第一个事务两次读到的数据可能是不一样的。幻读：在同一事务下，间断执行两次同样的SQL语句可能导致不同的后果，第二次的SQL语句可能会返回之前不存在的行。 不可反复读与幻读都是读到了已提交的数据，不同之处在于：不可反复读是因为有另一事务对数据进行了批改或删除导致；幻读是因为有另一事务对数据进行了新增操作导致。对于不可反复读InnoDB应用MVCC解决，对于幻读应用Gap Lock解决。 上面是隔离级别与对应呈现的问题： 隔离级别脏读不可反复读幻读未提交读会会会提交读不会会会可反复读不会不会会串行化读不会不会不会注明：可反复读隔离级别下会呈现幻读的可能，但能够通过Gap Lock解决；针对不可反复读能够通过MVCC解决。

生产的数据库有很多大表，数据量十分大曾经对系统稳固产生影响。通过沟通，这些表中之前寄存每天的数据，改为只寄存每个月最初一天的数据。 上面记录一些罕用的查问大表操作语句 查看所有数据库的大小selecttable_schema as '数据库',sum(table_rows) as '记录数',sum(truncate(data_length/1024/1024/1024, 2)) as '数据容量(GB)',sum(truncate(index_length/1024/1024/1024, 2)) as '索引容量(GB)'from information_schema.tablesgroup by table_schemaorder by sum(data_length) desc, sum(index_length) desc;查看所有表的大小并排序selecttable_schema as '数据库',table_name as '表名',table_rows as '记录数',truncate(data_length/1024/1024/1024, 2) as '数据容量(GB)',truncate(index_length/1024/1024/1024, 2) as '索引容量(GB)'from information_schema.tablesorder by data_length desc, index_length desc;找到一些十分大的表，对该表进行操作 数据库表名记录数数据容量(GB)索引容量(GB)pccmdbcaf_tbyh_daily864560564404.20360.42pccmdbcaf_tbyh_jbdaily207974565259.2090.78pccmdbcaf_tbyh_jbcxqd710513371253.26237.65pccmdbrg_to_crsp_yj7321262353.8042.18

咱们晓得应用 MySQL 去存储数据，咱们须要先去建表，那么在表中去增加各个数据列，其实咱们须要给数据列指定一些属性，比如说咱们在列属性设置为容许，那就能够不搁置任何数据到这一列中。然而这会带来哪些麻烦或者是坑呢？那么带着这个问题，咱们来聊聊表属性设置为 NULL，你可能要面临很多麻烦。 为什么会有很多人用 NULL 呢？第一点，NULL 它是一个默认行为，如果你不去被动指定这个列字段是 NOT NULL，那么它就是 NULL，这其实是容许 NULL 列最常见的起因了。很多刚开始学习应用 MySQL 的同学，没有显示的去指定当前列是 NOT NULL ，那么 MySQL 会主动的设置为当前列是容许 NULL 的。 第二点，有一个很重大的误区，就是很多初学者会认为 NULL 它代表的是空，也就是 Mysql 什么都不会存储，所以应用那能够节俭存储空间， 然而实际上这是一个误区，那它是会占用存储空间的。 第三点，NULL 属性十分不便，SQL 语句或者代码不须要额定的填充或判断。这个说法看起来十分正当，咱们在操作数据时，如果某一列是空值，那么无论是 SQL 语句还是代码，咱们都不须要去思考它。 然而即便是有这么多起因，这么多人应用容许 NULL 的属性列，咱们仿佛还是会常常听到，那么应用 NULL 列并不好，那么咱们到底应该去怎么做抉择呢？也就是去应该听谁的呢？ 咱们当然不能仅凭据说去认证哪种抉择会更好，也不能认为应用的人多就是对的。那么为了搞清楚这个问题，咱们能够看看官网对容许 NULL 列的一个形容。 看看 MySQL 官网对 NULL 列的形容在 MySQL 的官网上能够看到如下的解释： NULL columns require additional space in the rowto record whether their values areNULL.For MyISAM tables, each NULL columntakes one bit extra, rounded up to thenearest byte.翻译过去就是：MySQL 难以优化援用可空列的一个查问，它会使索、引索引统计和值更加简单。可空的列须要更多的存储空间，还须要 MySQL 外部进行非凡解决。可空列被索引之后，每条记录都须要一个额定的字节，它还会导致像 MySAM 中固定大小的索引变成可变大小的索引。 ...

行锁的三种算法 Record Lock：单个记录上的锁Gap Lock:间隙锁，锁定一个范畴，但不蕴含记录自身Next-Key Lock：Gap Lock+Record Lock，锁定一个范畴，并且锁定记录自身。采纳Next-Key Lock的锁定技术称为Next-Key Locking。它是为了解决幻读，如果一个索引有10,11,13,20这几个值，采纳Next-Key Locking后，上锁的区间为：(-∞，10)[10,11)[11,13)[13,20)[20,+∞) 咱们来看下Next-Key Lock在列为惟一索引与辅助索引下的不同表现形式，先看惟一索引：如果列是惟一索引，Next-Key Lock会被优化，并降级为Record Lock，也就是仅锁住索引自身而不是范畴。 如果是辅助索引就须要好好剖析下了，咱们看上面的示例： create table z(a int,b int,primary key(a),key(b));insert into z select 1,1;insert into z select 3,1;insert into z select 5,3;insert into z select 7,6;insert into z select 10,8;表有两列，a为惟一索引，b为辅助索引。接下来执行上面sql:select * from z where b=3 for update;因为a上是惟一索引，所以会在a=5的索引上加Recork lock；而b是辅助索引，其上加的是Next-Key Lock，锁定的范畴是(1,3)，还有一点须要留神的是,InnoDB还会对辅助索引下一个健值加上gap lock，即还有一个辅助索引范畴为(3,6)的锁。因而上面的语句都会被阻塞： select * from z where a=5 lock in share mode;insert into z select 4,2;insert into z select 6,5;剖析：因为a=5上曾经加了行锁，所有第一条SQL会阻塞；因为2,5都在(1,3)与(3,6)范畴里，所以第二条与第三条同样会被阻塞。 ...

在InnoDB外在构造中，对每个含有自增长的表都有一个自增长计数器，当进行插入操作时，这个计数器会被初始化，执行如下语句失去计数器的值： select max(auto_inc_col) from t from update插入操作会根据这个自增长计数器值加1赋给自增长列，这个实现形式叫AUTO-INC Locking。此锁是采纳一种非凡的表锁机制，为了进步插入的性能，锁不是在一个事务实现后才开释，而是在实现对自增长值插入的SQL语句后立刻开释。但对于相似insert...select的插入则须要期待另一个事务完结，这样性能就降落了。在版本mysql.5.1.22开始，InnDB提供了一种经量级互斥量的自增长实现机制以进步自增长值的插入性能，innodb_autoinc_lock_mode参数能够配置应用锁还是互斥量。 实践上mysql主键会用完，如果是int类型其最大值为4294967295;bigint则为18446744073709551615,这两个数据曾经很大了，不过不太可能会增长到那个时候，因为早就要进行分库分表了。 本文来自于《mysql技术底细 InnoDB存储引擎》一书

一致性非锁定读一，定义一致性非锁定读指InnoDB引擎通过行多版本控制的形式(也就是多版本并发管制)来读取以后执行工夫数据库中行的数据。如果读取的行正在执行DELETE或UPDATE操作，这时读取操作不会因而去期待行上锁(对应X锁)的开释，而是会去读取行的一个快照数据。 快照数据：是指该行的之前版本数据，它是通过undo段实现的，次要用在事务中回滚数据。另外读取快照数据不须要上锁。多版本并发管制：快照数据其实就是以后行数据之前的历史版本，一个行记录可能有不止一个快照数据，由此而来的并发管制称为多版本并发管制。二，不同隔离级别对一致性非锁定读的不同体现在事务隔离级别READ COMMITTED(下简称RC)和REPEATABLE READ(下简称RR)下,InnoDB应用非一致性锁定读。 在RC级别下，对于快照数据，非一致性读总是读取被锁定行的最新一份快照数据。在RR级别下，对于快照数据，非一致性读总是读取本事务开始时的行数据版本。三，示例 首先在以后数据库连贯会话A中执行如下SQL：session A mysql>BEGIN;query OK,0 rows affected(0.00 sec)mysql>select * from parent where id = 1;+----+| id |+----+| 1 |+----+1 row in set (0.00 sec)会话A中已通过显式开启了一个事务，并读取id为1的数据，但事务没没有完结。与此同时，用户再开启另一个会话B，操作如下： mysql>BEGIN;query OK,0 rows affected (0.00 sec);mysql>update parent set id=3 where id=1;query ok, 1 row affectedRows matched :1 Changed : 1 Warning:0同样会话B的事务并没有提交，因为会话B执行的是一个批改执行所以id=1的行加了X锁。如果其它会话再次读取id为1的记录，在RC与RR隔离级别下会应用非锁定的一致性读。这个时候会话A在上次未提交的事务里再次读取id为1的操作，不论是RC还是RR都能够查到id=1的记录： mysql>select * from parent where id=1;+----+| id |+----+| 1 |+----+1 row in set (0.00 sec)分RC与RR两种级别进行剖析： RC总是读取被锁定行的最新一份数据，也就是最新的一个版本，因为以后id=1的数据只被批改了1次，只有一个版本，所以RC下读到了id=1的版本。RR总是读取事务开始时的行数据版本，同样因为id=1只有一个版本，这个版本也是事务开始时的那个版本，所以RR下也读到了id=1的版本这里要留神的是，只管RC与RR都读到了id=1的数据，但它们读到的起因是不同的。为了进一步看到差别，咱们将会话B的事务进行提交，而后用RC隔离级别下在会话A中再次运行如下查问： mysql>select @@tx_isolation;@@tx_isolation:READ-COMMITTED;1 row in set (0.00 sec)mysql>select * from parent where id=1;empty set (0.00 sec)再将隔离级别换成RR： ...

前言： 上篇文章介绍了 mydumper 备份工具的应用办法，文中有提到 mydumper 和 myloader 是一对互相的命令，即 mydumper 负责备份（导出），myloader 负责复原（导入）。那么 myloader 又该如何应用呢？本篇文章咱们一起来看下。 1. myloader 介绍myloader 是与 mydumper 工具配合应用的多线程备份复原工具，能够间接以 mydumper 输入文件为输出，复原备份数据。次要用于将 dump 进去的 sql 文件以并行的形式进行复原。 执行 myloader --help 能够查看帮忙信息，同样的，咱们来看下 myloader 相干参数： 参考官网介绍，以下简要阐明局部罕用的参数。 参数名缩写含意--user-u应用的用户名--pasword-p连贯所用的用户明码--host-hMySQL 服务端地址--port-PMySQL 端口号--threads-t开启的线程数，默认是4--directory-d指定待复原的备份目录--queries-per-transaction-q每次事务执行的查问数量，默认是1000--overwrite-tables-o如果要复原的表存在，则先drop掉该表--database-B须要还原到哪个数据库（指标数据库）--source-db-s抉择被还原的数据库（源数据库）--enable-binlog-e在复原时开启binlog咱们晓得，myloader 也是多线程的，面对 mydumper 备份进去的那么多文件，复原的时候是如何程序执行的呢？各个线程是如何工作的？myloader 具体工作流程可参考下图： 即首先会创立一个主线程，主线程负责主逻辑，子线程为 worker 线程，执行具体复原数据工作，子线程执行实现后再由主线程创立函数、存储过程、事件及视图、触发器这些对象。 2. myloader 复原示例咱们以上篇文章备份出的文件为例，来看下如何用 myloader 进行复原： # 复原备份文件中的全副 若表已存在则先删除myloader -u root -p 123456 -o -d /backups/all3# 从全备中复原指定库myloader -u root -p 123456 -s db1 -o -d /backups/all3# 将某个数据库备份还原到另一个数据库中（指标库不存在则会新建）myloader -u root -p 123456 -B recover_db1 -s db1 -o -d /backups/all3myloader -u root -p 123456 -B recover_db1 -o -d /backups/db1# 复原时开启binlog（有备库的时候须要开启）myloader -u root -p 123456 -e -o -d /backups/db1# 无奈间接还原单表 只能找到单表的sql文件 进入命令行source 执行source db1.tb1-schema.sql 还原表构造source db1.tb1.sql 还原表数据能够看到应用 myloader 复原数据还是很不便的，并且有多个参数可选，复原场景也更加灵便。比方咱们能够从全备中复原出单个库，或者将备份复原到一个新库中等等，这些场景根本能笼罩日常复原需要。尽管不反对单表复原，但咱们能够到文件夹中轻松找到该表的建表及插数据的 sql 脚本，进入 mysql 命令行中再执行单个脚本也能实现复原单表的需要。 ...

为什么要有锁？反对对共享资源进行并发拜访，提供数据的完整性和一致性。 InnoDB个别会在哪些地方用到锁？InnoDB除了在行级别上对表数据上锁外，还会在缓冲池中的LRU列表应用锁。 为什么要将锁进一步细化？锁能够应答并发问题，但对于热点数据，还须要将锁细化为读锁与写锁以应答更高的并发。 其它对于MyISAM引擎，其锁是表锁设置，并发状况下读是没有问题的。所以针对于只读利用，底层可选用MyISAM而非InnoDB以取得更高性能。 InnoDB锁的类型共享锁：S Lock，容许事务读一行数据。排他锁：X Lock，容许事务删除或更新一行数据。意向锁：Intention Lock，容许事务在行级上的锁和表级上的锁同时存在，意向锁将锁定对 象分为多个粒度，意向锁意为着事务心愿在更细粒度上进行加锁。动向共享锁：IS Lock，事务想要取得一张表中某几行的共享锁。动向排他锁：IX Lock，事务想要取得一张表中某几行的排他锁。 意向锁应用举例若将上锁的对象看成一棵树，那么对最上层的对象上锁，也就是对最细粒度的对象上锁，那么首先须要对粗粒度的对象上锁。例如，如果须要对页上的记录R进行上X锁，那么别离须要对数据A，表，页上意向锁IX，最初对记录R上X锁。 InnoDB各种锁的兼容性 ISIXSXIX兼容兼容兼容不兼容IS兼容兼容不兼容不兼容S兼容不兼容兼容不兼容X不兼容不兼容不兼容不兼容

大家好，我是大彬~ 明天给大家分享MySQL常考的面试题，看看你们能答对多少。 本期MySQL面试题的目录如下： 事务的四大个性？事务隔离级别有哪些？索引 什么是索引？索引的优缺点？索引的作用？什么状况下须要建索引？什么状况下不建索引？索引的数据结构Hash索引和B+树索引的区别？为什么B+树比B树更适宜实现数据库索引？索引有什么分类？什么是最左匹配准则？什么是汇集索引？什么是笼罩索引？索引的设计准则？索引什么时候会生效？什么是前缀索引？常见的存储引擎有哪些？MyISAM和InnoDB的区别？MVCC 实现原理？快照读和以后读共享锁和排他锁大表怎么优化？bin log/redo log/undo logbin log和redo log有什么区别？讲一下MySQL架构？分库分表什么是分区表？分区表类型查问语句执行流程？更新语句执行过程？exist和in的区别？truncate、delete与drop区别？having和where的区别？什么是MySQL主从同步？为什么要做主从同步？乐观锁和乐观锁是什么？用过processlist吗？事务的四大个性？事务个性ACID：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。 原子性是指事务蕴含的所有操作要么全副胜利，要么全副失败回滚。一致性是指一个事务执行之前和执行之后都必须处于一致性状态。比方a与b账户共有1000块，两人之间转账之后无论胜利还是失败，它们的账户总和还是1000。隔离性。跟隔离级别相干，如read committed，一个事务只能读到曾经提交的批改。持久性是指一个事务一旦被提交了，那么对数据库中的数据的扭转就是永久性的，即使是在数据库系统遇到故障的状况下也不会失落提交事务的操作。事务隔离级别有哪些？先理解下几个概念：脏读、不可反复读、幻读。 脏读是指在一个事务处理过程里读取了另一个未提交的事务中的数据。不可反复读是指在对于数据库中的某行记录，一个事务范畴内屡次查问却返回了不同的数据值，这是因为在查问距离，另一个事务批改了数据并提交了。幻读是当某个事务在读取某个范畴内的记录时，另外一个事务又在该范畴内插入了新的记录，当之前的事务再次读取该范畴的记录时，会产生幻行，就像产生幻觉一样，这就是产生了幻读。不可反复读和脏读的区别是，脏读是某一事务读取了另一个事务未提交的脏数据，而不可反复读则是读取了前一事务提交的数据。 幻读和不可反复读都是读取了另一条曾经提交的事务，不同的是不可反复读的重点是批改，幻读的重点在于新增或者删除。 事务隔离就是为了解决下面提到的脏读、不可反复读、幻读这几个问题。 MySQL数据库为咱们提供的四种隔离级别： Serializable (串行化)：通过强制事务排序，使之不可能互相抵触，从而解决幻读问题。Repeatable read (可反复读)：MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行，解决了不可反复读的问题。Read committed (读已提交)：一个事务只能看见曾经提交事务所做的扭转。可防止脏读的产生。Read uncommitted (读未提交)：所有事务都能够看到其余未提交事务的执行后果。查看隔离级别： select @@transaction_isolation;设置隔离级别： set session transaction isolation level read uncommitted;索引什么是索引？索引是存储引擎用于进步数据库表的访问速度的一种数据结构。 索引的优缺点？长处： 放慢数据查找的速度为用来排序或者是分组的字段增加索引，能够放慢分组和排序的速度放慢表与表之间的连贯毛病： 建设索引须要占用物理空间会升高表的增删改的效率，因为每次对表记录进行增删改，须要进行动静保护索引，导致增删改工夫变长索引的作用？数据是存储在磁盘上的，查问数据时，如果没有索引，会加载所有的数据到内存，顺次进行检索，读取磁盘次数较多。有了索引，就不须要加载所有数据，因为B+树的高度个别在2-4层，最多只须要读取2-4次磁盘，查问速度大大晋升。 什么状况下须要建索引？常常用于查问的字段常常用于连贯的字段建设索引，能够放慢连贯的速度常常须要排序的字段建设索引，因为索引曾经排好序，能够放慢排序查问速度什么状况下不建索引？where条件中用不到的字段不适宜建设索引表记录较少须要常常增删改参加列计算的列不适宜建索引区分度不高的字段不适宜建设索引，如性别等索引的数据结构索引的数据结构次要有B+树和哈希表，对应的索引别离为B+树索引和哈希索引。InnoDB引擎的索引类型有B+树索引和哈希索引，默认的索引类型为B+树索引。 B+树索引 B+ 树是基于B 树和叶子节点程序拜访指针进行实现，它具备B树的平衡性，并且通过程序拜访指针来进步区间查问的性能。 在 B+ 树中，节点中的 key 从左到右递增排列，如果某个指针的左右相邻 key 别离是 keyi 和 keyi+1，则该指针指向节点的所有 key 大于等于 keyi 且小于等于 keyi+1。 进行查找操作时，首先在根节点进行二分查找，找到key所在的指针，而后递归地在指针所指向的节点进行查找。直到查找到叶子节点，而后在叶子节点上进行二分查找，找出key所对应的数据项。 MySQL 数据库应用最多的索引类型是BTREE索引，底层基于B+树数据结构来实现。 mysql> show index from blog\G;*************************** 1. row *************************** Table: blog Non_unique: 0 Key_name: PRIMARY Seq_in_index: 1 Column_name: blog_id Collation: A Cardinality: 4 Sub_part: NULL Packed: NULL Null: Index_type: BTREE Comment:Index_comment: Visible: YES Expression: NULL哈希索引 ...

DDL 语句和 DML 语句用DDL定义数据库用DDL保护数据库应用DML新增和更新表数据应用DML删除表DDL 定义数据库数据定义语言（Data Definition Language，DDL）是一种用于形容数据库所需存储的事实世界实体的专门语言， 其次要工作是用于定义和保护数据库以及数据表构造。 创立数据库语句 CREATE DATABASE 数据库名删除数据库语句 DROP DATABASE 数据库名查看数据库 SHOW DATABASES创立库 -> 表 - >列 创立数据库语句CREATE TABLE 表名( column_name(字段名) date_type(字段数据类型) default_value(默认值) (数据完整性束缚), );示范: CREATE TABLE 表名( UserName int primary key auto_increment not null, Sex varchar(2) default '男' );给表增加外键-- 主键:PRIMARY KEY (表面必须有主键) /* FOREIGN KEY (以后表的列) REFERENCES 外键的表 (表面的列);*/CREATE TABLE A( sid INT PRIMARY KEY -- 留神：关联的表 必有主键);CREATE TABLE B( Sid INT, FOREIGN KEY(Sid) REFERENCES A(Sid) -- B的sid被外键A的SID限度 );注意事项 : 1. 被关联的外键必须是主键 2.数据类型要统一. ...

上一篇文章介绍了MySQL主从同步的原理和利用，本文总结了MySQL主从提早的起因和解决办法。如果主从提早过大，会影响到业务，该当采纳适合的解决方案。 MySQL主从提早的体现先insert或update写入更新操作，再立刻select查问，然而得不到最新的后果。可通过show slave status命令，后果中的Seconds_Behind_Master列，查看主从提早的秒数。 MySQL主从提早的起因读写拆散时，写操作走主库，读操作走从库，然而主库的变更还未同步至从库网络传输提早：从库发动dump申请，主库推送binlog文件，从库写入本地relay log从库串行执行sql语句：主库并发的事务提交，然而在从库上只能串行执行，速度比主库慢MySQL主从提早解决办法业务优化如果业务场景容许，先写入更新操作，期待一小段时间后再查问。比方，新增一条记录，前端成心提早半秒再调后端接口查问。 技术优化拆库+并行复制：MySQL反对库级别的并行复制，拆库后每个分库的数据质变小，主从提早天然也变小了。慢sql优化除慢sql，也能升高主从提早 终结计划以上方法治标不治本，只能起到缓解主从提早的作用，彻底根治还需这么做。 显式查主库：不同的分片中间件做法不一样，client侧分片可在每次查问前设置查主库的标记（ThreadLocal变量），proxy侧分片开启事务长处：实现简略，毛病：受MySQL QPS限度，QPS极高时不举荐双写数据库和缓存，查缓存：防止MySQL主从提早长处：可撑持高并发场景

ORACLE： SQL> create table tab2(c1 number, c2 number, c3 varchar2(10));表が作成されました。SQL> declare a number;begin a := 1; for i in 1 .. 500 loop for j in 1 .. 1000 loop insert into tab2 values(a,j,'a'); commit; a := a+1; end loop; end loop;end;/PL/SQLプロシージャが失常に完了しました。SQL> create index ind2_2 on tab2(c2);索引が作成されました。SQL> insert into tab2 values(9999,null,'test');1行が作成されました。SQL> commit;コミットが完了しました。SQL> exec dbms_stats.gather_table_stats(ownname=>'TEST',tabname=>'TAB2',cascade=>TRUE);PL/SQLプロシージャが失常に完了しました。SQL> set lin 150 pages 9999SQL> set autot traceonly expSQL> select count(*) from tab2 where c2 is null;実行計画----------------------------------------------------------Plan hash value: 2781695375---------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |---------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 4 | 310 (1)| 00:00:01 || 1 | SORT AGGREGATE | | 1 | 4 | | ||* 2 | TABLE ACCESS FULL| TAB2 | 1 | 4 | 310 (1)| 00:00:01 |---------------------------------------------------------------------------Predicate Information (identified by operation id):--------------------------------------------------- 2 - filter("C2" IS NULL)SQL> select count(*) from tab2 where c2=10;実行計画----------------------------------------------------------Plan hash value: 3563712581----------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |----------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 4 | 4 (0)| 00:00:01 || 1 | SORT AGGREGATE | | 1 | 4 | | ||* 2 | INDEX RANGE SCAN| IND2_2 | 500 | 2000 | 4 (0)| 00:00:01 |----------------------------------------------------------------------------Predicate Information (identified by operation id):--------------------------------------------------- 2 - access("C2"=10) Mysql（Innodb）： ...

我把所有Java相干的面试题和答案都整顿成了PDF，并且带书签目录，浏览起来十分不便 面试题及答案PDF下载：https://www.hicxy.com/?p=2645 面试题及答案PDF下载：https://www.hicxy.com/?p=2645 面试题及答案PDF下载：https://www.hicxy.com/?p=2645 1. 列值为NULL时，查问是否会用到索引？在MySQL里NULL值的列也是走索引的。当然，如果打算对列进行索引，就要尽量避免把它设置为可空，MySQL难以优化援用了可空列的查问,它会使索引、索引统计和值更加简单。 2. 说一说三个范式第一范式（1NF）： 数据库表中的字段都是繁多属性的，不可再分。这个繁多属性由根本类型形成，包含整型、实数、字符型、逻辑型、日期型等。第二范式（2NF）： 数据库表中不存在非关键字段对任一候选关键字段的局部函数依赖（局部函数依赖指的是存在组合关键字中的某些字段决定非关键字段的状况），也即所有非关键字段都齐全依赖于任意一组候选关键字。第三范式（3NF）： 在第二范式的根底上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则合乎第三范式。所谓传递函数依赖，指的是如 果存在"A → B → C"的决定关系，则C传递函数依赖于A。因而，满足第三范式的数据库表应该不存在如下依赖关系： 关键字段 → 非关键字段 x → 非关键字段y 3. innodb引擎的个性插入缓冲（insert buffer)二次写(double write)自适应哈希索引(ahi)预读(read ahead)4. 下面提到了B+树在满足聚簇索引和笼罩索引的时候不须要回表查问数据,什么是聚簇索引?在B+树的索引中,叶子节点可能存储了以后的key值,也可能存储了以后的key值以及整行的数据,这就是聚簇索引和非聚簇索引. 在InnoDB中,只有主键索引是聚簇索引,如果没有主键,则筛选一个惟一键建设聚簇索引.如果没有惟一键,则隐式的生成一个键来建设聚簇索引. 当查问应用聚簇索引时,在对应的叶子节点,能够获取到整行数据,因而不必再次进行回表查问. 5. 你们数据库是否反对emoji表情，如果不反对，如何操作？如果是utf8字符集的话，须要降级至utf8_mb4方可反对 前面的问题，大家能够先本人独立思考一下。 另外我把所有Java相干的面试题和答案都整理出来了，给大家参考一下 面试题及答案PDF下载：https://www.hicxy.com/?p=2645 面试题及答案PDF下载：https://www.hicxy.com/?p=2645 面试题及答案PDF下载：https://www.hicxy.com/?p=2645 6. 索引分类7. 怎么解决这些问题呢?MySQL的事务隔离级别理解吗?8. 一个6亿的表a，一个3亿的表b，通过外间tid关联，你如何最快的查问出满足条件的第50000到第50200中的这200条数据记录。9. MyISAM索引实现？10. 索引的应用场景11. MyISAM存储引擎利用场景有哪些？12. 同时有多个事务在进行会怎么样呢?13. 什么是MySQL？14. 索引是什么？有什么作用以及优缺点？15. 对MySQL的锁理解吗?16. 应用 MySQL 视图有何长处？17. myisamchk 是用来做什么的？18. 那么在哪些状况下会产生针对该列创立了索引然而在查问的时候并没有应用呢?19. 如果要存储用户的明码散列,应该应用什么字段进行存储?20. MySQL复制基本原理流程21. 关系型数据库有什么劣势？22. Explain 性能剖析23. MySQL索引的注意事项24. MySQL的复制原理以及流程25. SQL 语句有哪些分类？26. MySQL 中有哪几种锁？27. 索引对性能的影响：28. 内连贯分为三类29. 索引的类型30. 全连贯（FULL JOIN）31. MySQL的binlog有有几种录入格局?别离有什么区别?32. 存储期间33. 以下三条sql 如何建索引，只建一条怎么建？34. 创立索引的语法35. MySQL中varchar与char的区别以及varchar(50)中的50代表的涵义36. 锁机制与InnoDB锁算法37. 并发事务带来哪些问题?38. 超大分页怎么解决?39. 什么是存储过程？40. InnoDB 引擎的四大个性是什么？41. 数据库删除操作中的 delete、drop、 truncate 区别在哪？42. 触发器的应用场景43. 简略形容MySQL中，索引，主键，惟一索引，联结索引的区别，对数据库的性能有什么影响？44. 应用索引查问肯定能进步查问的性能吗？为什么45. SQL语句优化的一些办法？46. SELECT COUNT(*) 在哪个引擎执行更快？47. varchar(10)和int(10)代表什么含意?48. CHAR 和 VARCHAR的区别？49. 什么是 SQL50. 锁的优化策略51. MySQL事务处理52. 外连贯（LEFT JOIN/RIGHT JOIN）53. 如何优化SQL54. MySQL都有哪些锁呢?像下面那样子进行锁定岂不是有点妨碍并发效率了?55. SQL 注入破绽产生的起因？如何避免？56. 主键应用自增ID还是UUID?57. 索引的区别58. MySQL锁机制59. B-Tree 和 B+Tree60. 做过哪些MySQL索引相干优化61. 什么是存储过程？有哪些优缺点？62. 什么是 MySql 视图？63. 如果一个表有一列定义为TIMESTAMP，将产生什么？64. MySQL 里记录货币用什么字段类型好65. 什么是事务?66. 关怀过业务零碎外面的sql耗时吗?统计过慢查问吗?对慢查问都怎么优化过?67. 索引的优缺点68. 存储引擎常用命令69. InnoDB 存储引擎利用场景是什么？70. MySQL索引的创立准则71. Innodb应用的是哪种隔离级别呢?72. 非聚簇索引肯定会回表查问吗?73. 为什么用 B+ 树做索引而不必哈希表做索引?74. MySQL中varchar与char的区别以及varchar(50)中的50代表的涵义75. MySQL 存储引擎类型有哪些？76. MySQL由哪些局部组成, 别离用来做什么77. MyISAM存储引擎个性有哪些？78. 简略说一说drop、delete与truncate的区别79. 惟一索引比一般索引快吗, 为什么80. 什么是关系型数据库？81. 字段为什么要求定义为not null?82. 如何在MySQL种获取以后日期？83. ACID是什么?能够具体说一下吗?84. MyISAM索引与InnoDB索引的区别？85. Hash索引和B+树所有有什么区别或者说优劣呢?86. 以下语句是否会利用索引：SELECT FROM users WHERE YEAR(adddate) < 2007;87. 请阐明InnoDB和MyISAM的区别88. 创立的索引有没有被应用到?或者说怎么才能够晓得这条语句运行很慢的起因?89. Myql 中的事务回滚机制概述90. 在建设索引的时候,都有哪些须要思考的因素呢?91. innodb的事务与日志的实现形式92. MySQL中的varchar和char有什么区别.93. 数据库的乐观锁和乐观锁是什么？94. 横向分表和纵向分表,能够别离举一个适宜他们的例子吗?95. 优化数据库的办法96. MySQL 数据库作公布零碎的存储，一天五万条以上的增量， 预计运维三年,怎么优化？97. 简略形容 MySQL 中，索引，主键，惟一索引，联结索引的区别，对数据库的性能有什么影响（从读写两方面）98. 请阐明varchar和text的区别99. InnoDB和MyISAM有什么区别?100. MySQL 有哪些数据类型？101. 什么是视图？以及视图的应用场景有哪些？102. 超键、候选键、主键、外键别离是什么？103. int(10) 和 bigint(10) 能存储的数据大小一样吗？104. 解释 MySQL 外连贯、内连贯与自连贯的区别105. MySQL的罕用操作106. MySQL索引的原理107. FLOAT和DOUBLE的区别是什么？108. 索引是个什么样的数据结构呢?109. 索引的根底110. MySQL如何保障复制过程中数据一致性及缩小数据同步延时111. 什么状况下设置了索引但无奈应用112. 创立MySQL联结索引应该留神什么？113. VARCHAR(50) 能寄存几个 UTF8 编码的汉字？114. 为什么要尽量设定一个主键?115. MySql 服务默认端口号是多少 ？116. 联结索引是什么?为什么须要留神联结索引中的程序?117. 怎么看到为表格定义的所有索引？118. MySQL反对哪些存储引擎?119. 存储过程和函数如同差不多，你说说他们有什么区别?120. UNION与UNION ALL的区别？121. 联结查问（UNION与UNION ALL）122. MySQL数据库cpu飙升到500%的话他怎么解决？123. drop、delete与truncate别离在什么场景之下应用？124. 什么是触发器，MySQL中都有哪些触发器？125. 六种关联查问

UPDATE `workingImdbMatchTask`SET `task_json` = CASE WHEN (`workingImdbMatchTask`.`id` = 5) THEN 'asds' WHEN (`workingImdbMatchTask`.`id` = 8) THEN 'asds' WHEN (`workingImdbMatchTask`.`id` = 9) THEN 'asds' ELSE NULL ENDWHERE `workingImdbMatchTask`.`id` IN (5, 8, 9);

数据库的基本原理学习数据库，第一步就是先打好根底，数据库原理是计算机科班的一门必修课，非科班的我抉择的是自学，我过后也是通过看MySQL视频教程，配合大学教材《数据库系统概论》来自学的。 书籍这种货色，必定还是偏实践的一点，相比来说，看视频教程更容易了解。 数据库是干嘛的？数据库的性能就是用来组织数据，组织很多很多的数据。 这些数据通常都是存储在外存(磁盘)数据库提供的外围性能，也就是针对数据的增删改查~ 学习数据库咱们次要理解的内容次要蕴含几个方面： 1、数据库模型有哪些：包含层次模型、网状模型和关系模型，咱们所用的关系型数据库就是基于关系模型实现的。 2、关系数据库的根底和sql：理解关系数据库的基本概念，理解sql的根本应用办法，至多CRUD和一些常见用法要搞懂。 3、数据库的安全性和完整性，这两局部内容其实实践的货色比拟干燥，实际上对应到理论场景中，安全性就是要爱护数据的平安，包含权限管制和数据备份，而完整性则是通过一些约定和标准来限度数据库的存储内容，比方咱们能够用主键、惟一键、非空等要求来限度字段的取值。 4、关系数据实践。这部分内容很有意思，也比较复杂，讲到了数据库的范式实践，从一范式到四范式，各有各的用法和要求，某互联网公司“第四范式”就是用这个概念来命名的。 5、事务和锁，最初一部分内容，就是数据库的两个重要组成部分，事务和锁，事务能够保障一组数据库操作的ACID个性，十分实用于须要数据一致性的场景，而数据库的锁不然而实现事务的根底，还能够灵便地实用于不同的数据库利用场景，咱们还能够通过sql语句来实现加锁和开释，对于并发场景尤其管用。 MySQL的实现原理学习完了数据库根底之后，接下来就该正式学习MySQL了，毕竟很多时候咱们的数据库利用就是MySQL。 其实MySQL里的很多知识点和咱们下面提到的数据库根底大同小异，而回到MySQL的实现层，咱们就得来看看MySQL的存储引擎了。 MySQL的存储引擎分为innodb和myisam，置信大家对于这两个引擎区别的面试题看了也不少，比方innodb反对事务，反对行级锁，而myisam不反对。 因为当初innodb基本上是支流，所以咱们探讨MySQL的时候基本上就是在探讨innodb。 对于MySQL的实现原理，我认为大略有这么一些内容须要咱们去学习。 首先，咱们理解MySQL里有哪些数据类型，个别的用法如何，而后，尝试用MySQL去跑一些sql语句，建库建表，加索引加主键，总之，这些实际能帮忙你更好地学习上述内容。 想要更好地理解MySQL的原理，咱们就必须要理解MySQL的整体架构，一般来说，MySQL从上到下能够分为这么几层 客户端也就是咱们常常用的可视化工具，比方Navicat for MySQL 服务端就是咱们装置的MySQL程序，其实关上它它就是一个MySQL的服务端过程 sql执行层sql执行层次要负责解析执行sql，外面蕴含了很多简单的组成部分，比方解释器，分析器，优化器等等，执行层会生成一个sql的执行打算，这个打算也常常是咱们剖析sql性能的一个重要参考内容 存储引擎层存储引擎层是innodb了，比方数据要如组织和寄存，索引要如何建设和治理等等，加锁怎么加，事务如何实现，都是这一层要思考的内容。 文件系统层存储引擎的下一层就是文件系统了，数据库的数据如何和文件系统进行交互，就是这一层要做的事件了。 索引不得不说，索引相对是数据库中最常常考查，考点也最多的内容了。 比方给你一条sql，那么它是否命中索引，能命中哪些索引，如果想要命中某个索引，你应该如何批改，这种问题面试时是不是常常看到，变来变去这么多题型，其实面试官就是想考查你对于索引的了解。 还有就是，索引的数据结构，一样是十分热门的考点之一，索引其实是基于B+树来实现的，不晓得b+树是啥，请回去看数据结构。 简略来说，它是一种多路搜寻树，致力于更短的工夫来实现数据检索，因为它的高度比二叉树要低，而比起一般的b树，它的非叶节点只起索引作用，而叶子节点是程序串联的，所以非常适合做搜寻树。 如果你了解了这一点，那么面对此类面试题就能够更加从容一些，面试官其实就是想晓得你对b+树的理解到了什么样的水平而已。 事务和锁除了索引之外，数据库中最简单的内容可能就是事务和锁了。 就拿事务的ACID个性来说，你须要理解每个大写字母背地的实现原理，比方原子性是如何实现的，一致性是如何保障的，背地的原理是什么。 咱们平时罕用的事务可能就是spring里的事务模板，在事务里执行的同库数据库操作，要么都胜利，要么都失败，这就是原子性。 两个事务之间互不影响，这就是隔离性，当然了，这里又波及到了事务隔离级别。 事务隔离级别包含读未提交，读已提交，可反复读和序列化，每个事务隔离级别都实用于某种数据库读写场景，很多时候，咱们都须要搞懂隔离级别背地的原理，能力更好地实用它。 MySQL里默认应用可反复读的隔离级别，这个级别基本上能够保障咱们的事务依照预期执行，在MySQL中，这个事务隔离级别甚至能够解决幻读的问题。 在MySQL的事务背地，其实有一个暗藏的boss，那就是数据库的锁，很多事务的隔离级别都是通过锁来实现的，比方可反复读只有加行锁就能够实现了，而幻读则须要加上间隙锁next-key lock来实现。 行级锁和表级锁是MySQL中的两种锁，表级锁顾名思义，会间接锁表，一次只有一个事务可能拜访，而行级锁其实锁的也并非是一行，在MySQL中，这个锁加在索引上，而这个索引对应的数据往往不止一行，所以这个行级锁只是理论意义上的"行级锁" 说了这么多，要了解MySQL的事务和锁，还是要多看看相干的书籍和文章，了解其外部的实现原理，知其然也要知其所以然。 MySQL学习教程这个视频是最适宜老手学习的MySQL根底入门视频，能源节点的杜老师所讲，杜老师讲课格调雷厉风行，干脆利索。 特点： 适宜相对零根底的学者观看；视频采纳循序渐进的形式教学，所以不存在听不懂，学不会；看完视频齐全能够担当日常开发工作；总的来说，视频是站在相对零根底的角度来教，次要内容包含：DQL、DML、DDL、DCL、TCL等SQL语句的学习，尤其对DQL语句进行了具体的解说，包含单表查问、多表联查、内连贯、外连贯等。另外还讲授了数据库事务的解决，数据库索引的实现原理，视图的应用等内容。 通过本mysql视频学习能够让一个小白从不会数据库到可能在编程中纯熟应用数据库。 下边是学习材料，点击下边 https://www.bilibili.com/vide...

引言上一章节咱们探讨过数据垂直拆分，明天咱们来持续探讨数据拆分：程度拆分！ 程度拆分和垂直拆分有些不一样，垂直拆分最小单元是字段，与业务有很强的关联性，具体业务对应具体的拆分数据；而程度拆分最小单元是数据行，与具体业务关系不大，业务关联能够是拆分后的单张表数据，也能够是拆分前的全局数据。简略来说，程度拆分对利用通明，应用逻辑在数据拆分后不须要大动。 注释个别在关系数据库中，程度拆分具体对应两个方面：第一是程度拆表。程度拆表是基于一张表的某个字段，以肯定的拆分办法拆分为多张表的数据拆分，拆分完后须要把原来对单张表的操作转换为对多张子表的操作。一般来讲，和垂直拆分相似，须要一张全局路由表。定义好路由表后，即可简化对拆分表的操作。比方波及到数据拆分后的数据同步，查问语句下发到拆分子表等都能够间接操作路由表。如下图所示，表 A 依照 ID 拆分，奇数表为表 A1 ，偶数表为表 A2 ： 第二是程度分区。程度分区和程度拆表相似，都是基于一个字段对表数据进行拆分。 不同的是程度分区是数据库内置性能，相比程度分表来讲，操作上会更加简略。不过最大的毛病是拆分后的数据不能跨实例，这也是当初大部分中间件或者是 NEW SQL 不间接用程度分区的起因。然而如果仅仅思考在单机上进行数据拆分，应该首选程度分区，具体起因咱们后续章节会讲，明天次要是来回顾下 MySQL 的内置程度拆表计划。 MySQL 原生程度拆表提到 MySQL 的原生程度拆表，能想到的就是 MERGE 表！MERGE 表是针对传统 MYISAM 表做程度汇总的功能表。一提到 MYISAM ，可能好多人感觉过期了，没必要持续了！不过我这儿要讲的是，尽管 MERGE 过期了，然而 MERGE 提供给咱们将来进行程度拆分的办法是十分值得学习的，这也就是为什么这篇要对 MERGE 做一个示例阐明的起因。理解如何应用 MERGE 表对咱们前面要讲的 INNODB 表拆分有很大的借鉴意义。 MERGE 表的长处很多，列举如下：数据易于治理。比方一张很大的日志表，寄存10年的数据，依照月份拆分成120张表，采纳 MERGE 表做汇聚，不须要对120张子表别离检索，只须要检索 MERGE 表即可。升高单块磁盘 IO 使用率。比方能够把日志表不同月份的数据扩散到不同的磁盘来防止繁多磁盘 IO 使用率过高的问题。查问简略。比方日志表的查问模式比拟固定，查问以后年份数据的申请十分频繁，历史数据偶然查问，就能够拆分成两张表，一张以后表，一张历史表，再用 MERGE 表来做这两张表的对立入口，查问 MERGE 表会主动路由到以后表。MERGE 表零保护。MERGE 表只寄存所蕴含的子表元数据，所以不须要保护，创立销毁十分疾速。MERGE 表治理的子表非常灵活。每张子表不须要局限在单个数据库中，能够灵便的散布在不同的数据库里。那接下来，用几个简略例子来理解下 MERGE 表的应用办法。表m1 - m10，10张子表，别离依照 id 从小到大来寄存，每张表10000条记录，表构造如下： (debian-ytt1:3500)|(ytt)>show create table m1\G*************************** 1. row *************************** Table: m1Create Table: CREATE TABLE `m1` ( `id` int NOT NULL, `r1` int DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_r1` (`r1`)) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci1 row in set (0.00 sec)(debian-ytt1:3500)|(ytt)>select count(*) from m1;+----------+| count(*) |+----------+| 10000 |+----------+1 row in set (0.00 sec)...对应的 MERGE 表构造如下： ...

联结查问之unionunion能够合并两个以上 select语句查问进去的表，并打消表中的反复行。 其中，select语句须要领有雷同数量和雷同数据类型的列。 查问中国各省的ID以及省份名称select ProID,ProName from T_Province复制代码湖南省所有地级市ID、名字select CityID,CityName from T_Citywhere ProID = ( select ProID from T_Province where ProName="湖南省");复制代码用union将他们合并select ProID,ProName from T_Provinceunionselect CityID,CityName from T_Citywhere ProID = ( select ProID from T_Province where ProName="湖南省");复制代码这样就失去两个查问后果的并集了。UNION 合并后的汇合中的列名总是等于 UNION 中第一个 SELECT 语句中的列名。 联结查问之union allselect ProID,ProName from T_Provinceunion allselect CityID,CityName from T_Citywhere ProID = ( select ProID from T_Province where ProName="湖南省");复制代码当应用union all，不会打消反复行。 联结查问之inner join 查问湖北省有多少地级市不必联结查问：select count(CityID) from T_Citywhere ProID = (select ProID from T_Province where ProName="湖北省")复制代码通过ProID将两张表连贯在一起 select ProName,CityName from（ ...

本文依据 PingCAP DevCon 2021 上来自微众银行资深数据库架构师黄蔚的分享整顿而成，次要论述 TiDB 在微众银行的利用实际，包含微众银行抉择 TiDB 的背景和 TiDB 的部署架构，以及 TiDB 在贷款外围批量场景的利用，最初分享了基于 TiDB 优化计划的最佳实际和将来布局。 TiDB 的产品劣势从 2018 年底微众银行开始接触 TiDB 的团队，到 2019 年上线，TiDB 在数据库的选型之中展示了很多独有的劣势。 TiDB 兼容 MySQL 协定，同时也兼容 MySQL 的生态工具，比方备份、复原、监控等等，不论是利用自身还是运维或是开发人员，从 MySQL 迁徙到 TiDB，其老本和门槛都较低。对于 TiDB 原生的计算、存储拆散的架构，用户将不用放心容量或者单机性能的瓶颈，某种程度能够把 TiDB 当作一个很大的 MySQL 来应用。同时 TiDB 的数据多正本强统一的个性对金融场景来说非常重要，TiDB 还人造反对多 IDC 的部署架构，能够反对利用做到同城多活的部署架构。此外，TiDB 开源社区的经营也十分沉闷，比方在 AskTUG 平台能够看到很多用户的典型问题的解决办法，蕴含大量的贵重教训能够借鉴，能够进一步升高用户应用 TiDB 的门槛。 当初应用 TiDB 的用户越来越多，不论是互联网头部厂商或者金融行业用户都在大量应用，这也是 TiDB 产品越来越成熟的体现，也给更多用户应用 TiDB 带来了更强的信念。 TiDB 在微众银行的部署架构TiDB 的个性是否可能满足金融机构高可用的架构需要？ 这是 TiDB 在微众银行的部署架构，如图所示，首先 TiKV 抉择三正本，别离部署在同城的三个数据中心，这样能够实现 IDC 级别的高可用，同时在每个 IDC 部署了一套 TiDB Server，通过绑定到负载均衡器提供 VIP 服务，这样使得利用能够做到多活接入的模式。这套架构也禁受过 IDC 级别的实在故障的演练验证，将其中一个 IDC 的网络全副断掉，察看到集群能够疾速复原，咱们认为TiDB 可能合乎金融场景高可用的要求。 ...

问题：昨天线上呈现报错导致一个性能无奈执行，查找日志发现是mysql的死锁问题。 剖析问题：其实解决问题最大的难点在于剖析问题找到呈现问题呈现在哪里，这个过程破费的工夫和思考是最多的，而应用代码解决问题反而很疾速。 （1）报错日志如下： 2021-10-09 18:59:04] local.INFO: RobotAuction-SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction (SQL: select id, cash, freeze, area_id from users where users.id in (2634, 2662, 2672, 2673, 2675, 2685, 2808, 2811, 2818, 2834, 2869, 2886, 2926, 2961, 2962, 2981, 3066, 3080, 3124, 3131, 3135) and users.deleted_at is null for update)-669 从报错日志下来查看msyql的死锁日志，再联合业务上的可能的操作进行剖析（2）死锁日志： 2021-10-09 18:59:04 0x150d81d79700* (1) TRANSACTION:TRANSACTION 385220, ACTIVE 0 sec starting index readmysql tables in use 1, locked 1LOCK WAIT 11 lock struct(s), heap size 1136, 19 row lock(s)MySQL thread id 1376113, OS thread handle 23147762767616, query id 23440050 localhost 127.0.0.1 lpt Sending data ...

《高性能Mysql》学习笔记（一）前言 Mysql的品质比拟好的书其实并不是很多，所以能够说是看一本少一本，这本书也算是学习MYSQL必看的一本书，当然非常厚，尽管版本很老然而讲述的内容都会非常实用的，对于学习MYSQL的人能够说是一本必读的进阶好书。 最初，这篇读书笔记是整顿集体以前自学的时候看书做的笔记，做的非常毛糙=-=，当初来看很多笔记记得过于根底了。另外过后很多都是截图的，很多都是图片HHHH（流量观看谨慎）。 MySQL逻辑架构图 尽管看上去比拟复旧，然而挺经典的。 小贴士： 存储引擎不会去解析sql， 不同存储引擎不会互相通信，只是简略响应下层申请（InnoDB引擎除外，会解析外键定义，因为mysql服务器自身没有实现该性能） 连贯治理和安全性 每一个连贯都是一个独自线程，服务器会对连贯缓存而不是创立或者销毁线程 优化与执行执行流程： 解析查问创立数据结构（解析树），优化（重写查问，读表程序优化，抉择索引等）尝试查问缓存（SELECT）返回后果并发管制 目标：外部领有锁机制避免数据毁坏 共享锁和排他锁（读锁和写锁）读锁是共享的，互相不阻塞写锁是排他的，一个写锁会阻止其余读锁和写锁锁粒度 进步共享资源并发性就是让锁更有选择性，让锁只监控局部数据 记住：任何时候，给定资源下，锁定数据量越少，并发水平越高，只有互相不发生冲突即可 mysql提供多个存储引擎反对丰盛的锁策略 表锁 (table lock) 表锁是msyql中最根本的锁策略，开销最小的策略，这种形式相似邮箱的加锁机制：会锁定整张表，用户拜访时候，对表进行写操作，须要优先取得写锁，会阻塞其余用户读写操作，只有没有写锁时候，其余用户能力取得读锁，读锁之间是不互相阻塞的，特定场景表锁能够有良好性能。 注意事项： 写锁比读锁有更高的优先级，写锁有可能会插入到一个读锁的后面，然而读锁不能插入到写锁队列后面服务器会为alter table 等语句默认应用表锁而不是依据引擎决定（尽管存储引擎才是真正干活的）行级锁 (row lock) 该锁能够最大水平反对并发解决（与此同时带来微小锁开销），InnoDB和XtraDB， 实现了行级锁，行级锁只在存储层也就是存储引擎实现，而<font color='red'>mysql服务层没有实现</font> 事务事务的ACIDA（atomicity） 原子性 一个事务是一个不可分割的单位，事务中的所有操作，要么全实现，要么全不实现，任何一个操作的失败，都会回滚到事务执行之前的状态。C （consistency） 一致性 事务完结后，零碎状态是统一的。即，在并发操作时，零碎的状态也要和串行执行事务时一样。I （isolation）隔离性 并发执行的事务之间，无奈看到彼此的零碎状态。D （durability）持续性 在事务实现后，事务对数据库的操作会被长久保留在数据库中，不会被回滚。 事务应用与否依据理论业务状况而定（甚至能够不应用事务，而是应用sql 进行肯定的安全措施），如何抉择适合的 mysql 引擎来解决问题可能事务自身更加重要。 隔离级别 死锁 如果多个线程同时更改同一行数据，你们两个线程相互期待对面的锁，造成死锁 解决办法：例如：InnoDB 检测死循环依赖，并且立刻返回一个谬误（死锁会造成慢查问）。查问工夫达到锁期待超时设定工夫之后放弃锁申请。InnoDB目前（5.1）解决办法：将持有<font color='red'>起码行级排他锁</font>的事务进行回滚。大多数时候因为数据抵触，有时候的确是因为存储引擎形式引起的！！！只有局部或者齐全回滚一个事务能力突破死锁，事务性零碎无奈防止。大多数时候只须要从新执行死锁事务即可事务日志 事务日志采纳追加形式，因而I/O的耗费比拟小，内存批改数据后盾缓缓刷会磁盘，目前大多数存储引擎都是这样实现被称为：预写式日志 mysql中的事务innoDBNDB cluster主动提交 默认状况下咱们所写的SQL默认都是主动提交的，也就是说在执行的时候MYSQL都会给咱们自定加上一条，COMMIT语句，也就是主动提交事务，咱们能够应用SHOW VARIABLES LIKE 'AUTOCOMMIT'语句查看是否开启主动提交。 <font color='red'>切记：查找对应版本会产生 AUTO_COMMIT 所有语句</font> 设置隔离级别命令如下： > SET SESSION TRASACTION ISOLATTION LEVEL READ COMMITTED ...

1.查问英语分数在 80－90之间的同学。 SELECT stu_idFROM examWHERE score >=80 AND score <=90 AND sub_id = ( SELECT subject_id FROM `subject` WHERE subject_name = '英语')2.查问数学分数为89,90,91的同学。 SELECT * FROM student WHERE stu_no IN( SELECT stu_id FROM exam WHERE score IN(89,90,91) AND sub_id = ( SELECT subject_id FROM `subject` WHERE subject_name = '数学' ))3.查问所有姓李的学生问题。 SELECT * FROM exam WHERE stu_id IN ( SELECT stu_no FROM student WHERE stuname LIKE "李%")4.查问数JAVA>80 并且 HTML分>80的同学的信息。 SELECT stu_id , COUNT(*) FROM exam e , `subject` s WHERE e.sub_id= s.subject_id AND ( (e.score >= 80 AND s.subject_name='JAVA') OR (e.score >= 90 AND s.subject_name='HTML'))GROUP BY stu_id HAVING COUNT(*) = 25.对数学问题排序后输入。 ...

日常工作中，MySQL数据库是必不可少的存储，其中读写拆散根本是标配，而这背地须要MySQL开启主从同步，造成一主一从、或一主多从的架构，把握主从同步的原理和晓得如何理论利用，是一个架构师的必备技能。楼主将在本文做总结，看这一篇就够了。 1、主从同步原理主从同步架构图（异步同步）这是最常见的主从同步架构。 主从同步流程（异步同步）主库把数据变更写入binlog文件从库I/O线程发动dump申请主库I/O线程推送binlog至从库从库I/O线程写入本地的relay log文件（与binlog格局一样）从库SQL线程读取relay log并从新串行执行一遍，失去与主库雷同的数据什么是binlog？主库每提交一次事务，都会把数据变更，记录到一个二进制文件中，这个二进制文件就叫binlog。需注意：只有写操作才会记录至binlog，只读操作是不会的（如select、show语句）。 binlog的3种格局：statement格局：binlog记录的是理论执行的sql语句row格局：binlog记录的是变动前后的数据（波及所有列），形如update table_a set col1=value1, col2=value2 ... where col1=condition1 and col2=condition2 ...mixed格局：默认抉择statement格局，只在须要时改用row格局binlog格局比照statement级别：长处是binlog文件小，毛病是主库的慢sql也会在从库上再呈现一次，一些依赖环境或上下文的函数可能会产生不统一的数据row级别：毛病是文件大（一条语句如果波及多行，会放大n倍），长处是无上述慢sql问题，不依赖环境或上下文为了获取前后变动数据，canal倡议应用row级别主从同步的2种形式异步同步：默认形式，可能会导致主从切换时数据失落。因为主库是否commit与主从同步流程无关，也不感知。半同步：高可用计划，较新mysql版本反对，须要至多1个从库（默认1，具体数量可指定）对写入relay log进行ack，主库才会commit并把后果返回client。主从同步流程（半同步）从库在连贯主库时，表明本人反对半同步复制主库也需反对半同步复制，主库commit事务前会阻塞期待至多一个从库写入relay log的ack，直至超时如果阻塞期待超时，则主库长期切换回异步同步模式，当至多一个从库的半同步追上进度时，主库再切换至半同步模式半同步实用场景高可用备份：半同步复制，可确保从库与主库的一致性，当主库产生故障时，切换到从库不会失落数据。为了保障稳定性（不因半同步慢而连累主库），个别不承当业务流量、尽可能快地ack，只用于同步备份。 2、主从同步利用场景一般场景：线上从库异步同步，高可用备份半同步 对一致性要求较高的大数据取数需要大数据取数可能导致从库cpu使用率飙升、ack变慢，可设置半同步所需ack数量为1，失常状况下高可用备份能很快ack，于是主库会commit并返回，而大数据取数复制慢一些也无所谓。这样就不会因为大数据取数ack慢而影响主库和业务了。 参考：mysql官网文档 https://dev.mysql.com/doc/ref...https://dev.mysql.com/doc/int...

前言索引下推(ICP)是针对MySQL应用索引从表中检索数据行的状况的优化。 在没有索引下推的状况下，MySQL通过存储引擎遍历索引来定位表中的数据行并将它们返回给MySQl服务器，服务器再进行WHERE条件的判断，确认是否将数据行退出后果集。开启索引下推，且WHERE条件局部能够仅应用索引中的列来评估，这时MySQL服务器会将这部分WHERE条件下推到存储引擎，接着存储引擎应用索引条目评估推送的索引条件，仅当满足该条件时才从表中进行读取。索引下推能够缩小存储引擎拜访数据表的次数以及MySQL服务器拜访存储引擎的次数。 注释看完下面这段官网文档的解释，你当初是不是这样的 是的话，那就对了，毫无疑问下面这段话了解起来相当吃力，但请不要灰心，我将用最通俗易懂的语言来带你理解索引下推。 在此之前我先像你介绍两个敌人 最左前缀准则回表最左前缀准则 MySQL在建设联结索引时会遵循最左前缀准则，比方当初User表建设了联结索引（id，name，age）依据最左前缀准则只有在SQL的条件局部命中(id)、(id，name)或者(id, name, age)时能力应用到这个联结索引。 能应用该索引的状况如下： SELECT * FROM USER WHERE id = 1 SELECT * FROM USER WHERE id = 1 and name = 'zhangsan' SELECT * FROM USER WHERE id = 1 and name = 'zhangsan' and age = 18 不能应用该索引的状况如下: SELECT * FROM USER WHERE name = 'zhangsan' SELECT * FROM USER WHERE age = 18 SELECT * FROM USER WHERE name = 'zhangsan' and age = 18 ...

由五部门公布的《汽车数据安全治理若干规定（试行）》明天起正式实施。这是继数据安全法出台之后，汽车行业数据安全规定的率先推动实施，其重要水平可见一斑。 事实上，往年已有四部以上的汽车数据安全、智能网联汽车治理规定相继出台。政策密集公布背地有何原因？《规定》有哪些细节和亮点值得关注？为跟上合规驱动的新阶段，相干企业又该有何口头？基于以上问题，咱们邀请到了腾讯平安车联网平安专家张康、腾讯平安云鼎实验室数据安全专家刘海洋为大家详解法规内容、提供口头思路。 4月29日，全国信息安全标准化技术委员会公布《信息安全技术网联汽车采集数据的平安要求（草案）》。 6月21日，工信部公布《车联网（智能网联汽车）网络安全规范体系建设指南》并公开征求意见。 8月12日，工信部公布《对于增强智能网联汽车生产企业及产品准入治理的意见》。 8月16日，网信办、发改委、工信部、公安部、交通运输部颁布《汽车数据安全治理若干规定（试行）》。 数据安全治理火烧眉毛 《规定》有哪些新要求？ “新四化”的趋势下，汽车运行产生的数据量十分大，将来仅一辆车的数据都将以“G”，甚至以“T”为单位，然而如此宏大的数据该当如何进行正当开发利用，行业认知和摸索仍处于起步阶段。腾讯平安车联网平安专家张康提道，过来很多企业都遵循着本人的规范，行业整体处于“千企千面”的状态，产业链上的合作、数据通讯也经常因为各自协定规范不对立，无奈无效地保障数据安全、共享应用。 而另一方面，安全事件频发，严厉的数据安全挑战成为行业倒退的外围痛点。据报道，2020年1-9月，针对整车企业车联网信息服务提供商等相干企业和平台的歹意攻打达280余万次；往年6月的某次信息安全事件中，约有330万汽车的车主和潜在客户的个人信息受到泄露。 数据安全治理到了迫不及待的时候，而《规定》的出台让汽车行业的数据安全有了遵循根据，更给了宽广用户一颗安心驾驶的定心丸。 《规定》界定了汽车数据和监管主体，提出了4项举荐的数据处理准则，同时明确了数据处理者的任务，并制订跨境数据传输规定，初步建设起中国汽车数据安全的合规框架。 腾讯平安云鼎实验室数据安全专家刘海洋认为，《规定》首次对“汽车数据处理者”和“重要数据”类型等内容做了清晰的界定。如“汽车数据处理者”不仅限于惯性认知中的汽车制造商、零部件和软件供应商等，还包含经销商、培修机构以及出行服务企业。同时，《规定》落实了年度报告制度，汽车数据处理者该当按时被动报送年度汽车数据安全治理状况，这意味着国家的监管力度曾经更强，向系统化治理迈出重要一步。 从事件驱动转为合规驱动 平安能力晋升势在必行 “在过来，车联网平安其实还处于行业教育阶段，更多由事件驱动，只有当破绽被发现或者呈现安全事故，相干刚才会采取行动，而《规定》的实施让行业转变为合规驱动，汽车数据处理者必须平安合规，否则就将守法。”张康提道。 目前，政府仍在逐渐补齐和欠缺汽车数据监管体系和办法，在《数据安全法》《个人信息保护法》等上位法的框架下，进一步推动欠缺《智能网联汽车生产企业及产品准入治理指南》、《汽车数据安全治理若干规定》等规定制度的相干实施细则，明确企业的数据安全爱护责任，欠缺汽车数据安全爱护体系。 当然，合规非最终目标，它将原先漫长的行业教育过程放慢，极速造成了广泛的认知共识，而这只是迈向真正实现车联网数据安全的终点。对于当下的车企而言，本身平安能力的晋升也同样重要，适配智驾环境的技术手段的不足（如采集图像及视频的模糊化、匿名化解决）、车载零碎及内部组件的未知危险破绽等诸多问题，都在制约着数据安全的倒退过程。 坚守平安底线 被动建设网络安全能力新标杆 车企如何更好地应答合规时代的要求？在自主建设平安能力框架方面，刘海洋抛出了“晋升四部曲”的倡议： 1.数据资产和数据场景的梳理：梳理企业的数据资产和数据场景（如大数据处理加工剖析、智驾数据的标注、第三方委托解决等）的重要内容，为技术管控、合规应答、管理体系建设做好根底铺垫； 2.企业本身合规的评估剖析：正如《个人信息保护法》《数据安全法》当中所提到的，作为数据处理者要定期发展合规审计，评估本身的数据管控状态和合规状态，并进行合规差距剖析； 3.查漏补缺，晋升平安硬实力：针对性地对所不足的平安技术做晋升，个别包含数据加解密、数据脱敏、电子认证等核心内容； 4.管理制度与稽核流程的建设：建设企业的数据安全管理制度，对数据安全爱护任务进行落实，并通过稽核的伎俩保障汽车数据运行处于合规状态。 同时，车联网的数据量级大、主体多、链条长，也意味着单点危险解决形式收效甚微。而通过车联网平安技术的联结深度共建，造成全流程一体化的解决方案，将可能无效、全面地放慢车企平安能力的晋升。 以上汽团体为例，其正在积极探索车联网平安能力建设之道。往年4月，上汽团体和腾讯发表共建网络安全联结实验室。单方将独特打造网络安全产品，建设笼罩智能网联汽车全生命周期的网络安全经营体系，并通过深度融入整车研发制作流程的形式晋升汽车云管端一体化的网络安全程度。 法规的出台进一步推动行业放慢数据安全布局过程，挑战与时机共存。面向未来的新征程上，腾讯平安愿与更多企业单干，增强技术研发与数据安全技术利用、晋升平安可控能力、构建欠缺的数据安全管理体系，筑牢合规时代的“汽车网络安全底座”，独特摸索汽车网络安全行业新标杆。

mysql复制流程在备库 B 上通过 change master 命令，设置主库 A 的 IP、端口、用户名、明码，以及要从哪个地位开始申请 binlog，这个地位蕴含文件名和日志偏移量在备库 B 上执行 start slave 命令，这时候备库会启动两个线程，就是图中的 io_thread 和 sql_thread。其中 io_thread 负责与主库建设连贯主库 A 校验完用户名、明码后，开始依照备库 B 传过来的地位，从本地读取 binlog，发给 B备库 B 拿到 binlog 后，写到本地文件，称为直达日志（relay log）sql_thread 读取直达日志，解析出日志里的命令，并执行binlog的三种格局statementstatement 格局下，记录到 binlog 里的是语句原文 binlog 设置的是 statement 格局，并且语句中有 limit，所以这个命令可能是 unsafe 的，可能会呈现这样一种状况：在主库执行这条 SQL 语句的时候，用的是索引 a；而在备库执行这条 SQL 语句的时候，却应用了索引 t_modified。因而，MySQL 认为这样写是有危险的在statement模式下，因为他是记录的执行语句，所以，为了让这些语句在slave端也能正确执行，那么他还必须记录每条语句在执行的时候的一些相干信息，也就是上下文信息，以保障所有语句在slave端被执行的时候可能失去和在master端执行时候雷同的后果。这须要应用mysqlbinlog 工具解析进去，而后把解析后果整个发给 MySQL 执行，而不是应该只应用从statement解析出的语句来执行，这样会短少上下文 row当 binlog_format 应用 row 格局的时候，binlog 外面记录了实在影响的行的主键 id 当 binlog_format 应用 row 格局的时候，binlog 外面记录了实在删除行的主键 id，这样 binlog 传到备库去的时候，就必定会删除 id=4 的行，不会有主备删除不同行的问题row 格局的毛病是，很占空间。比方你用一个 delete 语句删掉 10 万行数据，用 statement 的话就是一个 SQL 语句被记录到 binlog 中，占用几十个字节的空间。但如果用 row 格局的 binlog，就要把这 10 万条记录都写到 binlog 中。这样做，不仅会占用更大的空间，同时写 binlog 也要消耗 IO 资源，影响执行速度 ...

隔离性与隔离级别ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、持久性、隔离性）SQL 规范的事务隔离级别包含： 读未提交（read uncommitted）读提交（read committed）可反复读（repeatable read）串行化（serializable ）在实现上，数据库外面会创立一个视图，拜访的时候以视图的逻辑后果为准。 “读未提交”隔离级别下间接返回记录上的最新值，没有视图概念；在“读提交”隔离级别下，这个视图是在每个 SQL 语句开始执行的时候创立的在“可反复读”隔离级别下，这个视图是在事务启动时创立的，整个事务存在期间都用这个视图“串行化”隔离级别下间接用加锁的形式来防止并行拜访oracle默认是读提交、mysql默认是可反复读 mvccInnoDB 外面每个事务有一个惟一的事务 ID，叫作 transaction id。它是在事务开始的时候向 InnoDB 的事务零碎申请的，是按申请程序严格递增的而每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把 transaction id 赋值给这个数据版本的事务 ID，记为 row trx_id。同时，旧的数据版本要保留，并且在新的数据版本中，可能有信息能够间接拿到它 也就是说，数据表中的一行记录，其实可能有多个版本 (row)，每个版本有本人的 row trx_id每一行的多个版本v1,v2,v3并不是实在存在的，而是以后版本通过undolog算进去的依照可反复读的定义，一个事务启动的时候，可能看到所有曾经提交的事务后果。然而之后，这个事务执行期间，其余事务的更新对它不可见 在实现上， InnoDB 为每个事务结构了一个数组，用来保留这个事务启动霎时，以后正在“沉闷”的所有事务 ID。“沉闷”指的就是，启动了但还没提交数组外面事务 ID 的最小值记为低水位，以后零碎外面曾经创立过的事务 ID 的最大值加 1 记为高水位,这个视图数组和高水位，就组成了以后事务的一致性视图（read-view）对于以后事务的启动霎时来说，一个数据版本的 row trx_id，有以下几种可能 如果一个数据的版本row trx_id<低水位示意这个版本是已提交的事务或者是以后事务本人生成的，这个数据是可见的如果一个数据的版本row trx_id > 高水位示意是未来的事务生成的，必定不可见如果一个数据的版本row trx_id在低水位与高水位之间，有两种可能 若在数组中，是未提交的批改，不可见不在数组中，是提交的批改，可见 假如数组是[1,2,3,5]，查看的数据版本是4，这意味着在事务启动时，[1,2,3,5]事务都没有提交，然而4提交了，所以4是能够被看到的。这也阐明低水位～高水位数字范畴之间的row trx_id并不是都没有提交的，而是不在数组中的就是曾经被提交的本人的事务版本可见更新数据都是先读后写的，而这个读，只能读以后的值，称为“以后读”（current read） 除了 update 语句外，select 语句如果加锁，也是以后读 select k from t where id=1 lock in share mode;读锁select k from t where id=1 for update;写锁假如事务a对于某一行的以后读（更新或select加锁），事务b正在更新，然而还没提交，此时事务a的以后读会被阻塞

数据结构innodb应用了b+树作为索引主键索引的叶子节点存的是整行数据，也被称为聚簇索引非主键索引的叶子节点存的是主键的值，也被称为二级索引基于非主键索引的查问，先搜寻树失去主键的值，再到主键的索引树搜寻一次，这个过程称为回表，要多扫描一棵索引树，在利用中应该尽量应用主键查问 索引保护B+ 树为了保护索引有序性，在插入新值的时候须要做必要的保护当插入一个两头值，可能会波及到数据页的移动，包含页决裂、页合并自增主键是指自增列上定义的主键，在建表语句中个别是这么定义的： NOT NULL PRIMARY KEY AUTO_INCREMENT，它每次插入都是追加操作，不波及到移动其余记录，不会触发叶子节点决裂有业务逻辑的字段做主键，则往往不容易保障有序插入，这样写数据老本绝对较高（性能）主键应用自增主键，长度比应用字符串更小，一般索引的叶子节点更小，占用的空间也更小（存储空间）当业务场景是只有一个索引、且必须是惟一索引，能够应用业务字段做主键笼罩索引在查问中，索引曾经笼罩了查问所需的所有字段，称为笼罩索引笼罩索引能够缩小树的搜寻次数，显著晋升查问性能，应用笼罩索引是一个常见的优化伎俩最左前缀准则 最左前缀能够是联结索引的最左 N 个字段，也能够是字符串索引的最左 M 个字符索引下推优化，如果一个查问条件蕴含笼罩索引的最左字段与其余字段，查问时会通过笼罩索引去比对其余字段是否满足要求，若不满足则不会去回表惟一索引和一般索引对于一般索引来说，查找到满足条件的第一个记录 后，须要查找下一个记录，直到碰到第一个不满足一般索引条件的记录对于惟一索引来说，因为索引定义了唯一性，查找到第一个满足条件的记录后，就会进行持续检索InnoDB 的数据是按数据页为单位来读写的，对于整型字段，一个数据页能够放近千个 key，因而呈现这种状况的概率会很低。所以，咱们计算均匀性能差别时，仍能够认为这个操作老本对于当初的 CPU 来说能够忽略不计change buffer当须要更新一个数据页时，如果数据页在内存中就间接更新，而如果这个数据页还没有在内存中的话，在不影响数据一致性的前提下，InnoDB 会将这些更新操作缓存在 change buffer 中，这样就不须要从磁盘中读入这个数据页了在下次查问须要拜访这个数据页的时候，将数据页读入内存，而后执行 change buffer 中与这个页无关的操作。通过这种形式就能保障这个数据逻辑的正确性将 change buffer 中的操作利用到原数据页，失去最新后果的过程称为 merge。除了拜访这个数据页会触发 merge 外，零碎有后盾线程会定期 merge。在数据库失常敞开（shutdown）的过程中，也会执行 merge 操作显然，如果可能将更新操作先记录在 change buffer，缩小读磁盘，语句的执行速度会失去显著的晋升。而且，数据读入内存是须要占用 buffer pool 的，所以这种形式还可能防止占用内存，进步内存利用率Change Buffer 的相干设置下面就是写缓存（Change Buffer）的相干常识，写缓存（Change Buffer）咱们也是能够应用命令参数来管制，MySQL 数据库提供了两个对写缓存（Change Buffer）的参数。Change Buffer 参数 innodb_change_buffer_max_sizeinnodb_change_buffer_max_size 示意 Change Buffer 最大大小占 Buffer Pool 的百分比，默认为 25%。最大能够设置为 50%。 innodb_change_bufferinginnodb_change_buffering 参数用来管制对哪些操作启用 Change Buffer 性能，默认是：all change buffer 实用场景change buffer 并不是实用于所有场景，以下两种状况不适宜开启change buffer ： ...

一、概述深刻学习MySQL，从概览MySQL逻辑架构开始。 首先来看一下MySQL的逻辑架构图： MySQL最重要、最不同凡响的个性就是它的存储引擎架构，这种架构将：查询处理、其余零碎工作、数据的存储与提取 三局部拆散。所以，带来的益处就是能够在应用时依据性能、个性，以及其余需要来抉择数据存储形式。 存储引擎架构分为三层，自上而下，分为第一层：连贯层；第二层：服务层；第三层：引擎层。 第一层：连贯层： MySQL的最上层是连贯服务，引入了线程池的概念，容许多台客户端连贯。次要工作是：连贯解决、受权认证、平安防护等。 连贯层为通过平安认证的接入用户提供线程，同样，在该层上能够实现基于SSL 的平安连贯。 第二层：服务层： 服务层用于解决外围服务，如规范的SQL接口、查问解析、SQL优化和统计、全局的和引擎依赖的缓存与缓冲器等等。所有的与存储引擎无关的工作，如过程、函数等，都会在这一层来解决。在该层上，服务器会解析查问并创立相应的外部解析树，并对其实现优化，如确定查问表的程序，是否利用索引等，最初生成相干的执行操作。如果是SELECT 语句，服务器还会查问外部的缓存。如果缓存空间足够大，这样在解决大量读操作的环境中可能很好的晋升零碎的性能。 第三层：引擎层： 存储引擎层，存储引擎负责理论的MySQL数据的存储与提取，服务器通过API 与 存储引擎进行通信。不同的存储引擎性能和个性有所不同，这样能够依据理论须要有针对性的应用不同的存储引擎。 二、连接器当客户端（利用）连贯到MySQL服务器时，服务器须要对其进行认证。认证基于用户名、原始主机信息和明码。 除了根本认证之外，连接器还会进行一些线程的解决。 每个客户端连贯都会在服务器过程中领有一个线程，这个连贯的查问只会在这个独自的线程中执行，该线程只能轮流在某个CPU外围或者CPU中运行。服务器会负责缓存线程，因而不须要为每一个新建的连贯创立或者销毁线程。 连接器：负责跟客户端建设连贯 | 获取权限 | 维持和治理连贯。连贯命令个别如下模式: mysql -h$ip -P$port -u$user -p通过如下语句能够查看以后连贯的信息: mysql> show processlist;+----+------+--------------------+-------+---------+------+----------+------------------+| Id | User | Host | db | Command | Time | State | Info |+----+------+--------------------+-------+---------+------+----------+------------------+| 5 | root | 192.168.33.1:57721 | mysql | Sleep | 29 | | NULL || 6 | root | localhost | NULL | Query | 0 | starting | show processlist |+----+------+--------------------+-------+---------+------+----------+------------------+2 rows in set (0.00 sec)其中"Sleep"代表当初零碎外面有一个闲暇连贯. ...

全局锁全局锁就是对整个数据库实例加锁。MySQL 提供了一个加全局读锁的办法，命令是Flush tables with read lock (FTWRL)。当你须要让整个库处于只读状态的时候，能够应用这个命令，之后其余线程的以下语句会被阻塞： 数据更新语句（数据的增删改）数据定义语句（包含建表、批改表构造等）更新类事务的提交语句应用场景全局锁的典型应用场景是，做全库逻辑备份。也就是把整库每个表都 select 进去存成文本 弊病如果你在主库上备份，那么在备份期间都不能执行更新，业务基本上就得停摆如果你在从库上备份，那么备份期间从库不能执行主库同步过去的 binlog，会导致主从提早 改良形式应用可反复读隔离级别备份时也能够失去一致性视图 一致性读是好，但前提是引擎要反对这个隔离级别。比方，对于 MyISAM 这种不反对事务的引擎，如果备份过程中有更新，总是只能取到最新的数据，那么就毁坏了备份的一致性。这时，咱们就须要应用 FTWRL 命令了全局锁和set global readonly=true的区别有些零碎中，readonly 的值会被用来做其余逻辑，比方用来判断一个库是主库还是备库。因而，批改 global 变量的形式影响面更大在异样解决机制上有差别。如果执行 FTWRL 命令之后因为客户端产生异样断开，那么 MySQL 会主动开释这个全局锁，整个库回到能够失常更新的状态。而将整个库设置为 readonly 之后，如果客户端产生异样，则数据库就会始终放弃 readonly 状态，这样会导致整个库长时间处于不可写状态，危险较高 表级锁表锁表锁的语法是 lock tables … read/write。与 FTWRL 相似，能够用 unlock tables 被动开释锁，也能够在客户端断开的时候主动开释。须要留神，lock tables 语法除了会限度别的线程的读写外，也限定了本线程接下来的操作对象如果在某个线程 A 中执行 lock tables t1 read, t2 write; 这个语句，则其余线程写 t1、读写 t2 的语句都会被阻塞。同时，线程 A 在执行 unlock tables 之前，也只能执行读 t1、读写 t2 的操作，不能拜访其余表 元数据锁MDL 不须要显式应用，在拜访一个表的时候会被主动加上。MDL 的作用是，保障读写的正确性如果一个查问正在遍历一个表中的数据，而执行期间另一个线程对这个表构造做变更，删了一列，那么查问线程拿到的后果跟表构造对不上，必定是不行的。因而，在 MySQL 5.5 版本中引入了 MDL ...

两阶段提交执行器先找引擎取 ID=2 这一行。ID 是主键，引擎间接用树搜寻找到这一行。如果 ID=2 这一行所在的数据页原本就在内存中，就间接返回给执行器；否则，须要先从磁盘读入内存，而后再返回执行器拿到引擎给的行数据，把这个值加上 1，比方原来是 N，当初就是 N+1，失去新的一行数据，再调用引擎接口写入这行新数据引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 外面，此时 redo log 处于 prepare 状态。而后告知执行器执行实现了，随时能够提交事务执行器生成这个操作的 binlog，并把 binlog 写入磁盘执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新实现解体复原时的判断规定如果 redo log 外面的事务是残缺的，也就是曾经有了 commit 标识，则间接提交；如果 redo log 外面的事务只有残缺的 prepare，则判断对应的事务 binlog 是否存在并残缺： a. 如果是，则提交事务；b. 否则，回滚事务。redo log 和 binlog 是怎么关联起来的?它们有一个独特的数据字段，叫 XID。解体复原的时候，会按程序扫描 redo log： 如果碰到既有 prepare、又有 commit 的 redo log，就间接提交；如果碰到只有 parepare、而没有 commit 的 redo log，就拿着 XID 去 binlog 找对应的事务。因为 redo log 和 binlog 是两个独立的逻辑，如果不必两阶段提交会有什么问题？先写 redo log 后写 binlog。假如在 redo log 写完，binlog 还没有写完的时候，MySQL 过程异样重启。因为咱们后面说过的，redo log 写完之后，零碎即便解体，依然可能把数据恢复回来，所以复原后这一行 c 的值是 1。然而因为 binlog 没写完就 crash 了，这时候 binlog 外面就没有记录这个语句。因而，之后备份日志的时候，存起来的 binlog 外面就没有这条语句。而后你会发现，如果须要用这个 binlog 来复原长期库的话，因为这个语句的 binlog 失落，这个长期库就会少了这一次更新，复原进去的这一行 c 的值就是 0，与原库的值不同。先写 binlog 后写 redo log。如果在 binlog 写完之后 crash，因为 redo log 还没写，解体复原当前这个事务有效，所以这一行 c 的值是 0。然而 binlog 外面曾经记录了“把 c 从 0 改成 1”这个日志。所以，在之后用 binlog 来复原的时候就多了一个事务进去，复原进去的这一行 c 的值就是 1，与原库的值不同为什么 redo log 具备 crash-safe 的能力，而 binlog 没有redo log 是什么？ ...

22C4400 – Database Systems Project – Initial 1/28/2019Project ScopeRaman Aravamudhan RSA-22C4400-S19-PROJECT-SCOPEDepartment of Computer Science Page 1 of 5 Version 1.1Note: This document is intentionally incomplete and is in non-standardformat; as part of the course details on requirements will be provided whenasked.Project Scope:A new airline company “Iowa Air” has come to Iowa with Cedar Rapids asits Headquarters. Iowa Air seeks to build their Airline PassengerReservation System (ARS). This airline is expected to attract Iowa andsurrounding passengers in a big way. The Reservation system must besimple, easy to use and offer very high performance. ...

Mysql 专栏 - MVCC机制前言 mvcc机制是mysql解决事务问题一项重要机制，通过这个机制，mysql解决了对于事务的问题：脏写、脏读、反复读的问题，然而默认的不可反复读的状况下还是会呈现幻读的问题。 概述：undo log的版本链条和read view的实现Undo log以及read view如何解决常见的事务问题简略介绍对于独占锁和共享锁的内容mysql事务问题： 事务的问题无非上面两种： 多个事务并发执行的时候，可能会同时对缓存页里的一行数据进行更新，这个抵触怎么解决?是否要加锁?可能有的事务在对一行数据做更新，有的事务在查问这行数据，这里的抵触怎么解决?undo log事务回滚的实现根本介绍： 首先咱们须要理解undo log中存在两个重要的属性，一个是trx_id，一个是roll_pointer，这个trx_id就 是最近一次更新这条数据的事务id，roll_pointer 就是指向你了你更新这个事务之前生成的undo log， 对于undo log之前都讲过了这里不再过多的介绍。 Undo log 版本链 介绍mvcc机制之前，咱们须要先理解对于undo log的版本链条的构造 ，很显著这个机制的引入是为了mvcc的机制铺路筹备的，上面咱们来一一解说undo log回滚机制 是什么？ undo log 版本链条是通过链表的形式，当同一条记录存在多个事务提交的时候，为了保障事务能够失常回滚，会通过roll_pointer 以及 txd_id 实现多个事务版本的串联，同时串联多个版本的值。 比方上面这个undo log版本链条如下所示： 首先，事务A写入了一条数据并且写入的值为A，此时事务A id为50，所以在undo log的链条外面存储的也是trx_id事务B往这一行记录更新一个值B，此时会更新trx_id 为58，并且roll_point 会指向trx_id 为 50的记录如果此时呈现事务C更新数据，依照同样的情理也会呈现一个链表的节点并且将事务C指向trx_id 为69的记录 至此，一个undo log多版本控制链曾经实现，他的构造如上面的模式： 这种设计有什么作用？ 这种设计的作用是，保障多个事务提交的时候一旦须要回滚操作，能够保障同一个事务只能读到比以后版本更早提交的值，不能看到更晚提交的值。 Read view是什么？ read view是mvcc机制的实现一个要害组件，是mysql基于undo log多版本链条实现的，在一个事务开启的时候，默认会为以后事务生生成一个read view表，这个表在事务开启的时候所有的参数都确定，并且在事务完结的时候才会销毁。 一个read view当中外面蕴含了上面的内容，蕴含4个重要的根本字段，其中最重要的是m_ids以及max_trx_id 以及 min_trx_id这三个字段。 一个是m_ids，这个就是说此时有哪些事务在MySQL里执行还没提交的;一个是min_trx_id，就是m_ids里最小的值;一个是max_trx_id，这是说mysql下一个要生成的事务id，就是最大事务id;一个是creator_trx_id，就是你这个事务的id留神max_trx_id是下一个要生成的事务id，之所以这样设计是不便事务id的判断 依照逻辑的简略了解，他的存储构造如下所示，具体的参数的含意会在下文依据理论的案例进行解释，这里只是作为展现数据的存储展现了解即可。 检查和读取步骤 理解了下面的根本结构图之后，上面咱们来理解一下如何读取和检索来实现一个undo log的回滚操作，为了更好的了解咱们须要依据下面的图退出一些模仿的操作来进行解释： 假如事务A须要读取数据，而事务B须要更新数据，事务A的id为50，事务B为58，依照read view的设计，最终会呈现一副上面的状况： ...

写在后面其实这篇我很早就想写了，但始终拖着，周末码几个字，始终拖到了当初。 今年年初的时候，我就给本人定了两个往年必须长期保持的大指标，一个是保持锤炼，另外一个则是保持读书，当然这里指的是非技术类的书。 对于锤炼的事件一言难尽，先不聊了。明天无妨先来聊一聊对于读书打算（非技术篇）的事件。 俗话说得好，业宜精专，书宜读杂。从去年开始，次要我就想多看一点技术以外的杂书，最好是文学、传记、治理、心理、哲学、理财等方面都波及一点。 我还是感觉理工科生抽空读点技术业余以外的杂书也挺好，最次要是能宽阔宽阔思维。 程序员的思维是谨严倒没错，但有时候却不肯定宽阔。所以如果总僵化地守着本人那一亩三分地，不宽阔一下思维，路可能会越走越窄，思维也会变得僵化，从而可能愈发焦虑和迷茫。 所以很多时候咱们有必要换一些角度来看生存，这样也就不至于把本人某些小事看得太过于纠结。 而读书恰好则是一个性价比极高的低门槛路径。 本文在GitHub开源仓库「编程之路」 https://github.com/rd2coding/Road2Coding 中曾经收录，外面有我整顿的6大编程方向(岗位)的自学路线+知识点大梳理、面试考点、我的简历、几本硬核pdf笔记，以及我的程序员人生，欢送鉴赏。读书布局和进度之前的想法是每天晚上睡前抽个四十分钟看一看，然而实际操作下来发现不肯定每天都能管制得这么好，尤其是最近两个月因为太忙，进度又慢下来了。 有时候回来太晚或者切实不想看也就停两天，次要是我也不想这事成为一种心里上的累赘，不然就事与愿违了。 我给本人定的指标是很佛系的，总体打算是一个月能残缺读完一到两本技术之外的书就很称心了，这样一年下来也能读完十几本。如果都能认真看完，并且有所了解和心得，那就十分值得了。 理论状况是，半年过来了，进度总体比预计的要慢一些，不过没啥压力，属于休闲看的那一种。 上面分享一下往年的书单，年初的时候做打算时列的，这些书籍根本都来源于后盾小伙伴的安利举荐，以及羊嫂给我的工作安顿，我从当选的十几本。 也欢送大家在评论区分享出你们感觉不错的书籍或者书单，一起交换看看。 书单《南京传》（已实现）《侧面管教》（已实现）《养育女孩》（已实现）《数学之美》（已实现）《非暴力沟通》（已实现）《软技能·代码之外的生存指南》（已实现）《诗经》（循环看）《软技能2·软件开发者职业生涯指南》（已实现）《债权危机》（进行中...）《怪诞心理学》（进行中...）《弱流传》《被厌恶的勇气》《知行·技术人的治理之路》《偏见》《简单生命的起源》 目前看完的几本包含： 《软技能系列》 正如题目所言，这是两本和程序员本身多元化倒退，以及软件开发者职业生涯非亲非故的书。 书外面讲到了很多无关职场和程序员职业生涯的剖析，各种自我营销路径的解释，集体的继续学习和成长，甚至还聊到了理财、健身、找工作、谈薪、心态调整...等诸多问题，不少看起来都是代码之外的货色。 然而往往就是这些代码之外的软技能，会让人变得更加自信和有竞争力。 诚然，我感觉程序员应该器重代码，但不应该只关注代码，很多代码之外的货色对现如今的生存也十分重要。 《南京传》 作为一个新南京人，听听老南京人讲南京故事就挺好，这本书满足了我的这个欲望。 当你理解了你所在城市的历史，生存于其中的感触是齐全不同的。不得不说，是一本十分优良的城市传记，作者的文字读起来更是令人酣畅淋漓。 《侧面管教》& 《养育女孩》 尽管外表看起来都是育儿方面的书籍，然而看了之后才发现这说的不就是当年的本人嘛。 读完才惊奇地发现原来成年人世界的很多性情缺点以及做事的形式、态度，都无一不和幼时的管教环境无关，甚至那些始终操纵着成年人，让咱们有时候无奈好好生存的不良行为、性情、态度、习惯，竟然都能溯源。 《数学之美》 这本书我应该是三刷了，而且我读的这本还是吴军学生的签名版，所以每次都颇有典礼感。作为一个通信业余进去的同学，外面提到的几十个技术科普主题的实践局部大部分其实都接触过，然而不少的确都曾经忘了，所以看起来总有一种既相熟又生疏的感觉。 但每次刷这本书给我的感觉就是，作者的确高屋建瓴、化繁为简，可能将当年学起来感觉十分难懂艰涩的数学问题解释得通俗易懂，算是深入浅出了。除此之外也联合了很多工程利用方面的货色，也算是更加宽阔了眼界。 《非暴力沟通》 这是一本十分热门的心理学图书，很多人应该都看过。顾名思义，就是应用非暴力的形式进行沟通。 暴力沟通的形式和场景在平时的家庭、生存以及工作中不经意间呈现的频率还是很高的。 “暴力褪去，流露出来的将会是爱”。 这本书里所讲的对于非暴力沟通的剖析和因素实用于日常生活以及工作。个人感觉，尤其是在生活中，我感觉更有用，因为咱们总习惯于将好的一面给他人，而把最差的一面却留了本人最亲热的人。所以无论何时，多一点聆听、多一点了解、多一点真挚、也多一点爱。 《诗经》 作为中国最早诗歌总集，《诗经》所承载的经典和意义想必就不必多说了，满满的都是柔美的文字，有工夫读读新诗美文也挺好的，就当陶冶情操了，没事读读也确实心静。 这中央顺便多提一点就是（个别人我都不通知他），多读读诗经，说不定当前给孩子起名字的时候都能用失去呢，岂不美哉。 后 记所以明天就先聊到这里吧，等年末的时候，会再来回顾一年的读书状况，做一个年度的读书复盘。 不得不说，读书的工夫的确会让人心田感到非常平静和虚浮，忘了压力和焦虑。这种感觉对于当下竞争强烈的程序员们来说真的是十分宝贵了。 最初也欢送大家分享出你们感觉不错的书籍或者书单，一起交换进步！ 另外最近花了大把力量，把自用的编程学习资源做了个大整顿。 都是纯肝货，目录如下。 该内容在GitHub开源仓库「编程之路」 https://github.com/rd2coding/Road2Coding 中曾经收录，外面有我整顿的6大编程方向(岗位)的自学路线+知识点大梳理、面试考点、我的简历、几本硬核pdf笔记，以及我的程序员人生，欢送star。 整顿不易，欢送反对，下篇见。

本文来自涂鸦智能的刘筠松在 PingCAP DevCon 2021 上的分享，包含 TiDB 在 IoT 畛域，特地是在智能家居行业的应用。 对于涂鸦智能涂鸦智能是一个全球化 IoT 开发平台， 打造互联互通的开发规范，连贯品牌、OEM 厂商、开发者、零售商和各行业的智能化需要。基于寰球私有云，实现智慧场景和智能设施的互联互通。涵盖硬件开发工具、寰球私有云、智慧商业平台开发三方面； 提供从技术到营销渠道的全面赋能，打造中立且凋谢的开发者生态。 目前涂鸦在国内外曾经有超过十万家的合作伙伴，在 IoT PaaS 和 IoT 的开发者平台的生态客户数量曾经达到 32 万 +，其波及到制造业、零售业、运营商、地产、养老、酒店（PaaS）等。涂鸦赋能的有欧美品牌和中国品牌，包含飞利浦，国内的海尔以及三大运营商。 海量数据的实时响应：TiKV 选型历程涂鸦的设施在寰球每天解决 840 亿申请，均匀解决顶峰次数能达到 150 万 TPS，均匀响应工夫要求小于 10 毫秒。因为涂鸦是物联网行业，区别于传统行业，没有低峰点，写入量十分大，涂鸦用六年的工夫一直选型尝试，摸索最合适的数据架构。 涂鸦之所以有这么大量的数据，是因为目前人们家里应该都会应用到智能设施，例如智能电灯、扫地机器人，设施联网后就与涂鸦平台有了通信的能力，而智能设施的各种定时触发，比方家里的摄像头巡更、扫地机器人的地位信息都须要上报给涂鸦的 Zeus 平台。Zeus 零碎作为涂鸦平台最重要的角色，负责解决数据上报，业务拓扑如下图所示，利用网关收集到智能设施上报的 MQTT 音讯之后会发送到 Kafka 和 NSQ 下面，Zeus 零碎会生产这些音讯进行解密，解决过后要放到存储外面。本文次要形容的也正是从 Zeus 到存储之间的这段产品选型。 AWS Aurora涂鸦在晚期应用的是 AWS Aurora。Aurora 跟阿里云的 PolarDB 相似，是存算拆散的架构，涂鸦在 Aurora 上稳固运行了三年，在前三年应用中 Aurora 齐全满足需要。物联网在六七年前还比拟冷门，智能家居设施没有这么遍及，用户用的不多，但起初随着业务的扩大，近几年设施呈指数级的成长，每年都要翻三到五倍，Aurora 就无奈接受暴增的数据量，特地是物联网响应工夫要求是 10 毫秒以内，即便进行分库分表，拆散集群也达不到涂鸦的业务需要。 Apache Ignite于是涂鸦开始尝试应用 Apache Ignite，也是一个分布式的 KV 零碎，相似于 PingCAP 的 TiKV，它是基于JAVA 架构进行数据分片的，其分片比拟大，1G 的数据一个 Partition，并且其扩容没有 TiKV 这么线性。如果涂鸦的业务量翻倍，在机器要扩容的时候就不得不停机，还会有数据失落的危险。这个期间咱们在一个 Ignite 前面下挂了 Aurora 作为灾备，数据会同步写到 Aurora 外面。然而随着业务量的暴增，一个 Ignite 也不能满足涂鸦的业务需要，就须要进行扩容，而 Ignite 架构下扩容的时候要求停机，这是物联网所无奈容忍的。 ...

一、背景笔者和团队在昆仑分布式数据库中的两阶段提交形式，能够胜利防止经典的两阶段提交算法的缺点。 而在此分布式事务处理两阶段提交机制和原理上，笔者和团队加强其容灾能力和错误处理能力，能够做到任意时刻昆仑数据库集群的任意节点宕机或者网络故障、超时等都不会导致集群治理的数据产生不统一或者失落等谬误。 本文会详述分布式事务对于两阶段提交算法的错误处理原理和机制及延时损耗~ 二、昆仑数据库如何对两阶段提交算法错误处理？在生产环境的分布式数据库集群的工作场景中，通常只有不到0.01%的分布式事务提交会产生谬误，然而咱们依然须要解决所有可能产生的谬误。 因为哪怕执行了100亿笔事务，只有有1笔产生了提交谬误，都会导致用户数据出错。 数据库系统就是要确保事务永远正确地提交，ACID保障始终成立，没有例外。 这对于分布式数据库系统来说，会比单机数据库更加简单，因为可能的谬误起源更多（多个计算节点和多个存储节点，及其之间的网络连接）。 这也是为什么数据库系统的设计和实现会如此简单，而分布式数据库系统的设计和实现更加简单。 上面，咱们就看一下昆仑分布式数据库集群如何解决分布式事务提交过程中产生的谬误。咱们别离讲述两阶段提交的每个阶段的错误处理，以及批量写入commit log的错误处理。 2.1 第一阶段错误处理 图1. 第一阶段提交失败的解决 如果prepare阶段产生语句谬误，网络断连或者超时，那么GTM会提交rollback记录申请给GTSS，并且不期待其返回后果就立即发送rollback命令给出错的节点并且断连超时的连贯，而后返回谬误给客户端，告知客户端该事务GT被回滚。 GTSS会在commit log中记录GT的提交指令为ROLLBACK, 这样cluster_mgr 随后解决GT的prepared事务分支时会回滚它们。 2.2 批量写入Commit logging 错误处理 图2. commit log写入失败的解决 如果GTSS写入commit log 出错或者超时，那么GTM会回滚GT的所有preapred事务分支，也就是发送XA ROLLBACK给GT写入的所有存储集群，而后不管其后果如何都返回‘Aborted’给客户端表明GT被回滚了。 即便XA ROLLBACK发送失败了那么这个事务分支依然会按预期被cluster_mgr回滚。 2.3 第二阶段错误处理 图3. 第二阶段提交失败的解决 如果第二阶段产生网络谬误或者超时，那么依然返回提交胜利给客户端。 这是因为只有记录了commit log提交的任何分布式事务，都必须实现提交。 如果执行第二阶段期间任何计算、存储节点产生宕机或者网络故障，那么cluster_mgr过程会依据commit log的指令，来解决这些事务分支 --- 如果指令是提交那么就提交GT的所有事务分支。 如果指令是回滚或者无奈找到GT的commit log，那么就回滚GT的所有事务分支。 如果第二阶段进行过程中计算节点宕机或者断网了那么这个事务仍将提交，此时利用零碎后端（也就是数据库的客户端）会发现自己的commit语句没有返回直到数据库连贯超时（通常应用层也会让终端用户连贯超时）或者返回了断连谬误。 三、延时损耗因为两阶段提交的prepare和commit阶段都须要期待存储引擎flush WAL日志，并且在两个阶段之间还须要期待commit log写入元数据集群，所以两阶段提交的时耗肯定比执行雷同的SQL DML语句但做一阶段条会减少一些。 依据这个性能报告：http://www.zettadb.com/blogs/...，昆仑数据库的两阶段提交在一般的服务器硬件配置和千兆网络状况下会减少约30毫秒的延时。 在商用服务器硬件和网络环境下，这个延时减少会少于30毫秒。这个30毫秒包含了commitlog的写入，多执行一个阶段的等待时间以及所有减少的网络通信工夫开销等。 四、总结昆仑分布式数据库的分布式事务处理机制，确保了分布式事务执行和提交的一致性和容灾能力，在事务提交期间任何节点、网络故障都不会导致事务的ACID保障生效，从而确保了用户数据正确。

前言 本文为mysql专栏零碎索引的第一个大节的文章，索引蕴含的内容却是不少， 为了让这些知识点不过分的沉积在一起，这里会将本文拆分为多个大节，并且后续的内容会逐步加深，本文更多是为索引的深刻了解进行概念性的讲述，蕴含索引的根底构造页目录和数据页的关联，以及索引如何依据页目录扩大主键目录，以及后续的索引页的设计介绍进行前置内容的解说。 概述索引页的根底构造：数据页和页目录的介绍，介绍对于页决裂的细节，他是mysql保护索引的一项重要个性，间接影响索引的查问效率。对于全表扫描的根底步骤了解，以及主键查问原理简略介绍，后续会做更加具体的介绍。对于索引的概览：主键索引和BTree索引的根底设计介绍。索引的根底构造数据页 之前介绍过数据页的根本逻辑构造，在理解索引之前，咱们先来理解索引的物理构造，首先咱们须要晓得在磁盘上大抵如何存储： 在磁盘文件的构造：数据页的每一行其实是一个二进制的非凡格局，每一个数据页蕴含指针，一个指向上一个数据页，一个指向下一个数据页，也就是说数据页是用双向链表进行串联的。总而言之，数据页是多个链表进行串联的，那么依照推理数据行其实也是链表的形式进行存储的，不过应用的是单向的链表，并且数据行是依照主键从小到大进行排序的。 页目录 理解数据行的构造之后，接着就是和索引无关的构造，这个构造叫做页目录，为了保护数据页，每一个数据页的头部会蕴含页目录，依据数据行的主键进行寄存，数据行同时被扩散到不同的槽位下来。能够说页目录是一个从小到大排序的一个动静数组，外面寄存的是键值对内容，键就是主键，值就是对应的数据页的数据行。 针对下面数据页和页目录，咱们来看下整个页目录和数据页的的根底构造： 页决裂 既然提到了页目录和数据页的构造，上面须要介绍一个和索引无关的重要个性：页决裂。页决裂说的是在传统的物理存储构造上，数据页之间都是应用双向链表进行串联的，数据页内的数据行是单向链表的模式进行串联，比方像下面这样，此时如何咱们新插入一条数据，会把数据依照链表的模式串联起来，并且如果主键是自增的状况下，他会依照主键自增的程序进行链接。 下面的状况在主键自增的状况下通常没有什么问题。然而如果你的主键不是自增的，比方当初你插入12，下一次你插入8，就会呈现问题了，此时就会很页决裂，对于页决裂的内容，能够看上面的格局： 什么是页决裂？ 简略来讲，在一个多链表链接的多个数据页外面，页决裂会把一个主键较大的值移动到新的的数据页，而新插入的主键较小的值会移动到之前的数据页 1. 比方如果咱们不依照自增的形式增长主键，就会呈现上面的形式。 接着，依据页目录的保护规定，须要对于数据也进行挪移的动作，其实挪移的规定很简略：把主键更大的值挪到更新的数据页，把更小的值挪到一起。 页决裂对于mysql的索引有哪些影响? 页决裂的行为会影响mysql的索引，可能会呈现mysql找不到数据所在的页呈现全表扫描 全表扫描 理解了数据页和页目录的根底构造之后，咱们来看下全表扫描是如何解决的，全表扫描其实是数据页一直加载到缓冲区的过程，这个过程在之前的文章有过介绍这里不做过多赘述，在没有索引的状况下，数据页加载到缓冲区只能依照数据页的链表一个个拜访，比如说加载第一个数据页没有找到数据，就加载第二个，没有第二个就加载第三个，以此类推，最初找到咱们想要的数据为止，如果数据页非常多然而须要的数据零散的散布在少数的数据页上，这样的查找效率是非常低的。 最初咱们针对索引做一个简略的介绍，这就好比你去图书馆找书，你要把所有的货架都扫完了能力找到你要的书，这样未免就太慢了，页目录就如同一个小册子，标记那一个货架有你要的书，而后找到对应的货架去扫描就行了。。 为了放慢这个查找速度，咱们最先想到的是主键查问的形式： 主键查问的原理 其实晓得了页目录之后，咱们就晓得主键是如何查找的，主键是依照从小到大的程序排序的，查找主键其实就是二分查找的形式依照页目录的排序进行查找找到对应的主键，而后取出对应的的槽位并且找到对应的数据页进行扫描，而数据页之间也是链表查找，找到数据页之后找到对应的数据行就行。这就是主键查问的大抵思路。 索引介绍主键索引 什么是主键索引？之前的页决裂咱们理解了数据页会在主键上把主键的内容进行排序。而主键索引实际上就是针对主键制作一个主键目录，把每个数据页的页号，数据页最小的主键值放大一起，组成一个索引，这样通过找到最小的主键号就能够疾速的找到对应的数据页和数据行了。 主键索引的结构图如下： BTree索引（重点）索引页的设计模式 接下来就是本文的重点也是mysql重要的btree索引，在具体的理解之前，咱们须要理解一下他的索引设计构造，也就是索引页。 什么是索引页？大家能够思考一下，如果把索引页和数据页离开成为独自的构造，其实是非常不不便的，这样增大了磁盘扫描和数据加载到内存的开销，并且数据页太多了之后存储页非常不不便，所以其实索引也是被设计为“数据页”的，只不过存储的内容和个别的数据页不一样，存储的是每个数据页的最小主键。这里为了更好的了解，咱们从逻辑上把他们拆分为两种表现形式，上面咱们用结构图来示意索引页的设计模式: 然而遇到一个问题，如果把索引页全都是平级的关系，会不晓得找到哪一个索引页，所以在索引页存在上下级的关系，接下来咱们又能够把索引页多加一个层级进去，在更高的索引层级里，保留了每个索引页的索引页的号码和索引页里的最小主键值： 咱们假如索引页如下面的设计，首先索引要先从35找到索引页1，而后应用索引页1的二分查找定位到指标的索引页，找到比方在数据页8外面有数据，而后找到数据页8的数据行进行扫描，找到最初的数据。因为在存储的过程中一直的决裂出一个层级，能够发现这种派生的形式其实就是组成一个bTree 的树。 以上就是对于BTree索引的大抵设计概览，当然理论的细节远远没有下面说的简略，然而下面的内容能够根本理解对于索引的设计规定。 总结 这一节更像是对于mysql索引的底层入门介绍，然而内容并不算十分复杂。 写在最初 mysql的索引第一篇，对于索引更多的内容将会在后续的大节持续深刻。

小伙伴们大家好，JuiceFS v0.17 在国庆小长假降临之际如期公布了！这是咱们在 2021 年秋季推出的第二个版本，让咱们直奔主题，看看都有哪些新变动吧。 本次更新累计 80+ 提交，共有 9 位来自 JuiceFS 社区的小伙伴在 GitHub 上奉献代码。在这里，咱们向每一位贡献者示意最诚挚的感激，同时欢送屏幕前的你也退出到 JuiceFS 开源社区，奉献代码、文档或探讨想法。 通过 LTP 1270 项测试，Linux 零碎下兼容性更完满JuiceFS 的最新版本针对 Linux 零碎环境做了进一步的优化，改良了 rename 和 setxattr 读其余参数的反对，顺利通过了 LTP 的 1270 项测试。 LTP（Linux Test Project）是一个由 IBM，Cisco 等多家公司联合开发保护的我的项目，旨在为开源社区提供一个验证 Linux 可靠性和稳定性的测试集。LTP 中蕴含了各种工具来测验 Linux 内核和相干个性。测试后果： Testcase Result Exit Value-------- ------ ----------fcntl17 FAIL 7fcntl17_64 FAIL 7getxattr05 CONF 32ioctl_loop05 FAIL 4ioctl_ns07 FAIL 1lseek11 CONF 32open14 CONF 32openat03 CONF 32setxattr03 FAIL 6-----------------------------------------------Total Tests: 1270Total Skipped Tests: 4Total Failures: 5Kernel Version: 5.4.0-1029-awsMachine Architecture: x86_64其中，跳过和失败的我的项目次要是因为几个尚未反对的性能，详情见此文档。 ...

随着物流行业的一直倒退，物流企业中波及生产、运输、仓储及运送流环节中的各类数据增长迅速，出现数据量大、数据类型多、价值变现难的特点。作为中国大宗物流的领导企业，山西快成物流科技有限公司（简称“快成物流”）利用 TiDB 一栈式数据服务平台实现全流程精细化经营，减速海量数据的价值变现，进一步驱动产业翻新。 山西快成物流科技有限公司（简称“快成物流”）是以新一代信息技术为外围的“互联网 + 大宗物流产业链生态”的平台型科技企业，网络货运排名跻身全国前三。快成物流保持数据驱动，以“网络货运”外围业务为抓手，打造“大宗商品数字物流产业链”。目前平台服务车辆超 58 万，注册司机超 60 万人，货主近 3 万家，全国年运复数超 700 万单，年运费额超 100 亿元。 实时交易和海量剖析瓶颈凸显 快成物流的业务数据类型多样，包含车辆运单结构化数据、行车轨迹时序数据、司机行为数据、订单发票凭证图像数据等。在业务高峰期，平台产生大量的接单和抢单操作，对数据库的高并发承载能力要求严格，大量结算业务对一致性要求刻薄。此外，快成物流须要对大宗货物的行车轨迹数据进行实时统计和剖析，以便对行车路线优化、运价调整作出实时决策。 快成物流原先应用 MySQL 集群，在多维度查问、关联查问等方面都会受到制约，性能问题成为制约业务倒退的瓶颈。**特地是在 MySQL 主库执行大批量更新操作的时候，主从集群的同步提早问题比较突出。思考到业务数据量的一直增长，快成物流思考选用一款既能反对事务，又能弹性扩大满足海量数据查问需要的数据库系统。 构建新一代实时数据平台 通过比照测试与利用兼容验证后，TiDB 数据库在扩展性、海量数据规模下的查问性能、事务完整性等方面表现出色，快成物流决定选用 TiDB 分布式数据库构建新一代数据服务平台。 快成物流在私有云上部署 TiDB 集群，迁徙外围业务到 TiDB，撑持接单、抢单、订单、行车轨迹、合同发票等多个业务利用以及综合经营治理和办公治理利用。此外，TiDB 与数据湖无缝连贯，为各类大数据分析提供数据源。在 TiDB 集群自身的高可用根底上，快成物流通过 MySQL 和私有云建设多级灾备体系，全方位保障业务的连续性。 图1：快成物流新一代数据平台逻辑架构 快成物流联合大数据、人工智能和物联网等先进技术，用数字连贯司机、车辆和货物，打造“数据物流运营商”的翻新业态。随着 TiDB 新一代数据平台的深刻利用，快成物流用数据驱动的全流程精细化经营开始浮现效益：基于订单和轨迹类等业务数据的剖析，快成物流能够精准实现对大宗物流的超载管制，进一步优化返程布局、升高货车的空载率，在异样天气提供更正当的动静运价调整策略。TiDB 的利用价值次要体现在以下几个方面： 多场景反对一个 TiDB 数据平台撑持多个业务场景，残缺的 HTAP 能力同时撑持海量数据的事务交易（OLTP）和实时剖析（OLAP）。在满足数据一致性的根底上，TiDB 反对高并发读写，提供分钟级统计分析，有助于业务更灵便的决策和变更。TiDB 领有高度凋谢的数据生态，具备残缺的数据离线、实时同步工具，可与 Flink、Spark、BI 等大数据生态构建实时或离线的数仓体系。 开发效率晋升一倍面向未来的云原生分布式架构提供业务无感知的主动伸缩能力，可独自扩大计算或者存储，无需通过利用实现分布式事务。TiDB 对利用开发和数据模型设计无侵入，反对敏态开发和在线业务变更，与原有数据库系统相比开发效率约晋升一倍。 运维老本升高 50%TiDB 反对 Java, Python, Golang 等所有可对接 MySQL 的开发编程语言和 ORM 框架，提供在线迁徙工具。TiDB 内置的图形化 TiDB Dashboard 及 Prometheus 监控零碎，提供残缺闭环监控能力和故障剖析能力，运维老本升高 50% 左右。 ...

2021年2月21日，公众号“架构之美”发表的一篇《是的，我守业了！》刷爆IT业界，资深架构师孙玄在文中写道：“为中国 IT 教育培养行业做出一点点奉献，让 IT 教育培训取得应有的尊严，对于我来说，这样的人生会更加精彩和炫目。”2021年9月中，新在线IT职业教育平台奈学教育再取得一笔A1轮融资，金额为5000万元，两月内累积融资8000万元。《科创人》有幸失去机会，与IT江湖人尊称“玄姐”的孙玄复盘守业600天来的点点滴滴。 玄姐下海心路：咨询服务小众，教育普惠公众在IT业界，提起架构师常识分享畛域的KOL，必然会提及来自58系的两位同门好友：孙玄（公众号：架构之美）、沈剑（公众号：架构师之路）。2011年，沈剑第一次与孙玄单干，便感到本人遇见了同类：彼此都是“架构清新强迫症”患者。孙玄决定守业之后，沈剑在《最好的敌人守业了，我必须要为他站台》一文中还提到，“不愿长期在旧的业务架构修修补补，总想着新业务，设计新架构，是很多架构师的偏执”。 不愧是至亲好友，这句话用于形容孙玄最是贴切不过，他不仅对于58团体外部的业务翻新极为上心之外，还非常关注技术畛域的趋势变动，一直思考着关乎人生的业务翻新。 2014年，孙玄受友人之邀，首次试水企业内训。接下来的五年工夫内，每到周末孙玄便化身空中飞人，见惯了北京的深夜与生疏城市的凌晨，被友人质疑“是不是在那个城市有了新女友”……代价惨重，播种亦是微小，除了经济收益，“航行模式”人生帮忙孙玄拓宽了格局边界、晋升了思维强度、结缘了大量优质人脉，还带来了将来事业的可能性：“我发现技术人才的成长存在系统性缺点，进入到企业之后，大部分技术人繁忙于具体的工作、不足无效的自我晋升，而IT技术兼具深度与疾速迭代属性，如果不能继续学习，就会呈现薪水一直晋升、能力反而倒退的悖离状态，最终因为个体ROI过低导致淘汰，这就是IT圈35岁景象的实质”。 察看到这一景象之后，孙玄感触到内心深处的一股力量逐步沉睡，它既是谋求更高人生境界的能源，又是承当一份惨重责任的使命感。他先是与开课吧单干试水技术大课《百万年薪架构师》，激发市场千层巨浪。试水胜利之后，他决定守业，真正投身职业教育事业。 “你疯了？百万年薪、几千万期权不要了？”这句话的出处，江湖传言有多个版本：孙玄的家人、孙玄的老板、孙玄的共事……孙玄笑着给出了官网认证：以上都对，“很多人都劝过我，可为了本人的幻想、为了中国IT技术晋升、为了IT教育行业真正取得尊重、为了帮忙更多的技术兄弟姐妹领有更好的人生，我必须守业。” 2019年中，他向老板动摇表态，确定工作至大年三十，站好最初一班岗。 2020年1 月 23 日武汉封城，1 月 25 日北京客运全副进行，1 月 30日北京住处的小区有人确诊……万般意外临头，2月1日凌晨，孙玄依然顶着疫情带来的微小不确定性抵京。 2020年2月2日，没有鲜花、没有典礼、没有一顿像样的聚餐、甚至没有合影留念，带着口罩、啃着泡面（购自京东）的6位IT大汉，正式点燃了奈学教育的第一把炬火，强劲而亮堂。 ▲奈学教育创建之初的第一张个体合影，在某山庄闭关研究至深夜，推门见瑞雪。 起航之初被投资人疯抢第一要务是确立奈学的特别之处科创人：守业最后的一个月内，让您印象最深的霎时是什么？ 孙玄：有两件印象很深的事，第一是我那篇《是的，我守业了》发表后的第二天，就有几十家风投找了过去，从ts（投资意向书）到打款周期很短。非常感谢大家的认可，让我对将来更有信念。 其次是倒退比拟快，我之前与开课吧的单干毕竟有一些积攒，做出产品的工夫周期比拟短，3月就上线售卖，当月支出几十万元。2月2日那天还有人开玩笑，“咱们6集体租的工位是不是有点多呀”，后果很快空间就不够了，还得扩。 科创人：除了您之前集体积攒的品牌优势、产品劣势、人脉资源优势之外，创建奈学教育之初，您如何思考奈学的中长期策略定位和差异化劣势？ 孙玄：我认为传统的职业技术培训大都是割韭菜：首先，大部分都是用同一款产品收割不同的人群，撑持这一模式的燃料是流量，一直的找韭菜、割韭菜，但这并不能解决IT人成长的基本问题，他们真正须要的是在科学合理的培训体系下，继续学习、一生成长；其次，传统的教育形式下，受教育者的吸收率并不高，咱们粗略判断只有30-50%，最大的问题在于IT技术是一种实用技术，脱离场景只讲授基础知识、原理，很难被不足根底和教训的同学排汇，陷入了“听懂能力学会，可学会能力听懂”的怪圈。 对应这两个市场痛点，奈学确定了本人的教育模式，它不是一门课程，而一整套残缺的技术人才成长打算，依据学员所处的技术能力阶段抉择针对性的造就形式，每晋升到下一个档次，都有帮忙学员进一步晋升的课程和培训办法，这种模式从价值角度说，能真正解决技术人员成长不间断的主观困境，从商业模式角度说，奈学要与学员短暂走上来，大家独特谋求美妙的后果，能力产生复购，这样的培训模式才算得上工夫的敌人。 第二，在教学过程中，咱们构建了大量实在场景的实战型内容平台，让学员在上战场之前感触到战场的变动、残暴和压力，利用本人所学的常识解决工作中确定会遇到的挑战和难题。 科创人：奈学教育打算服务的客群是细分某一部分，还是全量的IT从业人员？ 孙玄：起步阶段咱们肯定是服务与课程内容相干的业余人群，比方最后的Java、大数据学科，后续咱们将不断完善课程体系。谈指标的话，中国3000万IT从业者，我认为奈学首先要服务好这些人——不是下限指标，而是第一阶段的指标。 不聚焦的教训：三门课程回归两门课保持策略广度：奈学教育到奈学团体 科创人：应该如何了解这个事件：作为一个教育机构，笼罩全副从业者却只是上限，是起始？ 孙玄：奈学教育的底层价值是教育+科技的模式赋能中国科技翻新，翻新的主体当然包含咱们3000万IT从业者，但也包含那些一直做出各种新尝试的守业企业。所以奈学未来存在一种可能性，咱们除了通过教育培训间接赋能企业之外，还要开拓一条中转的通道，以技术培训、技术产品的模式间接为企业提供服务。 最近的融资布局便包含了To B服务这一部分，将来奈学教育会降级为奈学团体，以多种形式赋能企业，晋升中国整体的技术水平。 科创人：在起步不到两年的期间便做出了如此巨大的布局，会不会有人放心，奈学在教育领域的深耕水平不够、过早分兵？ 孙玄：这是个很大的话题，须要在不同的维度下探讨： 在战术层面，过早的分兵、自觉扩张，的确会出问题，奈学吃过不够聚焦的亏。去年8月份，咱们就遇到了一个难关，只是不像个别守业公司是倒退不起来的问题，奈学的问题是倒退太快。 2020年8月，在Java和大数据课程取得成功之后，咱们便迅速推出了略欠打磨的第三门课程，并在营销端大举进攻。后果不仅没有让第三门课迅速占领市场、退费率很高，还牵累了之前口碑十分好、销量增长态势不错的两门拳头课程，100万营销费用进来，80万销售额回来，不算其余老本都曾经亏本。那段时间团队士气都出了问题，庄重复盘之后咱们确定，不能自觉扩张，奈学须要粗劣、有深度、具备绝对优势的课程产品，而不能为了谋求销售额自觉提速。乏味的事，膨胀了产品线，却带来了销售额的快速增长，2021年7月咱们的销售额曾经冲破了1000万元，次要奉献还是来自Java和大数据学科。 但在策略层面，我认为要有前瞻性，没有人能完满地预判将来，但只有思考分明奈学提供的底层价值到底是什么，就不会有太大的动作偏差。后面说了，无论是集体教育培训，还是企业技术培训，还是间接提供技术解决方案甚至提供产品，都围绕着奈学的底层价值构建。 当然，这方面的动作咱们会十分审慎，目前以绝对规范的我的项目制模式，与一些高动向的单干企业开展试点，一直摸索B端业务低成本规模化复制路线。在很长一段时间内，奈学的外围业务都仍将是教育培训。 IT从业者目前是3000万的规模，如果奈学可能进一步成长、赋能整个数字化产业，这部分在将来将是2~3亿的从业人员规模，可能笼罩这部分人群，奈学才有可能成长为千亿市值的平凡企业。 治理心得：因材施管科创人：守业企业一把手，不仅是策略掌舵者，也是治理文化的制定者，比照守业前后，在治理方面您有哪些心得？ 孙玄：守业之前最多治理过300多人的团队，奈学也是300多人，但300人研发团队面向的是同一个工种，但守业后，各个职能部门、业务部门都须要建设治理办法，还要和投资人去搞好关系。 针对不同团队要采取不同的治理格调，比方销售就是指标要严格、处分要及时，咱们的销售要立书面军令状，有军事化治理的色调，可只有实现了，他们的支出肯定高过行业平均水平20-30%；而对于产研团队，治理办法要温顺一些，多与大家进行感性层面的交换沟通。 科创人：问一个具体的场景问题：业务侧出身的创业者，在守业初期常常会与营销团队产生摩擦，奈学是否也经验过这样的阶段？ 孙玄：摩擦是必然产生的，不过奈学从一开始就十分留神甄别合作伙伴的价值观，只有底层价值认知绝对统一，具体方法层的摩擦大家也都容易了解。而且我提倡指标驱动，充沛受权，定下共识指标后我只负责提供资源，不干预太多具体工作。一个月不行两个月，两个月不行可能就要淘汰一部分人。 ▲孙玄的办公室内，各路销售俊杰立下的军令状。 守业常见坑：如何放弃输出？科创人：越来越多的投资人和创业者将“生意”视作贬义词，他们不心愿本人做的事件变成“能赚点钱但没什么成长”的状态，奈学如何防止本人成为一门生意？ 孙玄：我意识的创业者大抵有两种，一种是有多少资源办多小事，一种是明确指标后玩命去攒可能实现目标的资源，我属于后者，从不思考本人有什么，只思考本人须要什么。 奈学的顺利起步也给了我更大的底气，让我敢于接触最好的专家、最好的老师、最好的营销团队，独特实现一个平凡的指标。 科创人：很多源自“工作成绩”的创业项目都难以跳出这样一个怪圈：在实战场景中积攒、输出的价值与能力，在守业场景一直的输入、耗费下逐步成为“旧识”，最终落后、被淘汰，奈学作为一个教育组织，在脱离了实战场景之后，如何放弃本身能力的继续成长？ 孙玄：奈学教育有残缺的迭代翻新流程，甄别——立项——打磨——出品，一方面技术更新频率快、强度大，但真正具备长期价值的技术创新占比不大，须要察看和确认，教育自身并不是追新的产业，适宜急躁察看之后再系统性积淀。一旦确定某项新技术值得出品课程，就像后面说的，咱们会找到行业最顶级的专家、最优良的实践者，邀请他们来到奈学教育的大舞台之上，将本人的常识复制给更多的技术人，发明更大的价值。 2021年的孙玄2040年的孙玄与奈学 科创人：比照2020年之前的孙玄，2021年的孙玄哪一部分能力晋升最大？ 孙玄：首先是事业层面能力的全面晋升，我在守业之前也是企业的外围管理层，也会有一些想法，但那些想法大多还是拘囿在产品、技术团队内，还是一个“参与者”的角色，很难将本人的实在想法写进企业的DNA里。 但守业之后，要思考的是全局，守业自身是将创始人的能力映射到整个团队的过程，奈学的方方面面都受到我的影响，肩膀上的责任也重得多。好在我的迁徙能力和学习能力都不错，对本人也比拟狠，能被动突破舒服区，奈学的高层和基层根本都是每天一复盘、一天一迭代，有着“高强度高支出高成长”的团队文化。 科创人：您心愿20年后的孙玄，是怎么的一个人？ 孙玄：我心愿20年后，孙玄可能率领着奈学成为华为一样，真正通过课程、通过产品取得成功的企业，心愿奈学曾经成为了一家千亿市值的企业。 说到千亿市值，并不是在谈钱多钱少。前两天我在谈融资的时候，一个投资人问我，如果你做一家100亿人民币市值的教育公司，你会不会满足，我说如果我的指标仅仅是如此，可能并不需要进去守业。我的内心深处有一件想做的事，这件事很难，但做成了会很有价值，只有做成了这件事，天然就会达到千亿市值的规模，如果没有达到，只能说我还没有做好。

端到端的实时计算：TiDB + Flink 最佳实际作者简介孙晓光，PingCAP Community Development 团队负责人，原知乎根底研发团队架构师，长期从事分布式系统相干研发工作，关注云原生技术。 本文来自孙晓光在 Apache Flink x TiDB Meetup · 北京站的演讲，次要分享了知乎在 TiDB x Flink 批流一体方面的局部工作，并以理论业务为例介绍如何充分利用两者的特点实现端对端实时计算的闭环交付。 背景上图是十分典型的实时数仓链路上的各个组件和数据，能够看到在很多中央 TiDB 和 Flink 都能够联合在一起去解决咱们的业务问题。比方 TiDB 的大本营是在线交易，所以 ODS 是能够利用 TiDB 的，后边的维表和利用数据存储等也都能够利用 TiDB。 实时业务场景场景剖析先看一下知乎这边一个理论的业务场景，知乎主站上的创作核心为创作者提供了内容交互数据的剖析能力。创作者能够在这看到本人创作的内容所取得的同意，评论，喜爱，珍藏的数据以及过来一段时间内这些数据的变动。这些数据能够帮忙创作者更好地优化本人的创作。比方创作者对内容做了一些调整，而后发现交互数据开始产生显著的变动，创作者就能够基于这个信号对内容做相应的调整，去躲避不好的或者进一步发扬光大好的策略，因而对创作者具备十分大的价值。另外，这个数据越即时，创作者的策略调整就能越即时。比如说创作者刚追更了一篇答复，心愿立即就能够看到相干的数据变动，如果数据变动是正向的，下次就能够做更多相似的调整。或者形象进去过来好的调整都是什么，这样每次都能够基于之前的教训做出读者更喜爱的创作。 惋惜对创作者这么有价值的数据目前依然是不是实时的，大家能够在右上角看到数据更新的阐明。这是咱们在实时利用上还没有笼罩得足够好的一个证据，还是用传统的 T+1 的技术去实现的一个产品。 Flink 是咱们把相似创作核心这样的利用场景实时化必然的抉择，然而同大量应用 MySQL 的公司不同。知乎站上靠近 40% 的 MySQL 数据库曾经实现了到 TiDB 的迁徙，所以咱们必须将 TiDB 和 Flink 的实时计算能力做一个深刻的整合。在将来当 TiDB 成为咱们相对主力数据库的时刻，可能取得更好的综合收益。 接下来咱们探讨如何将内容交互数据的统计实时化，利用 TiDB 和 Flink 实现答复和文章这两种内容的喜爱、评论和同意数据的实时计算。 业务数据模型剖析图中是对这些数据进行实时计算所须要关注的相干业务，这几个业务包含问答也就是右边的 QA，还有左边的专栏文章，以及评论、用户交互、视频答复。咱们心愿通过整合这些扩散在不同业务外面的数据，失去创作者中心里的用户交互的统计数据，而且咱们心愿它是实时的。首先咱们先放大一下问答业务，右边是 QA 业务里比拟根底的几个根本表，本质上咱们并不需要为计算交互信息理解到所有表所有的细节，只须要关注左边这几张表的局部字段就能够了。从这些表里咱们只须要晓得答复的 id，这个答复创作者的 member_id 还有被点赞的答复 id，就能够残缺地计算某一个人的某一个答复有多少点赞。与此类似的是专栏文章，这边同样列出了一些根底表。如果要去做专栏文章的点赞这件事件的实时计算，咱们关注 article 和 article_vote 这两张表，利用 member_id、id 和 vote 字段能够非常容易的计算失去文章的点赞数。除了在业务零碎内的点赞交互数据，其它类型的交互数据扩散在多个不同的业务零碎中。比方评论零碎的 comment_relation 表，视频答复的 vote 表，还有其它交互的 reaction 表。基于这些用户的行为数据，再加上内容数据就可能计算失去用户创作的残缺交互数据了。从业务模型上能够失去交互数据计算的实质是把各种不同类型的内容和各种交互行为的数据作为源表，而后依照对这些数据以内容的 ID 分组进行聚合计算。比如说点赞就是一个 count 计算，因为表里一行数据就是一个点赞。如果说它是一个分值，那么这个数据的计算就是 sum。在拿到所有内容和所有交互聚合的后果后，再次同内容表做一个左连贯就能拿到最初的计算结果了。 ...

从 MySQL 8.0.4 开始，默认身份验证插件从 mysql_native_password 更改为 caching_sha2_password。相应地，当初的 libmysqlclient 将应用 caching_sha2_password 作为默认的验证机制。 为什么这样做呢？ MySQL 5.6/5.7 的默认明码插件始终以来都是 mysql_native_password。其长处是它反对 challenge-response 机制，这是十分快的验证机制，无需在网络中发送理论明码，并且不须要加密的连贯。然而，mysql_native_password 依赖于 SHA1 算法，但 NIST（美国国家标准与技术研究院）已倡议停止使用 SHA1 算法，因为 SHA1 和其余哈希算法（例如 MD5）已被证实非常容易破解。 此外，因为 mysql_native_password 在 mysql.user 表中 authentication_string 字段存储的是两次哈希 SHA1(SHA1(password)) 计算的值 ，也就是说如果两个用户帐户应用雷同的明码，那么通过 mysql_native_password 转换后在 mysql.user 表失去的哈希值雷同。只管有 hash 值也无奈失去理论明码信息，但它依然通知这两个用户应用了雷同的明码。为了防止这种状况，应该给明码加盐（salt），salt 基本上是被用作输出，用于转换用户明码的加密散列函数。因为 salt 是随机的，即便两个用户应用雷同的明码，转换后的最终后果将产生较大的变动。 从 MySQL 5.6 开始反对 sha256_password 认证插件。它应用一个加盐明码（salted password）进行多轮 SHA256 哈希（数千轮哈希，暴力破解更难），以确保哈希值转换更平安。然而，它须要要么在平安连贯或明码应用 RSA 秘钥对加密。所以，尽管明码的安全性更强，但平安连贯和多轮 hash 转换须要在认证过程中的工夫更长。 为了克服这些限度，从 MySQL 8.0.3 开始，引入了一个新的身份验证插件 caching_sha2_password。从 MySQL 8.0.4 开始，此插件成为 MySQL 服务器的新默认身份验证插件。caching_sha2_password 尝试一个两败俱伤的联合，既解决安全性问题又解决性能问题。 首先，是 caching_sha2_password 对用户明码的解决，其实次要是 sha256_password 的机制： ...

本文首发于 2020-05-05 21:55:15一、前言从接触MySQL开始断断续续的看过一些文章，对count()操作七嘴八舌，其中分歧点次要在于count(1)和count(*)哪个效率高，有说count(1)比count(*)快的（这种说法更广泛），有说二者一样快的。集体了解这两种行为可能实用于的是不同的版本，我只关怀较新的MySQL版本是什么行为，详见下文。 二、含意首先，先阐明一下常见count()操作及含意： count(*)：计算包含NULL值在内的行数，SQL92定义的规范统计行数的语法。 count(1)：计算包含NULL值在内的行数，其中的1是恒真表达式。 count(列名)：计算指定列的行数，但不蕴含NULL值。 三、具体区别MySQL手册中相干形容如下： For transactional storage engines such as InnoDB, storing an exact row count is problematic. Multiple transactions may be occurring at the same time, each of which may affect the count. InnoDB does not keep an internal count of rows in a table because concurrent transactions might “see” different numbers of rows at the same time. Consequently, SELECT COUNT(*) statements only count rows visible to the current transaction. ...

本文首发于 2019-12-09 19:37:101. 概念自增列，即 AUTO_INCREMENT，可用于为新的记录生成惟一标识。 要求： AUTO_INCREMENT 是数据列的一种属性，只实用于整数类型数据列。AUTO_INCREMENT 数据列必须具备 NOT NULL 属性。2. 应用办法2.1. 创立含自增列的表-- 不指定 AUTO_INCREMENT 的值，则从1开始mysql> create table t1(a int auto_increment primary key,b int);Query OK, 0 rows affected (0.01 sec)-- 手动指定 AUTO_INCREMENT 的值mysql> create table t2(a int auto_increment primary key,b int) AUTO_INCREMENT=100;Query OK, 0 rows affected (0.02 sec)2.2. 插入数据-- 不指定自增列mysql> insert into t1(b) values(1),(2);Query OK, 1 row affected (0.00 sec)mysql> select * from t1;+---+------+| a | b |+---+------+| 1 | 1 || 2 | 2 |+---+------+3 rows in set (0.00 sec)-- 指定自增列mysql> insert into t1(a,b) values(3,3);Query OK, 1 row affected (0.00 sec)2.3. 如何查看表的 AUTO_INCREMENT 涨到了多少？mysql> show create table t1;+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+| Table | Create Table |+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+| t1 | CREATE TABLE `t1` ( `a` int(11) NOT NULL AUTO_INCREMENT, `b` int(11) DEFAULT NULL, PRIMARY KEY (`a`)) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 |+-------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+1 row in set (0.00 sec)2.4. 插入数据时是否有空洞？能够的，但要留神 AUTO_INCREMENT 的值肯定比自增列以后最大的记录值大。 ...

本文首发于 2019-04-22 20:56:521. MEMORY 引擎简介可能有的敌人对MEMORY存储引擎不太理解，首先介绍一下（以下形容来自官网）： MEMROY存储引擎（以前称为HEAP）的表把表构造寄存到磁盘上，而把数据放在内存中。每个Memory表只理论对应一个磁盘文件，在磁盘中体现为.frm文件。因为它的数据是放在内存中的，并且默认应用hash索引（也反对B-Tree索引），因而Memory类型的表访问速度十分快（比应用B-Tree索引的MyISAM表快），然而一旦服务敞开，表中的数据就会失落。因为MEMRORY表在mysqld重启后数据会失落，为了取得稳固的数据源，能够在启动mysqld时增加--init-file选项，把相似insert into ... select或load data的语句放进去。MEMROY存储引擎的典型实用场景蕴含如下特色： 波及瞬态非关键数据的操作，如会话治理或缓存。数据能够齐全放入内存而不会导致操作系统替换虚拟内存页，并且要求快速访问。只读或以读为主的数据拜访模式（无限的更新）。对于性能： 在解决更新时，单线程执行和表锁开销导致的争用会限度MEMORY性能。只管MEMORY表在内存中进行解决，然而对于忙碌的服务器、通用查问或读/写工作负载，它们并不一定比InnoDB表快。特地是，执行更新所波及的表锁定会升高多个会话中内存表的并发应用速度。MEMORY表具备以下特色： MEMORY表的空间以小块模式调配。表对插入应用100%动静哈希，不须要占用额定的内存。被删除的行并未开释，而是放在链表中，并在插入新数据时重用。MEMORY表应用固定长度的行存储数据。（即便是VARCHAR也不例外）MEMORY表不反对 BLOB、TEXT 列。MEMORY表反对 AUTO_INCREMENT 列。MEMORY表是有大小限度的，次要受限于两个参数： max_heap_table_size 和 MAX_ROWS（默认状况下MAX_ROWS依赖于max_heap_table_size，可执行ALTER TABLE tbl_name MAX_ROWS= MAX_ROWS批改MAX_ROWS）。问：MEMORY表和长期表有什么区别？ 长期表默认应用的存储引擎是服务器指定的存储引擎（对于5.7是InnoDB），因为长期表定义和数据都放在内存中，未放到磁盘，因而用show tables招不到长期表。如果长期表占用空间太大，MySQL会将其转为磁盘存储。而对于用户创立的MEMORY表，则不会转为磁盘存储。mysql> create temporary table temp_t1(a int primary key, b int);Query OK, 0 rows affected (0.00 sec)mysql> show tables;+---------------+| Tables_in_db4 |+---------------+| t1 |+---------------+1 row in set (0.00 sec)2. 故障剖析景象： 最近碰到有用户应用 MEMORY 存储引擎，引发主从 GTID 不统一、从节点 GTID 比主节点多一条的状况。 剖析： 查看日志，确认没有产生过主从切换，也就排除了主节点有 prepare 的事务而后故障（从节点变为主）、重启导致 local commit的状况。在从节点 binlog 中找到那条本地事务，发现是 MEMORY 表的 DELETE FROM 。该从节点产生过重启，依据 MEMORY 引擎的个性，确认是 MEMORY 表生成的。向用户反馈问题起因后，用户将 MEMORY 表改为了 InnoDB 表。 ...

背景 笔者在过来经典的两阶段提交算法过程中，发现会遇上局部节点在执行事务提交期间产生故障，导致如下的谬误，这些谬误都会导致用户数据失落或者出错。谬误如下： 1、一个分布式事务的一部分事务分支被提交，另一部分事务分支被回滚 2、应答给客户端事务提交胜利，然而分布式事务所有分支全副被回滚 3、应答给客户端事务被回滚，然而分布式事务局部或者全副分支被提交 4、存储节点故障复原时，某个存储节点的事务分支不能被正确地复原。 在下面这些谬误源中，第#4类错误处理由存储节点本身负责，分布式事务处理机制负责解决前3类谬误，笔者会在下篇文章做次要探讨。 对于第#4类谬误，笔者已经在FOSDEM 2021做过一次技术分享，https://fosdem.org/2021/sched...，国内视频连贯在：昆仑分布式数据库 MySQL XA事务处理的容灾技术（https://b23.tv/h7zzmR）当前也会陆续撰文详述。 经典的两阶段提交算法原理 两阶段提交算法把事务的提交分为preapre和commit两个阶段。 第一阶段事务管理器GTM发送prepare命令给所有的resourcemanager（RM），每个RM就prepare分布式事务的本地分支，也就是把它们的WAL日志刷盘以便即便RM宕机，复原之后依然能够提交（或者回滚）这些prepared状态的事务。 prepare一个事务之后，这个事务进入prepared状态，之后既能够commit它，也能够rollback它。 如果GTM收到所有的RM返回的都是胜利，那么GTM发送commit给每个参加的RM，于是RM就提交其prepared状态的事务分支，这样就实现了两阶段提交。 经典的两阶段提交算法缺点 如果两阶段提交流程中产生GTM或者RM宕机等故障，那么这个两阶段提交流程就可能中断并且无奈正确地持续的问题。 如何优化防止其缺点？ 为防止此类事变产生，昆仑分布式数据库的分布式事务处理机制基于经典的两阶段提交算法，并在此基础上加强了其容灾能力和错误处理能力。 故此能够做到任意时刻昆仑数据库集群的任意节点宕机或者网络故障、超时等都不会导致集群治理的数据产生不统一或者失落等谬误。 一个昆仑分布式数据库集群蕴含若干个彼此独立且性能雷同的计算节点做分布式事务处理和分布式查询处理（下篇文章做详述）： 蕴含若干个存储集群存储用户数据分片，每个存储集群应用高可用机制确保节点宕机数据不失落。 一个构造与存储集群完全相同的元数据集群，它存储着这个集群的要害元数据信息，包含本文所说的commit log。 一个cluster_mgr模块, 负责保护集群运行状态，并且解决因为节点故障而残留的prepared 状态的事务分支。 故此在上述的模块的有机配合下，经典的两阶段算法提交的缺点能够很好的防止！ 总结 对于经典的两阶段提交算法流程，笔者及团队曾经做了优化用于解决这些问题，从而达到坚不可摧的容灾能力。对于优化的原理过程，笔者会在下篇文章做详述（有疑难可私聊~）

背景mysql在Linux零碎中默认是辨别大小写的，也就是user和USER是两张不同的表，而且前期这个参数是无奈批改的，批改的话须要清空数据，老本十分高，而且最新版也没有针对这个问题的改良，这个设计我想不出是出于什么目标，因为理论状况是一个数据库可能很多零碎共用，有些须要辨别大小写，有些不须要，如果后期没有发现这问题，前期就要从新搭建一个数据库做数据迁徙，除了要搞死mysql外，我想不出有什么其余理由oracle要这么设计。 解决方案备份数据库前面咱们会对数据库进行初始化，初始化后所有数据失落，须要提前做好备份 mysqldump -uroot -p 数据库名称 >db_name.sql倡议一个个数据库进行备份批改配置文件批改配置文件/etc/mysql/my.cnf，减少以下配置 lower_case_table_names=1批改数据文件目录datadir = /data/mysql/data/mysql必须为空敞开数据库执行以下命令进行初始化mysqld --lower_case_table_names=1 --initialize-insecure --basedir=/usr/ --datadir=/data/mysql重启数据库后所有数据都会失落，咱们须要从新创立数据库和数据库用户# 仅供参考create database db_name;update user set host='%' where user='root';ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password;alter user 'root'@'%' identified by 'mysql';GRANT ALL PRIVILEGES ON db_name.* TO 'root'@'%';从新导入数据mysql -uroot -p db_name < db_name.sql

在线MySQL,SQL Server建表语句生成JSON测试数据工具在线MySQL,SQL Server建表语句生成JSON测试数据工具 本工具能够将SQL建表语句生成JSON测试数据,反对MySQL,SQL Server建表语句 SQL:结构化查询语言是一种数据库查问和程序设计语言，用于存取数据以及查问、更新和治理关系数据库系统 JSON:(JavaScript Object Notation, JS对象简谱) 是一种轻量级的数据交换格局。它基于 ECMAScript (欧洲计算机协会制订的js标准)的一个子集，采纳齐全独立于编程语言的文本格式来存储和示意数据。 https://tooltt.com/sql2jsondata/

作者：胡呈清 爱可生 DBA 团队成员，善于故障剖析、性能优化，集体博客：https://www.jianshu.com/u/a95...，欢送探讨。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 有一个很久前就存在的纳闷：在没有写入的状况下，show engine innodb status 中的 Pages flushed up to 为什么不等于 Last checkpoint point？它示意什么？ 明天在写一篇文章时，想通过一个测试，从这几个 LSN 的变动来验证一个说法，后果从新勾起了这个问题，在一番“钻研”后（其实就是google了一通，当然还是须要一些测试验证），终于弄明确了其中含意。 次要还是借鉴了一篇文章：http://blog.itpub.net/3022142...，因为有大量的源码剖析，而我看不懂源码，所以花了不少工夫才了解其中原理，并且通过测试验证了其准确性，而后整顿成了一个让像我这样不懂代码的人更不便浏览的文档。 明天在写一篇文章时，想通过一个测试，从这几个 LSN 的变动来验证一个说法，后果从新勾起了这个问题，这次我决定彻底弄明确到底是怎么一回事。 次要还是借鉴了一篇文章：http://blog.itpub.net/3022142...，因为有大量的源码剖析，而我也看不懂源码，所以花了不少工夫才了解其中原理，并且通过测试验证了其准确性，而后整顿成了一个更不便让像我这样不懂代码的人了解的文档。 LSNshow engine innodb status 的输入中，有一部分是 LSN 的状态： mysql> pager grep -A 5 LOG PAGER set to 'grep -A 5 LOG'mysql> show engine innodb status\GLOG---Log sequence number 2471197058Log flushed up to 2471197058Pages flushed up to 2471197058Last checkpoint at 24711970491 row in set (0.00 sec)Log sequence number：所有批改数据的操作都会产生 redo log，这是零碎以后 redo log 序列号（前面简称 LSN）的最大值； ...

前言： 后面文章有介绍过 MySQL 零碎自带的 mysqldump 备份工具的应用，其实还有一个开源工具 mydumper 同样实用于 MySQL 的逻辑备份。之前始终没有正式体验过，只是据说比 mysqldump 要快很多，具体应用成果如何， 一起来看下吧。 1. mydumper 简介mydumper 是一款社区开源的逻辑备份工具。该工具次要由 C 语言编写，目前由 MySQL 、Facebook 等公司人员开发保护。 官网地址：https://launchpad.net/mydumperGitHub 地址：https://github.com/maxbube/mydumper 参考官网介绍，mydumper 次要有以下几点个性： 反对多线程导出数据，速度更快。反对一致性备份。反对将导出文件压缩，节约空间。反对多线程复原。反对以守护过程模式工作，定时快照和间断二进制日志。反对依照指定大小将备份文件切割。数据与建表语句拆散。2. mydumper 装置装置办法大略有两种，一种是编译装置，一种是 yum 间接装置 rpm 包。上面以 CentOS 零碎为例，简略展现下装置办法： # 1.编译装置[root@localhost ~]# yum -y install glib2-devel mysql-devel zlib-devel pcre-devel zlib gcc-c++ gcc cmake[root@localhost ~]# wget https://launchpad.net/mydumper/0.9/0.9.1/+download/mydumper-0.9.1.tar.gz[root@localhost ~]# tar zxf mydumper-0.9.1.tar.gz[root@localhost ~]# cd mydumper-0.9.1/[root@localhost mydumper-0.9.1]# cmake .[root@localhost mydumper-0.9.1]# make[root@localhost mydumper-0.9.1]# make install# 装置实现后生成两个二进制文件 mydumper 和 myloader 位于 /usr/local/bin 目录下[root@localhost bin]# ls /usr/local/bin/mydumper myloader# 2.间接装置 rpm 包# rpm包地址：https://github.com/maxbube/mydumper/releases 请依据本人的零碎类型抉择下载版本[root@localhost ~]# yum install https://github.com/maxbube/mydumper/releases/download/v0.10.7-2/mydumper-0.10.7-2.el7.x86_64.rpm# 装置实现后生成两个二进制文件 mydumper 和 myloader 位于 /usr/bin 目录下3. mydumper 应用装置实现后，能够很显著看出，mydumper 和 myloader 是绝对应的一组可执行程序，二者的作用别离是导出数据与导入数据。咱们先来看下如何应用 mydumper 来备份数据。 ...

1、建设索引2、id关联

原创：码农参上（微信公众号ID：CODER_SANJYOU），欢送分享，转载请保留出处。事件是这样的，前几天隔壁部门的哥们在生产环境的数据库上，执行了一下drop命令，好嘛，活生生的删库跑路的例子竟然真的在我身边产生了，好在运维同学给力，起初复原了数据。预先据说这哥们尽管没被开革，但也吃了个公司的正告。 再而后，运维那边回收了所有环境下数据库的drop命令的权限，甚至包含了开发环境，原本感觉对咱们也没啥影响，个别咱们也没有啥须要删表的需要。然而隔了没几天，我在重命名一个表的时候，忽然弹出了这样一个报错： 认真看了一眼报错： 1142 - DROP command denied to user 'hydra'@'localhost' for table 't_orders'什么状况，重命名表和drop命令还有什么关系？本着狐疑的态度，就想探索一下没有drop权限后，对咱们的日常数据库操作都有什么影响，于是就有了前面一系列在本地进行的测试。 首先须要一个没有drop权限的mysql用户，咱们先在本地环境应用root用户登录mysql，勾销用户hydra的drop权限。和grant受权命令绝对应的，能够应用revoke命令勾销对用户的受权： revoke drop on *.* from hydra@'localhost';好了，筹备工作做完了，It's show time~ 批改表名后面间接应用navicat来批改表名失败，那咱们再用sql命令来尝试一下： 下面测试了两种重命名表的命令，无论是ALTER还是RENAME都不能失常应用，看来drop的权限的确会对批改表名造成影响。至于重命名失败的起因，看一下官网文档的阐明： RENAME TABLE renames one or more tables. You must have ALTER and DROP privileges for the original table, and CREATE and INSERT privileges for the new table.简略来说就是在重命名表时，必须有原始表的ALTER和DROP权限，以及新表的CREATE和INSERT权限。 truncate当我须要清空一张表、顺带把AUTO_INCREMENT的主键置为初始值时，忽然发现truncate命令也无奈执行了： 有了下面的教训，还是看一下官网文档的阐明： Although TRUNCATE TABLE is similar to DELETE, it is classified as a DDL statement rather than a DML statement. It differs from DELETE in the following ways: ...

前言： 数据库被误删过，想着学习 mysql ，将其整理出来,才有本次记录，本文为本人学习mysql记录，线上环境慎用，自己也不是业余的DBA。一、MySQL日志mysql 有两个重要的日志模块 redo log (重做日志) 和 binlog (归档日志)，当有一条数据须要更新时，InnoDB引擎会在零碎闲暇的时候，将记录更新到磁盘中。会先将记录寄存到 redo log 里，在更新内存，这个时候更新就实现了，InnoDB引擎会在零碎闲暇的时候，将记录更新到磁盘中，redo log是物理日志，记录在某个数据做了什么批改， redo log 是InnoDB引擎中特有的日志，换句话说 redo log 是InnoDB引擎为了进步零碎效率，用来做日志缓冲的。binlog 是记录所有数据库表构造变更以及表数据批改的二进制日志（不会记录 SELECT和SHOW 这类操作），binlog 是逻辑日志,记录语句的原始逻辑。数据恢复: 能够通过 mysqlbinlog工具进行数据恢复。二、数据恢复当初数据库执行上面命令,看MySQL日志是否开启 mysql> show variables like 'log_bin%';+---------------------------------+---------------------------------------------------------+| Variable_name | Value |+---------------------------------+---------------------------------------------------------+| log_bin | ON || log_bin_basename | C:\ProgramData\MySQL\MySQL Server 8.0\Data\binlog || log_bin_index | C:\ProgramData\MySQL\MySQL Server 8.0\Data\binlog.index || log_bin_trust_function_creators | OFF || log_bin_use_v1_row_events | OFF |+---------------------------------+---------------------------------------------------------+这里显示的ON为开启,如果显示OFF为敞开,关上上面门路,编辑 my.ini C:\ProgramData\MySQL\MySQL Server 8.0增加上面属性,大略127行 # 不记录每条sql语句的上下文信息，仅需记录哪条数据被批改了，批改成什么样了binlog_format = ROW# binlog过期清理工夫；expire_logs_days= 7 # binlog每个日志文件大小；max_binlog_size = 512m # binlog缓存大小；binlog_cache_size = 128m # 最大binlog缓存大小。max_binlog_cache_size = 512m 筹备数据 ...

引言一般来说讲，提到数据拆分，能够归结为两个层面：一是垂直拆分，二是程度拆分。这里咱们来探讨下垂直拆分。 垂直拆分是以数据库、表、列等为单位进行拆分的办法。 注释MySQL里垂直拆分能够细分为：垂直拆库（实例级别）、垂直拆模（表级别）、垂直拆表（列级别）。1、垂直拆库：也即在业务层依照业务逻辑由大拆小，各个子业务之间无关联查问，仅查问单个子业务即可，相似微服务治理的思维。在 MySQL 里体现为将全副表依照业务关联严密水平拆分后存储在不同的数据库，每个数据库为一台 MySQL 实例，查问仅查对应的数据库实例即可。如图1所示： 上图展现出原始业务数据的拆分示例，依照不同的业务逻辑分类划分为多个子业务，每个子业务对应一套 MySQL 实例组，每个 MySQL 实例组依照 MySQL 的 HA 架构部署（主从同步、组复制、MySQL CLUSTER等） 图1的长处很显著，原始业务的压力扩散到各个小业务上，晋升了整体的性能。但也不能疏忽毛病：数据库对利用端不通明，利用端必须本人保护路由数据；当单个实例数据量以及申请再次达到下限时，后续拆分十分艰难。 2、垂直拆模：垂直拆模和垂直拆库大体相似，不过垂直拆模的最小单元是 schema ，而不是实例。大家晓得，MySQL 的数据库等同于 schema ， 一个数据库对应磁盘上的一个文件目录。这种拆分个别是为了解决文件系统中单个目录里文件个数过多导致的性能升高。如图2所示： 图2显式了比方一个数据库 dbA ， 外面含有10000张表，每1000张表独自划分为一个数据库，比方dbA1,dbA2，...，db10；每个数据库的数据无论从物理还是逻辑上都独立的。 举个例子阐明下在数据库端垂直拆模的步骤以及对写入和查问申请的影响： 数据库 ytta 下有10000张表，表名别离为t1到t10000. (debian-ytt1:3500)|(ytta)>select count(*) from information_schema.tables where table_schema='ytta';+----------+| count(*) |+----------+| 10000 |+----------+1 row in set (0.04 sec)此处把这10000张表均匀垂直拆分到数据库 ytt1 到 ytt10 里。 先创立10个数据库 ytt1-ytt10 。 ytt@debian-ytt1:~/mysql-sandboxes/3500/sandboxdata$ for i in `seq 1 10`; \> do mysql -S mysqld.sock -uroot -proot -e "create database ytt$i";done;别离往这10个数据库中 COPY 原始数据库的表构造以及数据： ...

背景介绍–公司介绍茄子科技（海内 SHAREit Group）是一家全球化互联网科技公司，次要从事挪动互联网软件研发与寰球挪动广告变现解决方案、跨境领取解决方案等互联网服务等业务。茄子快传（SHAREit）是茄子科技旗下的代表产品， 是一款一站式数字娱乐内容与跨平台资源分享平台，累计装置用户数近 24 亿。茄子科技作为一家出海企业，曾经在东南亚、南亚、中东以及非洲等地区，打造了多款工具和内容的利用，并且在 Google Play 的下载榜上长年名落孙山。 背景介绍–业务特点及选型茄子科技的产品矩阵较多，产品状态绝对比较复杂，包含了工具、内容、游戏、广告、领取等。针对绝对简单的业务场景，依据不同的业务状态，咱们做了不同的数据库选型。目前，茄子科技应用的六款最次要的数据库包含： 自研长久化 KV：特色平台、用户画像、行为记录等Redis Cluster：业务缓存、session 信息等Cassandra：内容库MySQL： Hue、Metadata、经营平台等ClickHouse：数据分析、实时报表TiDB：用户增长、APM 零碎、云账单等TiDB的利用实际–业务痛点及TiDB的劣势基于业务层面的痛点思考，咱们在多个业务场景引入了 TiDB：第一，茄子科技作为一家出海企业引入了多家私有云作为基础设施，所以在数据库的层面，要思考业务在多云架构下的业务适配、数据迁徙、数据库的兼容以及数据同步的问题。第二，茄子有多款高流量的 APP 产品，业务出现高速增长的态势，传统的 DRS 数据库，比方 MySQL，因为须要分库分表，妨碍业务疾速倒退。第三，Cassandra、HBase 等 NoSQL 数据库，无奈满足分布式事务，多表 join 等简单场景。 茄子科技的 APM 等零碎，有一些是 HTAP 场景，同一份业务数据既有 OLTP 又有 OLAP 的需要，咱们心愿一套数据库能够搞定。 引入 TiDB 之后，TiDB 在多个方面施展出独特劣势，帮忙茄子科技打造可继续倒退的数据库生态： 利用 TiDB 的跨集群迁徙、数据同步的能力打造多云架构下的业务扩大能力，满足多云架构下的业务架构设计。TiDB 提供主动程度弹性扩大的能力，做到业务无感知，解决分库分表的问题。TiDB 高度兼容 MySQL，在大容量、高并发的场景下学习成本低、迁徙成本低。利用 TiDB HTAP 的能力，满足业务在一份数据上的 OLTP 与 OLAP 的双重需要。 TiDB的利用实际–APM 场景利用茄子科技的 APM（Application Performance Management）零碎提供 APP 解体、性能等问题的监控、剖析、看板、修复的一体化能力，用来撑持多款高增长的 APP 利用。这个零碎的第一个特点就是信息量大，每天产生百亿条的数据，须要保留 30 天；第二个特点是时效性要求比拟高，针对一些比拟辣手的状况，比如说解体以及重大的性能问题，如果时效性不能满足的话会间接影响到用户的体验，甚至是产品的营收；第三个特点是须要买通工单零碎，提供问题追踪、修复的一体化能力；第四个特点是在 OLTP 事务场景的根底上须要兼顾 OLAP 的剖析场景。 首先剖析一下晚期 APM 的数据流转，从 APP 数据上报到日志收集，最初到 ClickHouse，整个数据流转是一个相似批处理的流程，大略须要两个多小时，整体时效性偏弱，问题裸露不及时，会对用户体验产生影响。另外，这套零碎外面有 MySQL 和 ClickHouse 两套数据库。为什么这么设计？因为 ClickHouse 能够用来做数据的剖析聚合，MySQL 次要是用来打造流程工单，同时有两套数据库在撑持，在老本上比拟高。再来看引入了 TiDB 之后的新版 APM 数据流转，能够看到从 APP 的上报，到看板展现，到报警，再到流程工单，实现分钟级的准实时看版展现和报警。这部分次要是借助了 TiDB 的 HTAP 能力，通过聚合剖析向看版进行展现，向报警核心进行及时的报警。同时，利用 TiDB 的 OLTP 能力进行看板的行更新。所以，咱们能够通过一套 TiDB 数据库买通看版、监控、问题的追踪和修复流程。 ...

该文档仅供参考，具体请查看： https://gitee.com/zettadb/kun... 在装置完所有的库和依赖状况下，相比于手动装置 kunlun cluster 须要30分钟到一个小时的工夫装置，一键疾速装置只须要10分钟就能够玩起来。 在装置之前，要确保装置环境满足以下要求： 1、所有节点所在机器须为Linux, 装置了bash, sed, gzip, python2, python2-dev等工具或者库。python 2可执行程序设置为python2。 2、 所有集群节点所在机器曾经正确设置好用户，节点将以该用户启动，该用户可能运行sudo而不须要明码。 3、对于装置存储节点的机器，须要事后装置以下库(此处为ubuntu 20.04): libncurses5 libaio-dev。 4、 对于装置计算节点的机器，须要事后装置以下库(此处为ubuntu 20.04): libncurses5 libicu66 python-setuptools gcc。 5、对于装置动作，须要事后将二进制公布包 ( percona-8.0.18-bin-rel.tgz, postgresql-11.5-rel.tgz,cluster_mgr_rel.tgz ) 放入当前目录. 此外，工具运行机器和节点所在机器间网络不能太慢，因为须要将公布包传递到这些机器上。 以ubuntu为示例，能够通过sudo apt-get install的形式装置对应库，如装置python2： 图片该环境下曾经装置python2，所以提醒python2是最新的版本。 能够通过apt list --installed的形式查看已装置的库。 因为列出进去的已装置的库太多，用grep过滤指定库是一个比拟好的方法。 实现上述要求后，就能够开始一键疾速装置kunlun cluster 以下装置是基于集体环境装置 kunlun cluster （仅供参考） 1、通过git clone形式在gitee上拉kunlun-scripts包： git clone https://gitee.com/zettadb/kun... 2、cd进入 kunlun_scripts/cluster下: cd kunlun_scripts/cluster 3、获取最新的版本的下载包：以0.8.3为例（近期就会推出0.8.4版本，敬请期待） （1）进入泽拓官网http://downloads.zettadb.com/，点击产品下载。 （2）点击releases/0.8.3/release-binaries,获取三个安装包的下载地址，能够通过右键--复制链接地址的形式获取： （3）在ubuntu外面应用wget形式获取三个下载包到以后cluster目录下： 4、编辑批改配置文件install.json：vi install.json（配置详情看第五步） ...

TiDB 慢日志在伴鱼的实际作者简介：刘江，伴鱼英语数据库负责人，TUG 2020 年度 MOA。负责伴鱼数据库运维、大数据运维以及数据库平台化建设。 本文来自于伴鱼英语 DBA 组负责人刘江在「能量钛」第二期流动的分享，刘江为大家分享了 TiDB 慢日志在伴鱼的实际。本文将从以下三个方面开展： 第一局部是背景与需要，首先介绍伴鱼做 TiDB 慢日志零碎的背景，以及基于这个背景，要把慢日志零碎做成什么样子；第二局部介绍下慢日志零碎具体是怎么做的；第三局部通过几个线上案例，看看慢日志零碎是如何定位线上问题的。背景与需要往年上半年，阿里云公布了新一代 DAS（数据库自治服务）服务，外面谈到数据库的问题，90% 以上的问题都是来源于数据库的异样申请。其实在咱们日常的数据库问题场景，大部分的问题也都是异样 SQL 申请，像数据库的 bug 或者是机器导致的故障问题，平时遇到还是绝对较少的。对于异样 SQL 的定位，数据库的慢日志剖析，是一种特地无效的伎俩。 那么咱们在平时利用慢日志剖析问题的时候，会有哪些痛点？在做慢日志零碎之前，集群的慢日志是散布在多台机器下面的，如果数据库呈现了问题，就须要登录到多台机器一台台的去剖析，问题解决的效率很低。特地是当集群规模特地大的时候，基本上没方法去疾速定位问题。 当然，TiDB 在 4.0 版本反对了 Dashboard，咱们能够通过 Dashboard 查看整个集群的慢日志信息，比方最近 15 分钟的或者最近半个小时的慢日志。但当零碎真正呈现问题的时候，慢日志会特地多，Dashboard 会面临计算加载等性能问题，同时 Dashboard 不反对检索和剖析统计，这不利于咱们疾速定位到异样 SQL。 TiDB 零碎库自带了一张表（INFORMATION_SCHEMA.SLOW_QUERY）来实时存储慢日志，咱们也能够通过它来定位异样 SQL，但这张表是一个关系型的表，自身是没有索引的，当日志量特地大的时候，多维检索和剖析是特地慢的。同时，对于关系型表的多维检索和剖析统计，也不是它所善于的。 基于以上的痛点，伴鱼的慢日志零碎须要满足以下几个需要： 首先，就是慢日志集中式收集，可能把线上多个集群甚至几十个集群的慢日志全副收拢在一起，便于集中剖析，这样做入口就对立了。 其次，要保障收集的慢日志是准实时的。因为如果收集的慢日志提早太大的话，对于解决线上问题和剖析问题是没有帮忙的。 而后，慢日志能够检索和统计分析。因为当呈现问题的时候慢日志是特地多的，这个时候如果可能检索和统计分析的话，就能够疾速定位到异样 SQL。 最初，慢日志零碎须要反对监控和告警。 零碎详解基于以上的背景和需要，咱们来看一下伴鱼的慢日志零碎是怎么做的。 零碎架构伴鱼慢日志零碎整体架构，如下图所示。咱们在 TiDB Server 机器初始化时部署了 Filebeat 组件，通过它把采集的慢日志，写入到 Kafka，同时打上机器 IP 信息。而后通过 logstash 解析出咱们关注的字段，存储到 ES。ES 自身是一个搜索引擎，做数据的剖析和统计，速度是特地快的。同时咱们通过 Kibana 查看 ES 里的慢日志数据，做可视化的统计和检索。当然，慢日志零碎还有一种架构，如下图所示。Clickhouse 是最近几年比拟火的剖析型数据库，有些公司通过把监控数据发送到 Clickhouse， 做实时监控和告警剖析。咱们能够用 Flink 替换 logstash 组件，通过简略的计算，把慢日志数据写入到 Clickhouse。因为伴鱼的慢日志零碎做得比拟早，所以采纳的是 ELK 的架构。 ...

前言： 当连贯数据库失败次数过多时，MySQL 是否会限度登录呢？数据库服务端应该怎么应答暴力破解呢？本篇文章介绍下 MySQL 中的连贯管制插件，一起来学习下此插件的作用。 1.连贯管制（connection_control）插件介绍MySQL 服务端蕴含一个插件库，能够自定义装置各类插件。connection_control 插件也是其中一种，次要用来管制客户端在登录操作间断失败肯定次数后的响应的提早。该插件可无效的避免客户端暴力登录的危险。该插件蕴含以下两个组件： CONNECTION_CONTROL：用来管制登录失败的次数及提早响应工夫。CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS：将登录失败的操作记录至 information_schema零碎库中。连贯管制插件文件的根本名称为 connection_control 。每个平台的文件名后缀有所不同(对于 Unix 和类 Unix 零碎为 .so ，对于 Windows 为 .dll )。上面以 Linux 零碎为例来装置下 connection_control 插件，Windows 零碎只须要将 .so 改成 .dll 即可。 # 动静装置 connection_control 插件mysql> INSTALL PLUGIN CONNECTION_CONTROL SONAME 'connection_control.so';Query OK, 0 rows affected (0.04 sec)mysql> INSTALL PLUGIN CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS SONAME 'connection_control.so';Query OK, 0 rows affected (0.01 sec)# 验证插件状态mysql> SELECT -> PLUGIN_NAME,PLUGIN_STATUS -> FROM -> INFORMATION_SCHEMA.PLUGINS -> WHERE -> PLUGIN_NAME LIKE 'connection%';+------------------------------------------+---------------+| PLUGIN_NAME | PLUGIN_STATUS |+------------------------------------------+---------------+| CONNECTION_CONTROL | ACTIVE || CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS | ACTIVE |+------------------------------------------+---------------+# 装置实现后 能够看到相干零碎变量mysql> show variables like 'connection_control%';+-------------------------------------------------+------------+| Variable_name | Value |+-------------------------------------------------+------------+| connection_control_failed_connections_threshold | 3 || connection_control_max_connection_delay | 2147483647 || connection_control_min_connection_delay | 1000 |+-------------------------------------------------+------------+能够看出，插件装置还是很简略的，不过这个插件具体有什么作用呢？咱们先来解释下相干零碎变量： ...

作者：岳明强 爱可生北京分公司 DBA 团队成员，负责数据库治理平台的运维和 MySQL 问题解决。善于对 MySQL 的故障定位。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 在生产中个别产生运行问题，能够翻翻 error 日志，大部分都能解决。有的时候数据库忽然宕机重启，此时咱们在 error 日志中会发现"This could be because you hit a bug"，而后打了一堆看不懂的堆栈。这时候如果拿着碰到BUG的论断交差，多半会被利用一顿暴击输入：有证据没，这个 bug 怎么呈现的，官网怎么修的，在什么版本修的。那么接下来，我将依据现有 error 日志报错中的堆栈信息，找到具体的 BUG 修复记录 一、查看以后谬误日志MySQL 异样解体，查看 error 日志，红框处为地位信息 注：如呈现这种相似 BUG 信息，不应只看这部分信息，应先查看 MySQL 异样退出前是否存在报错信息。此处不进行演示 二、gdb 查看报错文件地位应用 gdb 追踪报错文件地位，后面报错文件为 mysqld ,就 gdb mysqld 文件，如果是其余的文件，例如组复制插件，那么就 gdb 该文件 首先先 b 一下函数名称，如下所示： 能够看出前面找到两个地位，而后咱们再加上偏移量，再 b 一下： 很显著，第二个找到的是 mysql 里文件，从官网上下载雷同版本源码包进行解压，找过 pipeline_stats.h 这一文件中的410行，确定函数名为 Pipeline_member_stats() 三、查看该函数变更内容在 github上mysql 官网地址中找到这一文件 https://github.com/mysql/mysq... ...

MySQL根底一、查问的SQL语句（DQL语言的一部分）1、查问语句1.1 根本语句留神：sql语句对大小写不敏感，所以创立表时id int，Id varchar这样的不能同时呈现。查问能够查：常量、表达式、函数； SELECT 100;SELECT 100-92;SELECT VERSION();如果想查的字段蕴含反复的，本人想去重，那么能够应用distinct。 #显示有哪些部门编号SELECT DISTINCT department_id FROM employees;+的作用：java中有拼接的性能，而mysql中不是，只有运算的性能；比方两个运算，如果间接能算，那么就计算，如果不能那么会试图把他们转换成数值型再计算，如果转换失败就会把它们转换为0，如果其中有一方为null，那么后果是null； #查问员工姓和名，拼接成姓名 上面这个是错的SELECT first_name+last_name`departments` '姓名' FROM employees;#下面这个拼接能够用CONCAT，CONCAT(str1,str2......)函数SELECT CONCAT(first_name,last_name) AS '姓名' FROM employees;#这个也能计算胜利，后果213SELECT 123 + '90';#后果是123SELECT 123 + 'abv';#后果是0SELECT 'abc' + 'abv';#后果为nullSELECT 90 + null;如果某个字段中有null值，拼接会为null，那么就须要应用函数IFNULL()了。 IFNULL(`字段名`，0); =>#这示意把某个字段的null值变为01.2 where——筛选#语法SELECT 查问的列表 FROM 表名 WHERE 筛选条件;筛选条件分为几类按条件表达式筛选： =、<、>、<=、>=、<>按逻辑表达式筛选：&&（与）、||（或）、！（非） ===>and、or、not含糊查问：like、between...and、in、is null；like含糊查问其中%示意任意多个字符，_示意任意一个字符；between...and前后数不能调换，in中的值类型必须对立is null和<=>：is null只能判断null值，<=>除了判断null值，还能够判断别的值，举荐应用is null判断null值，因为可读性高#比方like的字段蕴含特殊字符须要本义，查问名第二个字符为_的SELECT * FROM employees WHERE last_name LIKE '_\_%';#判断某个列值为null的用户信息，能够应用is null，也能够用<=>，这里举荐应用is null，因为可读性高SELECT last_name,job_id,commission_pct FROM employees WHERE commission_pct <=> NULL;1.3 order by——排序order by前面反对别名。上面这个查问完年薪起别名，能够按别名排序。 ...

哔哩哔哩视频链接：https://www.bilibili.com/vide...笔记是从黑马程序员那里获取的~ Mysql高级-day01MySQL高级课程简介序号Day01Day02Day03Day041Linux零碎装置MySQL体系结构利用优化MySQL 常用工具2索引存储引擎查问缓存优化MySQL 日志3视图优化SQL步骤内存治理及优化MySQL 主从复制4存储过程和函数索引应用MySQL锁问题综合案例5触发器SQL优化罕用SQL技巧 1. Linux 零碎装置MySQL1.1 下载Linux 安装包https://dev.mysql.com/downloads/mysql/5.7.html#downloads 1.2 装置MySQL1). 卸载 centos 中预装置的 mysql rpm -qa | grep -i mysql rpm -e mysql-libs-5.1.71-1.el6.x86_64 --nodeps2). 上传 mysql 的安装包 alt + p -------> put E:/test/MySQL-5.6.22-1.el6.i686.rpm-bundle.tar3). 解压 mysql 的安装包 mkdir mysql tar -xvf MySQL-5.6.22-1.el6.i686.rpm-bundle.tar -C /root/mysql4). 装置依赖包 yum -y install libaio.so.1 libgcc_s.so.1 libstdc++.so.6 libncurses.so.5 --setopt=protected_multilib=false //在centos7上装置失败， yum update libstdc++-4.4.7-4.el6.x86_645). 装置 mysql-client rpm -ivh MySQL-client-5.6.22-1.el6.i686.rpm6). 装置 mysql-server rpm -ivh MySQL-server-5.6.22-1.el6.i686.rpm 1.3 启动 MySQL 服务service mysql startservice mysql stopservice mysql statusservice mysql restart#这里应用来开启systemctl start mysqld1.4 登录MySQLmysql 装置实现之后, 会主动生成一个随机的明码, 并且保留在一个密码文件中 : /root/.mysql_secretmysql -u root -p 登录之后, 批改明码 :set password = password('itcast');受权近程拜访 : grant all privileges on *.* to 'root' @'%' identified by 'itcast';flush privileges;#敞开防火墙service iptables status;以上步骤在1.2装置依赖包时出错，参考上面链接在centos7上装置MySQL5.7 ...

背景应用python脚本监控特定过程的资源占用状况，存入数据库；每次过程敞开后写入日志到特定目录（Logs/日期/小时）。当初须要记录在比拟数据中存储的数据的一致性问题。总数统计比照：1、查问日志总数状况能够递归遍历查问日期下目录的数据，脚本如下：ls -lR |grep "_20210903.log.gz$"|wc -l2、去重查询数据库中总数状况能够利用distinct进行mysql的去重查问操作。 select distinct(process_id) from server_process_perf_by_second where process_name in ("name1","name2") and date ="20210903" 后果能够查看到日志监控到503个过程PID。而日志监控到的数据是179个数据，这两个数据不统一，所以mysql记录的数据中存在漏数据的状况。须要进一步进行剖析哪些过程PID数据有问题。 数据详情比照导出数据存入Excel表格中利用公式输出如下公式： =COUNTIF($A$2:$A$500,B2)后进行数据比照，比照的后果如下图 综上能够针对差别的过程PID号进行问题的排查。

macOS + VSCode 版本看这里环境信息macOS Big Sur 11.5.2CLion 2021.2MySQL 5.7.35CMake 3.21.1openssl 1.1下载源码从官网下载携带 boost 版本源码 下载链接：https://dev.mysql.com/get/Downloads/MySQL-5.7/mysql-boost-5.7.35.tar.gz 也能够从 GitHub 上克隆代码，切换到指定 TAG 或分支。 Patch 源码如果 MySQL <= 8.0.21，则须要执行以下脚本 Patch 源码： mv VERSION MYSQL_VERSIONsed -i '' 's|${CMAKE_SOURCE_DIR}/VERSION|${CMAKE_SOURCE_DIR}/MYSQL_VERSION|g' cmake/mysql_version.cmake具体起因，可参考文章：MySQL 源码 —— 问题 expanded from macro MYSQL_VERSION_MAJOR 配置 CMake CMake options 配置如下： -DWITH_DEBUG=1-DDOWNLOAD_BOOST=1-DDOWNLOAD_BOOST_TIMEOUT=60000-DWITH_BOOST=boost-DCMAKE_INSTALL_PREFIX=build_out-DMYSQL_DATADIR=build_out/data-DSYSCONFDIR=build_out/etc-DMYSQL_TCP_PORT=3307-DMYSQL_UNIX_ADDR=mysql-debug.sock解释下下面的参数： -DWITH_DEBUG=1 # 开启DEBUG模式-DDOWNLOAD_BOOST=1 # boost不存在时主动下载-DDOWNLOAD_BOOST_TIMEOUT=60000 # 下载boost的超时工夫-DWITH_BOOST=boost # boost目录，不存在时会主动下载到该目录-DCMAKE_INSTALL_PREFIX=build_out # MySQL装置目录，可在启动时指定`--basedir`笼罩-DMYSQL_DATADIR=build_out/data # MySQL数据目录，可在启动时指定`--datadir`笼罩-DSYSCONFDIR=build_out/etc # `my.cnf`默认目录，可在启动时指定`--defaults-file=file_name`笼罩-DMYSQL_TCP_PORT=3307 # 如果本机已装置过MySQL，防止抵触换个别的-DMYSQL_UNIX_ADDR=mysql-debug.sock # 默认/tmp/mysql.sock，防止抵触，此处绝对与`--datadir`目录会主动创立所有可选参数：MySQL Source-Configuration Options手动创立配置中的目录： # 为何加`cmake-build-debug`前缀，因为`CLion`中`CMake`的`Build directory`就是`cmake-build-debug`，可自行批改mkdir -p cmake-build-debug/build_out cmake-build-debug/build_out/data cmake-build-debug/build_out/etc运行 CMake办法一：Tools > CMake > Reset Cache and Reload Project ...

前言： 咱们都晓得，当执行 select 查问语句时，用没用到索引区别是很大的，若没用到索引，一条 select 语句可能执行好几秒或更久，若应用到索引则可能霎时实现。那么当执行 update 语句时，用没用到索引有什么区别呢，执行工夫相差大吗？本篇文章咱们一起来探索下。 1. update SQL 测试为了比照出差距，这里笔者创立两张一样数据的大表，一张有一般索引，一张无一般索引，咱们来比照下二者的差异。 # tb_noidx 表无一般索引mysql> show create table tb_noidx\G*************************** 1. row *************************** Table: tb_noidxCreate Table: CREATE TABLE `tb_noidx` ( `increment_id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主键', `col1` char(32) NOT NULL COMMENT '字段1', `col2` char(32) NOT NULL COMMENT '字段2', ... `del` tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否删除',) ENGINE=InnoDB AUTO_INCREMENT=3696887 DEFAULT CHARSET=utf8 COMMENT='无索引表'mysql> select count(*) from tb_noidx;+----------+| count(*) |+----------+| 3590105 |+----------+mysql> select concat(round(sum(data_length/1024/1024),2),'MB') as data_length_MB, concat(round(sum(index_length/1024/1024),2),'MB') as index_length_MB -> from information_schema.tables where table_schema='testdb' and table_name = 'tb_noidx'; +----------------+-----------------+| data_length_MB | index_length_MB |+----------------+-----------------+| 841.98MB | 0.00MB |+----------------+-----------------+# tb_withidx 表有一般索引mysql> show create table tb_withidx\G*************************** 1. row *************************** Table: tb_withidxCreate Table: CREATE TABLE `tb_withidx` ( `increment_id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主键', `col1` char(32) NOT NULL COMMENT '字段1', `col2` char(32) NOT NULL COMMENT '字段2', ... `del` tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否删除', PRIMARY KEY (`increment_id`), KEY `idx_col1` (`col1`), KEY `idx_del` (`del`)) ENGINE=InnoDB AUTO_INCREMENT=3696887 DEFAULT CHARSET=utf8 COMMENT='有索引表'mysql> select count(*) from tb_withidx;+----------+| count(*) |+----------+| 3590105 |+----------+mysql> select concat(round(sum(data_length/1024/1024),2),'MB') as data_length_MB, concat(round(sum(index_length/1024/1024),2),'MB') as index_length_MB -> from information_schema.tables where table_schema='testdb' and table_name = 'tb_withidx'; +----------------+-----------------+| data_length_MB | index_length_MB |+----------------+-----------------+| 841.98MB | 210.50MB |+----------------+-----------------+这里阐明下，tb_noidx 和 tb_withidx 两张表数据完全相同，表大略有 360W 条数据，约占用 840M 空间。其中 col1 字段区分度较高，del 字段区分度很低，上面咱们别离以这两个字段为筛选条件来执行 update 语句： ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 背景本文又是来源于客户征询的问题： 是否管制单表在一个固定的记录数，比如说1W条，超过不让插入新记录或者说间接抛出谬误？ 对于这个问题，没有一个简化的答案，比方执行一条命令或者说简略设置一个参数都不能完满解决。接下来我给出一些可选解决方案。 注释对数据库来讲，个别问题的解决方案无非有两种，一种是在利用端；另外一种是在数据库端。 首先是在数据库端（假如表硬性限度为1W条记录）：一、触发器解决方案：触发器的思路很简略，每次插入新记录前，检查表记录数是否达到限定数量，数量未到，持续插入；数量达到，先插入一条新记录，再删除最老的记录，或者反着来也行。为了防止每次检测表总记录数全表扫，布局另外一张表，用来做以后表的计数器，插入前，只需查计数器表即可。要实现这个需要，须要两个触发器和一张计数器表。t1为须要限度记录数的表，t1_count 为计数器表： mysql:ytt_new>create table t1(id int auto_increment primary key, r1 int);Query OK, 0 rows affected (0.06 sec) mysql:ytt_new>create table t1_count(cnt smallint unsigned);Query OK, 0 rows affected (0.04 sec) mysql:ytt_new>insert t1_count set cnt=0;Query OK, 1 row affected (0.11 sec)得写两个触发器，一个是插入动作触发： DELIMITER $$USE `ytt_new`$$DROP TRIGGER /*!50032 IF EXISTS */ `tr_t1_insert`$$CREATE /*!50017 DEFINER = 'ytt'@'%' */ TRIGGER `tr_t1_insert` AFTER INSERT ON `t1` FOR EACH ROW BEGIN UPDATE t1_count SET cnt= cnt+1; END;$$DELIMITER ;另外一个是删除动作触发： ...

MVCC 介绍MVCC 全称是 Multiversion concurrency control，即多版本并发管制。从它的名字就能够看出是对于在并发时对读写管制的一种办法，根本市面上风行的 Database 都有其具体的实现。 MVCC 使得各个事务在读写数据时能最大水平的升高锁的依赖，在保障事务隔离性的同时，也能让读类型的事务和写操作的事务并发进行。 当咱们在进行批改操作时，MVCC 会通过 undo log 保留了之前的数据记录，就像每条记录都有本人的历史版本一样。 通过这些历史版本的追溯，MVCC 就再也不怕写操作的影响了，这就是 MVCC 的精华所在了。 MVCC 作用咱们晓得，在事务的四大个性中有隔离性的存在，而它的实现离不开锁的使用。然而锁有它的性能瓶颈，比方须要排队期待或者一不小心就产生死锁等等。 而在有了 MVCC 多版本控制后，读写操作再也不必小心翼翼的防着对方，大大提高了数据库的并发解决。 当然，这针对的是读和写的并发状况，如果是写和写的同时操作，那么原来该怎么管制就得怎么管制，这是波及到数据的完整性准则了。 所以，MVCC 次要是优化了读写并发的操作，对于很多读多写少的互联网我的项目，曾经能达到优化的目标了。 MVCC 原理在说 MVCC 的具体原理之前，咱们先来介绍下 undo log，它在 MVCC 里施展了很大的作用。 undo log 是对事务操作时的一个日志记录，以提供数据回滚性能。比方当初事务进行了 insert 操作，则回滚时会逆向解析为 delete；如果是 delete 操作，则变为 insert 操作，相当于一种逻辑的反向操作。 而 undo log 除了记录下每一次的操作类型、数据状况和事务 ID 外，还蕴含了一个指针：即上一次的记录指针，以造成残缺的历史链路。 所以 MVCC 历史版本数据就来是从 undo log 的记录指针去追溯获取的。那么，最近一次的记录指针是寄存在哪里呢？ 实际上，每当咱们插入一行数据的时候，数据库还会额定的帮咱们生成 2 个隐形字段： DB_TRX_ID：事务 IDDB_ROLL_PTR：回滚记录指针。这一行的 DB_ROLL_PTR 也就是最近一次的记录指针了，这样的话，每次须要追溯历史版本，就能够从这开始了。 后面提及到事务的隔离性，隔离性是有四个隔离级别的：未提交读、已提交读、可反复读、可串行化。而事实上 MVCC 只在已提交读、可反复读隔离级别上实现了。 ...

Mysql专栏 - 缓冲池补充、数据页、表空间简述前言 这一节咱们来持续讲述对于缓冲池的内容，以及对于数据页和表空间的内容，当然内容页比拟根底和简略，了解相干概念即可。 概述补充缓冲池的内容，对于后盾刷新线程，以及多线程拜访buffer pool的锁模式等数据行和数据页的构造，简要的理解简略的外部细节。表空间以及数据区，以及整个mysql表的逻辑构造缓冲池补充 在介绍具体的内容之前，这里先补充对于缓冲池的一些细节。 后盾线程定时刷新冷数据 上一节提到了冷热数据拆散，其实冷数据不可能是在缓冲池满的时候才会进行刷新的，而是会在LRU冷数据的尾部随机找几个缓存页刷入磁盘，他会有一个定时工作，每隔一段时间就进行刷新的操作，同时将刷新到磁盘之后的数据页退出到free链表当中。所以LRU的链表会定期把数据刷入到磁盘当中进行解决，并且在缓存没有用完的时候会清空一些无用的缓存页。 flush链表的数据定期刷入缓存 flush的链表寄存的是脏页数据，当然它也有一个定时工作，会定期把flash链表的数据刷入到缓冲池当中，并且咱们也能够大抵认为整个LRU是一直的挪动的，flush链表的缓存页页在一直的缩小，free list的内容在一直变多。 多线程并发拜访是否会加锁 多线程拜访的时候会进行加锁，因为读取一个缓冲页波及 free list, flush list, lru list三个链表的操作，并且还须要对于数据页进行哈希函数的查找操作，所以整个操作过程是必定要加锁的，尽管看似操作的链表有三个，然而实际上消耗不了多少的性能，因为链表的操作都是一些指针的操作查找操作，所以根本都是一些常数的工夫和空间耗费，即便是排队来一个个解决，也是没有多大的影响的。 多个buffer pool并行优化 当mysql的buffer pool大于1g的 时候其实能够配置多个缓冲池，MySQL默认的规定是：如果你给Buffer Pool调配的内存小于1GB，那么最多就只会给你一个Buffer Pool。比方在上面的案例当中如果是一个8G的Mysql服务器，能够做如下的配置： [server]innodb_buffer_pool_size = 8589934592innodb_buffer_pool_instances = 4 这样就能够设置4个buffer pool，每一个占用2g大小。理论生产环境应用buffer pool进行调优是非常重要的。 运行过程中能够调整buffer pool大小么？ 就目前解说来看，是无奈实现动静的运行期间调整大小的。为什么？因为如果要调整的话须要把整个缓冲区的大小拷贝到新的内存，这个速度切实是太慢了。所以针对这一个问题，mysql引入了chunk的概念。 mysql的chunk机制把buffer pool 拆小 为了实现动静的buffer pool扩大，buffer pool是由很多chunk组成的，他的大小是innodb_buffer_pool_chunk_size参数管制的，默认值就是128MB，也就是说一个chunk就是一个默认的缓冲池的大小，同时缓存页和形容信息也是依照chunk进行分块的，假如有一个2G 的chunk的，它的每一个块是128M，也就是大略有16个chunk进行切割。 有了chunk之后，申请新的内存空间的时候，咱们要把之前的缓存复制到新的空间就好办了，间接生成新的到chunk即可。而后把数据搬移到新的chunk即可。 生产环境给多少buffer pool适合？ 如果32g的mysql机器要给30g的buffer pool，想想也没有情理！crud的操作根本都是内存的操作，所以性能非常高，对于32g的内存，你的机器起码就得用好几个g的解决，所以首先咱们能够调配一半的内存给mysql.或者给个60%左右的内容即可。 `innodb_buffer_pool_size`默认的状况下为128M，最大值取决于CPU的架构。在32-bit平台上，最大值为`(2^32 -1)`,在64-bit平台上最大值为`(2^64-1)`。当**缓冲池大小大于1G时**，将`innodb_buffer_pool_instances`设置大于1的值能够进步服务器的可扩展性。最初大的缓冲池能够减小屡次磁盘I/O拜访雷同的表数据，如果数据库配置在专门的服务器当中，能够将缓冲池大小设置为服务器物理内存的60 - 80%，也就是说32g的内容给24g - 26g都是比拟好的抉择，当然 。buffer pool调配公式： 对于buffer pool，这里有一个要害的公式：buffer pool总大小=(chunk大小 * buffer pool实例数量)的倍数，默认的chunk大小是128M, 要给20G的buffer pool ，而后依照公式套入就是：Buffer pool = 128 * 16 * 10，也就是每一个chunk大小是128，再次强调一遍buffer pool总大小=(chunk大小 * buffer pool数量)的倍数 ...

MySQL 架构（图片来源于《MySQL 实战 45 讲》） 索引下推索引下推，简称 ICP，英文全称：Index Condition Pushdown，用于优化查问。其外围点就在于把数据筛选的过程放在了存储引擎层去解决，而不是像之前一样放到Server层去做过滤。 这是 MySQL 5.6 之后新增的性能。 MySQL 5.6+ 默认是开启 ICP 的，能够通过以下命令敞开： SET optimizer_switch = 'index_condition_pushdown=off';从一个查问开始如下： create table if not exists `sakila`.`user` ( `id` int unsigned auto_increment not null , `age` tinyint unsigned not null default 0, `name` varchar(30) not null default '', `city` varchar(30) not null default '', primary key (`id`), key `idx_age_name`(`age`, `name`) using BTREE ) engine=InnoDB; insert into `sakila`.`user` (`age`, `name`, `city`) values (10, 'Jack', 'Beijing'), (5, 'Jane', 'Shanghai'), (21, 'Jhon', 'ChongQing');当初有以下查问： ...

近日，DB-Engines 更新了的9月份数据库引擎排行。榜单前 10 名里，Oracle、MySQL、Microsoft SQL Server 别离以 1271.55、1212.52、970.85的分数蝉联前 3 甲，前面顺次是PostgreSQL、MongoDB、Redis、IBM Db2、Elasticsearch 、 SQLite 以及Cassandra。 本次DB-Engines榜单，通过综合打分，对 354 个数据库模型进行排名，并将2021年9月/8月排名与2020年排名做了比照。用户可依据去年到往年的每一项得分比照，查看具体排名的变动。 榜单排名第 3 位的 Microsoft SQL Server ，近年来得分始终打分处于降落趋势。同比去年分数降落了 91.91 分，比照往年 8 月份，本次排名得分降了 2.5 分。好在 Microsoft SQL Server 此次的 970.85 分，比照 577.50 分排名第 4 的PostgreSQL，临时还有劣势。 本次榜单中，MySQL 名次降落最显著。同比 2020 年同期，分数降了 51.72 分，相比往年 8 月份，其分数降了 25.69 分，但比照前面一位同样有肯定劣势 。 本次榜单前 10 里，除去前 5 的地位无变动之外，前面 5 位外面有小变动。其中，去年排在第 7 位的 Redis ，往年以171.94 的得分排到了第 6 位；去年排第 6 的 IBM Db2 ，往年以166.56 的得分降了一名排到了第 7 ，两者排名呈现了调换。 ...

摘要日志的存在，为数据库的很多性能提供了保障。像用于回滚数据的 undo log，用于复原数据的 redo log， 以及用于主从备份的 binlog。本文将会大抵介绍下数据库里的日志类别，以及重点剖析下事务日志的相干知识点。 日志分类在 mysql 里的日志品种有很多，从总体上来讲能够分为 Server 层 和 存储引擎层的（对于 mysql 的总体架构能够看这篇：mysql 系列：总体架构概述）。 在 Server 层里的日志分类如下： 谬误日志谬误日志是 mysql 在启动、运行或进行时出现异常的日志。咱们能够通过上面这个命令来查看谬误日志的地位： SHOW VARIABLES LIKE 'log_error';下面默认查问到的是 stderr，示意规范谬误输入，如果有终端存在，则只会在终端打印谬误。 当然，咱们也能够在 my.cnf 里设置谬误日志地位： [mysqld] log-error=谬误日志地位应用场景：像咱们在启动 mysql 失败时，个别能够到谬误日志里查看。 通用查问日志通用查问日志记录了用户的所有操作，包含 sql 语句的查问更新。个别状况下是不会开启的，有点相似于咱们平时应用 debug 级别的日志。同样的，咱们也能够通过上面的语句来查看是否开启及其输入地位： SHOW VARIABLES LIKE '%general%';当咱们想要开启通用查问日志，以记录所有客户端的 sql 操作时，就能够用上面的语句了： SET GLOBAL general_log=on;下面的日志输入是到文件，如果想要应用 sql 语句来查找日志，能够将日志的输入设置为表： SET GLOBAL log_output='table';而后就能够应用上面的 sql 语句来查问了： select * from mysql.general_log;这样就能够监控到所有客户端的操作状况了，当然，不要遗记应用完后敞开日志，否则将会占用很大的磁盘空间。 DDL 日志DDL 日志记录了数据库里元数据的变更信息。DDL 即数据定义语句，像 create，drop，alter语句。 DDL 日志是一个二进制文件，不被人为的浏览批改，也没有其余配置项能够配置它。个别寄存在数据目录下，ddl_log.log 文件即是。而且在胜利启动 mysqld 后会被删除，只有在记录元数据时才会被从新创立。 ...

Integer type (Exact Value)TypeStorage (Bytes)Minimum Value SignedMinimum Value UnsignedMaximum Value SignedMaximum Value UnsignedTINYINT1-1280127255SMALLINT2-3276803276765535MEDIUMINT3-83886080838860716777215 (千万)INT4-214748364802147483647(二十亿)4294967295(四十亿)BIGINT8-2^6302^63-12^64-1int类型占用4个字节参考:https://dev.mysql.com/doc/ref...

MySQL - 锁的品种和概念

Mysql专栏 - 缓冲池的内部结构(二)前言 这是mysql专栏的第四篇，上一个大节咱们理解了如何通过flush list存储所有的脏页数据，这一节咱们来持续介绍缓冲池的内部结构LRU链表。 概述 缓冲池的大小是固定的，缓冲池当然不是永远都驻留在缓冲池的，然而闲暇缓冲页不够状况下如何解决呢？本节将会探讨缓冲池重要的淘汰机制：LRU的淘汰机制，后续会介绍mysql的冷热数据拆散个性，最初将给出几个思考题回顾整个内容。 缓存页的刷新机制 - LRU淘汰缓存页Buffer pool 中的缓存页不够怎么办？ 通过上一节的探讨，当执行器发来了增删改查的申请的时候会从磁盘文件读取对应的数据块到缓冲池当中，之前提到过缓冲池不是有限的，默认状况下最多只有128m，一旦所有的缓存页都被加载就意味着free list外部没有闲暇的缓存页，当所有的闲暇缓存页被调配完了，这意味着缓冲池曾经无奈再调配缓冲页了，然而咱们还想把数据页加载到缓存池怎么办？ 如果咱们想要加载新的缓存页也非常简略，只有淘汰一些不罕用的缓存页即可。 淘汰那个缓存，淘汰谁？ 淘汰缓冲页就是把缓冲池外面的某个缓冲页刷新到磁盘（必须先刷新数据到磁盘）而后把对应的缓存页删除即可。接着再把新的数据页的内容加载到缓冲池即可。那么到底要把那个缓存页刷新到磁盘呢？ 缓存命中率 缓存命中率很好了解，假如有两个缓存页，第一个缓存页在100次申请中查问和批改了30次，意味着这个缓存页的命中率为30%。并且缓存命中率不错。第二个缓存页则在100次内只操作了1，2次，这意味着缓存命中率很低，所以不用说，必定是淘汰第二个。 LRU链表淘汰算法 为了判断哪些缓存页常常被拜访，哪些缓存页很少被拜访。mysql引入一个新的LRU链表，LRU 就是least recently used，也就是起码应用的意思。通过这个LRU链表，咱们就能够晓得那个缓存页是起码应用的，当须要一个新的缓存页的时候就能够通过一个LRU链表晓得那个缓存页应用频率最低并将其刷新到磁盘文件并且移除。 当某个缓存页被操作的时候，就会找到LRU列表对应的节点退出进去，须要淘汰一个缓存页，就找到LRU列表的尾部进行淘汰(输出磁盘并且从缓冲池状况，同时free list减少一个闲暇的形容信息节点)，因为最初一个节点必定是应用频率最低的。 上面咱们依据之前文章的结构图，补充一个LRU链表，最初的结构图内容如下： 简略的LRU链表存在哪些问题？ 当Free list没有可用的闲暇节点的时候，须要从LRU链表的尾部刷新一个缓存块到磁盘并且清空这个缓存块把地位让给新的数据块。 然而mysql的LRU的链表有许多的个性。那么在介绍新个性之前，咱们来看下一般的LRU链表会带来哪些问题 简略的LRU链表有哪些问题呢？ 1. 预读： 首先这样的LRU有一个重大的隐患：预读，比方当初存在两个闲暇缓存页，加载一个数据页之后，同时会把相邻的数据页页加载到缓存区，正好每一个数据页放入一个闲暇缓存页。意味着实际上只有一个缓存页被拜访了，另一通过预读的机制加载的缓存页，然而这两个都被放到了链表的最后面，最初，预读会造成尾端的缓存页被谬误的删除，然而正确的做法是删除第二个被预读缓存的缓存页。 接着咱们来看看，到底哪些状况下会触发MySQL的预读机制呢? (1) 有一个参数是**innodb_read_ahead_threshold**，他的默认值是56，意思就是如果程序的拜访了一个区里的多个数据页，拜访的数据页的数量超过了这个阈值，此时就会触发预读机制，把下一个相邻区中的所有数据页都加载到缓存里去。 (2) 如果Buffer Pool里缓存了一个区里的13个间断的数据页，而且这些数据页都是比拟频繁会被拜访的，此时就会间接触发预读机制，把这个区里的其余的数据页都加载到缓存里去 这个预读机制是通过参数**innodb_random_read_ahead**来管制的，他**默认是OFF**，也就是这个规定默认是敞开的吐槽：预读的机制有点相似机器磁盘的程序拜访操作。2. 全表扫描 全表扫描置信学过数据库的都晓得这个理念，。从底层来看一个全表扫描的查问可能会把表所有的数据页放到buffer pool外面，最终可能会把一整个表的数据页加载到缓存页外面，LRU的后面一大串页都是全表查问的数据页。这会导致尾部淘汰的缓存页是一些常常用到的缓存页，而留下的都是不怎么应用的数据块，这样缓存的命中率会大大降低，导致整个mysql的性能非常差。 冷热数据拆散的LRU 解决下面的两个问题激素应用冷热拆散的LRU，冷热拆散的意思是说依照肯定的比例把整个链表分为热数据和冷数据，mysql当中由 innodb_old_blocks_pct 参数进行管制，默认是37, 意味着冷数据占了37%，热数据占了63%。 冷热数据如何应用 第一次加载的时候缓存页的数据会放到哪一个地位？略微推敲一下不难得出答案那就是：冷数据的头部。第一次把数据页退出到缓存页默认会放到冷数据的头部。 冷数据什么时候进入热数据 冷数据进入热数据必定是须要肯定的缓存命中率的，所以是依照缓存命中率断定的，是这样么？其实不是的，这样想是错的，因为这很难作为一个衡量条件。其实冷热数据是依照第一次加载缓冲页1S之后如果你还是拜访了这个数据页，那么这个数据就会降级为热数据也就是放到热数据的头部，另外这个参数是依据innodb_old_blocks_time这个参数进行判断的，默认设置的参数就1000（毫秒）也就是1s。 缓存页不够如何淘汰缓存 冷热拆散之后淘汰缓存页就简略了，间接找到冷数据的尾部缓存页，把这些缓存文件刷到磁盘文件之后能够间接革除，无需放心他们这些数据可能是频繁拜访的数据。 冷热拆散如何解决预读和全表查问问题 当预读和全表查问加载出一大堆的数据之后，会发现他们的数据其实都在冷数据的头部的，然而如果1S之后仍然频繁拜访的冷数据，则会一直的放到热数据的头部去的，然而一大段读取进去的冷数据，因为只拜访了一次之后就再也没有拜访过了。所以是没有什么关系的。 预读和全表加载的数据，会进入热数据区域么？ 如果仅仅是一个全表扫描的查问，此时你必定是在1s内就把一大堆缓存页加载进来，而后就拜访了这些缓存页一下后就完事了，通常这些操作1s内就完结了。也就是说一个全表查的数据许多的长期数据是会间接放到冷数据页的。然而如果这部分数据在1S之后再次被拜访，才会降级为热数据。然而“全表查最好尽量避免，谬误的热数据也是隐患”。 ...

前言这次新开了一个集体的mysql专栏，专门用于总结mysql的一些细节以及相干的案例总结，同时也包含了一些mysql的底层实现，在后续的篇章则是依据《mysql技术底细innodb存储引擎》（第二版）来深刻理解mysql中用的最多的存储引擎的外部细节。 什么是数据库驱动？mysql的驱动置信每一个做开发的人员都很相熟，在通常的状况下咱们只须要引入一个mysql的依赖同时应用jdbc的模板代码就能实现一次mysql的连贯。 一次网络连接必须要让线程来进行解决 毫无疑问，一次网络连接不论是在tomcat还是在mysql的外部都是通过一个独自的线程进行治理的，当然tomcat的线程和mysql的线程没有任何的关系。 咱们通常状况下都是间接应用tomcat的servlet Api进行开发，同时Servlet的每一次拜访都是一个独自的线程，意味着每个用户的拜访都是互相隔离的，然而如果咱们数据库驱动连贯是单线程的并且只能有一个用户连贯，当之前的线程还在连贯解决数据，前面的线程进行连贯那么之前的解决数据的数据库连贯就会断开，这样必定是不行的，同时如果线程用完之后就被抛弃，这样也会造成资源的节约甚至有可能呈现闲暇线程明明有很多然而零碎因为某种状况无奈回收等问题，最终导致线程期待数据库的连贯申请等问题，基于这些问题数据库有了连接池的概念。 数据库连接池连接池的作用就是维持数据库当中多个数据库连贯，当有线程拜访的时候就会从连接池当中调配一个连贯给对应的线程。另外mysql架构当中的第一个重要体系概念就是连接池，值得注意的是连接池并不是单方面的的，而是在连贯方和mysql数据库驱动方都会存在一个数据库的连接池。 依据下面的介绍，咱们绘制出上面的一张图，能够看到其实在tomcat的外部以及mysql服务器的外部都有一个对应的连接池进行对应，有了数据库连接池之后，每一个用户解决完数据库的申请会把线程归还给线程池，这样不仅进步了线程的复用率又保障了每一个用户的数据库连贯和操作是独立的。 疑难：1. mysql数据库连接池最多能够开启多少个连贯？2. 如何管制mysql的连接数?解答：1、查看最大连接数show variables like '%max_connections%';然而这里有一个参数叫做 'max_user_connections'的参数，这个参数和'max_connections'有什么关系呢?max_connections 是指整个mysql服务器的最大连接数；max_user_connections 是指每个MySQL用户的最大连接数2、批改最大连接数set GLOBAL max_connections = 200;mysql的根本构造上面咱们来看下mysql的根本构造是什么，从外层来看，整个申请的解决仿佛都是在mysql服务器外面进行解决，然而实际上mysql设计必定不会这样简略，在mysql的外部，他会被拆分为上面这几个组件： sql解析器：解析用户发来的sql语言，负责剖析语法，对于sql语句进行拆解等相干操作。 查问优化器：查问优化器负责解析之后的sql语法进行逻辑的优化，保障sql能够依照最短门路来执行 存储引擎：存储引擎是用于真正执行sql的组件，存储引擎依照sql语句进行内存和硬盘上的数据更新操作。同时应用对外的接口进行操作。 执行器：执行器就是负责真正调用存储引擎上接口的组件。 上面咱们依照下面的程序通过图画来形容mysql外部是如何运作的： sql解析器：当咱们通过tomcat发送一条申请的时候，数据库连贯会干啥，他会依据tomcat发来的查问语句，通过一个叫做sql解析器的货色进行解析，其实数据库服务器自身也不晓得这条语句干啥用的，所以sql解释器负责管理这个货色，在通过sql接口承受到申请之后，会传递个sql解析器去进行解析动作。 select id,name,age from users where id=1个查问解析器(Parser)就是负责对SQL语句进行解析的，比方对下面那个SQL语句进行一下拆解，拆解成以下几个局部: 咱们当初要从“users”表里查问数据查问“id”字段的值等于1的那行数据对查出来的那行数据要提取外面的“id,name,age”三个字段通过下面的案例咱们能够晓得了，Sql解析其实就是合成sql语法，通过sql语法分析出具体要做什么事件。 查问优化器既然晓得了如何解析，上面就应该理解如何进行查问优化了。查问优化器顾名思义就是对于查问的门路进行优化和抉择，比方上面的sql语句有两种抉择（当然数据库实在执行必定不是这样的，然而咱们能够含糊的了解） 查问id=?的记录，并且提取对应的字段找到须要的三个字段的所有数据，并且从中抉择id=?的数据查问优化器就是用来优化查问逻辑的，会用最短的查问门路对于查问进行优化。 当然这种优化是无限的，更多状况下还是要看sql语句的查问逻辑是否简单以及sql的品质是否足够好。 存储引擎既然查问优化器还不是执行查问的中央，那么咱们接下来再来看下查问优化器解决完之后如何解决。 咱们都晓得数据库无非是由一种非凡的数据结构结构的文件罢了，只是对外提供特定的接口以及须要依照mysql的语法能力对数据进行crud，既然是操作数据，那必定逃不过硬盘和内存，既然存储引擎是间接和这个数据结构打交道的，那么通过查问优化器优化过的的查问语句必定是要交给存储引擎的，既然执行语句的操作是交给存储引擎的，换句话说就是决定如何解决sql的最终执行权在存储引擎手上。 执行器存储引擎能够执行sql语句，然而谁来操作存储引擎的接口呢？实际上调用存储引擎接口的是执行器，执行器会依照存储引擎的接口依照肯定的逻辑对sql进行执行。那么要如何调用接口呢？执行器会依据以后的存储引擎配套一份执行打算，而后调用存储引擎实现sql的语句对于数据进行增删改查。 依据下面的介绍，咱们能够发现实际上mysql最外围的局部是 存储引擎，它是真正在做事的一个组件。所以上面将会介绍innodb存储引擎的构造: innodb存储引擎和构造这里跳过innodb的介绍，咱们间接来理解外部的具体构造： 缓冲池innodb应用缓冲池来缓解磁盘操作的压力，尽量让数据的操作在内存中进行，同时应用不定时脏数据刷盘的操作将内存的数据同步到磁盘，和少数的缓存作用了解一样，在进行查问的时候如果发现命中了缓冲池则会查缓存的数据，否则查磁盘的数据。在查缓存的时候为了避免其余的线程把缓冲池的数据变脏，会对数据进行加锁的操作。 undo日志undo日志作用和咱们平时的ctrl+z的原理是一样的，在更新数据之前innodb须要先把批改的前的数值放到undo日志外面，而后在执行后续的操作，这个undo日志也实现事务回滚的组件，理解mysql咱们都晓得数据要么在事务外面要么在事务执行之前的undo日志，一旦事务操作失败或者手动调用回滚rollback，此时mysql就须要依据undo日志的内容把数据进行回滚。 redo缓冲池和redo日志文件redo日志翻译过去就是重做日志，他的构造相似缓冲池和硬盘的链接形式，所以从了解上来看须要看作两局部缓冲池和日志文件，整个redo的作用就是记录哪一行的数据进行了批改并且在事务提交将缓存刷新到日志文件进行同步。（说白了还是磁盘io） 理解了根本redo作用之后咱们来思考一下如果mysql服务操作数据的时候产生了数据失落的状况，会呈现什么状况？ 为了解决这个问题，innodb在筹备执行事务之前会当时操作一遍redo log buffer的缓冲区，这个缓冲区用来寄存哪一行文件的那个字段被批改了，记录数据所在的地位以及改变的数据内容等。 事务没有提交，宕机了如何解决？数据库当中每次执行一条sql都是一个事务的提交。如果数据库解体则会呈现redo日志失落的状况，时候mysql如何解决？ 这个问题很简略，事务都没有提交，阐明数据压根没有批改，而且此时尽管缓冲池的数据变了，然而磁盘数据行的内容没有变，所以redo缓冲池的数据失落了也没有影响，当宕机重启复原之后将会通过undo日志把内容进行还原。 提交事务之后将redo日志写入磁盘事务提交之后，此时redo会应用肯定的策略把redo_log_buffer 的数据刷新到磁盘文件中，能够通过一个配置：innodb_flush_log_at_trx_commit更改策略 当这个值为0的时候不会把redo_log_buffer的内容刷新到磁盘，此时如果mysql宕机，内存的文件就全副失落了： 如果把这个值设置为1：就会在事务提交胜利之后把redo缓存数据刷新到日志文件当中，并且文件当中也会存在一条你批改了xxx行那个字段的记录。 如果此时缓冲池的内容更新了，redo日志的内容也更新了，redo文件外面的内容也记录了记录的批改内容，此时mysql忽然宕机了会导致磁盘文件的磁盘数据的不统一么？必定不会的，如果此时一旦宕机，缓冲池就会去redo日志复原之前的批改操作 如果innodb_flush_log_at_trx_commit 设置为2，会是什么状况？此时提交事务的时候会把redo日志写到os cache外面，而不是写入磁盘，可能会是1秒之后才会把os cache的数据写入到磁盘文件。然而此时须要留神这个日志文件是在cache外面的，所以意味着一旦宕机os cache的日志内容也没了。 三种redo日志刷盘策略到底抉择哪一种? 提交事务的时候，咱们对redo日志的刷盘策略应该抉择哪一种?每一种刷 盘策略的优缺点别离是什么?为什么? 如果对于数据特殊要求个别状况下选1就能够了，如果选0，mysql一旦宕机就生效了，如果选2，同样尽管数据是写入到零碎缓存的当中。然而还是在内存外面，只有断电宕机，数据同样会失落。 Binlog 日志咱们先看下binlog日志在整个mysql执行过程中的过程步骤： ...

Mysql专栏 - 缓冲池的内部结构（一）前言 这一节咱们来介绍缓冲池的内部结构。如果不分明缓冲池是什么货色能够查看之前系列的第一篇文章。缓冲池最简略的了解为数据库磁盘文件在内存对应的映射，是一个非常重要的外围组件，缓冲池的内容和细节还是挺多的，这部分内容集体会限度篇幅让读者更好的消化。 缓冲池的介绍：Mysql专栏 - mysql、innodb存储引擎、binlog的工作流程#缓冲池概述Buffer pool的内部结构 数据页和缓存页的关系数据页的形容信息是什么？Mysql是如何晓得哪些数据页被加载了脏页 脏页的伪代码实现以及脏页的介绍重点 分分明free list和flush list 相熟整个buffer pool的结构图。 Buffer pool 构造 对于buffer pool的残缺结构图如下，本文将会一一合成来讲述各个块的内容： Buffer pool在mysql中位置 Buffer pool能够看作是一个内存构造的组件，能够了解为一大片的内存区域，在默认的状况下它是128m的空间大小。须要留神的是默认值比拟小，通常状况下这个值是远远不够的。 从结构图来看缓冲池是十分外围的一个组件，因为mysql数据的操作不可能放到磁盘实现的，哪怕是固态硬盘也是不可能快过内存，缓冲池能够看作是数据操作的时候磁盘文件的数据的一对一映射，然而如果咱们操作内存又会呈现另一个问题，内存的操作是非常快的，然而硬盘的刷新速度更不上内存，所以就会呈现内存和硬盘上的数据不统一的问题，种因为某些操作更新之后的内容更新过的数据页在mysql当中统称为脏页。 所以redo log、undo log、bin log这几个日志文件某种程度上能够认为是为了确保数据正确同步的策略而呈现的。 数据页和缓存页 既然缓冲池是一块内存空间，那么数据是否在buffer pool中呢？咱们的数据是如何放在buffer pool中的？ 这里咱们咱们来回顾下数据库的逻辑构造，数据库分为表+字段+行的模式，一个表有很多行数据，那么数据页的内容就是多行？其实数据库抽取了一个叫做数据页的概念，多行数据会放到一个数据页外部，磁盘中有多个页，每一个页都有很多行数据合并到一起，最终咱们更新数据就是找到某一个页的某一行。 数据页的默认大小：16kb，缓存页的大小也是16kb。 总结：buffer pool寄存的是一个个数据页，也叫做缓存页，因为buffer pool是一个近似内存的缓冲池，所以硬盘的数据会转变为一个个缓存页缓存到这块“内存”当中。Buffer pool中一个缓存页和磁盘的一个数据页大小是对应的都是16kb。 缓存页的形容信息 尽管咱们晓得了缓存页的大小，缓存页外面寄存的也是一行行的数据，然而缓存页本人是不晓得这些信息的，这时候mysql引入了另一个数据块叫做缓存页的形容信息，在缓存页形容信息蕴含了上面的内容： 所属表空间数据页编号缓存页在缓冲池外面的所属地址 形容信息有多大呢？一个形容信息大略是缓存页的5%左右的大小，可能是800个字节左右的大小，默认128m的缓冲池。须要留神的是，为了避免数据页撑满缓冲池导致形容信息无奈寄存，mysql会给形容信息一些额定的内存空间保障形容信息能够记录所有的数据页（缓存页）。所以这外面128M不是齐全固定的，会额定多个几M的缓存页形容信息。 形容信息如何寄存？ 形容信息和缓存页依照相似“对称”的构造进行存储，形容信息放在缓存页的最后面，缓存页则放在缓冲池的最初面，至于这样设计的起因一方面是尽可能让形容信息不烦扰数据页的调配，另一方面是为了让缓冲池有“额定”并且足够的空间来寄存形容信息。 如何尽量减少buffer pool的内存碎片？ 当缓存页和形容信息划分完数据块之后，必定是会存在一小部分的空间是既不能调配形容信息，又不能放下缓存块的内容的，所以这部分内容没有方法应用。 如何缩小呢？ 在划分缓存页的时候让他们依照程序的排列程序严密排列，尽可能减少节约，其实就是程序的分配内存。 如何晓得哪些缓存页是闲暇的? 那么mysql是如何晓得缓存页是闲暇的呢？在Buffer pool 会有一个叫做free list 双向链表，链表每一个节点就是数据页对应的形容数据块。也就是说一个数据页是闲暇的，就会放到free链表中，并且在数据库刚刚启动free链表寄存了所有形容信息块内容。另外，如果相熟链表的构造，就会晓得链表当中会有一个根底节点（其实就是链表的头指针，只不过内容丰盛很多）来存储开始节点和完结节点等内容。 至于这个根底节点的更新操作，相熟链表的人此时肯定非常分明了，其实就是双向链表的插入操作和删除操作。 为了更好的了解下面一大段的内容，咱们通过一个图来蕴含下面介绍的所有内容： freelist占用多少内存空间？ Buffer pool 和 freelist外面的数据内容是截然不同的一份拷贝么？大错特错！因为形容信息在freelist外面是依据链表的节点规定串联的，同时因为这个节点只须要找到闲暇缓存块即可（Free List中的所有节点都会指向一个从未被应用过的缓存页，说白了就是每个节点有个指向闲暇缓存页的一对一指针）。 ...

前言数据库是一个容许多用户、多会话、多线程拜访的零碎。为了在并发拜访中能保证数据的一致性和完整性，个别会应用事务来做管制，外加锁来作为辅助伎俩。所以明天整顿了一下锁的相干常识，看看它在事务里是怎么配合应用的。 锁的分类咱们先来看下锁的分类及其作用有哪一些，以便能更好的剖析使用场景。 乐观/乐观锁乐观锁：在读取数据时会假如各个事务互不影响，它们会解决好属于本人的那局部数据。如果在更新数据时，发现有其余事务批改了属于本人的数据，则会回滚之前的所有操作。 乐观锁：采取了先获取锁再拜访的激进策略，如果曾经有其余事务获取了锁，则必须期待锁开释能力持续。 共享/排它锁共享锁：又称读锁，以后事务在读取时，容许其余事务并发读取，但不容许其余事务上排它锁，必须等本人开释了能力持续。 排它锁：又称写锁，在写锁占有时，如果其余事务想上读写锁，则得排队期待。 表锁/行锁表锁：在操作数据时，间接将整张表锁住，操作粒度很大，很容易让其余事务在期待，但不会产生死锁。 行锁：针对的是行记录的并发管制，锁粒度很细，能反对高并发，然而不排除会有死锁状况产生。在 mysql 里行锁依赖索引实现，如果没有索引存在，则会间接进行表锁！ 其中，行锁还细分出了上面几种锁： 记录锁：只锁住某一条记录。当对惟一索引(包含主键)进行准确查问时，会应用记录锁。 间隙锁：当应用范畴查问时，会对符合条件的区间数据上锁。在波及到一般索引（即不是惟一索引）的查问时，都会应用间隙锁。 Next-key 锁：临建锁，能够了解为 记录锁 + 间隙锁。当对惟一索引进行范畴查找或对惟一索引进行查找但后果不存在时（能够了解为锁住不存在的记录），会应用临建锁。 下面的间隙锁、临建锁无效的避免了事务幻读状况产生，防止了在查找期间有数据新增或删除。 意向锁意向锁是属于表锁的一种，它仅仅示意一种操作动向。当咱们应用粒度比拟小的行锁时，在检测是否有锁时，须要一行一行的查看，效率较低。 有了意向锁之后，则不需一行一行的排查，只需检测对应的意向锁即可。 意向锁有动向共享锁，以及动向排它锁。mysql 规定事务在上共享/排它锁时，必须能先获取到兼容的意向锁，否则必须期待锁的开释。 例如以后数据上已有动向共享锁，如果此时其余事务想上排它锁，则是不兼容的，必须期待开释。对于意向锁和共享/排它锁的兼容性表如下： 动向共享锁动向排它锁共享锁兼容互斥排它锁互斥互斥MVCCMVCC 并不属于锁操作里的货色，然而它是事务隔离级别里会使用到的技术，并且因为它有相似快照数据的性能，所以应用 MVCC 时能很大水平的缩小锁的应用，缩小了并发抵触。具体能够看看这篇文章：MVCC。 事务里锁的使用在之前的文章事务解释里咱们谈到了事务的隔离性，而事务的隔离性离不开锁的使用，所以当初就让咱们来看看具体的应用吧。 可反复读可反复读应用的是 MVCC 快照，所以在读取数据时大多数时候不须要应用锁。 但应用了 UPDATE, DELETE，或 SELECT with FOR UPDATE（排它锁） 或 FOR SHARE（共享锁），则会依据上面的状况来应用锁： 在惟一索引上准确查找某条记录时，应用记录锁对于其余的搜寻，InnoDB 将会锁定扫描到的索引范畴，应用间隙锁或临建锁来避免幻读的产生读提交也是应用 MVCC 机制来读取数据，不过在应用 UPDATE, DELETE，或 SELECT with FOR UPDATE（排它锁） 或 FOR SHARE（共享锁）时和下面的机制不一样，当存储引擎将筛选到的记录交给 mysql server 层后，会对不相干的数据进行解锁，所以不会波及间隙锁或临建锁。 它们只会在做外键束缚检查和反复键查看时应用到。 因为间隙锁的禁用，可能会呈现幻读景象。 未提交读在 mysql 的 innodb 存储引擎里做 SELECT操作不会做任何锁动作，如果是 myisam 存储引擎，则会上共享锁。 ...

脚本#!/bin/bashDING_TOKEN='https://oapi.dingtalk.com/robot/send?access_token=xxx'MYSQL_PORT=3306MYSQL_VIP1=192.168.1.111MYSQL_VIP2=192.168.1.112MYSQL_USERNAME=rootMYSQL_PASSWORD=rootGET_MYSQL_PORT=`netstat -na|grep "LISTEN"|grep "3306"|awk -F[:" "]+ '{print $5}'`CHECK_MYSQL=`mysql -u$MYSQL_USERNAME -p$MYSQL_PASSWORD -h $MYSQL_VIP1 --connect_timeout=5 -e "show databases;"`STATUS=$(mysql -u$MYSQL_USERNAME -p$MYSQL_PASSWORD -h $MYSQL_VIP1 -e "show slave status\G" | grep -i "running")IO_env=`echo $STATUS | grep IO | awk ' {print $2}'`SQL_env=`echo $STATUS | grep SQL | awk '{print $2}'`function checkMysqlStatus(){ if [ "$GET_MYSQL_PORT" == "3306" ] then if [ "$CHECK_MYSQL" -ne 0 ] then dingAlert "Server: $1 mysql is down, please try to restart mysql by manual!" else echo "Server: $1 mysql is running..." fi else dingAlert "WARN!Server: $1 mysql is down." fi if [ "$IO_env" = "Yes" -a "$SQL_env" = "Yes" ] then echo "Server: $1 MySQL Slave is running!" else dingAlert "Server: $1 MySQL Slave is not running!" fi}function dingAlert(){ curl $DING_TOKEN \ -H 'Content-Type: application/json' \ -d "{\"msgtype\": \"text\", \"text\": {\"content\": \"数据库监控测试\n$1\"}}"}参考资料mysql主从监控shell ...

版本抉择MySQL 8.0.20 CentOS 7.6 下载地址https://downloads.mysql.com/a... 部署细节次要参考：https://blog.csdn.net/weixin_...惟一不同，遇到报错，短少libaio.so.1类库。yum装置即可：yum -y install libaio 常用命令查看mysql运行状态：systemctl status mysqld

摘要索引是数据库里重要的组成部分，也是进步查问效率必备的知识点。本文将会介绍索引作用、索引类型、索引优化以及索引底层构造，也算是对索引常识的一次演绎。 一、索引介绍什么是索引？数据库是用来存储与读取数据的，如何在这宏大的数据中查问咱们想要的那一行呢？最简略的方法便是扫描整个数据表，一一比照。然而这样效率太低了。 如果咱们有相似字典的性能，在查问某行数据前，先到字典里定位到行地位，再依据行地位找到具体数据，是否能更快呢？是的，索引就是这么设计的。 个别的，咱们往表里插入某一行数据时，总会有额定的信息来定位到这一行。这个信息可能是一个指针地址，也可能是一个主键标识。 在拿到这一行的定位信息后，就能够将列数据和定位信息做关联了。下次想查找这个字段列所对应的行数据时，就能够先到关联信息里搜寻，拿到定位信息后间接查找即可。这就是索引，存储了列和定位信息，这定位信息也能够了解指向数据记录的援用指针。 须要留神的是，索引是由存储引擎这个模块来实现的，不同的存储引擎有不同的实现形式。像 innodb 的主键就蕴含了行数据，找到了主键，也就找到了数据。 索引的分类在数据库里，索引有好多种。咱们能够从上面几方面来分类演绎。 从数据结构划分：B+ 树、hash 索引、全文索引 从物理构造划分：汇集索引、非汇集索引 从逻辑用户划分：主键、惟一索引、复合索引、一般单列索引 其中， B+ 树、 hash 索引、全文索引将会在前面具体介绍其底层构造，咱们来看看其余的索引： 汇集索引：该索引除了存储索引信息还存储了行数据，像刚刚提到的主键就是。找到它也就象征找到数据了。并且它的排序间接对应了物理存储程序。 非汇集索引：该索引除了存储索引信息还存储了定位到数据记录的信息，须要依据这个信息再做一次查问，能力获取到数据，并且它的排序是逻辑上，不是物理存储程序。 主键：惟一地标识表中一条记录的索引，不能有 NULL 值。在 InnoDB 里，主键就是汇集索引。 惟一索引：索引所对应的列值里是不能有反复值的，容许有 NULL 值。像刚刚提到的主键是不容许有 NULL 值的。 复合索引：有多列组合在一起的索引，但只能按最左准则查找，即第一列字段能力被索引查找，前面只是作为附带信息寄存着。次要是为了找到索引后，不须要再去行数据里捞数据，间接从索引里提取字段信息即可。 一般单列索引：没有什么限度条件的索引列。 索引的毛病引入索引，并不总意味着高效，它是须要付出代价保护的。每当有数据须要增加更新时，都得更新对应的索引，这是额定的性能开销，甚至有可能有呈现死锁。 另外，索引是须要占用磁盘空间的，不能无限度的增加索引，要有针对性的建索引。 二、索引的应用应用准则索引之所以那么快，是因为咱们将平时查问频率较高的字段独自保护了起来。当咱们有多个查问选项，多个查问条件就不肯定能发挥作用了，所以索引的应用是有注意事项的，上面总结了一些： where 里最常常用到的查问字段才建索引，能利用主键 id，就用主键 id 来增删改查按最左匹配准则，将多个单列索引改为复合索引，缩小保护量尽量挑抉择度高，也就是反复率低的列作为索引，像性别这种列就不适宜了，会在 B+ 树里做多层次多范畴的搜寻，还不如全表扫描呢查找时，不对索引列做函数计算，否则不能应用到索引查问条件尽量用 union 来取代 orlike 用法： ‘列%’ 这样还是能够用到索引的，'%列%' 就不行了IS NULL，IS NOT NULL 是用不到索引的在 order by，group by 里尽量应用索引字段join 的 on 条件里尽量应用索引字段性能剖析当咱们应用了索引后，又如何晓得它有没有应用到索引呢？咱们能够借助执行打算来剖析，执行打算是 mysql 依据咱们的查问语句进行一系列的剖析后失去的优化计划。咱们能够通过执行打算来获取执行过程。 执行打算的获取： explain select 语句 波及的字段含意如下： ...

Mysql专栏 - 线上调优与压力测试 前言 本节内容讲述线上的调优伎俩以及压力测试的相干工具，联合一些理论的命令参数，咱们将会介绍运行后果的具体含意。本节内容为大抵的介绍如何压力测试和如何浏览参数，具体的运行成果须要本人部署一台机器测试，对于这部分的内容受到不同的机器影响会呈现齐全不同的成果，须要理论测试所以没有进行记录。 概述介绍常见的mysql零碎性能剖析指标，介绍吞吐量和机器的抉择压力测试工具的介绍，以及数据库压力测试的实战。最初将会依据Linux零碎的命令介绍如何浏览mysql服务器的性能简略介绍Prometheus和Grafana 两个零碎。 零碎指标剖析小型零碎： 小型并发零碎不须要思考其余条件，因为那种零碎可能每隔几分钟才会有一波申请发到数据库下来，而且数据库里一张表兴许就几百条、几千条或者几万条数据，数据量很小，并发量很小，操作频率很低，用户量很小，并发量很小，只不过可能零碎的业务逻辑很简单而已，对于这类零碎的数据库机器选型，就不在咱们的思考范畴之内了。 通常抉择: 大多数状况下个别8核16G的机器部署的MySQL数据库，每秒抗个一两千并发申请是没问题的，然而如果并发量再高一些，假如每秒有几千并发申请，那么可能数据库就会有点危险了，因为数据库的CPU、磁盘、IO、内存的负载都会很高，数据库压力过大就会宕机。 吞吐量： 如果一个零碎解决一个mysql申请须要1s，那么一分钟可能只解决100个申请，4核8G的机器部署一般的Java利用零碎，通常每秒大抵就是抗下几百的并发拜访，然而同一个配置的机器能够从每秒一两百申请到每秒七八百申请都是有可能的，要害是看你每个申请解决须要消耗多长时间。 固态硬盘 因为数据库最大的简单就在于大量的磁盘IO，他须要大量的读写磁盘文件，所以如果能应用SSD固态硬盘，那么你的数据库每秒能抗的并发申请量就会更高一些。 数据库压力测试 有了数据库之后，第一件事就是做压力测试： 什么是qps，什么是tps？ 压测数据库，每秒能扛下多少申请，每秒会有多少申请，如果要断定性能能够通过上面的指标： Qps:全称是 query per second，意味着数据库每秒能够解决多少个申请，一个申请就是一个sql语句，在mysql中意味着一秒能够解决多少个sql语句。 Tps全程是 transaction per second，Tps是用来掂量一个数据库每秒实现事务的数量，有一些人会把tps了解为数据库的每秒钟申请多数量，然而不太谨严。 每秒能够解决的事务量，这个数据用在数据库外部中用的比拟多，意味着数据库每秒会执行多少次事务提交或者回滚。 Io的性能指标 关注的io相干性能指标，大家也要跟他做一个理解： (1) IOPS：这个指的是机器的随机IO并发解决的能力，比方机器能够达到200 IOPS，意思就是说每秒能够执行200个随机 IO读写申请。 (2) 吞吐量：这个指的是机器的磁盘存储每秒能够读写多少字节的数据量 (3) latency：这个指标说的是往磁盘里写入一条数据的提早。 通常状况下一个一般磁盘的程序写入都是能够达到200mb的申请上，通常而言，磁盘吞吐量都能够到200mb 通常状况下一块硬盘的读写提早越低，数据库的性能就越高，执行sql和事务的速度就会越快。压力测试的其余性能指标cpu负载：是一个重要的性能指标，假如数据库压测到了3000了，然而cpu负载曾经满了，也就意味着它最多只能 解决这么多数据了。 网络负载：压测到肯定的qps或者tps的时候，每秒钟都机器网卡都输出多少mb数据，输入多少mb数据，qps1000的时候，网络负载打满了，每秒传输100mb达到下限也是无奈压力测试的。内存负载：机器的消耗到了极限也是不能压力测试的。给你一台4核8G的机器，他能够扛住每秒几千甚至每秒几万的并发申请吗? 扛下多少申请，须要看理论的cpu，硬盘，内存，网络带宽等环境。一台机器扛下500+的申请曾经很高了，如果每秒1000+申请，根本负载会打满。机器有可能挂掉。同时此时的内存也根本打满了，同时jvm的gc频率可能会十分高。 压力测试工具介绍 应用压力测试的工具是：sysbench工具 装置教程：装置教程如下： curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash sudo yum -y install sysbenchsysbench --version 数据库压测实战上面是一个案例的指令，能够在应用的时候边运行后果比照理解： ...

1.下载mysql源安装包 $ wget http://dev.mysql.com/get/mysq... 2.装置mysql源 $ yum localinstall mysql57-community-release-el7-8.noarch.rpm  3.查看mysql源是否装置胜利 $ yum repolist enabled | grep "mysql.-community." 4.批改yum源 【可跳过】 $ vim /etc/yum.repos.d/mysql-community.repo 扭转默认装置的mysql版本。比方要装置5.6版本，将5.7源的enabled=1改成enabled=0。而后再将5.6源的enabled=0改成enabled=1即可。 备注：enabled=1示意行将要装置的mysql版本，这个文件也能够不批改，默认装置mysql最高版本 5.装置MySQL  这一步才是真正装置mysql $ yum install mysql-community-server 6.启动MySQL服务并设置开机启动 $ systemctl start mysqld $ systemctl enable mysqld $ systemctl daemon-reload 7.端口凋谢 $ firewall-cmd --zone=public --add-port=3306/tcp --permanent $ firewall-cmd --reload 8.批改root本地登录明码  1）查看mysql明码 $ grep 'temporary password' /var/log/mysqld.log 留神如果查问不到任何信息，证实明码就是空，提醒输出明码时，间接回车就好 2）连贯mysql $ mysql -uroot -p $ use mysql;    (连贯上数据库之后还得抉择应用那个数据库，这里应用mysql本人的数据库) 3）批改明码【留神：前面的分号肯定要跟上】新密码为：new password mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY 'new password'; ...

最近遇到了一个很奇怪的事，某个服务线上环境中有一张表的数据总是莫名其妙的隐没，说来也很奇怪。然而生产环境又不能做调试，于是只好通过翻各种日志来破案，这里将mysql的log_bin日志的查问过程大抵形容一下。 首先阐明一下，binlog是一个记录了mysql所有操作的二进制文件。 首先，确保曾经关上日志记录，执行sql命令：show variables like 'log_bin%';如果是ON的话，就阐明开启了日志记录，并且这个日志记录默认是File，这就是就是咱们接下来要找的文件。如果是记录为到表，那就是间接查数据库了。 第一步，找到日志文件地位个别状况下，日志文件都会在装置目录下的logs中然而配置文件能够批改日志存储门路，所以咱们间接用sql命令查找：show master status这个命令会将最新的一个日志文件地址形容进去。 第二步，找到可编译二进制文件的mysqlbinlog可执行文件在mysql目录下执行shell命令：find ./ -name mysqlbinlog如果没找到，那就间接用shell命令(应用前确保有权限)：find / -name mysqlbinlog 第三步，再mysql-bin.010001中找到关键字比方我要在mysql-bin.010001中找到delete操作，那么就能够用shell命令： ./mysqlbinlog -v ../logs/logbin/mysql-bin.010001 | grep -i delete其中 -i 示意疏忽大小写因为delete操作非常的多，我还想准确到删除某一张表，那我就能够改写命令： ./mysqlbinlog -v ../logs/logbin/mysql-bin.010001 | grep -i 'delete from tableName'我还想找到delete删除操作的前后几行，比方前三行，后十行，那么我的命令就会变成： ./mysqlbinlog -v ../logs/logbin/mysql-bin.010001 | grep -i -A 10 -B 3 'delete from tableName'还有我的查问条件中蕴含特殊字符： ./mysqlbinlog -v ../logs/logbin/mysql-bin.010001 | grep -i -A 10 -B 3 "insert into tableName (`id`"

环境筹备 192.168.32.130 --主库192.168.32.131 --从库主库my.cnf 减少以下配置log-bin=mysql-binserver-id=123从库my.cnf 减少以下配置server-id=124主库上执行SQLCREATE USER 'repl'@'192.168.32.%' IDENTIFIED BY '123456';GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.32.%';SHOW MASTER STATUS;从库上执行SQLCHANG MASTER TO MASTER_HOST='192.168.128.130', MASTER_USER='repl', MASTER_PASSWORD='123456', MASTER_LOG_FILE='mysql-bin.000002', MASTER_LOG_POS=10368;START SLAVE;SHOW SLAVE STATUS;验证主从同步性能

最近通过慢查问日志发现了一条慢SQL，相干业务表随着数据减少已达千万级，须要加索引进行优化查问。给大表加索引、加字段属于DDL（数据定义语言）操作，任何对MySQL大表的DDL操作都值得警觉，不然很可能会引起锁表，报错Waiting for meta data lock，造成业务解体。那么如何对大表进行加索引操作？ 晚期DDL原理再谈如何对加大表加索引前，先谈一下MySQL DDL操作为什么会锁表？对于这个问题，须要先理解一下MySQL5.6.7之前的晚期DDL原理。 晚期DDL操作分为copy table和inplace两种形式。 copy table 形式 创立与原表雷同的长期表，并在长期表上执行DDL语句锁原表，不容许DML（数据操作语言），容许查问将原表中数据逐行拷贝至长期表（过程没有排序）原表降级锁，禁止读写，即原表暂停服务rename操作，将长期表重命名原表inplace 形式（fast index creation，仅反对索引的创立跟删除） 创立frm（表构造定义文件）临时文件锁原表，不容许DML（数据操作语言），容许查问依据汇集索引程序构建新的索引项，依照程序插入新的索引页原表降级锁，禁止读写，即原表暂停服务rename操作，替换原表的frm文件晚期copy VS inplace 形式？inplace 形式绝对于 copy 形式来说，inplace 不会生成长期表，不会产生数据拷贝，所以缩小了I/O资源占用。 inplace 只实用于索引的创立与删除，不适用于其余类的DDL语句。 不论是晚期copy还是晚期inplace形式的DDL，都会进行锁表操作，不容许DML操作，仅容许查问。 晓得了DDL的机制，上面就理解一下“如何对大表进行加索引操作”！ 计划一：“影子策略”此办法来自《高性能MySQL》一书中的计划。 计划思路创立一张与原表（tb）构造雷同的新表（tb_new）在新表上创立索引重命名原表为其余表名（tb => tb_tmp），新表重命名为原表名（tb_new => tb），此时新表（tb）承当业务为原表（tb_tmp）新增索引替换表，新表改回最后的名称（tb => tb_new），原表改回最后的名称（tb_tmp => tb），原表（tb）从新承当业务把新表数据导入原表（即把新表承当业务期间产生的数据和到原表中）如何实际SQL实现： # 以下sql对应下面六步create table tb_new like tb;alter table tb_new add index idx_col_name (col_name);rename table tb to tb_tmp, tb_new to tb;alter table tb_tmp add index idx_col_name (col_name);rename table tb to tb_new, tb_tmp => tb;insert into tb (col_name1, col_name2) select col_name1, col_name2 from tb_new;“影子策略”有哪些问题？ ...

介绍在上一篇文章 mysql 总体概述 里咱们大略理解了 mysql 的架构设计，其中提到了存储引擎。它在 mysql 里是一个十分重要的角色，负责了数据的创立、读取和更新，也就是数据的 I/O 操作。 最重要的是，它是可插拔的模块，这意味着咱们在切换存储引擎时，对于下层利用来讲，是不须要做任何适配的。 存储引擎有很多种，而且都有属于本人的个性，像咱们常见的 InnoDB 有事务反对、MyISAM 速度较快等。 存储引擎的用法作为插件化的模块，咱们能够很天然的增加、卸载存储引擎，并且在创立表时指定存储引擎。 加载存储引擎mysql 通过曾经定义好的 API 接口与存储引擎通信，所以咱们只有实现对应的 API 接口，就能够在 mysql 运行时加载进来。 在 mysql 源码里有一个 example 的存储引擎，咱们能够看到它须要实现的 API 接口如下： 当咱们实现了这些办法后，就能够把它编译为共享库，而后应用上面的语句加载进来了 INSTALL PLUGIN example SONAME 'example.so';须要留神的是，插件文件必须位于 mysql 插件目录中，并且领有对 plugin 表的 INSERT 权限。 卸载存储引擎要卸载存储引擎，就比较简单了 UNINSTALL PLUGIN example;当卸载后，对应的表将不可拜访，所以肯定要留神是否还有该存储引擎的表在应用！ 查看并应用存储引擎当咱们加载了存储引擎后，能够应用上面的命令来查看： show engines;如果咱们想要应用对应的存储引擎时，能够应用上面的办法： 创立表时指定：CREATE TABLE t1 (id INT) ENGINE = INNODB;设置默认应用：SET default_storage_engine=INNODB;批改表时指定：ALTER TABLE t ENGINE = InnoDB;其中 ALTER TABLE 将会把旧表复制到新的表，并且在此期间都会加锁应用，要特地留神。 存储引擎的品种特点在 mysql 里实现了很多种的存储引擎，每种存储引擎都有属于它们的特色。咱们来看看 mysql 里反对的存储引擎有哪些吧。 ...

装置homebrew装置 brew install mysql官网MySQL Community Downloads https://dev.mysql.com/downloa...环境配置# 批改 ~/.zshrcvim ~/.zshrc# 切换编辑模式i # 增加mysql门路到PATHexport PATH=$PATH:/usr/local/mysql/bin# 退出vim编辑模式,保留批改ESC + :wq!# 使配置失效soucre ~/.zshrc# 别名设置 mysql启动、敞开、重启alias mysqlstart='sudo /usr/local/mysql/support-files/mysql.server start'alias mysqlstop='sudo /usr/local/mysql/support-files/mysql.server stop'alias mysqlrestart='sudo /usr/local/mysql/support-files/mysql.server restart'批改字符集查看字符集、字序集# 命令行登录mysqlmysql -uroot -p# 查看mysql编码show variables like '%char%';在 MacOS 里，mysql 一开始就没有 my.cnf 文件，在iterm里，输出： mysql --help | grep cnf# 失去order of preference, my.cnf, $MYSQL_TCP_PORT,/etc/my.cnf /etc/mysql/my.cnf /usr/local/mysql/etc/my.cnf ~/.my.cnf# 新建my.cnfcd /etcvim my.cnf# 新增如下配置[client]port = 3306default-character-set = utf8[mysqld]port = 3306character-set-server = utf8collation-server = utf8_unicode_ciinit_connect = 'SET NAMES utf8'default-storage-engine = INNODB[mysql]default-character-set = utf8# 查看mysql编码show variables like '%char%';[client] 代表客户端默认设置内容[mysql] 代表咱们应用mysql命令登录mysql数据库时的默认设置[mysqld] 代表数据库本身的默认设置 ...

学习《MySQL高级》锁和事务，并参考其余优良相干文章整顿的笔记表锁读锁会阻塞写，然而不会梗塞读；写锁会把读锁和写锁都阻塞。 详解：会话s1给表A加读锁，s1、s2……都不可写表A，可读表A；会话s1给表A加写锁，s1可对表A增删改查，s2、s3等未拿到锁的会话，既不能查也不能写；会话s1不论是表A加读锁还是写锁，须要等表A的锁开释后能力操作其余没有加锁的表（能够给多个表加锁，同时操作多个表）。 PS：读锁，又叫共享锁（S锁）；写锁，又叫排他锁（X锁）。 行锁行锁反对事务 事务什么是事务？事务是数据库操作的最小工作单元，组合一组操作一起提交，要么执行都胜利（commit），要么执行都不胜利（rollback）。 事务的个性（ACID）Atomicity：原子性Consistency：一致性Isolation：隔离性Durability：持久性原子性 事务被视为不可分割的最小单元，事务的所有操作要么全副胜利，要么全副失败回滚。 一致性 数据库在事务执行前后都放弃一致性状态，在一致性状态下，所有事务对一个数据的读取后果都是雷同的。 隔离性 一个事务所做的批改在最终提交以前，对其余事务是不可见的。 持久性 一旦事务提交，则其所做的批改将会永远保留到数据库中。即便零碎产生解体，事务执行的后果也不能丢。 并发事务处理带来了哪些问题更新失落 (Lost Update)脏读 (Dirty Reads)不可反复读 (Not-Repeatable Reads)幻读 (Phantom Reads)更新失落 当两个或多个事务抉择同一行，而后基于最后选定的值更新该行时，因为每个事务都不晓得其余事务的存在，就会产生失落更新问题。最初的更新笼罩了由其余事务所做的更新。 脏读 一句话：事务A读取到了事务B已批改但尚未提交的数据，还在这个数据根底上做了操作。此时，如果B事务回滚，A读取的数据有效，不合乎一致性要求。 不可反复读 一个事务在读取某些数据后的某个工夫，再次读取以前读过的数据，却发现其读出的数据曾经产生了扭转、或某些记录曾经被删除了！这种景象就叫做“不可反复读”。 一句话：事务A读取到了事务B已批改且已提交的数据，不合乎隔离性 幻读 一个事务按雷同的查问条件从新读取以前检索过的数据，却发现其余事务插入了满足其查问条件的新数据，这种景象就称为“幻读”。 一句话：事务A读取到了事务B新增且已提交的数据，不合乎隔离性。 PS: 认真了解加黑的中央，脏读、不可反复读、幻读的区别高深莫测。 事务的隔离级别读未提交（READ UNCOMMITTED） 事务中的批改，即便没有提交，对其余事务也是可见的。 读已提交（READ COMMITTED） 一个事务只能读取曾经提交的事务所做的批改。换句话说，一个事务所做的批改在提交之前对其余事务是不可见的。 可反复读（REPEATABLE READ）（默认级别） 保障在同一个事务中屡次读取同样数据的后果是一样的。 可串行化（SERIALIZABLE） 强制事务串行执行。 每种隔离级别以及会呈现的问题汇总表 隔离级别脏读不可反复读幻影读未提交读√√√提交读×√√可反复读××√可串行化×××查看以后数据库的事务隔离级别： show variables like 'tx_isolation';《MySQL实战45讲》03 | 事务隔离：为什么你改了我还看不见？一文解析的更加清晰明了 行锁降级表锁如果A事务依据条件 a = 1 更新时，索引生效，事务未提交前；B事务依据条件 a = 10 更新时，会被阻塞。由此可见，插入时索引生效导致行锁降级为表锁。 总结：没有索引或者索引生效更新数据时，InnoDB 的行锁降级为表锁。 间隙锁（Gap Lock）什么是间隙锁？当咱们用范畴条件而不是相等条件检索数据，并申请共享或排他锁时，InnoDB 会给符合条件的已有数据记录的索引项加锁；对于键值在条件范畴内但并不存在的记录，叫做“间隙(GAP)”。 InnoDB 也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁(Gap Lock) 。 ...

学习《MySQL高级》高阳老师解说索引课程的笔记，本篇偏重对 order by 排序剖析建表# 建表CREATE TABLE tblA(#id int primary key not null autp_increment,age int,birth timestamp not null);insert into tblA(age,birth) values(22,now());insert into tblA(age,birth) values(23,now());insert into tblA(age,birth) values(24,now());# 建设复合索引CREATE INDEX idx_A_ageBirth on tblA(age,birth);select * from tblA;Order By 优化（索引剖析）因为本表中只有两个字段 age, birth，复合索引都笼罩了，所以 select * 就相当于 select age, birth, 查问间接走索引，不须要回表。此处仅关注排序（order by）是否会呈现文件排序（filesort）。 1.1 explain select * from tblA where age > 20 order by age;+----+-------------+-------+------------+-------+----------------+----------------+---------+------+------+----------+--------------------------+| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |+----+-------------+-------+------------+-------+----------------+----------------+---------+------+------+----------+--------------------------+| 1 | SIMPLE | tblA | NULL | index | idx_A_ageBirth | idx_A_ageBirth | 9 | NULL | 3 | 100.00 | Using where; Using index |+----+-------------+-------+------------+-------+----------------+----------------+---------+------+------+----------+--------------------------+排序用到了 age 字段的索引，不会呈现filesort。 ...

学习《MySQL高级》高阳老师解说索引课程的笔记，本篇偏重对where索引的剖析建表运行环境：MySQL 5.7.32 # 建表CREATE TABLE test03(id int primary key not null auto_increment,c1 char(10),c2 char(10),c3 char(10),c4 char(10),c5 char(10));insert into test03(c1,c2,c3,c4,c5) values('a1','a2','a3','a4','a5');insert into test03(c1,c2,c3,c4,c5) values('b1','b2','b3','b4','b5');insert into test03(c1,c2,c3,c4,c5) values('c1','c2','c3','c4','c5');insert into test03(c1,c2,c3,c4,c5) values('d1','d2','d3','d4','d5');insert into test03(c1,c2,c3,c4,c5) values('e1','e2','e3','e4','e5');select * from test03;# 建设 c1, c2, c3, c4 复合索引create index idx_test03_c1234 on test03(c1, c2, c3, c4);show index from test03;索引剖析explain 跑在 MySQL 5.7.32 上 explain select * from test03 where c1 = 'a1';explain select * from test03 where c1 = 'a1' and c2 = 'a2';explain select * from test03 where c1 = 'a1' and c2 = 'a2' and c3 = 'a3';explain select * from test03 where c1 = 'a1' and c2 = 'a2' and c3 = 'a3' and c4 = 'a4';1. explain select * from test03 where c1 = 'a1' and c2 = 'a2' and c3 = 'a3' and c4 = 'a4';+----+-------------+--------+------------+------+------------------+------------------+---------+-------------------------+------+----------+-------+| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |+----+-------------+--------+------------+------+------------------+------------------+---------+-------------------------+------+----------+-------+| 1 | SIMPLE | test03 | NULL | ref | idx_test03_c1234 | idx_test03_c1234 | 164 | const,const,const,const | 1 | 100.00 | NULL |+----+-------------+--------+------------+------+------------------+------------------+---------+-------------------------+------+----------+-------+全值匹配，查问用到了全副4个字段的索引（通过 key 字段判断应用了复合索引，type 类型为 ref，通过 ref 字段判断应用4个索引） ...

示例慢 SQLSELECT * FROM task_engine_base_data WHERE outer_task_id = 1001871场景上下文数据表构造现状为缩小浏览烦扰，已去除与本案例无关的字段及索引定义CREATE TABLE `task_engine_base_data` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID', `task_type_id` int(11) NOT NULL DEFAULT '0' COMMENT '工作类型ID', `outer_task_id` varchar(64) NOT NULL DEFAULT '' COMMENT '内部工作ID', PRIMARY KEY (`id`), KEY `idx_outer_id_type_id` (`outer_task_id`,`task_type_id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='子工作规定表';起因剖析慢SQL的EXPLAIN 表中存在索引 idx_outer_id_type_id(outer_task_id,task_type_id)。 字段定义 outer_task_id varchar(64) NOT NULL DEFAULT ''。 字段类型为字符串，但查问条件的值为整型，导致 MySQL 隐式转换。 列值会被转换成浮点数类型，即 CAST(col_name AS DOUBLE) = XXX，对列值进行了计算，无奈应用索引。 解决方案程序中强制转换值的类型，与数据库字段类型放弃完全一致，防止隐式转换。 SELECT * FROM task_engine_base_data WHERE outer_task_id = '1001871'或者应用 CAST 转换查问值： ...

失常环境1.环境介绍测试数据库1：192.168.1.21测试数据库2：192.168.1.20虚构IP1（写库）：192.168.1.111虚构IP2（读库）：192.168.1.112 2.查看主从状态show slave status 3.查看VIPip a#VIP1 192.168.1.212: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:9e:e7:26:5c brd ff:ff:ff:ff:ff:ff inet 192.168.1.21/24 brd 192.168.1.255 scope global eth0 valid_lft forever preferred_lft forever inet 192.168.1.111/32 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::5054:9eff:fee7:265c/64 scope link valid_lft forever preferred_lft forever#VIP2 192.168.1.202: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:9e:17:53:e5 brd ff:ff:ff:ff:ff:ff inet 192.168.1.20/24 brd 192.168.1.255 scope global eth0 valid_lft forever preferred_lft forever inet 192.168.1.112/32 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::5054:9eff:fe17:53e5/64 scope link valid_lft forever preferred_lft forever4.查看Keepalived日志tail -f /var/log/messages#192.168.1.21Aug 24 16:36:14 i-6gxo6kx7 Keepalived_vrrp[4207]: VRRP_Instance(VI_1) Transition to MASTER STATEAug 24 16:36:15 i-6gxo6kx7 Keepalived_vrrp[4207]: VRRP_Instance(VI_1) Entering MASTER STATE#192.168.1.20Aug 24 16:11:55 i-7jaope92 Keepalived_vrrp[1502]: VRRP_Instance(VI_2) Transition to MASTER STATEAug 24 16:11:56 i-7jaope92 Keepalived_vrrp[1502]: VRRP_Instance(VI_2) Entering MASTER STATE可用性测试1.读库宕机测试(192.168.1.20)1.敞开从库Mysql ...