系统优化怎么作-数据库优化

前言

目前大部分公司的数据库都是MySQL，虽然如今NoSQL数据库好比mongo, hbase愈来愈流行了，但传统的MySQL依然是业界用得最多。本文是以MySQL为例。

数据库

数据库是惟一在应用系统中的单点资源，对于数据库的资源的使用要特别当心。有以下几点注意点

1. 数据库做为数据存储的地方，不该该把宝贵的资源用于数据的转换或统计操做，SQL中不使用一些字符转换等操做。
2. 数据库链接资源宝贵，外围系统按需分配使用
3. 数据库不怕高qps的小查询，但惧怕慢查询，所以请消灭慢查询。
4. 索引不是越多越好，维护索引资源也耗费数据库运算资源,数据库运算能力宝贵程度大于存储
5. 若是是主从架构，主机器与从机器的网络带宽及稳定性要保证 不在数据库中存储图片、文件等大数据
6. 禁止在线上作数据库压力测试
7. 禁止从测试、开发环境直连线上数据库
8. 不在业务高峰期批量更新、查询数据库
9. 不在MySQL数据库中存放业务逻辑,写储存过程及触发器等
10. 禁止在主库上执行后台管理和统计报表类的功能查询，都放到从库

硬件

• 磁盘

MySQL每秒钟都在进行大量、复杂的查询操做，对磁盘的读写量可想而知。因此，一般认为磁盘I/O是制约MySQL性能的最大因素之一，推荐使用RAID-0+1磁盘阵列。

• CPU

推荐使用至少4U以上的服务器来专门作数据库服务器，基本上是越多越好

• 内存

服务器内存建议不要小于4GB。基本上是越大越好

系统配置

MySQL配置在my.conf,影响新能的几个关键配置属性

1. 使用INNODB存储引擎 5.5之后的默认引擘，支持事务，行级锁，更好的恢复性，高并发下性能更好，对多核，大内存，ssd等硬件支持更好。
2. 表字符集使用utf8mb4
   使用utf8mb4字符集，若是是汉字，占3个字节，但ASCII码字符仍是1个字节；统一，不会有转换产生乱码风险，并能解决符号表情乱码问题；
3. max_connections 最大链接（用户）数
4. innodb_log_file_size
   在高写入负载尤为是大数据集的状况下很重要。这个值越大则性能相对越高，可是要注意到可能会增长恢复时间。设置为64-512MB，根据服务器大小而异
5. Innodb_buffer_pool_pages_data 分配出去， 正在被使用页的数量
6. Innodb_buffer_pool_pages_total 缓冲区总共的页面数 Innodb_page_size
   编译的InnoDB页大小(默认16KB)

调优参考计算方法：

val = Innodb_buffer_pool_pages_data / Innodb_buffer_pool_pages_total * 100%

1. val > 95% 则考虑增大 innodb_buffer_pool_size， 建议使用物理内存的75%
2. val < 95% 则考虑减少 innodb_buffer_pool_size，
3. 建议设置为：

Innodb_buffer_pool_pages_data * Innodb_page_size * 1.05 / (1024*1024*1024)

数据库表结构

表结构的设计目标除了知足业务之外，尽可能减小代码实现上的联表查询操做，所以在设计上能够适当有一些冗余字段的设计，减小数据库IO次数。

如今很流行的ElasticSearch等大数据存储宽表的概念也是这种思想的体现

1. 尽可能避免使用分区表 MySQL的分区表实际性能不是很好。 拆分大字段和访问频率低的字段，分离冷热数据
2. 采用合理的分库分表策略，推荐使用HASH进行分表，表名后缀使用十进制数，下标从0开始首次分表尽可能多的分，避免二次分表，二次分表的难度和成本较高
3. 单表字段数控制在20个之内
4. 一条完整的建表语句中应包含必要的字段、主键、合理的索引（综合代码中全部的条件语句建立合理的索引，主键必需要有

索引设计

索引是一把双刃剑，它能够提升查询效率但也会下降插入和更新的速度并占用磁盘空间。

1. 单张表中索引数量不超过5个
2. 单个索引中的字段数不超过5个
3. 对字符串使用前缀索引，前缀索引长度不超过10个字符；若是有一个CHAR(200)列，若是在前10个字符内，多数值是唯一的，那么就不要对整个列进行索引。对前10个字符进行索引可以节省大量索引空间，也可能会使查询更快
4. 表必须有主键，不使用UUID、MD五、HASH做为主键，尽可能不选择字符串列做为主键；主键建议选择自增id
5. 建立复合索引时区分度较大的字段放在最前面
6. 不在低区分度的字段上建立索引，如“性别”
7. 避免冗余或重复索引
8. 合理建立联合索引（避免冗余），index(a、b、c) 至关于index(a)、index(a、b)、index(a、、b、c)
9. 索引不是越多越好，按实际须要进行建立
10. 每一个额外的索引都要占用额外的磁盘空间，并下降写操做的性能
11. 不在索引列进行数学运算和函数运算；
12. 尽可能不要使用外键 外键用来保护参照完整性，可在业务端实现，对父表和子表的操做会相互影响，下降可用性
13. 不使用%前导的查询，如like“%xxx”，不使用反向查询，如not in / not like 没法使用索引，致使全表扫描 1. 全表扫描致使buffer pool利用下降

字段设计

1. 尽量不要使用TEXT、BLOB类型。删除这种值会在数据表中留下很大的"空洞"，能够考虑把BLOB或TEXT列分离到单独的表中
2. 用DECIMAL代替FLOAT和DOUBLE存储精确浮点数。浮点数相对于定点数的优势是在长度必定的状况下，浮点数可以表示更大的数据范围；浮点数的缺点是会引发精度问题
3. 将字符转化为数字
4. 使用TINYINT来代替ENUM类型
5. 字段长度尽可能按实际须要进行分配，不要随意分配一个很大的容量 VARCHAR(N)，N表示的是字符数不是字节数，好比VARCHAR(255)，能够最大可存储255个汉字，须要根据实际的宽度来选择N。VARCHAR(N)，N尽量小，由于6. 6.MySQL一个表中全部的VARCHAR字段最大长度是65535个字节，进行排序和建立临时表一类的内存操做时，会使用N的长度申请内存；
6. 若是可能, 全部字段均定义为not null
7. 使用UNSIGNED存储非负整数 一样的字节数，存储的数值范围更大。如tinyint有符号为-128-127，无符号为0-255
8. 使用TIMESTAMP存储时间. 由于TIMESTAMP使用4字节，DATETIME使用8个字节,同时TIMESTAMP具备自动赋值以及自动更新的特性.
9. 使用INT UNSIGNED存储IPV4
10. 使用VARBINARY存储大小写敏感的变长字符串
11. 禁止在数据库中存储明文密码

思考题

1. 数据库有哪些高可用措施？
2. 若是数据库挂了,怎么保证核心业务是可用的？