数据库优化_史上更全的 MySQL 高性能优化实战总结！

一、前言

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:、htop、nmon、内存：空闲、ps-auxIO 设备（磁盘、网络）：ss、iftop、lsof

命令说明：

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

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

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

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

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

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

问题2：IO负载高，CPU负载低

问题3：IO和CPU负载都很高

硬件不够或者SQL有问题

5.基础优化

5.1.优化思路

定位问题点：

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

加工方向：

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

5.2.硬件优化

主持人：

中央处理器选择：

内存选择：

贮存：

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.存储引擎层（基本优化参数）

过去的选择