AWS RDS 테이블 색인이있는 경우에도 읽기가 느림

Question

AWS를 처음 사용합니다.

두 개의 서버가 있습니다. 하나는 내 사이트 서버이고 다른 하나는 AWS입니다. 내 사이트 서버는 내 컴퓨터가 아니고 내 컴퓨터가 아니기 때문에 서버 A이라고합니다. 사이트 서버에서 AWS 서버로 테이블을 마이그레이션하고 있습니다.

내 문제는 AWS 서버에서 테이블 읽기가 느리다는 것입니다. 대기 시간이 DB 부분에서 오는 것인지 또는 AWS 설정에서 해결할 수 있는지 확실하지 않습니다 (여기에 할 수있는 작업이있는 경우).

서버 A는 MySQL을 기반으로하며 AWS는 Aurora를 기반으로합니다.

내 질문은 이것이다 :이 인덱스 문제가있는 경우 찾으려고

SELECT sessionId, sequence, timestamp, source, sourceType, repId, 
    content, contentType FROM chatLines 
    WHERE sessionId=%s ORDER BY sequence ASC; 

하지만, 다음과 같이 인덱스 정보는 서버 A와 AWS 서버와 동일합니다

Table, Non_unique, Key_name, Seq_in_index, Column_name, Collation, Cardinality, Index_type 

chatLines, 0, PRIMARY, 1, id, A, 2492436 ,   BTREE  
chatLines, 0, IDX_CHATLINES_SESSIONID_SEQUENCE, 1, sessionId, A, 166162,    BTREE  
chatLines 0 IDX_CHATLINES_SESSIONID_SEQUENCE 2 sequence A 2492436    BTREE  
chatLines 1 IDX_CHATLINES_SESSIONID_TIMESTAMP 1 sessionId A 166162    BTREE  
chatLines 1 IDX_CHATLINES_SESSIONID_TIMESTAMP 2 timestamp A 2492436    BTREE  
chatLines 1 IDX_CHATLINES_SESSIONID_BYTYPE 1 sessionId A 207703    BTREE  
chatLines 1 IDX_CHATLINES_SESSIONID_BYTYPE 2 sourceType A 623109    BTREE  

다음은 내가 테이블을 만드는 데 사용한 테이블 스키마. 여기

explain select * from chatLines 
where sessionId = 'ID1560302010' order by sequence asc 

1. Server A 

id, select_type, table, type, possible_keys, key, key_len, ref, rows, Extra 
1, SIMPLE, chatLines, ref, IDX_CHATLINES_SESSIONID_SEQUENCE,IDX_CHATLINES_SESSIONID_TIMESTAMP,IDX_CHATLINES_SESSIONID_BYTYPE, IDX_CHATLINES_SESSIONID_SEQUENCE, 62, const, 16, Using where 

2. AWS 

id, select_type, table, type, possible_keys, key, key_len, ref, rows, Extra 
1, SIMPLE, chatLines, ref, IDX_CHATLINES_SESSIONID_SEQUENCE,IDX_CHATLINES_SESSIONID_TIMESTAMP,IDX_CHATLINES_SESSIONID_BYTYPE, IDX_CHATLINES_SESSIONID_SEQUENCE, 62, const, 16,**Using index condition;** Using where 

는 AWS 매개 변수 구성 (내가 중요하다고 생각하는)입니다 : 여기

-- Table structure for table `chatLines` 
-- 

/*!40101 SET @saved_cs_client  = @@character_set_client */; 
/*!40101 SET character_set_client = utf8 */; 
CREATE TABLE `chatLines` (
`id` int(11) NOT NULL AUTO_INCREMENT, 
`sessionId` varchar(20) NOT NULL, 
`sequence` smallint(6) NOT NULL, 
`timestamp` datetime NOT NULL, 
`source` varchar(100) NOT NULL, 
`sourceType` char(1) NOT NULL, 
`repId` varchar(20) DEFAULT NULL, 
`content` mediumtext, 
`contentType` char(1) NOT NULL, 
PRIMARY KEY (`id`), 
UNIQUE KEY `IDX_CHATLINES_SESSIONID_SEQUENCE` (`sessionId`,`sequence`), 
KEY `IDX_CHATLINES_SESSIONID_TIMESTAMP` (`sessionId`,`timestamp`), 
KEY `IDX_CHATLINES_SESSIONID_BYTYPE` (`sessionId`,`sourceType`), 
CONSTRAINT `chatLines_ibfk_1` FOREIGN KEY (`sessionId`) 
    REFERENCES `chatSessions` (`sessionId`) ON DELETE CASCADE ON UPDATE CASCADE 
) ENGINE=InnoDB AUTO_INCREMENT=308232770 DEFAULT CHARSET=utf8; 
/*!40101 SET character_set_client = @saved_cs_client */; 

이 선택 결과를 EXPLAIN입니다> 수입 스키마 - 나는 MySQL의 워크 벤치에서이 있어요. "SELECT"있습니다 AWS에 대한 느린 :

1. query_cache_type을 : {DBInstanceClassMemory/24}

2. query_cache_size를 : 1

3. innodb_buffer_pool_size : {DBInstanceClassMemory * 3/4}

4. 스위치 innodb_adaptive_hash_index = 1

Answer 1

id 및 현재 PRIMARY KEY을 제거하십시오. 대부분의 다른 쿼리가 빠르게 실행됩니다 아마 고유 인덱스가 변경 후

PRIMARY KEY(`sessionId`,`sequence`) 

을로 변경, 문제의 쿼리가 실행됩니다 빨리 (모든 컴퓨터에)합니다.

이 변경으로 인해 발생할 수있는 문제가 제거됩니다. id의 제한은 약 20 억 개이며 이미 3 억입니다.

두 서버가 다르게 작동하는 이유는 분명히 다른 버전의 MySQL을 실행하고 있기 때문입니다. 어떤 버전입니까?

다른 것을 확인해 봅시다. 각각의 RAM은 얼마입니까? innodb_buffer_pool_size의 값은 무엇입니까?