Hi there,
yes, I know what query your database is complaining about. It’s a query that increments a counter in the same table is being selected. But rest assured that even if this is in theory considered “unsafe”, the query itself has been designed so that everything will be okay.
Please refer to
http://www.dbasquare.com/2012/04/17/why-a-statement-can-be-unsafe-when-it-uses-limit-clause/
for more information on the problem in general. In my case, I needed an auto_increment field that is not the primary key (visit_id), in order to avoid maintaining and using a separate table just for that.
Thanks for the response – I am actually seeing the message for both the query that updates the visit_id as well as the $insert_new_hit_sql :
$insert_new_hit_sql = "INSERT INTO {$GLOBALS['wpdb']->prefix}slim_stats ( " . implode( ", ", array_keys( $stat ) ) . " )
SELECT " . substr(str_repeat('%s,', count($stat)), 0, -1) . "
FROM DUAL
WHERE NOT EXISTS ( ";
$select_sql = "SELECT id
FROM {$GLOBALS['wpdb']->prefix}slim_stats
WHERE ";
foreach ($stat as $a_key => $a_value){
if ($a_key == 'dt')
$select_sql .= "(TIME_TO_SEC(TIMEDIFF(FROM_UNIXTIME(%s),FROM_UNIXTIME(dt))) < $ignore_interval) AND ";
else
$select_sql .= "$a_key = %s AND ";
}
$select_sql = substr($select_sql, 0, -5);
$insert_new_hit_sql .= $select_sql.' LIMIT 1)';
I can appreciate that it’s not actually an issue for the slimstats code (and really I’m not that worried about being able to restore the slimstats data from the binlog), but the problem is that there are so many log messages being generated by slimstats that I can’t see if there are other more serious issues by looking at my mysql logs.
Is it possible to suppress the warnings for these queries?
Hi there,
according to
http://bugs.mysql.com/bug.php?id=46265
a new option log_warnings has been introduced starting from MySQL 5.1.39, which does exactly that.
log_warnings=0 turns off the warning for the error log
log_warnings=1 turns on the warning for the error log
Cheers,
Camu
I don’t want to disable the warnings globally though – there might be something legitimate that warrants further investigation. I tried messing with the code to set the log_warnings variable at the session scope but the warnings were still showing up in the MySQL log.
I came across this post about changing the binlog format to fix the problem – after switching to row logging it did go away:
http://www.dbasquare.com/kb/warning-the-statement-is-unsafe-because-it-uses-a-limit-clause/
In my my.cnf –
binlog-format = ROW
FWIW, I have seen several recommendations to ORDER BY an indexed column when you are using LIMIT, even if you only expect 0 or 1 results.
thanks!
Thank you for your feedback.
FWIW, I have seen several recommendations to ORDER BY an indexed column when you are using LIMIT, even if you only expect 0 or 1 results.
This may indeed help, I’ll add it to my todo list.
Cheers
Camu