加入收藏 | 设为首页 | 会员中心 | 我要投稿 东莞站长网 (https://www.0769zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长学院 > MySql教程 > 正文

MySQL之优化

发布时间:2022-04-11 18:27:41 所属栏目:MySql教程 来源:互联网
导读:MySQL的优化 : 一、我们可以且应该优化什么? 硬件 操作系统/软件库 SQL服务器(设置和查询) 应用编程接口(api) 应用程序 ------------------------------------------------------------ 二、优化硬件 如果你需要庞大的数据库表(2G),你应该考虑使用64位的硬
        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对于打开、读写都非常快。文件检查只需几秒种。
 
----------------------------------------------------------------
 
五、 优化应用
 
应该集中精力解决问题。
在编写应用时,应该决定什么是最重要的:
速度
操作系统间的可移植性
SQL服务器间的可移植性
使用持续的连接。.
缓存应用中的数据以减少SQL服务器的负载。
不要查询应用中不需要的列。
不要使用select * FROM table_name...
测试应用的所有部分,但将大部分精力放在在可能最坏的合理的负载下的测试整体应用。通过以一种模块化的方式进行,你应该能用一个快速“哑模块”替代找到的瓶颈,然后很容易地标出下一个瓶颈。
如果在一个批处理中进行大量修改,使用LOCK TABLES。例如将多个UPDATES或DELETES集中在一起。

(编辑:东莞站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    热点阅读