分析MySQL语句查询性能的方法除了使用 EXPLAIN 输出执行计划，还可以让MySQL记录下查询超过指定时间的语句，我们将超过指定时间的SQL语句查询称为“慢查询”。
学完数据库基础知识，要想更深入地了解数据库，就需要学习数据库进阶知识，今天我们就先来聊一聊慢SQL查询那些事儿。
由于没有安装pt-digest-query工具（不通外网有依赖装不了）就用mysql自带的mysqldumpslow分析
查看系统慢sql是否开启 //慢查询时间阈值 > show variables like '%long_query_time%'; //查看慢查询配置情况 > show status like '%slow_queries%'; // 查看慢日志路径 > show variables like '%slow%'; 开启慢日志 > set global slow_query_log=On; > set global long_query_time=1; //设置查看时间超过1秒的查询被记录到日志 > s
MySQL的慢查询日志是MySQL提供的一种日志记录，它用来记录在MySQL中响应时间超过阀值的语句，具体指运行时间超过long_query_time值的SQL，则会被记录到慢查询日志中。long_query_time的默认值为10，意思是运行10S以上的语句。默认情况下，Mysql数据库并不启动慢查询日志，需要我们手动来设置这个参数，当然，如果不是调优需要的话，一般不建议启动该参数，因为开启慢查询日志会或多或少带来一定的性能影响。慢查询日志支持将日志记录写入文件，也支持将日志记录写入数据库表。
当前，如果不是调优需要的话，一般不建议启动该参数，因为开启慢查询日志会对性能造成一定的影响，慢查询日志支持将日志记录到文件中
每一个SQL都需要消耗一定的I/O资源，SQL执行的快慢直接决定了资源被占用时间的长短。假设业务要求每秒需要完成100条SQL的执行，而其中10条SQL执行时间过长，从而导致每秒只能完成90条SQL，所有新的SQL将进入排队等待，直接影响业务，然后用户就各种投诉来了。
按i进入编辑模式 在[mysqld]末尾（注意不要添加到其他项的配置下了）增加以下配置
在项目里面，多多少少都隐藏着一些执行比较慢的SQL, 不同的开发测试人员在平时使用的过程中多多少少都能够遇到，但是无法立马有时间去排查解决。那么如果有一个文件能够将这些使用过程中比较慢的SQL记录下来，定期去分析排查，那该多美好啊。这种情况MySQL也替我们想到了，它提供了SQL慢查询的日志，本文就分享下如何使用吧。
导读 软件测试人员在工作使用SQL语言中的查询是使用得最多的，而查询也是SQL语言中最复杂的，很多测试人员只使用到其中最简单的查询 1.数据库的使用 现在在任何项目中都有数据的存在，那么在测试过程中查看数据库中的数据是必不可少的步骤，那什么情况下测试人员会查看数据库呢？ 比如有一个测试场景是注册新用户，用户在前端页面上添加了一个新用户，点击提交后，弹出提示用户注册成功。 这时预期结果中就应该包含查询数据库： 查询user表中新增一条数据，数据字段的信息与注册信息一致； 查询password表中新增一条数据
MySQL 的慢查询日志是MySQL提供的一种日志记录，他用来记录在MySQL中响应时间超过阀值的语句。
码农架构的读者应该注意到上个周末有分享一篇文章：一个几乎每个系统必踩的坑儿：访问数据库超时，最后对于怎么避免写出慢SQL没有过多赘述，但实际上这个问题我们经常遇到。我们不能等着系统上线，慢 SQL 吃光数据库资源之后，再找出慢 SQL 来改进，那样就晚了。那么，怎样才能在开发阶段尽量避免写出慢 SQL 呢？
mysql索引的本质是什么 1、其实就相当于目录，是帮助mysql高效获取数据的数据结构。 2、我们都知道，在mysql中数据最终存储在硬盘中的，访问磁盘相当于是IO操作。 3、在mysql中有一个page的概念，一个表都被分为若干个页面(page),每个页面(page)就是树中的一个节点，每次mysql就会取出一个页面(page)也就是一个节点的数据，而mysql默认一个页面(page)保存16k的数据。 4、页面(page)的大小会直接影响到数据的存储和检索效率，因此我们也可以实际业务需求和硬件条件进行评估和调整，合理设置mysql的页面(page)大小，以达到最佳的性能表现。
对于生产业务系统来说，慢查询也是一种故障和风险，一旦出现故障将会造成系统不可用影响到生产业务。当有大量慢查询并且SQL执行得越慢，消耗的CPU资源或IO资源也会越大，因此，要解决和避免这类故障，关注慢查询本身是关键。
2、在配置MySQL相关参数后，可以通过mysqldumpslow查找出查询较慢的SQL语句。
今天，数据库的操作越来越成为整个应用的性能瓶颈了，这点对于Web应用尤其明显。关于数据库的性能，这并不只是DBA才需要担心的事，而这更是我们程序员需要去关注的事情。当我们去设计数据库表结构，对操作数据库时（尤其是查表时的SQL语句），我们都需要注意数据操作的性能。这里，我们不会讲过多的SQL语句的优化，而只是针对MySQL这一Web应用最多的数据库。希望下面的这些优化技巧对你有用。
眼下用的最多的关系型数据库数MySql莫属了，之前也用过其它各种数据库。最近使用MySql一段时间了，突然好奇心下，想看看MySql到底性能如何？刚好最近手上有一份2000W的数据集，刚好拿过来练练手。
B+树是一种在非叶子节点存放排序好的索引而在叶子节点存放数据的数据结构，值得注意的是，在叶子节点中，存储的并非只是一行表数据，而是以页为单位存储，一个页可以包含多行表记录。非叶子节点存放的是索引键值和页指针。
是的，这是MYSQL的exists关键词，今天我们就来说说这个exist，为了给大家更清楚的讲解，先给大家说下本文目录：
MySQL 中的数据同样也是根据索引分类，通过索引可以快速高效的查询到我们想要的数据。
Mysql系列的目标是：通过这个系列从入门到全面掌握一个高级开发所需要的全部技能。
一、慢查询日志介绍 许多存储系统（例如MySQL）提供慢查询日志帮助开发和运维人员定位系统存在的慢操作。所谓慢查询日志就是系统在命令执行前后计算每条命令的执行时间，当超过预设阀值，就将这条命令的相关信息记录下来，Redis也提供了类似的功能 Redis的慢查询日志功能用于记录执行时间超过给定时长的命令请求，用户可以通过这个功能产生的日志来监视和优化查询速度 客户端命令执行步骤一般分为4步：发送命令、命令排队、命令执行、返回结果。慢查询只统计命令执行的时间的时间，所以没有慢查询并不代表客 户端没有超时问题
操作系统版本：CentOS Linux release 7.7.1908 (Core)
在MySQL中，我们可以通过EXPLAIN命令获取MySQL如何执行SELECT语句的信息，包括在SELECT语句执行过程中表如何连接和连接的顺序。
先看看具体有哪些字段： mysql> EXPLAIN SELECT 1; 其实除了以SELECT开头的查询语句，其余的DELETE、INSERT、REPLACE以及UPDATE语句前边都可以加上EXPLAIN这个词儿，用来查看这些语句的执行计划 建两张测试表： CREATE TABLE t1 ( id INT NOT NULL AUTO_INCREMENT, key1 VARCHAR(100), key2 VARCHAR(100), key3 VARCHAR(100),
监控系统监控到我们的程序变慢了，怀疑是sql的原因，要怎么去分析排查呢？一般按照如下几个步骤进行：
今天在说Mysql查询优化之前，我先说一个常见的面试题，并带着问题深入探讨研究。这样会让大家有更深入的理解。
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
对于我们这些MySQL的使用者来说，MySQL其实就是一个软件，平时用的最多的就是查询功能。DBA时不时丢过来一些慢查询语句让优化，我们如果连查询是怎么执行的都不清楚还优化个毛线，所以是时候掌握真正的技术了。我们在第一章的时候就曾说过，MySQL Server有一个称为查询优化器的模块，一条查询语句进行语法解析之后就会被交给查询优化器来进行优化，优化的结果就是生成一个所谓的执行计划，这个执行计划表明了应该使用哪些索引进行查询，表之间的连接顺序是啥样的，最后会按照执行计划中的步骤调用存储引擎提供的方法来真正的执行查询，并将查询结果返回给用户。不过查询优化这个主题有点儿大，在学会跑之前还得先学会走，所以本章先来瞅瞅MySQL怎么执行单表查询（就是FROM子句后边只有一个表，最简单的那种查询～）。不过需要强调的一点是，在学习本章前务必看过前边关于记录结构、数据页结构以及索引的部分，如果你不能保证这些东西已经完全掌握，那么本章不适合你。
CPU、内存、磁盘IO、网络作为性能优化的四大天王，但MySQL中一条查询语句的执行成本是由磁盘IO和CPU成本决定的：
在任何一种数据库中，都会有各种各样的日志，记录着数据库工作的方方面面，以帮助数据库管理员追踪数据库曾经发生过的各种事件。MySQL 也不例外，在 MySQL 中，有 4 种不同的日志，分别是错误日志、二进制日志（BINLOG 日志）、查询日志和慢查询日志，这些日志记录着数据库在不同方面的踪迹。
对于大多数中小型应用，最多和最明显的的性能问题应该是出自最底层的数据库，数据库的性能又很复杂，SQL优化，索引等等，
我们都知道，我们每执行一次 SQL，数据库除了会返回执行结果以外，还会返回 SQL 执行耗时，以 MySQL 数据库为例，当我们开启了慢 SQL 监控开关后，默认配置下，当 SQL 的执行时长大于 10 秒，会被记录到慢 SQL 的日志文件中。
索引是数据库提供的利于快速查询的机制，索引类似于书籍目录，当查询条件那一列建立了索引之后，那么数据库会去硬盘索引文件中找到满足查询条件的（数据的）物理位置， 根据位置就可以定位并获取到数据。
“ 在上一篇关系型数据库之MySQL的文章中，我们介绍了什么是关系型数据库以及MySQL查询优化的大体思路，那今天我们就针对具体的语句来看一下，如何优化MySQL的查询语句。”
索引的本质：通过不断地缩⼩想要获取数据的范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件，也就是说，有了这种索引机制，我们可以总是⽤同⼀种查找⽅式来锁定数据。磁盘中数据的存取
select ...from table where exist (子查询)；
在性能分析之SQL性能分析（mysql）文中，全面介绍了 MySQL 常见的性能分析工具。本文将以一个案例详细展开介绍如何针对单条SQL进行性能分析。
show variables like ‘%slow_query_log%’; #如果结果中包含slow_query_log | OFF ，则说明慢日志已经关闭 #开启慢查询日志的方式：set global slow_query_log=1;
Memory表支持 Hash索引，因此查找操作非常快。Memroy表是表级锁，因此并发写入的性能较低，每行的长度是固定的，可能导致部分内存的浪费。
在mysql中，索引就是帮助mysql快速找到某条数据的一种数据结构，它是排好序的，独立于mysql表数据之外的。
它能记录下所有执行超过longquerytime时间的SQL语句，帮我们找到执行慢的SQL，方便我们对这些SQL进行优化。
想必大家也听说过数据库单表建议最大2kw条数据这个说法。如果超过了，性能就会下降得比较厉害。
在 MySQL 的众多存储引擎中，InnoDB 是最常用的存储引擎，也是 MySQL 现阶段唯一免费支持事务机制的存储引擎。在本文中，我们以 InnoDB 为例，介绍 MySQL 的索引结构以及其使用 B+ 树实现索引的原因。
我有一个程序员朋友, 我们都叫他回龙观大叔, 因为他所在公司经营不善, 被动离职。我们一起听听他的故事.
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
