MYSQL5.7.9开启慢查询日志的技巧-mysql的慢查询日志怎么查看

一般mysql超过多长时间，会被认为是慢查询？

一般情况下，当MySQL查询的执行时间超过阈值时，会被认为是慢查询。这个阈值可以根据具体的应用需求进行配置，通常设置为几秒钟。超过这个时间的查询可能会对系统性能产生负面影响，因此被认为是慢查询。慢查询可以通过MySQL的慢查询日志进行记录和分析，以便优化查询性能并提高系统的响应速度。

2020-07-09：mysql如何开启慢查询？

my.cnf和mysqld都可以记录慢查询，通过配置log-slow-queries=file-path就可以，重启之后生效。

mysql官方提供了慢查询日志分析工具mysqldumpslow。主要功能包括统计不同慢sql的类型、出现次数、执行最长时间、累计总耗费时间、等待锁的时间、发送给客户端的行总数、行总数、用户以及sql语句本身。这样就可以很快地定位问题点，也可以为下一步sql有提供充足的参考。

还有一些第三方的工具，但是我没用过，貌似有些GUI的更好用，你可以搜索下。之所以我不用，是担心生产环境中更多的软件部署会导致安全漏洞更多。

希望送的回复对你有帮助。

这专业的回答咋配图？为啥只有配图的才能优质回答？

pt-query-digest

子曰：“工欲善其事，必先利其器”

善于利用好的性能分析工具可以使运维效率事半功倍。pt-query-digest 属于 Percona Toolkit 工具集中较为常用的工具，用于分析 slow log，可以分析 MySQL 数据库的 binary log 、 general log 日志，同时也可以使用 show processlist 或从 tcpdump 抓取的 MySQL 协议数据来进行分析。

mysql select insert速度执行起来有点慢，有没有更效率的查询插入语句命令呢？

Mysql 的select insert语句执行速度慢，首先想到是语句是不是优化，有没有更效率的查询插入语句命令，这个应该是不成立的，DDL和DML的语句都是有固定的语法。

MySQL语句优化-EXPLAIN

EXPLAIN 语句可以被当作 DESCRIBE 的同义词来用，也可以用来获取一个MySQL要执行的 SELECT 语句的相关信息。

语法：

EXPLAIN SELECTselect_options或者EXPLAINtbl_name

• EXPLAIN tbl_name 语法和 DESCRIBE tbl_name 或 SHOW COLUMNS FROM tbl_name 一样。
  

• 当在一个 SELECT 语句前使用关键字 EXPLAIN 时，MYSQL会解释了即将如何运行该 SELECT 语句，它显示了表如何连接、连接的顺序等信息。
  

EXPLAIN 返回了一行记录，它包括了 SELECT 语句中用到的各个表的信息。在 EXPLAIN 的帮助下，您就知道什么时候该给表添加索引，以使用索引来查找记录从而让 SELECT 运行更快。

MySQL语句优化方法

1. 应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描；

2. 应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描；

3. 应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描；

4. in 和 not in 也要慎用，否则会导致全表扫描。

执行速度慢先从语句本身的角度去检查一下，如果语句没有问题，那要考虑一下数据表的结构是否合理，数据库的配置是否配置合理。

Mysql某个表有近千万数据，CRUD比较慢，该如何优化呢？

我是【会点代码的大叔】，每天为你分享程序员干货，关注并私信我数字“1”，送你一份程序员大礼包。

MySQL 数据库某张表近千万的数据，CRUD比较慢，如何优化？

说实话，这个数据量级， MySQL 单库单表支撑起来完全没有问题的，所以首先还是考虑数据库本身的优化。

从上图可以看到，数据库优化通常可以通过以上几点来实现：

• 硬件升级：也就是花更多的钱，升级我们数据库硬件配置，包括 CPU、内存、磁盘、网络等等，但是这个方案成本高，而且不一定能起到非常好的效果。
• 数据库配置：修改数据库的配置，有可能让我们的 CRUD 操作变得更快，不过我也不建议大家把经历放在这一点上面；首先，数据库的配置通常由专业的 DBA 来负责；第二，大部分时候，默认的数据库配置在大多数情况下已经是最优配置了。

对于开发人员来说，我们需要把注意力放在后面三点：

数据结构的优化，也就是表结构的优化

• 数据类型的选择：选用合适的数据结构。什么叫做"合适的数据结构"，比如性别字段，M表示男F表示女，那么一个 char(1) 就足够了，如果存储人的年龄，那么就没有必要使用 INT 这么大范围的字段了；
• 适当的拆分：千万不要试图把所有的字段放在一张表中，因为这会非常影响性能，通常一张表的字段最好不要超过 30 个；
• 适当的冗余：如果一些常用的字段，可能会用在不同的维度，那么我们可以把这些字段设计在多张表中，因为这样可能会减少表关联；
• 字段尽量设置成 not Null，尽量带有默认值。

SQL 语句的优化

优化 SQL 语句执行速度的方法有很多，比如：

• 尽量使用索引，尽量避免全表扫描，提高查询速度；
• 当然你不能无限制地建立索引；维护索引也会影响性能，会降低 DML 操作的速度；
• 注意 SQL 语句的书写，有一些错误的写法可能会导致索引失效；
• 尽量避免在 where 子句中对字段进行 Null 值判断（当然我们在表设计中，直接建议不要有 Null）；
• 条件值多的情况下，尽量不要使用 in 和 not in ；
• select 的时候，使用具体的字段代替 * 号
• 避免返回大量数据，增加分页；

减少数据库的访问

• 我们可以通过增加本地缓存或分布式缓存的方式，将热点数据存储到缓存中，以减少数据库的访问；
• 终极大招，如果是一个不合理的需求，我们可以拒绝做这个需求，这样也算是"减少了数据库访问"。

说完了 MySQL 本身的优化，如果数据量进一步增大的话，我们还有什么优化的方案呢？

读写分离

主库用于写，从库用于读，将读写分散在不同的数据库上，利用多台机器的资源，来提高数据库的可用性和性能。

分库分表

如果数据持续增多，超过了单台 MySQL 的支撑上限，那么只能用【分库分表】这一招了；我们可以采用一定的路由规则，将数据保存到不同的数据库中。

当然，如果不是“迫不得已”，我是不太建议分库分表的，因为这样极大地增加了系统的复杂程度，并且会带来更多的问题需要开发人员解决。

以上就是常用的 MySQL 优化方案，如果是千万级数据量，优化 MySQL 本身即可。

会点代码的大叔 | 原创

一个写代码的架构师，专注程序员的学习和成长，关注并私信我数字“1”，送你一份程序员大礼包。