恩，我也来说说：P关于数据库的优化，有很多部分，呵呵，硬件升级，参数配置优化，数据库表结构优化，应用实例的优化（菜鸟一个，大家别见怪：P）我就说说数据库表结构设计和应用时优化的一些个人看法吧：P首先说说记录数的问题： 单表有大小限制大家都说了， 另外，单条记录占用空间同样影响这个保证性能的记录数分界点， 再次，建立索引的字段的索引长度也影响着这个数值， 另外，在具体应用中你的查询结果集和实际查询行数也可能决定着这个数值。 举个例子吧，如果有这样一张表 tab_name( id int(10) unsigned not null auto_increament, flag enum('Y','N') not null default 'Y', status_a tinyint(1) unsigned not null default '0', status_b tinyint(1) unsigned not null default '0', type tinyint(3) unsigned not null default '0', keyword_a varchar(10) not null, keyword_b varchar(15) not null, name varchar(30) not null, primary key (id) )type=myisam
一下子点击发送了上面的例子中， 如果应用上是主键做索引的操作，那么即使这个表有 1千万 的数据量，也没有问题。而如果你的查询条件是 name like ‘％xxx％’，那么几万条记录速度都会明显变慢。查询范围大了，没办法。呵呵在这方面，影响查询速度的主要是 索引文件大小（用索引的话）和查询搜索的记录集大小（记录数，占用空间大小）。 呵呵，先说到这里吧，最近累坏了，再加上上火了破相了好困睡觉先：P大家也要注意休息，注意锻炼啊。什么重要？ 身体最重要！^_^
更正一句话：上面的例子中， 如果应用上是主键做索引的操作，那么即使这个表有 1千万 的数据量，也没有问题 －－－－－－－－－应该是 上面的例子中， 如果应用上是主键做查询条件的操作，那么即使这个表有 1千万 的数据量，也没有问题 （如 select ... from tab_name where id>100 and id < 200;）
请问主键（如:newsid）需要添加为索引吗？
MYSQL还没有试过那么海量的操作……
tab_name(
id int(10) unsigned not null auto_increament,
flag enum('Y','N') not null default 'Y',
status_a tinyint(1) unsigned not null default '0',
status_b tinyint(1) unsigned not null default '0',
type tinyint(3) unsigned not null default '0',
keyword_a varchar(10) not null,
keyword_b varchar(15) not null,
name varchar(30) not null, primary key (id)
)type=myisam
呵呵，先说到这里吧，最近累坏了，再加上上火了破相了好困睡觉先：P大家也要注意休息，注意锻炼啊。什么重要？ 身体最重要！^_^
－－－－－－－－－应该是 上面的例子中， 如果应用上是主键做查询条件的操作，那么即使这个表有 1千万 的数据量，也没有问题 （如 select ... from tab_name where id>100 and id < 200;）
比如说只记录日志的表，150万条记录，而表的容量不是太大，基本还是很快的，所以mysql优化，主要结合实际情况～索引和分表是正道~
但哪些该分，哪些不该分。
当然，如果你能认真研读一下mysql的源码或许能找到“理论”根据
2、“我们的数据一天记录的量就700W条”这句话很值得商榷，暂且不去考虑他的真伪
如果这700W条数据是追加至一张表的话，假定每条记录只有10个字节。那么只要60天，你的数据表就已经达到4G的默认界限了。7,000,000*10*60=4,200,000,000
10个字节的信息能表示什么呢？
而这个4G的界限不是mysql规定的，而是操作系统规定的。
一个无符号长整型数只能表示4G 2^32-1=4,294,967,295
count(*)最快 :)因为数据库做了优化。具体差别可以查手册。
to pswdf(小邪)：
呵呵，索引和分表虽然好用，但是就怕乱用阿，呵呵，
适当的索引以及按列的分表是设计数据库表时必备的基本条件；至于按行的分表，个人觉得很大程度上取决于应用，一般的应用没有必要拆分表。
to xuzuning(唠叨) ：
呵呵，说句实在话，楼主的700W/天的数据量还是有可能的。：P 就拿我这里的应用来说，目前测试阶段每天的数据量大概是150-200W，平均每行200-300字节（算索引），要求能承受的极限值是每天2-3千万（当然，这也只是说说，不过从实际情况的分析来看1千万是必须的，预计实际情况中平均的数据量会在300-500W间）。呵呵，当然啦，这些数据都只是采集上来未处理的数据，每天存一个表就好，然后做数据挖掘用（好想学学，可惜没我份）。to 楼主：
楼主的应用还是很值得优化的，在应用上的优化很可能是效果最明显的。首先，选择表类型（myisam），字段类型（适当长度，not null）建表，适当创建索引（可以考虑多字段的索引），根据实际情况分表（楼主对这个表的查询应该不会很复杂吧？如果需要无法用主键做条件限制查询结果集的话，那么速度很可能受到影响的，很可能同一天的数据也需要分表或者这些数据需要加工后写入新的表然后再提供查询）；其次，
在应用的时候，这个表的数据最好不要真实删除，如果需要删除操作，最好采用标记位方式；
对于查询操作，尽量用主键限制查询范围（如 where id>val_a and id<val_b and .....）；
如果查询条件无法指定主键范围那么尽量使用整型的字段做索引；
查询条件中条件的排列顺序也有可能影响查询速度（因为sql只能用一个索引做查询条件的索引，所以用产生结果集最小的做为查询索引才是最有效的，可以用explain分析，有时需要强制指定索引）；
如果有关联字段，那么尽量保证相关数据的完整（也就是相关联的数据表尽量不要有真实删除的操作，从而在表关联时使用 join 而不是left join 之类）；
外键字段尽量使用整型而且尽可能的设置为tinyint，smallint；等等中午，吃饭啦。先说到这里。
http://www.bhc.com
有测试所以我觉得MySQL记录千万记录是没有问题，执行上还很可以的。
今天下午开了一下午会，结果客户要求我们做到流量40G/s的数据的采集和分析
混特40G每秒的数据普通的主干网好像都没这个流量
要求系统有对10T的数据的存储和分析查询的能力
^_^，胡说八道。大家当听个笑话了，哈阿
呵呵，这样看怎么用了，如果是日志，查看最新就行的话，当然没有问题。如果是让你 来个xxx like 'xxx%' 都得死～
如果是like '%xxx%' 那就等着挂吧，^_^
曾经看过一句话,好像说只有几个点的效率的提升算不上理论上的提升.
所以我感觉,你所说的技术,不一定就是将来要用的数据库技术.我想技术的提升应该还需要其他理论上突破才行.
那是要付出代价的，google查询速度那么快的代价是N台服务器
总有些人喜欢让mysql干它不擅长的事情你们知道mysql的定位吗？mysql是用来解决什么问题的？
把mysql当log，抓网页……不是想象力太丰富就是知识太匮乏
没必要吹捧哪个，大炮能炸死敌人，小枪也一样能杀敌。除非你变态到非要把敌人炸成肉酱，否则有必要那么浪费么。
很多人，一发现速度慢了，就说：阿，这个不好用了，不能满足需要了，要换，换最好的，拿台银河来，装上最好的数据库， 就能满足需要了。。
岂不知你的应用是多么垃圾，如果找找应用中的错误，很可能一台赛扬600，128内存的PC一样完成任务。
干嘛都推崇那些高端的东西。拿大炮打苍蝇很爽么？
中国目前还不富裕，大多数企业还在起步阶段，很多创业人没那么财大气粗。用点心，多学学，用你所掌握的技术来节省这笔浪费的投入，
程序员不是干吃饭，只懂得要求这个升级，那个更新的。用有限的资源解决一定范围内的问题才是正理~
就像mysql中的explain .学会去分析问题,才知道如何解决问题.这个说慢，那个说不慢的。我说 select * from tab_name limit 1;快，咋地？有用么？我说 select * from tab_name limit 300000;慢，有什么意义么？不要把小孩子带坏了。：P（玩笑）