谈一谈对于MySQL性能的理解

MySQL的性能大致可以分为四类

1.硬件和操作系统层面的优化

2.架构设计层面的优化

3.MySQL程序配置的优化

4.SQL优化

硬件及操作系统层面的优化：

从硬件层面来说，影响MySQL性能的因素有，CPU，可用内存的大小，磁盘的读写速度，网络带宽

从操作系统层面来说，应用文件句柄数，操作系统网络配制都会影响到MySQL性能，这部分的优化，一般是由DBA或者维运工程师去完成的，在硬件基础资源的优化中，我们重点应该关注服务本身承载的体量，然后提出合理的指标要求，避免出现资源浪费。

架构设计层面的优化

MySQL是一个磁盘IO访问量非常频繁的关系型数据库，在高并发和高性能的场景中，MySQL必然会承受巨大的并发压力，而此时，我们优化的方式可以分为几个部分

1.搭建MySQL主从集合群，单个MySQL服务容易单点故障，一旦服务器宕机，将会导致依赖MySQL数据库的应用全部无法响应，主从集群或者主主集群可以保证服务的高可用性。

2.读写分离设计，在读写分离的场景中通过分库可以降低单个服务器节点的IO压力，通过分表的方式可以降低单表数据量，从而提升SQL查询的效率。

3.针对

针对热点数据，可以引入更为高效的分布式数据库，比如 Redis 、 MongoDB

等，他们可以很好的缓解 Mysql 的访问压力，同时还能提升数据检索性能。

MySQL 程序配置优化

MySQL 是一个经过互联网大厂验证过的生产级别的成熟数据库，对于 Mysql 数

据库本身的优化，一般是通过 Mysql 中的配置文件 my.cnf 来完成的，比如。

Mysql5.7 版本默认的最大连接数是 151 个，这个值可以在 my.cnf 中修改。

binlog 日志，默认是不开启

缓存池 bufferpoll 的默认大小配置等。

由于这些配置一般都和用户安装的硬件环境以及使用场景有关系，因此这些配置

官方只会提供一个默认值，具体情况还得由使用者来修改。

关于配置项的修改，需要关注两个方面。

l 配置的作用域，分为会话级别和全局

l 是否支持热加载

因此，针对这两个点，我们需要注意的是：

l 全局参数的设定对于已经存在的会话无法生效

l 会话参数的设定随着会话的销毁而失效

l 全局类的统一配置建议配置在默认配置文件中，否则重启服务会导致配置失效

SQL 优化又能分为三步曲

l 第一、慢 SQL 的定位和排查

我们可以通过慢查询日志和慢查询日志分析工具得到有问题的 SQL 列表。

l 第二、执行计划分析

跟着Mic学架构 针对慢 SQL ，我们可以使用关键字 explain 来查看当前 sql 的执行计划 . 可以重点

关注 type key rows filterd 等字段 ，从而定位该 SQL 执行慢的根本原因。再有

的放矢的进行优化

l 第三、使用 show profile 工具

Show Profile 是 MySQL 提供的可以用来分析当前会话中， SQL 语句资源消耗情

况的工具，可用于 SQL 调优的测量。在当前会话中 . 默认情况下处于 show profile

是关闭状态，打开之后保存最近 15 次的运行结果

针对运行慢的 SQL ，通过 profile 工具进行详细分析 . 可以得到 SQL 执行过程中

所有的资源开销情况 .

如 IO 开销 ,CPU 开销 , 内存开销等 .

以上就是我对 MySQL 性能优化的理解。

好的，看完高手的回答后，相信各位对 MySQL 性能优化有了一定的理解了，最

后我在给各位总结一下常见的 SQL 优化规则：

l SQL 的查询一定要基于索引来进行数据扫描

l 避免索引列上使用函数或者运算 , 这样会导致索引失效

l where 字句中 like % 号 , 尽量放置在右边

l 使用索引扫描 , 联合索引中的列从左往右 , 命中越多越好 .

l 尽可能使用 SQL 语句用到的索引完成排序 , 避免使用文件排序的方式

l 查询有效的列信息即可 . 少用 * 代替列信息

l 永远用小结果集驱动大结果集。