MySQL的优化实战，助你高薪之路顺畅！

来源：clsn.io/clsn/lx287.html

一、简介

MySQL对于很多Linux从业者来说是一个非常困难的问题。 大多数情况下，是因为数据库问题和解决方案不明确。 在优化MySQL之前必须了解的是MySQL的查询过程。 很多查询优化工作其实只是遵循一些原则，让MySQL优化器能够按照预期合理的方式运行。

今天给大家带来MySQL优化的实战经验，助您顺利高薪之路！

图-MySQL查询流程

2.优化的哲学

注意：优化有风险，参与需谨慎！

2.1. 优化可能带来的问题

2.2. 优化需求

2.3. 谁参与优化？

进行数据库优化时，数据库管理员、业务部门代表、应用架构师、应用设计人员、应用开发人员、硬件和系统管理员、存储管理员等业务相关人员都应该参与。

3、优化思路

3.1. 优化什么？

数据库优化主要有两个方面：安全性和性能。

3.2. 优化的范围是什么？

存储、主机和操作系统方面： 应用方面： 数据库优化方面：

注：无论是设计系统、定位问题还是优化，都可以按这个顺序执行。

3.3. 优化尺寸

数据库优化有四个维度：硬件、系统配置、数据库表结构、SQL和索引。

优化选项：

4、优化工具有哪些？

4.1. 数据库级别

检查问题的常用工具：

不太常用但有用的工具：

4.2. 解决数据库级别问题的思路

一般紧急调整思路：

针对业务处理突然滞后，无法进行正常业务处理的情况！ 需要立即解决的情况！

一般调优思路：

对于周期性业务滞后，比如每天10-11点业务特别慢，但是还是可以用的，过了这个时间段就没事了。

4.3. 系统级

CPU方面：

,sar 顶部,htop,nmon,

记忆：

免费，ps-aux，

IO设备（磁盘、网络）：

, ss, , ,iftop,lsof,

命令说明：命令说明示例命令：-dk 1 5

-d -k -x 5（查看设备使用情况（%util）和响应时间（等待））

4.4. 系统级问题的解决方案

您认为负载较高还是较低更好？

实际生产中，一般认为只要CPU不超过90%就不会出现问题。

当然，也不排除以下特殊情况： 问题一：CPU负载高，IO负载低 问题二：IO负载高，CPU负载低 问题三：IO负载高，CPU负载高

硬件不够或者SQL有问题

5.基础优化

5.1. 优化思路

定位问题点：

硬件-->系统-->应用-->数据库-->架构（高可用、读写分离、分库分表）

加工方向：

明确优化目标、性能和安全权衡，防患于未然

5.2. 硬件优化

主机：cpu选择：内存选择：存储：raid卡：主机raid卡选择：网络设备：

利用流量支持更高的网络设备（交换机、路由器、网线、网卡、HBA卡）

注：系统初始设计时应考虑上述规划。

5.3. 服务器硬件优化

5.4. 系统优化

中央处理器：

基本上不需要调整，只需关注硬件选型即可。

记忆：

基本上不需要调整，只需关注硬件选型即可。

交换：

MySQL 试图避免使用交换。 阿里云服务器默认swap为0

IO：

该参数决定 Linux 是否倾向于使用交换或释放文件系统缓存。 在内存紧张的情况下，较低的值往往会释放文件系统缓存。 当然，这个参数只能减少使用swap的概率，但并不能阻止Linux使用swap。

修改MySQL的配置参数并启用该模式。 在这种情况下，池将直接绕过文件系统缓存来访问磁盘，但重做日志仍然会使用文件系统缓存。值得注意的是，重做日志处于覆盖模式。 即使使用文件系统缓存，也不会占用太多

IO调度策略：

5.5. 系统参数调整

Linux系统内核参数优化：

用户限制参数（mysql不需要设置以下配置）：

5.6. 应用优化

业务应用和数据库应用是独立的，防火墙：，以及其他无用的服务（关闭）：

安装图形界面服务器时不要启动图形界面3。 另外，思考一下我们的业务未来是否真的需要MySQL，或者使用其他类型的数据库。 使用数据库的最高境界就是不使用数据库。

6.数据库优化SQL优化方向：

执行计划、索引、SQL重写

架构优化方向：

高可用架构、高性能架构、分库分表

6.1. 数据库参数优化

调整：

实例整体（高级优化、扩展）

连接层（基础优化）

设置合理的对接客户及对接方式

SQL层（基础优化）

6.2. 存储引擎层（基本优化参数）

关注公众号“程序心”（ID：），以获得更好的阅读体验，我们每天都会给您真诚的资讯！