Re: innodb_lock_wait_timeout
- Original Message - From: Markus Falb markus.f...@fasel.at With a low timeout the connection will be terminated sooner, but if the application retries another connection is taken. I could have raised the timeout with the same effect on the db side (1 process is waiting) but maybe more performant (no new connection necessary) and with simpler logic on the application side (no retry logic) Maybe you imply that there is some kind of sleep before the retry, so that other statements could be fulfilled? No, a *lock* timeout does not kill your connection, it merely rolls back the active transaction. You do not need another connection, as you haven't lost the current one. You can of course close the connection and sleep for a moment to allow other clients time to do stuff, too; but then you lose any local session state you had (like sql variables that you may have set). Besides, if your server is so busy that you can't spare the time for a retry on a failed connection, it may be time to start looking for ways to extend capacity, too. -- Linux Bier Wanderung 2012, now also available in Belgium! August, 12 to 19, Diksmuide, Belgium - http://lbw2012.tuxera.be -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Can I measure the use of index?
Afternoon Somebody knows how can I log or measure the index use ? Thanks Carlos
Re: Can I measure the use of index?
Am 15.10.2012 17:24, schrieb Carlos Eduardo Caldi: Afternoon Somebody knows how can I log or measure the index use ? explain select whatever from table where bla=value signature.asc Description: OpenPGP digital signature
RE: Can I measure the use of index?
I want to count how many time one index was used during a day, do you now how to log it to count? Date: Mon, 15 Oct 2012 17:27:54 +0200 From: h.rei...@thelounge.net To: mysql@lists.mysql.com Subject: Re: Can I measure the use of index? Am 15.10.2012 17:24, schrieb Carlos Eduardo Caldi: Afternoon Somebody knows how can I log or measure the index use ? explain select whatever from table where bla=value
Re: Can I measure the use of index?
On Mon, Oct 15, 2012 at 11:24 AM, Carlos Eduardo Caldi ce_ca...@hotmail.com wrote: Somebody knows how can I log or measure the index use ? http://www.percona.com/doc/percona-toolkit/2.1/pt-index-usage.html - Perrin -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: innodb_lock_wait_timeout
- Original Message - From: trimurthy skd.trimur...@gmail.com hi sir even i also have a doubt regarding the connections. suppose if there is an existing connection to the server with the user name xxx and password if i send another request with the same user name and password then what will happen Please always ask questions on the list. I'm not all-knowing, and it is often that others have better answers or different experiences. As to your question, MySQL's default behaviour is to allow multiple connections for the same user; so your second request will also execute just fine - within the limits of max_connections, table locks et cetera, of course. -- -- -- What's tiny and yellow and very, very dangerous? A canary with the root password. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
mysql logs query with indexes used to the slow-log and not logging if there is index in reverse order
Hi, list.
Sorry for the long subject, but I'm really interested in solving this and
need a help:
I've got a table:
mysql show create table send_sms_test;
+---+---+
| Table | Create
Table
|
+---+---+
| send_sms_test | CREATE TABLE `send_sms_test` (
`sql_id` bigint(20) NOT NULL AUTO_INCREMENT,
`momt` enum('MO','MT') DEFAULT NULL,
`sender` varchar(20) DEFAULT NULL,
`receiver` varchar(20) DEFAULT NULL,
`udhdata` blob,
`msgdata` text,
`time` bigint(20) NOT NULL,
`smsc_id` varchar(255) DEFAULT 'main',
`service` varchar(255) DEFAULT NULL,
`account` varchar(255) DEFAULT NULL,
`id` bigint(20) DEFAULT NULL,
`sms_type` tinyint(1) DEFAULT '2',
`mclass` bigint(20) DEFAULT NULL,
`mwi` bigint(20) DEFAULT NULL,
`coding` bigint(20) DEFAULT NULL,
`compress` bigint(20) DEFAULT NULL,
`validity` bigint(20) DEFAULT NULL,
`deferred` bigint(20) DEFAULT NULL,
`dlr_mask` bigint(20) DEFAULT NULL,
`dlr_url` varchar(255) DEFAULT NULL,
`pid` bigint(20) DEFAULT NULL,
`alt_dcs` bigint(20) DEFAULT NULL,
`rpi` bigint(20) DEFAULT NULL,
`charset` varchar(255) DEFAULT NULL,
`boxc_id` varchar(255) DEFAULT NULL,
`binfo` varchar(255) DEFAULT NULL,
`meta_data` text,
`task_id` bigint(20) DEFAULT NULL,
`msgid` bigint(20) DEFAULT NULL,
`priority` int(3) unsigned NOT NULL DEFAULT '500',
PRIMARY KEY (`sql_id`),
KEY `task_id` (`task_id`),
KEY `receiver` (`receiver`),
KEY `msgid` (`msgid`),
KEY `priority_time` (`priority`,`time`)
) ENGINE=InnoDB AUTO_INCREMENT=7806318 DEFAULT CHARSET=utf8
Slow-queries turned on with an option:
| log_queries_not_using_indexes | ON|
mysqld --version
mysqld Ver 5.1.65-rel14.0 for debian-linux-gnu on x86_64 ((Percona Server
(GPL), 14.0, Revision 475))
If I check with EXPLAIN MySQL says it would use the index:
mysql *desc select * from send_sms_test where time=UNIX_TIMESTAMP(NOW())
order by priority limit 0,11;*
++-+---+---+---+---+-+--+--+-+
| id | select_type | table | type | possible_keys | key
| key_len | ref | rows | Extra |
++-+---+---+---+---+-+--+--+-+
| 1
Re: mysql logs query with indexes used to the slow-log and not logging if there is index in reverse order
Hi, I've just checked on MySQL-5.5.28
it acts absolutely same.
I need to use (priority,time) KEY instead of (time, priority) because query
results in better performance.
With first key used there is no need to sort at all, whilst if using latter:
mysql *desc select * from send_sms_test FORCE INDEX (time_priority) where
time=UNIX_TIMESTAMP(NOW()) order by priority limit 0,13;*
++-+---+---+---+---+-+--+---+-+
| id | select_type | table | type | possible_keys | key
| key_len | ref | rows | Extra |
++-+---+---+---+---+-+--+---+-+
| 1 | SIMPLE | send_sms_test | range | time_priority | time_priority
| 8 | NULL | 73920 | Using where; *Using filesort* |
++-+---+---+---+---+-+--+---+-+
1 row in set (0.00 sec)
It uses filesort and results in a worser performance...
Any suggestions ? Should I submit a bug?
2012/10/16 spameden spame...@gmail.com
Hi, list.
Sorry for the long subject, but I'm really interested in solving this and
need a help:
I've got a table:
mysql show create table send_sms_test;
+---+---+
| Table | Create
Table
|
+---+---+
| send_sms_test | CREATE TABLE `send_sms_test` (
`sql_id` bigint(20) NOT NULL AUTO_INCREMENT,
`momt` enum('MO','MT') DEFAULT NULL,
`sender` varchar(20) DEFAULT NULL,
`receiver` varchar(20) DEFAULT NULL,
`udhdata` blob,
`msgdata` text,
`time` bigint(20) NOT NULL,
`smsc_id` varchar(255) DEFAULT 'main',
`service` varchar(255) DEFAULT NULL,
`account` varchar(255) DEFAULT NULL,
`id` bigint(20) DEFAULT NULL,
`sms_type` tinyint(1) DEFAULT '2',
`mclass` bigint(20) DEFAULT NULL,
`mwi` bigint(20) DEFAULT NULL,
`coding` bigint(20) DEFAULT NULL,
`compress` bigint(20) DEFAULT NULL,
`validity` bigint(20) DEFAULT NULL,
`deferred` bigint(20) DEFAULT NULL,
`dlr_mask` bigint(20) DEFAULT NULL,
`dlr_url` varchar(255) DEFAULT NULL,
`pid` bigint(20) DEFAULT NULL,
`alt_dcs`
RE: mysql logs query with indexes used to the slow-log and not logging if there is index in reverse order
* Rows = 11 / 22 -- don't take the numbers too seriously; they are crude
approximations based on estimated cardinality.
* The 11 comes from the LIMIT -- therefore useless in judging the efficiency.
(The 22 may be 2*11; I don't know.)
* Run the EXPLAINs without LIMIT -- that will avoid the bogus 11/22.
* If the CREATE INDEX took only 0.67 sec, I surmise that you have very few rows
in the table?? So this discussion is not necessarily valid in general cases.
* What percentage of time values meet the WHERE? This has a big impact on the
choice of explain plan and performance.
* Set long_query_time = 0; to get it in the slowlog even if it is fast. Then
look at the various extra values (such as filesort, on disk, temp table used,
etc).
* Do this (with each index):
SHOW SESSION STATUS LIKE 'Handler_read%';
SELECT ... FORCE INDEX(...) ...;
SHOW SESSION STATUS LIKE 'Handler_read%';
Then take the diffs of the handler counts. This will give you a pretty
detailed idea of what is going on; better than the SlowLog.
* INT(3) is not a 3-digit integer, it is a full 32-bit integer (4 bytes).
Perhaps you should have SMALLINT UNSIGNED (2 bytes).
* BIGINT takes 8 bytes -- usually over-sized.
-Original Message-
From: spameden [mailto:spame...@gmail.com]
Sent: Monday, October 15, 2012 1:42 PM
To: mysql@lists.mysql.com
Subject: mysql logs query with indexes used to the slow-log and not
logging if there is index in reverse order
Hi, list.
Sorry for the long subject, but I'm really interested in solving this
and need a help:
I've got a table:
mysql show create table send_sms_test;
+---+--
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---+
| Table | Create
Table
|
+---+--
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---+
| send_sms_test | CREATE TABLE `send_sms_test` (
`sql_id` bigint(20) NOT NULL AUTO_INCREMENT,
`momt` enum('MO','MT') DEFAULT NULL,
`sender` varchar(20) DEFAULT NULL,
`receiver` varchar(20) DEFAULT NULL,
`udhdata` blob,
`msgdata` text,
`time` bigint(20) NOT NULL,
`smsc_id` varchar(255) DEFAULT 'main',
`service` varchar(255) DEFAULT NULL,
`account` varchar(255) DEFAULT NULL,
`id` bigint(20) DEFAULT NULL,
`sms_type` tinyint(1) DEFAULT '2',
Re: mysql logs query with indexes used to the slow-log and not logging if there is index in reverse order
Sorry, my previous e-mail was a test on MySQL-5.5.28 on an empty table. Here is the MySQL-5.1 Percona testing table: mysql select count(*) from send_sms_test; +--+ | count(*) | +--+ | 143879 | +--+ 1 row in set (0.03 sec) Without LIMIT: mysql desc select * from send_sms_test FORCE INDEX (time_priority) where time=UNIX_TIMESTAMP(NOW()) order by priority; ++-+---+---+---+---+-+--+---+-+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | ++-+---+---+---+---+-+--+---+-+ | 1 | SIMPLE | send_sms_test | range | time_priority | time_priority | 8 | NULL | 73920 | Using where; Using filesort | ++-+---+---+---+---+-+--+---+-+ 1 row in set (0.00 sec) mysql desc select * from send_sms_test FORCE INDEX (priority_time) where time=UNIX_TIMESTAMP(NOW()) order by priority; ++-+---+---+---+---+-+--++-+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | ++-+---+---+---+---+-+--++-+ | 1 | SIMPLE | send_sms_test | index | NULL | priority_time | 12 | NULL | 147840 | Using where | ++-+---+---+---+---+-+--++-+ 1 row in set (0.00 sec) But I actually need to use LIMIT, because client uses this to limit the number of records returned to process. mysql select * from send_sms_test FORCE INDEX (priority_time) where time=UNIX_TIMESTAMP(NOW()) order by priority LIMIT 0,100; 100 rows in set (0.00 sec) mysql show profile; ++--+ | Status | Duration | ++--+ | starting | 0.53 | | Opening tables | 0.09 | | System lock| 0.05 | | Table lock | 0.04 | | init | 0.37 | | optimizing | 0.05 | | statistics | 0.07 | | preparing | 0.05 | | executing | 0.01 | | Sorting result | 0.03 | | Sending data | 0.000856 | | end| 0.03 | | query end | 0.01 | | freeing items | 0.15 | | logging slow query | 0.01 | | logging slow query | 0.47 | | cleaning up| 0.02 | ++--+ 17 rows in set (0.00 sec) mysql select * from send_sms_test FORCE INDEX (time_priority) where time=UNIX_TIMESTAMP(NOW()) order by priority LIMIT 0,100; 100 rows in set (0.08 sec) mysql show profile; ++--+ | Status | Duration | ++--+ | starting | 0.48 | | Opening tables | 0.09 | | System lock| 0.02 | | Table lock | 0.04 | | init | 0.47 | | optimizing | 0.06 | | statistics | 0.43 | | preparing | 0.18 | | executing | 0.01 | | Sorting result | 0.076725 | | Sending data | 0.001406 | | end| 0.03 | | query end | 0.01 | | freeing items | 0.12 | | logging slow query | 0.01 | | cleaning up| 0.02 | ++--+ 16 rows in set (0.00 sec) As you can see latter query takes more time, because it's using filesort as well. Now, handler: mysql SHOW SESSION STATUS LIKE 'Handler_read%';select * from send_sms_test FORCE INDEX (priority_time) where time=UNIX_TIMESTAMP(NOW()) order by priority LIMIT 0,100;SHOW SESSION STATUS LIKE 'Handler_read%'; +---++ | Variable_name | Value | +---++ | Handler_read_first| 18 | | Handler_read_key | 244| | Handler_read_next | 719969 | | Handler_read_prev | 0 | | Handler_read_rnd | 226| | Handler_read_rnd_next | 223| +---++ 6 rows in set (0.00 sec) 100 rows in set (0.00 sec) +---++ | Variable_name | Value | +---++ | Handler_read_first| 19 | | Handler_read_key | 245| | Handler_read_next | 720068 | | Handler_read_prev | 0 | | Handler_read_rnd | 226| | Handler_read_rnd_next | 223| +---++ 6 rows in set (0.00 sec) mysql SHOW SESSION STATUS LIKE 'Handler_read%'; +---++ | Variable_name | Value | +---++ | Handler_read_first| 17 | | Handler_read_key | 143|
Re: mysql logs query with indexes used to the slow-log and not logging if there is index in reverse order
Sorry, forgot to say: mysql show variables like 'long_query_time%'; +-+---+ | Variable_name | Value | +-+---+ | long_query_time | 10.00 | +-+---+ 1 row in set (0.00 sec) It's getting in the log only due: mysql show variables like '%indexes%'; +---+---+ | Variable_name | Value | +---+---+ | log_queries_not_using_indexes | ON| +---+---+ 1 row in set (0.00 sec) If I turn it off - it's all fine My initial question was why MySQL logs it in the slow log if the query uses an INDEX? And why it's not logging if I create an INDEX (time, priority) (but in the query there is FORCE INDEX (priority,time) specified, so MySQL shouldn't use newly created INDEX (time, priority) at all). 2012/10/16 spameden spame...@gmail.com Sorry, my previous e-mail was a test on MySQL-5.5.28 on an empty table. Here is the MySQL-5.1 Percona testing table: mysql select count(*) from send_sms_test; +--+ | count(*) | +--+ | 143879 | +--+ 1 row in set (0.03 sec) Without LIMIT: mysql desc select * from send_sms_test FORCE INDEX (time_priority) where time=UNIX_TIMESTAMP(NOW()) order by priority; ++-+---+---+---+---+-+--+---+-+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | ++-+---+---+---+---+-+--+---+-+ | 1 | SIMPLE | send_sms_test | range | time_priority | time_priority | 8 | NULL | 73920 | Using where; Using filesort | ++-+---+---+---+---+-+--+---+-+ 1 row in set (0.00 sec) mysql desc select * from send_sms_test FORCE INDEX (priority_time) where time=UNIX_TIMESTAMP(NOW()) order by priority; ++-+---+---+---+---+-+--++-+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | ++-+---+---+---+---+-+--++-+ | 1 | SIMPLE | send_sms_test | index | NULL | priority_time | 12 | NULL | 147840 | Using where | ++-+---+---+---+---+-+--++-+ 1 row in set (0.00 sec) But I actually need to use LIMIT, because client uses this to limit the number of records returned to process. mysql select * from send_sms_test FORCE INDEX (priority_time) where time=UNIX_TIMESTAMP(NOW()) order by priority LIMIT 0,100; 100 rows in set (0.00 sec) mysql show profile; ++--+ | Status | Duration | ++--+ | starting | 0.53 | | Opening tables | 0.09 | | System lock| 0.05 | | Table lock | 0.04 | | init | 0.37 | | optimizing | 0.05 | | statistics | 0.07 | | preparing | 0.05 | | executing | 0.01 | | Sorting result | 0.03 | | Sending data | 0.000856 | | end| 0.03 | | query end | 0.01 | | freeing items | 0.15 | | logging slow query | 0.01 | | logging slow query | 0.47 | | cleaning up| 0.02 | ++--+ 17 rows in set (0.00 sec) mysql select * from send_sms_test FORCE INDEX (time_priority) where time=UNIX_TIMESTAMP(NOW()) order by priority LIMIT 0,100; 100 rows in set (0.08 sec) mysql show profile; ++--+ | Status | Duration | ++--+ | starting | 0.48 | | Opening tables | 0.09 | | System lock| 0.02 | | Table lock | 0.04 | | init | 0.47 | | optimizing | 0.06 | | statistics | 0.43 | | preparing | 0.18 | | executing | 0.01 | | Sorting result | 0.076725 | | Sending data | 0.001406 | | end| 0.03 | | query end | 0.01 | | freeing items | 0.12 | | logging slow query | 0.01 | | cleaning up| 0.02 | ++--+ 16 rows in set (0.00 sec) As you can see latter query takes more time, because it's using filesort as well. Now, handler: mysql SHOW SESSION STATUS LIKE 'Handler_read%';select * from send_sms_test FORCE INDEX (priority_time) where time=UNIX_TIMESTAMP(NOW()) order by priority LIMIT 0,100;SHOW SESSION STATUS LIKE
RE: mysql logs query with indexes used to the slow-log and not logging if there is index in reverse order
I don't fully understand Handler numbers, either. But note the vast difference in Handler_read_next, as if the second test had to read (sequentially scan) a lot more stuff (in the index or the data). Summary: INDEX(time, priority) -- slower; bigger Handler numbers; shorter key_len; filesort INDEX(priority, time) -- faster; smaller; seems to use both keys of the index (key_len=12); avoids filesort (because INDEX(priority, ...) agrees with ORDER BY priority). The Optimizer has (at some level) two choices: * Start with the WHERE * Start with the ORDER BY Since the ORDER BY matches one of the indexes, it can avoid the sort and stop with the LIMIT. However, if most of the rows failed the WHERE clause, this could be the wrong choice. That is, it is hard for the optimizer to get a query like this right every time. To see what I mean, flip the inequality in WHERE time = ... around; I think the results will be disappointing. If you had more than a million rows, I would bring up PARTITIONing as a assist to this 2-dimensional type of problem. From: spameden [mailto:spame...@gmail.com] Sent: Monday, October 15, 2012 3:23 PM To: Rick James Cc: mysql@lists.mysql.com Subject: Re: mysql logs query with indexes used to the slow-log and not logging if there is index in reverse order Sorry, my previous e-mail was a test on MySQL-5.5.28 on an empty table. Here is the MySQL-5.1 Percona testing table: mysql select count(*) from send_sms_test; +--+ | count(*) | +--+ | 143879 | +--+ 1 row in set (0.03 sec) Without LIMIT: mysql desc select * from send_sms_test FORCE INDEX (time_priority) where time=UNIX_TIMESTAMP(NOW()) order by priority; ++-+---+---+---+---+-+--+---+-+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | ++-+---+---+---+---+-+--+---+-+ | 1 | SIMPLE | send_sms_test | range | time_priority | time_priority | 8 | NULL | 73920 | Using where; Using filesort | ++-+---+---+---+---+-+--+---+-+ 1 row in set (0.00 sec) mysql desc select * from send_sms_test FORCE INDEX (priority_time) where time=UNIX_TIMESTAMP(NOW()) order by priority; ++-+---+---+---+---+-+--++-+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | ++-+---+---+---+---+-+--++-+ | 1 | SIMPLE | send_sms_test | index | NULL | priority_time | 12 | NULL | 147840 | Using where | ++-+---+---+---+---+-+--++-+ 1 row in set (0.00 sec) But I actually need to use LIMIT, because client uses this to limit the number of records returned to process. mysql select * from send_sms_test FORCE INDEX (priority_time) where time=UNIX_TIMESTAMP(NOW()) order by priority LIMIT 0,100; 100 rows in set (0.00 sec) mysql show profile; ++--+ | Status | Duration | ++--+ | starting | 0.53 | | Opening tables | 0.09 | | System lock| 0.05 | | Table lock | 0.04 | | init | 0.37 | | optimizing | 0.05 | | statistics | 0.07 | | preparing | 0.05 | | executing | 0.01 | | Sorting result | 0.03 | | Sending data | 0.000856 | | end| 0.03 | | query end | 0.01 | | freeing items | 0.15 | | logging slow query | 0.01 | | logging slow query | 0.47 | | cleaning up| 0.02 | ++--+ 17 rows in set (0.00 sec) mysql select * from send_sms_test FORCE INDEX (time_priority) where time=UNIX_TIMESTAMP(NOW()) order by priority LIMIT 0,100; 100 rows in set (0.08 sec) mysql show profile; ++--+ | Status | Duration | ++--+ | starting | 0.48 | | Opening tables | 0.09 | | System lock| 0.02 | | Table lock | 0.04 | | init | 0.47 | | optimizing | 0.06 | | statistics | 0.43 | | preparing | 0.18 | | executing | 0.01 | | Sorting result | 0.076725 | | Sending data | 0.001406 | | end| 0.03 | | query end | 0.01 | | freeing items | 0.12 | | logging slow query | 0.01 | | cleaning up| 0.02 |
RE: mysql logs query with indexes used to the slow-log and not logging if there is index in reverse order
Ø My initial question was why MySQL logs it in the slow log if the query uses an INDEX? That _may_ be worth a bug report. A _possible_ answer... EXPLAIN presents what the optimizer is in the mood for at that moment. It does not necessarily reflect what it was in the mood for when it ran the query. When timing things, run them twice (and be sure not to hit the Query cache). The first time freshens the cache (buffer_pool, etc); the second time gives you a 'reproducible' time. I believe (without proof) that the cache contents can affect the optimizer's choice. From: spameden [mailto:spame...@gmail.com] Sent: Monday, October 15, 2012 3:29 PM To: Rick James Cc: mysql@lists.mysql.com Subject: Re: mysql logs query with indexes used to the slow-log and not logging if there is index in reverse order Sorry, forgot to say: mysql show variables like 'long_query_time%'; +-+---+ | Variable_name | Value | +-+---+ | long_query_time | 10.00 | +-+---+ 1 row in set (0.00 sec) It's getting in the log only due: mysql show variables like '%indexes%'; +---+---+ | Variable_name | Value | +---+---+ | log_queries_not_using_indexes | ON| +---+---+ 1 row in set (0.00 sec) If I turn it off - it's all fine My initial question was why MySQL logs it in the slow log if the query uses an INDEX? And why it's not logging if I create an INDEX (time, priority) (but in the query there is FORCE INDEX (priority,time) specified, so MySQL shouldn't use newly created INDEX (time, priority) at all). 2012/10/16 spameden spame...@gmail.commailto:spame...@gmail.com Sorry, my previous e-mail was a test on MySQL-5.5.28 on an empty table. Here is the MySQL-5.1 Percona testing table: mysql select count(*) from send_sms_test; +--+ | count(*) | +--+ | 143879 | +--+ 1 row in set (0.03 sec) Without LIMIT: mysql desc select * from send_sms_test FORCE INDEX (time_priority) where time=UNIX_TIMESTAMP(NOW()) order by priority; ++-+---+---+---+---+-+--+---+-+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | ++-+---+---+---+---+-+--+---+-+ | 1 | SIMPLE | send_sms_test | range | time_priority | time_priority | 8 | NULL | 73920 | Using where; Using filesort | ++-+---+---+---+---+-+--+---+-+ 1 row in set (0.00 sec) mysql desc select * from send_sms_test FORCE INDEX (priority_time) where time=UNIX_TIMESTAMP(NOW()) order by priority; ++-+---+---+---+---+-+--++-+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | ++-+---+---+---+---+-+--++-+ | 1 | SIMPLE | send_sms_test | index | NULL | priority_time | 12 | NULL | 147840 | Using where | ++-+---+---+---+---+-+--++-+ 1 row in set (0.00 sec) But I actually need to use LIMIT, because client uses this to limit the number of records returned to process. mysql select * from send_sms_test FORCE INDEX (priority_time) where time=UNIX_TIMESTAMP(NOW()) order by priority LIMIT 0,100; 100 rows in set (0.00 sec) mysql show profile; ++--+ | Status | Duration | ++--+ | starting | 0.53 | | Opening tables | 0.09 | | System lock| 0.05 | | Table lock | 0.04 | | init | 0.37 | | optimizing | 0.05 | | statistics | 0.07 | | preparing | 0.05 | | executing | 0.01 | | Sorting result | 0.03 | | Sending data | 0.000856 | | end| 0.03 | | query end | 0.01 | | freeing items | 0.15 | | logging slow query | 0.01 | | logging slow query | 0.47 | | cleaning up| 0.02 | ++--+ 17 rows in set (0.00 sec) mysql select * from send_sms_test FORCE INDEX (time_priority) where time=UNIX_TIMESTAMP(NOW()) order by priority LIMIT 0,100; 100 rows in set (0.08 sec) mysql show profile; ++--+ | Status | Duration | ++--+ | starting | 0.48 | | Opening tables | 0.09 | | System lock| 0.02 | | Table lock
Re: mysql logs query with indexes used to the slow-log and not logging if there is index in reverse order
Thanks a lot for all your comments! I did disable Query cache before testing with set query_cache_type=OFF for the current session. I will report this to the MySQL bugs site later. 2012/10/16 Rick James rja...@yahoo-inc.com **Ø **My initial question was why MySQL logs it in the slow log if the query uses an INDEX? That _may_ be worth a bug report. ** ** A _possible_ answer... EXPLAIN presents what the optimizer is in the mood for at that moment. It does not necessarily reflect what it was in the mood for when it ran the query. ** ** When timing things, run them twice (and be sure not to hit the Query cache). The first time freshens the cache (buffer_pool, etc); the second time gives you a 'reproducible' time. I believe (without proof) that the cache contents can affect the optimizer's choice. ** ** *From:* spameden [mailto:spame...@gmail.com] *Sent:* Monday, October 15, 2012 3:29 PM *To:* Rick James *Cc:* mysql@lists.mysql.com *Subject:* Re: mysql logs query with indexes used to the slow-log and not logging if there is index in reverse order ** ** Sorry, forgot to say: mysql show variables like 'long_query_time%'; +-+---+ | Variable_name | Value | +-+---+ | long_query_time | 10.00 | +-+---+ 1 row in set (0.00 sec) It's getting in the log only due: mysql show variables like '%indexes%'; +---+---+ | Variable_name | Value | +---+---+ | log_queries_not_using_indexes | ON| +---+---+ 1 row in set (0.00 sec) If I turn it off - it's all fine My initial question was why MySQL logs it in the slow log if the query uses an INDEX? And why it's not logging if I create an INDEX (time, priority) (but in the query there is FORCE INDEX (priority,time) specified, so MySQL shouldn't use newly created INDEX (time, priority) at all). 2012/10/16 spameden spame...@gmail.com Sorry, my previous e-mail was a test on MySQL-5.5.28 on an empty table. Here is the MySQL-5.1 Percona testing table: mysql select count(*) from send_sms_test; +--+ | count(*) | +--+ | 143879 | +--+ 1 row in set (0.03 sec) Without LIMIT: mysql desc select * from send_sms_test FORCE INDEX (time_priority) where time=UNIX_TIMESTAMP(NOW()) order by priority; ++-+---+---+---+---+-+--+---+-+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | ++-+---+---+---+---+-+--+---+-+ | 1 | SIMPLE | send_sms_test | range | time_priority | time_priority | 8 | NULL | 73920 | Using where; Using filesort | ++-+---+---+---+---+-+--+---+-+ 1 row in set (0.00 sec) mysql desc select * from send_sms_test FORCE INDEX (priority_time) where time=UNIX_TIMESTAMP(NOW()) order by priority; ++-+---+---+---+---+-+--++-+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | ++-+---+---+---+---+-+--++-+ | 1 | SIMPLE | send_sms_test | index | NULL | priority_time | 12 | NULL | 147840 | Using where | ++-+---+---+---+---+-+--++-+ 1 row in set (0.00 sec) But I actually need to use LIMIT, because client uses this to limit the number of records returned to process. mysql select * from send_sms_test FORCE INDEX (priority_time) where time=UNIX_TIMESTAMP(NOW()) order by priority LIMIT 0,100; 100 rows in set (0.00 sec) mysql show profile; ++--+ | Status | Duration | ++--+ | starting | 0.53 | | Opening tables | 0.09 | | System lock| 0.05 | | Table lock | 0.04 | | init | 0.37 | | optimizing | 0.05 | | statistics | 0.07 | | preparing | 0.05 | | executing | 0.01 | | Sorting result | 0.03 | | Sending data | 0.000856 | | end| 0.03 | | query end | 0.01 | | freeing items | 0.15 | | logging slow query | 0.01 | | logging slow query | 0.47 | | cleaning up| 0.02 | ++--+ 17 rows in set (0.00
Re: Can I measure the use of index?
Hi, If you are using Percona Server, you can use this query: SELECT DISTINCT s.table_schema, s.table_name, s.index_name FROM information_schema.statistics `s` LEFT JOIN information_schema.index_statistics indxs ON ( s.table_schema = indxs.table_schema AND s.table_name = indxs.table_name AND s.index_name = indxs.index_name ) WHERE indxs.table_schema IS NULL AND s.index_name NOT IN ( 'PRIMARY' ) ; It will display all indexes that not use. or this query: SELECT table_name, index_name, SUM(rows_read) FROM information_schema.index_statistics GROUP BY table_name, index_name; you can get the all indexes are using. On Tue, Oct 16, 2012 at 12:44 AM, Perrin Harkins per...@elem.com wrote: On Mon, Oct 15, 2012 at 11:24 AM, Carlos Eduardo Caldi ce_ca...@hotmail.com wrote: Somebody knows how can I log or measure the index use ? http://www.percona.com/doc/percona-toolkit/2.1/pt-index-usage.html - Perrin -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql -- Senior MySQL Developer @ Taobao.com Mobile Phone: +86 18658156856 (Hangzhou) Gtalk: penglixun(at)gmail.com Twitter: http://www.twitter.com/plinux Blog: http://www.penglixun.com
Re: Can I measure the use of index?
For the record mariadb also has table and index statistics. Including statistics on temporary tables. On Mon, Oct 15, 2012 at 8:34 PM, Lixun Peng pengli...@gmail.com wrote: Hi, If you are using Percona Server, you can use this query: SELECT DISTINCT s.table_schema, s.table_name, s.index_name FROM information_schema.statistics `s` LEFT JOIN information_schema.index_statistics indxs ON ( s.table_schema = indxs.table_schema AND s.table_name = indxs.table_name AND s.index_name = indxs.index_name ) WHERE indxs.table_schema IS NULL AND s.index_name NOT IN ( 'PRIMARY' ) ; It will display all indexes that not use. or this query: SELECT table_name, index_name, SUM(rows_read) FROM information_schema.index_statistics GROUP BY table_name, index_name; you can get the all indexes are using. On Tue, Oct 16, 2012 at 12:44 AM, Perrin Harkins per...@elem.com wrote: On Mon, Oct 15, 2012 at 11:24 AM, Carlos Eduardo Caldi ce_ca...@hotmail.com wrote: Somebody knows how can I log or measure the index use ? http://www.percona.com/doc/percona-toolkit/2.1/pt-index-usage.html - Perrin -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql -- Senior MySQL Developer @ Taobao.com Mobile Phone: +86 18658156856 (Hangzhou) Gtalk: penglixun(at)gmail.com Twitter: http://www.twitter.com/plinux Blog: http://www.penglixun.com -- Eric Bergen eric.ber...@gmail.com http://www.ebergen.net -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
