本帖最后由 huangjiu1990 于 2009-12-16 17:46:16 编辑

解决方案 »

  1.   

    具体查询速度依赖于你的查询语句,比如如果直接根据KEY查询,而且查询字段不多,肯定很快,如果查询的字段多,有关联其他表,而且还有like这样的模糊查询,或者有很多查询条件,这些都是要考虑的因素。即使选择分区,分表,也要具体考虑业务上的东西,根据你数据的分布情况来处理。最简单的情况,比如:
    表mytable 
    A bigint(20) primary key. 
    B varchar(2000), 
    C varchar(500), 
    D tinyint(2). 表中有300万条记录。现在要select * from mytable where A=? 
    这样查询的话,不用分表,分区,1-2毫秒就可以查询出来。
      

  2.   

    没有你的具体的表结构,记录分布,无法帮你做什么分析。建议你可以读一下。http://dev.mysql.com/doc/refman/5.1/zh/optimization.html
    7. 优化
    7.1. 优化概述
    7.1.1. MySQL设计局限与折衷
    7.1.2. 为可移植性设计应用程序
    7.1.3. 我们已将MySQL用在何处?
    7.1.4. MySQL基准套件
    7.1.5. 使用自己的基准
    7.2. 优化SELECT语句和其它查询
    7.2.1. EXPLAIN语法(获取SELECT相关信息)
    7.2.2. 估计查询性能
    7.2.3. SELECT查询的速度
    7.2.4. MySQL怎样优化WHERE子句
    7.2.5. 范围优化
    7.2.6. 索引合并优化
    7.2.7. MySQL如何优化IS NULL
    7.2.8. MySQL如何优化DISTINCT
    7.2.9. MySQL如何优化LEFT JOIN和RIGHT JOIN
    7.2.10. MySQL如何优化嵌套Join
    7.2.11. MySQL如何简化外部联合
    7.2.12. MySQL如何优化ORDER BY
    7.2.13. MySQL如何优化GROUP BY
    7.2.14. MySQL如何优化LIMIT
    7.2.15. 如何避免表扫描
    7.2.16. INSERT语句的速度
    7.2.17. UPDATE语句的速度
    7.2.18. DELETE语句的速度
    7.2.19. 其它优化技巧
      

  3.   

    几百万这个数量级,是个比较尴尬的数字,很难说分与不分。如果增长趋势很明显,可以按比较容易辨别的字段做横向分割,比如日期/地区。如果表里面字段太多,特别是有较大的VARCHAR之类,而大部分查询条件又很难100%依赖索引,则纵向切割(甚至夸张到Key-Value)
      

  4.   


    我觉得这个问题问得有问题——你觉得在一台386的机器上和一台至强的机器上时间会一样么?CPU,内存大小,硬盘速度,表的设计都是有关系的。