>  기사  >  데이터 베이스  >  mysql 최적화 예시 공유

mysql 최적화 예시 공유

零下一度
零下一度원래의
2017-07-17 10:03:331501검색
  1. 오늘날 데이터베이스 작업은 전체 애플리케이션, 특히 웹 애플리케이션의 성능 병목 현상을 점점 더 많이 발생시키고 있습니다. 데이터베이스의 성능에 관해서는 이는 DBA만이 고민해야 할 부분이 아니라, 우리 프로그래머들이 주목해야 할 부분입니다. 데이터베이스 테이블 구조를 설계하고 데이터베이스를 운영할 때(특히 테이블 조회 시 SQL문) 데이터 운영의 성능에 주의를 기울여야 합니다. 여기서는 SQL 문의 최적화에 대해 너무 많이 이야기하지 않고 가장 많은 웹 애플리케이션이 있는 데이터베이스인 MySQL에만 중점을 둘 것입니다. 다음 최적화 팁이 귀하에게 도움이 되기를 바랍니다.

  2. 1. 테이블 구조

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. 실행문

DESC 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

3. 실행 계획

    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

4. 0.001초

총 시간 : 17.184 sec


5.설명에 따르면 실행계획에 따르면 type은 index이고 key와 key_len은 정상인 것 같지만 행은 거의 full table records입니다. (정확하지는 않습니다. full table scan입니다.) 3백만 개가 넘는 데이터의 실행 시간은 실제로 17초입니다.

생각하기: 필드의 nullable을 null이 아닌 것으로 변경하면 key_len이 더 짧아지나요? 비어 있는지 여부에 대한 판단 논리가 데이터에 추가되나요? NULL에 대한 기사:

개선:

1. 인덱스 추가

ALTER TABLE `test`.`room_break_history_tmp_test`     ->   ADD  INDEX `idx_handle_time` (`handle_type`, `create_time`);
E

2. 실행 계획

    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
E

3. : 0.179초

위 내용은 mysql 최적화 예시 공유의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.