Uno dovrebbe evitare di aggiungere ancora un altro campo a una tabella MySQL più grande?

Question

Ho una tabella MySQL-InnoDB con oltre 350.000 righe, contenente un paio di cose come id, otherId, shortTitle e così via. Ora ho bisogno di un campo Bool / Bit per forse un paio di centinaia o migliaia di quelle righe. Devo solo aggiungere quel campo bool nella tabella o dovrei creare una nuova tabella che faccia riferimento agli ID della vecchia tabella, senza quindi rischiare di causare problemi di prestazioni su tutte le vecchie funzioni esistenti che accedono alla prima tabella?

(Informazioni a margine: non sto mai usando " SELECT * ... " ;. La tabella principale contiene molte letture, raramente scrivendo.)

Answer 1

L'aggiunta di un campo può effettivamente ostacolare un po 'le prestazioni, poiché la riga della tabella aumenta, ma non è certo un problema per un campo BIT .

Molto probabilmente, avrai esattamente lo stesso numero di righe per pagina, il che significa che non avrai alcuna riduzione delle prestazioni.

D'altra parte, l'utilizzo di un JOIN aggiuntivo per accedere al valore della riga in un'altra tabella sarà molto più lento.

Aggiungerei la colonna direttamente nella tabella.

Answer 2

Cosa indica la nuova colonna?

Dal punto di vista della modellazione dei dati, se la colonna appartiene ai dati in qualunque forma sia in uso, quindi inserirli con i dati; impatto sulle prestazioni essere dannato. Se la colonna non appartiene direttamente alla tabella, inseriscila in una seconda tabella con una chiave esterna.

Realisticamente, l'impatto sulle prestazioni dell'aggiunta di una nuova colonna su una tabella con ~ 350.000 non sarà particolarmente grande. Hai provato a rilasciare l'istruzione ALTER TABLE su una copia, magari su una workstation locale?

Answer 3

Non so perché la gente insista nel chiamare grandi tavoli da 350K righe. Nel mondo dei mainframe, ecco quanto sono grandi le tabelle di configurazione del DBMS :-).

Detto questo, dovresti progettare le tue tabelle in terza forma normale. Se, e solo se, hai problemi di prestazioni, dovresti prendere in considerazione la de-normalizzazione.

Se hai una colonna che si applicherà solo ad alcune delle righe, (probabilmente) non sarà 3NF per metterlo nella stessa tabella. Dovresti avere una tabella separata con una chiave esterna nella tua tabella "primaria".

Tieni presente che se il campo booleano in realtà non si applica ad alcune righe. Questa è una situazione diversa rispetto al campo che si applica a tutte le righe ma non è noto per alcuni. In tal caso, sarebbe meglio una colonna nullable nella tabella principale. Ma questo non suona come quello che stai descrivendo.

Answer 4

Richiede un campo bit per le voci successive solo sembra che tu voglia implementare l'ereditarietà. In tal caso, lo aggiungerei a una nuova tabella per mantenere le cose leggibili. Altrimenti, non importa se lo aggiungi o meno alla tabella principale, a meno che le tue query non utilizzino gli indici, nel qual caso lo cambierei prima di prendere qualsiasi altra decisione relativa alle prestazioni.