一个关于索引的疑问

[文盲老顾]

假设有一个表，字段大概在30到40个，记录数超过500万，其中没有varchar(max)、nvarchar(max)、text等不定长度的类型

该表中所有字段都可能参与条件筛选，那么就需要建立很多索引，而每建立一个索引当相关字段更新时，索引就需要同步更新，那么也就是说索引关联的字段越多，索引数量越多，那么更新操作越慢

好，我们换一个方式，我们对每一个字段都建立一个单独的索引，并包含主键，那么更新操作的压力就很低了，但问题来了

问题1：当我们每个字段都按照如上方法建立索引后，那么在插入、删除时，更新索引的压力有多大？

当我们使用索引时，指令会变形成这样

select pk from tb a inner join (select pk from tb where field1='value') b on a.pk=b.pk inner join (select pk from tb where field2 between 0 and 100) c on a.pk=c.pk

用这种方式来代替where各种条件时所需要的索引支持，那么又一个问题出现了

问题2：当我们以这样的方式使用单独索引进行查询时，对于不确定条件组合的情况下，整体效率是提高了还是降低了？

[吉普赛的歌]

问题1：当我们每个字段都按照如上方法建立索引后，那么在插入、删除时，更新索引的压力有多大？ --你先确定增删改是否频繁？ 问题2：当我们以这样的方式使用单独索引进行查询时，对于不确定条件组合的情况下，整体效率是提高了还是降低了？ --会有提高，但不显著。 sql语句就不要自己改了， sqlserver会调整执行计划的。 个人建议是先建立了单索引再说， 后面监控用户的查询， 对于较多的组合方式再另外加索引。

[日月路明]

脚本随便写，但是数据库会自己优化的，你费尽心力写的语句，数据库未必会按你的意图执行

[日月路明]

通常这种查询会有一个时间段的限制，以便降低数据量，这样一般不需要太多的索引