MySQL优化（2）

慕课网视频笔记

第3部分：数据库结构优化

选择合适的数据类型：

数据类型的选择：

使用可以存下你的数据的最小的数据类型
使用简单的数据类型，Int要比varchar类型在MySQL处理上简单
尽可能的使用not null 定义字段
尽量少用text类型，非要不可时最好考虑分表

注：为什么时间戳不用timestamp类型，而用int型，那是因为int的时间戳可以转成任何时间格式输出。timestamp还得先转成unix时间戳，才能转成其它格式。

用简单数据类型存储有好的一面，不好的一面时兼容性差，要用MySQL专用函数查询。

用int类型存储日期，要使用from_unixtime()将int类型转换为日期，使用unix_timestamp()日期转换为int。

CREATE TABLE test(id INT AUTO_INCREMENT NOT NULL, timestr INT, PRIMARY KEY(id));

INSERT INTO test(timestr) VALUES(UNIX_TIMESTAMP('2014-06-01 13:12:00'));

SELECT FROM_UNIXTIME(timestr) FROM test;

使用bigint来存储IP地址（一般的想法是利用varchar来进行存储），利用INET_ATON(),INET_NTOA()两个函数来进行转换，inet_aton将IP地址转为bigint，inet_aton将bigint转换为IP地址。

CREATE TABLE sessions(id INT AUTO_INCREMENT NOT NULL,ipaddress BIGINT,PRIMARY KEY(id));

INSERT INTO sessions(ipaddress) VALUES(INET_ATON('192.168.0.1'));

SELECT INET_NTOA(ipaddress) FROM sessions;

数据库表的范式化优化：

表的范式化和反范式化：
范式化是指数据库设计的范式，目前说到范式化一般是指第三设计范式，也就是要求数据表中不存在非关键字段对任意候选关键字段的传递函数依赖则符合第三范式。

传递函数依赖关系：
(商品名称)->(分类)->(分类描述)
也就是说存在非关键字段“分类描述”对关键字段“商品名称”的传递函数依赖。

这里写图片描述

分类描述对分类来说是相同重复的，分类描述对分类有函数依赖，所以不符合第三范式，造成了数据的冗余，应该对表进行拆分。

不符合第三范式要求的表存在下列问题：

数据冗余：（分类，分类描述）对于每一个商品都会进行记录；
数据的插入异常
数据的更新异常
数据的删除异常

范式化：减少冗余，不能出现非关键字段影响关键候选字段。
反范式化：为了提高性能，可以有一些冗余。例如将一些经常一起查询的字段放在一块，虽然造成了冗余，但是提供了查询速度，反范式化是一种用空间换取时间的做法。

数据表字段的拆分：
商品表，分类表和描述表拆分，这样设计可以使分类和商品相互独立，也就是我们常说的解耦，分类和商品的信息可以更加灵活地增删改查。比如说要把分类中地饮料改成进口饮料，原先只有一张表，有N条记录就要要修改N次，而现在只需要在分类表修改一次就行了。

数据库表的反范式优化：

反范式化是指为了查询效率的考虑把原本符合第三范式的表适当的增加冗余，已达到优化查询的目的，反范式化是一种以空间来换取时间的操作。

这里写图片描述

针对反范式化插入更新删除异常时，我们可以使用外键，虽然外键会影响效率。但是可以有效防止数据出现异常。

数据库表的垂直拆分：

垂直拆分的其中一个重要原因时innodb表每行大小不能超过innodb_page_size。用可变大小的类型，容易超过上限，造成写入数据库不成功。

表的垂直拆分：
所谓的垂直拆分，就是把原理一个有很多列的表拆分成多个表，这解决了表的宽度问题。通常垂直拆分可以按以下原则进行：

1.把不常用的字段单独存放到一个表中。
2.把大字段独立存放到一个表中。
3.把经常一起使用的字段放到一起。

数据库表的水平拆分：

表的水平拆使为了解决单表的数据量过大的问题，水平拆分的表每一个表的结构都是完全一致的。例如电商的销售记录，可以按年（销售记录多的话按年加月）水平拆分，这样也方便统计。

常用的水平拆分方法为：

1.对customer_id进行hash运算，如果要拆分成5个表则使用mod(customer_id,5)取出0-4个值。
2.针对不同的hashID把数据存到不同的表中。

挑战：

1.跨分区表进行数据查询。
2.统计及后台报表操作。

第4部分：系统配置优化

数据库系统配置优化：

数据库是基于操作系统的，目前大多数MySQL都是安装在Linux系统之上，所以对于操作系统的一些参数配置也会影响到MySQL的性能，下面就列出一些常用到的系统配置。

-- 网络方面的配置，要修改/etc/sysctl.conf文件
# 增加tcp支持的队列数
net.ipv4.tcp_max_syn_backlog = 65535
# 减少断开连接时，资源回收
net.ipv4.tcp_max_tw_buckets = 8000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout =10

打开文件数的限制，可以使用ulimit -a查看目录的各位限制，可以修改/etc/security/limits.conf文件，增加以下内容修改打开文件数量的限制。

soft nofile 65535
hard nofile 65535

除此之外，最好在MySQL服务器上关闭iptables，selinux等防火墙软件，可以使用硬件防火墙。

MySQL配置文件优化：

MySQL可以通过启动时指定配置参数和使用配置文件两种方法进行配置，在大多数情况下配置文件位于/etc/my.cnf或是/etc/mysql/my.cnf，在windows系统配置文件可以是位于C:/windows/my.ini文件，MySQL查找配置文件的顺序可以通过以下方法获得：

$ /usr/sbin/mysqld --verbose --help | grep -A 1 'Default options'

注意：如果存在多个位置存在配置文件，则后面的会覆盖前面的。

MySQL常用参数说明：

innodb_buffer_pool_size
innodb_buffer_pool_instances
innodb_log_buffer_size
innodb_flush_log_at_trx_commit
innodb_read_id_threads、_innodb_write_io_threads
innodb_file_per_table
innodb_stats_on_metadata

innodb_buffer_pool_size是非常重要的一个参数，用于配置Innodb的缓冲池，如果数据库只有Innodb表，则条件配置量为总内存的75%。

innodb_buffer_pool_instances是MySQL5.5中新增参数，可以控制缓冲池的个数，默认情况下只有一个缓冲池。

innodb_log_buffer_size是innodb log缓冲的大小，由于日志最长每秒钟就会刷新所以一般不用太大。

innodb_flush_log_at_trx_commit，关键参数，对innodb的IO效率影响很大。默认值为1，可以取0，1，2三个值，一般建议设为2，但如果数据安全性要求比较高则使用默认值1。

innodb_read_io_threads、_innodb_write_id_threads决定了innodb读写的IO进程数，默认为4。

innodb_file_per_table 控制innodb每一个表使用独立的表空间，默认为OFF，也就是所有表都会建立在共享空间中。设置为ON时，是每个表使用独立的表空间。

innodb_stats_on_metadata，决定了MySQL在什么情况下会刷新innodb表的统计信息。

缓存池：缓存吃是对于mysql服务端来说的，就是缓存一部分数据在内存中，用于数据缓存，减少数据查询开销。
连接池：连接池是对客户端应用程序来说的，减少每次创建连接的开销的。

第三方配置工具使用：

第三方配置工具：Percon Configuration Wizard

http://tools.percona.com/wizard

第5部分：服务器硬件优化

如何选择CPU？

MySQL有一些工作只能使用单核CPU：Replicate，SQL….

MySQL对CPU核数的支持并不是越多越快，MySQL5.5使用的服务器不要超过32核。

Disk IO优化：

常用RAID级别简介：

RAID0：也称为条带，就是把多个磁盘链接成一个硬盘使用，这个级别IO最好
RAID1：也称为镜像，要求至少两个磁盘，每组磁盘存储的数据相同
RAID5：也是把多个(最少3个)硬盘合并成1个逻辑盘使用，数据读写时会建立奇偶校验信息，并且奇偶校验信息和相对应的数据分别存储于不同的磁盘上。当RAID5的一个磁盘数据发生损坏后，利用剩下的数据和相应的奇偶校验信息取恢复被损坏的数据
RAID1+0：就是RAID1和RAID0和结合。同时具备两个级别的优缺点。一般建议数据库使用这个级别。

SAN和NAT是否适合数据库？

常用于高可用解决方案。
顺序读写效率高，但是随机读写不如人意。
数据库随机读写比率很高。

更加简略的总结：http://qixingjun.tech/2017/03/10/mysql-optimization/

猜你喜欢