分享既学习

事务的起源可以追溯到 6000 年以前，当时苏美尔人（Sumerians）就发明了事务处理和记录方法。已知最早的记录是写在土块上的，上面记录的是皇家的税收、土地、谷物、牲畜、奴隶和黄金，明确地记下了每笔交易。这种早期的系统已经具备了事务处理的关键特征。记录使用的土块和记号方式就是数据库，每次土块的加入都会造成数据状态的变化，在今天可以称为事务。PS：事务是数据库关系系统中的一系列操作的一个逻辑单位。这种基于土块的事务处理系统的技术演变了数千年，经历了纸莎草纸、羊皮纸、最后到我们现在用的纸。

performance_schema 是 MySQL 提供的一个较为底层的监控，它可以监控数据库中每个线程的所有动作，这些动作被称为事件，可以是一个函数调用，也可以是一条 SQL 执行过程。总体来讲 performance_schema 是一个相对专业的模块。

今天遇到了一个有意思的问题，线上数据库 CPU 出现了偶发的抖动。定位到原因是一条查询语句偶发变慢造成的，随后通过调整表中的索引解决。优化器通过某种机制检测到 index_merge 能带来性能提升，某些情况下不会带来提升，反而会耗费更长的时间，属于优化器的缺陷，可以通过调整表中的索引来解决。

由于误操作、代码 bug 或平台误点，我们在操作数据时难免会遇到数据丢失的情况，比如一条 delete 删除了预期之外的数据。早期想要恢复数据，只能通过 全量备份 + 日志备份 恢复数据或业务人员通过日志以及业务逻辑进行手动订正，这些恢复数据的方法影响其恢复速度的变量很多，全量备份如果数据量很大，上传和解压缩的耗时很久，还要考虑增量日志应用。手动订正数据量大业务逻辑复杂的话，是一件非常消耗人力的事情，且容易出错。直到出现 Binlog 闪回技术，大大的提升了 DML 造成数据丢失的恢复速度。

慢 SQL 是指 MySQL 中执行时间超过指定阈值的语句将被记录到 Slow log 文件中的查询。慢 SQL 的风险是可能随时都会因为某种原因而被触发，并且根据 DBA 的工作经验，数据库最常出现的问题，都是因为慢查询导致数据库慢了，进而导致整个实例雪崩，从而导致了线上故障。因此需要定期治理优化，避免数据库内慢 SQL 很多。云上数据库，都会提供慢 SQL 的分析功能，使用起来也非常便捷，本篇文章主要讨论自建 MySQL 慢 SQL 如何分析。

MySQL 是单进程多线程的程序，在 8.0 之前所有的线程优先级都是相同的，并且所有的线程资源都是共享的。8.0 之后推出 RESOURCE GROUP 特性 DBA 可以通过资源组的方式修改线程优先级以及所使用的资源，目前仅支持 CPU 资源。查询现有的资源组，系统默认的资源组，无法进行修改或者删除。可以通过下方 SQL 查询资源组的使用情况，被哪些线程使用。我们模拟要跑一个 UPDATE 批次任务，现在创建一个资源组。VCPU = 0将线程与资源组绑定，设置的权重为 10。

MySQL 8.0.12 版本支持 “快速加列” 功能，既添加字段时可以支持 “INSTANT” 快速完成。通过只修改数据字典的方法来实现大表快速加列，避免之前加列操作必须做的数据拷贝，从而大幅缩小大表加列所需的时间，减少对系统的影响。最开始的快速加列只能将列加在表中的末尾，随着该特性的不断完善，在 MySQL 8.0.29 中增加了在表的任何位置添加（或删除）列功能。MySQL 版本 8.0.12 及以上腾讯云内核版本 MySQL 5.7 20190830 及以上。

Sysbench 是一个开源的多线程基准测试工具，也是目前使用最多的 MySQL 压力测试工具。

MySQL 的锁可以分为四类：MDL 锁、表锁、行锁、GAP 锁，其中除了 MDL 锁是在 Server 层加的之外，其它三种都是在 InnoDB 层加的。下面主要介绍一下：MDL 元数据锁，主要作用就是维护 DDL 过程中数据的安全性 & 正确性。当对一个表进行 DML 时，需要加 MDL 读锁，当需要对一张表结构进行变更时，需要加 MDL 写锁。读锁之间不互斥，即可以多个线程对一张表进行并发增删改。读写锁与写锁，之间是互斥的，用来保证变更表结构操作的安全性。

最近遇到研发提问，为何使用 Delete 删除一张 30G 大表中 50% 的记录，为何空间使用率没有降下来，反而还更大了呢？使用率更大的原因是 Binlog 未来及触发上传归档，至于空间为何没下降，导致该现象原因就是空间碎片。

通过上方代码，模拟了用户登陆错误，执行 SQL 错误，均未触发该异常，随后在官方文档中 host_cache Table 介绍中，提到了一个 SUM_CONNECT_ERRORS 字段。上面介绍的是临时解决方法，实际遇到此类异常时，建议先查 host_cache 表，找到发起 MySQL 协议握手失败的程序，定位问题的根源，才能彻底解决问题。从文档描述中，了解到这里的错误指的是协议握手错误。首先，需要介绍一下 host_cache 表，它记录了 MySQL 服务器缓存的连接信息，常用于排查连接错误的问题。

在线核心业务都会有日志表，随着业务持续运行，日志表每天都在增大，最后超过阈值触发空间使用率告警。DBA 处理空间告警时，会先导出一份表大小信息，然后发给研发确认，哪些表是可以清理些数据的，让研发先清理。如果没有清理空间就需要提审批扩容。如果有数据可以清理，又分为 删库、清空表、删除表中部分数据 三种情况。前两种可以直接使用 MySQL 命令处理，第三种通常需要研发写一个任务批量删除，

有一个典型的使用场景，就是 RDS 下云大多数都是通过 DTS 进行数据传输的，用户是不会同步到自建数据库的。需要运维人员在自建数据库重新创建用户，如果用户数量很多的话，那么手动创建并不现实。那么就是 pt-show-grants 发挥作用的时候了。

最近有研发同学问我：有一个问题，想查一个 ID 为 xxxx 的 sku 什么时候被更新了吗？更新前的数据是什么？一般这么讲，可能是由于手动执行或者是代码 Bug 导致出现数据丢失或者数据误更新，需要确认订正，一般需要通过分析 Binlog 来解决，本篇文章将通过该案例介绍此类问题的处理思路。本篇文章介绍了如何从 Binlog 中定位记录，需要有一点 Python 基础，但注册 Binlog 思路可应用多个场景，例如使用它恢复增量日志等。

MySQL 8.0 官方推出过一个高可用方案 ReplicaSet 主要由 Router、MySQL Shell、MySQL Server 三个组件组成。MySQL Shell 负责管理 ReplicaSet 包括部署、切换、节点加入等，都可以通过内置 AdminAPI 自动化完成。MySQL Router 是一款轻量级中间件，可在应用程序和 ReplicaSet 之间提供透明路由和读写分离功能。8.0 时期的 Router 读写需要配置两个端口，应用如果想要使用读写分离的特性，需要额外适配。

升级到 MySQL 8.0 后，可能会遇到如下报错，常发生在连接 MySQL 或配置复制关系的时候。网络上通常建议的解决方案是将 default_authentication_plugin 修改为 mysql_native_password 来解决。虽然可以规避报错，但是在 MySQL 8.1 版本 mysql_native_password 旧插件将被废弃，到时还是要直面 caching_sha2_password 插件。本篇文章将详细解读新的认证插件。

MySQL 中，当 SQL 索引字段使用了函数的话，会出现隐式转换的问题，导致索引失效，从而导致 SQL 执行效率变慢。本篇文章介绍 MySQL 不同版本此类问题的应对策略。

本篇文章介绍一些 MySQL 中常用的监控指标，常见的监控工具都是采集 MySQL 中的状态变量（status variables）理解这些状态变量，可以更好的帮助我们理解 MySQL 监控的含义及配置有效完备的监控，从而游刃有余的定位数据库的性能问题。

研发自己搭建了一套 MySQL 没有设置双一参数，机房异常断电，导致数据页出现损坏，本篇文章介绍处理思路。

Generated Invisible Primary Keys 简称 GIPK，是 2022 年 7 月 16 日 MySQL 发布 8.0.30 版本中的新特性，仅适用于 Innodb 引擎。

数据库备份恢复是 DBA 的 “保命” 技能，生产业务不仅要保证有合适的备份策略，也要定期验证备份的有效性和恢复演练流程，因为数据恢复和验证可能会涉及多方合作，演练可以让灾难真正发生时，多方配合有条不紊的将数据恢复，从而尽可能的减少 RTO 让业务快速恢复。Xtrabackup 是 MySQL 社区唯一一款开源物理热备工具，本篇文章将详细介绍 DBA 如何使用它，以及备份恢复的详细步骤。

上一篇文章中，我们介绍了使用 Clone 插件进行备份，相关的恢复流程将在本篇文章介绍。MySQL 8.0 Clone Plugin 详解恢复增量数据的方法，使用的是伪装为 relay log 通过多线程复制加速恢复的方式，之前有写过一个案例。MySQL 通过 MTS 多线程恢复增量日志备份。

克隆插件（Clone Plugin）是 MySQL 8.0.17 引入的一个重大特性，可以从本地或者远程克隆数据。如果在 8.0.17 之前想要给 MySQL 复制拓扑中添加一个新节点，只支持 Binlog 一种恢复方式，如果新节点所需要的 Binlog 在集群中不存在，就只能先借助备份工具进行全量备份恢复，再配置增量同步。这种方式虽然能达到添加新节点的目的，但总归是需要借助外部工具，相对来说是有一定的使用门槛和工作量。

systemd 是 Linux 系统推出的初始化（init）系统，MySQL 使用 RPM 或者 Debian 包安装 MySQL 会默认使用 systemd 来管理 MySQL 服务，不需要额外配置，但是二进制安装还需要运维人员手动配置。

通过调整该参数，可以提升二级索引的创建速度。创建二级索引时，在排序和构建阶段，使用线程的个数，一定程度上可以加快索引的创建速度，默认为 4 个。

MySQL Innodb ReplicaSet 是 MySQL 团队在 2020 年推出的一款产品，用来帮助用户快速部署和管理主从复制，在数据库层仍然使用的是主从复制技术。

MySQL 只有企业版有审计插件，开源社区版没有审计插件。企业要通过等保需要开通审计，这里记录使用 MariaDB 开源审计插件，让 MySQL 社区版拥有审计功能。以上就是审计日志的配置和使用说明，值得注意的是，开通审计会增加数据库性能开销，需要关注磁盘空间使用情况。

今天遇到了一个报错，觉得挺有意思的，在此记录下。

对于保证精度的数字，MySQL 也有对应的小数类型，下图是 MySQL 中小数类型概览。浮点：小数点非固定的数，可表示数据范围较广，整数，小数都可表示。定点：小数点固定，可表示整数，小数。int（整数）本质是小数点位于末尾的 32 位定点数而已。-- 建表-- 写入f1f2100100.00单精度：使用 4 个字节存储，有效数字为 8 位，MySQL 中的 float 类型为单精度。双精度：使用 8 个字节存储，有效数字为 16 位，MySQL 中的 double 类型为双精度。

使用 lscpu 命令可以从 sysfs 和 /proc/cpuinfo 中收集 CPU 体系结构信息，并解析优化为易阅读的格式。该信息包括: CPU 的线程、核心、套接字数量和非一致内存访问(NUMA) 节点的数量，以及 CPU 缓存、共享缓存、系列、型号等信息。lscpu。

最近迁移几张表，又遇到 767 异常，迁移前只检查了 sql_mode 忽略对比了这个参数，导致几张表创建失败，其实解决方法也很简单，开启参数重新导入即可。该 ERROR 常发生在字符串类型的大字段上，本篇文章详细解读该问题。

Generated Invisible Primary Keys 简称 GIPK，是 2022 年 7 月 16 日 MySQL 发布 8.0.30 版本中的新特性，仅适用于 Innodb 引擎。

本篇文章介绍一些 MySQL 管理的实用语句及适用的场景。SQL 基于 MySQL 5.7 版本。

MySQL 的规范中，一般都会建议表要有主键，常使用自增列作为主键字段，这和 MySQL 属于聚簇索引表有关，顺序增长的主键比较合适。最近有研发咨询，为什么有张表的自增主键变的非常大？而且偶尔还出现的异常，这篇文章将介绍下此类问题。

为了取得更好的读写性能，InnoDB 会将数据缓存在内存中（InnoDB Buffer Pool）对磁盘数据的修改也会落后于内存，这时如果进程或机器崩溃，会导致内存数据丢失，为了保证数据库本身的一致性和持久性，InnoDB 维护了 REDO LOG。

MySQL 同步 MTS 多线程特性快速恢复增量日志备份

最近在搞标准化巡检平台，通过 MySQL 的元数据分析一些潜在的问题。冗余索引也是一个非常重要的巡检目，表中索引过多，会导致表空间占用较大，索引的数量与表的写入速度与索引数成线性关系(微秒级)，如果发现有冗余索引，建议立即审核删除。PS：之前见过一个客户的数据库上面竟然创建 300 多个索引！？当时的想法是 “他们在玩排列组合呢” 表写入非常慢，严重影响性能和表维护的复杂度。

本篇文章介绍如何查询 Binlog 的生成时间。云上 RDS 有日志管理，但是自建实例没有，该脚本可用于自建实例闪回定位 Binlog 文件。

帮研发解决问题时，有一些需要分析Binlog日志的场景，虽然不多，但是都比较重要。本篇文章介绍如何从二进制日志中发现问题。分析是否有大事务；分析是否有长期未提交的会话；分析事务的生成频次；分析表的变更频次；.........

mysqldump是MySQL官方提供的一款逻辑备份工具，它将生成一组可以导入数据库中以重现原始数据库中的数据和数据库对象的SQL语句。可用于备份恢复、表结构导出、备份上云。本篇文章介绍原理和用法。...