SQL_NO_CACHE
Hi, I was hoping that using SQL_NO_CACHE would help me bypass the query cache, but judging from the below it doesn't. What can I do to avoid the query cache? Thanks. Morten mysql select count(*) from users where email = 'hello'; +--+ | count(*) | +--+ |0 | +--+ 1 row in set (7.22 sec) mysql select count(*) from users where email = 'hello'; +--+ | count(*) | +--+ |0 | +--+ 1 row in set (0.45 sec) mysql select count(*) from users where email = 'hello'; +--+ | count(*) | +--+ |0 | +--+ 1 row in set (0.45 sec) mysql select SQL_NO_CACHE count(*) from users where email = 'hello'; +--+ | count(*) | +--+ |0 | +--+ 1 row in set (0.43 sec) -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: SQL_NO_CACHE
Keep in mind the file system caches too, so it might be working, but the file access is still getting put in memory. You should disable that too if you really want consistent results. In Linux you can dump the file system cache between each query, I have no clue how to do it in windows or other systems, although Unix stuff is probably similar. -Micah On 03/04/2009 07:27 AM, Morten wrote: Hi, I was hoping that using SQL_NO_CACHE would help me bypass the query cache, but judging from the below it doesn't. What can I do to avoid the query cache? Thanks. Morten mysql select count(*) from users where email = 'hello'; +--+ | count(*) | +--+ |0 | +--+ 1 row in set (7.22 sec) mysql select count(*) from users where email = 'hello'; +--+ | count(*) | +--+ |0 | +--+ 1 row in set (0.45 sec) mysql select count(*) from users where email = 'hello'; +--+ | count(*) | +--+ |0 | +--+ 1 row in set (0.45 sec) mysql select SQL_NO_CACHE count(*) from users where email = 'hello'; +--+ | count(*) | +--+ |0 | +--+ 1 row in set (0.43 sec) -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: SQL_NO_CACHE
On Wed, Mar 4, 2009 at 10:27 AM, Morten my.li...@mac.com wrote: Hi, I was hoping that using SQL_NO_CACHE would help me bypass the query cache, but judging from the below it doesn't. You probably just brought the data into the cache and are not hitting the query cache. - Perrin -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: SQL_NO_CACHE
On Wed, 4 Mar 2009, Morten wrote: Hi, I was hoping that using SQL_NO_CACHE would help me bypass the query cache, but judging from the below it doesn't. What can I do to avoid the query cache? Thanks. Morten mysql select count(*) from users where email = 'hello'; +--+ | count(*) | +--+ |0 | +--+ 1 row in set (7.22 sec) mysql select count(*) from users where email = 'hello'; +--+ | count(*) | +--+ |0 | +--+ 1 row in set (0.45 sec) mysql select count(*) from users where email = 'hello'; +--+ | count(*) | +--+ |0 | +--+ 1 row in set (0.45 sec) mysql select SQL_NO_CACHE count(*) from users where email = 'hello'; +--+ | count(*) | +--+ |0 | +--+ 1 row in set (0.43 sec) Hi SQL_NO_CACHE means that the query result is not cached. It does not mean that the cache is not used to answer the query. You may use RESET QUERY CACHE to remove all queries from the cache and then your next query should be slow again. Same effect if you change the table, because this makes all cached queries invalid. But why do you want to do this? Regards, Thomas Spahni -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: SQL_NO_CACHE
On Wed, Mar 4, 2009 at 11:23 AM, Thomas Spahni t...@lawbiz.ch wrote: SQL_NO_CACHE means that the query result is not cached. It does not mean that the cache is not used to answer the query. Oh, right, he's looking for this: SET SESSION query_cache_type=off; - Perrin -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: SQL_NO_CACHE
If SQL_NO_CACHE is specify, the cache will never be used : The Query Cache behaviour is quite simple, it uses the exact given query syntax as a hash to search into the query cache; it means writing 'select' or 'SELECT' is different. It also means adding SQL_NO_CACHE will search in the cache for a different query string, which will never be cached :) Jocelyn Le 04/03/2009 17:39, Perrin Harkins a écrit : On Wed, Mar 4, 2009 at 11:23 AM, Thomas Spahnit...@lawbiz.ch wrote: SQL_NO_CACHE means that the query result is not cached. It does not mean that the cache is not used to answer the query. Oh, right, he's looking for this: SET SESSION query_cache_type=off; - Perrin -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: SQL_NO_CACHE
Thanks for all the suggestions. The caching must be done somewhere else. There is no index on the column and there are about 500.000 rows in the table. A MySQL restart doesn't flush the cache in play, but a full restart of my laptop does (OS X). I may be chasing the wrong problem, but we have seen a query take a lot of time on a production machine and have not been able to pin point why, as the EXPLAIN looks good and the query is responsive enough when I run it manually. I was just trying to reproduce that. The below is after a full restart: mysql SET SESSION query_cache_type=off; Query OK, 0 rows affected (0.00 sec) mysql select SQL_NO_CACHE count(*) from users where email = 'hello' AND 456 = 456; +--+ | count(*) | +--+ |0 | +--+ 1 row in set (28.80 sec) mysql RESET QUERY CACHE; Query OK, 0 rows affected (0.00 sec) mysql select SQL_NO_CACHE count(*) from users where email = 'hello' AND 789 = 789; +--+ | count(*) | +--+ |0 | +--+ 1 row in set (0.44 sec) -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: SQL_NO_CACHE
MySQL Key buffer and OS cache could also have an impact. Have you tried disabling the Key Buffer first ? Jocelyn Le 04/03/2009 18:26, Morten Primdahl a écrit : Thanks for all the suggestions. The caching must be done somewhere else. There is no index on the column and there are about 500.000 rows in the table. A MySQL restart doesn't flush the cache in play, but a full restart of my laptop does (OS X). I may be chasing the wrong problem, but we have seen a query take a lot of time on a production machine and have not been able to pin point why, as the EXPLAIN looks good and the query is responsive enough when I run it manually. I was just trying to reproduce that. The below is after a full restart: mysql SET SESSION query_cache_type=off; Query OK, 0 rows affected (0.00 sec) mysql select SQL_NO_CACHE count(*) from users where email = 'hello' AND 456 = 456; +--+ | count(*) | +--+ |0 | +--+ 1 row in set (28.80 sec) mysql RESET QUERY CACHE; Query OK, 0 rows affected (0.00 sec) mysql select SQL_NO_CACHE count(*) from users where email = 'hello' AND 789 = 789; +--+ | count(*) | +--+ |0 | +--+ 1 row in set (0.44 sec) -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: SQL_NO_CACHE
I did some tests a couple of weeks ago, using using SQL_NO_CACHE and clearing out the OS buffer after each query was enough to give me consistent results that were based on system load rather than cache efficiency. These two are by far the major factors in my experience, although no doubt other system setup can have an effect depending on the query. My goal was to test proper tuning parameters, so I didn't want to alter these artificially. Depends on the test you're doing. jocelyn fournier wrote: MySQL Key buffer and OS cache could also have an impact. Have you tried disabling the Key Buffer first ? Jocelyn Le 04/03/2009 18:26, Morten Primdahl a écrit : Thanks for all the suggestions. The caching must be done somewhere else. There is no index on the column and there are about 500.000 rows in the table. A MySQL restart doesn't flush the cache in play, but a full restart of my laptop does (OS X). I may be chasing the wrong problem, but we have seen a query take a lot of time on a production machine and have not been able to pin point why, as the EXPLAIN looks good and the query is responsive enough when I run it manually. I was just trying to reproduce that. The below is after a full restart: mysql SET SESSION query_cache_type=off; Query OK, 0 rows affected (0.00 sec) mysql select SQL_NO_CACHE count(*) from users where email = 'hello' AND 456 = 456; +--+ | count(*) | +--+ |0 | +--+ 1 row in set (28.80 sec) mysql RESET QUERY CACHE; Query OK, 0 rows affected (0.00 sec) mysql select SQL_NO_CACHE count(*) from users where email = 'hello' AND 789 = 789; +--+ | count(*) | +--+ |0 | +--+ 1 row in set (0.44 sec) -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: SQL_NO_CACHE
Just curious : if there's no index on the column why don't you try to add one ? That's probably why it takes a lot of time on the production machine. Jocelyn Le 04/03/2009 18:26, Morten Primdahl a écrit : Thanks for all the suggestions. The caching must be done somewhere else. There is no index on the column and there are about 500.000 rows in the table. A MySQL restart doesn't flush the cache in play, but a full restart of my laptop does (OS X). I may be chasing the wrong problem, but we have seen a query take a lot of time on a production machine and have not been able to pin point why, as the EXPLAIN looks good and the query is responsive enough when I run it manually. I was just trying to reproduce that. The below is after a full restart: mysql SET SESSION query_cache_type=off; Query OK, 0 rows affected (0.00 sec) mysql select SQL_NO_CACHE count(*) from users where email = 'hello' AND 456 = 456; +--+ | count(*) | +--+ | 0 | +--+ 1 row in set (28.80 sec) mysql RESET QUERY CACHE; Query OK, 0 rows affected (0.00 sec) mysql select SQL_NO_CACHE count(*) from users where email = 'hello' AND 789 = 789; +--+ | count(*) | +--+ | 0 | +--+ 1 row in set (0.44 sec) -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: SQL_NO_CACHE
On Mar 4, 2009, at 8:38 PM, Jocelyn Fournier wrote: Just curious : if there's no index on the column why don't you try to add one ? That's probably why it takes a lot of time on the production machine. Hehe.. I can understand why you ask, I over simplified the question which was wrong of me. I'm just using this specific column because I was playing around while trying to figure out why the first query was slow and the subsequent snappy. Br, Morten -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: SQL_NO_CACHE
On Wed, Mar 4, 2009 at 8:42 PM, Morten Primdahl my.li...@mac.com wrote: around while trying to figure out why the first query was slow and the subsequent snappy. Given that you posted that a MySQL restart does not change anything, but a system restart does, I put my money on the filesystem cache having buffered your data/index file on the second access. -- Celsius is based on water temperature. Fahrenheit is based on alcohol temperature. Ergo, Fahrenheit is better than Celsius. QED. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Does SQL_NO_CACHE work?
I tried : select SQL_NO_CACHE * from table where col1='abc'; which took 800ms the first time it was executed. The second time it was executed it took 0ms. How is that possible if the query is not put into the query cache? Should the query take roughly the same amount of time? TIA Mike MySQL 5.0.24 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Does SQL_NO_CACHE work?
mos wrote: I tried : select SQL_NO_CACHE * from table where col1='abc'; which took 800ms the first time it was executed. The second time it was executed it took 0ms. How is that possible if the query is not put into the query cache? Should the query take roughly the same amount of time? Disk cache. The database table was still in memory. The OS caches a lot of stuff too (file descriptors etc). Try restarting mysql between runs and see if that's more consistent. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Does SQL_NO_CACHE work?
In the last episode (Jan 16), mos said: I tried : select SQL_NO_CACHE * from table where col1='abc'; which took 800ms the first time it was executed. The second time it was executed it took 0ms. How is that possible if the query is not put into the query cache? Should the query take roughly the same amount of time? SQL_NO_CACHE doesn't affect mysql's key cache or the OS's buffer cache. -- Dan Nelson [EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Does SQL_NO_CACHE work?
learnt more from here. On Jan 16, 2008 2:31 PM, Dan Nelson [EMAIL PROTECTED] wrote: In the last episode (Jan 16), mos said: I tried : select SQL_NO_CACHE * from table where col1='abc'; which took 800ms the first time it was executed. The second time it was executed it took 0ms. How is that possible if the query is not put into the query cache? Should the query take roughly the same amount of time? SQL_NO_CACHE doesn't affect mysql's key cache or the OS's buffer cache. -- Dan Nelson [EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- I'm a mysql DBA in china. More about me just visit here: http://yueliangdao0608.cublog.cn
Re: SELECT /*!40001 SQL_NO_CACHE */ * FROM `ROUTEDATA` message
Logg, Connie A. wrote: I am running mysql version 5.0.24 and am seeing this error when running mysqldump. From what I can find on the web, this message is generated by an error in the mysql code. Please correct me if I am wrong. Is this fixed in mysql 5.0.27 ? Thanks, Connie Logg, Network Analyst Stanford Linear Accelerator Center ph: 650-926-2879 Happiness is found along the way, not at the end of the road, and 'IF' is the middle word in life. Connie, this is not an error but a normal SQL statement with a hint: /*!40001 SQL_NO_CACHE */ means that MySQL shall not cache this query and its corresponding result set. That makes perfect sense because one can assume that this statement will be issued just once (by mysqldump) and you wouldn't benefit from caching it. It seems that it takes a long time for this select to complete but there are not many ways to improve the situation. Maybe a faster (and exclusive) dump device? Do you use replication? That can help a lot because then o you can seperate workload (master) and dump activities (slave) o you can silence the slave and dump the slave in a consistent manner because no data changes during the dump. o you can set up more slaves to spread the workload even more From what you told about the completion time of your dump it seems you should re-design your whole MySQL setup. Regards, Frank. -- Dr. Frank Ullrich, DBA Netzwerkadministration Heise Zeitschriften Verlag GmbH Co KG, Helstorfer Str. 7, D-30625 Hannover E-Mail: [EMAIL PROTECTED] Phone: +49 511 5352 587; FAX: +49 511 5352 538 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: More info about 40001 SQL_NO_CACHE
The only time I ever saw a message just hang out in the processlist like that is when I ran a mysqldump and piped it directly to mysql to load data directly from one MySQL server to another. While doing this, the target MySQL system ran out of room on the mounted drive where the datadir was pointing. So the message you seeing I also saw from the source machine. MySQL is a little polite in this matter. I just pauses and waits until there is more room on the available target's datadir to continue send more data to the target. From what you described, you problem sounds very simple yet complicated. Try to find out what software issued that SQL statement and its intended target. - Original Message - From: Connie A. Logg [EMAIL PROTECTED] To: mysql@lists.mysql.com Sent: Wednesday, November 15, 2006 11:18:31 PM GMT-0500 US/Eastern Subject: More info about 40001 SQL_NO_CACHE This showed up in 'show processlist' and it had had an active time of about 4 days. Numerous other inquiries were hung behind it, although the other inquiries completed eventually...but they were so slow as to backup the data base entry code and extraditions for the analysis by several hours. Can someone please enlightn me on this problem? Like I mentioned, the web search entries indicated that this hanging was a mysql problem. I have upgraded to 5.0.27. But I will not know until tomorrow if the mysqldump that I do tonight works. -Original Message- From: Logg, Connie A. [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 15, 2006 11:41 AM To: mysql@lists.mysql.com Subject: SELECT /*!40001 SQL_NO_CACHE */ * FROM `ROUTEDATA` message I am running mysql version 5.0.24 and am seeing this error when running mysqldump. From what I can find on the web, this message is generated by an error in the mysql code. Please correct me if I am wrong. Is this fixed in mysql 5.0.27 ? Thanks, Connie Logg, Network Analyst Stanford Linear Accelerator Center ph: 650-926-2879 Happiness is found along the way, not at the end of the road, and 'IF' is the middle word in life. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: More info about 40001 SQL_NO_CACHE
Thank you...All I was doing was a musqldump of the tables in my data base to files, one file for each table. Yesterday I upgraded to mysql 5.0.27, so I will watch it for a while. It just started happening last Saturday night, and I had been running the system for a few months. Thanks for you response. Connie Logg, Network Analyst Stanford Linear Accelerator Center ph: 650-926-2879 Happiness is found along the way, not at the end of the road, and 'IF' is the middle word in life. From: Howard Hart [mailto:[EMAIL PROTECTED] Sent: Thursday, November 16, 2006 8:41 AM To: Logg, Connie A. Subject: RE: More info about 40001 SQL_NO_CACHE Looks like this may have been fixed in 5.0.25 or above, so if it's the same bug, you're good to go. http://bugs.mysql.com/bug.php?id=21288 Howard -Original Message- From: Logg, Connie A. [mailto:[EMAIL PROTECTED] Sent: Wed 11/15/2006 8:18 PM To: mysql@lists.mysql.com Subject: More info about 40001 SQL_NO_CACHE This showed up in 'show processlist' and it had had an active time of about 4 days. Numerous other inquiries were hung behind it, although the other inquiries completed eventually...but they were so slow as to backup the data base entry code and extraditions for the analysis by several hours. Can someone please enlightn me on this problem? Like I mentioned, the web search entries indicated that this hanging was a mysql problem. I have upgraded to 5.0.27. But I will not know until tomorrow if the mysqldump that I do tonight works. -Original Message- From: Logg, Connie A. [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 15, 2006 11:41 AM To: mysql@lists.mysql.com Subject: SELECT /*!40001 SQL_NO_CACHE */ * FROM `ROUTEDATA` message I am running mysql version 5.0.24 and am seeing this error when running mysqldump. From what I can find on the web, this message is generated by an error in the mysql code. Please correct me if I am wrong. Is this fixed in mysql 5.0.27 ? Thanks, Connie Logg, Network Analyst Stanford Linear Accelerator Center ph: 650-926-2879 Happiness is found along the way, not at the end of the road, and 'IF' is the middle word in life. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
SELECT /*!40001 SQL_NO_CACHE */ * FROM `ROUTEDATA` message
I am running mysql version 5.0.24 and am seeing this error when running mysqldump. From what I can find on the web, this message is generated by an error in the mysql code. Please correct me if I am wrong. Is this fixed in mysql 5.0.27 ? Thanks, Connie Logg, Network Analyst Stanford Linear Accelerator Center ph: 650-926-2879 Happiness is found along the way, not at the end of the road, and 'IF' is the middle word in life. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
More info about 40001 SQL_NO_CACHE
This showed up in 'show processlist' and it had had an active time of about 4 days. Numerous other inquiries were hung behind it, although the other inquiries completed eventually...but they were so slow as to backup the data base entry code and extraditions for the analysis by several hours. Can someone please enlightn me on this problem? Like I mentioned, the web search entries indicated that this hanging was a mysql problem. I have upgraded to 5.0.27. But I will not know until tomorrow if the mysqldump that I do tonight works. -Original Message- From: Logg, Connie A. [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 15, 2006 11:41 AM To: mysql@lists.mysql.com Subject: SELECT /*!40001 SQL_NO_CACHE */ * FROM `ROUTEDATA` message I am running mysql version 5.0.24 and am seeing this error when running mysqldump. From what I can find on the web, this message is generated by an error in the mysql code. Please correct me if I am wrong. Is this fixed in mysql 5.0.27 ? Thanks, Connie Logg, Network Analyst Stanford Linear Accelerator Center ph: 650-926-2879 Happiness is found along the way, not at the end of the road, and 'IF' is the middle word in life. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
sql_no_cache
I am trying to turn of the query caching for select queries I am testing as I would like to rerun the as if they were the first hit. The query-cache-type = 1. I am suspicious b/c I run a query and it takes 12 seconds. I then run the same query with no changes and it takes .17 seconds. Another piece to this puzzle might be that when I issued the FLUSH QUERY CACHE command and then reran the query and it still took a very short time. Since this is a devel server and I am the only one around I don't think there are any other obvious things going on. Mytop is clear of processes. Am I missing something? Boyd E. Hemphill -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: sql_no_cache
One possibility is that the OS has the portion of disk that the row is stored in cached in memory via its normal disk caching after the first execution. Another possibility is that the key for the table is in mysql's key_buffer after the first execution. If you are using innodb then it might be cached in the buffer_pool. There are quite a few levels of caching going on at the mysql and os level and they all need to be considered. John A. McCaskey -Original Message- From: Boyd E. Hemphill [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 27, 2004 12:41 PM To: [EMAIL PROTECTED] Subject: sql_no_cache I am trying to turn of the query caching for select queries I am testing as I would like to rerun the as if they were the first hit. The query-cache-type = 1. I am suspicious b/c I run a query and it takes 12 seconds. I then run the same query with no changes and it takes .17 seconds. Another piece to this puzzle might be that when I issued the FLUSH QUERY CACHE command and then reran the query and it still took a very short time. Since this is a devel server and I am the only one around I don't think there are any other obvious things going on. Mytop is clear of processes. Am I missing something? Boyd E. Hemphill -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: sql_no_cache
In an update to the last, I think I have the issue in hand: I am using TOAD 1.0 and it seems to be doing some sort of caching itself or going directly to the query cache. I issued the identical query and it would return the result immediately. Checking Mytop (did I mention that JZ rules?) the query was still running on the server. Thus it appears as if TOAD either cached the result or was going to the query cache itself. Best Regards, Boyd E. Hemphill [EMAIL PROTECTED] Triand, Inc. www.triand.com O: (512) 248-2287 M: (713) 252-4688 -Original Message- From: Boyd E. Hemphill [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 27, 2004 1:41 PM To: [EMAIL PROTECTED] Subject: sql_no_cache I am trying to turn of the query caching for select queries I am testing as I would like to rerun the as if they were the first hit. The query-cache-type = 1. I am suspicious b/c I run a query and it takes 12 seconds. I then run the same query with no changes and it takes .17 seconds. Another piece to this puzzle might be that when I issued the FLUSH QUERY CACHE command and then reran the query and it still took a very short time. Since this is a devel server and I am the only one around I don't think there are any other obvious things going on. Mytop is clear of processes. Am I missing something? Boyd E. Hemphill -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
SQL_NO_CACHE
Hi, I am trying to do some performance analysis by trying different indexing schemes and testing how long it takes. To get consistent results, I would like to use something like SQL_NO_CACHE. However, the mysqld version that I have installed does not seem to support it..its 4.0.16 Could anyone suggest any other way of achieving this. Thanks, Priyanka _ Get a FREE online virus check for your PC here, from McAfee. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: SQL_NO_CACHE
On Tue, 13 Jan 2004, Priyanka Gupta wrote: Hi, I am trying to do some performance analysis by trying different indexing schemes and testing how long it takes. To get consistent results, I would like to use something like SQL_NO_CACHE. However, the mysqld version that I have installed does not seem to support it..its 4.0.16 Could anyone suggest any other way of achieving this. What does SHOW VARIABLES LIKE 'query_cache_type'; show? -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
