一个表aamsg，自增字段ID是主键；PhoneNum字段；RecvTime字段；还有其他一些字段，大约20个。 aamsg目前的记录数大约是130万条，对该表的insert操作比较常见，差不多每1个小时要插入将近1000条，插入操作是自动的（接收到短信就插入）。 查询操作不太常见，主要有两个，简化如下：
A. select id from aamsg where phonenum='%s' limit 1，300（前300条）
B. select id from aamsg where phonenum='%s' and (recvtime between '%s' and '%s') limit 1，300（前300条） 查询操作不太常用，平均一天也就10几次，但由于是用户点击，需要等待返回结果的，为了不让用户等太久，我就增加了两个索引：PhoneNum和RecvTime，这样查询的时候能快些了。
但问题来了，虽然查询快些了，但插入时就慢了，由于查询B不如查询A常用，后来就把RecvTime这个索引去掉了，只保留主键ID和PhoneNum这两个索引。 现在我觉得有问题的地方是，130万条记录里面，PhoneNum大约只有300个，并且每次只查询300条，因此我感觉对phoneNum做索引也意义不大，现在的情况是，查询A、B确实快了一些，但一次收到多条短信时（约四五十条），数据库对phoneNum建索引的耗时还是不可忽略不计的。 说说看，这种情况下是否有必要对phoneNum建索引？ 由于工作机器不好测试，暂时想不出好的办法，就只好发文请教了。
建一个表
bbmsg,结构可以和 aamsg 一样,不用索引
这个表可以用来短信插入记录.然后建一个触发器, bbmsg 满 1000 条就把记录全部导入 aamsg 中,成功后清空 bbmsg 表.
这样的话,大概 1 个小时,aamsg 才插入一次数据,有索引都不怕.由于查询比较简单,可以 union 两个表来查询.
本周的放在table_week (不含当天)
其余的在table_year[align=center]==== 思想重于技巧 ====
[/align]
然后看结果的Cardinality列值。如果太小的话没有必要，就单独分表出来吧。很大。那就非常有必要。