首先给大家介绍一下数据库project师，数据库project师(Database Engineer)，是从事管理和维护数据库管理系统(DBMS)

摘要

MySQL的最初的核心思想，主要是开源、简便易用。其开发可追溯至1985年，而第一个内部发行版本号诞生，已经是1995年。

到1998年，MySQL已经能够支持10中操作系统了。当中就包含win平台。

此文档将从安装開始带领着读者一步步深入了解mySQL相关功能，该文由作者多年实战经验的总結而组成，当中包含例如以下内容：

• 近几十条优化经验
• mySQL集群、主备
• 多种SQL优化分析手段
• mySQL读写分离
• mySQL横向及垂直折分

面向读者

该文适用于Linux CENTOS6.X及以上相关环境，mySQL版本号为：5.x及以上。
本文读者须要具备0基础Linux系统使用的相关经验。
MYSQL的历史
MySQL的爆发实际是在01、02年。尤其是02年公布的4.0 Beta版，正式选定InnoDB作为默认引擎。对事务处理能力及数据缓存能力有了极大的提高。

同年4.1版開始支持子查询，至此MySQL最终蜕变成一个成熟的关系型数据库系统。05年的5.0版本号又加入了存储过程、服务端游标、触发器、查询优化以及分布式事务功能，但同年被Oracle抄了后路，InnoDB被Oracle收编。08年，MySQL被Sun收购，09年。Oracle收购了Sun和MySQL。

MySQL最大的一个特色，就是自由选择存储引擎。

每一个表都是一个文件，都能够选择合适的存储引擎。常见的引擎有 InnoDB、 MyISAM、 NDBCluster等。

但由于这种开放插件式的存储引擎，比方要求数据库与引擎之间的松耦合关系。

从而导致文件的一致性大大降低。在SQL运行优化方面，也就有着一些不可避免的瓶颈。在多表关联、子查询优化、统计函数等方面是软肋，并且仅仅支持极简单的HINT。

去IOE大潮下的MYSQL与PostgreSQL的比較

PostgreSQL

PostgreSQL官方宣称的是：“The world’s most advanced open source database”。most advanced我不知道是怎么定义的。由于PosgreSQL还是传统B+树索引的数据库，在一些场景下，比方全插入场景，其还是会比其它一些数据库要来得差非常多，比方TokuDB，MongoDB。撇开这部分的因素。不得不承认PostgreSQL是最为强大的开源数据库，也许，可是Oracle依旧才是最为强大的关系型数据库。

PostgreSQL阵营一直标榜自己在优化器和Oracle可移植性方面的优势，我想这对照MySQL也许是成立的。

然而，假设上述都成立的话，为什么PostgreSQL在装机量，流行度等指标上上远远地被后起之秀MySQL给超越了呢？全球前20大站点全然看不到PostgreSQL的身影呢？在写本篇文章的时候，我倏地想到了一个相似的问题，业界公认手机质量最好的Nokia。最终为什么会倒下？

下图是一个mySQL在大型站点和系统中的应用案例统计。

PostgreSQL还有一个痛点。我想非常多人没有会意识到的，就是在在线事务（OLTP）方面的性能问题。

PostgreSQL在功能方面也许是比較完整的。可是真的要进入到生产环节，看的不再是简单的功能。由于大部分用户都明确日常所使用的仅是数据库提供的20%功能。MySQL 5.7如今已经能够轻松达到50W QPS的性能。并支持通过NoSQL接口能够达到100W QPS。这是PostgreSQL为什么没有能在互联网时代站住脚跟的一个重要原因之中的一个。在线事务对性能的要求之苛刻，是普通用户所无法感知的。

PostgreSQL最大的优势是在线分析的场景，由于其优化器对于Join的支持堪称全面。对于复杂查询有着良好的支持。从Oracle迁移到PostgreSQL的成本会比較低。基于PostgreSQL的GreenPlum也已经开源。因此PostgreSQL眼下在这方便是较为率先的。

MYSQL

MySQL数据库官方的口号是：“ The world’s most popular open source database.”。对照PostgreSQL。这句话简直无法攻击。并且MySQL官方的目标也一直是成为最为流行的数据库。通过互联网浪潮，移动互联的时代，MySQL是真的做到了。
MySQL的优势是开源与开放性架构，使其拥有有着各种分支版本号与存储引擎可供选择。除了官方的InnoDB存储引擎，还有TokuDB。Infobright引擎可在特定场合下进行使用。也正是由于MySQL的开源与开放，使得大量的开发者加入到了MySQL的环抱。

MySQL是一个非常成功的开源项目。可能非常多人忽略了这个重要的因素。
MySQL被Oracle收购后表现的越来越好。一方面是功能越来越与Oracle数据库接近。非常多时候给我的感觉就是开源的Oracle数据库。还有一个重要的改进就是bug越来越少，甚至非常多遗留了有近10年的bug也已一一修复。官方这样严谨的态度。使得MySQL逐渐站稳了并開始蚕食一部分的企业市场。世界500强的选择就是最好的证明。

下图是一个mySQL在大型站点和系统中的应用案例统计。

MySQL在性能与流行度上的优势我不想再做过多的笔墨，由于这是不论什么人都无法回避的事实。MySQL数据库之前被PostgreSQL阵营攻击就是优化器，对于多表JOIN的性能以及不支持Hash Join。

然而。非常多人没有意识到，MySQL已经在5.6版本号支持了MRR（Multi-Range Read）。ICP（Index Condition Pushdown），BKA（Batched Key Access ）Join这些优化，多表的JOIN性能已经得到了非常大幅度的提升。不是否能则，MySQL依旧不支持Hash Join，可是这些优化的引入已经使得MySQL的Join性能提升到了一个新台阶。

同一时候，在在线分析的领域。用户真的不关心使用Hash Join能够5分钟出报表，而是用MySQL须要8分钟，这些时间全然是能够容忍的。

然在在线事务领域，0.1的时间都是所不能容忍的。因此。本人在这里呼吁。尝试升级MySQL到5.6，5.7版本号。而不要依旧停留在5.1或者5.5版本号。
MySQL替换Oracle还有一个被诟病的就是没有Oracle的透明网关(Transparent Gateway)功能。MySQL自带的Fedorate存储引擎支持MySQL数据库间的查询。不支持异构数据库之前的查询。然而，这个问题已经给MariaDB解决，用户仅仅须要通过Connect存储引擎，就能达到相似Oracle透明网关的功能。

另外。还实用户提出MySQL不支持分区的全局索引，物化视图等。事实上这些都能够通过变通的方法实现，如：Amoeba原虫或者是最先进的mycat。这些技术也在网易、淘宝这种互联网公司使用。

即使官方的MySQL无法满足你的需求，可是用户依旧有InfoBright与TokuDB存储引擎的选择。

InfoBright是列存的数据库引擎，非常适用于在线分析领域，这点连PostgreSQL都无法进行匹敌。

TokuDB是一种相似LSM数据结构的数据引擎，在大并发的插入生产环境下。其对照各种传统数据库都有着显著的优势，即使对照PostgreSQL与Oracle数据库本身。总之，MySQL能够在各种维度满足用户对于数据库的各种需求。
PosgreSQL与MySQL对照，最为关键的是整个人才的储备。看看中国的互联网公司基本都已将MySQL数据库作为标配，而PostgreSQL甚至连备胎都无法入选。MySQL在互联网行业积累了大量的高可用架构，分布式架构与灾备经验，可是PostgreSQL差点儿为0。

再看看图书市场。PostgreSQL凤毛菱角。而MySQL则有非常好的书籍供DBA。开发者，架构师等学习。然即使如此，MySQL离Oracle数据库本身的积累还有非常长的路要走。

去IOE

去IOE最早是由淘宝提出，旨在去除IT架构中的IBM小型机，Oracle数据库。EMC存储。去IE是比較简单的事情，由于这仅是硬件的替换。

另外，X86技术也越来越成熟，稳定性与小机的差距不断缩小。

然而去Oracle数据库才是淘宝去IOE的难点与精华所在。整个去Oracle历时3。4年的时间。

当中伴随着功能内部project师的质疑，大量Oracle人才的流失，但最终已经证明了MySQL数据库替代Oracle的可行性。
笔者高兴的是传统企业也開始有这种“觉悟”開始逐步进行去IOE的尝试，无论这种尝试是主动还是被动。但都是值得尊敬的行为。原因在于去Oracle数据库这件事情并不那么简单。数据库是传统企业最为核心的资产，不论什么损失都是不可接受的。

而去年银监会的39号文件也坚定了传统企业的去IOE决心。
去IOE风潮显现，一大帮的公司開始进入到这个领域。希望借助这阵风来大赚一笔。这点本无可非议，市场与技术相辅相成。然而。有一个非常不好的现象是，非常多公司是为了迎合某些领导的须要。而不是真正的为传统企业构建面向互联网+的安全可控的技术架构。而这当中有着一些不为人知的因素。
首当其冲的是领导们的绩效。传统企业做事，以绩效为导向，这与互联网行业并无不同。可是互联网行业有着技术积累，并且对于技术的选型与转型有着相当的耐心。从淘宝去Oracle用了3。4年就能够看出。

而眼下摆在传统企业领导面前的现实却是，有ZF文件要求各银行业金融机构对安全可控信息技术的应用以不低于15％的比例逐年添加，直至2019年达到不低于75％的总体占比。
有一些传统企业的朋友。领导要求他们用PostgreSQL替换Oracle数据库。原因在于这是“最快”的替换Oracle成本，可是他们站在IT从业人员的角度来看这件事是不正确的，有种敢怒不敢言。

当然，这当中也有部分商业公司在当中推动的关系。可是明确人心里都知道，PostgreSQL国内从业人员寥寥。之前在中国没有大规模的使用经验与架构设计。大多停留在找个文档折腾下的水平上。所谓“最快”的替换方案仅是由于不用进行存储过程的移植，假设仅仅是这样使用PostgreSQL，那么仅是应付上层的文件。而没有真正领会到文件的精神。更有商业公司号称有PostgreSQL的专家。然而非常经不起推敲，玩过GreenPlum的就是PostgreSQL专家？并且GreenPlum也仅做研究性质的用途？与专家交流后发现其对锁与并发。高可用这块的掌握更是让人触目惊心。

所以笔者一再和身边的朋友说，去IOE不是一件一蹴而就的事情，须要给MySQL时间，否则这件好事情会像着还有一个方向而发展，甚至反复当年年Sybase替换Oracle的事件发生。

可是好消息是这次的上层领导们最终開始认识到互联网的重要性。理解了安全可控对于一个国家的重要性，而互联网公司的成熟经验具有非常好的借鉴意义。

总结

MySQL数据库早已不是原来的迷你数据库。其在功能性与性能方面都已经大幅提升，随着SSD的崛起。MySQL数据库已经全然能够替换Oracle数据，而PostgreSQL还须要非常长的路要走。

但市场是开放的。就像Oracle称雄的年代，还有DB2，Sybase这种数据库与之中的一个较长短。我相信互联网时代，依旧是百花齐放的年代。没有谁能够一直占据优势，即便是MySQL也没有这个能力。

安装

升级yum

yum update

由于centos刚安装完后它的yum repo不一定为最新，为保持今后使用yum安装的各类软件始终为最新最稳定版，请升级你的yum。

另外，假设不及时升级yum有时还会碰到在yum install时系统提示“找不到相关的安装包”这种错误。

安装mysql

yum install -y mysql-server mysql mysql-devel s.

在等待了一番时间后，yum会帮我们选择好安装mysql数据库所须要的软件以及其它附属的一些软件。

在此，我安装的是mysql5.1，读者能够依据自己的实际环境如：centos7.x的环境下将安装更高版的mySQL。
当出现以下的结果时。就代表mysql数据库成功安装了。

你能够使用例如以下命令启动和停止mySQL。

启动：

service mysqld start

停止：

service mysqld stop

重新启动：

service mysqld restart

mySQL的配置与优化

配件文件所在路径

mySQL安装完后会生成例如以下几个关键文件夹：

• 核心配置文件 my.cnf，它位于/etc/文件夹下
• 日志文件，它们位于/var/log文件夹
• Binlog、运行时的.sock文件以及数据文件默认位于/var/lib/mysql文件夹下

核心配置文件

改动my.cnf文件，先来看看我本机的my.cnf的配置

[mysqld]
init_connect='SET autocommit=0'
server-id=101
log-bin=master-bin
log-bin-index=master-bin.index
lower_case_table_names=1
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
skip-external-locking
skip-name-resolve
back_log=384
key_buffer_size=512M
max_allowed_packet=6M
thread_stack=1024k
sort_buffer_size=8M
read_buffer_size=8M
thread_cache_size=64
query_cache_size=64M
tmp_table_size=256M
max_connections=500
wait_timeout=600
interactive_timeout=600
innodb_flush_log_at_trx_commit=2
innodb_log_buffer_size=10M
innodb_thread_concurrency=16
[mysqld]
#myslqd服务运行时的port号
port=3306

#socket文件是在Linux环境下特有的，用户的client软件连接能够不通过TCP/IP网络而直接使用unix socket连接到Mysql。
socket=/tmp/mysql.sock

#避免Mysql的外部锁定。降低出错几率，增强稳定性。
skip-external-locking

#禁止MySql对外部连接进行DNS解析。使用这一选项能够消除MySQL进行NDS解析的时间。

但须要注意的是：假设开启该选项。则所有远程主机连
接授权都要使用IP地址方式了，否则MYSQL将无法正常处理连接请求。
skip-name-resolve

#back_log參数的值指出在MySQL暂时停止响应新请求之前，短时间内的多少个请求能够被存在对堆栈中，假设系统短时间内有非常多连接。则需>要增大该參数的值。该參数值指定到来的TCP/IP连接的监听队列的大小。

不同的操作系统在这个队列的大小有自己的限制，假设试图将back_log设定得高于操作系统的限制将是无效的，其默认值为50，对于LINUX系统而言，推荐设置为小于512的整数。
back_log=384

#索引缓冲区大小，添加它可得到更好的索引处理性能，对于内存在4GB左右的server，该參数可设置为256M或384M。假设该參数值设置的过大>反而会使server的总体效率降低。

key_buffer_size=384M

#设定在网络传输中一次消息传输量的最大值，系统默认值为1MB。最大值是1GB。必须设定为1024的倍数，单位为字节。

max_allowed_packet=4M

#设置MySQL每一个线程的堆栈大小，默认值足够大，可满足普通操作。

可设置范围为128KB至4GB，默认192K。
thread_stack=256k

#设定查询排序时所能使用的缓冲区大小。系统默认大小为2MB。从5.1.23版本号開始，在除了WINDOWS 之外的64位平台上能够4GB的限制。该參数
相应的分配内在是每一个连接独占的，假设有100个连接。那么实际分配的总排序缓冲区大小为100*6＝600MB，那么对于内存4GB左右的server来>说，推荐将其设置为6MB-8MB。
sort_buffer_size=6M

#读查询操作所能使用的缓冲区大小。和sort_buffer_size一样，该參数相应的分配内在也是每一个连接独享。

read_buffer_size=4M

#设置Thread Cache池中能够缓存的连接池线程最大数量，可设置为0-16384,默觉得0。1GB内存我们配置为8。2GB内存我们配置为16。4GB或4GB以上内在我们配置为64。
thread_cache_size=64
#指定Mysql查询缓冲区的大小。能够通过在Mysql控制台观察，假设Qcache_lowmem_prunes的值非常大，则表明常常出现缓冲不够的情况，假设
Qcache_hits的值非常大。则表明查询缓冲使用的非常频繁
query_cache_size=64M

#设置内在暂时表最大值，假设超过该值，则会将暂时表写入磁盘，其范围为1KB至4GB。
tmp_table_size=256M

#指定MYSQL同意的最大连接进程数，假设在訪问程序时常常出现TOO MANY CONNECTIONS的错误提示。则须要增大该參数值。
max_connections=5000

#指定一个请求的最大连接时间，对于4GB左右内在的server来说。能够将其设置为5－10
wait_timeout=120

#该參数取值为server逻辑CPU数量*2，比方。server有两个物理CPU。每一个物理CPU支持HT超线程，所以实际取值4*2=8。这也是眼下双四核主流
server的配置。

thread_concurrency=8

#开启该选项能够彻底关闭MYSQL的TCP/IP连接方式，假设WEBserver是以远程连接的方式訪问MYSQL的数据库server，则不要开启该选项，否则>将无法正常连接。

skip-networking

innodb_flush_log_at_trx_commit
#抱怨Innodb比MyISAM慢 100倍？那么你大概是忘了调整这个值。默认值1的意思是每一次事务提交或事务外的指令都须要把日志写入（flush）
硬盘，这是非常费时的。

特别是使用电池供电缓存（Battery backed up cache）时。设成2对于非常多运用，特别是从MyISAM表转过来的是能够的>。它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬 盘，所以你一般不会丢失超过1-2秒的更新。

设成0会更快一点，但安>全方面比較差，即使MySQL挂了也可能会丢失事务的数据。

而值2仅仅会在整个操作系统 挂了时才可能丢数据。
innodb_flush_log_at_trx_commit=2

#这是 InnoDB 存储引擎的事务日志所使用的缓冲区。相似于 Binlog Buffer，InnoDB 在写事务日志的时候，为了提高性能。也是先将信息写>入 Innofb Log Buffer 中，当满足 innodb_flush_log_trx_commit 參数所设置的相应条件（或者日志缓冲区写满）之后。才会将日志写到文>件（或者同步到磁盘）中。能够通过 innodb_log_buffer_size 參数设置其能够使用的最大内存空间。
innodb_log_buffer_size=2M

#这个数字要依据实际的情况来设定。但对于大多数的情况，是一个比較合适的设置
innodb_thread_concurrency=8

#tmp_table_size 的默认大小是 32M。

假设一张暂时表超出该大小，MySQL产生一个 The table tbl_name is full 形式的错误。假设你做非常多
高级 GROUP BY 查询，添加 tmp_table_size 值。
tmp_table_size=64M

#随机读取数据缓冲区使用内存(read_rnd_buffer_size)：和顺序读取相相应，当 MySQL 进行非顺序读取（随机读取）数据块的时候，会利用>这个缓冲区暂存读取的数据。如依据索引信息读取表数据。依据排序后的结果集与表进行Join等等。

总的来说，就是当数据块的读取须要满足>一定的顺序的情况下。MySQL 就须要产生随机读取。进而使用到 read_rnd_buffer_size 參数所设置的内存缓冲区。

read_rnd_buffer_size=16M

#你最好在定义数据库命名规则的时候就所有採用小写字母加下划线的组合，而不使用不论什么的大写字母。
lower_case_table_names=1

#设置校验模式
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

#默认配置没开查询缓存哦亲
explicit_defaults_for_timestamp

innodb_buffer_pool_size=1024Mslow_query_loglog-short-format  slow_query_log_file=/var/log/mysqld-slow-query.log  long-query-time = 2  #log-long-format  #log-slow-admin-statementslog-queries-not-using-indexes[mysqld_safe]log-error=/var/log/mysqld.logpid-file=/var/run/mysqld/mysqld.pid

东西非常多，不要急，以下我们一个个參数来作说明。

核心配置文件的中的參数说明

对于參数说明，为了便于学习而不是塞填鸭式的教育，我把它分为了一个简版，一个升级版，

• 简版的參数说明： 适用于一般开发、測试迅速搭建mysql环境。
• 升级版的參数说明：适用于一般DBA和架构师级别。

核心配置參数简版

[mysqld]
#myslqd服务运行时的port号
port=3306

#socket文件是在Linux环境下特有的，用户的client软件连接能够不通过TCP/IP网络而直接使用unix socket连接到Mysql。
socket=/tmp/mysql.sock

#避免Mysql的外部锁定，降低出错几率。增强稳定性。
skip-external-locking

#禁止MySql对外部连接进行DNS解析，使用这一选项能够消除MySQL进行NDS解析的时间。但须要注意的是：假设开启该选项，则所有远程主机连
接授权都要使用IP地址方式了，否则MYSQL将无法正常处理连接请求。

skip-name-resolve

#back_log參数的值指出在MySQL暂时停止响应新请求之前，短时间内的多少个请求能够被存在对堆栈中，假设系统短时间内有非常多连接，则需>要增大该參数的值。该參数值指定到来的TCP/IP连接的监听队列的大小。不同的操作系统在这个队列的大小有自己的限制，假设试图将back_log设定得高于操作系统的限制将是无效的，其默认值为50，对于LINUX系统而言，推荐设置为小于512的整数。
back_log=384

#索引缓冲区大小。添加它可得到更好的索引处理性能。对于内存在4GB左右的server，该參数可设置为256M或384M。假设该參数值设置的过大>反而会使server的总体效率降低。
key_buffer_size=384M

#设定在网络传输中一次消息传输量的最大值。系统默认值为1MB，最大值是1GB。必须设定为1024的倍数。单位为字节。

max_allowed_packet=4M

#设置MySQL每一个线程的堆栈大小，默认值足够大。可满足普通操作。

可设置范围为128KB至4GB。默认192K。
thread_stack=256k

#设定查询排序时所能使用的缓冲区大小。系统默认大小为2MB，从5.1.23版本号開始，在除了WINDOWS 之外的64位平台上能够4GB的限制。该參数
相应的分配内在是每一个连接独占的。假设有100个连接。那么实际分配的总排序缓冲区大小为100*6＝600MB。那么对于内存4GB左右的server来>说，推荐将其设置为6MB-8MB。
sort_buffer_size=6M

#读查询操作所能使用的缓冲区大小，和sort_buffer_size一样，该參数相应的分配内在也是每一个连接独享。

read_buffer_size=4M

#设置Thread Cache池中能够缓存的连接池线程最大数量，可设置为0-16384,默觉得0。1GB内存我们配置为8，2GB内存我们配置为16，4GB或4GB以上内在我们配置为64。

thread_cache_size=64
#指定Mysql查询缓冲区的大小，能够通过在Mysql控制台观察，假设Qcache_lowmem_prunes的值非常大，则表明常常出现缓冲不够的情况，假设
Qcache_hits的值非常大，则表明查询缓冲使用的非常频繁
query_cache_size=64M

#设置内在暂时表最大值，假设超过该值。则会将暂时表写入磁盘，其范围为1KB至4GB。
tmp_table_size=256M

#指定MYSQL同意的最大连接进程数，假设在訪问程序时常常出现TOO MANY CONNECTIONS的错误提示。则须要增大该參数值。

max_connections=5000

#指定一个请求的最大连接时间。对于4GB左右内在的server来说，能够将其设置为5－10
wait_timeout=120

#该參数取值为server逻辑CPU数量*2。比方，server有两个物理CPU，每一个物理CPU支持HT超线程。所以实际取值4*2=8，这也是眼下双四核主流
server的配置。
thread_concurrency=8

#开启该选项能够彻底关闭MYSQL的TCP/IP连接方式，假设WEBserver是以远程连接的方式訪问MYSQL的数据库server。则不要开启该选项，否则>将无法正常连接。
skip-networking

innodb_flush_log_at_trx_commit
#抱怨Innodb比MyISAM慢 100倍？那么你大概是忘了调整这个值。默认值1的意思是每一次事务提交或事务外的指令都须要把日志写入（flush）
硬盘，这是非常费时的。

特别是使用电池供电缓存（Battery backed up cache）时。设成2对于非常多运用，特别是从MyISAM表转过来的是能够的>。它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬 盘。所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安>全方面比較差，即使MySQL挂了也可能会丢失事务的数据。而值2仅仅会在整个操作系统 挂了时才可能丢数据。
innodb_flush_log_at_trx_commit=2

#这是 InnoDB 存储引擎的事务日志所使用的缓冲区。

相似于 Binlog Buffer。InnoDB 在写事务日志的时候，为了提高性能，也是先将信息写>入 Innofb Log Buffer 中。当满足 innodb_flush_log_trx_commit 參数所设置的相应条件（或者日志缓冲区写满）之后，才会将日志写到文>件（或者同步到磁盘）中。能够通过 innodb_log_buffer_size 參数设置其能够使用的最大内存空间。
innodb_log_buffer_size=2M

#这个数字要依据实际的情况来设定，但对于大多数的情况。是一个比較合适的设置
innodb_thread_concurrency=8

#tmp_table_size 的默认大小是 32M。假设一张暂时表超出该大小。MySQL产生一个 The table tbl_name is full 形式的错误，假设你做非常多
高级 GROUP BY 查询，添加 tmp_table_size 值。

tmp_table_size=64M

#随机读取数据缓冲区使用内存(read_rnd_buffer_size)：和顺序读取相相应，当 MySQL 进行非顺序读取（随机读取）数据块的时候，会利用>这个缓冲区暂存读取的数据。如依据索引信息读取表数据。依据排序后的结果集与表进行Join等等。总的来说，就是当数据块的读取须要满足>一定的顺序的情况下。MySQL 就须要产生随机读取。进而使用到 read_rnd_buffer_size 參数所设置的内存缓冲区。

read_rnd_buffer_size=16M

#你最好在定义数据库命名规则的时候就所有採用小写字母加下划线的组合。而不使用不论什么的大写字母。

lower_case_table_names=1

#设置校验模式
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

#默认配置没开查询缓存哦亲
explicit_defaults_for_timestamp

一口气写了这么多，呵呵。
每一个參数我都作了注解，这样看起来不知道大家是不是会觉得更实用些？
以下，我们就来一个“升级”版的。所谓升级版内容一定会非常丰富，我总結了差点儿相同有77条。以下我们就一条条来看吧。这也是本文几个核心价值中的一个重要部分。

核心配置參数升级版

1. [client]
2. port   = 3306 # clientport号为3306
3. socket  = /data/3306/mysql.sock
4. default-character-set = utf8 
# client字符集,(控制character_set_client、character_set_connection、character_set_results)
5. [mysql]
6. no-auto-rehash  # 仅仅同意使用键值的updates和deletes
7. [mysqld]  
# 组包含了mysqld服务启动的參数，它涉及的方面非常多，当中有MySQL的文件夹和文件，通信、网络、信息安全，内存管理、优化、查询缓存区。还有MySQL日志设置等。
8. user    = mysql
# mysql_safe脚本使用MySQL运行用户(编译时--user=mysql指定),推荐使用mysql用户。

9. port    = 3306
# MySQL服务运行时的port号。

建议更改默认port,默认easy遭受攻击。

10. socket  = /data/3306/mysql.sock  
# socket文件是在Linux/Unix环境下特有的，用户在Linux/Unix环境下client连接能够不通过TCP/IP网络而直接使用unix socket连接MySQL。
11. basedir = /application/mysql  
# mysql程序所存放路径,常常使用于存放mysql启动、配置文件、日志等
12. datadir = /data/3306/data  
# MySQL数据存放文件(极其重要)
13. character-set-server = utf8  
# 数据库和数据库表的默认字符集。(推荐utf8,以免导致乱码)
14. log-error=/data/3306/mysql.err
# mysql错误日志存放路径及名称(启动出现错误一定要看错误日志,百分之百都能通过错误日志排插解决。

)
15. pid-file=/data/3306/mysql.pid  
# MySQL_pid文件记录的是当前mysqld进程的pid。pid亦即ProcessID。
16. skip-locking
# 避免MySQL的外部锁定，降低出错几率。增强稳定性。
17. skip-name-resolv
# 禁止MySQL对外部连接进行DNS解析。使用这一选项能够消除MySQL进行DNS解析的时候。

可是须要注意的是，假设开启该选项，则所有远程主机连接授权都要使用IP地址方式了，否则MySQL将无法正常处理连接请求！
18. skip-networking  
# 开启该选项能够彻底关闭MySQL的TCP/IP连接方式，假设Webserver是以远程连接的方式訪问MySQL数据库server的，则不要开启该选项，否则无法正常连接。
19. open_files_limit    = 1024
# MySQLd能打开文件的最大个数,假设出现too mant open files之类的就须要调整该值了。

20. back_log = 384  
# back_log參数是值指出在MySQL暂时停止响应新请求之前，短时间内的多少个请求能够被存在堆栈中。假设系统在短时间内有非常多连接。则须要添加该參数的值，该參数值指定到来的TCP/IP连接的监听队列的大小。不同的操作系统在这个队列的大小上有自己的限制。假设试图将back_log设置得高于操作系统的限制将是无效的，其默认值为50.对于Linux系统而言，推荐设置为小于512的整数。
21. max_connections = 800
# 指定MySQL同意的最大连接进程数。假设在訪问博客时常常出现 Too Many Connections的错误提示，则须要增大该參数值。
22. max_connect_errors = 6000  
# 设置每一个主机的连接请求异常中断的最大次数。当超过该次数。MySQLserver将禁止host的连接请求，直到MySQLserver重新启动或通过flush hosts命令清空此host的相关信息。

23. wait_timeout = 120  
# 指定一个请求的最大连接时间，对于4GB左右内存的server来说，能够将其设置为5~10。
24. table_cache = 614K  
# table_cache指示表快速缓冲区的大小。当MySQL訪问一个表时。假设在MySQL缓冲区还有空间。那么这个表就被打开并放入表缓冲区，这样做的优点是能够更快速地訪问表中的内容。一般来说，能够查看数据库运行峰值时间的状态值Open_tables和Open_tables，用以推断是否须要添加table_cache的值，即假设Open_tables接近table_cache的时候，并且Opened_tables这个值在逐步添加。那就要考虑添加这个值的大小了。
25. external-locking = FALSE  
# MySQL选项能够避免外部锁定。True为开启。
26. max_allowed_packet =16M  
# server一次能处理最大的查询包的值，也是server程序能够处理的最大查询
27. sort_buffer_size = 1M  
# 设置查询排序时所能使用的缓冲区大小。系统默认大小为2MB。
# 注意：该參数相应的分配内存是每一个连接独占的，假设有100个连接。那么实际分配的总排序缓冲区大小为100 x6=600MB。

所以，对于内存在4GB左右的server来说。推荐将其设置为6MB~8MB
28. join_buffer_size = 8M
# 联合查询操作所能使用的缓冲区大小，和sort_buffer_size一样，该參数相应的分配内存也是每一个连接独享。
29. thread_cache_size = 64
# 设置Thread Cache池中能够缓存的连接线程最大数量。可设置为0~16384。默觉得0.这个值表示能够又一次利用保存在缓存中线程的数量，当断开连接时假设缓存中还有空间，那么client的线程将被放到缓存中;假设线程又一次被请求，那么请求将从缓存中读取,假设缓存中是空的或者是新的请求。那么这个线程将被又一次创建，假设有非常多线程。添加这个值能够改善系统性能。通过比較Connections和Threads_created状态的变量，能够看到这个变量的作用。我们能够依据物理内存设置规则例如以下:1GB内存我们配置为8,2GB内存我们配置为16,3GB我们配置为32,4GB或4GB以上我们给此值为64或更大的值。
30. thread_concurrency = 8  
# 该參数取值为server逻辑CPU数量x 2。在本例中，server有两个物理CPU。而每一个物理CPU又支持H.T超线程，所以实际取值为4 x 2 = 8。

这也是双四核主流server的配置。
31. query_cache_size = 64M
# 指定MySQL查询缓冲区的大小。能够通过在MySQL控制台观察，假设Qcache_lowmem_prunes的值非常大，则表明常常出现缓冲不够的情况;假设Qcache_hits的值非常大。则表明查询缓冲使用得非常频繁。

另外假设改值较小反而会影响效率。那么能够考虑不用查询缓冲。对于Qcache_free_blocks，假设该值非常大，则表明缓冲区中碎片非常多。

32. query_cache_limit = 2M  
# 仅仅有小于此设置值的结果才会被缓存
33. query_cache_min_res_unit = 2k  
# 设置查询缓存分配内存的最小单位，要适当第设置此參数，能够做到为降低内存快的申请和分配次数。可是设置过大可能导致内存碎片数值上升。默认值为4K，建议设置为1K~16K。

34. default_table_type = InnoDB  
# 默认表的类型为InnoDB
35. thread_stack = 256K  
# 设置MySQL每一个线程的堆栈大小，默认值足够大。可满足普通操作。

可设置范围为128KB至4GB，默觉得192KB
#transaction_isolation = Level
# 数据库隔离级别 (READ UNCOMMITTED(读取未提交内容) READ COMMITTED(读取提交内容) REPEATABLE
READ(可重读) SERIALIZABLE(可串行化))
36. tmp_table_size = 64M  
# 设置内存暂时表最大值。

假设超过该值，则会将暂时表写入磁盘，其范围1KB到4GB。
37. max_heap_table_size = 64M  
# 独立的内存表所同意的最大容量。
38. table_cache = 614
# 给常常訪问的表分配的内存，物理内存越大，设置就越大。调大这个值，普通情况下能够降低磁盘IO，但相应的会占用很多其它的内存,这里设置为614。
39. table_open_cache = 512  
# 设置表快速缓存的数目。

每一个连接进来，都会至少打开一个表缓存。因此。 table_cache 的大小应与 max_connections 的设置有关。

比如，对于 200 个并行运行的连接。应该让表的缓存至少有 200 × N 。这里 N 是应用能够运行的查询的一个联接中表的最大数量。此外。还须要为暂时表和文件保留一些额外的文件描写叙述符。
40. long_query_time = 1  
# 慢查询的运行用时上限,默认设置是10s,推荐(1s~2s)
41. log_long_format  
# 没有使用索引的查询也会被记录。(推荐,依据业务来调整)
42. log-slow-queries = /data/3306/slow.log  
# 慢查询日志文件路径(假设开启慢查询,建议打开此日志)
43. log-bin = /data/3306/mysql-bin  
# logbin数据库的操作日志,比如update、delete、create等都会存储到binlog日志,通过logbin能够实现增量恢复
44. relay-log = /data/3306/relay-bin
# relay-log日志记录的是从serverI/O线程将主server的二进制日志读取过来记录到从server本地文件,然后SQL线程会读取relay-log日志的内容并应用到从server
45. relay-log-info-file = /data/3306/relay-log.info  
# 从server用于记录中继日志相关信息的文件,默认名为数据文件夹中的relay-log.info。
46. binlog_cache_size = 4M  
# 在一个事务中binlog为了记录sql状态所持有的cache大小，假设你常常使用大的，多声明的事务，能够添加此值来获取更大的性能，所有从事务来的状态都被缓冲在binlog缓冲中，然后再提交后一次性写入到binlog中，假设事务比此值大，会使用磁盘上的暂时文件来替代。此缓冲在每一个链接的事务第一次更新状态时被创建。

47. max_binlog_cache_size = 8M  
# 最大的二进制Cache日志缓冲尺寸。
48. max_binlog_size = 1G  
# 二进制日志文件的最大长度(默认设置1GB)一个二进制文件信息超过了这个最大长度之前,MySQLserver会自己主动提供一个新的二进制日志文件接续上。
49. expire_logs_days = 7  
# 超过7天的binlog,mysql程序自己主动删除(假设数据重要,建议不要开启该选项)
50. key_buffer_size = 256M  
# 指定用于索引的缓冲区大小。添加它可得到更好的索引处理性能。对于内存在4GB左右的server来说。该參数可设置为256MB或384MB。

# 注意：假设该參数值设置得过大反而会使server的总体效率降低！

51. read_buffer_size = 4M  
# 读查询操作所能使用的缓冲区大小。和sort_buffer_size一样，该參数相应的分配内存也是每一个连接独享。
52. read_rnd_buffer_size = 16M
# 设置进行随机读的时候所使用的缓冲区。此參数和read_buffer_size所设置的Buffer相反，一个是顺序读的时候使用，一个是随机读的时候使用。可是两者都是针对与线程的设置，每一个线程都能够产生两种Buffer中的不论什么一个。默认值256KB，最大值4GB。
53. bulk_insert_buffer_size = 8M  
# 假设常常性的须要使用批量插入的特殊语句来插入数据,能够适当调整參数至16MB~32MB,建议8MB。
54. myisam_sort_buffer_size = 8M
# 设置在REPAIR Table或用Create index创建索引或 Alter table的过程中排序索引所分配的缓冲区大小。可设置范围4Bytes至4GB，默觉得8MB
55. lower_case_table_names = 1  
# 实现MySQL不区分大小。(发开需求-建议开启)
56. slave-skip-errors = 1032,1062  
# 从库能够跳过的错误数字值(mysql错误以数字代码反馈,全的mysql错误代码大全,以后会公布至博客)。

57. replicate-ignore-db=mysql  
# 在做主从的情况下,设置不须要同步的库。
58. server-id = 1  
# 表示本机的序列号为1,假设做主从。或者多实例,serverid一定不能同样。

59. myisam_sort_buffer_size = 128M
# 当须要对于运行REPAIR, OPTIMIZE, ALTER 语句重建索引时，MySQL会分配这个缓存，以及LOAD DATA INFILE会载入到一个新表，它会依据最大的配置认真的分配的每一个线程。
60. myisam_max_sort_file_size = 10G
# 当又一次建索引（REPAIR，ALTER，TABLE，或者LOAD，DATA，TNFILE）时，MySQL被同意使用暂时文件的最大值。
61. myisam_repair_threads = 1
# 假设一个表拥有超过一个索引, MyISAM 能够通过并行排序使用超过一个线程去修复他们.
62. myisam_recover
# 自己主动检查和修复没有适当关闭的 MyISAM 表.
63. innodb_additional_mem_pool_size = 4M  
# 用来设置InnoDB存储的数据文件夹信息和其它内部数据结构的内存池大小。

应用程序里的表越多。你须要在这里面分配越多的内存。对于一个相对稳定的应用，这个參数的大小也是相对稳定的，也没有必要预留非常大的值。假设InnoDB用广了这个池内的内存，InnoDB開始从操作系统分配内存，并且往MySQL错误日志写警告信息。

默觉得1MB，当发现错误日志中已经有相关的警告信息时，就应该适当的添加该參数的大小。
64. innodb_buffer_pool_size = 64M  
# InnoDB使用一个缓冲池来保存索引和原始数据，设置越大，在存取表里面数据时所须要的磁盘I/O越少。强烈建议不要武断地将InnoDB的Buffer Pool值配置为物理内存的50%~80%，应依据详细环境而定。
65. innodb_data_file_path = ibdata1:128M:autoextend  
# 设置配置一个可扩展大小的尺寸为128MB的单独文件，名为ibdata1.没有给出文件的位置。所以默认的是在MySQL的数据文件夹内。

66. innodb_file_io_threads = 4  
# InnoDB中的文件I/O线程。通常设置为4，假设是windows能够设置更大的值以提高磁盘I/O
67. innodb_thread_concurrency = 8  
# 你的server有几个CPU就设置为几。建议用默认设置，一般设为8。
68. innodb_flush_log_at_trx_commit = 1  
# 设置为0就等于innodb_log_buffer_size队列满后在统一存储，默觉得1。也是最安全的设置。

69. innodb_log_buffer_size = 2M  
# 默觉得1MB，通常设置为8~16MB就足够了。
70. innodb_log_file_size = 32M  
# 确定日志文件的大小，更大的设置能够提高性能，但也会添加恢复数据库的时间。
71. innodb_log_files_in_group = 3  
# 为提高性能,MySQL能够以循环方式将日志文件写到多个文件。

推荐设置为3。
72. innodb_max_dirty_pages_pct = 90  
# InnoDB主线程刷新缓存池中的数据。
73. innodb_lock_wait_timeout = 120  
# InnoDB事务被回滚之前能够等待一个锁定的超时秒数。InnoDB在它自己的锁定表中自己主动检測事务死锁并且回滚事务。InnoDB用locak tables 语句注意到锁定设置。默认值是50秒。

74. innodb_file_per_table = 0  
# InnoDB为独立表空间模式。每一个数据库的每一个表都会生成一个数据空间。0关闭，1开启。
# 独立表空间优点：
# 1、每一个表都有自己独立的表空间。
# 2 、每一个表的数据和索引都会存在自己的表空间中。
# 3、能够实现单表在不同的数据库中移动。

# 4、空间能够回收（除drop table操作处，表空不能自己回收。

）
75. [mysqldump]

76. quick
#quick  不缓冲查询，直接导出至stdout
77. max_allowed_packet = 2M  
# 设定在网络传输中一次消息传输量的最大值。系统默认值为1MB，最大值是1GB，必须设置为1024的倍数。单位为字节。

mySQL配置远程可连接

mySQL安装完后，默认仅仅能在本机进行SQLclient的訪问，假设你要使用一台远程主机，比方説：
mySQL安装在192.168.0.101上。你要通过192.168.0.1上的mySQLclient登录192.168.0.101訪问。默认是不同意的。
为了能够远程訪问mySQL你必须配置远程可连接的用户信息。
一般来説：
为了简单，我们能够配置一个用户。用户名为“username@%”。这个%代表支持远程不论什么IP地址的client能够訪问这台mySQL主机。
可是，一般来説为了安全，我们会把username@后面跟上一个详细的ip。
所以假设在mySQL刚安装完成时。root用户仅仅能够作本地訪问，为了开启远程訪问功能我们一般都有一个root@%这种用户名。

操作过程例如以下：
1. 先登录本地mysql通过命令：

#mysql -uroot –proot的密码 –P(port号大写的P) -h 主机名
mysql -uroot –p111111 -P3307 -h 168.177.101.1

2. 在mysql命令符内运行例如以下语句:

GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION;

结合配置中的慢查询，统计有性能问题的SQL

在我的配置中有这么一段描写叙述

[mysqld]
…
…
slow_query_log
log-short-format
slow_query_log_file=/var/log/mysqld-slow-query.log
long-query-time = 2
#log-long-format
#log-slow-admin-statements
log-queries-not-using-indexes

此处注意了，网上对于“慢查询”的配置，非常多都已经deprecated了，请參照我上述这种写法。

配置解释

• 首先，我开启了query_log功能。
• 在日志查询中我使用的是log-short-format格式而不是long-format，由于这样我的mySQL日志更紧凑，要不然一天下来光统计这些日志就要耗掉G的空间了。
• 我指明了我的“慢查询”日志生成的路径位于何处。
• 我配置了对于超过2秒的查询SQL所有记录在慢查询日志中的功能。
• 同一时候，我还开启了在查询时凡是没实用到索引的SQL所有记录在慢查询日志中。

试验

我们配置完后使用service mysqld restart重新启动mysql服务后，我们能够看到在/var/log文件夹以下会有一个mysqld-slow-query.log的文件 。

我们在sqlclient运行例如以下语句

接下去我们来看看这个mysqld-slow-query.log中的文件内容：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="" />

这样看，似乎有一些不太习惯对不正确？
假设这个日志文件里有成千上百个日志，我们假设须要统计 Top10最慢的那些SQL各自是哪些。。

。怎么办？
我们能够使用mysqldumpslow命令

mysqldumpslow -s t -t 10 mysqld-slow-query.log

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="" />

mySQL 存储引擎中InnoDB与Myisam的主要差别

这个问题。我以前在面试时碰到过有人説“精通MYSQL“，于是我问了他们这么一个问题。结果是超过90%的人无法回答。

mySQL最重要的两种存储引擎InnoDB与Myisam，这是基础，一定要知道。以下来看。

1） 事务处理
innodb 支持事务功能，myisam 不支持。
Myisam 的运行速度更快，性能更好。
2） select ,update ,insert ,delete 操作
MyISAM：假设运行大量的SELECT。MyISAM是更好的选择
InnoDB：假设你的数据运行大量的INSERT或UPDATE。出于性能方面的考虑，应该使用InnoDB表
3） 锁机制不同
InnoDB 为行级锁，myisam 为表级锁。
注意：当数据库无法确定，所找的行时，也会变为锁定整个表。

如： update table set num = 10 where username like "%test%";
4） 查询表的行数不同
MyISAM：select count(*) from table,MyISAM仅仅要简单的读出保存好的行数。注意的是，当count(*)语句包含   where条件时。两种表的操作是一样的
InnoDB ： InnoDB 中不保存表的详细行数，也就是说，运行select count(*) from table时，InnoDB要扫描一遍整个表来计算有多少行
5） 物理结构不同

MyISAM ：每一个MyISAM在磁盘上存储成三个文件。第一个文件的名字以表的名字開始。扩展名指出文件类型。

• .frm文件存储表定义。
• 数据文件的扩展名为.MYD (MYData)。
• 索引文件的扩展名是.MYI (MYIndex)

InnoDB：基于磁盘的资源是InnoDB表空间数据文件和它的日志文件，InnoDB 表的大小仅仅受限于操作系统文件的大小，一般为 2GB

6） anto_increment 机制不同

这是一道非常早的面试题：

一张表,里面有ID自增主键,当insert了17条记录之后,删除了第15,16,17条记录,再把Mysql重新启动,再insert一条记录,这条记录的ID是18还是15 。

答案：
假设表的类型是MyISAM。那么是18。 
由于MyISAM表会把自增主键的最大ID记录到数据文件里，重新启动MySQL自增主键的最大ID也不会丢失。

假设表的类型是InnoDB。那么是15。 
InnoDB表仅仅是把自增主键的最大ID记录到内存中，所以重新启动数据库或者是对表进行OPTIMIZE操作，都会导致最大ID丢失。

其它） 为什么MyISAM会比Innodb 的查询速度快。

INNODB在做SELECT的时候，要维护的东西比MYISAM引擎多非常多；

• 数据块，INNODB要缓存。MYISAM仅仅缓存索引块，  这中间还有换进换出的降低；
• innodb寻址要映射到块，再到行。MYISAM 记录的直接是文件的OFFSET。定位比INNODB要快；
• INNODB还须要维护MVCC一致；尽管你的场景没有，但他还是须要去检查和维护；
• MVCC ( Multi-Version Concurrency Control )多版本号并发控制

InnoDB： 通过为每一行记录加入两个额外的隐藏的值来实现MVCC，这两个值一个记录这行数据何时被创建。另外一个记录这行数据何时过期（或者被删除）。可是InnoDB并不存储这些事件发生时的实际时间。相反它仅仅存储这些事件发生时的系统版本号号。这是一个随着事务的创建而不断增长的数字。每一个事务在事务開始时会记录它自己的系统版本号号。每一个查询必须去检查每行数据的版本号号与事务的版本号号是否同样。让我们来看看当隔离级别是REPEATABLE READ时这种策略是怎样应用到特定的操作的：
　　

SELECT InnoDB必须每行数据来保证它符合两个条件：

InnoDB必须找到一个行的版本号，它至少要和事务的版本号一样老(也即它的版本号号不大于事务的版本号号)。这保证了无论是事务開始之前。或者事务创建时，或者改动了这行数据的时候，这行数据是存在的。

这行数据的删除版本号必须是没有定义的或者比事务版本号要大。

这能够保证在事务開始之前这行数据没有被删除。

mySQL使用profiling分析慢sql语句的原因

MySQL 的 Query Profiler 是一个使用非常方便的 Query 诊断分析工具，通过该工具能够获取一条Query 在整个运行过程中多种资源的消耗情况，如 CPU，IO，IPC，SWAP 等，以及发生的 PAGE FAULTS，CONTEXT SWITCHE 等等，同一时候还能得到该 Query 运行过程中 MySQL 所调用的各个函数在源文件里的位置。

MySQL5.0.37版本号以上支持PROFILING调试功能。让您能够了解SQL语句消耗资源的详细信息。由于它须要调用系统的getrusage()函数，所以仅仅是在Linux/Unix类平台上才干使用。而不能在Windows平台上使用。并且，PROFILING是针对处理进程(process)而不是线程(thread)的，server上的其它应用。可能会影响您的调试结果，因此。这个工具适合开发过程中的调试。假设要在生产环境中调试使用。则要注意它的局限性。

查看是否已经启用profile，默认是关闭的

启用profiling（变量profiling是用户变量每次都得又一次启用）

使用profiling记录用户运行的SQL

为避免之前已经把 SQL 存放在 QCACHE 中。 建议在运行 SQL 时， 强制 SELECT 语句不进行 QCACHE 检測。这样能够提交分析的准确性。

使用show profile查询近期一条语句的运行信息

查看在server上运行语句的列表。(查询id，花费时间，语句)