热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

mysql优化之连接优化

PostedbyMoneyTalkson20120223|第一篇序章第二篇连接优化第三篇索引优化第四篇查询优化第五篇到实战中去连接优化连接优化主要

 

第一篇 序章
第二篇 连接优化
第三篇 索引优化
第四篇 查询优化
第五篇 到实战中去

连接优化

连接优化主要指客户端连接数据库以及数据库为响应客户端的请求而打开数据表和索引的过程中涉及到的参数调整。原文可以参考这里或者这里。(原文链接 http://ddbiz.com/?p=950)
尽管不同的mysql发行版本的编译和链接方式也会影响到客户端的链接请求,但是由于我的系统多是直接安装mysql的发行包,且很少会做改动,因此关于手动编译mysql的以达到优化的目的的方面,此处无法聊及,或许日后会有机会涉足其中。

根据MySQL如何使用内存中的说法,下面的参数会影响到客户端的每个请求:

  1. open-files-limit

    命令行参数: –open-files-limit=#
    ini/cnf参数: open-files-limit
    mysql 变量: open_files_limit
    全局变量,不可动态调整,取值范围 0到65535。
    open_files_limit指mysql能够打开的文件句柄数。该值不足时,会引发 Too many open files错误。具体需要多少个文件句柄,还需要根据 max_connections 和 table_open_cache来计算。
    一个有趣的现象是,在我的64bit linux中, –open-files-limit或者–open_files_limit可以设置超过 64k,如:
    --open-files-limit

    open-files-limit可能受到操作系统的限制,比如linux中,/proc/sys/fs/file-max,就限制了系统最大能够开启的文件句柄数目。像oracle在linux的安装运行要求,对最低要求就是要超过 64k. 可以通过修改/etc/sysctl.conf,增加或者修改 fs.file-max=#来增加系统最大打开值,别忘了修改完了,用 sysctl -p 来启用新值(以上操作为centos/rhel)。
    在linux中,还有一个参数可能会限制系统最大打开文件数值,就是/etc/security/limits.conf
    fs.file-max
    具体如何修改其值,请参考系统文档

    受如下参数影响: 受系统限制
    将影响如下参数: max_connections table_open_cache
    调整触发条件: 当系统出现 Too many open files 时需要调整此参数。

  2. thread_stack

    命令行参数: –thread_stack=#
    ini/cnf参数: thread_stack
    mysql 变量: thread_stack
    全局变量,不可动态调整。
    32bit系统中默认为192k, 64bit系统中默认为256k. 先谈及thread_stack是因为他对下面要讲的max_connections有关键影响因素。

    thread_stack 对应于操作系统层面中的stack size,windows中的默认线程的stack size为1M, linux根据版本不同会有变化,一般在8m或者10m。在我的几个Centos 5.x/6.x中,默认的stack size 都是10M(这要比windows高出10倍)

    ulimit -s
    10240

    stack size在32bit的OS中是一个很重要的参数,减少一个线程的stack size可以增加线程数,比如从10m减少到64k。但是在64bit的Linux(内核版本>= 2.6.x)中,如果允许 /proc/sys/vm/overcommit_memory,stack size或许没那么重要了。

    受如下参数影响: 无
    将影响如下参数: max_connections
    调整触发条件: max_connections 已经达到当前系统允许的最大值。

  3. max_connections

    命令行参数: –max_connections 或者 –max-connections
    ini/cnf定义: max_connections
    mysql 变量: max_connections
    全局变量,可动态调整

    MySQL数据库允许的并发连接数
    对于一个访问者众多(pv值很高)的网站来说,有时可能会发生 : Too many connections 的错误。可以考虑增加此值。对于MySQL来说,能够支持的最大的并发连接数,取决于很多因素,包括:

    1. 操作系统线程模型、操作系统版本(参见 thread_size)
    2. 可用的内存数量
    3. 每个连接的内存使用量/工作负载(参见 thread_size)
    4. 预期的服务器响应时间

    在内存允许的情况下,32bit windows可以支持最大2000左右的并发请求(因为单进程最大支持的内存为2G,而默认的一个线程需要资源为1MB),64bit windows 也可以根据内存计算得出可支持的线程数。(关于windows中可用线程估算,可以参考Mark Russinovich的文章Pushing the Limits of Windows: Processes and Threads,或者参考微软的一篇简述(进程地址空间))。
    而Linux中的因素可能更复杂,不过 stack_size 依然如同windows中一样,是制约线程数的一个重要因素,最大线程数在Liunx下也有默认值,cat /proc/sys/kernel/threads-max, 当不调整这个值时,MySQL的max_connections应该远小于它。

    在实际应用中,可支持的并发数将会远小于理论值,因为每个线程不可能只是空连接一下就断开。线程工作时的CPU/内存损耗,会降低整个系统的可用资源调配。对于MySQL来说,其提供了一个可以调整stack size的参数: thread_stack.
    mysql 的 max_connections * thread_stack 应小于可用内存;根据mysql的官方文档(doc5.5),linux(或者solaris)下,可以支持500到1000个并发连接,如果每个连接的工作很小,且服务器内存很大的话,那么可以支持到10k的链接。在windows下,则有一个 (open tables*2+open connection) <2048的限制。因此:

    受如下参数影响: thread_stack table_open_cache open_file_limit
    将影响如下参数: 无
    调整触发条件: 当threads_connected(show status like ‘threads_connected’) 接近 max_connections 时,应该采取行动提高并发数.

  4. thread_cache_size

    命令行参数: –thread_cache_size
    ini/cnf定义: thread_cache_size
    mysql 变量: thread_cache_size
    全局变量,可动态调整, 默认值0,最大值16k

    mysql使用此参数限定数据库服务中,缓存多少个线程共客户端使用。 如果服务器每秒都有几百个新的连接出现,那么这个值应该挑高一些。通过评测connections和threads_created判定是否需要增加thread_cache_size.
    mysql> show status like ‘%connections%’; 输出
    Connections 尝试连接请求(包括不能成功建立连接的请求)
    Max_used_connections 最大并发连接数量

    mysql> show status like ‘threads_c%’; 输出
    threads_cached 当前缓存线程数
    threads_connected 当前连接数
    thread_created 线程创建数

    当连接缓存的利用率( thread cache hit =(connections – threads_created)/connections*100%) 的值较低时,表明mysql需要创建更多的线程(线程缓存不够了)来接受客户端请求。

    受如下参数影响: 无
    将影响如下参数: 无
    调整触发条件: 当thread cache hit较低时,应该采取行动提高thread_cache_size此值.

  5. table_open_cache/table_cache

    命令行参数: –table-open-cache
    ini/cnf定义: table_open_cache
    mysql 变量: table_open_cache
    全局变量,可动态调整, 默认值400,最大值512k

    mysql打开表的描述符,被缓存在table_open_cache中,table_open_cache >= max_connections * 2,这是因为有些表打开时,需要两个文件符,如myisam表,另外还有index、临时表等的文件符。自链接的查询语句,会额外再多开启一个该表的文件符。

    一个针对性的设置是,找到和数据库有关的所有最复杂的查询语句(包括自链接,left/right/outer join,以及group 等统计语句)查看这些链接将打开多少数据表,设定此值为 N,则

    table_open_cache > max_connections * N

    受如下参数影响: max_connections open_file_limit
    将影响如下参数: max_connections
    调整触发条件: 当opened_tables(show status like ‘opened_tables’)值很大时,应该采取行动提高table_open_cache此值.

  6. net_buffer_length

    命令行参数: –net_buffer_length
    ini/cnf定义: net_buffer_length
    mysql 变量: thread_cache_size
    全局变量,可动态调整, 默认值16k,范围1k到1m.

    客户端连接时的缓冲和结果缓冲, 可以动态调整(自动调整,意味着 set net_buffer_length=xxx是无效的)到最大max_allowed_packet的大小。每个SQL语句结束后,这个值会恢复到初始值。内存不足时–这个情况也很少了,毕竟现在内存这么便宜–或者并发连接很大时,可以适当的缩小这个初始值,比如1k.

    受如下参数影响: max_allowed_packet
    将影响如下参数: 无
    调整触发条件: 如果要装载/导入/导出大量数据时;查询结果中包含大的数据字段时,如TEXT,BLOB等

  7. max_allowed_packet

    命令行参数: –max_allowed_packet
    ini/cnf定义: max_allowed_packet
    mysql 变量: max_allowed_packet
    全局变量,可动态调整, 默认值1m,范围1k到1g.

    客户端和服务端的max_allowed_packet需要一致,或者客户端的max_allowed_packet要大于服务端的max_allowed_packet。

    受如下参数影响: 无
    将影响如下参数: 无
    调整触发条件: 如果要装载/导入/导出大量数据时;查询结果中包含大的数据字段时,如TEXT,BLOB等

    Q:max_allowed_packet和net_buffer_length会影响load data infile吗?
    A:No 

  8. wait_timeout

    命令行参数: –wait_timeout
    ini/cnf定义: wait_timeout
    mysql 变量: wait_timeout
    全局变量,可动态调整, 默认值8小时,范围1秒到31536000.
    wait_timeout定义了一个已连接的客户端在不进行任何查询动作时最常的空闲时间。
    注意:对已经建立的连接将不产生影响。
    可以通过 show processlist 来查看当前数据库连接的状况,如:
    [singlepic id=96 w=320 h=240 float=none]

    受如下参数影响:
    将影响如下参数: max_connections
    调整触发条件: 短链接、高并发的系统应用中.

上一篇 序章 下一篇 索引优化


推荐阅读
  • 基于PgpoolII的PostgreSQL集群安装与配置教程
    本文介绍了基于PgpoolII的PostgreSQL集群的安装与配置教程。Pgpool-II是一个位于PostgreSQL服务器和PostgreSQL数据库客户端之间的中间件,提供了连接池、复制、负载均衡、缓存、看门狗、限制链接等功能,可以用于搭建高可用的PostgreSQL集群。文章详细介绍了通过yum安装Pgpool-II的步骤,并提供了相关的官方参考地址。 ... [详细]
  • 本文介绍了数据库的存储结构及其重要性,强调了关系数据库范例中将逻辑存储与物理存储分开的必要性。通过逻辑结构和物理结构的分离,可以实现对物理存储的重新组织和数据库的迁移,而应用程序不会察觉到任何更改。文章还展示了Oracle数据库的逻辑结构和物理结构,并介绍了表空间的概念和作用。 ... [详细]
  • Oracle Database 10g许可授予信息及高级功能详解
    本文介绍了Oracle Database 10g许可授予信息及其中的高级功能,包括数据库优化数据包、SQL访问指导、SQL优化指导、SQL优化集和重组对象。同时提供了详细说明,指导用户在Oracle Database 10g中如何使用这些功能。 ... [详细]
  • 本文介绍了Oracle数据库中tnsnames.ora文件的作用和配置方法。tnsnames.ora文件在数据库启动过程中会被读取,用于解析LOCAL_LISTENER,并且与侦听无关。文章还提供了配置LOCAL_LISTENER和1522端口的示例,并展示了listener.ora文件的内容。 ... [详细]
  • 本文讨论了在数据库打开和关闭状态下,重新命名或移动数据文件和日志文件的情况。针对性能和维护原因,需要将数据库文件移动到不同的磁盘上或重新分配到新的磁盘上的情况,以及在操作系统级别移动或重命名数据文件但未在数据库层进行重命名导致报错的情况。通过三个方面进行讨论。 ... [详细]
  • 本文介绍了在CentOS上安装Python2.7.2的详细步骤,包括下载、解压、编译和安装等操作。同时提供了一些注意事项,以及测试安装是否成功的方法。 ... [详细]
  • Windows7 64位系统安装PLSQL Developer的步骤和注意事项
    本文介绍了在Windows7 64位系统上安装PLSQL Developer的步骤和注意事项。首先下载并安装PLSQL Developer,注意不要安装在默认目录下。然后下载Windows 32位的oracle instant client,并解压到指定路径。最后,按照自己的喜好对解压后的文件进行命名和压缩。 ... [详细]
  • Oracle优化新常态的五大禁止及其性能隐患
    本文介绍了Oracle优化新常态中的五大禁止措施,包括禁止外键、禁止视图、禁止触发器、禁止存储过程和禁止JOB,并分析了这些禁止措施可能带来的性能隐患。文章还讨论了这些禁止措施在C/S架构和B/S架构中的不同应用情况,并提出了解决方案。 ... [详细]
  • EPICS Archiver Appliance存储waveform记录的尝试及资源需求分析
    本文介绍了EPICS Archiver Appliance存储waveform记录的尝试过程,并分析了其所需的资源容量。通过解决错误提示和调整内存大小,成功存储了波形数据。然后,讨论了储存环逐束团信号的意义,以及通过记录多圈的束团信号进行参数分析的可能性。波形数据的存储需求巨大,每天需要近250G,一年需要90T。然而,储存环逐束团信号具有重要意义,可以揭示出每个束团的纵向振荡频率和模式。 ... [详细]
  • 本文是一位90后程序员分享的职业发展经验,从年薪3w到30w的薪资增长过程。文章回顾了自己的青春时光,包括与朋友一起玩DOTA的回忆,并附上了一段纪念DOTA青春的视频链接。作者还提到了一些与程序员相关的名词和团队,如Pis、蛛丝马迹、B神、LGD、EHOME等。通过分享自己的经验,作者希望能够给其他程序员提供一些职业发展的思路和启示。 ... [详细]
  • 本文介绍了Java工具类库Hutool,该工具包封装了对文件、流、加密解密、转码、正则、线程、XML等JDK方法的封装,并提供了各种Util工具类。同时,还介绍了Hutool的组件,包括动态代理、布隆过滤、缓存、定时任务等功能。该工具包可以简化Java代码,提高开发效率。 ... [详细]
  • 在CentOS/RHEL 7/6,Fedora 27/26/25上安装JAVA 9的步骤和方法
    本文介绍了在CentOS/RHEL 7/6,Fedora 27/26/25上安装JAVA 9的详细步骤和方法。首先需要下载最新的Java SE Development Kit 9发行版,然后按照给出的Shell命令行方式进行安装。详细的步骤和方法请参考正文内容。 ... [详细]
  • CentOS 7部署KVM虚拟化环境之一架构介绍
    本文介绍了CentOS 7部署KVM虚拟化环境的架构,详细解释了虚拟化技术的概念和原理,包括全虚拟化和半虚拟化。同时介绍了虚拟机的概念和虚拟化软件的作用。 ... [详细]
  • Python SQLAlchemy库的使用方法详解
    本文详细介绍了Python中使用SQLAlchemy库的方法。首先对SQLAlchemy进行了简介,包括其定义、适用的数据库类型等。然后讨论了SQLAlchemy提供的两种主要使用模式,即SQL表达式语言和ORM。针对不同的需求,给出了选择哪种模式的建议。最后,介绍了连接数据库的方法,包括创建SQLAlchemy引擎和执行SQL语句的接口。 ... [详细]
  • 一句话解决高并发的核心原则
    本文介绍了解决高并发的核心原则,即将用户访问请求尽量往前推,避免访问CDN、静态服务器、动态服务器、数据库和存储,从而实现高性能、高并发、高可扩展的网站架构。同时提到了Google的成功案例,以及适用于千万级别PV站和亿级PV网站的架构层次。 ... [详细]
author-avatar
寡凫lo单鹄官方
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有