Sì.Originariamente inviato da franzauker
no
Oppure spieghi perchè "no"
Sì.Originariamente inviato da franzauker
no
Oppure spieghi perchè "no"
X franzauker beh per quell'applicazione il carico di lavoro/accesso non e' molto elevato.
Cosa che non succede al database che deve gestire piu' di 2kk di query giornaliere.
Alla fine mettetela come volete per pigliare l'id si deve sempre fare 1 ulteriore query, che sia fatta a mano , che sia tramite la funz php last_insert_id .... o come diavolo si chiama a sto punto una soluzione vale l'altra.
Ripeto ormai il problema e' risolto e l'applicazione e' conclusa e funzionante e non noto deficit prestazionali nemmeno con grossi carichi di lavoro sul db ne per le query dell'applicazione in causa o delle altre applicazioni che lavorano su quel db.
.... inoltre pure io sono curioso di sapere la motivazione di quel "no"
Attendo rips
c'è un assunto del tutto sbagliato, ossia che sia possibile sapere quale sia il prossimo ser leggendo da disco.Originariamente inviato da Virus_101
X franzauker beh per quell'applicazione il carico di lavoro/accesso non e' molto elevato.
Cosa che non succede al database che deve gestire piu' di 2kk di query giornaliere.
Alla fine mettetela come volete per pigliare l'id si deve sempre fare 1 ulteriore query, che sia fatta a mano , che sia tramite la funz php last_insert_id .... o come diavolo si chiama a sto punto una soluzione vale l'altra.
Ripeto ormai il problema e' risolto e l'applicazione e' conclusa e funzionante e non noto deficit prestazionali nemmeno con grossi carichi di lavoro sul db ne per le query dell'applicazione in causa o delle altre applicazioni che lavorano su quel db.
.... inoltre pure io sono curioso di sapere la motivazione di quel "no"
Attendo rips
Perchè (con innodb) molto semplicemente il ser sta in memoria, non su disco.
La strategia utilizza un lock speciale (a livello di istruzione SQL), che altro non è (alla fin fine) che un bel mutex (sia pure in memoria).
Non esistono "pallottole magiche", non è altro che una sezione critica.
Se il db è "serio" (per me "serio" significa una media di 500 query al secondo 24h) per inciso, può diventare un vero e proprio collo di bottiglia.
Se poi il db non è in autocommit, ovvero hai transazioni (ossia generalmente un'applicazione non banale), LAST_INSERT_ID() può diventare non definito a causa di errori nella transazione stessa
E, sempre così per dare qualche info, LAST_INSERT_ID è riferito al client (anzi meglio alla connessione).
Non ribadisco il perchè è sbagliato concettualmente utilizzarlo come chiave, se altre chiavi esistono, l'ho già spiegato seppur succintamente.
Anche se bisogna ricordare che le INSERT di innodb sono ordinate per chiave primaria, e quindi bisogna studiare bene il costo di una chiave "sparsa" come impatto nell'accesso delle pagine.
Soprattutto se l'indice è così grande da non stare in memoria, ovviamente.
Ovvero "mi va bene usare la chiave X, se so esattamente che pregi e difetti mi darà usarla". In certi casi è bene, in altri male.
Sottacendo poi il rischio di rebuild degli indici a causa del cambiamento del campo SER, e con le sue "particolarità" (se lo incrementi -> mysql non ti fa fare il rebuild dell'indice, neppure se cerchi di forzarlo).
In certi casi il rebuild può portar via anche 24 ore o più, mettendo in ginocchio un server in produzione.
E ricordando infine che la strategia di gestione è cambiata dalla versione 5.1.22 in poi, con la possibilità di avere sequenze "mischiate" tra più connessioni (settando innodb_autoinc_lock_mode)
---
In estrema sintesi: i campi SER vanno benissimo, se si conoscono con esattezza pregi, difetti e funzionamento.
Vanno un po' meno bene se ci si affida alla "speremmoendios", o si ha un db "serio" (=non fittabile in RAM); diciamo che è un argomento assai delicato (altri DB addirittura non hanno del tutto i campi SER, proprio perchè tutt'altro che banali).
Con mini-db funziona tutto, perfino i file CSV letti una riga alla volta.
---
Poi ognuno faccia come vuole, io sono principalmente un esperto di gatti, ne capisco poco di queste cose, magari mi sbaglio
franzauker ma 500 query al secondo 24h un utente normale (di questo forum) non le vedrà mai e non le dovrà gestire mai.
Trattare qui gli aspetti tipici degli ambienti enterprise ( o quasi) è totalmente fuori luogo. concorrenze, transazioni eccetera non rientrano, dalla mia piccola esperienza, nel 99% dei casi trattati su questo forum, almeno non ai livelli che stai imaginando tu.
Comunque sia, tornando in topic, non si parlava specificatamente di innodb, quindi nuovamente, cosa c'è di sbagliato nella query che ho proposto per lo scopo richiesto, dato che proprio la definizione del DB information_schema dice
"INFORMATION_SCHEMA is the information database, the place that stores information about all the other databases that the MySQL server maintains."
Questa era la domanda
Non sapevo che in questo forum ci si dovesse limitare ai db "csv-like".Originariamente inviato da Dascos
franzauker ma 500 query al secondo 24h un utente normale (di questo forum) non le vedrà mai e non le dovrà gestire mai.
Trattare qui gli aspetti tipici degli ambienti enterprise ( o quasi) è totalmente fuori luogo. concorrenze, transazioni eccetera non rientrano, dalla mia piccola esperienza, nel 99% dei casi trattati su questo forum, almeno non ai livelli che stai imaginando tu.
Adesso lo so.
La risposta l'ho già scritta.Comunque sia, tornando in topic, non si parlava specificatamente di innodb, quindi nuovamente, cosa c'è di sbagliato nella query che ho proposto per lo scopo richiesto, dato che proprio la definizione del DB information_schema dice
"INFORMATION_SCHEMA is the information database, the place that stores information about all the other databases that the MySQL server maintains."
Questa era la domanda
Ti segnalo che puoi avere una stima direttamente con SHOW TABLE STATUS.
Se desideri approfondire leggiti la documentazione di mysql, o meglio ancora il relativo sorgente.
O, più semplicemente, fai come vuoi, come detto non sono molto esperto.
Mai detto che si deve limitarsi a csv-like, è che se un utente chiede "come faccio a recuperare l'ultimo id inserito da una insert mutipla" andare a spiegare logiche ed ottimizzazioni tipiche di un ambiente enterprise non ha senso.Originariamente inviato da franzauker
Non sapevo che in questo forum ci si dovesse limitare ai db "csv-like".
Adesso lo so.
La risposta l'ho già scritta.
Ti segnalo che puoi avere una stima direttamente con SHOW TABLE STATUS.
Se desideri approfondire leggiti la documentazione di mysql, o meglio ancora il relativo sorgente.
O, più semplicemente, fai come vuoi, come detto non sono molto esperto.
Show table status ti da le stesse informazioni che ci sono nelle varie viste che sono presenti nella "schemata"...guarda caso
1) myisam non lo considero ormai più di tanto. anche mysql non lo considera, visto che addirittura l'engine di default è (5.5) innodbOriginariamente inviato da Dascos
Mai detto che si deve limitarsi a csv-like, è che se un utente chiede "come faccio a recuperare l'ultimo id inserito da una insert mutipla" andare a spiegare logiche ed ottimizzazioni tipiche di un ambiente enterprise non ha senso.
Show table status ti da le stesse informazioni che ci sono nelle varie viste che sono presenti nella "schemata"...guarda caso
2) This counter is stored only in main memory, not on disk.
3) Riguardo agli inserimenti multipli (seconda parte della domanda) con la tecnica "conto gli insert ed aumento il valore tornato" ho già segnalato che dalla versione 5.1.22 ciò non è sempre corretto.
Ossia può esserlo, oppure no (=> il che significa "mai", se hai un db in produzione e non un csv-db)
Dipende da innodb_autoinc_lock_mode, che se è settato su 2 (così andiamo nello specifico)
In this lock mode, auto-increment values are guaranteed to be unique and monotonically increasing across all concurrently executing “INSERT-like” statements. However, because multiple statements can be generating numbers at the same time (that is, allocation of numbers is interleaved across statements), the values generated for the rows inserted by any given statement may not be consecutive.
If the only statements executing are “simple inserts” where the number of rows to be inserted is known ahead of time, there will be no gaps in the numbers generated for a single statement, except for “mixed-mode inserts.” However, when “bulk inserts” are executed, there may be gaps in the auto-increment values assigned by any given statement.
Adesso mi dirai che nessuno altera le variabili di mysql, o meglio ancora che c'è una singola connessione alla volta al db (così non c'è alcun problema).
E ti darò ragione
Affatto, ti dico solo che la tabella delle schemate non esiste, ed ecco perchè fare la query sulla tabella TABLE della schemata è corretto (tralasciando, come detto, tutte le questioni su concorrenzialità "spinte" e motori scelti che come visto nel 99% dei casi su questo forum hanno incidenza zero)
Edit: prima della 5.5.5, per la precisione
non sono d'accordo, ma va bene lo stesso, come già scritto me lo aspettavo.Originariamente inviato da Dascos
come detto, tutte le questioni su concorrenzialità "spinte" e motori scelti che come visto nel 99% dei casi su questo forum hanno incidenza zero
Ripetere un milione di volte l'alfabeto non trasforma in poeti: se in un forum (o nella "vita reale") ci si occupa solo del livello "file-csv" non è che si cresca professionalmente.
Si rimane all'ABC
Indubbio, ma se quello che viene chiesto è di "livello medio", perchè fare i "so tutto io" con argomenti che sono fuori contesto e non c'entrano nulla?Originariamente inviato da franzauker
se ci si occupa solo del livello "file-csv" non è che si cresca professionalmente.
Permessi di invio
Rispondi quotando