Originariamente inviato da LeaderGL
Si alle memory table avevo pensato anche io, però per progetti grandi chissà se possono essere utili. Nel senso che la memoria a disposizione delle tabelle di tipo memory è predefinita (dalle impostazioni del server mysql) quindi se si hanno molti utenti può essere saturata.
Oltre al problema che non avendo campi blob/text non hai a disposizione un ampio campo di testo dove poter, come hai detto, serializzare.

Per le altre due soluzioni hai degli esempi o cmq altre informazioni?

Tu che metodo usi?
Per quanto riguarda le tabelle con engine memory

codice:
- If an internal table becomes too large, the server automatically converts it to an on-disk table. The size limit is determined by the value of the tmp_table_size system variable.

- The maximum size of MEMORY tables is limited by the max_heap_table_size system variable, which has a default value of 16MB. To have larger (or smaller) MEMORY tables, you must change the value of this variable. The value in effect at the time a MEMORY table is created is the value used for the life of the table. (If you use ALTER TABLE or TRUNCATE TABLE, the value in effect at that time becomes the new maximum size for the table. A server restart also sets the maximum size of existing MEMORY tables to the global max_heap_table_size value.) You can set the size for individual tables as described later in this section.
direi che anche il valore di default, per quanto possa essere immenso il progetto, basta, considera che 16mb per una tabella che al massimo può occupare 500 byte per riga, ma in realtà sta sotto i 100, a parte le variabili serializzate, vuol dire che dentro quella tabella ci possono stare più di cento mila sessioni quindi direi che tranne che ti ritrovi con un parco server ed un forum come hwupgrade il problema non lo hai (e volendo non lo hai nemmeno li impostando una garbage collection più frequente, personalmente utilizzo un calcolo delle probabilità)

Per il problema dei campi blob/text ci sono due soluzioni:
- la prima, che utilizzo, è appoggiare i valori su una seconda tabella e leggerli/scriverli SOLO quando è necessario ... per intenderci non estraggo i valori automaticamente all'accesso sia perché costerebbe risorse sia perché essendo dati serializzati dovrai pure deserializzarli, magari inutilmente
- la seconda potrebbe essere quella di creare una serie di sessioni fittizzie da joinare con un group_concat sul campo contenente le variabili di sessione, ma mentre è comoda per la lettura ... la scrittura è più pesante considerato che anche se si usano ad esempio gli insert multipli comunque ci saranno da effettuare più inserimenti ... inoltre questo sistema causerebbe una considerevole frammentazione dei dati perché abbiamo righe sparpagliate qua è là.

In questi casi, direi che conviene cambiare sistema di gestione, vedi ad esempio memcache che lo vedo estremamente adatto. sqlite non si può usare se si ha più di un server perché le performance si ridurrebberò parecchio.