Optimisation de Supprimer la requête sur la table de mémoire MySQL

Question

J'exécute un grand forum qui maintient une base de données MySQL pour le stockage de données backend. La table «session» suit les utilisateurs et les invités. Il s'agit actuellement d'environ 100 000 enregistrements, donc pas vraiment aussi grand. Cependant, ce tableau de session apparaît dans le journal de requête lent lorsque nous coupez les anciens enregistrements:

# Time: 120719 10:05:11
# User@Host: xxx[xxx] @  [10.x.x.x]
# Thread_id: 369051896  Schema: forumdb  Last_errno: 0  Killed: 0
# Query_time: 8.352811  Lock_time: 0.000028  Rows_sent: 0  Rows_examined: 19635  Rows_affected: 19635  Rows_read: 0
# Bytes_sent: 13  Tmp_tables: 0  Tmp_disk_tables: 0  Tmp_table_sizes: 0
SET timestamp=1342710311;
DELETE FROM session
    WHERE lastactivity < 1342709401;

J'ai confirmé qu'il y a un index btree sur le tableau des derniers:

mysql> SHOW INDEX FROM session FROM forumdb;
+---------+------------+--------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table   | Non_unique | Key_name     | Seq_in_index | Column_name  | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+---------+------------+--------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| session |          0 | PRIMARY      |            1 | sessionhash  | NULL      |       78941 |     NULL | NULL   |      | HASH       |         |               |
| session |          1 | userid       |            1 | userid       | NULL      |       26313 |     NULL | NULL   |      | HASH       |         |               |
| session |          1 | idhash       |            1 | idhash       | NULL      |        8771 |     NULL | NULL   |      | HASH       |         |               |
| session |          1 | userid_2     |            1 | userid       | NULL      |        NULL |     NULL | NULL   |      | HASH       |         |               |
| session |          1 | userid_2     |            2 | lastactivity | NULL      |       39470 |     NULL | NULL   |      | HASH       |         |               |
| session |          1 | userid_3     |            1 | userid       | NULL      |        NULL |     NULL | NULL   |      | HASH       |         |               |
| session |          1 | userid_3     |            2 | host         | NULL      |       39470 |     NULL | NULL   |      | HASH       |         |               |
| session |          1 | lastactivity |            1 | lastactivity | A         |        NULL |     NULL | NULL   |      | BTREE      |         |               |
+---------+------------+--------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
8 rows in set (0.00 sec)

Je suis curieux de savoir pourquoi la requête de suppression prend si longtemps avec si peu de disques.

Il convient de noter que ce tableau est utilisé très fortement avec autant d'utilisateurs en ligne en même temps. Nous avons du matériel lourd assis derrière.

Des idées sur ce que je peux faire pour accélérer ce processus? Il semble verrouiller la table afin que je vois une charge élevée sur mon cluster lorsque cette fonction de suppression se déroule.

Le cache de requête est désactivé (nous utilisons Memcache). Voici des parties pertinentes de my.cnf:

table_open_cache=8242
table_definition_cache=600
open_files_limit=65535
binlog_cache_size=6M
sort_buffer_size=8M
key_buffer_size=5G
myisam_sort_buffer_size=256M
join_buffer_size=3M
thread_cache_size=1000
thread_concurrency=16
ft_min_word_len=3
tmp_table_size=512M
max_allowed_packet=128M
max_heap_table_size=512M
read_rnd_buffer_size=1M
skip-external-locking

query_cache_limit=1M
query_cache_size= 32M
query_cache_type = 0

Enfin, voici quelques informations sur la table:

FIXÉ:

Après avoir changé la table en innodb (à 17:15 dans le graphique ci-dessous), je vois de bien meilleures performances et plus de suppression dans les Slowlogs pour ce tableau. L'ensemble du cluster voient de meilleures performances depuis qu'il a fait ce changement. Merci.