咨询一个数据表优化的问题，请帮忙

eddie

由于业务需求，数据要求实时查询展示，所以，是一个表承担了数据的插入、修改、删除和查询的职能。
表字段有20个，其中有不少varchar字段类型。
最初对mysql不了解，所以设计上没有做太多考虑。说下问题：
运行了半年，表数据大概有50万左右，表容量为300M，索引容量为160M，由于查询的要求，关联查询和order by desc查询较多，所以建立了6个复合索引。插入和修改的频率很高，基本上每分钟最少10次更新查询，最高的时候可以达到上百次，为多个终端进行操作。
现在的问题是：如果停止更新，查询效率很高，即便是关联查询基本都在1秒内可以完成，但一旦启动终端使用，更新操作开始，查询效率变的很低，更新操作也是如此，最简单的一个delete操作，都会耗费30秒的时间。初步判断是索引太多，每次更新会对索引操作造成影响。
服务器性能不高为：酷睿双核 4GB内存
做了不少优化，效果一般，对此表做了分区处理，但性能提升不明显，基本和以前效果一样。
请教各位，这种情况还可以做哪些优化？将此表拆分成多个表操作？还是通过mysql的优化方法就可以了，请多多指教

kider

首先你的表不大，应该是设计问题带来的性能问题。试试以下优化：
1、用innodb表引擎，使用行锁
2、表不大，索引多，建议把联合索引都拆成单个索引，可能效果要好些，不要有重复索引，同时文本字段的话建“前置”索引。
3、打开慢日志，用explain具体分析慢SQL
...

eddie

谢谢kider的答复

表引擎我修改过，现在用的是myisam引擎，看到资料说innodb是行锁定，所以我修改测试过，在什么都不进行修改的情况下，仅修改引擎为innodb，反而查询效率变低了，一直不得其解。

查看资料，mysql对order by desc支持不是很好，需要将查询的条件和内容建立到复合索引中才可以使用所以进行order by desc，不知理解是否正确，如果都建立独立所以，是否会对order by desc查询造成影响，现在系统的order by desc基本上都是时间排序

查看了一下系统状态，存在Copying to tmp table on disk或Copying to tmp table状态较多，是否可以通过增大tmp_table_size解决？

盼赐教