InnoDB

以 Compact 行格式为例： 总结 删除一条记录， 数据原有的被废弃 ， 记录头发生变化 ，主要是 打上了删除标记 。也就是原有的数据 deleted_flag 变成 1 ，代表数据被删除。但是数据没有被清空，在新一行数据大小小于这一行的时候， 可能会占用这一行 。这样其实就是 存储碎片 ，要想减少存储碎片，可以通过重建表来实现（例如对于高并发大数据量表，除了归档，还可以通过利用无锁算法 Alter 修改字段来重建表增加表性能）。 Compact 行格式存储 我们来创建一个包含几乎所有基本数据类型的表，其他的例如 geometry，timestamp 等等，也是基于 double 还有 bigint 而来的， text、json、blob等类型，一般不与行数据一起存储，我们之后再说： create table record_test_1 ( id bigint, score double, name char(4), content varchar(8), extra varchar(16) )row_format=compact; 插入如下几条记录： INSERT INTO `record_test_1`(`id`, `score`, `name`, `content`, `extra`) VALUES (1, 78.5, 'hash', 'wodetian',

字数：3620，阅读耗时：4分35秒 最近群里一位兄弟在面试中被问到： 「MySQL的架构体系是什么」 。 虽然他搞java开发好几年了，也一直使用的是MySQL数据库，但是面对这个问题依然是一脸懵逼，还以为面试官要问索引、慢查询、性能优化之类的（因为这些都是网上找点面试题背过了）。 但这位面试官不按套路出牌，这位兄弟当场就是脸红耳赤的，心想nnd居然会这么问。其实面试中面试官的问题有千千万，有的问题确实背背面试题就能应对，但不是所有的面试题咱们都能背下来的。 今天我们就来聊聊MySQL的架构体系，尽管咱们是java开发人员，但是在日常开发过程中也会经常和MySQL数据库打交道。如果公司有DBA能干点事还稍微好点，如果是没有DBA或者DBA没什么卵用的情况下，我们还是很有必要了解MySQL的整个体系的，况且在面试中遇到了也是一个加分项。 想要知道一条SQL是怎么查询的，只要对MySQL整个体系搞清楚了，才能说出个123。 所以于情于理，我们很有必要学习一下MySQL的架构体系的。 平时，和小伙伴们聊天的时候，经常会把MySQL当做我们开发的一个软件系统，既然是软件系统，那么就有个架构图，以及架构是如何分层的，每一层的功能是什么。 下面我们就来看看MySQL的整体架构图。 MySQL架构图 再来看看我们开发的系统架构图： 其实还是蛮相似的。都有分层的概念

一、引子 经常会有同学来问我，我的数据库占用空间太大，我把一个最大的表删掉了一半的数据，怎么表文件的大小还是没变？ 那么今天，我就和你聊聊数据库表的空间回收，看看如何解决这个问题。 这里，我们还是针对 MySQL 中应用最广泛的 InnoDB 引擎展开讨论。一个 InnoDB 表包含两部分，即：表结构定义和数据。在 MySQL 8.0 版本以前，表结构是存在以.frm 为后 缀的文件里。而 MySQL 8.0 版本，则已经允许把表结构定义放在系统数据表中了。因为表结构定义占用的空间很小，所以我们今天主要讨论的是表数据。 接下来，我会先和你说明为什么简单地删除表数据达不到表空间回收的效果，然后再和你介绍正确回收空间的方法。 二、参数 innodb_file_per_table 表数据既可以存在共享表空间里，也可以是单独的文件。这个行为是由参数innodb_file_per_table 控制的： 1. 这个参数设置为 OFF 表示的是，表的数据放在系统共享表空间，也就是跟数据字典放在一起； 2. 这个参数设置为 ON 表示的是，每个 InnoDB 表数据存储在一个以 .ibd 为后缀的文件中。 从 MySQL 5.6.6 版本开始，它的默认值就是 ON 了。 我建议你不论使用 MySQL 的哪个版本，都将这个值设置为 ON。因为，一个表单独存储为一个文件更容易管理

资源组介绍 简介 MySQL是单进程多线程的程序，MySQL线程包括后台线程（Master Thread、IO Thread、Purge Thread等），以及用户线程。在8.0之前，所有线程的优先级都是一样的，并且所有的线程的资源都是共享的。但是在MySQL8.0之后，由于Resource Group特性的引入，我们可以来通过资源组的方式修改线程的 优先级 以及所能使用的 资源 ，可以指定不同的线程使用特定的资源。 在目前版本中DBA只能操控CPU资源，并且控制的最小力度为vCPU，即操作系统逻辑CPU核数（可以通过 lscpu 命令查看可控制CPU总数）。 DBA经常会遇到需要执行跑批任务的需求，这种跑批的SQL一般都是很复杂、运行时间长、消耗资源多的SQL。所以很多跑批任务都是在业务低峰期的时候执行，并且在从库上执行，尽可能降低对业务产生影响。但是对于一些数据一致性比较高的跑批任务，需要在主库上执行，在跑批任务运行的过程中很容易影响到其他线程的运行。那么现在Resource Group就是DBA的福音了，我们可以对跑批任务指定运行的资源组，限制任务使用的资源，减少对其他线程的影响。 资源组信息查看 INFORMATION_SCHEMA.RESOURCE_GROUPS INFORMATION_SCHEMA库下的RESOURCE_GROUPS表中记录了所有定义的资源组的情况: 1

摘要： 大家提到Mysql的性能优化都是注重于优化sql以及索引来提升查询性能，大多数产品或者网站面临的更多的高并发数据读取问题。然而在大量写入数据场景该如何优化呢？ 今天这里主要给大家介绍，在有大量写入的场景，进行优化的方案。 总的来说MYSQL数据库写入性能主要受限于数据库自身的配置，以及操作系统的性能，磁盘IO的性能。主要的优化手段包括以下几点： 1、调整数据库参数 （1） innodb_flush_log_at_trx_commit 默认为1，这是数据库的事务提交设置参数，可选值如下： 0: 日志缓冲每秒一次地被写到日志文件，并且对日志文件做到磁盘操作的刷新，但是在一个事务提交不做任何操作。 1：在每个事务提交时，日志缓冲被写到日志文件，对日志文件做到磁盘操作的刷新。 2：在每个提交，日志缓冲被写到文件，但不对日志文件做到磁盘操作的刷新。对日志文件每秒刷新一次。 有人会说如果改为不是1的值会不会不安全呢？ 安全性比较如下： 在 mysql 的手册中，为了确保事务的持久性和一致性，都是建议将这个参数设置为 1 。出厂默认值是 1，也是最安全的设置。 当innodb_flush_log_at_trx_commit和sync_binlog 都为 1 时是最安全的，在mysqld 服务崩溃或者服务器主机crash的情况下，binary log 只有可能丢失最多一个语句 或者一个事务

问题参考自： https://www.zhihu.com/question/438078173，以下解答思路为个人原创 首先提出假设： 手机号码不会更新，只会插入和删除。 查询包括精确查询某个手机号是否存在，以及获取某一号码段的所有手机号 假设表只有一个字段，就是手机号 phone，并且 设置为主键 。如果不设置主键并且没有唯一索引，InnoDB 会给我们自动生成一个隐藏主键列，浪费空间。 MyISAM or InnoDB 如果插入和删除并不频繁，手机号是提前载入的字典表，而不是用户主动注册而产生的，则 MyISAM 看上去比 InnoDB 要好。因为 MyISAM 不涉及事务，更新都是表级锁。如果是用户触发的插入和删除，则需要用 InnoDB。 字段类型 考虑三种类型，BigInt，Char，Varchar 这几种类型在 InnoDB 引擎下默认行格式的存储方式为： 对于 bigint 类型，如果 不为 NULL，则占用8字节 ，首位为符号位，剩余位存储数字，数字范围是 -2^63 ~ 2^63 - 1 = -9223372036854775808 ~ 9223372036854775807。 如果为 NULL，则不占用任何存储空间 。 对于 定长字段 ，不需要存长度信息直接存储数据即可，如果不足设定的长度则补充。对于 char 类型，补充 0x20， 对应的就是空格。

建表语句： DROP TABLE IF EXISTS `stock_discover`; CREATE TABLE `stock_discover` ( `code` char ( 6 ) NOT NULL , ` index ` int ( 11 ) unsigned NOT NULL DEFAULT ' 0 ' , `name` varchar ( 20 ) NOT NULL , `exchange` varchar ( 10 ) NOT NULL DEFAULT '' , `date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP , `yesterday` double unsigned NOT NULL , PRIMARY KEY (`code`,` index `) ) ENGINE = InnoDB DEFAULT CHARSET = utf8 ROW_FORMAT = DYNAMIC; 单个添加更新 如果记录在表中不存在则进行插入，如果存在则进行更新： sql = " INSERT INTO stock_discover VALUES ('%s', 2, '%s', 'HZ', '%s', '%s') " \ " ON DUPLICATE KEY UPDATE

利用 Forcing InnoDB Recovery 特性解决 MySQL 重启失败的问题 参考文章： （1）利用 Forcing InnoDB Recovery 特性解决 MySQL 重启失败的问题 （2）https://www.cnblogs.com/glon/p/6728380.html 备忘一下。 来源： oschina 链接： https://my.oschina.net/u/3797416/blog/4880901

MySQL InnoDB支持三种行锁定 行锁（Record Lock）:锁直接加在索引记录上面，锁住的是key。 间隙锁（Gap Lock）:锁定索引记录间隙，确保索引记录的间隙不变。间隙锁是针对事务隔离级别为可重复读或以上级别而设计的。 后码锁（Next-Key Lock）：行锁和间隙锁组合起来就叫Next-Key Lock。 默认情况下，InnoDB工作在可重复读隔离级别下，并且会以Next-Key Lock的方式对数据行进行加锁，这样可以有效防止幻读的发生。Next-Key Lock是行锁和间隙锁的组合，当InnoDB扫描索引记录的时候，会首先对索引记录加上行锁（Record Lock），再对索引记录两边的间隙加上间隙锁（Gap Lock）。加上间隙锁之后，其他事务就不能在这个间隙修改或者插入记录。 行锁(Record Lock) 当需要对表中的某条数据进行写操作（insert、update、delete、select for update）时，需要先获取记录的排他锁（X锁），这个就称为行锁。 create table x(`id` int, `num` int, index `idx_id` (`id`)); insert into x values(1, 1), (2, 2); -- 事务A START TRANSACTION; update x set id = 1

锁是计算机协调多个进程或线程并发访问某一资源的机制。 在数据库中，除传统的 计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。 如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一 个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。 从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。 本章我们着重讨论MySQL锁机制 的特点，常见的锁问题，以及解决MySQL锁问题的一些方法或建议。 Mysql用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。 这些锁统称为悲观锁(Pessimistic Lock)。 MySQL锁概述 相对其他数据库而言，MySQL的锁机制比较简单，其最 显著的特点是不同的存储引擎支持不同的锁机制。 比如，MyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）； BDB存储引擎采用的是页面锁（page-level locking），但也支持表级锁； InnoDB存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。 表级锁 ： 开销小，加锁快； 不会出现死锁； 锁定粒度大，发生锁冲突的概率最高，并发度最低。 行级锁 ： 开销大，加锁慢； 会出现死锁； 锁定粒度最小，发生锁冲突的概率最低，并发度也最高。