大并发下,mysql表锁住了 400 请求出错 

每5秒钟内就有1万条数据插入，该不会是一个长事务吧？ 还是每次写一条就提交呢？
######@苗威 : 嗯嗯，我这次也就是准备用这个方法解决，谢谢你啦，嘿嘿######@李密 : 一次写一批，与一般的处理方法不一样，可以纵向分表，分库######@李密 : 1万左右的数据，就不用存硬盘了，用内存，java缓存组件也行，memcached也行，Mysql Memory引擎 也行，使用过的删掉，新的添上去。######@李密 : 这个就算作是一种“分区表”的应用啦。对每个运营商指定对应的表，然后在应用层做映射。 1W/5sec的插入加上高并发读取算不小的负荷，不知道使用pgsql（配合分区表）是否能解决性能问题。######@李密 : 能解决问题的方法就是好方法######

这张表因为要和游戏通信，包含很多必须的字段，字段总数有16个，目前服务器200台，以后估计至少500台，那时候插入和查询数量就更恐怖了，所以我越来越担心以后这个项目问题会卡在这个表上 (昨天(22:10) by 李密)

可以通过把字段分表方式避免单表过大。不过以你远期规模使用现在这种数据库结构肯定会崩溃。如果可行（楼主有权设计修改表结构），建议楼主考虑重新设计数据库表甚至更换数据库（有钱换oracle，免费换pgsql）。

另外，并发读写巨大，磁盘性能很重要，要么用SCSI/SAS阵列要么直接上SSD（但SSD的寿命也许需要考虑）。

 

已经运营两个月了，表内目前数据1000多万。

一年就6千万，如果不做分区表（以时间划分）那么迟早崩溃

java项目+mysql都在这一台服务器上

楼上还有朋友说读写分离，现在连数据库都不是独立服务器，估计再跑几个月就会葛屁的

 

关于pgsql和mysql比较的一些帖子

http://www.oschina.net/question/126398_23854
http://www.oschina.net/question/96003_13994
http://www.oschina.net/question/129318_19029

 

 

######

redis和Mysql Memory引擎 都行，10W条数据没问题

###### @苗威 : 嗯嗯，谢谢你这么耐心帮我，嘿嘿，以后多向你请教###### @李密: 客气，我也只有些理论基础，分表可以水平分，和垂直分，水平分是各个运营商分，垂直分是把所有的邀请码分成若干张表，比如用最后一个字符分，邀请码如果是字符串最好能换成int存，压缩会加快很多查找速度######抽空我研究下，目前想临时采用分表把这个问题解决下，给每个运营商动态分配一个礼品表，运营商两年内也不会超过200个，表的数量也不会有太多，先分表。威哥，你觉得这样设计有重大缺陷不？因为之前我还没这样做过######是 innodb 还是 myisam 呢
######薯哥哥，是innodb表######锁表应该是在innodB下发生的吧..myisam直接坏表了
######是innodb######这种情况充分说明内存缓存设计的重要性
######天啊..大并发居然用innodB..

  我测试过innodB的写入性能是非常低的,cpu效率不高..插入爆慢..

建议读写分离..写可以innodB,读还是myisam吧..

###### @gamespoerleveling : 没用的，读库同样存在数据更新问题。在从innodb写库同步到myisam读库时如果读库正好是访问高峰，那么就会遇到楼主现在同样的锁表情况。 总而言之，在大数据量大并发下mysql就是个坑爹的杯具～###### @mark35 : 我是说的读写分离...读myisam的表###### @hulei : 坏不坏表不好说, 但表锁的代价肯定比行锁高!######myisam是表锁啊，这种程度的数据输入myisam必坏表啊。######在myisam上大并发读写将会更悲摧的～###### ######那paulwong最后是怎么解决呢？可以分享下吗？######所有clinet直连 mysql server ？应该有数据库中间层吧######

这样的业务逻辑就感觉有问题，以前在唯晶的时候，也做过类似的

为什么要每分钟过来1w，3w的记录？直接生成个百万条记录分给他们去用就行了，

就只有检索和更新了

###### @陈俊贤 : 楼主这种应用采用读写分离意义不大并且还可能产生问题：通常情况下查询都会是有效查询，查询到记录就会产生关联写（改写激活码使用状态）。读写分离后数据肯定不是实时同步，那么当记录修改后（激活码已使用）在同步到读库这段时间中读库的该条记录查询结果都是老状态（激活码未使用），事务就不能保证一致了！###### @mark35 : 读写分离只是执行缓刑，不改这个逻辑，死刑是早晚的事###### @陈俊贤 : 读写分离不能根本解决问题的。或者说大家觉得读写分离是银弹那多半是因为mysql本来实在低能，用上读写分离就有效提高性能。但实际上即使使用读写分离也同样存在节点更新问题（写库同步到读库）。###### @李密 : 那就读写分离，照你说的话以后多半会崩掉###### @mark35 : 目前卡的类别已经达到500种以上，所以以后生成量更恐怖了。。。