I had a similar problem with a box I was diagnosing for performance issues, it turned out that there was an incorrect / misplaced heading entry within the my.cnf for that server, so MySQL was ignoring all the settings within that section...
For example, if you had the following;
[mysqld]
######################################################
# First, the generic server configuration items
port = 3306
socket = /var/lib/mysql/mysql.sock
datadir = /mysql/data
[client]
#password = your_password
port = 3306
socket = /var/lib/mysql/mysql.sock
key_buffer_size = 256M
table_open_cache = 1024
query_cache_size = 32M
Then the buffer tuning section is ignored as it is within the client
section and not the mysqld
section... Re-arrange the sections, and all works as intended.
Hopefully, it is as simple as this for you!
I'm not really sure why you expected log_queries_not_using_indexes=1
to not log queries that didn't use an index. The idea of the setting is to see which queries are getting run on your server that could be ideal candidates for optimization. For your example:
SELECT id_test from test where id_test != 69
Unless you change the requirements of the query, there's not much you can do. Of course it's faster to do a full scan and return all rows that don't match that id_test
value.
As for ideas on how to approach analysis:
You can set min_examined_row_limit
to a higher value. If, for example, you want to exclude queries that examine less than 5,000 rows, set this variable to 5000. This is useful to reduce the 'noise' in the slow query log.
You can use a tool called pt-query-digest
with the --review
option to review your slow queries. The tool allows you to store your review history so you don't repeat work on the same query during analysis:
It won’t show you queries you’ve already reviewed. A query is considered to be already reviewed if you’ve set a value for the reviewed_by column. (If you want to see queries you’ve already reviewed, use the --report-all option.)
It also has the added benefit of storing a history of the queries that get logged in your slow query. Who wouldn't love historical evidence of improving your queries?
Best Answer
It's all documented here and here.
Relevant part: