SQL 语句执行慢的原因是面试中经常会被问到的，对于服务端开发来说也是必须要关注的问题。
监控系统监控到我们的程序变慢了，怀疑是sql的原因，要怎么去分析排查呢？一般按照如下几个步骤进行：
其实最终的目的只有一个：如何使用性能分析工具定位SQL执行慢的原因？本篇主要是通过 如何使用 SHOW PROFILE 查看 SQL 的具体执行成本
MySQL 慢日志（slow log）是 MySQL DBA 及其他开发、运维人员需经常关注的一类信息。使用慢日志可找出执行时间较长或未走索引等 SQL 语句，为进行系统调优提供依据。 本文将结合一个线上案例，分析如何正确设置 MySQL 慢日志参数和使用慢日志功能，并介绍下网易云 RDS 对 MySQL 慢日志功能的增强。
工程师反馈数据库服务器内存使用率高，并且之前曾触发告警，登录服务器使用top -u mysql查看进程使用内存信息：
作为一个 DBA，想必都有过被慢查询折腾的经历，本文对常规和非常规手段进行了整理，由浅及深，简单介绍几个慢查询的分析手段。
可能是经常处理业务，最近总是听到开发的同学说SQL的查询慢。然后问我为什么，让我在数据库层面找原因。这样的需求接的多了，对于这类需求，我已经有了一套比较官方的回答思路，我来说，大家看，看看还有什么没有考虑到的地方，欢迎指正。
| 作者 王文安，腾讯CSIG数据库专项的数据库工程师，主要负责腾讯云数据库 MySQL 的相关的工作，热爱技术，欢迎留言进行交流。 ---- 作为一个 DBA，想必都有过被慢查询折腾的经历，一个慢查询有时候真的很让人抓狂，本文对常规和非常规手段进行了整理，由浅及深，简单介绍几个慢查询的分析手段。 需要说明的是，下面所有的手段都是原生支持的功能（≥MySQL 5.6），因此在各类 RDS 和原生数据库中都不会有什么使用上的差异，这里图方便就用腾讯云数据库 MySQL 来作为测试环境了，版本为 5.7。
线上有个定时任务，这个任务需要查询一个表几天范围内的一些数据做一些处理，每隔十分钟执行一次，直至成功。
作为后端开发，日常操作数据库最常用的是写操作和读操作。读操作我们下边会讲，这个分类里我们主要来看看写操作时为什么会导致 SQL 变慢。
上周五面试了字节的第三面，深感数据库知识的重要，我也意识到在平时的学习中，自己对于数据库的学习较为薄弱。甚至在有过一定实习经验之后，依旧因为开发分工的原因，对数据库方面的知识掌握依旧不多。我也相信，很多人对MySQL的 索引、 日志、 多版本并发控制、 ACID等等都只停留在八股文的阶段。
之前开发项目的过程当中数据库存储的数据量都不是很大，在表的设计当中就只有一个主键索引。很少接触到数据库的索引，SQL 优化这些东西。公司目前的项目数据达到了百万级别了，让我优化一下慢 SQL，之前是懂一些 SQL 优化和索引相关的理论知识，没有实际操作过，特此记录优化的过程和思路，事实证明，理论和实操还是有不少区别的。
昨天遇到一个问题, 200万的表里查询9万条数据, 耗时达63秒. 200万数据不算多, 查询9万也还好. 怎么用了这么长的时间呢? 问题是一句非常简单的sql. select * from tk_t
今天和同事处理了一个MySQL慢日志的问题，从这两天开始频繁收到一些报警信息，但是查看数据库端却没有任何异常。
某项目压测后发现qps达标，服务器cpu和内存占用均在70%以下，然而mysql服务的内存占用高达100%，且并没有因为压测而产生波动。
第3章 服务器性能剖析 优化的第一步应该是测量时间花在哪里。 对测试结果统计之后，对结果进行排序，把重要的任务排在前面。 如果优化的成本大于收益，就应该停止优化。 平均值在很多时候都隐藏了我们正在需要关注的地方。 虽然监控程序本身可能会拖慢程序，但是它对优化程序的贡献，是远远大于的其拖累的。 mysql慢查询日志可以帮助我们找到那些查询慢的语句。 利用pt-query-digest分析慢查询报告。 使用SHOW PROFILE 可以详细查看每条语句耗费时间的地方。 导致性能低下的原因有几种：资源被过度使用，
来源：juejin.im/post/5bcc2935f265da0ac66987c9
一、网络问题 1、临时性 检查：ping, mtr,dig,dig+trace 等命令，检查网络状况，DNS等 解决：联系机房或视具体情况而定 eg:http://ping.chinaz.com/ 查看各地响应时间 2、网络不同或距离太远 检查：客户端和机房所在网络情况 解决：双线机房或分布式部署，动态DNS，需要考虑成本 3、资源加载慢 检查：chrome控制台 解决：CDN，合并请求，压缩页面代码，多域名请求（http协议中有对浏览器并发请求连接数的限制，IE是10，火狐 chrome是6）等 二、前端
前几天，有位客户提了一个慢查询问题，需要这边帮忙分析一下；整个排查过程还是非常有趣，涉及到一些值得关注的知识点，因此在这里记录一下。
本文提要 从编码角度来优化数据层的话，我首先会去查一下项目中运行的sql语句，定位到瓶颈是否出现在这里，首先去优化sql语句，而慢sql就是其中的主要优化对象，对于慢sql，顾名思义就是花费较多执行时间的语句，它带来的影响也比较恶劣，首先是执行时间过长影响数据的返回速度，其次，慢sql的长时间执行也会消耗和占用mysql的系统资源，影响其他的sql语句执行，过多的慢sql极其影响性能，如果系统流量或者并发量较大的情况下，过多的执行慢sql很有可能造成mysql的死锁以致于mysql服务无法正常使用。 dr
在MySQL的日常维护中，我们总会遇到这样或那样的问题，对于那些经常发生且有处理经验的事故，不论是新手还是老司机都能在故障规定的容错时间内解决。而对于那些不常见、比较棘手的问题，新手上路可能就显得举足无措了，这个时候新手和老司机的差距就体现出来了。从知识储备还是工作经验，可能老司机比新手强一点，但如果一个新司机没有日志排错的意识，不具备日志排错的经验，那怎么能学会弯道超车、漂移的快感。我们知道数据库中有很多重要的日志，如错误日志error log、慢日志slow log、二进制日志binary log、查询日志general log等等其他日志，错误日志error log是我们分析问题参考的依据，它记录数据库的启动/运行/停止的过程，包含了info、warning、error三个级别，分析error log也有助于我们了解数据库的运行机制。
我们在开发的过程中使用分页是不可避免的，通常情况下我们的做法是使用limit加偏移量：select * from table where column=xxx order by xxx limit 1,20。当数据量比较小时（100万以内），无论你翻到哪一页，性能都是很快的。如果查询慢，只要在where条件和order by 的列上加上索引就可以解决。但是，当数据量大的时候（小编遇到的情况是500万数据），如果翻到最后几页，即使加了索引，查询也是非常慢的，这是什么原因导致的呢？我们该如何解决呢？
一、背景 我们在开发的过程中使用分页是不可避免的，通常情况下我们的做法是使用limit加偏移量：select * from table where column=xxx order by xxx limit 1,20。当数据量比较小时（100万以内），无论你翻到哪一页，性能都是很快的。如果查询慢，只要在where条件和order by 的列上加上索引就可以解决。但是，当数据量大的时候（小编遇到的情况是500万数据），如果翻到最后几页，即使加了索引，查询也是非常慢的，这是什么原因导致的呢？我们该如何解决呢？
我们在开发的过程中使用分页是不可避免的，通常情况下我们的做法是使用limit加偏移量：
以上的看似复杂的问题，如果转换成DSL，清楚的写出来，梳理清楚问题的来龙去脉，问题就自然解决了一大半。
大家好，我是程序员啊粥，这段时间一直在分享 MySQL 索引系列的文章，我们学会了索引模型 MySQL InnoDB 索引模型，以及和具体的索引使用原则等内容，今天开始我们学习 SQL 的优化。
最近迁移一个数据库，500多张表大概600多万条数据，通过navicat导出的数据，再通过source命令导入到mysql8.0
在执行select语句运行了100多秒然后现了lost connection to MySQL server during query错误信息 排查原因：
早上8:40左右，地铁上，在跟小伙伴聊天，接到电话“是不是服务出问题了？” 第一个反应，不可能吧。昨天又没有上线，前天刚优化过，并且又没有收到告警。
Mysql性能优化 Mysql的性能参数可以分为以下几个大类，这里仅整理一些常用的参数配置
谈到MySQL性能优化，查询优化作为优化的源头，它也是最能体现一个系统是否更快。 本章以及接下来的几章将会着重讲解关于查询性能优化的内容，从中会介绍一些查询优化的技巧，帮助大家更深刻地理解MySQL如何真正地执行查询、究竟慢在哪里、如何让其快起来，并明白高效和低效的原因何在，这样更有助于你更好的来优化查询SQL语句。
1、先查看了一下慢日志中的内容，发现慢日志中没有具体的记录。这个问题比较好解决，其实他的本质是设定的慢日志的阈值是1s，只有超过1s的SQL语句才会被记录，这里我把参数long_query_time的值设置成为0.4，这样，就可以把查询超过0.4s的SQL都记录到慢日志里面了。
在实际MySQL业务中，一般会先验证sql有没有问题，如果没有问题，再写业务代码。实际ES业务中，也一样，先DSL确认没有问题，再写业务代码。
爱可生交付服务部南区团队 DBA，主要负责公司自动化运维平台 DMP 维护和数据库日常问题处理。
问题描述： 此前测试服务器负载偏高，其他各项性能指标都正常，未找到原因。提阿里云工单回复正常。 当日CPU频繁达到100%，负载几十，造成服务器瘫痪。
SQL调优这块呢，大厂面试必问的。最近金九银十嘛，所以整理了SQL的调优思路，并且附几个经典案例分析。
最近遇到一个慢sql，在排查过程中发现和分库分表后的索引设置有关系，总结了下问题。
服务使用golang ，客户端库是go-mysql-driver ,系统测试环境频繁但是不总是报出invalid conn 错误，但实际拿sql执行时却是正常执行。
点击上方蓝字“ITester软件测试小栈“关注我，每周一、三、五早上 08:30准时推送，每月不定期赠送技术书籍。
星球一位小伙伴面试了 网易，遇到了一个 性能类的面试题：CPU飙升900%，该怎么处理？
刚来公司，跟公司测试环境项目的服务器，环境是linux Centos7.2 所有的tomcat都挂载在docker容器下，所以也就学习了一些简单的docker指令（学习之前请了解什么是docker，并会常用的linux指令）。
项目系统，多接口混压过程中，发现QPS有掉坑的情况，同时也发现其中一个接口的95分位响应时长明显慢于其它接口。
MySQL的慢查询日志是MySQL提供的一种日志记录，他用来记录在MySQL中响应的时间超过阈值的语句，具体指运行时间超过long_query_time（默认是10秒）值的SQL，会被记录到慢查询日志中。
今天，我们通过模拟案例以及原理分析，去弄清楚MySQL中DDL的风险，以及如何避免事故发生。
zabbix api 关联群组可以直接通过群组名字添加吗？而不是通过群组ID进行添加。
1.1 客户端一般通过tidb来连接TiDB集群，一般OOM之后可能会出现Lost Connection to MySQL Server during query
在使用 MySQL 的过程中，你可能会遇到时区相关问题，比如说时间显示错误、时区不是东八区、程序取得的时间和数据库存储的时间不一致等等问题。其实，这些问题都与数据库时区设置有关，本篇文章将从数据库参数入手，逐步介绍时区相关内容。
这些日志可以帮助我们定位 mysqld 内部发生的事件，数据库性能故障，记录数据的变更历史，用户恢复数据库等。本文主要讲解错误日志文件（Error Log）相关内容。
领取专属 10元无门槛券
手把手带您无忧上云
