文章目录
- 关系型数据库的主要考点
- 架构
- 1.怎么设计一个关系型数据库?
- 1.1什么是关系型数据库?
- 1.2关系型数据数据库的组成。
- 1.3如何设计一个关系型数据库?
- 1.4索引模块
- 索引
- 1.运用二分搜索树来创建索引。
- 2.运用AVL树和红黑树来创建索引。
- 3.运用B-Tree来创建索引。
- 4.运用B+树来创建索引(MySQL的索引结构)。
- 5.运用Hash来创建索引
- 6.SQL和NoSQL数据库的索引。
- 7.密集索引和稀疏索引的区别。
- 8.MySQL中的索引结构。
- 9.最左匹配原则
- 10.如何调优SQL
- 锁
- 1.锁的分类。
- 2.MyISAM与InnoDB在锁上的区别。
- 3.数据库事务的四大特性。
- 4.数据库事务的隔离级别以及各级别下并发访问的问题。
- 5.当前读和快照读,RR级别避免幻读的表象——MVCC。
- 6.RR级别如何真正避免幻读?(间隙锁)
- 其他常考点
- 1.MyISAM和InnoDB分别适用的场景
- 2.数据库三大范式
- 3.索引失效的情况
- 4.mysql怎么处理死锁
- 5.SQL字段的执行顺序
关系型数据库的主要考点
- 架构
- 索引
- 锁
架构
1.怎么设计一个关系型数据库?
1.1什么是关系型数据库?
关系型数据库,是指采用了关系模型来组织数据的数据库,其以行和列的形式存储数据,以便于用户理解,关系型数据库这一系列的行和列被称为表,一组表组成了数据库。用户通过查询来检索数据库中的数据,而查询是一个用于限定数据库中某些区域的执行代码。关系模型可以简单理解为二维表格模型,而一个关系型数据库就是由二维表及其之间的关系组成的一个数据组织。
1.2关系型数据数据库的组成。
一个关系型数据库是由两部分组成,一部分是,另一部分是。
RDBMS的全拼是Relational Database Management System,从字面上可以理解为关系数据库管理系统。可以简单理解为为是关系型数据库中的管理系统,也可以认为是一个程序实例,用来跟用户进行交互和数据的操作,将物理存储映射成逻辑结构。
存储系统即文件系统,即将数据以文件的形式持久化存储进硬盘(SSD,机械硬盘)中。
1.3如何设计一个关系型数据库?
1.:对数据的格式和文件分割进行管理,把物理数据通过逻辑结构标示出来。在这一模块中,还需要对存储效能进行优化,因为磁盘的IO速度很低,不能在磁盘上做数据的处理,需要将数据读取到内存当中进行处理,为了提高效率就需要尽量减少磁盘的IO次数。在进行磁盘IO的时候,读取一行数据和多行数据所消耗的时间是差不多的,所以行就失去了意义。在关系型数据库中,一般将页和块作为逻辑存储单位,块和页中存放多行数据,每次IO加载多个块到内存当中来提高效率。
2.:为了更好更快地对数据文件进行操作,需要引入缓存机制,将取出的数据块放入缓存中,下次程序再次使用就可以直接从内存中返回而不是对磁盘进行IO。缓存管理有许多种算法, 有一种思想是一旦某行数据被访问了,那么它附近的数据也极有可能在最近的访问中被访问到。
3.:在外界对数据库进行操作时,是需要使用SQL语句的,SQL解析模块负责将SQL语句解析编译成机器能识别的语言,并对数据进行操作。如果想要提升SQL效率,可以将SQL语句编译之后存到缓存当中,方便下次使用的时候直接解析即可。
4.:对数据库的操作需要记录下来,方便做数据库的主从同步和数据恢复。
5.:需要给用户数据管理的私密空间,按照权限划分,给不同用户不同的操作级别。
6.:数据库挂了需要恢复,怎么恢复,恢复到什么程度,需要设计。
7.:为了提升查询数据的速度,需要引入索引模块。
8.:为了让数据库支持并发,需要引入锁管理模块。
1.4索引模块
1.4.1 为什么要使用索引?
如果说没有索引的话,我们从数据库中查询数据需要对数据库进行全表扫描来查询所需的数据,将整张表的数据全部或者分批次加载到内存当中,找到我们需要的数据并返回。这种方式非常的慢,数据量小还可以,数据量大之后就不能用了,所以我们需要避免全表扫描的情况,引入索引机制。
索引的灵感来自于字典,在字典的检索目录中,我们将文字的关键信息组织起来,比如偏旁和部首,查询的时候根据偏旁或者部首找到对应的页码,就快速找到了我们想要的数据。数据库也一样,将关键信息放在索引中,快速找到数据所在的内存地址来获取数据。
1.4.2 什么样的信息适合作为索引?
能把该记录限定到一定范围内的字段,就适合用来作为索引,比如主键、唯一建和其他普通键都可以。索引的设置也需要进行相应的考虑,不是所有的字段作为索引都很高效。
1.4.3 索引的数据结构选择
有了关键字还不足以成为一个索引系统,关键是利用什么样的逻辑结构将关键字组织起来,让我们的检索变得高效。这就需要选择一种合适的数据结构了。具体的数据结构论述将在章节2中进行阐述。
索引
1.运用二分搜索树来创建索引。
二分搜索树是一种常用的树状数据结构,又称为BST。在树形态比较平衡的情况下,BST的搜索效率可以达到O(logN)级别,搜索的时间和树的层数成正比。所以我们可以利用BST来为数据库建立索引模块。
具体的实现就是,可以将索引的关键字信息挂到BST上,根据大小关系在BST中进行搜索,BST的每个节点存储着关键字对应数据的物理内存地址,搜索到所需关键字之后,根据指针去内存中拿到整个数据。也可以将数据和索引一起挂在BST的节点上,直接返回即可。
BST虽然简单,查询效率也高,但是有一个致命的问题是BST有可能会退化成一条链表,所有的节点都挂在根结点的右子树或者全部挂在左子树上,此时查询效率就会退化成O(N)级别,和全表扫描一样了。所以我们需要更稳定的索引结构,此时AVL树和红黑树就跳进了我们的脑海。
2.运用AVL树和红黑树来创建索引。
3.运用B-Tree来创建索引。
- 每个节点最多拥有m个子节点且m>=2,空树除外。
- 除根节点外每个节点的关键字数量大于等于ceil(m/2)-1,小于等于m-1,非根节点关键字数必须>=2。
- 所有叶子节点均在同一层、叶子节点除了包含了关键字和关键字记录的指针外也有指向其子节点的指针只不过其指针地址都为null对应下图最后一层节点的空格子。
- 如果一个非叶节点有n个子节点,则该节点的关键字数等于n-1。
- 所有节点关键字是按递增次序排列,并遵循左小右大原则。
4.运用B+树来创建索引(MySQL的索引结构)。
B+树是B树的一个升级版,相对于B树来说B+树更充分的利用了节点的空间,让查询速度更加稳定,其速度完全接近于二分法查找。
- B+跟B树不同B+树的非叶子节点不保存关键字记录的指针,只进行数据索引,这样使得B+树每个非叶子节点所能保存的关键字大大增加。
- B+树叶子节点的关键字从小到大有序排列,左边结尾数据都会保存右边节点开始数据的指针。
- 非叶子节点的子节点数=关键字数(来源百度百科)(根据各种资料这里有两种算法的实现方式,另一种为非叶节点的关键字数=子节点数-1(来源维基百科),虽然他们数据排列结构不一样,但其原理还是一样的Mysql的B+树是用第一种方式实现)。
- 由于非叶子节点不存储数据只存储索引,使得B+树的非叶子节点可以保存更多的索引关键字,而在磁盘IO中,为了满足局部性原理,会给每个节点分配一页的存储容量,这就保证了单词IO中可以有更多的检索信息,减少了查找时的磁盘IO次数。
- B+树必须查找到叶子节点才能拿到命中数据,而B树在非叶子节点也可能命中数据,所以B树的查询效率没有B+树稳定,而B+树的高度一般都比B树低。
- B+树的叶子节点使用链表链接,这样如果我们需要进行遍历或者全表扫描的时候可以直接对叶子节点遍历即可,B树则需要从根结点进行层层遍历。
- B+树可以进行区间查找,B树则无法进行区间查找。
5.运用Hash来创建索引
- 仅仅能满足单条数据的查询,比如“=”,“in”,无法进行范围查询。
- 无法避免数据的排序操作。
- 如果一些关键字无法进行一致的哈希运算,就不能用来当做索引。
6.SQL和NoSQL数据库的索引。
SQL数据库主要指关系型数据库,比如MySQL,SQL Server等。NoSQL数据库泛指非关系型数据库,比如MongoDB,Redis等。
SQL数据存在特定结构的表中,而NoSQL则更加灵活和可扩展,存储方式可以省是JSON文档、哈希表或者其他方式。这就导致了SQL经常需要进行遍历操作,而NoSQL可以将索引和结果数据聚合在一起。比如在MySQL中,我们有两个表,一个存储学生信息,一个表存储班级,我们想要获取1班中有几个学生,就需要先在班级表中查到1班的id,然后去学生表中遍历班级id为1班的数量。而MongoDB中,可以在一个集合中,将1班的所有同学聚合在班级表中,一次查询直接返回所有学生数即可。
根据之前介绍的B数和B+树的区别,不难想到,NoSQL数据库由于索引和数据聚合在一起,而且一般都是单一查询,所以使用B树作为存储结构更为合适,因为B树就是索引和数据聚合在一起的结构。
7.密集索引和稀疏索引的区别。
- 密集索引的叶子节点。
- 一个表只能创建一个密集索引,因为物理排列顺序只能有一种,密集索引的索引项和物理地址是顺序对应的。
- 稀疏索引的叶子节点。
8.MySQL中的索引结构。
MySQL中的索引结构和存储引擎有关
- MyISAM引擎的索引结构。
- MyISAM引擎中,不管是主键索引还是普通索引都是。
- MyISAM中,表数据和索引是分开存储的。B+树的叶子结点存储了索引信息和数据地址信息。
- InnoDB引擎的索引结构。
- 。
- InnoDB中主键索引和数据是存储在同一页文件中的,加载叶子节点进入内存时,数据也被加载了进去。
- InnoDB在进行稀疏索引查询时,首先需要在附注索引中定位到主键信息,再去主键索引中查询该条信息。
- 二者的索引表分布如下图所示,InnoDB是一种聚簇分布,MyISAM是一种非聚簇分布:
- InnoDB额外的知识:
- 若一个主键被定义,该主键则作为密集索引。
- 若没有主键被定义,该表的第一个唯一非空索引作为密集索引。
- 若不满足上述条件,InnoDB内部会生成一个隐藏主键作为密集索引。
- 非主键索引存储相关键位和数据对应的主键值,需要进行两次查找。
9.最左匹配原则
- 可以看出,联合索引其实是根据索引的最左字段来创建索引树的,在这里就是col3,也就是姓名列,而在姓名的基础上,联合索引会根据后续的索引值,对其进行排序。
- MySQL建立联合索引去查询时,第一位索引是绝对有序的,比如上图,联合索引col3,col2,查询时,B+树会按照col3进行查询,排序,然后查到的内容中再按照col2去排序,所以没有col2可以走联合索引,没有col3就没办法走联合索引。
:MySQL会从最左索引开始,一直向右匹配索引,知道遇到范围查询(>, <, between, like)就停止匹配。
- 比如建立联合索引,那么必须要有a索引,才可能匹配该联合索引,如 是完全匹配上该联合索引的,如果没有a索引,如 是无法使用该联合索引的。这一点从联合索引的介绍中可以发现,建立联合索引去查询时,第一位索引是绝对有序的,如果不提供第一索引位信息,是无法进行后续查询的。
- 建立联合索引,如果使用 ,其中c索引位使用了范围查询,那么索引匹配只到c为止,d是是用不上索引的,此时索引位为。其原理也很容易理解,由于d索引是在c索引确定后在其基础上进行排序的,如果c索引是一个范围,那么d索引无法利用索引排序进行查询。
- 其中,和是可以乱序的,比如可以匹配联合索引,这是因为MySQL的查询优化器会自动优化成索引可以识别的形式,也就是 。
10.如何调优SQL
这个问题是一种经验问题,具体场景需要具体分析,这里可以抽象出大致的优化思路:
- 根据慢日志定位查询SQL语句:
1.1 使用语句打开慢日志查询。
1.2 使用语句设定定义为慢查询SQL的时间,其中为自定义数字,单位为秒。
1.3 使用和来查询慢查询的关键信息 - 定位到慢查询语句之后,利用关键字对其进行分析
2.1 的SQL语句并不会真正的运行,只是分析
2.2 explain的结果中,比较关键的两个字段,一个是,一个是。 - 分析出SQL语句的问题之后,对SQL语句进行修改与优化,最好使其走索引。
锁
1.锁的分类。
数据库中锁的分类按照不同的划分方式,可以分为以下几种:
- 按照锁的粒度划分:可分为、和。
- 表级锁是锁住整张表,行级锁是锁住影响的数据行,页级锁介于行级锁和表级锁之间,一次锁定相邻的一组记录。
- 按照锁的级别划分:可分为、。
- 共享锁有些地方也称为读锁,因为数据库读事务会给行或者表上共享锁,此时别的读事务也可以给上了共享锁的数据继续上共享锁,也就是共享锁和共享锁兼容。
- 排它锁也被称为写锁,因为数据库修改事务会给行或者表上排它锁,此时别的事务无法再操作上了排它锁的数据,因为排它锁和其他的锁互斥,所以也叫互斥锁。
- 按照加锁方式划分:可分为、。
- 自动锁就是自动上锁,比如在数据库中执行select语句的时候,会自动上共享锁,不需要显示调用。
- 显示锁就是手动上锁,比如在数据库中执行select语句的时候,可以在语句最后显示加上lock in share mode,或者for update,会分别给数据上共享锁或者排它锁。这是一种显示的上锁方式。
- 按照操作划分:可分为、。
- 按照使用方式划分:可分为、。
- 乐观锁和Java多线程中的乐观锁思想其实是一样的,在数据库表中建立一个version字段,每次对数据进行修改时,为了防止发生冲突,先对version字段进行检查,再修改,修改成功version+1。这就是乐观锁的实现。
- 悲观锁其实就是利用数据库内置的排它锁。
2.MyISAM与InnoDB在锁上的区别。
- MyISAM引擎默认使用的是,不支持行级锁。
- MyISAM引擎在对表进行select查询时,会直接给表上一把读锁,也就是共享锁;在对表进行增删改的时候会给表上一把写锁,也就是互斥锁。
- 当表被读锁锁住的时候,另外的操作允许上读锁,但是上写锁会被block(阻塞)住,直到所有的锁释放为止。
- 当表被写锁锁住时,不允许另外的操作上任何锁,所有操作都会被阻塞,需要等锁的释放。
- select操作也可以通过显示的for update后缀操作上写锁。
- InnoDB引擎默认使用的是,也支持表级锁。
- 同MyISAM引擎一样,InnoDB读操作也是上读锁,增删改操作是上写锁。
- InnoDB中的锁,默认只锁住操作的数据行,未操作的数据行可以被另外的操作上锁。
- 除了用Id、主键索引以外的其他索引建,InnoDB会对涉及到的所有行上锁。
- 如果不走索引,InnoDB的锁会变成表级锁,锁住整张表。
3.数据库事务的四大特性。
数据库的四大特性为ACID,分别如下:
- (Atomic):指数据库事务作为一个整体被执行,要么全部执行,要么全部不执行。
- (Consistency):保证数据库状态从一个一致状态转变为另一个一致状态。
- (Isolation):多个事务并发执行时,一个事务的执行不应该影响其他事物的执行。
- (Durability):一个事务一但提交,对数据库的修改应当永久保存。
4.数据库事务的隔离级别以及各级别下并发访问的问题。
MySQL数据库事务的四大隔离级别如下:
- (Read Uncommitted):该隔离级别下,如果一个事务已经开始写数据,则不允许其他事务同时进行写操作,但允许其他事务读取正在写操作的数据。
- 隔离级别下,可能会出现的问题。脏读是指事务A读取了事务B已修改未提交的数据,而事务B随后回滚,就导致事务A读取到了错误的数据,成为脏读。
- (Read Committed):该隔离级别下,读取数据的事务允许其他事务继续访问该行数据,但是未提交的写事务将会禁止其它事务访问正在操作行数据。
- 隔离级别下,不会出现脏读问题,但是会出现问题。不可重复读是由于读取数据的事务允许其他事务继续访问该行数据,一个事务A在自己没有更新数据库数据的情况下,同一种查询操作执行两次或者多次获取到的结果不一致,因为别的事务B、C…在A查询的同时一直在对数据进行更新,并提交了事务。
- (Repeatable Read):该隔离级别下,读取数据的事务将会禁止写事务,但允许读事务,写事务则禁止其它任何事务。
- 隔离级别下,不会出现脏读和不可重复读问题,但是会出现问题。幻读有很多种解读说法,按照MySQL官方文档中的法,幻读是指读会读到上一次没有返回的数据,看起来像是幻影一般。也就是说事务A读取到了一个结果集,然后事务B向表中新增了一条数据,事务A再次读取结果集就发现数量增加了一条,这就是幻读。
- (Serializable):该隔离级别下,提供严格的事务隔离,将禁止并发执行,要求事务序列化执行,必须一个接一个执行。
- 隔离级别下,不会出现脏读、不可重复读和幻读问题,因为严格串行执行,虽然可靠性高,但是会降低并发操作的性能。
- MySQL默认的事务隔离级别是。
5.当前读和快照读,RR级别避免幻读的表象——MVCC。
上一节介绍中,在RR(可重复读)隔离级别下,会出现幻读的情况,MySQL也考虑到了这种情况并且给出了解决办法来尽量避免幻读现象的产生,那么到底是怎么解决的呢?首先是通过机制,利用快照读来一定程度上避免幻读。
- :多版本控制(Multiversion Concurrency Control),是一种提高并发的技术。MVCC解决幻读的方法就是利用undo log日志保存数据的多个版本,然后利用事务的id来创建快照,同一个事务中,事务只能看到其它事务在创建快照之前已经提交的修改(不管查询几次)和该事物本身提交的修改。
- :指读出的数据是数据库中的最新数据,加了锁的增删改查都是当前读,如,,和显式()。
- 为什么,,也是当前读呢?明明是写操作啊。以update为例,在其更新前,实际上会有一个当前读的操作,将数据的最新版本读取出来并进行修改,修改后再更新回数据库中。
- :指读出的数据是创建快照前的最新数据,普通的查询语句为快照读:。
- 的原理
- 首先,InnoDB存储引擎在数据库的每行数据后面添加了三个隐藏字段:
- :记录最近一次对本行数据进行修改(写操作)的事务ID。
- :一个回滚指针,指向上一次当前数据行的修改undo log信息。
- :随着新的数据行插入而单调递增的一个ID信息。(当InnoDB引擎没有指定主键并且没有唯一非空键的时候,就会调用这个ID信息作为自增聚簇索引键,这个字段和快照读的关系不大。)
- 当数据库进行了修改后,都会被记录在undo日志当中,这是一种老版本日志,包含两种,一种insert undo日志,记录事务的inset操作,只在回滚的时候需要;另外一种是update undo日志,不仅在回滚时需要,快照读也需要用到。
- RR隔离级别下,事务在开启后,第一次执行快照读,会创建一个快照(Read View),将当前系统中其他活跃的事务记录起来,以备快照读使用,此后该事物之后使用的都是此快照,直到事务结束。
- RC隔离级别下,事务在开启后,每次执行快照读,快照(Read View)都会被重置,即创建一个新的快照(Read View)。
- 当事务进行更新的时候,会将操作行的三个隐藏字段进行填充后记录到undo日志当中,如果进行了快照读,那么InnoDB会将该记录行的与Read View中的一些变量进行比较,然后只展现满足条件的数据。
- 比如事务A开始后,执行普通select语句,创建了快照;之后事务B执行insert语句;然后事务A再执行普通select语句,得到的还是之前B没有insert过的数据,因为这时候A读的数据是符合快照可见性条件的数据。这就防止了部分幻读,此时事务A是快照读。
- 事务更新undo日志的过程:
- 第一次修改:
- 再次修改:
- 虽然快照读利用MVCC和历史数据部分避免了幻读在一定程度上解决了幻读的问题,但还是,比如A事务在开启快照读之后,B事务进行了写操作插入了一个新行,然后A事务进行了update操作,此时A事务的update操作覆盖到了B事务刚插入的新行,那么A事务再次快照读就会读到这个新行,产生了幻读。
6.RR级别如何真正避免幻读?(间隙锁)
MySQL在RR级别下彻底解决幻读的方法其实还是加锁,RR级别下的当前读,利用了next-key锁,即行锁+gap锁来避免了幻读,加next-key锁需要显示进行调用,即使用语法进行上锁。
- 行锁在之前已经介绍过了,就是锁住正在操作的数据行。
- gap锁,又称为间隙锁,即锁住数据行之间的间隙,被锁住的gap无法**入新的数据,这就避免了幻读。gap锁会用在非唯一索引或者不走索引的当前读中,如下图所示:
在上图所示的表中,我们通过这个语句进行当前读的时候,由于id是非唯一键,为了防止幻读就会对如图所示的行间隙加gap锁。在当前事务未结束之前,其他事务不允许向间隙中添加数据。 - 如果对主键索引或者唯一键索引会使用gap锁么?如果where条件全部命中,就不会使用gap锁,只会加行锁,如下图所示:
此时当我们where id = 3 and id = 4完全命中时,只会加行锁,因为是唯一索引,其他事务无法添加id = 3或者id = 4的新纪录,所以不会出现幻读情况,就没有必要使用gap锁。 - 如果不走索引,那么Gap锁会锁住表的所有缝隙,这种情况比直接加表锁更降低性能。
其他常考点
1.MyISAM和InnoDB分别适用的场景
- MyISAM
- MyISAM引擎会使用一个变量保存表的行数,所以适合频繁执行全表count语句的场景。
- MyISAM引擎由于是表级锁,所以适用于查询非常频繁,增删改数据频率不高的场景。
- MyISAM不支持事务,所以适用于对事务无要求的场景。
- InnoDB
- InnoDB引擎不会保存表的行数,每次查询全表count都会要去扫描遍历表,虽然全表count效率不如MyISAM,但增删改效率比较高,所以适用于增删改查都相当频繁的场景。
- InnoDB支持事务,适用于可靠性要求比较高的场景。
2.数据库三大范式
- 第一范式(1NF):要求。比如下图的表结构就不满足第一范式,因为列中的数据还可以再分隔:
修改成下表就满足了第一范式: - 第二范式(2NF):第二范式需要确保(主要针对联合主键而言)。也就是说在一个数据库表中,一个表中只能保存一种数据,不可以把多种数据保存在同一张数据库表中。如下图表结构所示,由于一个订单号中可能包含几种产品号,所以主键为订单号和产品号联合组成,但是发现表中的订单金额和订单时间仅和订单号相关,与产品号无关,这就违反了第二范式。
此时需要对表进行拆分,拆分成下面两张表结构就满足了第二范式: - 第三范式(3NF):在2NF基础上,确保数据表中的每一列数据都和主键直接相关,而不能间接相关。比如下表结构,虽然满足第二范式,所有属性都依赖于学号,但是其中的“班主任性别”和“班主任年龄”直接依赖的是“班主任姓名”这一列,此时就违反了第三范式,需要对表进行拆分:
拆分成下面两张表结构,就满足了第三范式:
3.索引失效的情况
4.mysql怎么处理死锁
MySQL有两种死锁处理方式:
- 等待,直到超时(innodb_lock_wait_timeout=50s)。
- 发起死锁检测,主动回滚一条事务,让其他事务继续执行(innodb_deadlock_detect=on)。
由于性能原因,一般都是使用死锁检测来进行处理死锁。
如何避免发生死锁
收集死锁信息: - 利用命令 SHOW ENGINE INNODB STATUS查看死锁原因。
- 调试阶段开启 innodb_print_all_deadlocks,收集所有死锁日志。
减少死锁: - 使用事务,不使用 lock tables 。
- 保证没有长事务。
- 操作完之后立即提交事务,特别是在交互式命令行中。
- 如果在用 (SELECT … FOR UPDATE or SELECT … LOCK IN SHARE MODE),尝试降低隔离级别。
- 修改多个表或者多个行的时候,将修改的顺序保持一致。
- 创建索引,可以使创建的锁更少。
- 最好不要用 (SELECT … FOR UPDATE or SELECT … LOCK IN SHARE MODE)。
- 如果上述都无法解决问题,那么尝试使用 lock tables t1, t2, t3 锁多张表
解除正在死锁的状态有两种方法:
第一种:
1.查询是否锁表
show OPEN TABLES where In_use > 0;
2.查询进程(如果您有SUPER权限,您可以看到所有线程。否则,您只能看到您自己的线程)
show processlist
3.杀死进程id(就是上面命令的id列)
kill id
第二种:
1.查看下在锁的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;
2.杀死进程id(就是上面命令的trx_mysql_thread_id列)
kill 线程ID
例子:
查出死锁进程:SHOW PROCESSLIST
杀掉进程 KILL ;
其它关于查看死锁的命令:
1:查看当前的事务
SELECT * FROM INFORMATION_SCHEMA.INNODBjava基础数据管理_TRX;
2:查看当前锁定的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
3:查看当前等锁的事务
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
5.SQL字段的执行顺序
首先我是不是需要知道我要从哪个表去获取我想要的,也就是from;现在我知道从哪个表获取了,可是并不是这个表里面所有的信息都是我需要的,我需要把一些不需要的去掉(比如测试订单),或是把一些我需要的筛选出来,这就是where;现在我把我需要的订单明细筛选出来,可是我想要每个品类的订单量,这个时候是不是需要做一个分组聚合,也就是group by;分组聚合后的结果也并不是我们全部都要,我们只要大于10的品类,所以需要把大于10的筛选出来,非大于10的品类过滤掉,这就是having;现在我们想要的大部分信息都已经出来了,我们就可以用select把他们查询出来了;因为我们最后需要取前三的品类,所以我们需要把查询出来的结果进行一个降序排列,即order by;最后一步就是只把前三显示出来,做一个限制就行,也就是limit。
from-where-groupby-having-select-orderby-limit
版权声明:
本文来源网络,所有图片文章版权属于原作者,如有侵权,联系删除。
本文网址:https://www.bianchenghao6.com/h6javajc/20734.html