高级mysql数据库优化_SQL高级优化（一）之MySQL优化

不同方案效率对比

MySQL各字段默认长度(一字节为8位)

整型：

TINYINT 1 字节

SMALLINT 2 个字节

MEDIUMINT 3 个字节

INT 4 个字节

INTEGER 4 个字节

BIGINT 8 个字节

浮点型：

FLOAT(X) 4 如果 X < = 24 或 8 如果 25 < = X < = 53

FLOAT 4 个字节

DOUBLE 8 个字节

DOUBLE PRECISION 8 个字节

REAL 8 个字节

DECIMAL(M,D) M字节(D+2 , 如果M < D)

NUMERIC(M,D) M字节(D+2 , 如果M < D)

日期和时间型：

DATE 3 个字节

DATETIME 8 个字节

TIMESTAMP 4 个字节

TIME 3 个字节

YEAR 1 字节

串类型：

CHAR(M) M字节，1 <= M <= 255

VARCHAR(M) L+1 字节, 在此L <= M和1 <= M <= 255

TINYBLOB, TINYTEXT L+1 字节, 在此L< 2 ^ 8

BLOB, TEXT L+2 字节, 在此L< 2 ^ 16

MEDIUMBLOB, MEDIUMTEXT L+3 字节, 在此L< 2 ^ 24

LONGBLOB, LONGTEXT L+4 字节, 在此L< 2 ^ 32

ENUM('value1','value2',...) 1 或 2 个字节, 取决于枚举值的数目(***值65535)

SET('value1','value2',...) 1，2，3，4或8个字节, 取决于集合成员的数量(最多64个成员)

1、测试数据导入

在数据库中新建一张包含300万条数据的表

2、查询语句指定列和不指定列

select * from table;

select id from table;

在数据量巨大的情况下，查询的时候最好指定列，效率高

3、用不同引擎执行时间

select * from table;

MyISAM效率高于InnoDB

MySQL优化

一、MySQL优化简介

MySQL官方的优化(Optimization)解决方案

https://dev.mysql.com/doc/refman/5.7/en/optimize.html

优化概述 数据库性能取决于数据库级别的几个因素，例如表，查询和配置设置。这些软件结构导致在硬件级别执行CPU和I / O操作，您必须将这些操作最小化并使其尽可能高效。在研究数据库性能时，首先要学习软件方面的高级规则和准则，并使用时钟时间来衡量性能。成为专家后，您将了解有关内部情况的更多信息，并开始测量诸如CPU周期和I / O操作之类的东西。 典型的用户旨在从其现有的软件和硬件配置中获得最佳的数据库性能。高级用户寻找机会改进MySQL软件本身，或开发自己的存储引擎和硬件设备以扩展MySQL生态系统。 优化MySQL主要从两个方向：数据库级别和硬件级别，同时需考虑平衡便携性和性能。

硬件级别优化 随着数据库变得越来越繁忙，任何数据库应用程序最终都会达到硬件极限。DBA必须评估是否有可能调整应用程序或重新配置服务器以避免这些 瓶颈，或者是否需要更多的硬件资源。系统瓶颈通常来自以下来源：

磁盘搜索。磁盘查找数据需要花费时间。对于现代磁盘，此操作的平均时间通常小于10毫秒，因此理论上我们可以执行约100秒钟的搜索。这段时间随着新磁盘的使用而缓慢改善，并且很难为单个表进行优化。优化寻道时间的方法是将数据分发到多个磁盘上。更换好的硬盘(如：机械->固态)

磁盘读写。当磁盘位于正确的位置时，我们需要读取或写入数据。使用现代磁盘，一个磁盘至少可提供10–20MB / s的吞吐量。与查找相比，优化起来更容易，因为您可以从多个磁盘并行读取。更换好的硬盘(如：机械->固态)

CPU周期。当数据位于主存储器中时，我们必须对其进行处理以获得结果。与内存量相比，拥有较大的表是最常见的限制因素。但是对于小桌子，速度通常不是问题。选择好的CPU

内存带宽。当CPU需要的数据超出CPU缓存的容量时，主内存带宽将成为瓶颈。对于大多数系统来说，这是一个不常见的瓶颈，但是要意识到这一点。CPU缓存

数据库级别优化：使数据库应用程序快速运行的最重要因素是其基本设计：

表格的结构是否正确(Are the tables structured properly?)：特别是，这些列是否具有正确的数据类型，并且每个表都具有适合于该工作类型的列吗？例如，执行频繁更新的应用程序通常具有许多表而具有很少的列，而分析大量数据的应用程序通常具有很少的表而具有很多列。

是否安装了正确的索引以提高查询效率(Are the rightindexesin place to make queries efficient?)：优化索引是我们使用成本最低，效果最好的方式

您是否为每个表使用了适当的存储引擎，并利用了所使用的每个存储引擎的优势和功能？特别是，对于InnoDB诸如MyISAM性能或可伸缩性之类的事务性存储引擎或诸如非 事务性存储引擎的选择 可能非常重要。 注意InnoDB是新表的默认存储引擎。实际上，高级 InnoDB性能功能意味着 InnoDB表通常要比简单MyISAM表好，尤其是对于繁忙的数据库。

每个表都使用适当的行格式吗？该选择还取决于表使用的存储引擎。特别是，压缩表使用较少的磁盘空间，因此需要较少的磁盘I / O来读取和写入数据。压缩适用于带InnoDB表的所有工作负载 以及只读 MyISAM表。

应用程序是否使用适当的锁定策略？例如，通过在可能的情况下允许共享访问，以便数据库操作可以同时运行，并在适当的时候请求独占访问，以使关键操作获得最高优先级。同样，存储引擎的选择很重要。该InnoDB存储引擎处理大部分锁定问题，而不需要您的参与，允许在数据库更好的并发，减少试验和调整的金额，让您的代码。

用于缓存的所有内存区域大小是否正确？也就是说，足够大以容纳经常访问的数据，但又不能太大以至于它们会使物理内存过载并导致分页。要配置的主要内存区域是InnoDB缓冲池，MyISAM键高速缓存和MySQL查询高速缓存。

二、优化哲学

注意：优化有风险，涉足需谨慎！

1. 优化可能带来的问题

1.1 优化不总是对一个单纯的环境进行，还很可能是一个复杂的自己投产的系统

1.2 优化手段本来就有很大的风险，只不过IMEI能力意识到和预见到！

1.3 任何技术可以解决一个问题，但必然存在带来一个问题的风险！

1.4 对于优化来说解决问题而带来的问题，控制在可接受的范围内才是有成果。

结论：保持现状或出现更差的情况都是失败！

2. 优化的需求

2.1 稳定性和业务可持续行，通常比性能更重要！

2.2 优化不可避免涉及到变更，变更就有风险！

2.3 优化使性能编号，维持和变差是等概率事件！

2.4 切记优化应该是各部门协同，共同参与的工作，任何单一部门都不能对数据库进行优化！

结论：所以优化工作是有业务需要驱动的！！！

三、优化由谁参与

​ 在进行数据库优化时，应有数据库管理员、业务部门代表、应用程序架构师、应用程序设计人员、应用程序开发人员、硬件及系统管理员、存储管理员等，业务相关人员共同参与。

四、优化的顺序

​      优化选择

优化成本：硬件 > 系统配置 > 数据库表结构 > SQL及索引

优化效果：硬件 < 系统配置 < 数据库表结构 < SQL及索引

五、常见的优化工具

检查问题常用工具

mysqladmin # mysql客户端，可进行管理操作

mysqlshow # 功能请打的查看shell命令

show [SESSION | GLOBAL] variables # 插卡数据库参数信息

SHOW [SESSION | GLOBAL] STATUS # 查看数据库的状态信息

information_schema # 获取源数据的方法

SHOW ENGINE INNODB STATUS Innodb # 引擎的所有状态

SHW PROCESSLIST # 查看当前所有连接session状态

explain # 获取查看语句的执行计划

show index # 查看表的索引信息

slow-log # 记录慢查询语句

mysqldumpslow # 分析slowlog文件

不常用但好用的工具

zabbix # 监控主机、系统、数据库(部署zabbix监控平台)

pt-query-digest # 分析慢日志

mysqlslap # 分析慢日志

sysbench # 压力测试工具

mysql profiling # 统计数据库整体状态工具

Performance Schema mysql # 性能状态统计的数据

workbench # 管理、备份、监控、分析、优化工具(比较满资源)