Mentre ci si avvicina al "rispettabile". ', 2 milioni di righe è ancora una dimensione relativamente piccola per una tabella. (E quindi è generalmente possibile una performance più veloce)
Come hai scoperto, i caratteri jolly front-end sono particolarmente inefficienti e dovremo trovare una soluzione per questo se quel caso d'uso è comune per la tua applicazione.
Potrebbe semplicemente non avere il set di indici corretto . Prima di procedere, tuttavia, desidero sottolineare che mentre gli indici in genere migliorano le prestazioni del DBMS con le istruzioni SELECT di tutti i tipi, hanno sistematicamente un effetto negativo sulle prestazioni delle operazioni "CUD" (cioè con SQL CREATE/INSERT, UPDATE , DELETE verbi, cioè le query che scrivono al database anziché solo leggere ad esso). In alcuni casi l'impatto negativo degli indici sulle query di "scrittura" può essere molto significativo.
La mia ragione per sottolineare in particolare la natura ambivalente degli indici è che sembra che la tua applicazione esegua una discreta quantità di raccolta di dati come parte normale del suo funzionamento e dovrai prestare attenzione a un possibile degrado man mano che le query INSERT vengono rallentate . Una possibile alternativa è eseguire la raccolta dei dati in una tabella/database relativamente piccola, senza o con pochissimi indici, e importare regolarmente i dati da questo database di input a un database in cui avviene il data mining effettivo. (Dopo che sono state importate, le righe possono essere cancellate dal "database di input", mantenendolo piccolo e veloce per la sua funzione INSERT.)
Un'altra preoccupazione/domanda riguarda la larghezza di una riga nella tabella cast (il numero di colonne e la somma delle larghezze di queste colonne). Le cattive prestazioni potrebbero essere legate al fatto che le righe sono troppo larghe, determinando un numero troppo basso di righe nei nodi foglia della tabella e quindi una struttura ad albero più profonda del necessario.
Tornando agli indici...
in considerazione delle poche query nella domanda, sembra che potresti trarre vantaggio da un indice ip + note (un indice realizzato almeno con queste due chiavi in questo ordine). Un'analisi completa della situazione dell'indice e, francamente, una possibile revisione dello schema del database non può essere eseguita qui (informazioni insufficienti per uno...) ma il processo generale per farlo è fare l'elenco dei casi d'uso più comuni e per vedere quali indici di database potrebbero essere utili in questi casi. È possibile ottenere informazioni su come vengono gestite determinate query, inizialmente o dopo l'aggiunta di uno o più indici, con il comando MySQL EXPLAIN.
La normalizzazione O la demormalizzazione (o addirittura una combinazione di entrambi!), è spesso un'idea praticabile per migliorare le prestazioni anche durante le operazioni di mining.
