C'è un incremento automatico sul database completo (non su ogni tabella!) In MySQL?

Question

Esiste un'opportunità di incremento automatico nativa non correlata al workaround per TUTTE le tabelle in mySQL? Voglio dire, non solo auto inc per tabella, intendo UN numero che conta per OGNI nuova riga nel database?

Ho visto questo su un oracle professionale (?) Istituito. Il vantaggio principale è che si ha un ID univoco per TUTTE le righe/elementi in TUTTE le tabelle, non solo PER TABELLA.

Answer 1

PostgreSQL può essere configurato in questo modo con un CREATE SEQUENCE seq_name e utilizzando nextval(seq_name) su ogni inserto.

MySQL non ha il supporto nativo per questo, è possibile simulare il comportamento di un SEQUENCE di PostgreSQL creando una tabella con una sola colonna e uno AUTO_INCREMENT su quella colonna.

Inserire sempre in quella tabella per prima cosa leggere lo LAST_INSERT_ID di quella tabella per ottenere l'ID che è necessario inserire nella tabella. Sarebbe sicuro per le transazioni, quindi non sarebbero mai generati duplicati.

Un altro modo per ottenere ciò è creare una tabella con una colonna n. AUTO_INCREMENT e una sola riga contenente il valore massimo corrente.

Ogni volta che è necessario incrementare si esegue UPDATE seq_table SET seq_column = seq_colum+1; un aggiornamento incrementale è di per sé atomico ma è necessario leggere anche il valore successivo che rende due dichiarazioni e non sono atomici insieme a meno che non si imposti una transazione intorno a loro e un isolamento appropriato livello. Questo approccio consente di risparmiare spazio, ma genera anche query di blocco.

Più thread che provano a INSERT dovranno attendere che altri aggiornino il seq_table prima di poter aggiornare autonomamente e leggere il nuovo valore.

anche che avrebbe dovuto avvolgere la UPDATE e il SELECT su seq_table in una transazione con un appropriato ISOLATION LEVEL per evitare di leggere il valore che qualche altro thread incrementato dopo aver incrementato esso.

Ciò significa che INSERTS diventa un problema di transazione ma normalmente non lo sono, quindi non consiglierei il secondo approccio.