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

　　一、监控

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

　　二、调优

　　2.1 DB层操作和调优

　　2.1.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.2 mysqldumpslow分析慢查询。

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

　　Mysqldumpslow 分析慢查询日志

　　其参数说明：

• 　　-s 排序方式 c,t,l,r 四个参数分别表示记录次数、时间、查询时间的多少和返回记录次数排序。
• 　　-t 返回前面多少条数据
• 　　-g 正则表达式匹配日志内容

　　2.1.3、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.4 分析后调优，优化索引

　　根据每个sql语句的表现的不同，在相应的字段上加索引，索引一般加在sql语句中的where字句相关的字段上。

　　2.2 Cache层的操作和调优

　　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%’

1. 　　qcache_free_blocks:数目大说明有碎片
2. 　　qcache_free_memory:缓存中的空闲内存
3. 　　qcache_hits:命中次数，每次查询在缓存中命中就增加
4. 　　qcache_inserts:缓存中插入查询次数，每次插入就增加
5. 　　qcache_lowmem_prunes:这个数字增长，表明碎片多或内存少
6. 　　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反范式设计

　　  在实际工作中，当获得某些信息过于频繁时，我们一般采用反范式设计，这样能够避免多表的关键查询，让数据略有冗余，换来的是查询速度的提高。