I really don?t know the differences betwen MyISAM and InnoDB yet but I?ll google for it right now. Thank u. Zechim De: Eddie Drapkin [mailto:oorza2k5@xxxxxxxxx] Enviada em: sexta-feira, 12 de junho de 2009 15:05 Para: Nitsan Bin-Nun Cc: Jônatas Zechim; php-general@xxxxxxxxxxxxx Assunto: Re: phpMyAdmin, localhost, mysql overhead The better question is why are you using MyISAM tables? Unless there's a legitimate reason to prefer MyISAM over InnoDB, you should be using InnoDB. On Fri, Jun 12, 2009 at 2:01 PM, Nitsan Bin-Nun <nitsanbn@xxxxxxxxx> wrote: There is no way to avoid it since whenever you delete a row in a myisam table you create a space in the order of the rows, this space is expressed by a little bit of extra file size of the database. This extra file size is called in phpmyadmin as "overhead", you can kill this over head either by running some INSERT queries which will fill the space with the inserted rows or running an OPTIMISE query. In general, I don't think that there is anything that you should do or take care of, it is not rocket science and your tables will be good with or without the overhead ;) Nitsan On Fri, Jun 12, 2009 at 7:41 PM, Jônatas Zechim <zechim.php@xxxxxxxxx>wrote: > I have other tables running but only this give me ?overhead?. > > > > I?d know why this table does this and if is bad for my MySQL Server? > > Is there anyway to avoid it? > > > > Zechim > > > > De: nitsan@xxxxxxxxxxxx [mailto:nitsan@xxxxxxxxxxxx] Em nome de Nitsan > Bin-Nun > Enviada em: sexta-feira, 12 de junho de 2009 14:33 > Para: Jônatas Zechim > Cc: php-general@xxxxxxxxxxxxx > Assunto: Re: phpMyAdmin, localhost, mysql overhead > > > > I haven't read all your mail, I'm sorry for it in advance, but I think that > you should know that "overheard" is just a blasting phrase for something > which was made up by phpmyadmin. > > Basically, when you run a lot of DELETE or UPDATE queries on a table an > "overhead" is created, generally speaking this "overhead" is a space > between > rows in the database file, which will cause mysql engine to insert rows > into > this space on future INSERT queries. > > You can imagine your table as a hard drive, every couple of months (some > may > say weeks) you have to run a de-fragment on it, you can do the same with > your database table, look up the query OPTIMIZE TABLE which will do the > de-frag for you :) > > If you have any further questions feel free to bring them up. > > Regards, > Nitsan > > On Fri, Jun 12, 2009 at 7:02 PM, Jônatas Zechim <zechim.php@xxxxxxxxx> > wrote: > > Hi there, i have this table running on my localhost: > > CREATE TABLE `caffecheckout_compra_itens` ( > `compra_key` varchar(23) NOT NULL, > `item_id` int(5) NOT NULL, > `item_valor` decimal(10,2) NOT NULL, > `item_peso` decimal(5,3) NOT NULL, > `item_qtd` int(3) NOT NULL, > `item_data` int(10) NOT NULL, > `item_obs` varchar(100) NOT NULL, > PRIMARY KEY (`item_id`), > KEY `compra_key` (`compra_key`) > ) ENGINE=MyISAM DEFAULT CHARSET=latin1; > > > It's on my Server, but when I add a row and after remove that I'd overhead > this table (58bytes/row), anyone know why is this happening? > > I run this SQL: > > INSERT INTO > caffecheckout_compra_itens > (compra_key,item_id,item_valor,item_peso,item_qtd,item_data) > VALUES > ('12448259804a32897ce1116','2','19.90','0.250',1,'1244825980') > ON DUPLICATE KEY UPDATE > item_qtd=item_qtd+1 > > And after: > > DELETE FROM > caffecheckout_compra_itens > WHERE > compra_key='12448259804a32897ce1116' > > > Zechim > > > -----Mensagem original----- > De: Andrew Ballard [mailto:aballard@xxxxxxxxx] > Enviada em: sexta-feira, 12 de junho de 2009 09:38 > Para: revDAVE > Cc: php-general@xxxxxxxxxxxxx > Assunto: Re: Field type for american money > > On Thu, Jun 11, 2009 at 4:08 PM, revDAVE<Cool@xxxxxxxxxxxxxxxx> wrote: > > Php - MySQL - newbie question > > > > - Field type for american money - int(11) seems to work fine > > > > - but also I tried decimal(10,2) > > > > Is one a better choice than another for american money usage? > > > > > > -- > > Thanks - RevDave > > Cool @ hosting4days . com > > [db-lists 09] > > It depends on what you need to store, honestly. If all your dollar > amounts are integers, int would work fine. If you need decimals, > decimal(10, 2) would be fine for a lot of applications. However, a lot > of financial applications need a little more precision. SQL Server has > a money datatype that looks like it's about equivalent to decimal(19, > 4) and a smallmoney type that looks like it's equivalent to > decimal(10, 4). That handles things like gas prices that always have > that extra 9/10 of a penny tacked onto them, or items that are 3 for a > dollar. If you enter a price of 0.33 in a decimal(10, 2) field, > multiplying that by 3 will result in 0.99, whereas three items priced > at 0.3333 will come to 0.9999, which when formatted to two digits will > round to 1.00. > > Andrew > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > > >
