iPad
>
> On Oct 5, 2011, at 4:01 AM, Tompkins Neil
> wrote:
>
> > Following my mail below, if anyone can help optimise the query further
> that
> > would be a great help.
> >
> > -- Forwarded message --
> > From: Tompkins Neil
> >
t help.
>
> -- Forwarded message --
> From: Tompkins Neil
> Date: Wed, Oct 5, 2011 at 9:48 AM
> Subject: Re: Slow query - please help
> To: Johnny Withers
> Cc: "mysql@lists.mysql.com"
>
>
> I just revised my query and now get the followin
g
where'
After doing this the query speed is acceptable.
Thanks
Neil
On Wed, Oct 5, 2011 at 3:12 AM, Johnny Withers wrote:
> Can you post the explain extended output of your query?
>
> Sent from my iPad
>
> On Oct 4, 2011, at 2:45 PM, Neil Tompkins
> wrote:
>
>
onst',
'267', '100.00', 'Using index condition; Using where'
Thanks
Neil
On Wed, Oct 5, 2011 at 3:12 AM, Johnny Withers wrote:
> Can you post the explain extended output of your query?
>
> Sent from my iPad
>
> On Oct 4, 2011, at 2:45 PM
; To: mark carson
>> Cc: "[MySQL]"
>> Subject: Re: Slow query - please help
>>
>
>> I downloaded version mysql-5.6.2-m5-win32.msi and he table definitions are
>> below, let me know if you need any more information.
>>
>> CREATE TABLE `districts` (
I downloaded version mysql-5.6.2-m5-win32.msi and he table definitions are
below, let me know if you need any more information.
CREATE TABLE `districts` (
`district_id` int(11) NOT NULL,
`language_code` char(2) COLLATE utf8_unicode_ci NOT NULL DEFAULT 'en',
`city_id` int(11) DEFAULT NULL,
On Mon, Jan 24, 2011 at 6:43 PM, Gavin Towey wrote:
> If you show the EXPLAIN SELECT .. output, and the table structure, someone
> will be able to give a more definite answer.
>
>
Thanks for the reply Gavin. I actually did place this info in my very first
message on this thread, along with my bas
If you show the EXPLAIN SELECT .. output, and the table structure, someone will
be able to give a more definite answer.
-Original Message-
From: Kendall Gifford [mailto:zettab...@gmail.com]
Sent: Monday, January 24, 2011 2:29 PM
To: mysql@lists.mysql.com
Subject: Re: Slow query on MySQL4
On Mon, Jan 24, 2011 at 2:20 PM, Kendall Gifford wrote:
>
>
> On Mon, Jan 24, 2011 at 3:40 AM, Joerg Bruehe wrote:
>
>> Hi everybody!
>>
>>
>> Shawn Green (MySQL) wrote:
>> > On 1/21/2011 14:21, Kendall Gifford wrote:
>> >> Hello everyone, I've got a database on an old Fedora Core 4 server
>> >> r
On Mon, Jan 24, 2011 at 3:40 AM, Joerg Bruehe wrote:
> Hi everybody!
>
>
> Shawn Green (MySQL) wrote:
> > On 1/21/2011 14:21, Kendall Gifford wrote:
> >> Hello everyone, I've got a database on an old Fedora Core 4 server
> >> running
> >> MySQL 4 (mysql-server.x86_64 4.1.12-2.FC4.1). The database
Hi everybody!
Shawn Green (MySQL) wrote:
> On 1/21/2011 14:21, Kendall Gifford wrote:
>> Hello everyone, I've got a database on an old Fedora Core 4 server
>> running
>> MySQL 4 (mysql-server.x86_64 4.1.12-2.FC4.1). The database in question
>> has
>> just two (InnoDB) tables:
>>
>> messages (appr
On Fri, Jan 21, 2011 at 2:01 PM, Shawn Green (MySQL) <
shawn.l.gr...@oracle.com> wrote:
> On 1/21/2011 14:21, Kendall Gifford wrote:
>
>> Hello everyone, I've got a database on an old Fedora Core 4 server running
>> MySQL 4 (mysql-server.x86_64 4.1.12-2.FC4.1). The database in question has
>> just
On 1/21/2011 14:21, Kendall Gifford wrote:
Hello everyone, I've got a database on an old Fedora Core 4 server running
MySQL 4 (mysql-server.x86_64 4.1.12-2.FC4.1). The database in question has
just two (InnoDB) tables:
messages (approx 2.5 million records)
recipients (approx 6.5 million records)
you need hughe ram / innodb_buffer_pool for large datasets
in a perfect world the buffer_pool is as large as the data
how looks your current config?
how much RAM has the machine?
Am 21.01.2011 20:21, schrieb Kendall Gifford:
> Hello everyone, I've got a database on an old Fedora Core 4 server run
gton, CT 06032
860.674.8796 / FAX: 860.674.8341
E-mail: je...@gii.co.jp
Web site: www.the-infoshop.com
>-Original Message-
>From: Travis Ard [mailto:travis_...@hotmail.com]
>Sent: Tuesday, August 10, 2010 6:53 PM
>To: 'Jerry Schwartz'; mysql@lists.mysql.com
>Subject: R
>-Original Message-
>From: Travis Ard [mailto:travis_...@hotmail.com]
>Sent: Tuesday, August 10, 2010 6:53 PM
>To: 'Jerry Schwartz'; mysql@lists.mysql.com
>Subject: RE: Slow query using string operator
>
>Can you create a second, indexed column in your fee
Hi Jerry, all!
I second Travis' advice:
Travis Ard schrieb:
> Can you create a second, indexed column in your feed_new temp table that
> includes the title without the year appended? That might allow you to get
> by with a single pass through the larger prod table and avoid reading rows
> from
Can you create a second, indexed column in your feed_new temp table that
includes the title without the year appended? That might allow you to get
by with a single pass through the larger prod table and avoid reading rows
from the feed_new table.
-Travis
-Original Message-
From: Jerry S
.8796 / FAX: 860.674.8341
www.the-infoshop.com
>-Original Message-
>From: baron.schwa...@gmail.com [mailto:baron.schwa...@gmail.com] On Behalf Of
>Baron Schwartz
>Sent: Thursday, May 27, 2010 9:09 AM
>To: MySql
>Subject: Re: Slow query using string functions
>
>Jerry,
>-Original Message-
>From: Gavin Towey [mailto:gto...@ffn.com]
>Sent: Wednesday, May 26, 2010 7:39 PM
>To: je...@gii.co.jp; mysql@lists.mysql.com
>Subject: RE: Slow query using string functions
>
>Jerry,
>
>Are you sure this is really your explain plan for this
Jerry,
On Wed, May 26, 2010 at 5:13 PM, Jerry Schwartz wrote:
> I have a pretty simple query that seems to take a lot longer than it ought to
> (over 2 minutes).
>
I suspect that if you watch Handler_ stats, you'll find that the
EXPLAIN estimate is wrong for some reason and it's accessing many m
Hi!
Jerry Schwartz wrote:
> I have a pretty simple query that seems to take a lot longer than it ought to
> (over 2 minutes).
>
> [[...]]
>
> SELECT
> feed_new.new_title AS `New Title FROM Feed`,
> prod.prod_pub_prod_id AS `Lib Code FROM DB`,
> prod.prod_title AS `Title FROM
Jerry,
Are you sure this is really your explain plan for this query? That's not at
all what I would expect to see.
Regards,
Gavin Towey
-Original Message-
From: Jerry Schwartz [mailto:je...@gii.co.jp]
Sent: Wednesday, May 26, 2010 2:14 PM
To: mysql@lists.mysql.com
Subject: Slow query
On Wed, Apr 28, 2010 at 12:17 AM, Kandy Wong wrote:
> Is it true that the performance of running a query on a live replication
> master and slave has to be much slower than running a query on a static
> server?
>
> I've tried to run the following query on a replication master and it takes
> 1 min
Yves,
What happens if you replace the "tk.UserId IN (22943, 10899)" with
just one argument " tk.UserId = 22943".
Does it run much faster? If so, the In() statement may not be using an
index. You could try using a Union instead of In() to see if that is any
faster.
I have also found tha
On Sun, Apr 25, 2010 at 9:12 AM, Yves Goergen
wrote:
> Hi,
>
> I'm still stuck with my SQL query that is slow but really shouldn't be.
>
> The problem is that I cannot create a simple test case. I could only
> provide you a whole lot of pages of PHP code and SQL queries to explain
> the problem.
>
In the last episode (Jul 15), Tachu(R) said:
> I'm having random query slowness that i can only reproduce once. My main
> question is that the query runs faster the second time around but i dont
> have query cache enabled here is some info from mysql profiler;
>
> The time is spent mostly on the s
att.net
> To: dstepli...@gmail.com
> CC: mysql@lists.mysql.com
> Subject: Re: Slow query Performance
>
> On Wed, 15 Jul 2009 23:53:05 -0400 Darryle Steplight said:
>
> > Can you show us the output of DESCRIBE score and SHOW INDEX FROM score?
> >
> > On Wed, Jul 15, 200
On Wed, 15 Jul 2009 23:53:05 -0400 Darryle Steplight said:
> Can you show us the output of DESCRIBE score and SHOW INDEX FROM score?
>
> On Wed, Jul 15, 2009 at 6:44 PM, Tachu® wrote:
> > I'm having random query slowness that i can only reproduce once. My main
> > question is that the query runs
Can you show us the output of DESCRIBE score and SHOW INDEX FROM score?
On Wed, Jul 15, 2009 at 6:44 PM, Tachu® wrote:
> I'm having random query slowness that i can only reproduce once. My main
> question is that the query runs faster the second time around but i dont
> have query cache enabled he
# Query_time: 0 Lock_time: 0 Rows_sent: 1 Rows_examined: 150
SELECT SUM(COUNTER_VALUE) FROM STO_LIS sl, SCAT_LIS sfl WHERE l.STO_LIS_ID
=sfl.LIS_ID AND sfl.CAT_ID = '-1';
This is what is there in the slow-query log
On 1/2/09, Baron Schwartz wrote:
>
> It executes in 0 sec when you run it.
It executes in 0 sec when you run it. It might be in the query cache.
Try it with SQL_NO_CACHE. But even then it might run faster than it
did when it got logged in the slow log, because the table's data might
be in memory and therefore faster to access.
The point is that the slow query log show
mysql> explain SELECT SUM(COUNTER_VALUE) FROM STO_LIS sl,
-> SCAT_LIS sfl WHERE sl.STO_LIS_ID =
-> sfl.LIS_ID AND sfl.CAT_ID = '-1';
++-+---+--+---+---+-+-+--+-+
| id | select_type | ta
I'm just guessing, but if the slow query log time resolution is seconds,
perhaps 0.5 and higher rounds up?
Or, perhaps it has an index, but it can't be used in that query.
What does EXPLAIN [paste query here] tell you?
--
MySQL General Mailing List
For list archives: http://lists.mysql.
I advise you should add a new column to save this information
date_format(cache.server.tstamp,"%Y %M %d %H %i")) and add a new index on
it.
On Sat, Jun 28, 2008 at 8:55 PM, Darryl Steyn <[EMAIL PROTECTED]>
wrote:
> Hi Ananda,
>
> At the moment the explain for the entire month will look the same
Hi Ananda,
At the moment the explain for the entire month will look the same as the one
I first gave as the database currently only has test data for the start of
the month.
I will populate the database with more info on Monday, but I have managed to
get it to return only the rows where the minut
The more data u fetch the more time the query takes,.
Can u please check the explain plan for the entire month and lets us know.
If the number of rows processed by db is more than 10% of the total rows,
than optimizer considers doing a FULL TABLE scan better than a index scan
On 6/27/08, Darryl
Hi Ananda,
The problem is the one date is stored as a unix time stamp, and the other as
a -XX-XX XX:XX:XX format :/. Can MySQL just match it without converting?
I have dropped the 2nd conversions on the WHERE part of the query as I can
format that before executing to look correct.
It's takin
Also since mysql give date in Y-M-D you might want to remove the
"from_unixtime" and "date_format" formating functions
On 6/27/08, Darryl Steyn <[EMAIL PROTECTED]> wrote:
>
> Hi Jörg,
>
> I have applied the changes you have suggested and still no joy :(
>
> I will carry on playing around with it t
Hi Jörg,
I have applied the changes you have suggested and still no joy :(
I will carry on playing around with it to see if there is no way else for me
to simplify it (maybe selecting only every 30mins or so).
Thanks for the help,
Darryl
On Fri, Jun 27, 2008 at 5:28 PM, Joerg Bruehe <[EMAIL PRO
Hi Darryl, all,
Darryl Steyn wrote:
Hi Ananda,
The query is for reporting purposes and I would like to include a date range
for the user to report on. That part of the query has to be there for it to
work nicely.
Regards,
Darryl
On Fri, Jun 27, 2008 at 4:25 PM, Ananda Kumar <[EMAIL PROTECTED
At 10:07 AM 6/27/2008, you wrote:
Hi Ananda,
The query is for reporting purposes and I would like to include a date range
for the user to report on. That part of the query has to be there for it to
work nicely.
Regards,
Darryl
Darryl,
Your Where Clause uses a date expression on the colum
Hi Ananda,
The query is for reporting purposes and I would like to include a date range
for the user to report on. That part of the query has to be there for it to
work nicely.
Regards,
Darryl
On Fri, Jun 27, 2008 at 4:25 PM, Ananda Kumar <[EMAIL PROTECTED]> wrote:
> Hi Darryl,
> Indexing looks
Hi Darryl,
Indexing looks fine, but what are ur trying to achive using this conditions
"cache.server.tstamp > 0) AND
((date_format(cache.server.tstamp,'%Y-%m-%d') BETWEEN "2008-05-31" AND
"2008-06-10" ))"
On 6/27/08, Darryl Steyn <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> From the traffic.traffic
Hi,
>From the traffic.trafficin table;
UNIQUE KEY `namekey` (`name`,`time`),
KEY `nameindex` (`name`),
KEY `dateindex` (`date`),
KEY `timeindex` (`time`)
>From the cache.server table;
PRIMARY KEY (`tstamp`)
Thanks,
Darryl
On Fri, Jun 27, 2008 at 2:31 PM, Ananda Kumar <[EMAIL PROTECTED]>
what are the columns in namekey index
On 6/27/08, Darryl Steyn <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I am running a query that I feel shouldn't be taking as long as it does to
> execute. The query is as follows;
>
> SELECT traffic.trafficin.bytes_in as bytes_in,
> round(cache.server.serverallkbyt
Wow! 70k files in /tmp. Hell of a mistake :) I hope it doesn't happen often.
Arthur
On 3/17/08, Soenke Ruempler - NorthClick <[EMAIL PROTECTED]> wrote:
>
> Hi Baron,
>
>
> There were about 70k files in /tmp (caused by a mistake). the web
> application on this server had many lookups to tmp and tho
Hi Baron,
Baron Schwartz wrote:
I'd be interested to know what filesystem you're using and how big the
directories are. When you say big, do you mean number of entries in
the directory, or space used?
There were about 70k files in /tmp (caused by a mistake). the web
application on this serv
Hi,
On Mon, Mar 17, 2008 at 12:59 PM, Soenke Ruempler - NorthClick
<[EMAIL PROTECTED]> wrote:
> hi again,
>
> for those that are interested: the problem was indeed the filesystem
> with slow lookups of BIG directories (this had nothing to do with mysql
> but caused much iowait and therefore the
hi again,
for those that are interested: the problem was indeed the filesystem
with slow lookups of BIG directories (this had nothing to do with mysql
but caused much iowait and therefore the mysql process had been heavily
impacted).
Soenke Ruempler - NorthClick wrote:
I assume that those s
One of the list readers (thanks Brent!) suggested using a full text
index on the category names field. Queries dropped from 10-49 seconds
down to 0.0085
Thanks for the emails folks!
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.my
Ian M. Evans wrote:
Bad news: I have a slow query that doesn't appear to be using an index
even if I force it.
Good news: the forehead shaped dent in my desk is really progressing well.
Here's the query:
SELECT DISTINCT poster_data.*
FROM poster_data, poster_prodcat, poster_categories
WHERE p
Bob Pisani wrote:
On another note, you should really change all of those ip address columns
from varchar to int with the ip encoded as 4 bytes. You will save A LOT of
space in both your index and table. And you should reduce the other varchar
columns to the smallest amount possible.
Right, grea
your index and table. And you should reduce the other varchar
columns to the smallest amount possible.
-Original Message-
From: Mark Ponthier [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 14, 2007 10:52 AM
To: mysql@lists.mysql.com
Subject: RE: Slow query involving ORDER BY
Sorry
-+---+---+-+--
---+-+--+---+-------
---+
| 1 | SIMPLE | fsys | range | fs_syslog_1,fs_syslog_2 |
fs_syslog_1 | 5 | NULL | 23664 | Using where; Using temporary;
Using filesort |
| 1 | SIMPLE
680Using where; Using temporary; Using
filesort
1 SIMPLE h ALL
PRIMARY,hosts_1,hosts_2 {null} {null}
{null} 96Using where
Thanks,
Mark Ponthier
From: Ananda Kumar [mailto:[EMAIL
It looks like u dont have index on fsys.src_ip and host.ip, please create
index on these two columns, and also do a explain of ur query, u will know ,
where the problem is.
regards
anandkl
On 8/13/07, Mark Ponthier <[EMAIL PROTECTED]> wrote:
>
> Fellow MySQLers,
>
>
>
> I have a query that perfo
-
From: Kishore Jalleda [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 20, 2007 10:23 AM
To: Brent Baisley
Cc: mysql@lists.mysql.com
Subject: Re: Slow query examining 10 Million Rows, please help !!!
Yes I already did try adding an index on tag, but as you said it didn't
work as its using the pr
Yes I already did try adding an index on tag, but as you said it didn't work
as its using the primary key from the freetags table for the join , anyway I
will try adding an index on "object_type", and see if that helps ...
Thanks
Kishore Jalleda
http://kjalleda.googlepages.com
On 6/20/07, Brent
As Dan mentioned, you're searching on the 'tag' field which has no
index. But since that field is in the table you're joining on, adding
an index on it might not help. You actually searching on the tag_id
in the join field, not the 'tag'.
Add an index on 'object_type' in the freetagged_object
I would try adding an index on the freetags.tag column as you are querying
against that column with
WHERE tag = 'shot'
HTH,
Dan
On 6/19/07, Kishore Jalleda <[EMAIL PROTECTED]> wrote:
Hi everybody,
we have this super slow query which is going through
more
than 10 million ro
Hello, I pinned down the problem to the order by line. If i leave this
away the query is done in 0.05 seconds.
- Mike
Mike van Hoof schreef:
Hello,
i have the following query:
SELECT DISTINCT (
Waarde
) AS bestemming
FROM xml_kenmerk
WHERE Omschrijving = 'Bestemming'
AND IF
TK wrote:
My MySQL server (4.0.20, Linux) was running slowly. I checked the slow queries
log, and found many of these during the problem period:
# Time: 060730 20:44:40
# [EMAIL PROTECTED]: xxx []
# Query_time: 68 Lock_time: 0 Rows_sent: 0 Rows_examined: 2
# administrator command: Quit;
# [
I think you are right about O log N performance when finding matching
records within the index - however, the index doesn't contain all the
data, so the mysql server has to hit the table as stored on disk to find
what you were actually asking for (select *). That becomes time
consuming as it s
Thanks for the response, Dan. I did try ORDER BY on the table. Didn't help
-- I presume because the query is using an index.
Unfortunately, the point of my current development is to show searches
against millions of contacts, so the suggestion about working with other
user_ids isn't too practic
I would expect the problem to be that the further down in the data you
go by using OFFSET, the more records the mysql server has to scan in
order to get to what you want. This will produce a fairly linear
slowdown the further in you go - it just takes time to check through
1,000,000 matching r
Good morning James -
It looks like you have a multi-column index on the startIpNum and
endIpNum columns, but it's not doing you any good, at least not for
this query.
You don't mention how many rows of data you're searching against,
which would give a better idea as to what might be reasonab
2006/4/5, Mechain Marc <[EMAIL PROTECTED]>:
> Hi,
>
> Thank you for your answer.
> But is there a chance to be able to do it one day?
> I think it could be a nice feature.
>
You still have the option to sponsor that feature ;-D
--
MySQL General Mailing List
For list archives: http://lists.mysql.c
Mechain Marc wrote:
Hi,
Thank you for your answer.
But is there a chance to be able to do it one day?
I think it could be a nice feature.
Marc.
That should be asked to one of the devs.
Barry
--
Smileys rule (cX.x)C --o(^_^o)
Dance for me! ^(^_^)o (o^_^)o o(^_^)^ o(^_^o)
--
MySQL General
Hi,
Thank you for your answer.
But is there a chance to be able to do it one day?
I think it could be a nice feature.
Marc.
-Message d'origine-
De : Petr Chardin [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 5 avril 2006 13:06
À : Mechain Marc
Cc : MySQL
Objet : Re: Slow query lo
On Wed, 2006-04-05 at 11:38 +0200, Mechain Marc wrote:
> Is there a way to enable the Slow Query Log on the fly without having to
> restart mysqld
No.
Petr
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
You're still doing a full table scan with REGEX, so you'll never get
it really fast. I was thinking it would be slightly faster because of
less comparisons. It's the full table scan and no use of indexes that
you want to get away from. Without doing that, the only way to get
things faster i
Hi Brent,
Using REGEXP did not really help with the performance. I need to do
whole word matching sowould prefer not to do LIKE '%Vice President%' as
it may return ome negative results.
I separated out some of the text based columns in to a different table
using MYISAM storage engine. Using FU
Hi Green,
Scrubbing out the data is a great suggestion, I will definitely try that
out. I did try out the other option using REGEXP instead of matching
individual conditions. It definitely cleaned up the implementation, but
did not really improve the performance.
-Harini
[EMAIL PROTECTED] wrot
Hello.
> Does MYSQL provide any other option to perform text based searches? Can
> someone suggest any tips for performance tuning the database in this
> scenario?
>
Use the same queries linked with UNION instead of a lot of ORs in WHERE
clause. For example this query can't use index (at
Harini Raghavan <[EMAIL PROTECTED]> wrote on 10/04/2005
11:17:48 AM:
> Hi,
>
> I am using MYSQL 4.1 database in my J2ee application. I am facing
> performance issues with some queries that are being run on text fields.
> Since MYISAM storage engine does not support transactions(and my
> appli
There is a limit, but that is really limited to the hardware you are
running it on. You need to figure out what part of your system is
bottlenecking (disk I/O, RAM, CPU, or network I/O). Perhaps you have
to little RAM and/or your mysql configuration variables are not set
optimally. Too litt
Scott Gifford <[EMAIL PROTECTED]> writes:
[...]
> I think I'm going to take a look at the MySQL source and see if
> there's anything I can tweak to get the effect I want. I'll report
> back my results.
The MySQL source looked a bit too complex for casual hacking, but
here's what I ended up doin
"Jigal van Hemert" <[EMAIL PROTECTED]> writes:
> From: "Scott Gifford"
[...]
>> Right, ALL would be a great plan if it weren't for the LIMIT 1.
>
> The LIMIT 1 will be performed *after* the recordset is sorted :-(
Ah, I think that is the piece I was missing.
[...]
>> I'm a little surprised My
From: "Scott Gifford"
> >> Apparently MySQL's optimizer sees that it can use the primary key for
> >> mirealsource_home_supplemental to do the query, but for some reason
> >> decides not to.
> > This is often the case when the query will probably return more than 30%
of
> > the records in that tabl
Thanks for your response, Jigal. More below...
"Jigal van Hemert" <[EMAIL PROTECTED]> writes:
> From: "Scott Gifford"
[...]
>> Apparently MySQL's optimizer sees that it can use the primary key for
>> mirealsource_home_supplemental to do the query, but for some reason
>> decides not to.
>
> Thi
From: "Scott Gifford"
> mysql> explain
> SELECT mirealsource_homes.mls_num,
> mirealsource_homes_supplemental.listdate,
> mirealsource_images.image1,
> mirealsource_homes_stats.detail_views
> FROM mirealsource_homes,
> mirealsou
In the last episode (Apr 21), Scott Gifford said:
> I'm having a problem with query running very slowly. I run similar
> queries on other tables all the time that perform as expected, and
> this query used to run fine until I removed an explicit LEFT JOIN and
> let the optimizer decide in what ord
Chris,
- Original Message -
From: "Chris Elsworth" <[EMAIL PROTECTED]>
Newsgroups: mailing.database.myodbc
Sent: Saturday, February 12, 2005 2:14 PM
Subject: Re: slow query, how can i imporve it?
On Fri, Feb 11, 2005 at 10:45:46AM -0500, [EMAIL PROTECTED] wrote:
Normall
Chris Elsworth wrote:
On Fri, Feb 11, 2005 at 10:45:46AM -0500, [EMAIL PROTECTED] wrote:
Normally I do not reply to myself but I just realized that in my previous
response I confused COUNT(*) (which is slow for InnoDB because it always
does a table scan to resolve the version lock of each and eve
On Fri, Feb 11, 2005 at 10:45:46AM -0500, [EMAIL PROTECTED] wrote:
> Normally I do not reply to myself but I just realized that in my previous
> response I confused COUNT(*) (which is slow for InnoDB because it always
> does a table scan to resolve the version lock of each and every row) with
Normally I do not reply to myself but I just realized that in my previous
response I confused COUNT(*) (which is slow for InnoDB because it always
does a table scan to resolve the version lock of each and every row) with
SHOW STATUS (which computes table sizes based on the average of 1 random
p
YES, I need a LOT more information. Please provide ALL the information I
asked for in my previous post (especially questions 1, 2, and 3). To
compare with my "automobile" analogy: You told me that your auto is towing
a lot of identical trailers and that if you use a different vehicle on a
diff
HI,
i give some more information about my application.
1) i have 41 million records , and this records are in 10 tables.so
each table contains arrounds 4 million records.
2) Each table contains same columns definition . Total column is 61
and total number of the indexes column is 6.ok
3)now i fir
See below
Shailendra Soni <[EMAIL PROTECTED]> wrote on 02/10/2005 01:43:18
AM:
> Thank ,
> But i can't create multipal index it will not useful for my tabels.
>
> I tryed to set GLOBAL keycache1.key_buffer_size = 128*1024
>
> but it gives error that "unknown system varible ' keycache1' ".
Shailendra Soni <[EMAIL PROTECTED]> wrote on 02/09/2005 08:28:36
AM:
> Hi,
>
> I have a question regarding speed of the query.
> In my application i am useing Mysql 4.0.20a-nt.
> I have 10 tables and each table contains 400 records
> and also 61 columns. I already created indexs on six colum
[snip]
I have a question regarding speed of the query.
In my application i am useing Mysql 4.0.20a-nt.
I have 10 tables and each table contains 400 records
and also 61 columns. I already created indexs on six column which are
important for me.
i fired the query on tables through servlet(thread
Hello.
You have an application which executes prepared statements.
See:
http://dev.mysql.com/doc/mysql/en/c-api-prepared-statements.html
MySQL doesn't log to the slow log a prepared statement. You
can enable general query log which logs prepared statements.
Andrea Gangini <[EMAIL
-Original Message-
From: Max Michaels [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 08, 2004 8:32 AM
To: [EMAIL PROTECTED]
Subject: slow query issues
Hello all,
Recently, I have been seeing some strange behavior from a particular
query on my 4.0.21 mysql server. Here is the quer
What indices do you have?
What does explain say?
Richard Reina wrote:
Anyone know why this query takes so long?
SELECT SUM(l.cost+l.fscc)
FROM orders o, acctg.invoice i
LEFT JOIN acctg.payable p
ON (o.ORD_NO=p.ORD_NO)
WHERE p.ORD_NO IS NULL
AND i.ORD_NO=o.ORD_NO;
Is there something I can do to sp
Use MySQL Query Caching
-Original Message-
From: Aasef Iqbal [mailto:[EMAIL PROTECTED]
Sent: Monday, June 28, 2004 4:46 PM
To: [EMAIL PROTECTED]
Subject: slow query when searching database of over 2 million records
Hi,
I am working on a web project project where one of my pages has to
You should only need to do your second query and use the
SQL_CALC_FOUND_ROWS and a new query using SELECT FOUND_ROWS()to minimize
the number of times you need to _actually_ search your database.
see: http://dev.mysql.com/doc/mysql/en/SELECT.html
and: http://dev.mysql.com/doc/mysql/en/Information
Have you ran an explain plan on the query to identify the execution path?
-Original Message-
From: Aasef Iqbal
To: [EMAIL PROTECTED]
Sent: 6/28/04 6:15 AM
Subject: slow query when searching database of over 2 million records
Hi,
I am working on a web project project where one of my pages
TK wrote:
At 05:02 PM 6/12/2004 +0200, Harald Fuchs wrote:
Other DBMSs like PostgreSQL grok indexes on functional expressions;
MySQL doesn't. Thus your only choice seems to be storing the
uppercased initial in a separate column and putting an index on that
column.
As I indicated, I already tried
At 05:02 PM 6/12/2004 +0200, Harald Fuchs wrote:
>Other DBMSs like PostgreSQL grok indexes on functional expressions;
>MySQL doesn't. Thus your only choice seems to be storing the
>uppercased initial in a separate column and putting an index on that
>column.
As I indicated, I already tried that i
1 - 100 of 140 matches
Mail list logo
