一、MYSQL 架构与历史
1.mysql架构简图
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vWu46yfh-1645871438197)(…/mysql-image\MySql架构简图.png)]
? mysql存储引擎将存储引起中的数据通过行缓存格式拷贝数据、服务层将拷贝内存解码成各个列。(数据库一个表不建议设计多个列)
2. mysql并发控制
2.1 锁策略
同一个数据并发修改需要锁的机制来保证数据的一致性,所以常见的并发控制是通过实现两种机制的锁来解决并发问题。分别是排它锁(也叫写锁)和共享锁(读锁),场景如下:
- 读读锁:这种场景下是不会出现阻塞的,因为读数据并不会影响数据,所以支持并发读数据。
- 写写锁:该场景需要进行阻塞。
- 读写锁(写读锁) :虽然有读请求,但是写请求会影响读取结果,也需要进行排他锁处理。
所以说一个写锁会阻塞其他的写锁和读锁。
2.2 锁粒度
在上面我们介绍了锁的实现策略,而提交系统并发还有一种方式是细化锁定的范围即锁粒度 。只有在保证数据安全的前提下使得锁定范围尽可能的小,从而使得并发程度更高。
MySQL有三种锁的级别:页级、表级、行级
- MyISAM和MEMORY存储引擎采用的是表级锁(table-level locking);
- BDB存储引擎采用的是页面锁(page-level locking),但也支持表级锁;
- InnoDB存储引擎既支持行级锁(row-level locking),也支持表级锁,但默认情况下是采用行级锁。
MySQL这种锁的特性可大致归纳如下:
- 表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。
- 行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。
- 页面锁:开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间,并发度一般。
锁的机制是由各个的存储引擎实现的
3. mysql 事务
3.1 mysql事务日志
? 在修改数据的时候,只需修改内存中的数据并将修改记录以顺序IO的形式写入事务日志中,待以后慢慢回写磁盘。
有了事务日志,则数据持久化到磁盘不需要进行实时随机IO的更新数据操作
二、服务性能剖析
1. 服务性能指标
- 响应时间 : 服务器处理一次请求响应的耗时。
- QPS:Query Per Second,每秒请求数。响应时间越短,QPS则越高。在单线程的情况下,是呈线性关系,多线程时,总QPS = (1000ms/ 响应时间)* 线程数。
- 吞吐量:单位时间内可处理的事务的数量,属于性能定义的倒数。
三、mysql优化
1. schema和数据类型的优化
schema在数据库中表示的是数据库对象集合,它包含了各种对像,比如:表,视图,存储过程,索引。mysql的schema等价于数据库对象(包含表、视图、存储过程、索引等等的集合)
-
最小数据长度: 能正确存储数据的最小数据类型,datetime和timesamp存储日期(精确到秒),但是后者只需要占据前者一半的存储空间。 -
简单的数据类型:整型要比字符串(字符串设计字符编码和排序)操作代价更低,varchar 比char类型操作代价更低。 -
避免NULL列:查询包含NULL的列会使得 索引、索引统计、值比较变的复杂,且可为null的类创建索引的时候会额外占据空间 -
整型类型:tinyint(8)、smallint(16)、mediumint(24)、int(32)、bigint(64)。unsinged 无符号会使得正数的上限提高一倍。sql中的整型计算一般都会使用64字节的bigint整数 -
实数类型:float/double 使用浮点类型进行计算(会有误差)。decimal 为精确类型计算,其有一定的空间和计算开销,所以一些财务数据可以使用bigint(乘以相应的倍数存储)。 -
字符类型:不同引擎存储格式不同。 varchar 可变字符长度(需要一个额外字段记录长度) char定长长度 varchar相对于char节省了存储空间,但更新操作来说char不容易产生碎片。(由于行长度可变对于更新操作,页内没有更多的空间可能需要通过拆分数据进行存储(MyIsam会将行拆分成不同的片段存储,InnoDB则需要分裂页来存储数据))。 blob:二进制形式存储大的字符类型数据 tinyblob、smallblob、blob、mediumblob、bingblob text:字符串形式存储大的字符类型数据 tinytext、smatext、text、mediumtext、bigtext mysql将blob和text当做独立对象,如果其只太大时 页内只存储指针,指向外部存储的实际区域 尽量避免这两种数据类型 -
enum类型:枚举可以将字符串存储到预定义集合中,占用很少的空间。 -
日期时间类型:DateTime类型和TIMESTAMP类型,推荐使用TIMESTAMP因为其空间效率高。 -
位数据类型,mysql5.0之前BIT和tinyInt是一样的。mysql5.0之后是使用一个或多个bit(位)存储0/1,MySql将bit当做字符串类型进行处理。
2. mysql设计的范式
- 第一范式1NF: 数据库中的每个字段不可再分。
- 第二范式2NF: 有主键,非主键字段依赖主键。
- 第三范式3NF: 数据库表中不包含已在其他表中已包含的非主键字段。
- 反范式:通过一定的数据字段冗余避免表关联。
3. 缓存汇总相关
? 对于缓存汇总相关统计数据来说 有如下设计方式
1. 使用视图 增加读性能
2. 技术器相关 可以使用多条记录存储计数,最终使用sum汇总(解决多个地方同时修改一行记录 造成的全局互斥锁)
4. alter table
? mysql的alter table 操作对大表的性能损耗很大,与其需要表结构的原理有关:mysql在执行代大部分修改表结果的方式是创建一个新表,从旧表查询数据并插入新表(重构缓存)再删除旧表,同时alter 操作会终端mysql服务。
? alter table使用技巧:
1. 在不提供服务的mysql节点进行alter table操作 然后进行主从切换。
2. 使用**影子拷贝**。
3. alter table 表名 alter column xxx 操作改变表结构 会直接修改.frm文件而不涉及表数据。(<font color="red">是仅仅限于修改列的默认值 还是所有操作</font>)
mysql知识点(补充)
1. 查看表的相关信息
SHOW TABLE STATUS LIKE 'table_name'
(Name , Engine , Version , Row_format , Rows , Avg_row_length , Data_length , Max_data_length , Index_length , Data_free , Auto_increment , Create_time , Update_time , Check_time , Collation , Checksum , Create_options , Comment )
表属性 | 属性说明 |
---|
Name | 表名 | Engine | 表使用的存储引起 | Version | | Row_format | 行的格式。对于MyISAM表,可选的值为Dynamic 可变字段、Fixed或者Compressed | Rows | 表中的行数。对于 MyISAM 和其他一些存储引擎,该值是精确的,但对于 InnoDB,该值是估计值 | Avg_row_length | 平均每行包含的字节数 | Data_length | 表数据大小(以字节为单位) | Max_data_length | 表数据的最大容量,该值和存储引擎有关。 | Index_length | 索引的大小(以字节为单位) | Data_free | 对于 MyISAM 表,表示已分配但目前没有使用的空间。这部分空间包括了之前删除的行,以及后续可以被 INSERT 利用到的空间。 | Auto_increment | 下一个 AUTO_INCREMENT 的值 | Create_time | 表的创建时间 | Update_time | 表数据的最后修改时间 | Check_time | 使用 CHECK TABLE 命令或者 myisamchk 工具最后一次检查表的时间。 | Collation | 表的默认字符集和字符列排列规则 | Checksum | 如果启用,保存的是整个表的实时校验和。 | Create_options | 创建表时的其他选项 | Comment | 该列包含了一些其他的额外信息。对于 MyISAM 表,保存的是表在创建时带的注释。对于 InnoDB 表,则保存的是 InnoDB 表空间的剩余空间信息。如果是一个视图,则该列包含 “VIEW” 的文本字样。 |
|