MySQL Slow Query Log – SELECT /!N SQL_NO_CACHE /

backupMySQLmysqldumpperformanceslow-log

Using mysqldumpslow, I can see that the most common entries in a MySQL slow query log are of the following form:

SELECT /*!N SQL_NO_CACHE */ from wp_posts (or wp_comments).

I can't seem to find much information about what this statement means and whether I need to worry about it enough to try and track down where WordPress is creating this SQL.

Best Answer

These types of SELECT are always performed by mysqldumps.

If you look in the slow log for the start time of the query and the time of each of these SELECTs is the same time every day, it is definitely coming from a mysqldump you have crontab'd somewhere.

To eliminate this, you may need to run this

SET GLOBAL slow_query_log = 'OFF';

Then go run the mysqldumps, and then run

SET GLOBAL slow_query_log = 'ON';

This should totally eliminate this type of SELECT from landing needlessly in the slow log.

SUGGESTION #1

I would bump up the following settings in your my.ini

sort_buffer_size=4M
join_buffer_size=4M

This will make some joins and sort stay in memory. Of course, once a JOIN or an ORDER BY needs more than 4M, it will page to disk as a MyISAM table.

If you cannot login as root@localhost, then restart mysql with

C:\> net stop mysql
C:\> net start mysql

If you can login as root@localhost, you do not have to restart mysql to use these settings.

Just run this in the MySQL client:

SET @FourMegs = 1024 * 1024 * 4;
SET GLOBAL sort_buffer_size = @FourMegs;
SET GLOBAL join_buffer_size = @FourMegs;

SUGGESTION #2

Since your Data is on Drive D:, you may have Disk I/O on Drive C:.

Please run this query:

mysql> show variables like 'tmpdir';
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| tmpdir        | C:\Windows\TEMP |
+---------------+-----------------+
1 row in set (0.00 sec)

Since I run mysql on my Desktop with defaults, my temp tables are being written to Drive C:. If Drive D is a better disk than Drive C:, perhaps you can map temp tables to Drive D: by setting tmpdir in my.ini as follows:

tmpdir="D:/DBs/"

You will have to restart mysql since tmpdir is not a dynamic variable.

Give it a Try !!!

UPDATE 2013-11-29 10:09 EST

SUGGESTION #3

Given the fact that MySQL is running in Windows and you cannot touch the queries in the core package, I have two ideas tat must be done together.

IDEA #1 : Move the Database to a Linux Machine

You should be able to

Setup a Linux machine
Install MySQL on the Linux machine
Enable Binary Logging for MySQL in Windows
mysqldump the database to a text SQL file
Load SQL file to MySQL running in Linux
Setup replication from MySQL/Windows to MySQL/Linux

IDEA #2 : Reconfigure Moodle to point to the Linux Machine

Moodle was designed for LAMP in the first place. Just change the config files to point to the Linux machine instead of localhost.

Here is a link to an old Moodle 2.3 doc on setting up MySQL : http://docs.moodle.org/23/en/Installing_Moodle#Create_an_empty_database

I am sure the latest docs are available as well.

What is the Point of Moving the Database to Linux ???

How does this help the temp table situation ???

I would then suggestion setting up a RAM disk as the target folder for your temp tables

Jan 04, 2013 : Is there a MySQL engine or trick to avoid writing so many temp tables to disk?
Dec 17, 2012 : Why does MySQL produce so many temporary MYD files? (Actual instructions)
Nov 30, 2012 : Is it bad to create many mysql temporary tables simultaneously?

Temp table creation will still happen, but it will be written to RAM rather than disk. reducing Disk I/O.

UPDATE 2013-11-29 11:24 EST

SUGGESTION #4

I would suggest revisiting SUGGESTION #2 with a fast RAID-0 disk (32+ GB), configuring it as Drive T: (T for Temp). After installing such a disk, add this to my.ini:

[mysqld]
tmpdir="T:\"

MySQL restart would be required, using

net stop mysql
net start mysql

BTW I said RAID-0 on purpose so that you can get good write performance over a RAID-1, RAID-10. A tmp table disk is not something I would make redundant.

Without optimizing the queries as @RaymondNijland has been commenting on, you cannot reduce the temp table creation count in any way. SUGGESTION #3 and SUGGESTION #4 offer speeding up temp table creation and temp table I/O as the only alternative.

MySQL SELECT query hangs – Opening Tables INNODB

Yes, WordPress uses the default storage engine (which is InnoDB since MySQL 5.5).

I'm not sure I understand the problem. Can you execute the SELECT using the mysql command client? If you can, the problem is in the GUIs you use.

If you cannot (which means that you will receive an error, I think) you should investigate the error log. The only possible problem I can think now is a damaged table (REPAIR TABLE should solve the problem), but the error log should give you the exact answer.