我想知道在以下情况下一起定义两种类型的索引有什么害处。
表Tasks：
TaskID (Primary, Auto Number)
OwnerID (Single Column Index)
AssignedToID (Single Column Index)
DateUpdated (Single Column Index)
TaskStatus (Single Column Index)
Mutli Column Index (AssignedToID, DateUpdated)
有以下主要查询... to的查询DateUpdated是可选的。
访问单列索引DateUpdated
WHERE
DateUpdated <= startDate
AND DateUpdated <= endDate
ORDER BY
DateUpdated DESC
访问单列索引DateUpdated
WHERE
TaskStatus = 'Active'
ORDER BY
DateUpdated DESC
用户可以过滤仅分配给他们的任务
访问多列索引
WHERE
DateUpdated <= startDate
AND DateUpdated <= endDate
AND AssignedToID = userID
ORDER BY
DateUpdated DESC
访问多列索引
WHERE
AssignedToID = userID
AND TaskStatus = 'Active'
ORDER BY
DateUpdated DESC
DateUpdated 在任何标准中均未引用
TaskID访问单列索引
WHERE
AssignedToID = userID
AND TaskStatus = 'Active'
ORDER BY
TaskID DESC
看起来我可以通过在某些常见查询中定义多列索引来提高性能，但我有以下问题。
我的数据库操作是95％的读取和5％的写入，因此我不太担心索引写入性能问题，但是我的读取性能是最重要的。
定义组合索引和多个索引是否有害？
我宁愿称其为维护开销，而不是伤害：
-对于每个新索引，此表上的INSERT / UPDATE / DELETE会慢一些。
-索引占用一些磁盘空间。
如果查询包含每一列的谓词，而不管查询中列的顺序如何，SQL是否会优先考虑合并索引而不是单索引合并？
查询中列的顺序无关紧要。
索引中列的顺序很重要。
所以：
在指数（AssignedToID，DateUpdated）可用于寻找，而不是在（指数AssignedToID），但
在指数（DateUpdated，AssignedToID）不能用于寻求替代指数的（AssignedToID）。
查询优化器将根据估计的成本选择要使用的索引，并根据统计信息（表/索引中有多少行以及值的分布方式）计算出该索引。
它可能决定根本不使用索引-如果行数少并且扫描整个表便宜，或者索引不够选择性。
如果查询包含onAssignedToID和DateUpdated-上的谓词AssignedToID，DateUpdated则查询优化器比（AssignedToID）上的索引更可能使用（）上的索引。
但是，它取决于查询的所有其他元素以及数据库中的实际数据。
如果您有关于两个索引都可能有害的示例，那么我想学习为什么和如何做，以便我可以相应地设计索引。
当数据库或/和请求的数量显着增长时，开销可能变得很明显。
根据您的主要查询，看起来非聚集索引应该是：
DateUpdated）AssignedToID，DateUpdated）可能是：
TaskStatus）-但是，如果说有90％的任务是'Active'您只查询'Active'-那就没有用了。并不需要：
AssignedToID）-因为（AssignedToID，DateUpdated）索引就足够了。之后，您可以在测试数据库上验证假设，并且数据与生产足够接近。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句