mysql监控、性能调优及三范式理解

1监控

         工具：sp on mysql     sp系列可监控各类数据库

 

2调优

2.1 DB层操做与调优

              2.1.一、开启慢查询

                            在My.cnf文件中添加以下内容（若是不知道my.cnf的路径可以使用find / -name my.cnf进行查找）：

                            在mysqld下添加

                            Log_slow_queries = ON  做用：开启慢查询服务

                            Log-slow-queries = /var/log/slowqueries.log 做用：慢查询日志存储路径。

                            Long_query_time = 1 做用：定义慢查询时间长度，默认为10

                            添加以上内容后使用service mysqld restart 重启mysql服务

                            重启后使用 show variables like ‘%slow%’查看慢查询开启状态

                            如slow_query_log 和 log_slow_queries 两个字段的值都显示为ON，那么说明慢查询开启成功。

              2.1.二、mysqldumpslow分析慢查询。

                   切换到慢查询存储路径下 cd /var/log 使用 ll 命令查看文件，若是slowqueries.log 的文件的大小变大，有内容说明已经捕捉到慢查询语句，或者使用cat 、more 、less 、vi 等命令进入文件内部进行查看，有内容说明捕捉到慢查询。

Mysqldumpslow 分析慢查询日志

                                               参数说明：

                                                        -s 排序方式 c,t,l,r 四个参数分别表示记录次数、时间、查询时间的多少和返回记录次数排序。

                                                        -t 返回前面多少条数据

                                                        -g 正则表达式匹配日志内容

 

              2.1.三、explain执行计划进行sql语句分析

                                     Explain分析捕捉到的select语句

                                     用法：explain 后边直接加select 语句。

                                               重点：type列

                                               指标说明：（从左到右，性能由差到好）

                                                                 All,index ,range,ref,,eq_ref,const or system ,null

                                               重点：extra

                                               指标说明：

                                                                 Only index 使用到了索引

                                                                 Where used 使用到了where限制

                                                                 Using filesort 使用了全文排序

                                                                 Using temporary 使用到了临时表

                                               当extra里显示有using filesort 或 using temporary 时，sql的执行就会很吃力，时间就会增长。

 

              2.1.四、分析后调优，优化索引

                                     根据每一个sql语句的表现不一样，在相应的字段上加索引

                                     索引通常加在sql语句中的where字句相关的字段上。

 

2.2Cache层的操做与调优

2.2.1开启query cache

在my.cnf里mysqld下添加：

                             Query_cache_size = 268435456

使用的内存大小， 这个值必须是1024的整数倍

                             Query_cache_type = 1

                             此字段值能够0,1,2 三个值

                             0,表明关闭

                             1表明给全部的select语句作cache

                                       当语句select no_no_cache * from A;执行时不作cache

                             2表明开启query cache功能，但只有执行

                                                语句select sql_cache * from A; 时才作cache

                             Query_cache_limit = 1048576

                             单条语句的最大容量限制，超过此容量的sql语句讲不被cache

 

当作cache时需注意，只有彻底相同的sql语句才被认为是相同的，此时才可以从缓存当中取数据，增长sql执行速度。

若是cache不合理，会致使大量的清缓存，加cache的动做，不但不会增长sql执行速度，反而会下降效率。如：当某表中有大量的插入，删除，修改等操做时，就不适合作cache。

 

2.2.2query cache 运行状态分析

show status like ‘%qcache%’

                    qcache_free_blocks:数目大说明有碎片

                    qcache_free_memory:缓存中的空闲内存

                    qcache_hits:命中次数，每次查询在缓存中命中就增长

                    qcache_inserts:缓存中插入查询次数，每次插入就增长

                    qcache_lowmem_prunes:这个数字增加，代表碎片多或内存少

                    qcache_total_blocks:缓存中块的总数量

2.2.3计算

　　　　Query_cache命中率=query_hits/(qcache_hits+qcache_inserts)

　　　　缓存碎片率=qcache_free_blocks/qcache_total_blocks*100%

                    碎片率超过20%时，可用flush query cache整理缓存碎片

　　　　缓存利用率=（query_cache_size-qcache_free_memory）/query_cache_size*100%

 

2.2.4 qchche优化

         整理全部查询的sql，讲全部须要返回结果相同以及查询方法相同的sql整理后写成如出一辙的，或使用mybatis框架，把全部的sql写到配置文件中，使用的时候调用。

缘由是，只有如出一辙的sql语句，才会在cache中取结果。

 

 

2.3 mysql配置优化

2.3.1 back_log

要求 MySQL 能有的链接数量。当主要MySQL线程在一个很短期内获得很是多的链接请求，这就起做用，而后主线程花些时间(尽管很短)检查链接而且启动一个新线程。

back_log 值指出在MySQL暂时中止回答新请求以前的短期内多少个请求能够被存在堆栈中。只有若是指望在一个短期内有不少链接，你须要增长它，换句话说，这值 对到来的TCP/IP链接的侦听队列的大小。你的操做系统在这个队列大小上有它本身的限制。 试图设定back_log高于你的操做系统的限制将是无效的。

当你观察你的主机进程列表，发现大量 264084 | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待链接进程时，就要加大 back_log 的值了。默认数值是50，我把它改成500。

2.3.2interactive_timeout

服务器在关闭它前在一个交互链接上等待行动的秒数。一个交互的客户被定义为对 mysql_real_connect()使用 CLIENT_INTERACTIVE 选项的客户。 默认数值是28800，我把它改成7200。

2.3.3 key_buffer_size

索引块是缓冲的而且被全部的线程共享。key_buffer_size是用于索引块的缓冲区大小，增长它可获得更好处理的索引(对全部读和多重 写)，到你 能负担得起那样多。若是你使它太大，系统将开始换页而且真的变慢了。默认数值是8388600(8M)，个人MySQL主机有2GB内存，因此我把它改成 402649088(400MB)。

2.3.4 max_connections

容许的同时客户的数量。增长该值增长 mysqld 要求的文件描述符的数量。这个数字应该增长，不然，你将常常看到 Too many connections 错误。 默认数值是100，我把它改成1024 。

2.3.5 record_buffer

每一个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区。若是你作不少顺序扫描，你可能想要增长该值。默认数值是 131072(128K)，我把它改成16773120 (16M)

2.3.6 sort_buffer

每一个须要进行排序的线程分配该大小的一个缓冲区。增长这值加速ORDER BY或GROUP BY操做。默认数值是2097144(2M)，我把它改成 16777208 (16M)。

2.3.7 table_cache

为全部线程打开表的数量。增长该值能增长mysqld要求的文件描述符的数量。MySQL对每一个惟一打开的表须要2个文件描述符。默认数值是64， 我把它改成512。

2.3.8 thread_cache_size

能够复用的保存在中的线程的数量。若是有，新的线程从缓存中取得，当断开链接的时候若是有空间，客户的线置在缓存中。若是有不少新的线程，为了提升 性能可 以这个变量值。经过比较 Connections 和 Threads_created 状态的变量，能够看到这个变量的做用。我把它设置为 80。

2.3.9 wait_timeout

服务器在关闭它以前在一个链接上等待行动的秒数。 默认数值是28800，我把它改成7200。

注：参数的调整能够经过修改 /etc/my.cnf 文件并重启 MySQL 实现。这是一个比较谨慎的工做，上面的结果也仅仅是个人一些见解，你能够根据你本身主机的硬件状况(特别是内存大小)进一步修改。

2.4 数据库设计模型

2.4.1范式设计

2.4.1.1 一范式

须要保持每一列的原子性

例：电话号码：86-010-11111111

若是要符合一范式，那么须要把电话号码拆分为国家号码、区号、电话号码进行存储，达到每一列不可以再拆分。

符合原子性的标准即为一范式

2.4.1.2 二范式

首先必须符合一范式。

另外须要知足，每个表必须有主键

除主键外其余的列必须和主键相关，不能只与主键的某一个部分相关

例如一个表有一个联合主键，而部分数据是与联合主键相关而不与主键相关，那么这时须要把表拆开，使得每一列都与主键相关。

 

2.4.1.3 三范式

首先必须符合二范式

另外须要知足，每个非主键列必须直接依赖主键，而不能存在传递依赖。

 

2.4.1.4 范式设计的优势

范式设计能够避免数据冗余，减小数据库的使用空间，减轻维护数据完整性的麻烦。

2.4.1.5范式设计的缺点

 

符合范式设计的级别越高，那么拆分出来的表越多，想得到一个完整的数据的时候联合查询的时候所关联的表就越多，直接带来的问题就是性能的降低。

 

1.2.4.2反范式设计

在实际工做中，对于得到某些信息过于频繁时，咱们通常采用反范式设计，这样就避免了多表的关键查询，让数据略有冗余，换来的是查询速度的提升。