1监控
工具：sp on mysql sp系列可监控各种数据库
2调优
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.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反范式设计
在实际工作中，对于获得某些信息过于频繁时，我们一般采用反范式设计，这样就避免了多表的关键查询，让数据略有冗余，换来的是查询速度的提高。