En se dirigeant vers 'respectable ', 2 millions de lignes est encore une taille relativement petite pour une table. (Et donc une performance plus rapide est généralement possible)
Comme vous l'avez découvert, les caractères génériques frontaux sont particulièrement inefficaces et nous devrons trouver une solution à cela si ce cas d'utilisation est courant pour votre application.
Il se peut simplement que vous n'ayez pas le bon ensemble d'index . Avant de poursuivre, cependant, je tiens à souligner que si les index améliorent généralement les performances du SGBD avec des instructions SELECT de toutes sortes, ils ont systématiquement un effet négatif sur les performances des opérations "CUD" (c'est-à-dire avec SQL CREATE/INSERT, UPDATE , les verbes DELETE, c'est-à-dire les requêtes qui écrivent à la base de données plutôt que de simplement lire à elle). Dans certains cas, l'impact négatif des index sur les requêtes "en écriture" peut être très important.
La raison pour laquelle j'insiste particulièrement sur la nature ambivalente des index est qu'il semble que votre application effectue une bonne quantité de collecte de données dans le cadre normal de son fonctionnement, et vous devrez surveiller une éventuelle dégradation lorsque les requêtes INSERTs seront ralenties. . Une alternative possible consiste à effectuer la collecte de données dans une table/base de données relativement petite, avec peu ou pas d'index, et d'importer régulièrement les données de cette base de données d'entrée vers une base de données où l'exploration de données proprement dite a lieu. (Après leur importation, les lignes peuvent être supprimées de la "base de données d'entrée", en la gardant petite et rapide pour sa fonction INSERT.)
Une autre préoccupation/question concerne la largeur d'une ligne dans la table de distribution (le nombre de colonnes et la somme des largeurs de ces colonnes). Les mauvaises performances peuvent être liées au fait que les lignes sont trop larges, ce qui entraîne trop peu de lignes dans les nœuds feuilles de la table, et donc une structure arborescente plus profonde que nécessaire.
Revenons aux index...
au vu du peu de requêtes dans la question, il apparaît que vous pourriez bénéficier d'un index ip + note (un index fait au moins avec ces deux clés dans cet ordre). Une analyse complète de la situation de l'index, et franchement une éventuelle révision du schéma de la base de données ne peuvent pas être faites ici (pas assez d'informations pour un ...) mais le processus général pour le faire est de faire la liste des cas d'utilisation les plus courants et pour voir quels index de base de données pourraient aider dans ces cas. On peut recueillir des informations sur la façon dont des requêtes particulières sont traitées, initialement ou après l'ajout d'index, avec la commande mySQL EXPLAIN.
La normalisation OU la démormalisation (ou même une combinaison des deux !) est souvent une idée viable pour améliorer également les performances lors des opérations minières.
