关于表的主键及聚集索引建立问题
表结构如下：
ID 标识、自增为1
date 日期
name 名称
number 数量
大致内容如下：
ID date name number
1 2013-3-7 衣服 10
2 2013-3-7 裤子 5
3 2013-3-7 帽子 2
4 2013-3-8 衣服 3
5 2013-3-8 帽子 20
6 2013-3-8 袜子 50
*
*
特点
1、还有其他字段，比如店铺、规格、单位、单价、总价等。
2、每天都需要添加3000条记录，一直不停地往下添加。
3、品种（也就是name）是基本确定的，大概200个左右。
1、我的想法是ID为主键、自增为1
2、聚集索引建立在date上；因为查询时，日期肯定为第一要素。
3、店铺、品种为非聚集索引；因为要做比较细致的查询时，这两个字段是用频率比较高。
请问这样科学吗？
突然异想天开地想着设置ID+date为复合主键，date为聚集索引。
相比我自己的方案，哪个好一些？
分不多，请大神别介意，指点指点。
[解决办法]
一般讲像自增id这类的顺序、递增、选择性高的列适合聚集索引
但是你条件基本没用id查询，所以也就不要给它了
聚集索引倒是可以用date+名称，然后include(number)
如果你的name、店铺、等其他列也有单独查询的现象，可以单独或看情况添加复合索引
[解决办法]
Date+name聚集主键（如果唯一）
店铺非聚集
如果需要，根据选择字段设置include
[解决办法]
过早考虑优化，先把功能建立起来再说，不要低估SQL的处理能力，也不要高估索引的作用。
聚集：日期+名称+店铺
一点也不宽，除非字段定义得太离谱。如果规范化设计也就几个字节，个人认为应该规范化。
非聚集：名称+店铺+number 和 店铺+名称+number
统计用的，根据主要统计字段选一或全选。普通的select派不上用场，因为选择性太差。
[解决办法]
我倒觉得应该在设计的时候就考虑性能问题，当然前提是要先满足业务需求，不然其他都是白搭，对于索引，我个人觉得先要知道如何用这个表，才去考虑如何建索引，如果整表加载，那么没索引更快，如果是查询某些数据，那有索引往往更好，所以我一般是先等开发写好语句后再整体去衡量如何建索引
[解决办法]
