日期：2011-05-02 15:44:00 来源：本站整理
MySQL服务保护笔记(下)[MySQL防范]
本文“MySQL服务保护笔记(下)[MySQL防范]”是由七道奇为您精心收集，来源于网络转载，文章版权归文章作者所有，本站不对其观点以及内容做任何评价，请读者自行判断，以下是其具体内容：
利用的计划要点
假如MySQL利用占用的CPU超越10%就应当考虑优化了.
1.假如这个服务可以被其他非数据库利用替换（比方很多基于数据库的计数器完好可以用WEB日记统计替换）最好将其禁用.非用数据库不可吗?固然数据库的确可以简化很多利用的构造计划,但本身也是一个系统资源损耗对比大的利用.在某些情形下文本,DBM比数据库是更好的挑选,比方:很多利用假如没有很高的及时统计需求的话,完好可以先记录到文件日记中,按期的导入到数据库中做后续统计解析.假如还是需求记录简单的2维键－值对应构造的话可以利用近似于DBM的HEAP范例表.因为HEAP表全部在内存中存取,效率非常高,但服务器忽然断电时有大概呈现数据丧失,所以非常合适存储在线用户信息,日记等暂时数据.即便需求利用数据库的,利用假如没有太复杂的数据完好性需求的化,完好可以不利用那些支持外键的商业数据库,比方MySQL.只有非常需求完好的商业逻辑和事件完好性的时刻才需求Oracle这样的大型数据库.关于高负载利用来说完好可以把日记文件,DBM,MySQL等轻量级方法做前端数据采集格局,然后用Oracle MSSQL DB2 Sybase等做数据库仓库以完成复杂的数据库发掘解析工作.
有朋友和我说用尺度的MyISAM表替换了InnoDB表今后,数据库性能提高了20倍.
2.数据库服务的主要瓶颈:单个服务的衔接数.关于一个利用来说,假如数据库表构造的计划可以按照数据库原理的范式来计划的话,并且已经利用了最新版本的MySQL,并且按照对比优化的方法运行了,那么最后的主要瓶颈普通在于单个服务的衔接数,即便一个数据库可以支持并发500个衔接,最好也不要把利用用到这个地步,因为并发衔接数过大都据库服务本身用于调度的线程的开销也会非常大了.所以假如利用答应的话:让一台机械多跑几个MySQL服务分担.将服务均衡的筹划到多个MySQL服务端口上:比方app_1 ==> 3301 app_2 ==> 3302...app_9 ==> 3309.一个1G内存的机械跑上10个MySQL是很正常的.让10个MySQLD承当1000个并发衔接效率要比让2个MySQLD承当1000个效率高的多.当然,这样也会带来一些利用编程上的复杂度;
3.利用单独的数据库服务器（不要让数据库和前台WEB服务抢内存）,MySQL拥有更多的内存便大概能有效的举行后果集的缓存;在前面的启动脚本中有一个-O key_buffer=32M参数就是用于将缺省的8M索引缓存增添到32M（当然关于）
4.利用尽大概利用PCONNECT和polling机制,用于节俭MySQL服务成立衔接的开销,但也会造成MySQL并发链接数过量（每个HTTPD城市对应一个MySQL线程）;
5.表的横向拆分:让最常被拜候的10%的数据放在一个小表里,90%的历史数据放在一个归档表里（所谓:快慢表）,数据中间通过按期"搬迁"和按期删除无效数据来节俭,毕竟大部份利用（比方论坛）拜候2个月前数据的概率会非常少,并且代价也不是很高.这样关于利用来说老是在一个对比小的后果级中举行数据挑选,对比有利于数据的缓存,不要期望MySQL中对单表记录条数在10万级以上还有对比高的效率.并且有时刻数据没有必要做那么切确,比方一个快表中查到了某个人发表的文章有60条后果,快表和慢表的比例是1:20,那么便可以简单的预计这个人一共发表了1200篇.Google的搜索后果数也是一样:关于很多上十万的后果数,背面很多的数字都是通过一定的算法预计出来的.
6.数据库字段计划:表的纵向拆分（过渡范化）:将全部的定长字段（char, int等）放在一个表里,全部的变长字段（varchar,text,blob等）放在别的一个表里,2个表之间通过主键关联,这样,定长字段表可以得到很大的优化（这样可以利用HEAP表范例,数据完好在内存中存取）,这里也阐明别的一个原则,关于我们来说,尽大概利用定长字段可以通过空间的丧失换取拜候效率的提高.在MySQL4中也呈现了支持外键和事件的InnoDB范例表,尺度的MyISAM格局表和基于HASH构造的HEAP内存表,MySQL之所以支持多种表范例,实际上是针对差别利用供应了差别的优化方法;
7.细心的查抄利用的索引计划:可以在服务启动参数中加入 --log-slow-queries[=file]用于跟踪解析利用瓶颈,关于跟踪服务瓶颈最简单的办法就是用MySQL的status查看MySQL服务的运行统计和show processlist来查看当前服务中正在运行的SQL,假如某个SQL常常呈目前PROCESS LIST中,一.有大概被查询的此时非常多,二,里面有影响查询的字段没有索引,三,返回的后果数过大都据库正在排序（SORTING）;所以做一个脚本:比方每2秒运行以下show processlist;把后果输出到文件中,看毕竟是什么查询在吃CPU.
8.全文检索:假如呼应字段没有做全文索引的话,全文检索将是一个非常损耗CPU的功效,因为全文检索是用不上普通数据库的索引的,所以要举行呼应字段记录遍历.关于全文索引可以参考一下基于Java的全文索引引擎lucene的介绍.
9.前台利用的记录缓存:比方一个常常利用数据库认证,假如需求有更新用户最后登陆时间的操作,最好记录更新后就把用户放到一个缓存中（设置2个小时后过期）,这样假如用户在2个小时内再次利用到登陆,就直接从缓存里认证,避免了过于频繁的数据库操作.
10.查询优先的表应当尽大概为where和order by字句中的字段加上索引,数据库更新插入优先的利用索引越少越好.
总之:关于任何数据库单表记录超越100万条优化都是对比艰难的,关键是要把利用可以转化成数据库对比擅长的数据上限内.也就是把复杂需求简化成对比成熟的办理筹划内.
一次优化实战
以下例子是对一个论坛利用举行的优化:
1.用Webalizer替换了本来的通过数据库的统计.
2.首先通过TOP号令查看MySQL服务的CPU占用左右80%和内存占用:10M,阐明数据库的索引缓存已经用完了,改正启动参数,增添了-O key_buffer=32M,过一段时间等数据库安定后看的内存占用能否到达上限.最后将缓存一向增添到64M,数据库缓存才基本能充分利用.关于一个数据库利用来说,把内存给数据库比给WEB服务实用的多,因为MySQL查询速度的提高能加快web利用从而节俭并发的WEB服务所占用的内存资源.
3.用show processlist;统计常常呈现的SQL:
每分钟运行一次show processlist并记录日记:
* * * * * (/home/mysql/bin/mysql -uuser -ppassword < /home/chedong/show_processlist.sql >> /home/chedong/mysql_processlist.log)
show_processlist.sql里就一句:
show processlist;
比方可以从日记中将包含where的字句过滤出来:
grep where mysql_processlist.log
假如发现有死锁,一定要重新审视一下数据库计划了,关于普通情形:查询速度很慢,就将SQL where字句中没有索引的字段加上索引,假如是排序慢就将order by字句中没有索引的字段加上.关于有%like%的查询,考虑今后禁用和利用全文索引加快.
4.还是按照show processlist;看常常有那些数据库被频繁利用,考虑将数据库拆分到其他服务端口上.
MSSQL到MySQL的数据迁移:Access＋MySQL ODBC Driver
在从前的几次数据迁移实践历程中,我发现最简便的数据迁移历程并非通过专业的数据库迁移工具,也不是MSSQL自身的DTS举行数据迁移（迁移历程中间会有很多表出错误告诫）,但通过将MSSQL数据库通过ACCESS获得外部数据导入到数据库中,然后用ACCESS的表==>右键==>导出,拟定ODBC,通过MySQL的DSN将数据导出.这样迁移大部份数据城市非常顺利,假如导出的表有索引问题,还会出增添索引提醒（DTS就不行）,然后剩余的工作就是在MySQL中计划字段对应的SQL脚本了.
全文完
| 本文地址： | 与您的QQ/BBS好友分享! |
- 好的评价 如果您觉得此文章好，就请您
0%(0) 
- 差的评价 如果您觉得此文章差，就请您
0%(0) 
中查找“MySQL服务保护笔记(下)”更多相关内容
中查找“MySQL服务保护笔记(下)”更多相关内容评论内容只代表网友观点，与本站立场无关！
评论摘要(共 0 条，得分 0 分，平均 0 分)
查看完整评论