Mike, > Ronan, > If your queries are only returning fewer than a hundred rows, and > if every join is indexed, I would have expected it to take only a second or > two at most.
I´m sorry, but I´m not so good in SQL queries, rather joins. If my queries are taking about 15 seconds instead of 1 second. Can it be because some installation or running option? Today I saw another situation: These same SELECT statements are taking about 0.10 seconds... :-/ In other words: When a single execute a certain SELECT, the query returns in 0.10 second, but, when more the 30 users execute a SELECTs simultaneously, the same query returns in about 15 seconds. Would you know what can cause such problem? I think it may be because some MySQL configuration/parameter or a FreeBSD (5.1) limitation, perhaps with threads. > Have you put "Explain" in the front of the query to see if it is > using an index on all the joins? > Your "( ( TO_DAYS( CURDATE() ) - TO_DAYS( f.dtrelease ) <= 180" > won't use an index for f.dtrelease. You need to rewrite it so the column > name is not inside a function and it must be by itself on one side of a > comparison operator. Example: f.dtrelease >= Date_Sub(CurDate(), interval > 180 days). I'm not sure about the syntax but you get the idea. OK, I catched the idea. I´ll do it. Now, about EXPLAIN queries: The queries seems to be returning about 425 rows for the first index the 1 row for the last two indexes. Thank´s, Ronan -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
