十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
mysql的最大连接数默认是100, 这个数值对于并发连接很多的数据库应用是远远不够的,当连接请求大于默认连接数后,就会出现无法连接数据库的错误,因此我们需要把它适当调大一些。
目前创新互联建站已为上1000家的企业提供了网站建设、域名、虚拟空间、网站改版维护、企业网站设计、驻马店网站维护等服务,公司将坚持客户导向、应用为本的策略,正道将秉承"和谐、参与、激情"的文化,与客户和合作伙伴齐心协力一起成长,共同发展。
调节方法为:
1.linux服务器中:改my点吸烟 f中的值就行了
2.Windows服务器中(我用的):
在文件“my.ini”中找到段 [mysqld],在其中添加一行
max_connections=200 ### 200可以更改为想设置成的值.
然后重启"mysql"服务。
/mysqladmin所在路径/mysqladmin -uroot -p variables
输入root数据库账号的密码后可看到
| max_connections | 1000 |
其他需注意的:
在编程时,由于用mysql语句调用数据库时,在每次之执行语句前,会做一个临时的变量用来打开数据库,所以你在使用mysql语句的时候,记得在每次调用完mysql之后就关闭mysql临时变量。
另外对于访问量大的,可以考虑直接写到文本中,根据预测的访问量,先定义假若是100个文件文件名依次为1.txt,2.txt...100.txt。需要的时候,再对所有文本文件中的数据进行分析,再导入数据库。
1、使用行级别锁,避免表级别或页级别锁
尽量使用支持行级别锁的存储引擎,如InnoDB;只在读操作显著多于写作的场景中(如数据仓库类的应用)使用表级别锁的存储引擎,如MyISAM;。
2、降低热巨锁(hot gaint lock)出现的可能性以尽可能避免全局互斥量
临界区(仅允许单一线程访问的资源)会严重降低MySQL系统并发性;InnoDB缓冲池(buffer pool)、数据字典等都是常见的临界区;幸运的是,新版本的InnoDB已经能够较好的运行于多核处理器,支持使用 innodb_buffer_pool_instances服务器变量建立多个缓冲池实例,每个缓冲池实例分别自我管理空闲列表、列表刷写、LRU以及其它跟缓冲池相关的数据结构,并通过各自的互斥锁进行保护。
3、并行运行多个I/O线程
通过innodb_io_capacity服务器变量等增加磁盘I/O线程的数量可以提高前端操作(如SELECT)的性能,不过,磁盘I/O线程的数量不应该超过磁盘的IOPS(7200RPM的单块硬件的IOPS数量一般为100个左右)。
此外,异步I/O也可以在一定程度上提高系统的并发能力,在Linux系统上,可以通过将MySQL的服务器变量innodb_use_native_aio的值设定为ON设定InnoDB可以使用Linux的异步I/O子系统。
4、并行后端任务
默认情况下,MySQL的清写(purge)操作(用于移除带删除标记的记录)由InnoDB的主线程完成,这可以降低内部资源竞争发生的概率,进而增强MySQL服务伸缩能力。不过,随着InnoDB内部各式各样的竞争越来越多,这种设置带来的性能优势已几乎不值一提,因此,生产环境中应该通过为innodb_purge_threads服务器变量设定为ON将主线程与清写线程分开运行。
5、单线程复制模型中的SQL线程是一个热区
在从服务器上并行运行多个SQL线程可有效提高MySQL从服务器性能,MySQL 5.6支持多线程复制(每库一个复制线程);
由于mysql是一个连接给一个线程,当并发高的时候,每秒需要几百个甚至更多的线程,其中创建和销毁线程还好说,大不了多耗费点内存,线程缓存命中率下降还有创建销毁线程的性能增加问题---这个问题不是特别大,重点是mysql底层瞬间处理这几百个线程提交的sql(有时候一个页面会有10多条sql,cpu一次只能处理一条sql)会导致cpu的上下文切换,性能抖动,然后性能下降。
限流算法目前程序开发过程常用的限流算法有两个:漏桶算法和令牌桶算法。
漏桶算法
漏桶算法的原理比较简单,请求进入到漏桶中,漏桶以一定的速率漏水。当请求过多时,水直接溢出。可以看出,漏桶算法可以强制限制数据的传输速度。如图所示,把请求比作是水滴,水先滴到桶里,通过漏洞并以限定的速度出水,当水来得过猛而出水不够快时就会导致水直接溢出,即拒绝服务。
图片来自网络
漏桶的出水速度是恒定的,那么意味着如果瞬时大流量的话,将有大部分请求被丢弃掉(也就是所谓的溢出)。
令牌桶算法
令牌桶算法的原理是系统以一定速率向桶中放入令牌,如果有请求时,请求会从桶中取出令牌,如果能取到令牌,则可以继续完成请求,否则等待或者拒绝服务。这种算法可以应对突发程度的请求,因此比漏桶算法好。
图片来自网络
漏桶算法和令牌桶算法的选择
两者的主要区别漏桶算法能够强行限制处理数据的速率,不论系统是否空闲。而令牌桶算法能够在限制数据的平均处理速率的同时还允许某种程度的突发流量。如何理解上面的含义呢?漏桶算法,比如系统吞吐量是 120/s,业务请求 130/s,使用漏斗限流 100/s,起到限流的作用,多余的请求将产生等待或者丢弃。对于令牌桶算法,每秒产生 100 个令牌,系统容量 200 个令牌。正常情况下,业务请求 100/s 时,请求能被正常被处理。当有突发流量过来比如 200 个请求时,因为系统容量有 200 个令牌可以同一时刻处理掉这 200 个请求。如果是漏桶算法,则只能处理 100 个请求,其他的请求等待或者被丢弃。