mysql索引引擎范式事务总结

约定不等于承诺〃 2023-07-24 03:06 44阅读 0赞

### mysql ###

*  三范式
 *  存储引擎
 *  mysql架构及组件
 *  innodb存储引擎
 *   *  innodb的四大特性
     *  mysql中---lock与latch
 *  sql执行原理
 *  索引原理
 *   *  索引问题清单
     *  索引底层实现
     *  模拟索引的创建和查找过程
     *  索引失效分析
     *  自动创建索引
     *  聚集索引和非聚集索引
 *  事务
 *  注意点

# 三范式 #

[origin link][]  
[refer link][]  
一范式：**每列不可分**。【部门角色字段（销售部实习生）就应该切分为部门字段（销售部）和角色字段（实习生）】  
二范式：**每列与主键相关**（直接相关或者间接相关）一个表只描述一件事情。一个数据库表中只能保存一种数据（一张表对应一个pojo对象）订单表和商品表不能设计在一张表里，应该分开两个表，再加一个多对多的商品id和订单id关联表。（拆多表）【多对多关系应该拆表，使用中间表来关联（解耦）多对多】  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70]

三范式：**每列与主键直接相关**每个属性都跟主键有直接关系而不是间接关系。【消除传递依赖】  
用户名/用户电话是通过用户id和订单id间接关联（外键关联来解耦 一对多）,所以  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 1]

> 比如Student表（学号，姓名，年龄，性别，所在院校，院校地址，院校电话）  
> 这样一个表结构，就存在上述关系。 学号–> 所在院校 --> (院校地址，院校电话)  
> 这样的表结构，我们应该拆开来，如下。（学号，姓名，年龄，性别，所在院校）–（所在院校，院校地址，院校电话）

总结：三大范式只是一般设计数据库的基本理念，可以建立冗余较小、结构合理的数据库。如果有特殊情况，当然要特殊对待，数据库设计最重要的是看需求跟性能，需求>性能>表结构。所以不能一味的去追求范式建立数据库。

# 存储引擎 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 2]  
 存 储 引 擎 是 基 于 表 的 ， 而 不 是 数 据 库 \\color\{cyan\}\{存储引擎是基于表的，而不是数据库\} 存储引擎是基于表的，而不是数据库  
【Innodb，MYISAM，MEMORY】【ARCHIVE，BLACKHOLE，CSV，MRG\_MYISAM，PERFORMANCE\_SCHEMA】

*   I n n o d b \\color\{red\}\{Innodb\} Innodb  
    MySQL5.5以及之后的版本采用innodb作为默认的存储引擎，  
    **主要特点**  
    支持行级锁  
    支持外键约束  
    完备的事务机制，实现了四种隔离级别  
    可靠性号，崩溃后修复能力较高  
    **文件格式**  
    .frm(存储表定义)  
    共享表空间文件：ibdata1  
    私有表空间文件：表名.ibd  
    redo log文件  
    **适用场景** ：【数据修改频繁，对事务特性要求比较高(如金融系统)，需要支持并发处理能力的系统。】
 *   M Y I S A M \\color\{red\}\{MYISAM\} MYISAM  
    MySQL5.5以前采用MYISAM作为默认的存储引擎  
    **主要特点**  
    比较强调读取效率，查询速度较快  
    磁盘空间占用少  
    只支持表级锁，并发能力较差  
    不支持事务，灾难恢复能力较差  
    **文件格式**  
    .frm(存储表定义)  
    MYD(MYData，存储数据)  
    MYI(MYIndex，存储索引)  
    **适用场景**：【数据很少更新，一次插入，多次读取的业务场景。】
 *   M E M O R Y \\color\{red\}\{MEMORY\} MEMORY  
    类似于内存缓存，表结构的定义存在磁盘上(frm文件)，实际数据是存储在内存中  
    **主要特点**  
    响应速度快  
    表级锁，频繁更新数据可能会造成并发瓶颈  
    不支持可变字段(但可以借助verchar实现文本存储)  
    数据可靠性很差，机器或MySQL服务器重启后，就会丢失  
    需要机器有足够的内存  
    **适用场景**：【数据量不大，需要被频繁的访问，而且数据丢失不会对业务产生比较严重的影响。】
 *   A R C H I V E \\color\{red\}\{ARCHIVE\} ARCHIVE  
    【档案文件】【用于数据归档；它的压缩比非常的高，存储空间大概是innodb的10-15分之一所以它用来存储历史数据非常的适合，由于它不支持索引同时也不能缓存索引和数据，由于高压缩和快速插入的特点Archive非常适合作为日志表的存储引擎，但是前提是不经常对该表进行查询操作。archive存储引擎支持insert、replace和select操作，但是不支持update和delete。】
 *   B L A C K H O L E \\color\{red\}\{BLACKHOLE\} BLACKHOLE  
    【黑洞引擎，写入的任何数据都会消失，用于记录binlog做复制的中继存储！比如一个表test的引擎是BlackHole，任何对这个表的insert都将丢失，  
    对它的select永远返回空集，对应的数据目录下只有一个test.frm文件，且没有其他文件与之关联【适用场景：虽然其不保存数据，但对数据库的操作仍旧记录在binlog日志中。  
    这就带来一个好处，可以将其作为主从复制的中介，将原来从主库中同步的操作变为从作为中介的BlackHole引擎数据库中同步。1.作为伪主库分担主库负担；2.作为binlog日志收集器[refer link][refer link 1]】】
 *   C S V \\color\{red\}\{CSV\} CSV  
    【数据以文本方式存储在文件中，可对齐直接进行编辑  
    【适合做为数据交换的中间表  
    如，A表 与 B表需要进行数据交换，那么 A表会先将数据导入 CSV 文件中，然后 CSV 文件再将数据导入 B表。】 适合做为数据交换的中间表（能够在服务器运行的时候，拷贝和拷出文件，可以将电子表格存储为CSV文件再拷贝到MySQL数据目录下，就能够在数据库中打开和使用。同样，如果将数据写入到CSV文件数据表中，其它web程序也可以迅速读取到数据。】
 *   M R G M Y I S A M \\color\{red\}\{MRG\_MYISAM\} MRGMYISAM  
    （合并MYISAM引擎）【是一个相同的可以被当作一个来用的MyISAM表的集合。使用它来实现分表操作https://www.cnblogs.com/datastudy/p/6025462.html  
    把几张结构完全相同的表的数据合并到一张结构完全相同的表里面】
 *   P E R F O R M A N C E S C H E M A \\color\{red\}\{PERFORMANCE\_SCHEMA\} PERFORMANCESCHEMA  
    【性能模式】【主要用于收集数据库服务器性能参数。MySQL用户是不能创建存储引擎为PERFORMANCE\_SCHEMA的表  
    performance\_schema提供以下功能：  
    1.提供进程等待的详细信息，包括锁、互斥变量、zd文件信息；  
    2.保存历史的事件汇总信息，为提供MySQL服务器性能版做出详细的权判断；  
    3.对于新增和删除监控事件点都非常容易，并可以随意改变mysql服务器的监控周期，例如（CYCLE、MICROSECOND）  
    通过以上得到的信息，DBA能够较明细得了解性能降低可能是由于哪些瓶颈？  
    l performance\_schema功能开启和部分表功能  
    Performance的开启很简单，在my.cnf中\[mysqld\]加入performanc\_schema，检查性能数据库是否启动的命令:  
    SHOW VARIABLES LIKE ‘performance\_schema’;  
    若是返回的 值为ON，则说明性能数据库正常开启状态。】

[more refer link][]

# mysql架构及组件 #

![在这里插入图片描述][20200406214535857.png]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 3]  
第1层【连接层】的各种服务并非MySQL 独有。它们是许多基于网络的客户端/服务((Client/server))工具或务器都需要的服务,比如**连接处理、授权认证、安全**等

第2层【服务层】值得关注。它包括了MySQL 的大多数核心内容,比如**查询解析、分析、优化、缓存及所有内建函数**(如日期、时间、数学和加密函数等)的代码。各种存储引擎提供的功能也集中在这层,如**存储过程、触发器,视图**等。

第3层【引擎层】包含了存储引擎,存储引擎负责**存储和提取所有存放在MySQL 中的数据**，和GNU/Linux 下的各种文件系统一样,每个存储引擎都有自己的优势和劣势。服务器通过存储引擎API(( StorageEngine AP )与引擎进行通信。该接口隐藏了存储引擎之间的区别,使它们在查询层上是透明的。AP包含了几十个底层函数,用来执行相关操作,如“开始一个事务”,“提取一行拥有某主键的数据”等等。存储引擎不会进行SQL解析(注1)(( Parse),也不会互相通信,它们只是简单地响应服务器的请求

第4层 【存储层】数据存储层，主要是将数据存储在运行于裸设备的文件系统之上，并完成与存储引擎的交互。

> 连接词组件  
> 管理服务和工具组件  
> sql接口组件  
> 查询分析器组件  
> 优化器组件  
> 缓冲组件  
> 插件式存储引擎

# innodb存储引擎 #

## innodb的四大特性 ##

[插入缓存,两次写,自适应哈希索引,异步IO,刷新临近页][IO]  
插入缓存insert buffer 给innodb带来了**性能上的提升**，两次写doublewrite给innodb存储引擎带来了**数据页的可靠**

> 这里可以对比jvm来理解学习  
> sql（编译优化）---- java（编译优化）  
> innodb（磁盘io进行数据加载）-- jvm（类加载）

> innodb，最核心的功能就是：**将磁盘中的数据加载到内存中来，将内存中的数据写入到磁盘中去**

> 索引，事务，锁，日志文件，表文件等功能都由innodb提供实现，sql语句只是去调用存储引擎提供的api而已。

[mysql技术内幕–innodb存储引擎（内容概览–脑图图解）][mysql_innodb]

innodb引擎工作过程

> 对innodb引擎而言：对于建立了索引的字段(引擎会创建索引文件在磁盘中，当数据库用到索引时，会将这些索引文件读入内存，建立了索引的字段的数据就会以b+树的形式存放在内存中)当查询时，就能够进行快速的查找了。  
> 按页加载，使用LRU淘汰机制…  
> 这些过程都有一个线程，负责将这些操作记录写入到重做日志(记录了对于innodb存储引擎的事务日志)中  
> 在innodb，存储引擎中，主键是行的唯一标识符，通常应用程序中行记录的，插入顺序是按照，主键递增的顺序进行插入的  
> 现在的innodb使用的是内核级别的nio,即native aio,在innodb存储引擎中，read ahead方式的读取都是通过aio实现，脏页的刷新(即磁盘的写入操作)全部由aio完成。  
> 引擎会对行加锁，操作缓冲池中的列表增加，删除，移动，列表中的元素，为了保证一致性，也会有锁的介入

## mysql中—lock与latch ##

这里还要区分锁中容易令人混淆的概念lock与latch 。在数据库中,lock与latch 都可以被称为“锁”。但是两者有着截然不同的含义,本章主要关注的是lock

latch一般称为闩锁(轻量级的锁),因为其要求锁定的时间必须非常短。若持续的时间长,则应用的性能会非常差。在InnoDB 存储引擎中,latch 又可以分为mutex (互斥量)和rwlock (读写锁)。其目的是用来保证并发线程操作临界资源的正确性,并且通常没有死锁检测的机制。

lock的对象是事务,用来锁定的是数据库中的对象,如表、页、行。并且一般lock的对象仅在事务commit 或rollback 后进行释放(不同事务隔离级别释放的时间可能不同)。此外,lock,正如在大多数数据库中一样,是有死锁机制的。表6-1显示了lock与atch的不同。

# sql执行原理 #

[Sql语句的执行原理-MySQL][Sql_-MySQL]

1.  应用程序把查询SQL语句发送给服务器端执行
2.  查询缓存，如果命中（缓存中有），则直接从缓存中拿到结果并返回给客户端，否则就进入下一步
3.  查询优化处理，生成执行计划【这个阶段包括：解析SQL、预处理、优化SQL执行计划【查询优化器会自动判断是否使用索引…最终选择执行成本最低的执行计划】，其中任何一个阶段出错都会导致查询进行不下去。】
4.  Mysql根据相应的执行计划（数据结构）完成整个查询【这一步由存储引擎负责完成】
5.  将查询结果返回客户端【如果查询可以缓存，Mysql在这个阶段也会将结果放到查询缓存中。】

# 索引原理 #

> 如果表中一条记录占用磁盘1kb字节的话，对其中一个10个字节的字段建立索引，那么该记录对应的索引块的大小只有10个字节。了解到数据库中最小的空间单元是页，一个页在磁盘上占用16kb，那么这个页就可以记录16条字段记录，可以存储800条索引。如果我们要从8000条记录的表中检索符合某个条件记录的话，如果没有索引的话，需要遍历8000条*1000字节/8k=1000个页面。如果有索引的话，则查询8000条*10字节/8k=10个页面就可以了

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 4]  
0x07,0x56这些是执行数据34，77的物理地址的指针  
select \* from t2 where col2=89,需要查找6次。假设mysql按页从磁盘中加载数据到内存。一页能存一行数据 ，则需要6次io才能查询到结果。假设对col2字段建立了二叉搜索树的结构，则2次就可以找到数据。及2次io解决问题

> 打个比方：没有建立索引:  
> 一本厚厚的字典(假如有1000页)，当你想查找cool这个单词时，你就需要从头到尾一页一页的去查找这个单词，你需要查找1000次。  
> 建立索引:(按照a到z的顺序对数据排序)  
> 通过二分查找，迅速从a到z里面找到c，然后再按照c 的next指针找下去，就能很快找到cool

## 索引问题清单 ##

1.  mysql页文件为何默认16K

> 假设我们一行数据大小为1K,那么一页就能存16条数据,也就是一个叶子节点能存16条数据;再看非叶子节点,假设主键ID为bigint 类型,那么长度为8B,指针大小在Innodbi 源码中为6B,一共就是14B,那么一页里就可以存储16K/14=1170个(主键+指针)  
> 那么一颗高度为2的B+树能存储的数据为:1170*16=18720条,一颗高度为3的B+树能存储的数据为:1170*1170\*16=21902400(千万级条)  
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 5]

1.  为何采用b+树，而不用avl树，b树，红黑树

*  二叉树（avl树，红黑树）不管再整样平衡，它每层都只有两个节点，当数据量大时，必然会树的深度很深。磁盘io次数很多，性能很慢
 *  B Tree查询的效率不够稳定，键值其实都是分布在整棵树上的节点上的任何一个节点
 *  **b+树**它很好的利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样每个节点只需要一次I/O就可以完全载入。非叶子节点存指针+主键，叶子节点存数据：每次查询的时间复杂度是固定的。分叉（更向更宽广）就可以更多，树的高度就可以更小，一次io可以获取更多的key

## 索引底层实现 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 6]

## 模拟索引的创建和查找过程 ##

![在这里插入图片描述][20200409182335462.png]  
a是主键，abcd是int型的，e是vachar（20），bcd建立了联合索引（create index idx\_t1\_bcd on t1(b asc,c desc,d desc)）  
show index from t1  
此时有两个索引：PRIMARY【主键索引–默认创建的】和idx\_t1\_bcd  
![在这里插入图片描述][20200408170913436.png]  
//如果再对b建立普通索引idx\_t1\_b，那查询出来就有三个索引了。

> 局部性原理：  
> 操作系统在执行一行指令的时候，如果这行指令要去取数据，基于局部性原理，操作系统认为，这一行指令所需要的数据，以及他周围相邻的数据，可能是你接下来的立马要执行的那条指令，也需要的，所以这时候他在执行某条指令的时候，就会取出一页的数据，这就方便了，你下一条指令可能刚好命中这个条件。【按页（4kb）加载数据到内存】

innodb中一页的结构：  
![在这里插入图片描述][20200408173334856.png]  
t1表为例：4个int型的，一个vachar型的，则一行需要17Byte，按一页16kb，则一页能存964行数据。  
假设8条数据用2页来保存  
通过前后指针，两页在逻辑上就是连续的了  
通过页目录和目录页来加速查找。（加速了链表查询）  
B+树一个节点可以存储多个数据  
按照主键排序  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 7]  
加入一页只能存两条数据  
聚簇索引  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 8]  
非聚簇索引  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 9]

聚簇（集）索引的**叶子节点就是数据节点**，而非聚簇（集）索引的**叶子节点仍然是索引节点**，只不过有指向对应数据块的指针。非聚簇（集）索引在innodb引擎中，又叫做二级索引，辅助索引等。  
select \* fom t1 where b>1查询优化器判断出走全表扫描比走索引更快  
当select \* fom t1 where b>5它就又会走索引了【该情况下走索引成本更低】  
7条数据，它要回表7次。不如直接走主键索引/全表扫描  
全表扫描4页我就走4次就可以了  
![在这里插入图片描述][20200409071232476.png]  
不需要回表  
![在这里插入图片描述][20200409071306778.png]  
需要回表【**叶子节点仍然是索引节点，它还需要到主键索引中查找数据**】

select b from t1会走索引，因为索引的叶子节点里面存的是bcd数据，而b正好的bcd里面，所以相同数据量，只需要3页就能存完所有的bcd记录，但如果全表【主键索引】，可能需要6页才能存完完整的abcde的记录  
111是bcd的值，代表一行数据，浅黄色标出来的是这行数据对应的主键，方便对于select \* from t1 where b=1,c=1,d=1则可以通过111知道主键1，查出该行所有字段的结果了。这样记录主键就可以，不用记录所有的数据  
知道主键1(主键1在主键索引的叶子节点里面)此时就要回表【bcd索引叫二级/辅助索引】  
![在这里插入图片描述][20200409070202808.png]  
bcd是三个int型，一个int占4字节，又由于bcd都是可以为null的，这个还需要用1字节去记录下，所以每个b，c，d就占5字节，bcd三个就占15字节

> 一行的格式  
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 10]  
> 一行最多65535字节（Byte简写为B）  
> 一页16KB就是16384，行溢出就需要分页去存储。

## 索引失效分析 ##

> **索引优化口诀**  
> 全值匹配我最爱，最左前缀要遵守  
> 带头大哥不能死，中间兄弟不能断  
> 索引列上少计算，范围之后全完蛋  
> like百分写最右， 覆盖索引不写 \*  
> 不等空值还有or，索引失效要少用  
> var引号不能丢，SQL高级也不难

> **索引创建原则口诀**:  
> 主键索引自动建,频繁查询索引现;  
> 查询关联其它表,外键索引也要看  
> 频繁更新引不建,where 条件用到算  
> 单键/组合选择难,高并发下组合建  
> 若要速度有体现,排序字段索引建  
> 统计、分组你咋看,索引索引建建键;

建立索引a，b，c  
where a= 1走索引 1 \* \*  
where b=1不走索引，类似于 \* 1 \*  
字符串匹配一样1 \* \* < 644,但是 \* 1 \*无法和644比较，可能比他大，也可能比他小，这样计算机在判断时就只能走全表扫描了  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 11]  
走B索引范围查询，查出来的结果集对C而言不一定是有序的。但对b等值查询（查出来都是一样的），查出来的对C是有序的，  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 12]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 13]

## 自动创建索引 ##

ALTER TABLE `t1` ADD unique(`e`);  
给e字段添加唯一约束，则建表语句为UNIQUE KEY `e` (`e`)，此时会自动给e字段添加唯一索引，对于主键，外键字段，数据库也会自动添加索引。

> PRIMARY KEY (`a`), 主键a  
> UNIQUE KEY `e` (`e`), 唯一约束e  
> KEY `idx_t1_bcd` (`b`,`c`,`d`), 联合索引bcd  
> KEY `t2_id` (`f`), 外键f  
> KEY `t1_b` (`b`) 单值索引b

## 聚集索引和非聚集索引 ##

*  聚集索引  
    聚集索引表示表中存储的数据按照索引的顺序存储，检索效率比非聚集索引高，但对数据更新影响较大；该索引中键值的逻辑顺序决定了表中相应行的物理顺序。聚集索引类似于电话簿，后者按姓氏排列数据。由于聚集索引规定数据在表中的物理存储顺序，因此**一个表只能包含一个聚集索引**。但该索引可以包含多个列（组合索引），就像电话簿按姓氏和名字进行组织一样。【**外存表现：数据与索引放在同一文件里；内存表现：b+树中叶节点就是最终的数据节点**】
 *  非聚集索引  
    数据存储在一个地方，索引存储在另一个地方，索引带有指针指向数据的存储位置。对于非聚集索引，可以为在表非聚集索引中查找数据时常用的每个列创建一个非聚集索引。有些书籍包含多个索引。例如，一本介绍园艺的书可能会包含一个植物通俗名称索引，和一个植物学名索引，因为这是读者查找信息的两种最常用的方法。【**外存表现：数据与索引放在不同文件里；内存表现：b+树中叶节点仍然是索引节点，但它有一个指向最终数据的指针**】
 *  在数据库中通过什么描述聚集索引与非聚集索引的？  
    索引是通过二叉树的形式进行描述的，我们可以这样区分聚集与非聚集索引的区别：聚集索引的叶节点就是最终的数据节点，而非聚集索引的叶节仍然是索引节点，但它有一个指向最终数据的指针。  
    [二者的区别][Link 1]  
    [讲的很全面][Link 2]

# 事务 #

[参考我的mysql事务专题博客][mysql]

# 注意点 #

1.  mysql里的utf8-mb4是最全的utf8，支持表情符等
2.  vachar(20)这里的20指20个字符，而非字节

不同的字符所占的字节是不同的。
    ASCII码：
    一个英文字母（不分大小百写）占一个字节的空间，度一个中文汉字占两个字节的空间。一个二进制数字序问列，在计算机中作为一个数字单元，一般为8位二进制数，换算为十进制。最小值0，最答大值255。如一个ASCII码就是一个字节。
    UTF-8编码：
    一个英文字符等于一个字节，一个中文（专含繁体）等于三属个字节。
    Unicode编码：
    一个英文等于两个字节，一个中文（含繁体）等于两个字节。

[origin link]: https://blog.csdn.net/sinat_41144773/article/details/89502465?depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-3&utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-3
[refer link]: https://blog.csdn.net/q1054261752/article/details/52234188?depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1&utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70]: /images/20230528/74ba04bbf9054ca78ec3cff02239eb5e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 1]: /images/20230528/0ce1503aac3f42a0943eb886901fe08d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 2]: /images/20230528/de2b96f77c824d6e83acf3d12a72ae39.png
[refer link 1]: https://segmentfault.com/a/1190000012023635
[more refer link]: https://segmentfault.com/a/1190000019400925?utm_medium=referral&utm_source=tuicool
[20200406214535857.png]: /images/20230528/88be3a9eb9424a92a9b364561f54f7d0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 3]: /images/20230528/0c78386dd57847faa4c4081dd53d05b3.png
[IO]: http://blog.itpub.net/31523382/viewspace-2151661
[mysql_innodb]: https://blog.csdn.net/tanliqing2010/article/details/81509539?utm_source=app#5-innodb%E7%B4%A2%E5%BC%95%E4%B8%8E%E7%AE%97%E6%B3%95
[Sql_-MySQL]: https://blog.csdn.net/qq_32998153/article/details/81747643?utm_source=app
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 4]: /images/20230528/d0142d1ba393442bb28625d3a73c739f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 5]: /images/20230528/b8b5d4dd829a4107adc93e662dfa52b3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 6]: /images/20230528/b76b673969b547a69bd1463448c836f6.png
[20200409182335462.png]: /images/20230528/38c3325be0044fdca20ba9028d2db098.png
[20200408170913436.png]: /images/20230528/262d1418ce1e4d4b8f3748963a692b19.png
[20200408173334856.png]: /images/20230528/325c7c4177c045f4b96bd950754f2b64.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 7]: /images/20230528/7c4905051db74b7f898d230e65346b32.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 8]: /images/20230528/3ba72bd624ae4c288897223e84d3b4ab.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 9]: /images/20230528/5f33ed0f944f445f97be25ff47795a50.png
[20200409071232476.png]: /images/20230528/657df79ca7a246b8a98ff072481624c9.png
[20200409071306778.png]: /images/20230528/5a940b50816247b3ae17372172dd7dd8.png
[20200409070202808.png]: /images/20230528/9c891ddc040649359623fa0e0eaf253e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 10]: /images/20230528/cc79618b245149c3a05e580f2bdb42db.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 11]: /images/20230528/772156b4ba9e405f85f6ab70de075ad5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 12]: /images/20230528/350fe91afffd4601aef3dbb35deb1e5c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxMDYzMTQx_size_16_color_FFFFFF_t_70 13]: /images/20230528/ce91c474c6834616918a6815c80cf4f7.png
[Link 1]: https://blog.csdn.net/ww130929/article/details/76407648?depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1&utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1
[Link 2]: https://blog.csdn.net/w892824196/article/details/82661892
[mysql]: https://blog.csdn.net/qq_41063141/article/details/105366818