超详细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数据库索引>一文,先容较量具体,此处记录行使索引的三大留意事项:

（1）LIKE要害字匹配'%'开头的字符串,不会行使索引.

（2）OR要害字的两个字段必需都是用了索引,该查询才会行使索引.

（3）行使多列索引必需满意最左匹配.

2.1.4 解析表

对付字段较多的表,假如某些字段行使频率较低,此时该当,将其疏散出来从而形成新的表,

2.1.5 中间表

对付将大量毗连查询的表可以建设中间表,从而镌汰在查询时造成的毗连耗时.

2.1.6 增进冗余字段

相同于建设中间表,增进冗余也是为了镌汰毗连查询.

2.1.7 说明表,,搜查表,优化表

说明表首要是说明表中要害字的漫衍,搜查表首要是搜查表中是否存在错误,优化表首要是消除删除或更新造成的表空间挥霍.

（1）说明表: 行使 ANALYZE 要害字,如ANALYZE TABLE user;

1.  Op:暗示执行的操纵.
2.  Msg_type:信息范例,有status,info,note,warning,error.
3. Msg_text:表现信息.

（2）搜查表: 行使 CHECK要害字,如CHECK TABLE user [option]

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

1. QUICK:不扫描行,不搜查错误的毗连.
2. FAST:只搜查没有正确封锁的表.
3. CHANGED:只搜查前次搜查后被变动的表和没被正确封锁的表.
4. MEDIUM:扫描行,以验证被删除的毗连是有用的,也可以计较各行要害字校验和.
5. EXTENDED:最全面的的搜查,对每行要害字全面查找.

（3） 优化表:行使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 缓存集群

假如用户量越来越大，此时你可以不断的加呆板，好比说体系层面不断加呆板，就可以承载更高的并发哀求。然后数据库层面假如写入并发越来越高，就扩容加数据库处事器，通过度库分表是可以支持扩容呆板的，假如数据库层面的读并发越来越高，就扩容加更多的从库。可是这里有一个很大的题目：数据库着实自己不是用来承载高并发哀求的，以是凡是来说，数据库单机每秒承载的并发就在几千的数目级，并且数据库行使的呆板都是较量高设置，较量昂贵的呆板，本钱很高。假如你就是简朴的不断的加呆板，着实是差池的。以是在高并发架构里凡是都有缓存这个环节，缓存体系的计划就是为了承载高并发而生。以是单机承载的并发量都在每秒几万，，乃至每秒数十万，对高并发的承载手段比数据库体系要跨越一到两个数目级。以是你完全可以按照体系的营业特征，对那种写少读多的哀求，引入缓存集群。详细来说，就是在写数据库的时辰同时写一份数据到缓存集群里，然后用缓存集群来承载大部门的读哀求。这样的话，通过缓存集群，就可以用更少的呆板资源承载更高的并发。

结语

一个完备而伟大的高并发体系架构中，必然会包括：各类伟大的自研基本架构体系。各类精妙的架构计划.因此一篇小文顶多具有抛砖引玉的结果,可是数据库优化的头脑差不多就这些了.

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!