Mysql优化总结(一)

时间 2019-11-19

标签 mysql 优化总结栏目 MySQL 繁體版

原文原文链接

一，前言

数据库（Database）是按照数据结构来组织、存储和管理数据的仓库。mysql

MySQL 是一个关系型数据库管理系统，由瑞典 MySQL AB 公司开发，目前属于 Oracle 公司。MySQL 是一种关联数据库管理系统，关联数据库将数据保存在不一样的表中，而不是将全部数据放在一个大仓库内，这样就增长了速度并提升了灵活性。程序员

MySQL是开源的，因此不须要支付任何费用。
MySQL使用标准的SQL数据语言形式。
MySQL能够处理拥有千万条记录的大型数据库。
MySQL支持多种语言，如C，PHP，Java等。

　　本篇博客是总结MySQL存储机制及SQL优化方面的内容。sql

二，MySQL逻辑架构

分析：数据库

第一层是大多数基于网络的客户端/服务器的工具或者服务都有相似的架构。如链接处理，受权认证等。
第二层架构中，大多数的MYSQL的核心服务功能都在这一层，包括查询解析、分析、优化、缓存以及全部的内置函数（日期时间等），全部跨存储引擎的功能都在这一层实现：存储过程、触发器、视图等层。
第三层包含了存储引擎。存储引擎负责Mysql中的数据的存储和提取。
Mysql支持各类不一样的存储引擎，每一个存储引擎都有它的优点和劣势。服务器经过API和存储引擎进行通讯。这些API接口屏蔽了不一样存储引擎之间的差别，使的这些差别对上层的查询过程透明。存储引擎不会解析SQL（InnoDB是个例外，它会解析外键定义），不一样的存储引擎之间也不能互相通讯，而只是简单的响应上层服务器的请求。

缓存：当客户端请求到来时，先去查询缓存中是否存在数据，没有再去数据库中查询。缓存

分析器：对sql语句的分析，好比SELECT username FROM users; ，分析器分析出先执行FROM users，而后再执行SELECT　username。

优化器：上面只是举了一个简单的例子，而优化器做用在于选择那种执行方式，是执行SQL效率最快的。由于分析器对一条SQL语句会分析出多种不一样的结果，而优化器就会对以上的分析结果选择它认为最优的结果来执行。可是，须要注意的是，优化器认为最优的执行方案，并不必定是咱们认为的最优执行方案。所以再SQL语句量较大的状况下，就须要程序员手动对语句进行优化。服务器

下面再来讲说MySQL的存储引擎。网络

三，存储引擎

以博主的MySQL做为案例，执行select version();语句能够查看数据库版本。数据结构

接着再来看看MySQL都支持哪些存储引擎。架构

在倒数第二个，能够看出MySQL默认的存储引擎是InnoDB，再细看Transactions中只有InnoDB是支持事务的，其余存储引擎都是不支持的。这是在MySQL5.5以后支持的引擎，因此说在5.5以前MySQL是不支持事务的。函数

最长用的两种存储引擎为InnoDB和Myisam，请看二者之间的区别（MySQL5.6）。

特色	InnoDB	myisam
事务	支持事务	不支持
锁	行锁	表锁
B树索引	支持	支持
全文索引	不支持	支持
外键	支持（惟一支持的）	不支持

那么如何选择两种存储引擎，能够从如下几个方面考虑。

事务：

若是应用须要事务支持，那么InnoDB是较号的选择。若是不须要事务，而且主要是select和insert操做，则MyISAM是个不错的选择，好比日志型系统。

备份：

备份的需求也会影响存储引擎的选择。若是须要在线热备份，则选择InnoDB就是基本的要求。

数据恢复：

数据量比较大的时候，系统崩溃后如何快速恢复是一个须要考虑的额问题。相对而言，MyISAM崩溃后发生损坏的几率比InnoDB高的多，并且恢复也慢，所以即便不须要事务，一般也应该选择InnoDB引擎。

对于不一样存储引擎的选择，对数据库的性能都会带来较大的影响，除了MySQL默认支持的存储引擎以外，还有不少第三方存储引擎。

一般状况下，致使SQL性能降低还有如下几方面：

查询语句编写不合理
索引失效
关联查询数据太多
服务器的参数设置问题

下面总结一些关于SQL优化方面的内容。

四，数据类型优化

4.1，数据类型的选择原则。

更小的一般更好：

通常状况选择能够正确存储数据的最小数据类型。由于更小的数据类型一般更快，由于占用磁盘、内存和CPU缓存会越小。

简单就好：

简单数据类型的操做一般须要更少的CPU消耗。

尽可能避免NULL：

通常状况下最好执行列为NOT NULL，除非特殊须要。由于若是查询中包含为NULL的列，从SQL优化角度考虑，对建立索引，索引的统计等都会带来较大的困难，且优化起来也是较为复杂的，所以说尽可能避免NULL值。

4.2，具体类型的选择

1，整数类型：选择合适的字节大小做为数据的类型。

tinyint：8位字节
smallint：16位字节
mediumint：24位字节
int：32位字节
bigint：64位字节
unsigned属性：添加unsigned属性表示该字段不容许负数，正数的上限大体能够提升一倍。
好比tinyint unsigned能够存储0-255的范围。而tinyint是-128~127的范围。有符号和无符号占用空间大小相同，具备相同的性能。

int(11)是指定整数类型的宽度，它不会限制值得合法范围，对于存储和计算而言，int(1)和int(20)没什么区别

2，实数类型

float：32位
double：64位
decimal：decimel须要额外的空间和计算开销，因此应该尽可能只对小数进行精准计算时才使用decimel，例如存储金额。

3，字符串类型

varchar：是可变长的字符串，它比定长更节省空间。varchar须要使用1~2个额外字节记录字符串的长度。varchar节省了存储空间，因此对性能也有帮助，
可是因为长度可变，在update时可能使行变得比原来更长，这就致使须要进行额外的工做。至于如何进行空间增加取决于不一样的存储引擎。当字符串列的最大长度比平均长度要大不少，而且列的更新不多时比较适合使用varchar。
char：定长字符串，mysql根据定义的字符串长度分配足够的空间。
char很是适合存储很短的字符串，或者值得长度都很接近的字段。例如char很是适合存放密码的md5值，由于这是一个定长的值。对于常常变动的字段，使用char也更为合适，由于定长的char类型不容易产生碎片。对于很是短的列，存储空间也更有优点，好比char(1)只会占用一个字节，而varchar(1)会用到两个字节，由于还有一个字节用来记录varchar的长度。
blob和text：二者都是用于存储很大的数据而设计的字符串数据类型，
分别采用二进制和字符的方式存储。

varchar(5)和varchar(200)存储'hello'的空间开销是同样的。可是varchar(5)对性能提高有很大的优点。更长的列会消耗更多的内存，由于mysql一般会分配固定大小的内存块来保存内部值。尤为是使用内存临时表进行排序等操做时会特别糟糕。因此最好的策略是只分配真正须要的空间

4，时间和日期类型

datetime：能保存大范围的值，从1001年到9999年，精度为秒。它把日期和时间封装到YYYYMMDDHHMMSS的整数中，使用8个字节的存储空间。
timestamp：保存了从1970年1月1日以来的毫秒数，timestamp只使用了4个字节的存储空间，所以它的范围比datetime小的多；可是只能表示从1970年到2038年。另外timestamp也依赖于时区。

除了特殊行为以外，一般应该尽可能使用timestamp，
由于它比datetime空间效率更高。

五，总结

下面将总结索引方面的优化，包括B-Tree和B+Tree两种数据结构的原理，因为放在一块儿篇幅较长，因此就分红两个博客，这些内容会在下一篇博客中进行详细总结。

以上内容均是自主学习总结，若有不适之处，欢迎留言指正。

感谢阅读！