面向读者

该文适用于Linux CENTOS6.X及以上相干环境，mySQL版本为：5.x及以上。
本文读者需要具有低级Linux系统使用的相干经验。
MYSQL的历史
MySQL的爆发实际是在01、02年，特别是02年发布的4.0 Beta版，正式选定InnoDB作为默许引擎，对事务处理能力及数据缓存能力有了极大的提高。同年4.1版开始支持子查询，至此MySQL终究演变成1个成熟的关系型数据库系统。05年的5.0版本又添加了存储进程、服务端游标、触发器、查询优化和散布式事务功能，但同年被Oracle抄了后路，InnoDB被Oracle收编。08年，MySQL被Sun收购，09年，Oracle收购了Sun和MySQL。
MySQL最大的1个特点，就是自由选择存储引擎。每一个表都是1个文件，都可以选择适合的存储引擎。常见的引擎有 InnoDB、 MyISAM、 NDBCluster等。但由于这类开放插件式的存储引擎，比如要求数据库与引擎之间的松耦合关系。从而致使文件的1致性大大下降。在SQL履行优化方面，也就有着1些不可避免的瓶颈。在多表关联、子查询优化、统计函数等方面是软肋，而且只支持极简单的HINT。

PostgreSQL官方宣称的是：“The world’s most advanced open source database”。most advanced我不知道是怎样定义的，由于PosgreSQL还是传统B+树索引的数据库，在1些场景下，比如全插入场景，其还是会比其他1些数据库要来得差很多，比如TokuDB，MongoDB。撇开这部份的因素，不能不承认PostgreSQL是最为强大的开源数据库，也许，但是Oracle仍然才是最为强大的关系型数据库。PostgreSQL阵营1直标榜自己在优化器和Oracle可移植性方面的优势，我想这对照MySQL也许是成立的。但是，如果上述都成立的话，为何PostgreSQL在装机量，流行度等指标上上远远地被后起之秀MySQL给超出了呢？全球前20大网站完全看不到PostgreSQL的身影呢？在写本篇文章的时候，我倏地想到了1个类似的问题，业界公认手机质量最好的Nokia，终究为何会倒下？

下图是1个mySQL在大型网站和系统中的利用案例统计。

PostgreSQL另外一个痛点，我想很多人没有会心识到的，就是在在线事务（OLTP）方面的性能问题。
PostgreSQL在功能方面也许是比较完全的，但是真的要进入到生产环节，看的不再是简单的功能，由于大部份用户都明白天常所使用的仅是数据库提供的20%功能。MySQL 5.7现在已可以轻松到达50W QPS的性能，并支持通过NoSQL接口可以到达100W QPS，这是PostgreSQL为何没有能在互联网时期站住脚根的1个重要缘由之1。在线事务对性能的要求之刻薄，是普通用户所没法感知的。
PostgreSQL最大的优势是在线分析的场景，由于其优化器对Join的支持可谓全面，对复杂查询有着良好的支持，从Oracle迁移到PostgreSQL的本钱会比较低。基于PostgreSQL的GreenPlum也已开源，因此PostgreSQL目前在这方便是较为领先的。

MYSQL

MySQL数据库官方的口号是：“ The world’s most popular open source database.”。对照PostgreSQL，这句话简直没法攻击，并且MySQL官方的目标也1直是成为最为流行的数据库。通过互联网浪潮，移动互联的时期，MySQL是真的做到了。
MySQL的优势是开源与开放性架构，使其具有有着各种分支版本与存储引擎可供选择。除官方的InnoDB存储引擎，还有TokuDB，Infobright引擎可在特定场合下进行使用。也正是由于MySQL的开源与开放，使得大量的开发人员加入到了MySQL的围绕。MySQL是1个非常成功的开源项目，可能很多人疏忽了这个重要的因素。
MySQL被Oracle收购后表现的愈来愈好，1方面是功能愈来愈与Oracle数据库接近，很多时候给我的感觉就是开源的Oracle数据库，另外一个重要的改进就是bug愈来愈少，乃至很多遗留了有近10年的bug也已逐一修复。官方这样严谨的态度，使得MySQL逐步站稳了并开始蚕食1部份的企业市场，世界500强的选择就是最好的证明。

下图是1个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性能提升到了1个新台阶。同时，在在线分析的领域，用户真的不关心使用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是1种类似LSM数据结构的数据引擎，在大并发的插入生产环境下，其对照各种传统数据库都有着显著的优势，即便对照PostgreSQL与Oracle数据库本身。总之，MySQL能够在各种维度满足用户对数据库的各种需求。
PosgreSQL与MySQL对照，最为关键的是全部人材的储备。看看中国的互联网公司基本都已将MySQL数据库作为标配，而PostgreSQL乃至连备胎都没法入选。MySQL在互联网行业积累了大量的高可用架构，散布式架构与灾备经验，但是PostgreSQL几近为0。再看看图书市场，PostgreSQL凤毛菱角，而MySQL则有很好的书籍供DBA，开发人员，架构师等学习。然即便如此，MySQL离Oracle数据库本身的积累还有很长的路要走。

去IOE最早是由淘宝提出，旨在去除IT架构中的IBM小型机，Oracle数据库，EMC存储。去IE是比较简单的事情，由于这仅是硬件的替换。另外，X86技术也愈来愈成熟，稳定性与小机的差距不断缩小。但是去Oracle数据库才是淘宝去IOE的难点与精华所在。全部去Oracle用时3，4年的时间。其中伴随着功能内部工程师的质疑，大量Oracle人材的流失，但终究已证明了MySQL数据库替换Oracle的可行性。
笔者高兴的是传统企业也开始有这样的“觉悟”开始逐渐进行去IOE的尝试，不管这类尝试是主动还是被动，但都是值得尊重的行动。缘由在于去Oracle数据库这件事情其实不那末简单。数据库是传统企业最为核心的资产，任何损失都是不可接受的。而去年银监会的39号文件也坚定了传统企业的去IOE决心。
去IOE风潮显现，1大帮的公司开始进入到这个领域，希望借助这阵风来大赚1笔。这点本无可非议，市场与技术相辅相成。但是，有1个非常不好的现象是，很多公司是为了逢迎某些领导的需要，而不是真实的为传统企业构建面向互联网+的安全可控的技术架构。而这其中有着1些不为人知的因素。
首当其冲的是领导们的绩效，传统企业做事，以绩效为导向，这与互联网行业并没有不同。但是互联网行业有着技术积累，而且对技术的选型与转型有着相当的耐心，从淘宝去Oracle用了3，4年就能够看出。而目前摆在传统企业领导眼前的现实却是，有ZF文件要求各银行业金融机构对安全可控信息技术的利用以不低于15％的比例逐年增加，直至2019年到达不低于75％的整体占比。
有1些传统企业的朋友，领导要求他们用PostgreSQL替换Oracle数据库，缘由在于这是“最快”的替换Oracle本钱，但是他们站在IT从业人员的角度来看这件事是不对的，有种敢怒不敢言。固然，这其中也有部份商业公司在其中推动的关系。但是明白人心里都知道，PostgreSQL国内从业人员寥寥，之前在中国没有大范围的使用经验与架构设计，大多停留在找个文档折腾下的水平上。所谓“最快”的替换方案仅是由于不用进行存储进程的移植，如果只是这样使用PostgreSQL，那末仅是应付上层的文件，而没有真正领会到文件的精神。更有商业公司号称有PostgreSQL的专家，但是非常经不起斟酌，玩过GreenPlum的就是PostgreSQL专家？而且GreenPlum也仅做研究性质的用处？与专家交换后发现其对锁与并发，高可用这块的掌握更是让人触目惊心。
所以笔者1再和身旁的朋友说，去IOE不是1件一挥而就的事情，需要给MySQL时间，否则这件好事情会像着另外一个方向而发展，乃至重复当年年Sybase替换Oracle的事件产生。但是好消息是这次的上层领导们终究开始认识到互联网的重要性，理解了安全可控对1个国家的重要性，而互联网公司的成熟经验具有很好的鉴戒意义。

总结

MySQL数据库早已不是原来的迷你数据库，其在功能性与性能方面都已大幅提升，随着SSD的突起，MySQL数据库已完全可以替换Oracle数据，而PostgreSQL还需要很长的路要走。但市场是开放的，就像Oracle称雄的年代，还有DB2，Sybase这样的数据库与之1较长短。我相信互联网时期，仍然是百花齐放的年代，没有谁可以1直占据优势，即使是MySQL也没有这个能力。

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

另外，如果不及时升级yum有时还会碰到在yum install时系统提示“找不到相干的安装包”这样的毛病。

安装mysql

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

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

你可使用以下命令启动和停止mySQL。
启动：

停止：

重启：

mySQL的配置与优化

配件文件所在路径

mySQL安装完后会生成以下几个重要目录：

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

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
东西很多，不要急，下面我们1个个参数来作说明。

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

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

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

1. [client]
2. port   = 3306 # 客户端端口号为3306
3. socket  = /data/3306/mysql.sock
4. default-character-set = utf8 
# 客户端字符集,(控制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服务运行时的端口号。建议更改默许端口,默许容易遭受攻击。
10. socket  = /data/3306/mysql.sock  
# socket文件是在Linux/Unix环境下独有的，用户在Linux/Unix环境下客户端连接可以不通过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毛病日志寄存路径及名称(启动出现毛病1定要看毛病日志,百分之百都能通错误误日志排插解决。)
15. pid-file=/data/3306/mysql.pid  
# MySQL_pid文件记录的是当前mysqld进程的pid，pid亦即ProcessID。
16. skip-locking
# 避免MySQL的外部锁定，减少出错概率，增强稳定性。
17. skip-name-resolv
# 制止MySQL对外部连接进行DNS解析，使用这1选项可以消除MySQL进行DNS解析的时候。但是需要注意的是，如果开启该选项，则所有远程主机连接授权都要使用IP地址方式了，否则MySQL将没法正常处理连接要求！
18. skip-networking  
# 开启该选项可以完全关闭MySQL的TCP/IP连接方式，如果Web服务器是以远程连接的方式访问MySQL数据库服务器的，则不要开启该选项，否则没法正常连接！
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  
# 设置每一个主机的连接要求异常中断的最大次数，当超过该次数，MySQL服务器将制止host的连接要求，直到MySQL服务器重启或通过flush hosts命令清空此host的相干信息。
23. wait_timeout = 120  
# 指定1个要求的最大连接时间，对4GB左右内存的服务器来讲，可以将其设置为5~10。
24. table_cache = 614K  
# table_cache唆使表高速缓冲区的大小。当MySQL访问1个表时，如果在MySQL缓冲区还有空间，那末这个表就被打开并放入表缓冲区，这样做的好处是可以更快速地访问表中的内容。1般来讲，可以查看数据库运行峰值时间的状态值Open_tables和Open_tables，用以判断是不是需要增加table_cache的值，即如果Open_tables接近table_cache的时候，并且Opened_tables这个值在逐渐增加，那就要斟酌增加这个值的大小了。
25. external-locking = FALSE  
# MySQL选项可以免外部锁定。True为开启。
26. max_allowed_packet =16M  
# 服务器1次能处理最大的查询包的值，也是服务器程序能够处理的最大查询
27. sort_buffer_size = 1M  
# 设置查询排序时所能使用的缓冲区大小，系统默许大小为2MB。
# 注意：该参数对应的分配内存是每一个连接独占的，如果有100个连接，那末实际分配的总排序缓冲区大小为100 x6=600MB。所以，对内存在4GB左右的服务器来讲，推荐将其设置为6MB~8MB
28. join_buffer_size = 8M
# 联合查询操作所能使用的缓冲区大小，和sort_buffer_size1样，该参数对应的分配内存也是每一个连接独享。
29. thread_cache_size = 64
# 设置Thread Cache池中可以缓存的连接线程最大数量，可设置为0~16384，默许为0.这个值表示可以重新利用保存在缓存中线程的数量，当断开连接时如果缓存中还有空间，那末客户真个线程将被放到缓存中;如果线程重新被要求，那末要求将从缓存中读取,如果缓存中是空的或是新的要求，那末这个线程将被重新创建，如果有很多线程，增加这个值可以改良系统性能。通过比较Connections和Threads_created状态的变量，可以看到这个变量的作用。我们可以根据物理内存设置规则以下:1GB内存我们配置为8,2GB内存我们配置为16,3GB我们配置为32,4GB或4GB以上我们给此值为64或更大的值。
30. thread_concurrency = 8  
# 该参数取值为服务器逻辑CPU数量x 2，在本例中，服务器有两个物理CPU，而每一个物理CPU又支持H.T超线程，所以实际取值为4 x 2 = 8。这也是双4核主流服务器的配置。
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
# 给常常访问的表分配的内存，物理内存越大，设置就越大。调大这个值，1般情况下可以下降磁盘IO，但相应的会占用更多的内存,这里设置为614。
39. table_open_cache = 512  
# 设置表高速缓存的数目。每一个连接进来，都会最少打开1个表缓存。因此， table_cache 的大小应与 max_connections 的设置有关。例如，对 200 个并行运行的连接，应当让表的缓存最少有 200 × N ，这里 N 是利用可以履行的查询的1个联接中表的最大数量。另外，还需要为临时表和文件保存1些额外的文件描写符。
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日志记录的是从服务器I/O线程将主服务器的2进制日志读取过来记录到从服务器本地文件,然后SQL线程会读取relay-log日志的内容并利用到从服务器
45. relay-log-info-file = /data/3306/relay-log.info  
# 从服务器用于记录中继日志相干信息的文件,默许名为数据目录中的relay-log.info。
46. binlog_cache_size = 4M  
# 在1个事务中binlog为了记录sql状态所持有的cache大小，如果你常常使用大的，多声明的事务，可以增加此值来获得更大的性能，所有从事务来的状态都被缓冲在binlog缓冲中，然后再提交后1次性写入到binlog中，如果事务比此值大，会使用磁盘上的临时文件来替换，此缓冲在每一个链接的事务第1次更新状态时被创建。
47. max_binlog_cache_size = 8M  
# 最大的2进制Cache日志缓冲尺寸。
48. max_binlog_size = 1G  
# 2进制日志文件的最大长度(默许设置1GB)1个2进制文件信息超过了这个最大长度之前,MySQL服务器会自动提供1个新的2进制日志文件接续上。
49. expire_logs_days = 7  
# 超过7天的binlog,mysql程序自动删除(如果数据重要,建议不要开启该选项)
50. key_buffer_size = 256M  
# 指定用于索引的缓冲区大小，增加它可得到更好的索引处理性能。对内存在4GB左右的服务器来讲，该参数可设置为256MB或384MB。
# 注意：如果该参数值设置得过大反而会使服务器的整体效力下降！
51. read_buffer_size = 4M  
# 读查询操作所能使用的缓冲区大小。和sort_buffer_size1样，该参数对应的分配内存也是每一个连接独享。
52. read_rnd_buffer_size = 16M
# 设置进行随机读的时候所使用的缓冲区。此参数和read_buffer_size所设置的Buffer相反，1个是顺序读的时候使用，1个是随机读的时候使用。但是二者都是针对与线程的设置，每一个线程都可以产生两种Buffer中的任何1个。默许值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,如果做主从，或多实例,serverid1定不能相同。
59. myisam_sort_buffer_size = 128M
# 当需要对履行REPAIR, OPTIMIZE, ALTER 语句重建索引时，MySQL会分配这个缓存，和LOAD DATA INFILE会加载到1个新表，它会根据最大的配置认真的分配的每一个线程。
60. myisam_max_sort_file_size = 10G
# 当重新建索引（REPAIR，ALTER，TABLE，或LOAD，DATA，TNFILE）时，MySQL被允许使用临时文件的最大值。
61. myisam_repair_threads = 1
# 如果1个表具有超过1个索引, MyISAM 可以通过并行排序使用超过1个线程去修复他们.
62. myisam_recover
# 自动检查和修复没有适当关闭的 MyISAM 表.
63. innodb_additional_mem_pool_size = 4M  
# 用来设置InnoDB存储的数据目录信息和其他内部数据结构的内存池大小。利用程序里的表越多，你需要在这里面分配越多的内存。对1个相对稳定的利用，这个参数的大小也是相对稳定的，也没有必要预留非常大的值。如果InnoDB用广了这个池内的内存，InnoDB开始从操作系统分配内存，并且往MySQL毛病日志写正告信息。默许为1MB，当发现毛病日志中已有相干的正告信息时，就应当适当的增加该参数的大小。
64. innodb_buffer_pool_size = 64M  
# InnoDB使用1个缓冲池来保存索引和原始数据，设置越大，在存取表里面数据时所需要的磁盘I/O越少。强烈建议不要果断地将InnoDB的Buffer Pool值配置为物理内存的50%~80%，应根据具体环境而定。
65. innodb_data_file_path = ibdata1:128M:autoextend  
# 设置配置1个可扩大大小的尺寸为128MB的单独文件，名为ibdata1.没有给出文件的位置，所以默许的是在MySQL的数据目录内。
66. innodb_file_io_threads = 4  
# InnoDB中的文件I/O线程。通常设置为4，如果是windows可以设置更大的值以提高磁盘I/O
67. innodb_thread_concurrency = 8  
# 你的服务器有几个CPU就设置为几，建议用默许设置，1般设为8。
68. innodb_flush_log_at_trx_commit = 1  
# 设置为0就等于innodb_log_buffer_size队列满后在统1存储，默许为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事务被回滚之前可以等待1个锁定的超时秒数。InnoDB在它自己的锁定表中自动检测事务死锁并且回滚事务。InnoDB用locak tables 语句注意到锁定设置。默许值是50秒。
74. innodb_file_per_table = 0  
# InnoDB为独立表空间模式，每一个数据库的每一个表都会生成1个数据空间。0关闭，1开启。
# 独立表空间优点：
# 1、每一个表都有自己独立的表空间。
# 2 、每一个表的数据和索引都会存在自己的表空间中。
# 3、可以实现单表在不同的数据库中移动。
# 4、空间可以回收（除drop table操作处，表空不能自己回收。）
75. [mysqldump]


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

mySQL安装完后，默许只能在本机进行SQL客户真个访问，如果你要使用1台远程主机，比如説：
mySQL安装在192.168.0.101上，你要通过192.168.0.1上的mySQL客户端登录192.168.0.101访问，默许是不允许的。
为了能够远程访问mySQL你必须配置远程可连接的用户信息。
1般来説：
为了简单，我们可以配置1个用户，用户名为“username@%”，这个%代表支持远程任何IP地址的客户端可以访问这台mySQL主机。
但是，1般来説为了安全，我们会把username@后面跟上1个具体的ip。
所以如果在mySQL刚安装终了时，root用户只可以作本地访问，为了开启远程访问功能我们1般都有1个root@%这样的用户名。

操作步骤以下：
1. 先登录本地mysql通过命令：

2. 在mysql命令符内履行以下语句:

在我的配置中有这么1段描写

此处注意了，网上对“慢查询”的配置，很多都已deprecated了，请参照我上述这类写法。

我们配置完后使用service mysqld restart重启mysql服务后，我们可以看到在/var/log目录下面会有1个mysqld-slow-query.log的文件 。

我们在sql客户端履行以下语句

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

这样看，仿佛有1些不太习惯对不对？
如果这个日志文件中有成千上百个日志，我们如果需要统计 Top10最慢的那些SQL分别是哪些。。。怎样办？
我们可使用mysqldumpslow命令

这个问题，我曾在面试时碰到过有人説“精通MYSQL“，因而我问了他们这么1个问题，结果是超过90%的人没法回答。
mySQL最重要的两种存储引擎InnoDB与Myisam，这是基础，1定要知道，下面来看。

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条件时，两种表的操作是1样的
InnoDB ： InnoDB 中不保存表的具体行数，也就是说，履行select count(*) from table时，InnoDB要扫描1遍全部表来计算有多少行
5） 物理结构不同

MyISAM ：每一个MyISAM在磁盘上存储成3个文件。第1个文件的名字以表的名字开始，扩大名指出文件类型。

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

6） anto_increment 机制不同

这是1道很早的面试题：

1张表,里面有ID自增主键,当insert了17条记录以后,删除第15,16,17条记录,再把Mysql重启,再insert1条记录,这条记录的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还需要保护MVCC1致；虽然你的场景没有，但他还是需要去检查和保护；
• MVCC ( Multi-Version Concurrency Control )多版本并发控制 

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

这行数据的删除版本必须是未定义的或比事务版本要大。这可以保证在事务开始之前这行数据没有被删除。

MySQL 的 Query Profiler 是1个使用非常方便的 Query 诊断分析工具，通过该工具可以获得1条Query 在全部履行进程中多种资源的消耗情况，如 CPU，IO，IPC，SWAP 等，和产生的 PAGE FAULTS，CONTEXT SWITCHE 等等，同时还能得到该 Query 履行进程中 MySQL 所调用的各个函数在源文件中的位置。
MySQL5.0.37版本以上支持PROFILING调试功能，让您可以了解SQL语句消耗资源的详细信息。由于它需要调用系统的getrusage()函数，所以只是在Linux/Unix类平台上才能使用，而不能在Windows平台上使用。而且，PROFILING是针对处理进程(process)而不是线程(thread)的，服务器上的其他利用，可能会影响您的调试结果，因此，这个工具合适开发进程中的调试，如果要在生产环境中调试使用，则要注意它的局限性。

为避免之前已把 SQL 寄存在 QCACHE 中， 建议在履行 SQL 时， 强迫 SELECT 语句不进行 QCACHE 检测。这样可以提交分析的准确性。

生活不易，码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠