假设您有一张id,a,b,c,d,e,f,g
的表格,行数约为100万。然后,可以在多个组合中使用多个WHERE ...AND...AND...etc
条件进行查询。
例如,a AND b AND e
或a AND f AND g
或e AND f AND g
。
因此,考虑到所有组合,您必须创建多个复合索引,但如果a,b,c,d,e,f,g
的范围为[1,10],则不会为零。
可以简单地为每个起始变量生成一个单一的复合,以便a,b,c,d,e,f,g
和b,a,c,d,e,f,g
等。并且在查询期间执行类似
#b and e have not been chosen
SELECT * FROM WHERE a=3 AND b!=0 AND c=4 AND d=5 AND e!=0 AND f=1 AND g=9
#I think you get the logic
这样的程序是否允许mysql仍然使用复合索引,或者我是否真的需要创建所有可能的复合索引组合。
最终结果会将索引数减少到7而不是左组合数的数量,这可能高于7。
答案 0 :(得分:2)
如果可以,MySQL将按顺序使用复合索引。因此,如果您的数据代表某个分类,则单个索引就可以执行。假设客户既可以输入商业信息,也可以输入个人信息,并且可以使用特定的邮政编码,也可以是状态保费或常规信息,然后查询
SELECT * FROM customer
WHERE type = 'business'
AND postal_code = '12345'
AND status = 'premium';
可以使用基于type
+ postal_code
+ status
构建的复合键的索引。如果你不知道status
,索引仍然有用。但是,如果只知道postal_code
但不知道type
,则不会使用索引 - 订单很重要。
但我同意Strawberry的评论 - 这在标准关系模式中通常不是问题。在表中有几个外键并不罕见,但除非你正在构建数据立方体或其他一些特殊设计,否则这个问题不是你可能应该拥有的 - 当然不是7个字段。
但如果这是一个真正的问题,请考虑每个潜在索引字段的值。如果大多数查询能够使用多个索引(复合或非复合)将百万行缩小到几千行,则最终扫描可能是微不足道的。尝试使用EXPLAIN PLAN
来查看它在什么时候停止对大多数查询都很重要。
维护索引的成本可能微不足道......或者不是。在高度调整的事务系统中,单个插入,更新或删除将导致N + 1次写入:一行用于行,另一次用于每个索引。如果你主要是阅读,那么这可能没问题。如果没有,那么复合键的某些组合可能通过减少写入次数而获得一些好处。
但是我已经使用关系数据库超过几十年了。出现这种情况的情况几乎总是通过重新思考模式设计来解决;我不记得在典型的关系和规范化模式中复合键比多个索引更有意义的情况。