复习-JavaGuide-Database on 随记

mysql执行计划

Tue, 14 Mar 2023 22:34:52 +0000

优化 SQL 的第一步应该是读懂 SQL 的执行计划。本篇文章，我们一起来学习下 MySQL EXPLAIN 执行计划相关知识。

什么是执行计划？#

执行计划 是指一条 SQL 语句在经过 MySQL 查询优化器 的优化会后，具体的执行方式。

执行计划通常用于 SQL 性能分析、优化等场景。通过 EXPLAIN 的结果，可以了解到如数据表的查询顺序、数据查询操作的操作类型、哪些索引可以被命中、哪些索引实际会命中、每个数据表有多少行记录被查询等信息。

如何获取执行计划？#

-- 提交准备数据
SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;

-- ----------------------------
-- Table structure for dept_emp
-- ----------------------------
DROP TABLE IF EXISTS `dept_emp`;
CREATE TABLE `dept_emp` (
 `id` int(0) NOT NULL,
 `emp_no` varchar(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NULL DEFAULT NULL,
 `other1` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NULL DEFAULT NULL,
 `other2` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NULL DEFAULT NULL,
 PRIMARY KEY (`id`) USING BTREE,
 INDEX `index_emp_no`(`emp_no`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci ROW_FORMAT = Dynamic;

-- ----------------------------
-- Records of dept_emp
-- ----------------------------
INSERT INTO `dept_emp` VALUES (1, 'a1', 'o11', '012');
INSERT INTO `dept_emp` VALUES (2, 'a2', 'o21', 'o22');
INSERT INTO `dept_emp` VALUES (3, 'a3', 'o31', 'o32');
INSERT INTO `dept_emp` VALUES (4, 'a4', 'o41', 'o42');
INSERT INTO `dept_emp` VALUES (5, 'a5', 'o51', 'o52');

SET FOREIGN_KEY_CHECKS = 1;

MySQL 为我们提供了 EXPLAIN 命令，来获取执行计划的相关信息。

sql常见面试题总结01

Sun, 12 Mar 2023 17:53:18 +0000

检索数据#

select 用于从数据库中查询数据。

从 Customers 表中检索所有的 ID#

现有表 Customers 如下：

cust_id
A
B
C

编写 SQL 语句，从 Customers 表中检索所有的 cust_id。

答案：

select cust_id
from Customers;

检索并列出已订购产品的清单#

表 OrderItems 含有非空的列 prod_id 代表商品 id，包含了所有已订购的商品（有些已被订购多次）。

prod_id
a1
a2
a3
a4
a5
a6
a7

编写 SQL 语句，检索并列出所有已订购商品（prod_id）的去重后的清单。

答案：

select distinct prod_id
from OrderItems;

知识点：distinct 用于返回列中的唯一不同值。

检索所有列#

现在有 Customers 表（表中含有列 cust_id 代表客户 id，cust_name 代表客户姓名）

cust_id	cust_name
a1	andy
a2	ben
a3	tony
a4	tom
a5	an
a6	lee
a7	hex

需要编写 SQL 语句，检索所有列。

sql语法基础知识总结

Sun, 12 Mar 2023 17:52:48 +0000

基本概念#

数据库术语#

数据库（database） - 保存有组织的数据的容器（通常是一个文件或一组文件）。
数据表（table） - 某种特定类型数据的结构化清单。
模式（schema） - 关于数据库和表的布局及特性的信息。模式定义了数据在表中如何存储，包含存储什么样的数据，数据如何分解，各部分信息如何命名等信息。数据库和表都有模式。
列（column） - 表中的一个字段。所有表都是由一个或多个列组成的。
行（row） - 表中的一个记录。
主键（primary key） - 一列（或一组列），其值能够唯一标识表中每一行。

SQL 语法#

SQL（Structured Query Language)，标准 SQL 由 ANSI 标准委员会管理，从而称为 ANSI SQL。各个 DBMS 都有自己的实现，如 PL/SQL、Transact-SQL 等。

SQL 语法结构#

SQL 语法结构包括：

子句 - 是语句和查询的组成成分。（在某些情况下，这些都是可选的。）
表达式 - 可以产生任何标量值，或由列和行的数据库表
谓词 - 给需要评估的 SQL 三值逻辑（3VL）（true/false/unknown）或布尔真值指定条件，并限制语句和查询的效果，或改变程序流程。
查询 - 基于特定条件检索数据。这是 SQL 的一个重要组成部分。
语句 - 可以持久地影响纲要和数据，也可以控制数据库事务、程序流程、连接、会话或诊断。

SQL 语法要点#

SQL 语句不区分大小写，但是数据库表名、列名和值是否区分，依赖于具体的 DBMS 以及配置。例如：SELECT 与 select 、Select 是相同的。
多条 SQL 语句必须以分号（;）分隔。
处理 SQL 语句时，所有空格都被忽略。

SQL 语句可以写成一行，也可以分写为多行。

3种常用的缓存读写策略详解

Fri, 24 Feb 2023 09:31:52 +0000

看到很多小伙伴简历上写了“熟练使用缓存”，但是被我问到“缓存常用的3种读写策略”的时候却一脸懵逼。

在我看来，造成这个问题的原因是我们在学习 Redis 的时候，可能只是简单了写一些 Demo，并没有去关注缓存的读写策略，或者说压根不知道这回事。

但是，搞懂3种常见的缓存读写策略对于实际工作中使用缓存以及面试中被问到缓存都是非常有帮助的！

下面介绍到的三种模式各有优劣，不存在最佳模式，根据具体的业务场景选择适合自己的缓存读写模式。

Cache Aside Pattern（旁路缓存模式）#

Cache Aside Pattern 是我们平时使用比较多的一个缓存读写模式，比较适合读请求比较多的场景。

Cache Aside Pattern 中服务端需要同时维系 db 和 cache，并且是以 db 的结果为准。

下面我们来看一下这个策略模式下的缓存读写步骤。

写：

先更新 db
然后直接删除 cache 。

简单画了一张图帮助大家理解写的步骤。

读 :

从 cache 中读取数据，读取到就直接返回
cache 中读取不到的话，就从 db 中读取数据返回
再把数据放到 cache 中。

简单画了一张图帮助大家理解读的步骤。

你仅仅了解了上面这些内容的话是远远不够的，我们还要搞懂其中的原理。

比如说面试官很可能会追问：“在写数据的过程中，可以先删除 cache ，后更新 db 么？”

答案： 那肯定是不行的！因为这样可能会造成 数据库（db）和缓存（Cache）数据不一致的问题。

举例：请求 1 先写数据 A，请求 2 随后读数据 A 的话，就很有可能产生数据不一致性的问题。

这个过程可以简单描述为：

redis内存碎片

Fri, 24 Feb 2023 09:26:00 +0000

什么是内存碎片?#

你可以将内存碎片简单地理解为那些不可用的空闲内存。

举个例子：操作系统为你分配了 32 字节的连续内存空间，而你存储数据实际只需要使用 24 字节内存空间，那这多余出来的 8 字节内存空间如果后续没办法再被分配存储其他数据的话，就可以被称为内存碎片。

Redis 内存碎片虽然不会影响 Redis 性能，但是会增加内存消耗。

为什么会有 Redis 内存碎片?#

Redis 内存碎片产生比较常见的 2 个原因：

1、Redis 存储存储数据的时候向操作系统申请的内存空间可能会大于数据实际需要的存储空间。

以下是这段 Redis 官方的原话：

Redis 使用 zmalloc 方法(Redis 自己实现的内存分配方法)进行内存分配的时候，除了要分配 size 大小的内存之外，还会多分配 PREFIX_SIZE 大小的内存。

zmalloc 方法源码如下（源码地址：https://github.com/antirez/redis-tools/blob/master/zmalloc.c）：

void *zmalloc(size_t size) {
 // 分配指定大小的内存
 void *ptr = malloc(size+PREFIX_SIZE);
 if (!ptr) zmalloc_oom_handler(size);
#ifdef HAVE_MALLOC_SIZE
 update_zmalloc_stat_alloc(zmalloc_size(ptr));
 return ptr;
#else
 *((size_t*)ptr) = size;
 update_zmalloc_stat_alloc(size+PREFIX_SIZE);
 return (char*)ptr+PREFIX_SIZE;
#endif
}

另外，Redis 可以使用多种内存分配器来分配内存（ libc、jemalloc、tcmalloc），默认使用 jemalloc，而 jemalloc 按照一系列固定的大小（8 字节、16 字节、32 字节……）来分配内存的。jemalloc 划分的内存单元如下图所示：

redis特殊数据结构

Thu, 23 Feb 2023 23:02:58 +0000

除了 5 种基本的数据结构之外，Redis 还支持 3 种特殊的数据结构：Bitmap、HyperLogLog、GEO。

Bitmap#

介绍#

Bitmap 存储的是连续的二进制数字（0 和 1），通过 Bitmap, 只需要一个 bit 位来表示某个元素对应的值或者状态，key 就是对应元素本身。我们知道 8 个 bit 可以组成一个 byte，所以 Bitmap 本身会极大的节省储存空间。

你可以将 Bitmap 看作是一个存储二进制数字（0 和 1）的数组，数组中每个元素的下标叫做 offset（偏移量）。

常用命令#

命令	介绍
SETBIT key offset value	设置指定 offset 位置的值
GETBIT key offset	获取指定 offset 位置的值
BITCOUNT key start end	获取 start 和 end 之前值为 1 的元素个数
BITOP operation destkey key1 key2 …	对一个或多个 Bitmap 进行运算，可用运算符有 AND, OR, XOR 以及 NOT

Bitmap 基本操作演示 ：

redis基本数据结构

Thu, 23 Feb 2023 14:22:58 +0000

Redis 共有 5 种基本数据结构：String（字符串）、List（列表）、Set（集合）、Hash（散列）、Zset（有序集合）。

这 5 种数据结构是直接提供给用户使用的，是数据的保存形式，其底层实现主要依赖这 8 种数据结构：简单动态字符串（SDS）、LinkedList（双向链表）、Hash Table（哈希表）、SkipList（跳跃表）、Intset（整数集合）、ZipList（压缩列表）、QuickList（快速列表）。

Redis 基本数据结构的底层数据结构实现如下：

String	List	Hash	Set	Zset
SDS	LinkedList/ZipList/QuickList	Hash Table、ZipList	ZipList、Intset	ZipList、SkipList

Redis 3.2 之前，List 底层实现是 LinkedList 或者 ZipList。 Redis 3.2 之后，引入了 LinkedList 和 ZipList 的结合 QuickList，List 的底层实现变为 QuickList。

你可以在 Redis 官网上找到 Redis 数据结构非常详细的介绍：

未来随着 Redis 新版本的发布，可能会有新的数据结构出现，通过查阅 Redis 官网对应的介绍，你总能获取到最靠谱的信息。

String（字符串）#

介绍#

String 是 Redis 中最简单同时也是最常用的一个数据结构。

String 是一种二进制安全的数据结构，可以用来存储任何类型的数据比如字符串、整数、浮点数、图片（图片的 base64 编码或者解码或者图片的路径）、序列化后的对象。

redis面试题02

Thu, 23 Feb 2023 11:16:04 +0000

Redis 事务#

如何使用 Redis 事务？#

Redis 可以通过 MULTI，EXEC，DISCARD 和 WATCH 等命令来实现事务(transaction)功能。

> MULTI
OK
> SET PROJECT "JavaGuide"
QUEUED
> GET PROJECT
QUEUED
> EXEC
1) OK
2) "JavaGuide"

MULTI 命令后可以输入多个命令，Redis 不会立即执行这些命令，而是将它们放到队列，当调用了 EXEC 命令后，再执行所有的命令。

这个过程是这样的：

开始事务（MULTI）；
命令入队(批量操作 Redis 的命令，先进先出（FIFO）的顺序执行)；
执行事务(EXEC)。

你也可以通过 DISCARD 命令取消一个事务，它会清空事务队列中保存的所有命令。

> MULTI
OK
> SET PROJECT "JavaGuide"
QUEUED
> GET PROJECT
QUEUED
> DISCARD
OK

你可以通过 WATCH 命令监听指定的 Key，当调用 EXEC 命令执行事务时，如果一个被 WATCH 命令监视的 Key 被 其他客户端/Session 修改的话，整个事务都不会被执行。

# 客户端 1
> SET PROJECT "RustGuide"
OK
> WATCH PROJECT
OK
> MULTI
OK
> SET PROJECT "JavaGuide"
QUEUED

# 客户端 2
# 在客户端 1 执行 EXEC 命令提交事务之前修改 PROJECT 的值
> SET PROJECT "GoGuide"

# 客户端 1
# 修改失败，因为 PROJECT 的值被客户端2修改了
> EXEC
(nil)
> GET PROJECT
"GoGuide"

不过，如果 WATCH 与事务在同一个 Session 里，并且被 WATCH 监视的 Key 被修改的操作发生在事务内部，这个事务是可以被执行成功的（相关 issue ： WATCH 命令碰到 MULTI 命令时的不同效果）。

redis面试题01

Wed, 22 Feb 2023 11:31:11 +0000

Redis 基础#

什么是 Redis？#

Redis 是一个基于 C 语言开发的开源数据库（BSD 许可），与传统数据库不同的是 Redis 的数据是存在内存中的（内存数据库），读写速度非常快，被广泛应用于缓存方向。并且，Redis 存储的是 KV 键值对数据。

为了满足不同的业务场景，Redis 内置了多种数据类型实现（比如 String、Hash、【List、Set、】Sorted Set、Bitmap）。并且，Redis 还支持事务、持久化、Lua 脚本、多种开箱即用的集群方案（Redis Sentinel、Redis Cluster）。

Redis 没有外部依赖，Linux 和 OS X 是 Redis 开发和测试最多的两个操作系统，官方推荐生产环境使用 Linux 部署 Redis。

个人学习的话，你可以自己本机安装 Redis 或者通过 Redis 官网提供的在线 Redis 环境来实际体验 Redis。

全世界有非常多的网站使用到了 Redis ， techstacks.io 专门维护了一个使用 Redis 的热门站点列表，感兴趣的话可以看看。

Redis 为什么这么快？#

Redis 内部做了非常多的性能优化，比较重要的主要有下面 3 点：

Redis 基于内存，内存的访问速度是磁盘的上千倍；
Redis 基于 Reactor 模式设计开发了一套高效的事件处理模型，主要是单线程事件循环和 IO 多路复用（Redis 线程模式后面会详细介绍到）；
Redis 内置了多种优化过后的数据结构实现，性能非常高。

下面这张图片总结的挺不错的，分享一下，出自 Why is Redis so fast? 。

git

Tue, 07 Feb 2023 16:14:19 +0000

版本控制#

什么是版本控制#

版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。除了项目源代码，你还可以对任何类型的文件进行版本控制。

为什么要版本控制#

有了它你就可以将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态，你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能缺陷等等。

本地版本控制系统#

许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单，但是特别容易犯错。有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件。

为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。

集中化的版本控制系统#

接下来人们又遇到一个问题，如何让在不同系统上的开发者协同工作？于是，集中化的版本控制系统（Centralized Version Control Systems，简称 CVCS）应运而生。

集中化的版本控制系统都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。

这么做虽然解决了本地版本控制系统无法让在不同系统上的开发者协同工作的诟病，但也还是存在下面的问题：

单点故障： 中央服务器宕机，则其他人无法使用；如果中心数据库磁盘损坏又没有进行备份，你将丢失所有数据。本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。
必须联网才能工作： 受网络状况、带宽影响。

分布式版本控制系统#

于是分布式版本控制系统（Distributed Version Control System，简称 DVCS）面世了。 Git 就是一个典型的分布式版本控制系统。

这类系统，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。

分布式版本控制系统可以不用联网就可以工作，因为每个人的电脑上都是完整的版本库，当你修改了某个文件后，你只需要将自己的修改推送给别人就可以了。但是，在实际使用分布式版本控制系统的时候，很少会直接进行推送修改，而是使用一台充当“中央服务器”的东西。这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。

分布式版本控制系统的优势不单是不必联网这么简单，后面我们还会看到 Git 极其强大的分支管理等功能。

认识 Git#

Git 简史#

Linux 内核项目组当时使用分布式版本控制系统 BitKeeper 来管理和维护代码。但是，后来开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了 Linux 内核社区免费使用 BitKeeper 的权力。 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds）基于使用 BitKeeper 时的经验教训，开发出自己的版本系统，而且对新的版本控制系统做了很多改进。

MySQL高性能优化规范建议总结

Fri, 20 Jan 2023 11:36:34 +0000

数据库命名规范#

所有数据库对象名称必须使用小写字母并用下划线分割
所有数据库对象名称禁止使用 MySQL 保留关键字（如果表名中包含关键字查询时，需要将其用单引号括起来）
数据库对象的命名要能做到见名识意，并且最好不要超过 32 个字符
临时库表必须以 tmp_ 为前缀并以日期为后缀，备份表必须以 bak_ 为前缀并以日期 (时间戳) 为后缀
所有存储相同数据的列名和列类型必须一致（一般作为关联列，如果查询时关联列类型不一致会自动进行数据类型隐式转换，会造成列上的索引失效，导致查询效率降低）

数据库基本设计规范#

所有表必须使用InnoDB存储引擎#

没有特殊要求（即 InnoDB 无法满足的功能如：列存储，存储空间数据等）的情况下，所有表必须使用 InnoDB 存储引擎（MySQL5.5 之前默认使用 Myisam，5.6 以后默认的为 InnoDB）。
InnoDB 支持事务，支持行级锁，更好的恢复性，高并发下性能更好

数据库和表的字符集统一使用UTF-8#

兼容性更好，统一字符集可以避免由于字符集转换产生的乱码，不同的字符集进行比较前需要进行转换会造成索引失效，如果数据库中有存储 emoji 表情的需要，字符集需要采用 utf8mb4 字符集。

参考文章：

MySQL 字符集不一致导致索引失效的一个真实案例open in new window
[MySQL 字符集详解

所有表和字段都需要添加注释#

使用 comment 从句添加表和列的备注，从一开始就进行数据字典的维护

尽量控制单表数据量的大小，建议控制在500万以内#

500 万并不是 MySQL 数据库的限制，过大会造成修改表结构，备份，恢复都会有很大的问题。
可以用历史数据归档（应用于日志数据），**分库分表（应用于业务数据）**等手段来控制数据量大小

谨慎使用MySQL分区表#

分区表在物理上表现为多个文件，在逻辑上表现为一个表；
谨慎选择分区键，跨分区查询效率可能更低；
建议采用物理分表的方式管理大数据。

经常一起使用的列放到一个表中#

避免更多的关联操作。

MySQL常见面试题总结

Fri, 20 Jan 2023 11:36:06 +0000

MySQL基础#

关系型数据库介绍#

关系型数据库，建立在关系模型的基础上的数据库。表明数据库中所存储的数据之间的联系（一对一、一对多、多对多）
关系型数据库中，我们的数据都被存放在各种表中（比如用户表），表中的每一行存放着一条数据（比如一个用户的信息）
大部分关系型数据库都使用SQL来操作数据库中的数据，并且大部分关系型数据库都支持事务的四大特性（ACID）

常见的关系型数据库
MySQL、PostgreSQL、Oracle、SQL Server、SQLite（微信本地的聊天记录的存储就是用的 SQLite） ……

MySQL介绍#

MySQL是一种关系型数据库，主要用于持久化存储我们系统中的一些数据比如用户信息
由于 MySQL 是开源免费并且比较成熟的数据库，因此，MySQL 被大量使用在各种系统中。任何人都可以在 GPL(General Public License 通用性公开许可证) 的许可下下载并根据个性化的需要对其进行修改。MySQL 的默认端口号是3306。

MySQL基础架构#

MySQL的一个简要机构图，客户端的一条SQL语句在MySQL内部如何执行
MySQL主要由几部分构成
1. 连接器：身份认证和权限相关（登录MySQL的时候）
2. 查询缓存：执行查询语句的时候，会先查询缓存（MySQL8.0版本后移除，因为这个功能不太实用）
3. 分析器：没有命中缓存的话，SQL语句就会经过分析器，分析器说白了就是要先看你的SQL语句要干嘛，再检查你的SQL语句语法是否正确
4. 优化器：按照MySQL认为最优的方案去执行
5. 执行器：执行语句，然后从存储引擎返回数据。执行语句之前会先判断是否有权限，如果没有权限，就会报错
6. 插件式存储引擎：主要负责数据的存储和读取，采用的是插件式架构，支持InnoDB、MyISAM、Memory等多种存储引擎

MySQL存储引擎#

MySQL核心在于存储引擎

MySQL支持哪些存储引擎？默认使用哪个？#

MySQL支持多种存储引擎，可以通过show engines命令来查看MySQL支持的所有存储引擎
默认存储引擎为InnoDB，并且，所有存储引擎中只有InnoDB是事务性存储引擎，也就是说只有InnoDB支持事务
这里使用MySQL 8.x MySQL 5.5.5之前，MyISAM是MySQL的默认存储引擎；5.5.5之后，InnoDB是MySQL的默认存储引擎，可以通过select version()命令查看你的MySQL版本
```
mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.27 |
+-----------+
1 row in set (0.00 sec) 
```
使用show variables like %storage_engine%命令直接查看MySQL当前默认的存储引擎

如果只想查看数据库中某个表使用的存储引擎的话，可以使用show table status from db_name where name = 'table_name'命令

MySQL中的隐式转换造成的索引失效

Thu, 19 Jan 2023 17:10:48 +0000

前言#

关于数据库优化，最常见的莫过于索引失效，数据量多的时候比较明显，处理不及时会造成雪球效应，最终导致数据库卡死甚至瘫痪。
这里说的是隐式转换造成的索引失效

数据准备#

-- 创建测试数据表
DROP TABLE IF EXISTS test1;
CREATE TABLE `test1` (
 `id` int(11) NOT NULL,
 `num1` int(11) NOT NULL DEFAULT '0',
 `num2` varchar(11) NOT NULL DEFAULT '',
 `type1` int(4) NOT NULL DEFAULT '0',
 `type2` int(4) NOT NULL DEFAULT '0',
 `str1` varchar(100) NOT NULL DEFAULT '',
 `str2` varchar(100) DEFAULT NULL,
 PRIMARY KEY (`id`),
 KEY `num1` (`num1`),
 KEY `num2` (`num2`),
 KEY `type1` (`type1`),
 KEY `str1` (`str1`),
 KEY `str2` (`str2`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
-- 创建存储过程
DROP PROCEDURE IF EXISTS pre_test1;
DELIMITER //
CREATE PROCEDURE `pre_test1`()
BEGIN
 DECLARE i INT DEFAULT 0;
 SET autocommit = 0;
 WHILE i < 10000000 DO
 SET i = i + 1;
 SET @str1 = SUBSTRING(MD5(RAND()),1,20);
 -- 每100条数据str2产生一个null值
 IF i % 100 = 0 THEN
 SET @str2 = NULL;
 ELSE
 SET @str2 = @str1;
 END IF;
 INSERT INTO test1 (`id`, `num1`, `num2`,
 `type1`, `type2`, `str1`, `str2`)
 VALUES (CONCAT('', i), CONCAT('', i),
 CONCAT('', i), i%5, i%5, @str1, @str2);
 -- 事务优化，每一万条数据提交一次事务
 IF i % 10000 = 0 THEN
 COMMIT;
 END IF;
 END WHILE;
END;
// DELIMITER ;
-- 执行存储过程
CALL pre_test1();

其中，七个字段，首先使用存储过程生成 1000 万条测试数据，测试表一共建立了 7 个字段（包括主键），num1和num2保存的是和ID一样的顺序数字，其中num2是字符串类型。 type1和type2保存的都是主键对 5 的取模，目的是模拟实际应用中常用类似 type 类型的数据，但是**type2是没有建立索引的。 str1和str2都是保存了一个 20 位长度的随机字符串，str1不能为NULL，str2允许为NULL，相应的生成测试数据的时候我也会在str2字段生产少量NULL值**（每 100 条数据产生一个NULL值）。

MySQL数据库时间类型数据存储建议

Thu, 19 Jan 2023 17:10:06 +0000

不要用字符串存储日期#

优点：简单直白
缺点
1. 字符串占有的空间更大
2. 字符串存储的日期效率比较低（逐个字符进行比较），无法用日期相关的API进行计算和比较

Datetime和Timestamp之间抉择#

Datetime 和 Timestamp 是 MySQL 提供的两种比较相似的保存时间的数据类型。他们两者究竟该如何选择呢？

通常我们都会首选 Timestamp

Datetime类型没有时区信息#

DateTime 类型是没有时区信息的（时区无关） ，DateTime 类型保存的时间都是当前会话所设置的时区对应的时间。这样就会有什么问题呢？当你的时区更换之后，比如你的服务器更换地址或者更换客户端连接时区设置的话，就会导致你从数据库中读出的时间错误。不要小看这个问题，很多系统就是因为这个问题闹出了很多笑话。
Timestamp 和时区有关。Timestamp 类型字段的值会随着服务器时区的变化而变化，自动换算成相应的时间，说简单点就是在不同时区，查询到同一个条记录此字段的值会不一样

案例

-- 建表
CREATE TABLE `time_zone_test` (
 `id` bigint(20) NOT NULL AUTO_INCREMENT,
 `date_time` datetime DEFAULT NULL,
 `time_stamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

-- 插入数据
INSERT INTO time_zone_test(date_time,time_stamp) VALUES(NOW(),NOW());
-- 查看数据
select date_time,time_stamp from time_zone_test;
-- 结果
/*
 +---------------------+---------------------+
| date_time | time_stamp |
+---------------------+---------------------+
| 2020-01-11 09:53:32 | 2020-01-11 09:53:32 |
+---------------------+---------------------+
------ 
*/

修改时区并查看数据

set time_zone='+8:00';
/*
+---------------------+---------------------+
| date_time | time_stamp |
+---------------------+---------------------+
| 2020-01-11 09:53:32 | 2020-01-11 17:53:32 |
+---------------------+---------------------+
------ 
*/

关于MySQL时区设置的一个常用sql命令

SQL语句在MySQL中的执行过程

Thu, 19 Jan 2023 10:20:57 +0000

本篇文章会分析一个SQL语句在MySQL的执行流程，包括SQL的查询在MySQL内部会怎么流转，SQL语句的更新是怎么完成的
分析之前先看看MySQL的基础架构，知道了MySQL由哪些组件组成以及这些组件的作用是什么，可以帮助我们理解和解决这些问题

MySQL基础架构分析#

MySQL基本架构概览#

下图是MySQL的简要架构图，从下图可以看到用户的SQL语句在MySQL内部是如何执行的
先简单介绍一个下图涉及的一些组件的基本作用
1. 连接器： 身份认证和权限相关（登录MySQL的时候）
2. 查询缓存：执行查询语句的时候，会先查询缓存（MySQL8.0版本后移除，因为这个功能不太实用）
3. 分析器：没有命中缓存的话，SQL语句就会经过分析器，分析器说白了就是要先看你的SQL语句干嘛，再检查你的SQL语句语法是否正确
4. 优化器：按照MySQL认为最优的方案去执行
5. 执行器：执行语句，然后从存储引擎返回数据
简单来说 MySQL 主要分为 Server 层和存储引擎层：
- Server 层：主要包括连接器、查询缓存、分析器、优化器、执行器等，所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图，函数等，还有一个通用的日志模块 binlog 日志模块。
- 存储引擎：主要负责数据的存储和读取，采用可以替换的插件式架构，支持 InnoDB、MyISAM、Memory 等多个存储引擎，其中 InnoDB 引擎有自有的日志模块 redolog 模块。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5 版本开始就被当做默认存储引擎了

Server层基本组件介绍#

连接器 连接器主要和身份认证和权限相关的功能相关，就好比一个级别很高的门卫一样

主要负责用户登录数据库，进行用户的身份认证，包括校验账户密码，权限等操作，如果用户账户密码已通过，连接器会到权限表中查询该用户的所有权限，之后在这个连接里的权限逻辑判断都是会依赖此时读取到的权限数据，也就是说，后续只要这个连接不断开，即使管理员修改了该用户的权限，该用户也是不受影响的。
查询缓存（MySQL8.0 版本后移除）
查询缓存主要用来缓存我们所执行的 SELECT 语句以及该语句的结果集。
- 连接建立后，执行查询语句的时候，会先查询缓存，MySQL 会先校验这个 SQL 是否执行过，以 Key-Value 的形式缓存在内存中，Key 是查询预计，Value 是结果集。如果缓存 key 被命中，就会直接返回给客户端，如果没有命中，就会执行后续的操作，完成后也会把结果缓存起来，方便下一次调用。当然在真正执行缓存查询的时候还是会校验用户的权限，是否有该表的查询条件。
- MySQL 查询不建议使用缓存，因为查询缓存失效在实际业务场景中可能会非常频繁，假如你对一个表更新的话，这个表上的所有的查询缓存都会被清空。对于不经常更新的数据来说，使用缓存还是可以的。所以，一般在大多数情况下我们都是不推荐去使用查询缓存的。
MySQL 8.0 版本后删除了缓存的功能，官方也是认为该功能在实际的应用场景比较少，所以干脆直接删掉了

innodb引擎对MVCC的实现

Mon, 16 Jan 2023 19:23:55 +0000

一致性非锁定读和锁定读#

一致性非锁定读#

★★非锁定★★

对于一致性非锁定读（Consistent Nonlocking Reads）的实现，通常做法是加一个版本号或者时间戳字段，在更新数据的同时版本号+1或者更新时间戳。查询时，将当前可见的版本号与对应记录的版本号进行比对，如果记录的版本小于可见版本，则表示该记录可见
InnoDB存储引擎中，多版本控制（multi versioning）即是非锁定读的实现。如果读取的行正在执行DELETE或UPDATE操作，这时读取操作不会去等待行上 锁的释放.相反地，Inn哦DB存储引擎会去读取行的一个快照数据，对于这种读取历史数据的方式，我们叫它快照读（snapshot read）。
在 Repeatable Read 和 Read Committed 两个隔离级别下，如果是执行普通的 select 语句（不包括 select ... lock in share mode ,select ... for update）则会使用 一致性非锁定读（MVCC）。并且在 Repeatable Read 下 MVCC 实现了可重复读和防止部分幻读

锁定读#

如果执行的是下列语句，就是锁定读（Locking Reads）
1. select ... lock in share
2. select ... for update
3. insert 、upate、delete
4. 锁定读下，读取的是数据的最新版本，这种读也被称为当前读current read。锁定读会对读取到的记录加锁
5. select ... lock in share mode ：对(读取到的)记录加S锁，其他事务也可以加S锁，如果加X锁则会被阻塞
6. select ... for update、insert、update、delete：对记录加X锁，且其他事务不能加任何锁
在一致性非锁定读下，即使读取的记录已被其他事务加上X锁，这时记录也是可以被读取的，即读取的快照数据。
1. 在RepeatableRead下MVCC防止了部分幻读，这边的“部分”是指在一致性非锁定读情况下，只能读取到第一次查询之前所插入的数据（根据ReadView判断数据可见性，ReadView在第一次查询时生成），但如果是当前读，每次读取的都是最新数据，这时如果两次查询中间有其他事务插入数据，就会产生幻读
2. 所以，InnoDB在实现RepeatableRead时，如果执行的是当前读，则会对读取的记录使用Next-key Lock，来防止其他事务在间隙间插入数据。
RR产生幻读的另一个场景

MySQL事务隔离级别详解

Mon, 16 Jan 2023 01:00:44 +0000

事务隔离级别总结#

SQL标准定义了四个隔离级别
1. READ-UNCOMMITTED(读取未提交)：最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读
2. READ-COMMITED(读取已提交)：允许读取并发事务 已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生
3. REPEATABLE-READ(可重复读)：对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生
4. SERIALIZABLE(可串行化)：最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。
隔离级别脏读不可重复读幻读

READ-UNCOMMITTED √ √ √

READ-COMMITTED × √ √

REPEATABLE-READ × × √

SERIALIZABLE × × ×
MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ（可重读）
使用命令查看，通过SELECT @@tx_isolation;。
MySQL 8.0 该命令改为SELECT @@transaction_isolation;
```
MySQL> SELECT @@tx_isolation;
+-----------------+
| @@tx_isolation |
+-----------------+
| REPEATABLE-READ |
+-----------------+ 
```
从上面对SQL标准定义了四个隔离级别的介绍可以看出，标准的SQL隔离级别里，REPEATABLE-READ(可重复读)是不可以防止幻读的。但是，InnoDB实现的REPEATABLE-READ 隔离级别其实是可以解决幻读问题发生的，分两种情况
1. 快照读：由MVCC机制来保证不出现幻读
2. 当前读：使用Next-Key Lock进行加锁来保证不出现幻读，Next-Key Lock是行锁（Record Lock ）和间隙锁（Gap Lock）的结合，行锁只能锁住已经存在的行，为了避免插入新行，需要依赖间隙锁 (只用间隙锁不行，因为间隙锁是 > 或 < ，不包括等于，所以再可重复读下原记录可能会被删掉)
因为隔离级别越低，事务请求的锁越少，所以大部分数据库系统的隔离级别都是 READ-COMMITTED ，但是你要知道的是 InnoDB 存储引擎默认使用 REPEATABLE-READ 并不会有任何性能损失。

隔离级别	脏读	不可重复读	幻读
READ-UNCOMMITTED	√	√	√
READ-COMMITTED	×	√	√
REPEATABLE-READ	×	×	√
SERIALIZABLE	×	×	×

日志

Sat, 14 Jan 2023 17:31:53 +0000

前言#

首先要了解一个东西：WAL，全称 Write-Ahead Logging，它的关键点就是先写日志，再写磁盘

在概念上，innodb通过***force log at commit***机制实现事务的持久性，即在事务提交的时候，必须先将该事务的所有事务日志写入到磁盘上的redo log file和undo log file中进行持久化
1. WAL 机制的原理也很简单：修改并不直接写入到数据库文件中，而是写入到另外一个称为 WAL 的文件中；如果事务失败，WAL 中的记录会被忽略，撤销修改；如果事务成功，它将在随后的某个时间被写回到数据库文件中，提交修改
2. 使用 WAL 的数据库系统不会再每新增一条 WAL 日志就将其刷入数据库文件中，一般积累一定的量然后批量写入，通常使用页为单位，这是磁盘的写入单位。同步 WAL 文件和数据库文件的行为被称为 checkpoint（检查点），一般在 WAL 文件积累到一定页数修改的时候；当然，有些系统也可以手动执行 checkpoint。执行 checkpoint 之后，WAL 文件可以被清空，这样可以保证 WAL 文件不会因为太大而性能下降。
  
  有些数据库系统读取请求也可以使用 WAL，通过读取 WAL 最新日志就可以获取到数据的最新状态
  关于checkpoint：https://www.cnblogs.com/chenpingzhao/p/5107480.html思考一下这个场景：如果重做日志可以无限地增大，同时缓冲池也足够大，那么是不需要将缓冲池中页的新版本刷新回磁盘。因为当发生宕机时，完全可以通过重做日志来恢复整个数据库系统中的数据到宕机发生的时刻。但是这需要两个前提条件：1、缓冲池可以缓存数据库中所有的数据；2、重做日志可以无限增大
  
  因此Checkpoint（检查点）技术就诞生了，目的是解决以下几个问题：1、缩短数据库的恢复时间；2、缓冲池不够用时，将脏页刷新到磁盘；3、重做日志不可用时，刷新脏页。
  - 当数据库发生宕机时，数据库不需要重做所有的日志，因为Checkpoint之前的页都已经刷新回磁盘。数据库只需对Checkpoint后的重做日志进行恢复，这样就大大缩短了恢复的时间。
  - 当缓冲池不够用时，根据LRU算法会溢出最近最少使用的页，若此页为脏页，那么需要强制执行Checkpoint，将脏页也就是页的新版本刷回磁盘。
  - 当重做日志出现不可用时，因为当前事务数据库系统对重做日志的设计都是循环使用的，并不是让其无限增大的，重做日志可以被重用的部分是指这些重做日志已经不再需要，当数据库发生宕机时，数据库恢复操作不需要这部分的重做日志，因此这部分就可以被覆盖重用。如果重做日志还需要使用，那么必须强制Checkpoint，将缓冲池中的页至少刷新到当前重做日志的位置。
3. mysql 的 WAL，大家可能都比较熟悉。mysql 通过 redo、undo 日志实现 WAL。redo log 称为重做日志，每当有操作时，在数据变更之前将操作写入 redo log，这样当发生掉电之类的情况时系统可以在重启后继续操作。undo log 称为撤销日志，当一些变更执行到一半无法完成时，可以根据撤销日志恢复到变更之间的状态。mysql 中用 redo log 来在系统 Crash 重启之类的情况时修复数据（事务的持久性），而 undo log 来保证事务的原子性。

索引

Tue, 10 Jan 2023 22:09:25 +0000

补充索引基础知识(引自b站sgg视频)#

存储引擎，数据的基本单位是页，如果数据很少，只有一页，那就简单，是直接二分查找(不涉及磁盘IO)；如果数据很多，有好几个页，那么需要对页建立一种数据结构，能够最快定位到哪一页，然后减少磁盘IO

索引介绍#

索引是一种用于快速查询和检索数据的数据结构，其本质可以看成是一种排序好的数据结构

索引的作用就相当于书的目录。打个比方: 我们在查字典的时候，如果没有目录，那我们就只能一页一页的去找我们需要查的那个字，速度很慢。如果有目录了，我们只需要先去目录里查找字的位置，然后直接翻到那一页就行了
索引底层数据结构存在很多种类型，常见的索引结构有：B树，B+树和Hash、红黑树。在MySQL中，无论是Innodb还是MyIsam，都使用了B+树作为索引结构

索引的优缺点#

优点：

使用索引可以大大加快数据的检索速度（大大减少检索的数据量）, 这也是创建索引的最主要的原因。
通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。

缺点：

创建索引和维护索引需要耗费许多时间。当对表中的数据进行增删改的时候，如果数据有索引，那么索引也需要动态的修改，会降低 SQL 执行效率。
索引需要使用物理文件存储，也会耗费一定空间

索引一定会提高查询性能吗

多数情况下，索引查询都是比全表扫描要快的。但是如果数据库的数据量不大，那么使用索引也不一定能够带来很大提升

索引的底层数据结构#

Hash表#

哈希表是键值对的集合，通过键（key）即可快速取出对应的值（value），因此哈希表可以快速检索数据（接近O(1))
为何能够通过key快速取出value呢？原因在于哈希算法（也叫散列算法）。通过哈希算法，我们可以快速找到key对应的index，找到了index也就找到了对应的value
```
hash = hashfunc(key)
index = hash % array_size
```
注意，图中keys[天蓝色]是字符串，不是什么莫名其妙的人
哈希算法有个 Hash 冲突 问题，也就是说多个不同的 key 最后得到的 index 相同。通常情况下，我们常用的解决办法是 链地址法。链地址法就是将哈希冲突数据存放在链表中。就比如 JDK1.8 之前 HashMap 就是通过链地址法来解决哈希冲突的。不过，JDK1.8 以后HashMap为了减少链表过长的时候搜索时间过长引入了红黑树。
为了减少 Hash 冲突的发生，一个好的哈希函数应该**“均匀地”将数据分布**在整个可能的哈希值集合中
由于Hash索引不支持顺序和范围查询，假如要对表中的数据进行排序或者进行范围查询，那Hash索引就不行了，并且，每次IO只能取一个
例如： SELECT * FROM tb1 WHERE id < 500 ;
- 这种范围查询中，B+树优势非常大直接遍历比500小的叶子节点即可
- 如果使用Hash索引，由于Hash索引是根据hash算法来定位的，难不成把1 ~499 （小于500）的数据都进行一次hash计算来定位吗？这就是Hash最大的缺点
这里其实说的是已经找到了索引，但是索引没有数据的情形。要么通过hash一个个取数据，要么利用B+树的特性（叶子节点有完整数据）

字符集详解

Tue, 10 Jan 2023 16:48:22 +0000

图示总结

MySQL字符编码集有两套UTF-8编码实现：utf-8 和 utf8mb4
而其中，utf-8 不支持存储emoji符号和一些比较复杂的汉字、繁体字，会出错

何为字符集#

字符是各种文字和符号的统称，包括各个国家文字、标点符号、表情、数字等等
- 字符集就是一系列字符的集合，字符集的种类较多，每个字符集可以表示的字符范围通常不同，就比如说有些字符集无法表示汉字
计算机只能存储二进制的数据，那英文、汉字、表情等字符应该如何存储呢
- 我们要将这些字符和二进制的数据一一对应起来，比如说字符“a”对应“01100001”，反之，“01100001”对应 “a”。我们将字符对应二进制数据的过程称为"字符编码"，反之，二进制数据解析成字符的过程称为“字符解码”。

有哪些常见的字符集#

常见的字符集有ASCLL、GB2312、GBK、UTF-8
不同的字符集的主要区别在于
1. 可以表示的字符范围
2. 编码方式

ASCLL#

ASCII (American Standard Code for Information Interchange，美国信息交换标准代码) 是一套主要用于现代美国英语的字符集（这也是 ASCII 字符集的局限性所在）

为什么 ASCII 字符集没有考虑到中文等其他字符呢？ 因为计算机是美国人发明的，当时，计算机的发展还处于比较雏形的时代，还未在其他国家大规模使用。因此，美国发布 ASCII 字符集的时候没有考虑兼容其他国家的语言
ASCII 字符集至今为止共定义了 128 个字符，其中有 33 个控制字符（比如回车、删除）无法显示
一个 ASCII 码长度是一个字节也就是 8 个 bit，比如“a”对应的 ASCII 码是“01100001”。不过，最高位是 0 仅仅作为校验位，其余 7 位使用 0 和 1 进行组合，所以，ASCII 字符集可以定义 128（2^7）个字符

由于，ASCII 码可以表示的字符实在是太少了。后来，人们对其进行了扩展得到了 ASCII 扩展字符集 。ASCII 扩展字符集使用 8 位（bits）表示一个字符，所以，ASCII 扩展字符集可以定义 256（2^8）个字符

数据库基础

Tue, 20 Dec 2022 11:19:14 +0000

什么是数据库，数据库管理系统，数据库系统，数据库管理员#

数据库：数据库（DataBase 简称DB）就是信息的集合或者说数据库管理系统管理的数据的集合。
数据库管理系统：数据库管理系统（Database Management System 简称DBMS）是一种操纵和管理数据库的大型软件，通常用于建立、使用和维护 数据库。
数据库系统（范围最大）：数据库系统（Data Base System，简称DBS）通常由**软件、数据和数据管理员（DBA）**组成。
数据库管理员：数据库管理员（Database Adminitrator，简称DBA）负责全面管理和控制数据库系统 (是一个人)

数据库系统基本构成如下图所示

什么是元组，码，候选码，主码，外码，主属性，非主属性#

元组：元组（tuple）是关系数据库中的基本概念，关系是一张表，表中的每行（即数据库中的每条记录）就是一个元组，每列就是一个属性。在二维表里，元组也成为行
码：码就是能唯一标识实体的属性，对应表中的列
候选码：若关系中的某一属性或属性组的值能唯一的标识一个元组，而其任何、子集都不能再标识，则称该属性组为候选码。例如：在学生实体中，“学号”是能唯一的区分学生实体的，同时又假设“姓名”、“班级”的属性组合足以区分学生实体，那么**{学号}和{姓名，班级}都是候选码**。
主码：主码也叫主键，主码是从候选码中选出来的。一个实体集中只能有一个主码，但可以有多个候选码
外码：外码也叫外键。如果一个关系中的一个属性是另外一个关系中的主码则这个属性为外码。
主属性 ： 候选码中出现过的属性称为主属性(这里强调单个）。比如关系工人（工号，身份证号，姓名，性别，部门）. 显然工号和身份证号都能够唯一标示这个关系，所以都是候选码。工号、身份证号这两个属性就是主属性。如果主码是一个属性组，那么属性组中的属性都是主属性。
非主属性： 不包含在任何一个候选码中的属性称为非主属性。比如在关系——学生（学号，姓名，年龄，性别，班级）中，主码是“学号”，那么其他的“姓名”、“年龄”、“性别”、“班级”就都可以称为非主属性。

主键和外键有什么区别#

主键(主码) ：主键用于唯一标识一个元组，不能有重复，不允许为空。一个表只能有一个主键。
外键(外码) ：外键用来和其他表建立联系用，外键是另一表的主键，外键是可以有重复的，可以是空值。一个表可以有多个外键

为什么不推荐使用外键与级联#

对于外键和级联，阿里巴巴开发手册这样说道

【强制】不得使用外键与级联，一切外键概念必须在应用层解决。

说明: 以学生和成绩的关系为例，学生表中的 student_id 是主键，那么成绩表中的 student_id 则为外键。如果更新学生表中的 student_id，同时触发成绩表中的 student_id 更新，即为级联更新。

缺点： 外键与级联更新适用于单机低并发，不适合分布式、高并发集群; 级联更新是强阻塞，存在数据库更新风暴的风险; 外键影响数据库的插入速度
为什么不要使用外键
1. 增加了复杂性
  
  a. 每次做DELETE 或者UPDATE都必须考虑外键约束，会导致开发的时候很痛苦, 测试数据极为不方便; b. 外键的主从关系是定的，假如那天需求有变化，数据库中的这个字段根本不需要和其他表有关联的话就会增加很多麻烦。
2. 增加了额外操作
  
  数据库需要增加维护外键的工作，比如当我们做一些涉及外键字段的增，删，更新操作之后，需要触发相关操作去检查，保证数据的的一致性和正确性，这样会不得不消耗资源；（个人觉得这个不是不用外键的原因，因为即使你不使用外键，你在应用层面也还是要保证的。所以，我觉得这个影响可以忽略不计。）