MySQL数据库优化的引见（图文）【MySQL教程】,java,mysql,ubuntu

本篇文章给人人带来的内容是关于MySQL数据库优化的引见（图文），有肯定的参考价值，有须要的朋侪能够参考一下，愿望对你有所协助。

数据库优化一方面是找出体系的瓶颈,进步MySQL数据库的团体机能,而另一方面须要合理的结构设想和参数调解,以进步用户的响应速率,同时还要只管的勤俭体系资本,以便让体系供应更大的负荷.（相干引荐：MySQL教程）

1. 优化一览图

2. 优化

笔者将优化分为了两大类,软优化和硬优化,软优化平常是操纵数据库即可,而硬优化则是操纵效劳器硬件及参数设置.

2.1 软优化

2.1.1 查询语句优化

1.起首我们能够用EXPLAIN或DESCRIBE(简写:DESC)敕令剖析一条查询语句的实行信息.
2.例:

DESC SELECT * FROM `user`

显现:

其中会显现索引和查询数据读取数据条数等信息.

2.1.2 优化子查询

在MySQL中,只管运用JOIN来替代子查询.由于子查询须要嵌套查询,嵌套查询时会竖立一张暂时表,暂时表的竖立和删除都邑有较大的体系开支,而衔接查询不会建立暂时表,因而效力比嵌套子查询高.

2.1.3 运用索引

索引是进步数据库查询速率最主要的要领之一,关于索引能够参高笔者<MySQL数据库索引>一文,引见比较细致,此处纪录运用索引的三大注意事项:

LIKE关键字婚配'%'开首的字符串,不会运用索引.
OR关键字的两个字段必需都是用了索引,该查询才会运用索引.
运用多列索引必需满足最左婚配.

2.1.4 分解表

关于字段较多的表,假如某些字段运用频次较低,此时应该,将其星散出来从而构成新的表,

2.1.5 中心表

关于将大批衔接查询的表能够建立中心表,从而削减在查询时形成的衔接耗时.

2.1.6 增添冗余字段

类似于建立中心表,增添冗余也是为了削减衔接查询.

2.1.7 剖析表,,搜检表,优化表

剖析表主如果剖析表中关键字的散布,搜检表主如果搜检表中是不是存在毛病,优化表主如果消弭删除或更新形成的表空间糟蹋.

剖析表: 运用 ANALYZE 关键字,如ANALYZE TABLE user;

Op:示意实行的操纵.
Msg_type:信息范例,有status,info,note,warning,error.
Msg_text:显现信息.

搜检表: 运用 CHECK关键字,如CHECK TABLE user [option]

option 只对MyISAM有用,共五个参数值:

QUICK:不扫描行,不搜检毛病的衔接.

FAST:只搜检没有准确封闭的表.

CHANGED:只搜检上次搜检后被变动的表和没被准确封闭的表.

MEDIUM:扫描行,以考证被删除的衔接是有用的,也能够盘算各行关键字校验和.

EXTENDED:最周全的的搜检,对每行关键字周全查找.

优化表:运用OPTIMIZE关键字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;

LOCAL|NO_WRITE_TO_BINLOG都是示意不写入日记.,优化表只对VARCHAR,BLOB和TEXT有用,经由历程OPTIMIZE TABLE语句能够消弭文件碎片,在实行历程中会加上只读锁.

2.2 硬优化

2.2.1 硬件三件套

1、设置多中心和频次高的cpu,多中心能够实行多个线程.

2.设置大内存,进步内存,即可进步缓存区容量,因而能削减磁盘I/O时刻,从而进步响应速率.

3.设置高速磁盘或合理散布磁盘:高速磁盘进步I/O,散布磁盘能进步并行操纵的才能.

2.2.2 优化数据库参数

优化数据库参数能够进步资本利用率,从而进步MySQL效劳器机能.MySQL效劳的设置参数都在my.cnf或my.ini,下面列出机能影响较大的几个参数.

key_buffer_size:索引缓冲区大小

table_cache:能同时翻开表的个数

query_cache_size和query_cache_type:前者是查询缓冲区大小,后者是前面参数的开关,0示意不运用缓冲区,1示意运用缓冲区,但能够在查询中运用SQL_NO_CACHE示意不要运用缓冲区,2示意在查询中明确指出运用缓冲区才用缓冲区,即SQL_CACHE.

sort_buffer_size:排序缓冲区

传送门:更多参数

2.2.3 分库分表

由于数据库压力过大，起首一个题目就是高峰期体系机能可能会下降，由于数据库负载太高对机能会有影响。别的一个，压力过大把你的数据库给搞挂了怎么办？所以此时你必需得对体系做分库分表 + 读写星散，也就是把一个库拆分为多个库，布置在多个数据库效劳上，这时刻作为主库承载写入要求。然后每一个主库都挂载最少一个从库，由从库来承载读要求。

2.2.4 缓存集群

假如用户量越来越大，此时你能够不断的加机械，比如说体系层面不断加机械，就能够承载更高的并发要求。然后数据库层面假如写入并发越来越高，就扩容加数据库效劳器，经由历程分库分表是能够支撑扩容机械的，假如数据库层面的读并发越来越高，就扩容加更多的从库。然则这里有一个很大的题目：数据库实在自身不是用来承载高并发要求的，所以一般来讲，数据库单机每秒承载的并发就在几千的数量级，而且数据库运用的机械都是比较高设置，比较高贵的机械，本钱很高。假如你就是简朴的不断的加机械，实际上是不对的。所以在高并发架构里一般都有缓存这个环节，缓存体系的设想就是为了承载高并发而生。所以单机承载的并发量都在每秒几万，以至每秒数十万，对高并发的承载才能比数据库体系要凌驾一到两个数量级。所以你完全能够依据体系的营业特征，对那种写少读多的要求，引入缓存集群。具体来讲，就是在写数据库的时刻同时写一份数据到缓存集群里，然后用缓存集群来承载大部分的读要求。如许的话，经由历程缓存集群，就能够用更少的机械资本承载更高的并发。