作为一个后端工程师,想必没有人没用过数据库,跟我一起复习一下MySQL吧,本文是我学习《MySQL实战45讲》的总结笔记的第一篇,总结了MySQL的基础架构、一个查询语句的执行过程 以及 一条更新语句的执行过程。
当我们需要修改一个记录时,数据库会先根据条件找到要修改的数据,然后执行修改写入操作,因此我们再分析写操作的执行过程时,其实是包含读语句的执行过程的。
需要注意的是,查询的执行顺序可能会因查询的复杂性、索引的存在与否、表的大小以及其他因素而有所不同。MySQL的查询优化器会尽力选择最佳的执行计划,以提高查询性能。同时,可以使用EXPLAIN语句来查看MySQL执行查询时选择的执行计划,以帮助调优查询性能。
首先有一个 user_info 表,表里有一个 id 字段,执行下面这条查询语句:
mysql-client: 比如一个命令行,或者使用java的JDBC发送sql语句
查询缓存: 执行查询语句的时候,会先查询缓存(MySQL 8.0 版本后移除,因为这个功能不太实用)。
上期文档中我们让mysql开启慢查询日志,收集查询时间比较长的sql,进而通过explain指令查询sql的执行过程,explain能够查看sql是那种数据查询方式以及索引情况。但是有时候使用explain还是无法定位到问题sql,所以在mysql5.037版本之后新增了show profiles和show profile语句的支持,通过hava_profileing指令可以查看当前sql是否支持profiles。
很多人都在使用mysql数据库,但是很少有人能够说出来整个sql语句的执行过程是怎样的,如果不了解执行过程的话,就很难进行sql语句的优化处理,也很难设计出来优良的数据库表结构。这篇文章主要是讲解一下sql语句的执行过程。
连接器会校验你输入的用户名和密码是否正确,如果错误会返回提示,如果正确,连接器会查询当前用户对于的权限。连接器的作用就是校验用户权限
简单查询语句执行过程分析,是 MySQL 执行过程分析系列文章的基础,会对查询语句执行过程中各个阶段进行比较详细的分析。原本是计划写成一篇文章的,但是这样一来文章的内容就会很长,不利于阅读,经过一番考虑之后,计划把 MySQL 简单查询语句执行过程分析按执行阶段拆分为 6 篇文章,本文是第 1 篇。
在这种建表语句中不用过度注重细节,只需要知道 id 是主键,并且在user_name建了一个非主键的索引就行了。
索引在我们使用MySQL数据库时可以极大的提高查询效率,然而,有时候因为使用上的一些瑕疵就会导致索引的失效,无法达到我们使用索引的预期效果,今天介绍几种MySQL中几种常见的索引失效的原因,可以在以后的工作中尽可能避免因索引失效带来的坑。
在过去的半年时间里,研发团队内部尝试抓了一波儿慢查询SQL跟进处理率。发现有些同学对于慢查询处理的思路就是看看有没有用到索引,没有用到就试图加一个,实在不行就甩锅给这种情况是历史设计问题或者自行判定为用户特殊操作下触发的小概率事件,随即便申请豁免掉... 其实问题没有根本上解决。
趁着这几天过节,复盘了一下去年的一些历史遗留问题,其中有这样一个关于数据库的小问题让我忍不住翻出来又回味了一下,下面就让我们一起品味品味。
索引条件下推,也叫索引下推,英文全称Index Condition Pushdown,简称ICP。
本文是 MySQL 简单查询语句执行过程分析 6 篇中的第 3 篇,第 1 ~ 2 篇请看这里: MySQL 简单查询语句执行过程分析(一)词法分析 & 语法分析 MySQL 简单查询语句执行过程分析(二)查询准备阶段
我们经常说,看一个事儿千万不要直接陷入细节里,你应该先鸟瞰其全貌,这样能够帮助你从高维度理解问题。同样,对于 MySQL 的学习也是这样。平时我们使用数据库,看到的通常都是一个整体。比如,你有个最简单的表,表里只有一个 ID 字段,在执行下面这个查询语句时:
前言:MySQL在我们的开发中基本每天都要面对的,作为开发中的数据中间件,MySQL承担者存储数据和读写数据的职责。因为学习和了解MySQL是至关重要的,那么当我们在客户端发起一个sql到出现详细的查询数据,这其中究竟经历了什么样的过程?MySQL服务端是如何处理请求的,又是如何执行sql语句的?本篇博客将来探讨这个问题:
在一些业务场景中,会使用NOT EXISTS语句确保返回数据不存在于特定集合,部分同事会发现NOT EXISTS有些场景性能较差,甚至有些网上谣言说”NOT EXISTS不走索引”,哪对于NOT EXISTS语句,我们如何优化呢?
来跟你聊聊 MySQL 的基础架构。我们经常说,看一个事儿千万不要直接陷入细节里,你应该先鸟瞰其全貌,这样能够帮助你从高维度理解问题。同样,对于 MySQL 的学习也是这样。平时我们使用数据库,看到的通常都是一个整体。比如,你有个最简单的表,表里只有一个 ID 字段,在执行下面这个查询语句时:
熟悉MySQL的都知道MySQL服务端实现主要分为Server层和存储引擎层。Server层负责接收和管理客户端连接、管理缓存、解析SQL、优化SQL、调用存储引擎执行SQL;存储引擎层主要负责存储、查询数据。
本文是 group by 实现过程分析的第 2 篇文章,第 1 篇是 MySQL 怎么用索引实现 group by? <- 点击阅读
我们经常说,看一个事儿千万不要直接陷入细节里,应该先鸟瞰其全貌,这样能够帮助你从高维度理解问题。同样,对于 MySQL 的学习也是这样。平时我们使用数据库,看到的通常都是一个整体。比如,你有个最简单的表,表里只有一个 ID 字段,在执行下面这个查询语句时:
上一篇学习了 SQL 的执行过程,这一篇主要的学习内容就在其基础上新增了一个重要的知识点,日志系统。
支持innodb, myisam, memory, MySQL5.5.5 以后默认innodb,不同存储引擎的表数据存取方式也不同
server层:(所有跨存储引擎的操作均在这一层完成,包含下面mysql核心功能及内置函数均在这一层完成)
关于In与Exists的比较,先说结论,归纳出IN 和Exists的适用场景: 1)IN查询在内部表和外部表上都可以使用到索引。 2)Exists查询仅在内部表上可以使用到索引。 3)当子查询结果集很大,而外部表较小的时候,Exists的Block Nested Loop(Block 嵌套循环)的作用开始显现,并弥补外部表无法用到索引的缺陷,查询效率会优于IN。 4)当子查询结果集较小,而外部表很大的时候,Exists的Block嵌套循环优化效果不明显,IN 的外表索引优势占主要作用,此时IN的查询
写在前面:2020年面试必备的Java后端进阶面试题总结了一份复习指南在Github上,内容详细,图文并茂,有需要学习的朋友可以Star一下! GitHub地址:https://github.com/abel-max/Java-Study-Note/tree/master
大体来说,MySQL 可以分为 Server 层和存储引擎层两部分,不同的存储引擎共用一个 Server 层。
MySQL在我们的开发中基本每天都要面对的,作为开发中的数据的来源,MySQL承担者存储数据和读写数据的职责。因为学习和了解MySQL是至关重要的,那么当我们在客户端发起一个SQL到出现详细的查询数据,这其中究竟经历了什么样的过程?MySQL服务端是如何处理请求的,又是如何执行SQL语句的?本篇博客将来探讨这些问题。
MySQL是一种关系型数据库管理系统,关系数据库将数据保存在不同的表中,而不是将所有数据放在一个大仓库内,这样就增加了速度并提高了灵活性。
今天来讲讲 MySQL 索引的相关问题,谈到索引,其实算是有个非常有深度的问题,本人才疏学浅,能力有限,理解不当之处,请各位大佬批评指正!不胜感激;
建表sql大家也不用扣细节,只需要知道id是主键,并且在user_name建了个非主键索引就够了,其他都不重要。
当我们对一张数据表中的记录进行统计的时候,习惯都会使用 count 函数来统计,但是 count 函数传入的参数有很多种,比如 count(1)、count(*)、count(字段) 等。
原子性是指事务包含的所有操作要么全部成功,要么全部失败回滚。失败回滚的操作事务,将不能对事物有任何影响。
在上一篇《面试官:你说说一条查询SQL的执行过程?》中描述了Mysql的架构分层,通过解析器、优化器和执行引擎完成一条SQL查询的过程,那这一篇续上继续说明一条更新SQL的执行过程。
create procedure name(IN | OUT |INOUT str STRING) #定义存储过程名字
MySQL 临时表分为两种:外部临时表、内部临时表。用户通过 CREATE TEMPORARY TABLE 创建的是外部临时表。SQL 语句执行过程中 MySQL 自行创建的是内部临时表,explain 输出结果的 Extra 列出现了 Using temporary 就说明 SQL 语句执行时使用了内部临时表。
首先,我们先来看看MySQL的基础架构,我们再平时写的最多的也就是 sql 查询语句,那么,对于一条简单的查询语句,你可否有想过它是如何执行的,期间又经历了哪些步骤呢?如下sql 查询:
在系统设计和架构中,数据库是必不可少的一环。而优化数据库查询效率也是非常重要的一环。MySQL是一个流行的关系型数据库管理系统。本文将介绍MySQL中的执行计划,以及如何使用执行计划来优化查询效率。
当客户端(应用)连接到MySQL服务器时,服务器需要对其进行认证。认证基于用户名、原始主机信息和密码。
经常有同学疑问,为什么有时候一个SQL语句使用了索引,为什么还是会进入到慢查询之中呢?今天我们就从这个问题开始来聊一聊索引和慢查询。
在当今这个互联网的时代无非要解决两大难题,其一是信息安全,其二就是数据的存储。而信息安全则是在数据存储的基础之上。一个公司从刚开始成立到发展成一个有上百人甚至上千人团队的时候,公司的业务量是呈上升趋势,客户及用户也会越来越多;之前设计的表结构可能会显得不合理,表与表之间的联系没有一个稳定的业务功能划分,从而表现出来的是相关表的备用字段越来越不够用甚至新加字段,最坏的情况就是不同业务表之间会有数据冗杂。从而暴露出一些设计的问题,这也就是SQL优化点之一:数据库表结构设计的合理性。近年来大数据越来越火,而大数据也是为了解决数据的存储的手段之一,其目的是从海量的数据中收集到有价值的信息然后存储到数据库中,因为数据量大传统的数据库无法储存那么多的信息所以需要分析有价值的信息后再做决定是否持久化。
最近在刷LeetCode中数据库题目时,有一道排名题目,用了6种写法分别代表6种SQL思维来实现,想想也算是有趣。
连接到数据库,负责跟客户端建立连接、获取权限、维持和管理连接,命令通常是mysql -h$ip -P$port -u$user -p.
首先SQL判断一个语句是不是慢查询语句,用的是语句的执行时间。他把语句执行时间跟long_query_time这个系统参数作比较,如果语句执行时间比它还大,就会把这个语句记录到慢查询日志里面,这个参数的默认值是10秒。当然在生产上,我们不会设置这么大,一般会设置1秒,对于一些比较敏感的业务,可能会设置一个比1秒还小的值。
最近在写SQL语句时,对选择IN 还是Exists 犹豫不决,于是把两种方法的SQL都写出来对比一下执行效率,发现IN的查询效率比Exists高了很多,于是想当然的认为IN的效率比Exists好,但本着寻根究底的原则,我想知道这个结论是否适用所有场景,以及为什么会出现这个结果。
经常有同学问我,我的一个SQL语句使用了索引,为什么还是会进入到慢查询之中呢?今天我们就从这个问题开始来聊一聊索引和慢查询。
领取专属 10元无门槛券
手把手带您无忧上云