原文请详见：http://www.ucai.cn/blogdetail/7036?mid=1&f=5
能够在线执行查看效果哦！
本文依据优才网课程整理，面向web开发人员，内容以有用为主，专业DBA能够绕行。
假设你在大公司，可能有专门的DBA来做这些事情，假设你在一个小公司当架构师或者技术总监，或者你自己创业，那DBA的活你也得干了。咱们来讲一下主要的mysql安装和优化。
一： MYSQL安装和基本配置
在linux上安装，能够用包管理工具来安装，比較简单：
RedHat 系列：yum -yinstall mysql mysql-server
Debian系列：sudo apt-getinstall mysql mysql-server
安装之后不知道mysql装到哪了怎么办，用whereis mysql 命令来找一下。先找到mysql的默认配置文件。一般来说，安装后有这么几个备选的配置：my-huge.cnf my-innodb-heavy-4G.cnf my-large.cnf my-medium.cnf my-small.cnf
就2014年的机器配置来说，咱们直接用my-huge.cnf。把my-huge.cnf 拷贝到/etc/下，改名my.cnf。配置文件就有了，然后启动mysql： /etc/init.d/mysqld start 。
安装之后默认的帐号是root, password为空。咱们要做的第一件事是改rootpassword。
进入mysql：mysql -uroot -p
选择数据库： use mysql
改password： UPDATE user SET Password = PASSWORD('xxxx') WHERE user = 'root';
刷新权限： FLUSH PRIVILEGES;
如今数据库装好了，帐号和权限也设置了，是不是就能够使用了呢,还要检查几个配置。打开配置文件 vim /etc/my.cnf
skip-networking 要关闭。
bind-address = 127.0.0.1 这一行要关闭或者改动成同意的IP
skip-name-resolve 禁止dns解析，仅仅能用IP连，这个能够打开。
假设你的mysql经过一段时间执行，挺过了訪问高峰，咱们再来检查一下配置是否合适。以下说的配置，都必须是在执行一段时间后检查才有意义。假设刚启动没多久，mysql的执行状态没有代表性，不能作为參考。检查配置參数也没意义。
二：连接数(connection)配置
max_connections 能够设置最大并发连接数。当MySql的并发连接达到这个设定值时，新的连接将会被拒绝（“Can not connect to MySQL server. Too many connections”-mysql 1040错误，）。当发现MySql有能力处理很多其它的并发的时候， 建议调大这个值，对应给服务器带来更高的负载(CPU/IO/内存)。
查看设置的最大连接是多少：
mysql> show variables like 'max_connections';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 151 | 同意的最大连接数
+-----------------+-------+
看当前连接数：showstatus like 'threads_connected';
最大连接数: show status like "max_used_connections";
假设max_used_connections已经接近 max_connections了，就说明max_connections太小。不合适了。
另一些跟连接数相关的配置：
back_log=50
MySQL能暂存的连接数量。当主要MySQL线程在一个非常短时间内得到非常多的连接请求，这就起作用。假设MySQL的连接数据达到max_connections时，新来的请求将会被存在堆栈中，以等待某一连接释放资源，该堆栈的数量即back_log，假设等待连接的数量超过back_log，将不被授予连接资源。
back_log值指出在MySQL临时停止回答新请求之前的短时间内有多少个请求能够被存在堆栈中。仅仅有假设期望在一个短时间内有非常多连接，你须要添加它，换句话说，这值对到来的TCP/IP连接的侦听队列的大小。
不同的操作系统在这个队列大小上有它自己的限制。试图设定back_log高于你的操作系统的限制将是无效的。默认值为50。对于Linux系统推荐设置为小于512的整数。
假设链接数超过max_connections+back_log ，才会出错。
max_connect_errors=10
当client连接服务端超时(超过connect_timeout), 服务端就会给这个client记录一次error，当出错的次数达到max_connect_errors的时候，这个client就会被锁定。除非运行FLUSH HOSTS命令。
connect_timeout=5
连接超时的秒数
三：查询缓存(query_cache)配置
查询缓存就是内存中的一块存储区域，其存储了用户的SQL文本以及相关的查询结果。通常情况下，用户下次查询时，假设所使用的SQL文本是相同的，而且自从上次查询后，相关的纪录没有被更新过，此时数据库就直接採用缓存中的内容。从内存中读取要比从硬盘上速度要快好几百倍。MYSQL的查询缓存用于缓存select查询结果，并在下次接收到相同的查询请求时，不再运行实际查询处理而直接返回结果，有这种查询缓存能提高查询的速度，使查询性能得到优化.
要使用缓存，有几个条件：一是所採用的SQL语句是同样的。每次查询的语句不一样，肯定不能用到缓存。比方语句里带当前秒数 where ctime > xxx；二是表数据没有改过。没有改过结构，没有update，insert；三、client与server的默认字符集得一样。所以能够看出，要利用好缓存，有大量的同样的查询，而非常少改变表里的数据，否则没有必要使用此功能。
查看查询缓存的设置：
SHOW VARIABLES LIKE '%query_cache%'; +------------------------------+----------+ | Variable_name | Value | +------------------------------+----------+ | have_query_cache | YES | | query_cache_limit | 1048576 | 假设单个查询结果大于这个值，则不Cache | query_cache_min_res_unit | 4096 | 每次给QC结果分配内存的大小 | query_cache_size | 33554432 | | query_cache_type | ON | | query_cache_wlock_invalidate | OFF | +------------------------------+----------+
query_cache_type=1
假设设置为1，将会缓存全部的结果，除非你的select语句使用SQL_NO_CACHE禁用了查询缓存。假设设置为2，则仅仅缓存在select语句中通过SQL_CACHE指定须要缓存的查询。query_cache_size 默认是32M，太小了，可调到128M或者256M。 能够通过Qcache_lowmem_prunes变量的值来检查是否当前的值满足你眼下系统的负载。
query_cache_size的工作原理：一个SELECT查询在DB中工作后，DB会把该语句缓存下来，当相同的一个SQL再次来到DB里调用时，DB在该表没发生变化的情况下把结果从缓存中返回给Client。这里有一个关建点，就是DB在利用Query_cache工作时，要求该语句涉及的表在这段时间内没有发生变更。那假设该表在发生变更时，Query_cache里的数据又怎么处理呢？
首先要把Query_cache和该表相关的语句所有置为失效，然后在写入更新。那么假设Query_cache非常大，该表的查询结构又比較多，查询语句失效也慢，一个更新或是Insert就会非常慢，这样看到的就是Update或是Insert怎么这么慢了。所以在数据库写入量或是更新量也比較大的系统，该參数不适合分配过大。并且在高并发，写入量大的系统，建系把该功能禁掉。
Qcache_lowmem_prunes能够检查是否设置的太小。query_cache_limit 默认是1M，依据你的经常使用查询的数据结果大小来定。假设返回的数据小，能够设置小一点。设置值大对大数据查询有优点，但假设你的查询都是小数据查询，就easy造成内存碎片和浪费。
查看缓存使用效果怎样：
showstatus like '%Qcache%';
+-------------------------+----------+
| Variable_name | Value |
+-------------------------+----------+
| Qcache_free_blocks | 160 | 眼下还处于空暇状态的 Query Cache中内存 Block 数目，数目大说明可能有碎片。FLUSH QUERY CACHE会对缓存中的碎片进行整理，从而得到一个空暇块。
| Qcache_free_memory | 23147296 | 缓存中的空暇内存总量。
| Qcache_hits | 52349 | 缓存命中次数。
| Qcache_inserts | 8827 | 缓存失效次数。
| Qcache_lowmem_prunes | 0 | 缓存出现内存不足而且必需要进行清理以便为很多其它查询提供空间的次数。这个数字最好长时间来看；假设这个数字在不断增长，就表示可能碎片非常严重，或者内存非常少。
| Qcache_not_cached | 2446 | 没有被cache和不适合进行缓存的查询的数量，一般是因为这些查询不是SELECT语句以及因为query_cache_type设置的不会被Cache的查询。show,use,desc
| Qcache_queries_in_cache | 5234 | 当前被cache的SQL数量。
| Qcache_total_blocks | 10796 | 缓存中块的数量。
+-------------------------+----------+
show global status like 'Com_select';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Com_select | 12592 | com_select 变量记录的是无缓存的查询次数+错误查询+权限检查查询。
+---------------+-------+
Mysql的查询缓存命中率没有官方算法，仅仅有前人的经验总结
命中率≈ qcache_hits / (qcache_hits + com_select)
缓存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100% ,假设碎片率太高，20% ，能够FLUSHQUERY CACHE整理缓存碎片，或者试试减小query_cache_min_res_unit，假设你的查询都是小数据量的话。
查询缓存利用率 = (query_cache_size – Qcache_free_memory) / query_cache_size * 100%
#查询缓存利用率在25%下面的话说明query_cache_size设置的过大，可适当减小;查询缓存利用率在80%以上并且Qcache_lowmem_prunes> 50的话说明query_cache_size可能有点小，要不就是碎片太多。
怎样提高命中率：
1、字符集同样；2、SQL语句尽量固定(SQL语句避免随机数，秒数等)；3、 加大缓存空间； 4、适当分表,动静分离。
四、暂时表缓存(tmp_table_size)配置
mysql进行复杂查询或者 做高级GROUP BY操作的时候，系统为了优化查询，生成一些暂时表。通过设置tmp_table_size选项来设置暂时表占用空间的大小。我们使用explain分析SQL，假设在Extra列看到Using temporary就意味着使用了暂时表。
MySQL暂时表分为“内存暂时表”和“磁盘暂时表”，当中内存暂时表使用MySQL的MEMORY存储引擎，磁盘暂时表使用MySQL的MyISAM存储引擎。普通情况下，MySQL会先创建内存暂时表，但内存暂时表超过配置指定的值后，MySQL会将内存暂时表导出到磁盘暂时表。暂时表将在你连接MySQL期间存在。当你断开时，MySQL将自己主动删除表并释放所用的空间。
mysql> SHOW VARIABLES LIKE'%tmp_table_size%'; +----------------+----------+ | Variable_name | Value | +----------------+----------+ | tmp_table_size | 33554432 | +----------------+----------+ 1 row in set (0.00 sec) mysql> show global status like'created_tmp%'; +-------------------------+----------+ | Variable_name | Value | +-------------------------+----------+
| Created_tmp_disk_tables | 690421 | server运行语句时在硬盘上自己主动创建的暂时表的数量；
| Created_tmp_files | 755473 | mysqld已经创建的暂时文件的数量；
| Created_tmp_tables | 14372959 | server运行语句时自己主动创建的内存中的暂时表的数量。假设Created_tmp_disk_tables较大，你可能要添加tmp_table_size值使暂时 表基于内存而不基于硬盘；
+-------------------------+----------+
每次创建暂时表，Created_tmp_tables添加，假设暂时表大小超过tmp_table_size，则是在磁盘上创建暂时表，Created_tmp_disk_tables也添加,Created_tmp_files表示MySQL服务创建的暂时文件文件数，比較理想的配置是：Created_tmp_disk_tables /Created_tmp_tables * 100% <= 25%
比方上面的serverCreated_tmp_disk_tables / Created_tmp_tables * 100% ＝1.20%，应该相当好了。默认大小是 32M，可调到64-256最佳，线程独占，太大可能内存不够I/O阻塞。
跟暂时表相关的还有一配置是max_heap_table_size ，用户能够创建的独立的内存表所同意的最大容量.这个变量不适用与用户创建的内存表(memory table).SHOW VARIABLES LIKE'%max_heap_table_size%'; 咱们希望暂时表是放到内存的。所以这个值设置的暂时表缓存的空间一样即可。
（实际起限制作用的是tmp_table_size和max_heap_table_size的最小值。）假设暂时表大于这两个的不论什么一个，都会存硬盘缓存：自己主动地把它转化为基于磁盘的MyISAM表，存储在指定的tmpdir文件夹下。
五、索引缓冲区（key_buffer_size）配置
key_buffer_size是对MyISAM表性能影响最大的一个參数.key_buffer_size指定索引缓冲区的大小，它决定索引处理的速度，尤其是索引读的速度。通过检查状态值Key_read_requests和Key_reads，能够知道key_buffer_size设置是否合理。比例key_reads /key_read_requests应该尽可能的低，至少是1:100，1:1000更好。
key_buffer_size仅仅对MyISAM表起作用。即使你不使用MyISAM表，可是内部的暂时磁盘表是MyISAM表，也要使用该值。能够使用检查状态值created_tmp_disk_tables得知详情。
mysql> show variables like'key_buffer_size'; +-----------------+----------+ | Variable_name | Value | +-----------------+----------+ | key_buffer_size | 67108864 | 索引缓冲区的大小 +-----------------+----------+ show variables like 'key_cache_block_size'; mysql> show global status like 'key%'; +------------------------+------------+ | Variable_name | Value | +------------------------+------------+
| Key_blocks_not_flushed | 0 |索引缓存内已经更改，但还没有清空到硬盘上的索引的数据块数量。
| Key_blocks_unused | 0 | 索引缓存内未使用的块数量。你能够使用该值来确定使用了多少键缓存
| Key_blocks_used | 53585 | 索引缓存内使用的块数量。该值为高水平线标记，说明已经同一时候最多使用了多少块。
| Key_read_requests | 4952122733 | 一共同拥有XXX个索引读取请求，
| Key_reads | 11879 | 索引读取请求在内存中没有找到，直接从硬盘读取索引
| Key_write_requests | 10508455 | 将索引的数据块写入缓存的请求数。
| Key_writes | 6042774 | 将索引向硬盘写入数据块的物理写操作的次数。
+------------------------+------------+
比例key_reads /key_read_requests应该尽可能的低，至少是1:100，1:1000更好；
假设Key_reads太大,则应该把my.cnf中key_buffer_size变大.能够用Key_reads/Key_read_requests计算出cache失败率；
Key_writes/Key_write_requests：比例接近1较好。
别人的经验是内存在4GB左右的server该參数可设置为384M或512M。能够自己算一下自己数据库的索引文件大小。注意：该參数值设置的过大反而会是server总体效率减少！
Cache命中比率：
1 - Key_reads / Key_read_requests
Key buffer的使用率
100 – ( (Key_blocks_unused *key_cache_block_size) * 100 / key_buffer_size )