List:General Discussion« Previous MessageNext Message »
From:<prasad.ramisetti Date:September 7 2006 1:32pm
Subject:RE: problem with InnoDB
View as plain text  

Hi Douglas,

I need to know the number of rows that a query will return before
actually executing the query. So I am sending select count(*) before
sending select *. Actually I need to reject queries if the number of
records that it will return is huge, to avoid my server running out of
memory. My application has a huge database of around 10 millions.

The selects with INNODB falls drastically as the size of records grow. A
select count(*) that takes 4 secs with 1 million records takes 40 secs
with 3 million records.

Regards
Prasad

-----Original Message-----
From: Douglas Sims [mailto:doug@stripped]
Sent: Thursday, September 07, 2006 10:39 AM
To: Prasad Ramisetti (WT01 - Broadband Networks)
Cc: MySQL List
Subject: Re: problem with InnoDB

Hi Prasad

A primary key automatically creates an index and not-null and unique
constraints, too.  So you don't need to explicitly create an index on a
primary key column.

If your queries are going to have WHERE clauses (as they most likely
are) I'm not sure how the small-index suggestion would make the query
any faster - the WHERE clause would preclude the use of that index in
computing the rows - but I'm probably missing something here.

When you say that you need to know the number of rows returned before
executing the query, do you mean before you start getting rows back or
before you actually execute the query?  I don't think it's possible to
know how many rows the query will return without actually executing it,
but you might well want to know how many rows you get before you start
processing rows.

Have you looked at the SQL_CALC_FOUND_ROWS option on SELECT, and the
accompanying FOUND_ROWS() function? http://dev.mysql.com/doc/refman/
5.0/en/information-functions.html
  It will tell you the total number of rows which would have been found
if you hadn't used a LIMIT clause.  I think it is a connection- specific
function; if you created a second statement handle and did a SELECT
FOUND_ROWS() on the same connection, perhaps that would give what you
want.


Douglas Sims
Doug@stripped




On Sep 6, 2006, at 11:29 PM, <prasad.ramisetti@stripped>
<prasad.ramisetti@stripped> wrote:

>
> Hi Dan,
>
> Thanks for yur response. Does it makes sense to create an index on a
> primary key ..as that is my smallest field ?
>
> Regards
> Prasad
>
> -----Original Message-----
> From: Dan Nelson [mailto:dnelson@stripped]
> Sent: Monday, September 04, 2006 9:53 AM
> To: Prasad Ramisetti (WT01 - Broadband Networks)
> Cc: dmagick@stripped; mysql@stripped
> Subject: Re: problem with InnoDB
>
> In the last episode (Sep 04), prasad.ramisetti@stripped said:
>> Actually there is some requirement, where I need to know the number
>> of
>
>> rows that I will get for my queries before actually executing the
>> query. Could you please suggest some way for this.
>
> Your best bet is to create an index on the smallest column you can
> find (maybe even create a char(1) and leave it empty), and "SELECT
> COUNT(*) FROM innotable USE INDEX (smallcolumn)".  That way mysql only

> has to scan a small secondary index instead of the main table index.
>
> --
> 	Dan Nelson
> 	dnelson@stripped
>
>
> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> addressee(s) and may contain proprietary, confidential or privileged
> information. If you are not the intended recipient, you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately and destroy all copies of this message and any
> attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of
> viruses. The company accepts no liability for any damage caused by any

> virus transmitted by this email.
>
> www.wipro.com
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:    http://lists.mysql.com/mysql?unsub=1
>



The information contained in this electronic message and any attachments to this message
are intended for the exclusive use of the addressee(s) and may contain proprietary,
confidential or privileged information. If you are not the intended recipient, you should
not disseminate, distribute or copy this e-mail. Please notify the sender immediately and
destroy all copies of this message and any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should check this
email and any attachments for the presence of viruses. The company accepts no liability
for any damage caused by any virus transmitted by this email.

www.wipro.com
Thread
RE: problem with InnoDBprasad.ramisetti4 Sep
  • Re: problem with InnoDBDan Nelson4 Sep
RE: problem with InnoDBprasad.ramisetti7 Sep
  • Re: problem with InnoDBChris7 Sep
  • Re: problem with InnoDBDouglas Sims7 Sep
  • Re: problem with InnoDBDan Nelson7 Sep
    • Re: problem with InnoDBDouglas Sims7 Sep
RE: problem with InnoDBprasad.ramisetti7 Sep
  • Re: problem with InnoDBJochem van Dieten7 Sep
RE: problem with InnoDBprasad.ramisetti7 Sep
  • Re: problem with InnoDBPaul McCullagh7 Sep
    • Re: problem with InnoDBGabriel PREDA10 Sep