Also mir persönlich ist jetzt keine Datenbank bekannt, die Indexe kombinieren könnte. Ich habe allerdings auch nur Erfahrungen mit Microsofts
SQL Server, Oracle, DB2 und
MySQL* bzw. MariaDB*.
Bei denen bin ich mir sicher, dass sie bei der Ermittlung des Ausführungsplans prüfen, welcher der Indexe am besten passt, und diesen dann verwenden (und nein, der sogenannte "index_merge" den MariaDB /
MySQL manchmal versucht zählt nicht, der ist eher theoretischer Natur und greift im echten Leben fast nie).
Grundsätzlich sollte man sich also anschauen:
Nach welchen Spalten wird in aller Regel gemeinsam gefiltert? Diese sollten gemeinsam in einen Index. Es sollte dabei darauf geachtet werden, lieber einen Index mehr zu machen (also z.B. einen Index auf A, B und D und einen auf A, B, D und E), als eine Spalte zu viel in den Index aufzunehmen (z.B. nur einen Index auf A, B, D und E, wenn oft nur auf A, B, D abgefragt würde).
Dabei sollte man dann allerdings die Spalten, die in aller Regel mit selektiert (aber nicht gefiltert) werden in den Index als non-key Spalten mit zu includen (sofern die
DB das kann).
Hintergrund: Selbst wenn ein Index dazu führt, dass die betroffenen Spalten schnell identifiziert werden können: Ohne die included columns muss die Datenbank dann trotzdem wieder table seeks machen um die eigentlichen Daten lesen und ausliefern zu können. Wenn die Spalten aber schon als non-key im Index enthalten sind, kann sich die Datenbank den lookup sparen denn die Daten sind beim index schon gelesen und ist dann deutlichst schneller beim beantworten der queries. Hier z.B. Info dazu für den
SQL Server:
https://msdn.microsoft.com/en-us/library/ms190806.aspx