Om din DELETE är avsett att eliminera en stor majoritet av raderna i den tabellen, en sak som folk ofta gör är att kopiera bara de rader du vill behålla till en dubbletttabell och sedan använda DROP TABLE eller TRUNCATE för att radera den ursprungliga tabellen mycket snabbare.
Ett index kan hjälpa till att hitta de rader du behöver ta bort, men för att ta bort måste du uppdatera indexet. Efter att ha raderat många rader kan indexet vara obalanserat och kräver visst underhåll med OPTIMIZE TABLE .
DATE_SUB() funktion är ett konstant uttryck (den varierar inte rad för rad) så frågeoptimeraren bör vara smart nog att ta hänsyn till det och utföra beräkningen en gång.
Du behöver inte skapa ett extra index för en primärnyckel. Den primära nyckelbegränsningen skapar implicit ett index som ger samma fördel som ett icke-primärt nyckelindex.
Ett sammansatt index är förmodligen lika användbart som ett index med en kolumn, förutsatt att dina sökkriterier refererar till kolumn(erna) längst till vänster i indexet. Den "troligtvis" varningen beror på att de enskilda indexnoderna är större och det krävs därför mer minne för att cachelagra indexet, men detta är en tillräckligt liten faktor för att jag inte skulle skapa ett helt annat enkolumnsindex.