Answers:
我应该从头开始还是在出现性能问题时立即开始索引编制？
随着使用模式的出现，索引策略趋向于发展。也就是说，还有一些策略和设计准则可以预先应用。
选择一个好的群集密钥。通常，您可以在设计时根据对表的插入的预期模式来确定适当的聚簇索引。如果有令人信服的理由要求将来做出改变，那就这样吧。
创建您的主要约束和其他独特约束。这些将由唯一索引强制执行。
创建您的外键和关联的非聚集索引。外键是您最常引用的联接列，因此从一开始就对其进行索引。
为任何显然高度选择性的查询创建索引。对于查询模式，您已经知道它将具有很高的选择性，并且很可能使用查找而不是扫描。
除上述之外，请采用渐进的整体方法来实施新索引。整体而言，我的意思是在评估添加项时评估对所有查询和现有索引的潜在收益和影响。
由于缺少索引DMV和SSMS提示的指导，SQL Server圈中的一个常见问题是过度索引。这些工具都不会对现有索引进行评估，并且会建议您创建一个新的6列索引，而不是向现有的5列索引添加单个列。
-- If you have this
CREATE NONCLUSTERED INDEX [IX_MyTable_MyIndex] ON [dbo].[MyTable]
(
[col1] ASC
, [col2] ASC
, [col3] ASC
, [col4] ASC
, [col5] ASC
)
-- But your query would benefit from the addition of a column
CREATE NONCLUSTERED INDEX [IX_MyTable_MyIndex] ON [dbo].[MyTable]
(
[col1] ASC
, [col2] ASC
, [col3] ASC
, [col4] ASC
, [col5] ASC
, [col6] ASC
)
-- SSMS will suggest you create this instead
CREATE NONCLUSTERED INDEX [IX_MyTable_AnotherIndexWithTheSameColumnsAsTheExistingIndexPlusCol6] ON [dbo].[MyTable]
(
[col1] ASC
, [col2] ASC
, [col3] ASC
, [col4] ASC
, [col5] ASC
, [col6] ASC
)金伯利·特里普（Kimberly Tripp）拥有一些出色的索引策略材料，而SQL侧重于索引策略也适用于其他平台。对于SQL Server专家来说，有一些方便的工具可用于识别重复项，例如上面的示例。
我们还可以在执行查询时创建临时索引。这种技术的优缺点是什么？
这通常仅适用于很少运行的查询，通常是ETL。您需要评估：
这两种方法确实存在风险：
选项a）从一开始就建立索引，但没有意识到您已经创建了许多从未使用过的索引。这些增加了一些开销（最显着的是修改数据的查询，但同时还通过优化SELECT语句来尝试确定最佳索引）。
您将需要训练自己以识别不再使用的索引并尝试将其删除（PostgreSQL可以做到这一点；不幸的是，相比之下，MySQL的功能非常弱。）
选项b）在人们开始抱怨之前，否则不要添加索引，否则您的诊断工具会触发某些查询速度很慢并且可以改进的查询。
引入的风险是，从发现需要索引到必须添加索引之间的时间窗口不够长。
PostgreSQL确实支持构建索引CONCURRENTLY，这确实减轻了这种突然添加索引的压力，但是手册中有一些注意事项。
选项（b）通常是我的偏爱，但我认为将这两种选项混合使用可能是最好的解决方案。这与您是否认为实际使用索引有关的置信度有关。
使得该讨论特别复杂的是，更改索引通常很容易，但是更改架构则更困难。我不想提倡b 的延迟反应是鲁re的借口。
只是添加一些东西。
这是我的方法。
不要害怕在未使用的列中放置> 0或放置> ""在where子句中。
select * from blah
where A="one"
and B="two"
and C>="" --to match index
and D="four"
--This will use your existing index. No need to create a redundant one.