手头上有个系统，mysq
l的记录大概达到几千万的级别，每日新增几百万条记录。可以将过时的记录清除，但库中要保存的记录肯定有几千万条，未来会过亿。现时已经分为100个表，但由于select,insert,update都非常频繁，现时show processlist看，经常出现lock表的
手头上有个系统，mysql的记录大概达到几千万的级别，每日新增几百万条记录。可以将过时的记录清除，但库中要保存的记录肯定有几千万条，未来会过亿。现时已经分为100个表，但由于select,insert,update都非常频繁，现时show processlist看，经常出现lock表的情况。已经做了一部分select的cache，但是update和insert与及一部select还是不可避免。现时觉得压力很大，应该怎样去优化呢？现时用的表类型是myisam的，当频繁select,insert,update的时候，无可避免经常出现lock表的情况。我想到的优化的方法有以下几个，大家觉得哪个好一点呢？或者还有什么其它建议。
1、将表类型由myisam转为innodb。innodb是行级锁的，可能会解决频繁锁表的问题。但是据以前我的实验证明，innodb无论是insert,select,update的速度，都比不上myisam，尤其是insert，差得很远，这样虽然不锁表，但速度是否会变得更慢呢？
2、在同一台机装多个mysql，分别listen多个端口。这样可以分更多的表，比如分为1000个，将锁表的机率再调低。
3、将update和insert打平，限制并发的粒度。如将update和insert都放到N个队列中，由一些独立的线程专门去做update和insert工作。这样可以避免频繁地update和insert
.上亿条记录有什么可怕的? 100张分表,每张100W的数据 MyISAM应付绰绰有余.(只要记录和索引不大的离谱.),但是为了你长远的生活美好一些,建议分到1000张.分了表日后再分库,分机器也容易.
2.如果使用INSERT,UPDATE多,表经常删除,建议定期REPAIR TABLE,此命令可以修复,同时对数据进行压缩.即可以杜绝问题，也可以保证性能。
3.BerkeleyDB 不值得选择.毕竟管理等等远不如MySQL.
4.如果改写多,建议用INNODB,你对InnoDB的操作肯定是AUTO_COMMIT=1模式,所以才会那么慢.InnoDB是事务数据引擎,不是小孩过家家的玩具.如果你不愿意每次都自己管理事务,可以用偷懒innodb_flush_log_at_trx_commit=0.InnoDB的性能略好于这个MyISAM引擎.而且稳定，不容易出错。这是王道。就是维护麻烦一点。
5.MySQL的QueryCache,是基于表控制的,任何对表的改写都回淘汰所有和此表相关的Cache,所以你不要指望在大规模改写的情况他给你提高查询速度,其实还是累赘.
6.我自己的测试,MySQL在HP380G3的机器上1000000记录的多种操作的速度都可以达到5000/s左右,模拟真实环境也可以达到数千/s,几百万的INSERT,UPDATE,有什么可怕.
7.机器性能的优化我就不提了RAID 0+1最好，内存至少〉2G。MySQL的优化我也不废话了。
转载请注明原文链接：请教关于mysql的优化
