Newsgroup: it.comp.www.php
Titolo: Mysql Ottimizzazioni

Un saluto a tutto l'NG!
Veniamo al mio caso:
Ho un sito php che utilizza due tabelle che sono esattamente identiche come
colonne, ma che hanno due scopi completamente differenti:
Una è gigante e può contenere un numero pressochè infinito di insert (si può
arrivare tranquillamente a 1000000 insert), questa tabella non ha la pretese
di velocità, viene aperta generalmente per fare degli update e naturalmente
per essere letta.
L'altra è molto più breve può contenere al massimo 10 insert per utente
iscritto al sito, questa tabella deve essere velocissima in lettura, in
quanto viene aperta ad ogni pagina del sito, sia per lettura che per
scrittura.
Ho deciso quindi per i motivi sopracitati di tenere i due data su due
tabelle a parte, in quanto gli scopi sono molto diversi e poichè è un sito
sotto pesantissimo stress di traffico, ho bisogno che le richieste alla
seconda siano veramente velocissime.
Fin qui  tutto bene se non che quando devo spostare un insert da una tabella
all'altra devo fare una paccata di query, quando basterebbe fare un update
ad una colonna che faccia da flag..........
Veniamo alle domande:
C'è un modo per settare gli indici di una tabella in modo tale che salvi i
dati in due tabelle differenti o di chiedere al mysql di tenere i dati
archiviati in maniera diversa in modo da rendere più fast (and furious) le
query alla tabella che deve essere aperta ad ogni pagina.
vi ringrazio anticipatamente per la lettura! :)
apollo

 posted this:





analizza my.cnf, li puoi ottimizzare un bel casino, il default e' per macchine
con pochi Mega. 
Cercare di usare tabelle statiche (quindi senza varchar, text) ma dipende dai tuoi
dati. Di solito diventa _molto_ piu' veloce. Ottimizzare con cautela i tipi usati
per dei campi (int-smallint-tinyint, enum, set etc.)
Usare (ma qui serve capire como sono veramente organizzati i tuoi dati (e
se posti le definizioni si potrebbe ipotizzare qualcosa di concreto)) indici su
piu' campi.
Vedere se puoi normalizzare di piu' (che puo' causare grande differenze nella
velocita').
Analizzare con EXPLAIN le query che farai su queste tabelle. 

 Analizzare con EXPLAIN le query che farai su queste tabelle.
fico....... questa la provo subito
GRAZIE PER LE DRITTE
apollo

Ah intanto ho trovato questo su 
mysql.com
http://www.mysql.com/doc/en/MERGE.html
Me lo consigni?
Oppure è meglio non rischiare con cose ancora in testing?
Un piccolo estratto qui sotto:
MERGE tables can help you solve the following problems:
  a.. Easily manage a set of log tables. For example, you can put data from
different months into separate files, compress some of them with myisampack,
and then create a MERGE to use these as one.
  b.. Give you more speed. You can split a big read-only table based on some
criteria and then put the different table part on different disks. A MERGE
table on this could be much faster than using the big table. (You can, of
course, also use a RAID to get the same kind of benefits.)
  c.. Do more efficient searches. If you know exactly what you are looking
after, you can search in just one of the split tables for some queries and
use a MERGE table for others. You can even have many different MERGE tables
active, with possible overlapping files.
  d.. More efficient repairs. It's easier to repair the individual files
that are mapped to a MERGE file than trying to repair a really big file.
  e.. Instant mapping of many files as one. A MERGE table uses the index of
the individual tables. It doesn't need to maintain an index of its one. This
makes MERGE table collections VERY fast to make or remap. Note that you must
specify the key definitions when you create a MERGE table!.
  f.. If you have a set of tables that you join to a big table on demand or
batch, you should instead create a MERGE table on them on demand. This is
much faster and will save a lot of disk space.
  g.. Go around the file-size limit for the operating system.
  h.. You can create an alias/synonym for a table by just using MERGE over
one table. There shouldn't be any really notable performance impacts of
doing this (only a couple of indirect calls and memcpy() calls for each
read).

rileggendo tra le righe c'è scritto "You can, of
course, also use a RAID to get the same kind of benefits", proprio al punto
che spiega quello che vorrei fare io a proposito delle tabelle.
and so: what is RAID?




Redundant Array of Inexpensive Disks
Ovvero, anziche' un unico disco ne metti su cinque, e ottieni un
sustained transfer rate superiore.
In realta' per i DB su Web non e' cosi', per vari motivi.
Leonardo

Insomma se ho capito bene mysql è molto scalabile, ma questo poco mi aiuta
visto che dubito di poter costringere il mio hosting a montare 5 dischi ;)
voi cosa fareste? lascereste le due tabelle separate o le unireste
(apportando 2 colonne in più come flag) cercando un alternativa con gli
indici. Allo stadio attuale mi conviene lasciare così le cose e fare
funzioni complesse per lo spostamento di insert da una tabella all'altra e
amen (tanto questo accade di rado) e poco importa, rispetto ai ben più
frequenti select e update.
apollo

 frequenti select e update.
Posta le definizioni delle tabelle, qualche spiegazioni sui dati e
le query che devi fare. Poi vediamo. Sono sicuro che qualcosa
si puo' fare. ;-)

 ???? ^___^ <- beata ignoranza: normalizzare?
Ah, questo vuol dire che ti tocca di studiare. Cerca un po' in rete
ci sono alcuni testi su questo tema (e non dipende da mysql).