MySQL
中,如何定位慢查询?我们当时做压测的时候有的接口非常的慢,接口的响应时间超过了2秒以上,因为我们当时的系统部署了运维的监控系统Skywalking
,在展示的报表中可以看到是哪一个接口比较慢,并且可以分析这个接口哪部分比较慢,这里可以看到SQL
的具体的执行时间,所以可以定位是哪个sql
出了问题。
如果,项目中没有这种运维的监控系统,其实在MySQL
中也提供了慢日志查询的功能,可以在MySQL
的系统配置文件中开启这个慢日志的功能,并且也可以设置SQL
执行超过多少时间来记录到一个日志文件中,我记得上一个项目配置的是2秒,只要SQL
执行的时间超过了2秒就会记录到日志文件中,我们就可以在日志文件找到执行比较慢的SQL
了。
SQL
语句执行很慢, 如何分析呢?如果一条sql
执行很慢的话,我们通常会使用mysql
自动的执行计划explain
来去查看这条sql
的执行情况,比如在这里面可以通过key
和key_len
检查是否命中了索引,如果本身已经添加了索引,也可以判断索引是否有失效的情况,第二个,可以通过type
字段查看sql
是否有进一步的优化空间,是否存在全索引扫描或全盘扫描,第三个可以通过extra
建议来判断,是否出现了回表的情况,如果出现了,可以尝试添加索引或修改返回字段来修复。
索引在项目中还是比较常见的,它是帮助MySQL
高效获取数据的数据结构,主要是用来提高数据检索的效率,降低数据库的IO
成本,同时通过索引列对数据进行排序,降低数据排序的成本,也能降低了CPU
的消耗。
MySQL
的默认的存储引擎InnoDB
采用的B+
树的数据结构来存储索引,选择B+
树的主要的原因是:第一阶数更多,路径更短,第二个磁盘读写代价B+
树更低,非叶子节点只存储指针,叶子阶段存储数据,第三是B+
树便于扫库和区间查询,叶子节点是一个双向链表。
B
树和B+
树的区别是什么呢?B-树,这里的 B 表示 balance( 平衡的意思),B-树是一种多路自平衡的搜索树(B树是一颗多路平衡查找树)。
区别:
第一:在B
树中,非叶子节点和叶子节点都会存放数据,而B+树的所有的数据都会出现在叶子节点,在查询的时候,B+
树查找效率更加稳定;
第二:在进行范围查询的时候,B+
树效率更高,因为B+
树都在叶子节点存储,并且叶子节点是一个双向链表。
聚簇索引主要是指数据与索引放到一块,B+
树的叶子节点保存了整行数据,有且只有一个,一般情况下主键在作为聚簇索引的;
非聚簇索引值的是数据与索引分开存储,B+
树的叶子节点保存对应的主键,可以有多个,一般我们自己定义的索引都是非聚簇索引。
嗯,其实跟刚才介绍的聚簇索引和非聚簇索引是有关系的,回表的意思就是通过二级索引找到对应的主键值,然后再通过主键值找到聚集索引中所对应的整行数据,这个过程就是回表。
【备注:如果面试官直接问回表,则需要先介绍聚簇索引和非聚簇索引】
覆盖索引是指select
查询语句使用了索引,在返回的列,必须在索引中全部能够找到,如果我们使用id
查询,它会直接走聚集索引查询,一次索引扫描,直接返回数据,性能高。
如果按照二级索引查询数据的时候,返回的列中没有创建索引,有可能会触发回表查询,尽量避免使用select *
,尽量在返回的列中都包含添加索引的字段。
MYSQL
超大分页怎么处理 ?超大分页一般都是在数据量比较大时,我们使用了limit
分页查询,并且需要对数据进行排序,这个时候效率就很低,我们可以采用覆盖索引和子查询来解决。
先分页查询数据的id
字段,确定了id
之后,再用子查询来过滤,只查询这个id
列表中的数据就可以了。
因为查询id
的时候,走的覆盖索引,所以效率可以提升很多。
就是表中的数据要超过10万以上,我们才会创建索引,并且添加索引的字段是查询比较频繁的字段,一般也是像作为查询条件,排序字段或分组的字段这些。
还有就是,我们通常创建索引的时候都是使用复合索引来创建,一条sql
的返回值,尽量使用覆盖索引,如果字段的区分度不高的话,我们也会把它放在组合索引后面的字段。
如果某一个字段的内容较长,我们会考虑使用前缀索引来使用,当然并不是所有的字段都要添加索引,这个索引的数量也要控制,因为添加索引也会导致新增改的速度变慢。
比如,索引在使用的时候没有遵循最左匹配法则,第二个是,模糊查询,如果%
号在前面也会导致索引失效。如果在添加索引的字段上进行了运算操作或者类型转换也都会导致索引失效。
我们之前还遇到过一个就是,如果使用了复合索引,中间使用了范围查询,右边的条件索引也会失效。
所以,通常情况下,想要判断出这条sql
是否有索引失效的情况,可以使用explain
执行计划来分析。
sql
的优化的经验?如果直说sql
优化的话,我们会从这几方面考虑,比如:
建表的时候、使用索引、sql
语句的编写、主从复制,读写分离,还有一个是如果量比较大的话,可以考虑分库分表。
tinyint
(1字节)>smallint
(2字节)>int
(4字节)>bigint
(8字节),比如逻辑删除y/n
字段上(1代表可用,0代表)就可以选择tinyint
(1字节)类型;null
,使用null
的字段查询很难优化,影响索引,可以使用0或''
代替;text
和blob
,如果非使用不可,将类型为text
和blob
的字段在独立成一张新表,然后使用主键对应原表;float
或double
类型,这个坑超大,float
或double
存在精度问题,在进行比较或者加减操作的时候会丢失精度导致数据异常,凡是使用float
或double
类型的时候考虑下可不可使用int
或bigint
代替。比如金额,以元为单位使用float
或double
类型的时候,可以考虑以分为单位使用int
,bigint
类型代替,然后由业务代码进行单位的转换;createUser
、createTime
、updateUser
、updateTime
字段;a
,b
,c
,d
,a
,b
,c
,d
这个表的维度为4。where
,on
,group by
,order by
中出现的列使用索引。DML
操作的速度影响很大,因为其每增删改一次就得从新建立索引。sql
语句做了哪些优化呢?limit
进行限制limit 1
进行限制count(*)
来统计行数或者使用count(主键)
来查询,使用count(列)
的时候,不会统计此列为null
的情况select *
来查数据,使用select
需要的列名,这样的方式去查询join
链接代替子查询in
操作的集合数量,不要太大了explain
去分析原因,然后优化sql
,让其尽量走索引SQL
语句避免造成索引失效的写法;union all
代替union
,union
会多一次过滤,效率比较低;inner join
,不要使用用left join
、right join
,如必须使用 一定要以小表为驱动。这个比较清楚,事务的特性:ACID
,分别指的是:原子性、一致性、隔离性、持久性;
我举个例子:
A向B转账500,转账成功,A扣除500元,B增加500元,原子操作体现在要么都成功,要么都失败;
在转账的过程中,数据要一致,A扣除了500,B必须增加500;
在转账的过程中,隔离性体现在A像B转账,不能受其他事务干扰;
在转账的过程中,持久性体现在事务提交后,要把数据持久化(可以说是落盘操作)。
我们在项目开发中,多个事务并发进行是经常发生的,并发也是必然的,有可能导致一些问题。
第一是脏读, 当一个事务正在访问数据并且对数据进行了修改,而这种修改还没有提交到数据库中,这时另外一个事务也访问了这个数据,因为这个数据是还没有提交的数据,那么另外一个事务读到的这个数据是“脏数据”,依据“脏数据”所做的操作可能是不正确的。
第二是不可重复读:比如在一个事务内多次读同一数据。在这个事务还没有结束时,另一个事务也访问该数据。那么,在第一个事务中的两次读数据之间,由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况,因此称为不可重复读。
第三是幻读(Phantom read
):幻读与不可重复读类似。它发生在一个事务(T1
)读取了几行数据,接着另一个并发事务(T2
)插入了一些数据时。在随后的查询中,第一个事务(T1
)就会发现多了一些原本不存在的记录,就好像发生了幻觉一样,所以称为幻读。
MySQL
的默认隔离级别是?解决方案是对事务进行隔离。
MySQL
支持四种隔离级别,分别有:
第一个是,未提交读(read uncommitted
)它解决不了刚才提出的所有问题,一般项目中也不用这个。第二个是读已提交(read committed
)它能解决脏读的问题的,但是解决不了不可重复读和幻读。第三个是可重复读(repeatable read
)它能解决脏读和不可重复读,但是解决不了幻读,这个也是mysql
默认的隔离级别。第四个是串行化(serializable
)它可以解决刚才提出来的所有问题,但是由于让是事务串行执行的,性能比较低。所以,我们一般使用的都是mysql
默认的隔离级别:可重复读。
undo log
和redo log
的区别?其中redo log
日志记录的是数据页的物理变化,服务宕机可用来同步数据,而undo log
不同,它主要记录的是逻辑日志,当事务回滚时,通过逆操作恢复原来的数据,比如我们删除一条数据的时候,就会在undo log
日志文件中新增一条delete
语句,如果发生回滚就执行逆操作;
redo log
保证了事务的持久性,undo log
保证了事务的原子性和一致性。
MVCC
)事务的隔离性是由锁和mvcc
实现的。
其中mvcc
的意思是多版本并发控制。指维护一个数据的多个版本,使得读写操作没有冲突,它的底层实现主要是分为了三个部分,第一个是隐藏字段,第二个是undo log
日志,第三个是readView
读视图。
隐藏字段是指:在mysql
中给每个表都设置了隐藏字段,有一个是trx_id
(事务id
),记录每一次操作的事务id
,是自增的;另一个字段是roll_pointer
(回滚指针),指向上一个版本的事务版本记录地址。
undo log
主要的作用是记录回滚日志,存储老版本数据,在内部会形成一个版本链,在多个事务并行操作某一行记录,记录不同事务修改数据的版本,通过roll_pointer
指针形成一个链表。
readView
解决的是一个事务查询选择版本的问题,在内部定义了一些匹配规则和当前的一些事务id
判断该访问那个版本的数据,不同的隔离级别快照读是不一样的,最终的访问的结果不一样。如果是rc
隔离级别,每一次执行快照读时生成ReadView
,如果是rr
隔离级别仅在事务中第一次执行快照读时生成ReadView
,后续复用。
MySQL
主从同步原理 ?MySQL
主从复制的核心就是二进制日志(DDL
(数据定义语言)语句和DML
(数据操纵语言)语句),它的步骤是这样的:
第一:主库在事务提交时,会把数据变更记录在二进制日志文件Binlog
中。
第二:从库读取主库的二进制日志文件Binlog
,写入到从库的中继日志Relay Log
。
第三:从库重做中继日志中的事件,将改变反映它自己的数据。
MySQL
的分库分表吗?因为我们都是微服务开发,每个微服务对应了一个数据库,是根据业务进行拆分的,这个其实就是垂直拆分。
这个是使用过的,我们当时的业务是(xxx
),一开始,我们也是单库,后来这个业务逐渐发展,业务量上来的很迅速,其中(xx
)表已经存放了超过1000万的数据,我们做了很多优化也不好使,性能依然很慢,所以当时就使用了水平分库。
我们一开始先做了3台服务器对应了3个数据库,由于库多了,需要分片,我们当时采用的mycat
来作为数据库的中间件。数据都是按照id
(自增)取模的方式来存取的。
当然一开始的时候,那些旧数据,我们做了一些清洗的工作,我们也是按照id取模规则分别存储到了各个数据库中,好处就是可以让各个数据库分摊存储和读取的压力,解决了我们当时性能的问题。
MySQL
支持哪些存储引擎?MySQL
支持多种存储引擎,比如InnoDB
、MyISAM
、Memory
、Archive
等等.在大多数的情况下,直接选择使用 InnoDB
引擎都是最合适的,InnoDB
也是MySQL
的默认存储引擎。
MyISAM
和InnoDB
的区别有哪些:
InnoDB
支持事务,MyISAM
不支持InnoDB
支持外键,而MyISAM
不支持InnoDB
是聚集索引,数据文件是和索引绑在一起的,必须要有主键,通过主键索引效率很高;MyISAM
是非聚集索引,数据文件是分离的,索引保存的是数据文件的指针,主键索引和辅助索引是独立的。Innodb
不支持全文索引,而MyISAM
支持全文索引,查询效率上MyISAM
要高;InnoDB
不保存表的具体行数,MyISAM
用一个变量保存了整个表的行数。MyISAM
采用表级锁(table-level locking
);InnoDB
支持行级锁(row-level locking
)和表级锁,默认为行级锁。超键:在关系中能唯一标识元组的属性集称为关系模式的超键。一个属性可以为作为一个超键,多个属性组合在一起也可以作为一个超键。超键包含候选键和主键。
候选键:是最小超键,即没有冗余元素的超键。
主键:数据库表中对储存数据对象予以唯一和完整标识的数据列或属性的组合。一个数据列只能有一个主键,且主键的取值不能缺失,即不能为空值(Null
)。
外键:在一个表中存在的另一个表的主键称此表的外键。
SQL
约束有哪几种?NOT NULL
: 用于控制字段的内容一定不能为空(NULL
)。
UNIQUE
: 控件字段内容不能重复,一个表允许有多个Unique
约束。
PRIMARY KEY
: 也是用于控件字段内容不能重复,但它在一个表只允许出现一个。
FOREIGN KEY
: 用于预防破坏表之间连接的动作,也能防止非法数据插入外键列,因为它必须是它指向的那个表中的值之一。
CHECK
: 用于控制字段的值范围。
MySQL
中的varchar
和char
有什么区别?char
是一个定长字段,假如申请了char(10)
的空间,那么无论实际存储多少内容。该字段都占用 10 个字符,而 varchar
是变长的,也就是说申请的只是最大长度,占用的空间为实际字符长度+1
,最后一个字符存储使用了多长的空间。
在检索效率上来讲,char
> varchar
,因此在使用中,如果确定某个字段的值的长度,可以使用char
,否则应该尽量使用 varchar
。例如存储用户MD5
加密后的密码,则应该使用char
。
MySQL
中in
和exists
区别?MySQL
中的in
语句是把外表和内表作hash
连接,而exists
语句是对外表作loop
循环,每次loop
循环再对内表进行查询。一直大家都认为exists
比in
语句的效率要高,这种说法其实是不准确的。这个是要区分环境的。
如果查询的两个表大小相当,那么用in
和exists
差别不大。
如果两个表中一个较小,一个是大表,则子查询表大的用exists
,子查询表小的用in
。
not in
和not exists
:如果查询语句使用了not in
,那么内外表都进行全表扫描,没有用到索引;而not extsts
的子查询依然能用到表上的索引。所以无论那个表大,用not exists
都比not in
要快。
drop
、delete
与truncate
的区别?