有这样一个表mytable
A bigint(20) primary key.
B varchar(2000),
C varchar(500),
D tinyint(2).
表中有300万条记录。现在要select * from mytable where A=? 这样的语句处理时间小于1毫秒，insert，update操作也是很简单的insert mytable (A,B,C,D) values(?,?,?,?); update也是单表根据key更新。
我测试大部分时间都超过1毫秒了，偶然小于1毫秒，大家有什么优化方案没有，数据库我用MYSQL好像还达不到这个要求，也许是我的技术问题吧. 反正这些都是可选择的，可以用其他数据库。
我想了，更新和插入可以采取异步更新到数据库的方式，但是查询呢？？
说明：如果同时把这些数据存在应用系统的内存，是可以解决的，但是耗费内存太大，而且不能持久保存，所以单纯这个方案否定了。
大家帮忙看看，谢谢了。
------解决方案--------------------------------------------------------
我也想知道
------解决方案--------------------------------------------------------
行不行的
------解决方案--------------------------------------------------------
SELECT 可以通过把整个表的所有字段都建成INDEX试试
INSERT和UPDATE不清楚该怎么实现?
------解决方案--------------------------------------------------------
partion分区，SQL2005有这个功能，不知道MySQL有没有。
在多CPU情况下效果明显，胡百敬书里有按时间分区的例子，代码有点长，自己去找吧。
建了索引后，对于大表Insert,Update都要花费时间长，分区后就相当于在小表上操作。
还有你可以异步多线程操作，就是发出指令就返回，让过程自己去搞，看起来是一瞬间，欺骗观众，实际还是多线程排队自己去处理。
还有一些小字典表你可以提前缓存起来到客户端哈希表中（比如在网站服务开始的时候就花点时间，把数据库里所有500行记录以内的数据缓存，大概就几兆内存而已），可以避免大多数inner join ，只在显示的时候把数据根据key-value对应上，哈希表O(1)的查找特性还是比较爽的，加上你节省的往返数据库通讯的时间成本，可以提升性能。这在系统架构上要改进。
大量数据插入，做输入缓存，利用bulk insert ,比如以前做的一个抗日投票，一天就600多万条记录插入，可以做输入缓存，比如缓存到类似Application这样的静态全局变量里就可以，达到一定行数，假设100，这次访问的倒霉蛋，执行一次批量插入，这比每秒执行几次插入n次，系统开销要小得多。
分布式缓存，适合在多处服务调用数据的情况下，假设你们公司的某个业务，历史上有多个服务器要调用，那么大家都不要连数据库，都去某一个服务器去取，只有这个服务器连数据库，比如大家都可以取用户信息，在MemCache服务器上，保存着用户实例，包括Session等还可以实现同步。MemCache服务是个巨大的哈希表，一般会有4G以上的内存。你也可以把所有对象序列化放进去，缺点是有个反序列化和通讯的过程。不过微软WCF架构已经支持了泛型。
------解决方案--------------------------------------------------------
小于1毫秒是没必要的，只要用户所有的等待不超过5秒，就是很正常的程序了。
10秒是可以接受的程序，1秒就是很优秀的程序。
------解决方案--------------------------------------------------------
顶