mysql数据库的优化.doc

  1. 1、本文档共11页,可阅读全部内容。
  2. 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
mysql数据库的优化

数据库性能优化涉及到系统硬件和软件的方方面面,本文以mysql为例,讨论了mysql性能优化的各个方面,包括: 硬件 操作系统/软件库 SQL服务器(设置和查询) 应用编程接口(API) 应用程序 一、优化硬件 如果你需要庞大的数据库表(2G),你应该考虑使用64位的硬件结构,像Alpha、Sparc、IA64。因为MySQL内部使用大量64位的整数,64位的CPU将提供更好的性能。 对大数据库,优化的次序一般是RAM、快速硬盘、CPU能力。 更多的内存通过将最常用的键码页面存放在内存中可以加速键码的更新。 如果不使用事务安全(transaction-safe)的表或有大表并且想避免长文件检查,一台UPS就能够在电源故障时让系统安全关闭。 对于数据库存放在一个专用服务器的系统,应该考虑1G的以太网。延迟与吞吐量同样重要。 二、优化磁盘 为系统、程序和临时文件配备一个专用磁盘,如果确是进行很多修改工作,将更新日志和事务日志放在专用磁盘上。 低寻道时间对数据库磁盘非常重要。对与大表,你可以估计你将需要log(行数)/log(索引块长度/3*2/(键码长度? +? 数据指针长度))+1次寻到才能找到一行。对于有500000行的表,索引Mediun? int类型的列,需要log(500000)? /? log(1024/3*2/(3? +? 2))+1=4次寻道。上述索引需要500000*7*3/2=5.2M的空间。实际上,大多数块将被缓存,所以大概只需要1-2次寻道。 然而对于写入(如上),你将需要4次寻道请求来找到在哪里存放新键码,而且一般要2次寻道来更新索引并写入一行。 对于非常大的数据库,你的应用将受到磁盘寻道速度的限制,随着数据量的增加呈N? log? N数据级递增。 将数据库和表分在不同的磁盘上。在MySQL中,你可以为此而使用符号链接。 条列磁盘(RAID? 0)将提高读和写的吞吐量。 带镜像的条列(RAID? 0+1)将更安全并提高读取的吞吐量。写入的吞吐量将有所降低。 不要对临时文件或可以很容易地重建的数据所在的磁盘使用镜像或RAID(除了RAID? 0)。 在Linux上,在引导时对磁盘使用命令hdparm? -m16? -d1以启用同时读写多个扇区和DMA功能。这可以将响应时间提高5~50%。 在Linux上,用async? (默认)和noatime挂载磁盘(mount)。 对于某些特定应用,可以对某些特定表使用内存磁盘???但通常不需要。 三、优化操作系统 不要交换区。如果内存不足,增加更多的内存或配置你的系统使用较少内存。 不要使用NFS磁盘(会有NFS锁定的问题)。 增加系统和MySQL服务器的打开文件数量。(在safe_mysqld脚本中加入ulimit? -n? #)。 增加系统的进程和线程数量。 如果你有相对较少的大表,告诉文件系统不要将文件打碎在不同的磁道上(Solaris)。 使用支持大文件的文件系统(Solaris)。 选择使用哪种文件系统。在Linux上的Reiserfs对于打开、读写都非常快。文件检查只需几秒种。 四、选择应用编程接口 PERL 可在不同的操作系统和数据库之间移植。 适宜快速原型。 应该使用DBI/DBD接口。 PHP 比PERL易学。 使用比PERL少的资源。 通过升级到PHP5可以获得更快的速度。 C MySQL的原生接口。 较快并赋予更多的控制。 低层,所以必须付出更多。 C++ 较高层次,给你更多的时间来编写应用。 仍在开发中 ODBC 运行在Windows和Unix上。 几乎可在不同的SQL服务器间移植。 较慢。MyODBC只是简单的直通驱动程序,比用原生接口慢19%。 有很多方法做同样的事。很难像很多ODBC驱动程序那样运行,在不同的领域还有不同的错误。 问题成堆。Microsoft偶尔还会改变接口。 不明朗的未来。(Microsoft更推崇OLE而非ODBC) ODBC 运行在Windows和Unix上。 几乎可在不同的SQL服务器间移植。 较慢。MyODBC只是简单的直通驱动程序,比用原生接口慢19%。 有很多方法做同样的事。很难像很多ODBC驱动程序那样运行,在不同的领域还有不同的错误。 问题成堆。Microsoft偶尔还会改变接口。 不明朗的未来。(Microsoft更推崇OLE而非ODBC) JDBC 理论上可在不同的操作系统何时据库间移植。 可以运行在web客户端。 Python和其他 可能不错,可我们不用它们。 五、优化应用 应该集中精力解决问题。 在编写应用时,应该决定什么是最重要的: 1、速度 2、操作系统间的可移植性 3、SQL服务器间的可移植性 4、使用持续的连接。 5、缓存应用中的数据以减少SQL服务器的负载。 6、不要查询应用

文档评论(0)

jgx3536 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

版权声明书
用户编号:6111134150000003

1亿VIP精品文档

相关文档