貌似么什么新贴子了，我发个，请进

[geniuswjt]

我弱弱的问一句
建立组合索引时，按道理高选择性列放最左边，这个应该没问题额？
那么一般时间列不是肯定选择性最高么？比如取某个时间段的数据这种很平常，那么貌似时间列99%都是放在组合索引最左边？不知道这个理论有问题么？

举个例子，有个表tb，有几个字段id,daytime,user,password,content,status（意思比如分别为自增流水号，时间，用户名，密码，提交的内容，状态）
那么id作为主键，然后我还想建个组合索引，方式：idx_daytime_user_status？这样有什么弊端么？或者有什么更好的意见么？因为按照查询方式来说，时间最常用，用户名次之，状态再次之？
还有，有必要加上content么？方便有时用like ...%？

码了不少字，辛苦看一下。

[geniuswjt]

索引多了增删改都耗时啊，比如数据量大到千万级，维护起来就难受了吧？[Quote=引用 8 楼 lxpbs8851 的回复:]
嗯 3个。
[/Quote]

[chuanzhang5687]

围观！

[NBDBA]

[Quote=引用 5 楼 geniuswjt 的回复:]
不是啊，查一个月的你说就都是重复了？难道你用datediff(month,daytime,getdate())=0这种？
这种左边用公式的是走不了索引的啊！
肯定是比如查8月你用daytime between '2011-8-1' and '2011-9-1'或者 daytime>='2011-8-1' and daytime<'2011-9-1'
[/Quote]
这种如果daytime有索引，而且范围内数据占的比例不大，就会出现一个范围索引查找，速度还是很快的
但是如果范围内数据占的比例较大，就可能不选择索引，改用聚集索引扫描或者表扫描，速度就很慢了

如果还有个 and user='张三'，这时如果有user索引，就必然选择user索引，进行一个精确的索引查找，不管你的时间范围如何了
反之，如果没有这个索引，那速度就没保证了

[NBDBA]

(id,status) 3
没必要，已经有id主键

[geniuswjt]

船长请发言！你不发言让你图片里的妹子发言也可~[Quote=引用 10 楼 chuanzhang5687 的回复:]
围观！
[/Quote]

[oO寒枫Oo]

[Quote=引用 9 楼 geniuswjt 的回复:]

索引多了增删改都耗时啊，比如数据量大到千万级，维护起来就难受了吧？引用 8 楼 lxpbs8851 的回复:
嗯 3个。
[/Quote]
我觉得还行 看具体的查询需求了。要是查询需求很多的话 见过6，7个索引的大表。
千万级的表不算太大 增删改操作太多的话 索引是需要经常维护的 比如统计更新等 必要的时候也可以进行索引的定期重建。

[geniuswjt]

idx_daytime_user_status这个里面不也有user列的索引么？and user='张三'的话再加上时间范围也可以走这个索引的哇？
为什么一定要分2个user,status
daytime,status
索引呢？索引越多不是insert,delete都越来越痛苦么[Quote=引用 11 楼 nbdba 的回复:]
引用 5 楼 geniuswjt 的回复:
不是啊，查一个月的你说就都是重复了？难道你用datediff(month,daytime,getdate())=0这种？
这种左边用公式的是走不了索引的啊！
肯定是比如查8月你用daytime between '2011-8-1' and '2011-9-1'或者 daytime>='2011-8-1' and daytime<'2011-9-1'……
[/Quote]

[geniuswjt]

嗯，我的意思就是idx_daytime_user_status包含了所有可能
为什么一定要分多个索引呢？[Quote=引用 14 楼 lxpbs8851 的回复:]
引用 9 楼 geniuswjt 的回复:

索引多了增删改都耗时啊，比如数据量大到千万级，维护起来就难受了吧？引用 8 楼 lxpbs8851 的回复:
嗯 3个。

我觉得还行 看具体的查询需求了。要是查询需求很多的话 见过6，7个索引的大表。
千万级的表不算太大 增删改操作太多的话 索引是需要经常维护的 比如统计更新等 必要的时候也可以进行索引的定期重建。
[/Quote]

[NBDBA]

[Quote=引用 15 楼 geniuswjt 的回复:]
idx_daytime_user_status这个里面不也有user列的索引么？and user='张三'的话再加上时间范围也可以走这个索引的哇？
为什么一定要分2个user,status
daytime,status
索引呢？索引越多不是insert,delete都越来越痛苦么

引用 11 楼 nbdba 的回复:
引用 5 楼 geniuswjt 的回复:
不是啊，查一个月的你……
[/Quote]

是可以走，但是先判断时间了，范围索引查找，或者用不了索引
如果有User开头的索引，是必然选中并作精确的索引查找
你可以找数据测试下的

[oO寒枫Oo]

[Quote=引用 12 楼 nbdba 的回复:]

(id,status) 3
没必要，已经有id主键
[/Quote]
多列索引 最重要还是看第一列的
类似于 order by id,status 为主的还是id
单独为status建立一个索引显然是不明智的 。
（id asc, status）

[chtzhking]

围观，学习，都是牛人啊。提高一下

[oO寒枫Oo]

[Quote=引用 16 楼 geniuswjt 的回复:]

嗯，我的意思就是idx_daytime_user_status包含了所有可能
为什么一定要分多个索引呢？引用 14 楼 lxpbs8851 的回复:
引用 9 楼 geniuswjt 的回复:

索引多了增删改都耗时啊，比如数据量大到千万级，维护起来就难受了吧？引用 8 楼 lxpbs8851 的回复:
嗯 3个。

我觉得还行 看具体的查询需求了。要是查询需求很多的话 见过6，7……
[/Quote]
包含了所有可能的话 要是你的查询仅仅只有 user这个条件的话
也不会去走索引

[oO寒枫Oo]

也不能这么肯定 但是查询的速度肯定不是你想要的
但是这个索引
你的查询条件里面有主列 即 daytime 这个条件 情况会好很多
然后 查询的时候 where 各个条件之间的顺序也是有讲究的
越强力筛选的条件越往后面靠

[geniuswjt]

其实我对select中的列，where中的列，order by中的列能走索引的区别还满晕的
求指导

[oO寒枫Oo]

select中的列和索引没有关系的
where 中的才有

order by的时候 列的顺序最好和索引中列的顺序一致

[geniuswjt]

order by和where中的哪个索引优先走？[Quote=引用 23 楼 lxpbs8851 的回复:]
select中的列和索引没有关系的
where 中的才有

order by的时候 列的顺序最好和索引中列的顺序一致
[/Quote]

[oO寒枫Oo]

[Quote=引用 24 楼 geniuswjt 的回复:]

order by和where中的哪个索引优先走？引用 23 楼 lxpbs8851 的回复:
select中的列和索引没有关系的
where 中的才有

order by的时候 列的顺序最好和索引中列的顺序一致
[/Quote]
问题不是这么问的
where中的条件走索引是为了更加快速的查询出结果集 没有where的话指定是全表扫描 那速度不言而喻；
order by只是为了让查出的结果集有个排列顺序 没有order by 查询更舒服 一定要用order by 那最好是按照索引列的顺序来排序 这样会提高order by 的效率 不按照索引顺序来排序效率只不过低一点。

[gogodiy]

http://www.xker.com/page/e2010/0601/96570.html
看看这个能否帮助你

[yuanwza]

学习.......

[geniuswjt]

虽然没讨论出啥，不过还是谢谢lxpbs8851和nbdba
结贴