MYSQL数据库的设计与调优

优化思路:android

1.检查数据表结构,改善不完善设计ios

2.跑一遍主要业务,收集经常使用的数据库查询SQLredis

3.分析查询SQL,适当拆分,添加索引等优化查询数据库

4.优化SQL的同时,优化代码逻辑缓存

5.添加本地缓存和redis缓存数据库设计

6.增长数据库硬件配置和增长读写分离函数

检查数据表结构性能

看数据表结构设计是否合理。优化

尽量不要使用NULL值spa

建表的时候若是不对建立的值设置默认值,MYSQL设置默认都会为NULL。

  NULL使得索引维护更加复杂,强烈建议对索引列设置NOT NULL

  NOT IN!=等负向条件查询在有NULL值的状况下返回永远为空结果,查询容易出错。

  NULL列须要一个额外字节做为判断是否为NULL的标志位。

  使用NULL时和该列其余的值可能不是同种类型,致使问题。(在不一样的语言中表现不同)。

  MySQL难以优化为NULL的列的查询。

添加索引

 

对于常常查询的字段,请加上索引,有索引和没有索引的查询速度相差十倍甚至更多。

 

通常来讲,每张表都须要有一个主键id字段经常使用于查询的字段应该设置索引varchar

型的字段,在创建索引的时候,最好指定长度查询有多个条件时,优先使用具备索引

的条件LIKE条件这样的模糊搜索对于字段索引是无效的,须要另外创建关键词索引

来解决请尽可能不要在数据库层面约束表和表之间的关系,这些表之间的依赖应该在代

码层面去解决。当表和表之间有约束时,虽然增删查的SQL语句变简单了,可是带来

的负面效果是插入等操做数据库都会去检查约束(虽然能够手动设置忽略约束),这

样至关于把一些业务逻辑写到了数据库层,不便于维护。

 

优化表字段结构

 

数据库中那些能够用整形表示的数据就不要使用字符串类型,究竟是用varchar仍是char

 

要看字段的可能值。这种优化每每在数据库中有大量数据之后是不可行的,最好在数据库

设计以前就设计好。对于那些可能值颇有限的列,使用tinyint代替VARCHAR好比记录移

动设备平台,只有两个值:android,ios,那么就可使用0表示android,1表示ios,这种

列必定要写好注释为何不用ENUM呢?ENUM扩展困难,好比后来移动平台又增长了一

ipad,那岂不是懵逼了,而tinyint加个2就行,并且ENUM在代码里面处理起来特别奇怪,

是当成整形呢仍是字符串,各个语言不同。这种方式,必定要在数据库注释或者代码里面

写明各个值的含义对于那些定长字符串,可使用char,好比邮编,老是5位对于那些长度未

知的字符串,使用varchar不要滥用bigint,好比记录文章数目的表id字段,用int就好了,21亿

篇文章上限够了适当打破数据库范式添加冗余字段,避免查询时的表链接查询的时候,确定int

 

类型比varchar快,由于整数的比较直接调用底层运算器就能够实现,而字符串比较要逐个字符

比较。定长数据比变长数据查询快,由于比较定长数据与数据之间的偏移是固定的,很容易计算

下一个数据的偏移。而变长数据则还须要多一步去查询下一个数据的偏移量。不过。定长数据可

能会浪费更多的存储空间。

 

大表拆分

 

对于那些数据量可能近期会超过500W或者增加很快的表,必定要提早作好垂直分表或者水平分表,

当数据量超过百万之后,查询速度会明显降低。分库分表尽可能在数据库设计初期敲定方案,不然后

期会极大增长代码复杂性并且不易更改。垂直分表是按照日期等外部变量进行分表,水平分表是按

照表中的某些字段关系,使用hash映射等分表。分库分表的前提条件是在执行查询语句以前,已经

知道须要查询的数据可能会落在哪个分库和哪个分表中。

 

优化查询语句

 

这个才是不少系统数据库瓶颈的始做俑者。

 

请尽可能使用简单的查询,避免使用表连接请尽可能避免全表扫描,包括但不限于:where子句条件横真

或为空使用LIKE使用不等操做符(<>、!=)查询含义is null的列在非索引列上使用or多条件查询时,

请把简单查询条件或则索引列查询置于前面请尽可能指定须要查询的列,不要偷懒使用select *若是不

指定,一方面会返回多余的数据,占用宽带等另外一方面MySQL执行查询的时候,没有字段时会先去

查询表结构有哪些字段大些的查询关键字比小写快一点点使用子查询会建立临时表,会比连接(JOIN)

和联合(UNION)稍慢在索引字段上查询尽可能不要使用数据库函数,不便于缓存查询结果当只要一行数

据时,请使用LIMIT 1,若是数据过多,请适当设定LIMIT,分页查询千万不要 ORDER BY RAND(),性

能极低。

 

上面是我总结的一些小tips,这些规则是死的,可是业务场景是活的,在实际使用的过程当中,好比数据统计,能够适当牺牲性能换取便利。

 

添加缓存

 

使用redis等缓存,还有本地文件缓存等,能够极大地减小数据库查询次数。缓存这个东西,必定要分析本身系统的数据特色,适当选择。

 

对于一些经常使用的数据,好比配置信息等,能够放在缓存中能够在本地缓存数据库的表结构缓存的数据必定要注意及时更新,还有设置有效期增长缓存务必会增长系统复杂性,必定要注意权衡

相关文章
相关标签/搜索