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 > > > > > > > > >
