Aujourd'hui, les opérations de base de données deviennent de plus en plus le goulot d'étranglement des performances de l'ensemble de l'application, en particulier pour les applications Web. Concernant les performances de la base de données, ce n’est pas seulement quelque chose dont les administrateurs de base de données doivent s’inquiéter, mais c’est aussi quelque chose auquel nous, les programmeurs, devons prêter attention. Lorsque nous concevons la structure des tables de la base de données et exploitons la base de données (en particulier les instructions SQL lors de la recherche de tables), nous devons prêter attention aux performances des opérations sur les données. Ici, nous ne parlerons pas trop de l’optimisation des instructions SQL, mais nous concentrerons uniquement sur MySQL, la base de données comportant le plus d’applications Web. J'espère que les conseils d'optimisation suivants vous seront utiles.
1. Structure du tableau
CREATE TABLE `room_break_history_tmp_test ` ( `id` INT(11) NOT NULL AUTO_INCREMENT, `break_type` INT(11) DEFAULT NULL, `app_id` INT(11) DEFAULT NULL, `room_id` INT(11) DEFAULT NULL, `from_user_id` INT(11) DEFAULT NULL, `to_user_id` INT(11) DEFAULT NULL, `content_type` INT(11) DEFAULT NULL, `content_name` VARCHAR(300) DEFAULT NULL, `source_message` VARCHAR(1536) DEFAULT NULL, `send_message` VARCHAR(1536) DEFAULT NULL, `request_type` INT(4) DEFAULT NULL, `report_relation` VARCHAR(1536) DEFAULT NULL, `handle_type` INT(11) DEFAULT NULL, `handle_uid` INT(11) DEFAULT NULL, `create_time` DATETIME DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_from_user_id` (`room_id`,`from_user_id`,`handle_type`,`create_time`) ) ENGINE=INNODB AUTO_INCREMENT=3416971 DEFAULT CHARSET=utf8mb4
2.
3. Plan d'exécutionDESC SELECT COUNT(1) FROM (SELECT COUNT(1) FROM room_break_history_tmp_test WHERE `create_time` BETWEEN '2017-07-01 22:25:33' AND '2017-07-01 22:27:00' AND handle_type = 5 GROUP BY room_id, from_user_id) AS keywordtemp
id select_type table type possible_keys key key_len ref rows Extra ------ ----------- ------------------ ------ ---------------- ---------------- ------- ------ ------- -------------------------- 1 PRIMARY <derived2> ALL (NULL) (NULL) (NULL) (NULL) 3438331 (NULL) 2 DERIVED room_break_history index idx_from_user_id idx_from_user_id 21 (NULL) 3438331 Using where; Using index
Temps d'exécution : 17,182 sec
Temps de transfert : 0,001 secTotal Temps : 17,184 sec
5. Description, en ce qui concerne le plan d'exécution, le type est index, key et key_len sont normaux. Il semble que l'index soit supprimé, mais les lignes sont des enregistrements de table presque pleins. (pas précis, il s'agit d'une analyse de table complète) ), le temps d'exécution de plus de 3 millions de données est en réalité de 17 secondes.
Réflexion : après avoir changé le nullable du champ en non nul, key_len devient plus court. La logique de jugement indiquant s'il est vide est-elle ajoutée aux données ?
Articles sur null :
Améliorations :
1.Ajouter un index
2.ALTER TABLE `test`.`room_break_history_tmp_test` -> ADD INDEX `idx_handle_time` (`handle_type`, `create_time`);
3. Temps d'exécution : 0,178 sec
id select_type table type possible_keys key key_len ref rows Extra ------ ----------- --------------------------- ------ -------------------------------- --------------- ------- ------ ------ -------------------------------------------------------- 1 PRIMARY <derived2> ALL (NULL) (NULL) (NULL) (NULL) 2 (NULL) 2 DERIVED room_break_history_tmp_test range idx_from_user_id,idx_handle_time idx_handle_time 7 (NULL) 1 Using index condition; Using temporary; Using filesort
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!