运用的方案要点
若是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剧本了。
版权声明：
原创作品，允许转载，转载时请务必以超链接编制标明文章 原始来由 、作者信息和本声明。否则将清查律例责任。
