mysql数据库高并发解决方案,高并发下数据库如何优化
在Apache、PHP、mysql的架构中，MySQL对性能的影响最大，也是关键的核心部分。为了Discuz！论坛计划也是如此。MySQL设置是否合理优化，直接影响论坛的速度和承载量！同时，MySQL也是优化最难的部分，不仅需要了解一些MySQL专业知识，还需要长期的观察和统计，根据经验判断，然后设置合理的参数。
让我们来看看MySQL优化的一些基础知识。MySQL的优化分为两部分，一是服务器物理硬件的优化，二是MySQL本身(my.cnf)的优化。
磁盘寻道功能(磁盘I/O)。以现在的高速SCSI硬盘(7200转)为例。这种硬盘理论上每秒寻道7200次，是物理特性决定的。没有办法改变。MySQL每秒都在进行大量复杂的查询操作，对磁盘的读写量可想而知。因此，一般认为磁盘I/O是制约MySQL性能的最大因素之一。对于日均访问超过100万PV的Discuz！论坛，由于磁盘I/O的限制，MySQL的性能会很低！要解决这个约束，可以考虑以下解决方案：使用RAID-0 1磁盘阵列，注意不要尝试RAID-5，MySQL在RAID-5磁盘阵列上的效率不会像你想象的那么快。
CPU对于mysql应用，建议使用S.M.P架构的多路对称CPU。例如，可以使用两个英特尔至强3.6GHz CPUs。现在，我更喜欢使用4U服务器作为数据库服务器，而不仅仅是MySQL。
物理内存对于使用MySQL的数据库服务器，建议服务器内存不要小于2GB，建议使用4GB以上的物理内存。但是内存对于现在的服务器来说可以说是一个可以忽略的问题，高端服务器的内存在工作中基本都超过16G。
解决了上面的服务器硬件约束，我们再来看看MySQL自己的优化是怎么做的。MySQL本身的优化主要是对其配置文件my.cnf中的参数进行优化调整，下面是一些对性能影响较大的参数。由于my.cnf文件的优化设置与服务器硬件配置密切相关，我们指定一个假设的服务器硬件环境：
#vim /etc/my.cnf下面只列出my.cnf文件中段落[mysqld]的内容，其他段落的内容对MySQL的运行性能影响不大，我们就忽略不计吧。
#禁止MySQL解析外部连接。使用这个选项可以减少MySQL解析DNS的时间。但是需要注意的是，如果开启了这个选项，所有的远程主机连接授权都必须使用IP地址，否则MySQL将无法正常处理连接请求！
#back_log参数的值表示在MySQL暂时停止响应新请求之前，短时间内堆栈中可以存储多少请求。如果系统在短时间内有许多连接，您需要增加该参数的值，该参数指定传入TCP/IP连接的监听队列的大小。不同的操作系统对此队列的大小有自己的限制。试图将back_log设置得高于操作系统的限制将是无效的。默认值为50。对于Linux系统，建议将其设置为小于512的整数。
#key_buffer_size指定用于索引的缓冲区大小。增加它可以获得更好的索引处理性能。对于内存约为4GB的服务器，该参数可以设置为256M或384M。注意：将该参数设置得太大会降低服务器的整体效率！
#对查询进行排序时可以使用的缓冲区大小。注意：对应于该参数的分配内存是每个连接独占的。如果有100个连接，实际分配的总排序缓冲区大小为100 6=600 MB。所以对于4GB左右内存的服务器，建议设置为6-8M。
#读取查询操作可以使用的缓冲区大小。和sort_buffer_size一样，这个参数对应的分配内存是每个连接独占的。
#联合查询操作可以使用的缓冲区大小与sort_buffer_size相同，该参数对应的分配内存是每个连接独占的。
#指定MySQL查询缓冲区的大小。你可以在MySQL控制台中观察到，如果Qcache_lowmem_prunes _ prunes的值很大，说明经常缓冲不足；如果Qcache_hits的值非常大，则表明查询缓冲区的使用非常频繁。如果值很小，会影响效率，可以考虑不使用查询缓冲。Qcache_free_blocks，如果这个值很大，说明缓冲区有很多碎片。
#指定MySQL允许的最大连接进程数。如果访问论坛时经常出现连接过多的错误提及，则需要增加该参数的值。
#该参数的值是服务器的逻辑CPU数量*2。在这个例子中，服务器有2个物理CPU，每个物理CPU都支持H.T .超线程，所以实际值是4*2=8。
#开启此选项可完全关闭MySQL的TCP/IP连接模式。如果WEB服务器以远程连接方式访问MySQL数据库服务器，就不要打开这个选项！否则将无法正常连接！
PS:可能有人会说myisam无法抵抗太多的写操作，但是我可以通过架构来弥补。先说我现有数据库平台的容量：主从数据总量在几百吨以上，每天有十几亿pv的动态页面。还有几个大项目是通过数据接口调用的，总pv不算。(其中之一是单个数据库每天处理9000万个查询，因为memcached在早期没有部署)。而我整个数据库服务器的平均负载在0.5-1左右。
key _ buffer _ size这对于MyISAM表非常重要。如果只使用MyISAM表，可以将其设置为可用内存的30-40%。的合理值取决于索引大小、数据量和负载—请记住，MyISAM表使用操作系统的缓存来缓存数据，因此需要为它们保留一些内存。在许多情况下，数据比索引大得多。然而，总是需要检查是否所有的key _ buffers都被利用了——很少会出现。myi文件只有1GB，但是key _ buffer设置为4GB。这样做是浪费。如果您很少使用MyISAM表，请将key_buffer_size保持在16-32MB以下，以适应分配给磁盘的临时表索引。
Innodb _ buffer _ pool _ size——这对innodb表非常重要。Innodb比MyISAM表对缓冲更敏感。MyISAM可以在默认的key_buffer_size设置下运行，但是在默认的innodb_buffer_pool_size设置下，Innodb就像一只蜗牛。因为Innodb缓存数据和索引，所以不需要给操作系统留太多内存，所以如果只需要使用Innodb，可以将其可用内存设置为70-80%就可以了。应用于key_buffer的一些规则是——如果你的数据量不大，不会爆炸，那么你就不需要把innodb_buffer_pool_size设置得太大。
innodb _ additional _ pool _ size——这个选项对性能没有太大影响，至少在内存几乎足够分配的操作系统上是如此。但是，如果您仍然希望将其设置为20MB(或更大)，您需要查看Innodb中还需要分配多少内存。
Innodb_log_file_size在高写负载的情况下很重要，尤其是大型数据集。该值越高，性能越高，但请注意恢复时间可能会增加。我经常把它设置为64-512MB，这取决于服务器的大小。
innodb_log_buffer_size的默认设置。在中等强度的写负载和短事务的情况下，服务器性能也可以通过。如果出现更新操作高峰或负载较重，应考虑增加其值。如果它的值设置得太高，可能会浪费内存——每秒都会刷新一次，所以不需要设置超过1秒所需的内存空间。一般8-16MB就够了。系统越小，其价值就越小。
Innodb _ flush _ logs _ at _ Trx _ commit是因为Innodb比MyISAM慢1000倍，而且脑袋大吗？可能你忘了修改这个参数。默认值为1，这意味着每个提交的更新事务(或每个事务以外的语句)都将被刷新到磁盘，这相当消耗资源，尤其是在没有电池备份缓存的情况下。很多应用，尤其是从MyISAM改过来的应用，只是把它的值设置为2，也就是不会把日志刷新到磁盘，只刷新到操作系统的缓存。日志仍然会每秒刷新到磁盘，所以每秒1-2次更新的消耗通常不会丢失。如果设置为0，会快很多，但也相对不安全MySQL服务器崩溃时会丢失部分事务。设置为2将导致刷新到操作系统缓存的事务部分丢失。
table _ cache—打开一个表的开销会很大。例如，MYISAM标记该表正在使用的MyI文件头。你肯定不希望这种操作过于频繁，所以通常需要增加缓存的数量，这样才能最大限度的缓存打开的表。它需要操作系统的资源和内存，这对于目前的硬件配置来说当然不是问题。如果您有超过200个表，将其设置为1024可能比较合适(每个线程需要打开一个表)。如果连接数很大，请增加其值。我见过设置为10万的。
thread _ cache—创建和销毁线程的开销可能非常高，因为需要连接/断开每个线程。我通常至少设置为16。如果应用中有大量的跳转并发连接，Threads_Created的值比较大，那么我会增加它的值。其目的是避免在正常操作中创建新线程。
query _ cache——如果您的应用程序有很多读取，而没有应用程序级缓存，这将非常有用。不要设置的太大，因为维护起来也需要很大的开销，会拖慢MySQL。On通常设置为32-512Mb。设置好之后，最好能跟进一段时间，看看效果好不好。在一定的负载压力下，如果缓存命中率太低，就启用。
sort _ buffer _ size——如果您只有一些简单的查询，那么没有必要增加它的值，即使您有64GB的RAM。也许会降低性能。
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。