Am 15.03.2012 17:31, schrieb Malka Cymbalista:
> We are running MySQL version 5.0.45 on a Linux machine. Most of our tables
> are MyIASM but we have recently installed drupal 7 and drupal 7 requires
> INNODB tables. Every now and then when we restart MySQL using the commands
> /etc/init.d/mys
On 9/7/06, Paul McCullagh <[EMAIL PROTECTED]> wrote:
It sounds like you program allows ad-hoc queries, so why don't you
just limit the number of rows returned by a select?
For example you could limit the number of rows to 1001. If the server
returns 1001, then display 1000 and tell the user the
On Sep 7, 2006, at 3:32 PM, <[EMAIL PROTECTED]> wrote:
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,
On 9/7/06, [EMAIL PROTECTED] wrote:
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
:[EMAIL PROTECTED]
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 crea
:[EMAIL PROTECTED]
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 crea
Hi Prasad
This question got me a bit interested as we're thinking of moving
some MyISAM tables to InnoDB and I haven't used it much.
I decided to test some of these ideas so I created an innodb table
and put some data into it and tried some selects:
(Running on MacBook Pro, 2.0ghz, 1gb RA
In the last episode (Sep 07), [EMAIL PROTECTED] said:
> Hi Dan,
>
> Thanks for yur response. Does it makes sense to create an index on a
> primary key ..as that is my smallest field ?
It might, because in an InnoDB table, your primary index also holds
your row data. So it's actually your largest
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:[EMAIL PROTECTED]
Sent: Monday, September 04, 2006 9:53 AM
To: Prasad Ramisetti (WT01 - Broadband Networks)
Cc: [EMAIL PROTECTED];
[EMAIL PROTECTED] 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 ?
A primary key already has an index.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.
Networks)
Cc: [EMAIL PROTECTED]; mysql@lists.mysql.com
Subject: Re: problem with InnoDB
In the last episode (Sep 04), [EMAIL PROTECTED] 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.
In the last episode (Sep 04), [EMAIL PROTECTED] 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 smalles
PROTECTED]
Sent: Wednesday, August 16, 2006 9:58 AM
To: Prasad Ramisetti (WT01 - Broadband Networks)
Cc: mysql@lists.mysql.com
Subject: Re: problem with InnoDB
[EMAIL PROTECTED] wrote:
> Hi ,
>
>
> select count(*) is painfully slow in case of innoDB when the number of
> records are a
Subject: RE: Problem with INNODB transactions
What connection pool code are you using? My guess is that the problem is
in your code somewhere. Either transactions are not being closed (i.e.
because of a connection pool flaw maybe?) or you have two threads trying
to update the same row at the same
What connection pool code are you using? My guess is that the problem is
in your code somewhere. Either transactions are not being closed (i.e.
because of a connection pool flaw maybe?) or you have two threads trying
to update the same row at the same time (in which case this would be
expected beha
[EMAIL PROTECTED] wrote:
Hi,
There is a problem with CPU utlization when using INNODB. The CPU
utilization goes to 100% in a dual processor solaris box. With the same
setup, myISAM uses only 60% of the CPU.
As I said before, stuff like 'count(*)' queries cannot use an index in
innodb - if y
Hi,
There is a problem with CPU utlization when using INNODB. The CPU
utilization goes to 100% in a dual processor solaris box. With the same
setup, myISAM uses only 60% of the CPU.
Could someone please let me know what could be the problem. There are
some other processes running on the same b
Hi,
There is a problem with CPU utlization when using INNODB. The CPU
utilization goes to 100% in a dual processor solaris box. With the same
setup, myISAM uses only 60% of the CPU.
Could someone please let me know what could be the problem. There are
some other processes running on the same b
[EMAIL PROTECTED] wrote:
Hi ,
select count(*) is painfully slow in case of innoDB when the number of
records are around 1 million. Ths select count(*) query in myISAM takes
0.01 secs and the same query in InnoDB takes around 20.15 secs.
Can anybody suggest me how to speed up this query ?
Yo
19 matches
Mail list logo
