MySQL: постоянная «Поиск строки для обновления» на крошечном столе

У меня есть следующая таблица в моей MySQL схеме:MySQL: постоянная «Поиск строки для обновления» на крошечном столе

CREATE TABLE `security_token` (
`id` int(11) NOT NULL AUTO_INCREMENT, 
`customer_id` int(11) DEFAULT NULL, 
`expiration_date` datetime NOT NULL, 
`token_string` varchar(50) NOT NULL, 
`user_name` varchar(100) NOT NULL, 
PRIMARY KEY (`id`), 
KEY `security_token_token_string` (`token_string`) 
) ENGINE=InnoDB AUTO_INCREMENT=7054 DEFAULT CHARSET=latin1;

Следующий запрос часто исполненные (несколько раз в минуту), а иногда принимает сверх 3 минуты для выполнения:

UPDATE security_token 
SET expiration_date = '2016-09-01 18:20:37' 
WHERE user_name = 'john.smith' AND token_string = 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU' AND customer_id = 3

Если я выполняю SHOW PROCESSLIST статус является:

| 33515563 | db_user | 192.168.0.7:41058 | application_schema | Query | 116 | Searching rows for update | UPDATE security_token SET expiration_date = '2016-09-02 18:12:28' WHERE user_name = 'john.smith' AND ... | 
| 33515576 | db_user | 192.168.0.7:41062 | application_schema | Query | 113 | Searching rows for update | UPDATE security_token SET expiration_date = '2016-09-02 18:12:28' WHERE user_name = 'john.smith' AND ... | 
| 33515587 | db_user | 192.168.0.7:41064 | application_schema | Query | 110 | Searching rows for update | UPDATE security_token SET expiration_date = '2016-09-02 18:12:29' WHERE user_name = 'john.smith' AND ... | 
| 33515609 | db_user | 192.168.0.7:41067 | application_schema | Query | 106 | Searching rows for update | UPDATE security_token SET expiration_date = '2016-09-02 18:12:30' WHERE user_name = 'john.smith' AND ... | 
| 33515631 | db_user | 192.168.0.7:41071 | application_schema | Query | 104 | Searching rows for update | UPDATE security_token SET expiration_date = '2016-09-02 18:12:45' WHERE user_name = 'john.smith' AND ... | 
| 33515665 | db_user | 192.168.0.7:41076 | application_schema | Query | 101 | Searching rows for update | UPDATE security_token SET expiration_date = '2016-09-02 18:13:12' WHERE user_name = 'john.smith' AND ... | 
| 33515708 | db_user | 192.168.0.7:41081 | application_schema | Query | 98 | Searching rows for update | UPDATE security_token SET expiration_date = '2016-09-02 18:13:28' WHERE user_name = 'john.smith' AND ... | 
| 33515710 | db_user | 192.168.0.7:41086 | application_schema | Query | 93 | Searching rows for update | UPDATE security_token SET expiration_date = '2016-09-02 18:13:29' WHERE user_name = 'john.smith' AND ... | 
| 33515711 | db_user | 192.168.0.7:41090 | application_schema | Query | 88 | Searching rows for update | UPDATE security_token SET expiration_date = '2016-09-02 18:13:36' WHERE user_name = 'john.smith' AND ... | 
| 33515712 | db_user | 192.168.0.7:41092 | application_schema | Query | 85 | Searching rows for update | UPDATE security_token SET expiration_date = '2016-09-02 18:13:58' WHERE user_name = 'john.smith' AND ... |

Таблица имеет только 6 тыс. Строк и имеет размер 1,2 МБ. Вся схема имеет размер 300 Мбайт и в настоящее время работает на экземпляре Amazon RDS db.m4.xlarge.

Я не уверен, почему этот запрос вызывает столько проблем, может ли кто-нибудь указать какие-либо указатели, где искать/настраивать? К сожалению, я не могу включить схему производительности, поскольку это производственная база данных.

Обновление с подробной информацией

Я бегу версии 5.6.19-log, нет Триггеры на это (или любой) таблице. Первичный ключ этой таблицы не упоминается ни в каких других таблицах.

У меня есть следующие запросы, перечисленные в качестве блокирующих:

SELECT * FROM INNODB_LOCKS WHERE LOCK_TRX_ID IN (SELECT BLOCKING_TRX_ID FROM INNODB_LOCK_WAITS); 
+----------------------+-------------+-----------+-----------+---------------------------------------+--------------------+------------+-----------+----------+-------------------------------------------------------------+ 
| lock_id    | lock_trx_id | lock_mode | lock_type | lock_table       | lock_index   | lock_space | lock_page | lock_rec | lock_data             | 
+----------------------+-------------+-----------+-----------+---------------------------------------+--------------------+------------+-----------+----------+-------------------------------------------------------------+ 
| 535259585:349:43:132 | 535259585 | X   | RECORD | `application_schema`.`security_token` | security_token_idx |  349 |  43 |  132 | 'john.smith', 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU', 3, 70661 | 
| 535259584:349:43:132 | 535259584 | X   | RECORD | `application_schema`.`security_token` | security_token_idx |  349 |  43 |  132 | 'john.smith', 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU', 3, 70661 | 
| 535259583:349:43:132 | 535259583 | X   | RECORD | `application_schema`.`security_token` | security_token_idx |  349 |  43 |  132 | 'john.smith', 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU', 3, 70661 | 
| 535259581:349:43:132 | 535259581 | X   | RECORD | `application_schema`.`security_token` | security_token_idx |  349 |  43 |  132 | 'john.smith', 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU', 3, 70661 | 
| 535259575:349:43:132 | 535259575 | X   | RECORD | `application_schema`.`security_token` | security_token_idx |  349 |  43 |  132 | 'john.smith', 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU', 3, 70661 | 
| 535259574:349:43:132 | 535259574 | X   | RECORD | `application_schema`.`security_token` | security_token_idx |  349 |  43 |  132 | 'john.smith', 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU', 3, 70661 | 
| 535259573:349:43:132 | 535259573 | X   | RECORD | `application_schema`.`security_token` | security_token_idx |  349 |  43 |  132 | 'john.smith', 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU', 3, 70661 | 
| 535259570:349:43:132 | 535259570 | X   | RECORD | `application_schema`.`security_token` | security_token_idx |  349 |  43 |  132 | 'john.smith', 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU', 3, 70661 | 
| 535259554:349:43:132 | 535259554 | X   | RECORD | `application_schema`.`security_token` | security_token_idx |  349 |  43 |  132 | 'john.smith', 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU', 3, 70661 | 
| 535259551:349:43:132 | 535259551 | X   | RECORD | `application_schema`.`security_token` | security_token_idx |  349 |  43 |  132 | 'john.smith', 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU', 3, 70661 | 
| 535259546:349:43:132 | 535259546 | X   | RECORD | `application_schema`.`security_token` | security_token_idx |  349 |  43 |  132 | 'john.smith', 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU', 3, 70661 | 
| 535259544:349:43:132 | 535259544 | X   | RECORD | `application_schema`.`security_token` | security_token_idx |  349 |  43 |  132 | 'john.smith', 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU', 3, 70661 | 
| 535259543:349:43:132 | 535259543 | X   | RECORD | `application_schema`.`security_token` | security_token_idx |  349 |  43 |  132 | 'john.smith', 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU', 3, 70661 | 
| 535259541:349:43:132 | 535259541 | X   | RECORD | `application_schema`.`security_token` | security_token_idx |  349 |  43 |  132 | 'john.smith', 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU', 3, 70661 | 
| 535259525:349:43:132 | 535259525 | X   | RECORD | `application_schema`.`security_token` | security_token_idx |  349 |  43 |  132 | 'john.smith', 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU', 3, 70661 | 
| 535259522:349:43:132 | 535259522 | X   | RECORD | `application_schema`.`security_token` | security_token_idx |  349 |  43 |  132 | 'john.smith', 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU', 3, 70661 | 
| 535259521:349:43:132 | 535259521 | X   | RECORD | `application_schema`.`security_token` | security_token_idx |  349 |  43 |  132 | 'john.smith', 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU', 3, 70661 | 
| 535259520:349:43:132 | 535259520 | X   | RECORD | `application_schema`.`security_token` | security_token_idx |  349 |  43 |  132 | 'john.smith', 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU', 3, 70661 | 
| 535259519:349:43:132 | 535259519 | X   | RECORD | `application_schema`.`security_token` | security_token_idx |  349 |  43 |  132 | 'john.smith', 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU', 3, 70661 | 
| 535259517:349:43:132 | 535259517 | X   | RECORD | `application_schema`.`security_token` | security_token_idx |  349 |  43 |  132 | 'john.smith', 'mLBgrOXfVsXewCV333dVdvvDdxghJqQRU', 3, 70661 | 
+----------------------+-------------+-----------+-----------+---------------------------------------+--------------------+------------+-----------+----------+-------------------------------------------------------------+

источник

2016-09-02 smilin_stan

дать индекс в столбце security_token – Ish

Я бы предложил иметь следующие индексы 'alter table security_token add index security_token_idx (security_token);' и 'alter table security_token добавить index token_string_idx (token_string)' и 'alter table security_token добавить index customer_id_idx (customer_id) 'Если вы следуете тому же приоритету в where, то составной индекс будет лучше' alter table security_token add index user_token_customer_idx (имя_пользователя, token_string, customer_id) ' –

Я добавил индекс:' create index security_token_idx на security_token (имя_пользователя, token_string, customer_id) ', и это не имеет никакого значения, я все еще вижу, что эти запросы создаются в' show processlist' с длительным (2 мин) временем выполнения. –

Столкнувшись с такой же проблемой ..

Если вы вровень столы/замки/резьба по mysqladmin, он должен разрешить его: https://dev.mysql.com/doc/refman/5.5/en/mysqladmin.html

источник

2016-12-01 12:04:59

Хотя эта ссылка может ответить на вопрос, лучше включить здесь основные части ответа и предоставить ссылку для справки. Ответные ссылки могут стать недействительными, если связанная смена страницы –

MySQL: постоянная «Поиск строки для обновления» на крошечном столе

ответ

Смежные вопросы