Re: mysql big table select speed

Hello, On Sep/24/2008, Phil wrote: Just a wild guess but, did you perhaps change the filesystem to a journalling filsystem when moving to the different server? mount reports the same (ext3) I once accidently moved my database from an ext2 to an ext3 partition and it took me a while to

Re: mysql big table select speed

does it have the same network speed as your old server. On 9/25/08, Carles Pina i Estany [EMAIL PROTECTED] wrote: Hello, On Sep/24/2008, Phil wrote: Just a wild guess but, did you perhaps change the filesystem to a journalling filsystem when moving to the different server? mount

Re: mysql big table select speed

is /tmpdir parameter on both machines using the default value On 9/25/08, Carles Pina i Estany [EMAIL PROTECTED] wrote: Hello, On Sep/25/2008, Ananda Kumar wrote: does it have the same network speed as your old server. yes, it has. But I'm running the query from localhost :-) (socket

Re: mysql big table select speed

Hello, On Sep/25/2008, Ananda Kumar wrote: is /tmpdir parameter on both machines using the default value Old machine: yes. New machine: I have tried two places (different partitions, same FS -ext3-, same hard disk). On the old machine it's in a different partition of the same hard disk than

Re: mysql big table select speed

Hello, On Sep/25/2008, Ananda Kumar wrote: does it have the same network speed as your old server. yes, it has. But I'm running the query from localhost :-) (socket connection). Even, the query only returns one number and I don't have any federated tables, etc. On 9/25/08, Carles Pina i

Re: mysql big table select speed

On the new machine its on a different partition than the database. Also did u try to analyze the table and run the query On 9/25/08, Carles Pina i Estany [EMAIL PROTECTED] wrote: Hello, On Sep/25/2008, Ananda Kumar wrote: is /tmpdir parameter on both machines using the default value

Re: mysql big table select speed

Hello, On Sep/25/2008, Ananda Kumar wrote: On the new machine its on a different partition than the database. Also did u try to analyze the table and run the query I will do it (maybe on Saturday, as I guess that will take long time to do it). But I think that I did last weekend when I

mysql big table select speed

Hello, I have a database with a big table: 350 milion of registers. The table is a Isam table, very simple: mysql describe stadistics; +-+--+--+-+-++ | Field | Type | Null | Key | Default | Extra |

Re: mysql big table select speed

Just a wild guess but, did you perhaps change the filesystem to a journalling filsystem when moving to the different server? I once accidently moved my database from an ext2 to an ext3 partition and it took me a while to figure out the degradation of queries.. Phil On Wed, Sep 24, 2008 at 6:16

Re: SELECT Speed

At 05:57 PM 11/26/2007, you wrote: The second query might be faster due to caching. This can be verified by executing: RESET QUERY CACHE before executing the second query. This will clear the queries from the cache. Mike -- MySQL General Mailing List For list archives:

Re: SELECT Speed

On Nov 27, 2007 10:21 AM, mos [EMAIL PROTECTED] wrote: At 05:57 PM 11/26/2007, you wrote: The second query might be faster due to caching. This can be verified by executing: RESET QUERY CACHE before executing the second query. This will clear the queries from the cache. No need to blow

SELECT speed

Hi, I have a problem with SELECT speed. The first execution takes up to several minutes while the next (with the same statement) takes not more then several seconds. The statement example is: select nas.nasIpAddress, count(distinct(acct.user_id)), count(*), sum(acct.acctOutputOctets) from acct

SELECT Speed

Hi, I have a problem with SELECT speed. The first execution takes up to several minutes while the next (with the same statement) takes not more then several seconds. The statement example is: select nas.nasIpAddress, count(distinct(acct.user_id)), count(*), sum(acct.acctOutputOctets) from acct

Re: SELECT Speed

, 2007 10:03 AM Subject: SELECT Speed Hi, I have a problem with SELECT speed. The first execution takes up to several minutes while the next (with the same statement) takes not more then several seconds. The statement example is: select nas.nasIpAddress, count(distinct(acct.user_id)), count

Re: SELECT Speed

The second query might be faster due to caching. On 11/26/07, Alexander Bespalov [EMAIL PROTECTED] wrote: Hi, I have a problem with SELECT speed. The first execution takes up to several minutes while the next (with the same statement) takes not more then several seconds. The statement

Poor Select speed on simple 1 table query

It doesn't get any simpler than this. :) The Select statement takes way too long to complete. select rcd_id, company_name from company where company_name like fra% 12357 rows fetched (86.08 seconds) However if it returns just the column value from the index, it is quite fast: select company_name

RE: Poor Select speed on simple 1 table query

Mos, Personally, I never use like for anything. I would add a fulltext index myself and call it a day. But that's me. Donny -Original Message- From: mos [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 2:40 PM To: [EMAIL PROTECTED] Subject: Poor Select speed on simple 1

RE: Poor Select speed on simple 1 table query

[mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 2:40 PM To: [EMAIL PROTECTED] Subject: Poor Select speed on simple 1 table query It doesn't get any simpler than this. :) The Select statement takes way too long to complete. select rcd_id, company_name from company where

RE: Poor Select speed on simple 1 table query

You could always add an index on company_name + rcd_id. That technically shouldn't help, but I've seen crazier things before. Donny -Original Message- From: mos [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 4:23 PM To: [EMAIL PROTECTED] Subject: RE: Poor Select speed

select speed

Hi All, If I got one table A_table with many columns, and a second table B_table is the same but with just primary field and unique field... How much meaningful is the time difference between these queries? 1. SELECT unique_field FROM A_table WHERE prim_field='val'; 2. SELECT unique_field FROM

Re: select speed

Lorderon wrote: Hi All, If I got one table A_table with many columns, and a second table B_table is the same but with just primary field and unique field... How much meaningful is the time difference between these queries? 1. SELECT unique_field FROM A_table WHERE prim_field='val'; 2. SELECT

Re: select speed

On Thu, 26 Feb 2004, Lorderon wrote: Hi All, If I got one table A_table with many columns, and a second table B_table is the same but with just primary field and unique field... How much meaningful is the time difference between these queries? 1. SELECT unique_field FROM A_table WHERE

Re: Inefficient use of index (was: Big difference in MyISAM and InnoDB SELECT speed)

Janusz Krzysztofik wrote: ... I am trying to optimize MySQL (3.23.49 from Debian stable) setup for ASPseek application. I decided to try InnoDB in order to be able to update tables while performing time consuming selects. After converting all tables to InnoDB I noticed a big difference in

Big difference in MyISAM and InnoDB SELECT speed

Hello, I am trying to optimize MySQL (3.23.49 from Debian stable) setup for ASPseek application. I decided to try InnoDB in order to be able to update tables while performing time consuming selects. After converting all tables to InnoDB I noticed a big difference in processing speed of one of the

RE: Big difference in MyISAM and InnoDB SELECT speed

: lundi 24 novembre 2003 13:58 A : [EMAIL PROTECTED] Objet : Big difference in MyISAM and InnoDB SELECT speed Hello, I am trying to optimize MySQL (3.23.49 from Debian stable) setup for ASPseek application. I decided to try InnoDB in order to be able to update tables while performing time consuming

Inefficient use of index (was: Big difference in MyISAM and InnoDB SELECT speed)

an EXPLAIN on your query ? May be an index on (origin,status,deleted) could help. Marc. -Message d'origine- De : Janusz Krzysztofik [mailto:[EMAIL PROTECTED] Envoy : lundi 24 novembre 2003 13:58 A : [EMAIL PROTECTED] Objet : Big difference in MyISAM and InnoDB SELECT speed Hello

Re: Inefficient use of index (was: Big difference in MyISAM and InnoDB SELECT speed)

PROTECTED] Envoy : lundi 24 novembre 2003 13:58 A : [EMAIL PROTECTED] Objet : Big difference in MyISAM and InnoDB SELECT speed Hello, I am trying to optimize MySQL (3.23.49 from Debian stable) setup for ASPseek application. I decided to try InnoDB in order to be able to update tables while

RE: Inefficient use of index (was: Big difference in MyISAM and InnoDB SELECT speed)

difference in MyISAM and InnoDB SELECT speed) Marc, Thank you for your prompt answer. I run EXPLAIN in both cases and got: MyISAM (fast): mysql explain select url_id from urlword where deleted=0 and status=200 and origin=1

Re: Inefficient use of index (was: Big difference in MyISAM and InnoDB SELECT speed)

Hi, You are not using any indicies, because there aren't any that could be used in this query. Try adding an index on (status,deleted) I wonder: how many possible different values would such an index return? If this is a (very) low value, won't the index make things slower (if it's being

Re: Inefficient use of index (was: Big difference in MyISAM and InnoDB SELECT speed)

Martijn Tonies wrote: Hi, You are not using any indicies, because there aren't any that could be used in this query. Try adding an index on (status,deleted) I wonder: how many possible different values would such an index return? mysql select distinct status, deleted from urlword;

Re: Inefficient use of index (was: Big difference in MyISAM and InnoDB SELECT speed)

Hi, You are not using any indicies, because there aren't any that could be used in this query. Try adding an index on (status,deleted) I wonder: how many possible different values would such an index return? mysql select distinct status, deleted from urlword;

Re: select speed

Hey, you know what? You're right! I'm an idiot. Thanks. :) BD wrote: Gabriel, I have a sneaky suspicion your primary key is a CHAR or VARCHAR, right? If so, your select statement is using an integer which means it has to convert it for each record. If you put quotes around the

select speed

Greetings, We're running MySQL 3.23.47 on MacOS X 10.1.2. We've got a rather large table ( 200,000+ records, 120+ columns) and some simple queries on that table have pretty inconsistent performance. Due to licensing issues I can't give an actual example of the table, but here is an equivalent

Re: select speed

At 10:39 AM 3/18/2002, you wrote: Greetings, We're running MySQL 3.23.47 on MacOS X 10.1.2. We've got a rather large table ( 200,000+ records, 120+ columns) and some simple queries on that table have pretty inconsistent performance. Due to licensing issues I can't give an actual example of the

Re: select speed

On Mon, Mar 18, 2002 at 11:39:09AM -0500, Gabriel Ricard wrote: Greetings, We're running MySQL 3.23.47 on MacOS X 10.1.2. We've got a rather large table ( 200,000+ records, 120+ columns) and some simple queries on that table have pretty inconsistent performance. Due to licensing issues I

Re: select speed

key_buffer is 384M, table1.MYI is 17.5MB. Jeremy Zawodny wrote: On Mon, Mar 18, 2002 at 11:39:09AM -0500, Gabriel Ricard wrote: Greetings, We're running MySQL 3.23.47 on MacOS X 10.1.2. We've got a rather large table ( 200,000+ records, 120+ columns) and some simple queries on that table have

Re: select speed

Gabriel, I have a sneaky suspicion your primary key is a CHAR or VARCHAR, right? If so, your select statement is using an integer which means it has to convert it for each record. If you put quotes around the 30460203 it will run faster as in: select IndexField1,Field1,Field2 from