谈到MySQL性能优化，查询优化作为优化的源头，它也是最能体现一个系统是否更快。 本章以及接下来的几章将会着重讲解关于查询性能优化的内容，从中会介绍一些查询优化的技巧，帮助大家更深刻地理解MySQL如何真正地执行查询、究竟慢在哪里、如何让其快起来，并明白高效和低效的原因何在，这样更有助于你更好的来优化查询SQL语句。
我们都知道，我们每执行一次 SQL，数据库除了会返回执行结果以外，还会返回 SQL 执行耗时，以 MySQL 数据库为例，当我们开启了慢 SQL 监控开关后，默认配置下，当 SQL 的执行时长大于 10 秒，会被记录到慢 SQL 的日志文件中。
在项目里面，多多少少都隐藏着一些执行比较慢的SQL, 不同的开发测试人员在平时使用的过程中多多少少都能够遇到，但是无法立马有时间去排查解决。那么如果有一个文件能够将这些使用过程中比较慢的SQL记录下来，定期去分析排查，那该多美好啊。这种情况MySQL也替我们想到了，它提供了SQL慢查询的日志，本文就分享下如何使用吧。
学完数据库基础知识，要想更深入地了解数据库，就需要学习数据库进阶知识，今天我们就先来聊一聊慢SQL查询那些事儿。
系统从圣诞节那天晚上开始，每天晚上固定十点多到十一点多这个时段，大概瘫痪1h左右，过这时段系统自动恢复。系统瘫痪时的现象就是，网页和App都打不开，请求超时。系统架构：
在过去的半年时间里，研发团队内部尝试抓了一波儿慢查询SQL跟进处理率。发现有些同学对于慢查询处理的思路就是看看有没有用到索引，没有用到就试图加一个，实在不行就甩锅给这种情况是历史设计问题或者自行判定为用户特殊操作下触发的小概率事件，随即便申请豁免掉... 其实问题没有根本上解决。
来源：juejin.im/post/5bcc2935f265da0ac66987c9
MySQL性能优化是一个老生常谈的问题，无论是在实际工作中还是面试中，都不可避免遇到相应的场景，下面博主就总结一些能够帮助大家解决这个问题的小技巧。
监控系统监控到我们的程序变慢了，怀疑是sql的原因，要怎么去分析排查呢？一般按照如下几个步骤进行：
昨天遇到一个问题, 200万的表里查询9万条数据, 耗时达63秒. 200万数据不算多, 查询9万也还好. 怎么用了这么长的时间呢? 问题是一句非常简单的sql. select * from tk_t
就需要服务器引入nginx，Nginx官方宣传5W并发量，利用其反向代理，可以加入很多台Tomcat处理。但是有个问题，多机器Tomcat的Session之间共享问题。这个时候就需要引入Redis作为存储各个Tomcat之间的Session共享问题，同时 redis 也可作为下面的优化使用。一些经常查询的热点数据，可以存入Redis，加快相应速度，也就不用直接取数据库查询了。
select ...from table where exist (子查询)；
当前，如果不是调优需要的话，一般不建议启动该参数，因为开启慢查询日志会对性能造成一定的影响，慢查询日志支持将日志记录到文件中
show variables like ‘%slow_query_log%’; #如果结果中包含slow_query_log | OFF ，则说明慢日志已经关闭 #开启慢查询日志的方式：set global slow_query_log=1;
我们在设计一个系统的时候，有时候通常为了基础业务，写出的查询sql语句并不高效，从而影响到用户使用系统的整体体验感不是很好，我们通常在系统的测试阶段会开启MySQL中的慢日志查询的功能，可以在MySQL的系统配置文件中开启这个慢日志的功能，并且也可以设置SQL执行超过多少时间来记录到一个日志文件中，只要SQL执行的时间超过了我们设置的时间就会记录到日志文件中，我们就可以在日志文件找到执行比较慢的SQL了，从而就可以对这些语句进行调优优化，使用 Explain来分析 SQL 语句的性能。
Mysql慢查询和慢查询日志分析 众所周知，大访问量的情况下，可添加节点或改变架构可有效的缓解数据库压力，不过一切的原点，都是从单台mysql开始的。下面总结一些使用过或者研究过的经验，从配置以及调节索引的方面入手，对mysql进行一些优化。 第一步应该做的就是排查问题，找出瓶颈，所以，先从日志入手 开启慢查询日志 mysql>show variables like “%slow%”; 查看慢查询配置，没有则在my.cnf中添加，如下 log-slow-queries = /data/mysqldata/
大家好，我是田维常，可以叫我老田，也可以叫我田哥。2017年的时候，我刚去上海，朋友内推我去美团面试，之前我也写过一个一篇文章，也是在美团面试中遇到的：
一、网络问题 1、临时性 检查：ping, mtr,dig,dig+trace 等命令，检查网络状况，DNS等 解决：联系机房或视具体情况而定 eg:http://ping.chinaz.com/ 查看各地响应时间 2、网络不同或距离太远 检查：客户端和机房所在网络情况 解决：双线机房或分布式部署，动态DNS，需要考虑成本 3、资源加载慢 检查：chrome控制台 解决：CDN，合并请求，压缩页面代码，多域名请求（http协议中有对浏览器并发请求连接数的限制，IE是10，火狐 chrome是6）等 二、前端
为什么在 MySQL数据库中，一条慢查询只要添加上合适的索引，查询速度就能提升一个档次？对于 MySQL，如何巧用索引优化SQL语句性能？需要注意什么问题？
一般情况下，查询可以看成按如下顺序执行任务：由客户端向服务端发起查询请求，然后在服务器端进行解析，生成执行计划，执行，最后将结果返回给客户端。
对于当前数据库的监控方式有很多，分为数据库自带、商用、开源三大类，每一种都有各自的特色；而对于 mysql 数据库由于其有很高的社区活跃度，监控方式更是多种多样，不管哪种监控方式最核心的就是监控数据，获取得到全面的监控数据后就是灵活的展示部分。
最近公司项目添加新功能，上线后发现有些功能的列表查询时间很久。原因是新功能用到旧功能的接口，而这些旧接口的 SQL 查询语句关联5,6张表且编写不够规范，导致 MySQL 在执行 SQL 语句时索引失效，进行全表扫描。原本负责优化的同事有事请假回家，因此优化查询数据的问题落在笔者手中。笔者在查阅网上 SQL 优化的资料后成功解决了问题，在此从==全局角度==记录和总结 MySQL 查询优化相关技巧。
今天，数据库的操作越来越成为整个应用的性能瓶颈了，这点对于Web应用尤其明显。关于数据库的性能，这并不只是DBA才需要担心的事，而这更是我们程序员需要去关注的事情，希望文章的这些优化技巧对你有用。
mysql性能优化(九) mysql慢查询分析、优化索引和配置
我们都知道，在日常开发中我们经常遇到在钉钉群或者在业务群中会出现各种各样的慢业务的接口，比如某个接口在钉钉群疯狂出现，然后就有某些领导艾特你来解决这个慢业务问题，今天阿粉就来说说如何通过各种手段来定位慢业务问题，以及如何解决慢业务的问题。
慢查询指的是数据库中执行时间超过指定阈值的 SQL 语句。不同业务场景下，这个阈值通常各不相同。在我们公司内部，这个阈值被设定为 1 秒钟。也就是说，任何执行时间超过 1 秒的 SQL 语句都会被视为慢查询。
一般来说，面试不会问 inode 。但是 inode 是一个重要概念，是理解 Unix/Linux 文件系统和硬盘储存的基础。
大家好，我是程序员啊粥，这段时间一直在分享 MySQL 索引系列的文章，我们学会了索引模型 MySQL InnoDB 索引模型，以及和具体的索引使用原则等内容，今天开始我们学习 SQL 的优化。
不管是开发同学还是DBA,想必大家都遇到慢查询(select,update,insert,delete 语句慢)，影响业务稳定性。这里说的慢，有两个含义一是比正常的慢，有可能正常执行时间是10ms，异常的是100ms 。二是sql执行时间超过设置的慢查询标准比如500ms。
作为一名DBA，分析MySQL数据库的慢日志是一项经常会遇到的任务，今天我们来看下mysql官方自带的慢日志分析工具mysqldumpslow。
秒杀系统难做的原因：库存只有一份，所有人会在集中的时间读和写这些数据。例如小米手机每周二的秒杀，可能手机只有1万部，但瞬时进入的流量可能是几百几千万。又例如12306抢票，亦与秒杀类似，瞬时流量更甚。
大家好！我是黄啊码，MySQL的入门篇已经讲到第14个课程了，今天我们继续讲讲大白篇系列——数据库服务器优化流程
慢查询可以帮我们找到执行慢的 SQL，在使用前，我们需要先看下慢查询是否已经开启，使用下面这条命令即可：
“计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决”，这是计算机领域一句名言。任何问题都可以通过增加一个中间层来解决。互联网业务系统在应对大并发时候通常会选择引入缓存，当然可以Scale UP，但是响应成本上升，引入缓存是一种比较经济有效方法。在面对各种缓存更新与访问策略时候我们可能会眼花缭乱，不合适的缓存更新策略可能达不到预期效果。
刚入职的时候，同事就提醒过我，涉及三四张表的时候，数据量大，尽量不用连表查询，用单表。我最近还真的是遇到了。因为联表查询导致引发的慢sql。
一个测试环境，nginx+php-fpm对外提供服务，测试人员访问的时候出现时快时慢的情况，慢时超过了正常网页的等待打开时间范围。重启nginx php-fpm后恢复，访问几次后又会慢
统计一张表的总数量，是我们开发中常有的业务需求，通常情况下，我们都是使用 select count(*) from t SQL 语句来完成。随着业务数据的增加，你会发现这条语句执行的速度越来越慢，为什么它会变慢呢？
MySQL优化 MySQL 优化方案 对于 **MySQL** 的性能优化，大部分情况下都是想减少查询所消耗的时间；而一个查询是由很多个环节组成，那么就需要从每个环节消耗时间进行入手。 配置优化（连接） 当客户端连接到服务端有可能服务端连接数不够导致应用程序获取不到连接而报出 **Mysql: error 1040: Too many connections**** **的错误。一般情况下可以从两个方面去解决连接数不够的问题： 对于服务端来说，可以增加服务端的可用连接数（**MySQL 8.0.
表中只有一个字段时 count(*) 效率最高，count(列名) 当列名是主键时，它的效率高于 count(1)，其他情况 count(1) 效率更高。
php.ini是php运行核心配置文件,下面是一些常用配置 extension_dir="" 设置PHP的扩展库路径 expose_php = Off 避免PHP信息暴露在http头中 display_errors = Off 避免暴露php调用mysql的错误信息 log_errors = On 在关闭display_errors后开启PHP错误日志（路径在php-fpm.conf中配置） zend_extension=opcache.so extension=mysqli.so
MySQL 的慢查询日志记录的内容是：在 MySQL 中响应时间超过参数 long_query_time（单位秒，默认值 10）设置的值并且扫描记录数不小于 min_examined_row_limit（默认值0）的语句。
mysql -uuser_name -ppasswd -hlocalhost -Pport -D database -e "sql"
可能是经常处理业务，最近总是听到开发的同学说SQL的查询慢。然后问我为什么，让我在数据库层面找原因。这样的需求接的多了，对于这类需求，我已经有了一套比较官方的回答思路，我来说，大家看，看看还有什么没有考虑到的地方，欢迎指正。
’mysql慢查询优化 第一步：开启mysql慢查询日志，通过慢查询日志定位到执行较慢的SQL语句。 第二步：利用explain关键字可以模拟优化器执行SQL查询语句，来分析SQL查询语句。 第三步：通过查询的结果进行优化。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
