2012-08-22 3 views
6
SELECT r.*, u.username 
FROM `reservation` AS r JOIN 
    `users` AS u 
WHERE u.id = r.user_id 
AND DATE(r.bx_date) >= DATE('2012-08-22') 
AND DATE(r.bx_date) <= DATE('2012-08-22') 
AND r.status='1' 
ORDER BY r.id desc 

bx_date - 예약 날짜입니다.아래 쿼리를 최적화하는 방법은 무엇입니까?

이 쿼리를 실행하는 데 8 초 이상 걸립니다. 예약 테이블에는 50 만 개 이상의 레코드가 있고 사용자 테이블에는 4 만 개의 레코드가 있습니다.

데이터베이스 테이블에 최적화를하지 않았습니다. 전혀. PKs 만. 이 쿼리를 어떻게 최적화 할 수 있습니까? 이 데이터베이스의 성능을 향상시키는 옵션은 무엇입니까?

감사

표 예약 :

CREATE TABLE `reservation` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT, 
`user_id` int(10) unsigned NOT NULL COMMENT 'User ID', 
`tx_id` varchar(15) NOT NULL COMMENT 'Transaction ID', 
`tx_date` datetime NOT NULL COMMENT 'Transaction Date', 
`bx_date` date NOT NULL COMMENT 'Booking Date', 
`theater_id` int(10) unsigned NOT NULL COMMENT 'Theater ID', 
`movie_id` int(10) unsigned NOT NULL COMMENT 'Movie ID', 
`showtime_id` int(10) unsigned NOT NULL COMMENT 'Show Time ID', 
`category_id` int(10) unsigned NOT NULL COMMENT 'Category ID', 
`full_tickets` tinyint(2) unsigned NOT NULL COMMENT 'Number of Full Tickets', 
`half_tickets` tinyint(2) unsigned NOT NULL COMMENT 'Number of Half Tickets', 
`no_seats` tinyint(3) unsigned NOT NULL COMMENT 'No of Seats', 
`full_ticket_price` decimal(10,2) unsigned NOT NULL DEFAULT '0.00' COMMENT 'Full Ticket Price', 
`half_ticket_price` decimal(10,2) unsigned NOT NULL DEFAULT '0.00' COMMENT 'Half Ticket Price', 
`amount` decimal(10,2) unsigned NOT NULL DEFAULT '0.00' COMMENT 'Total Amount', 
`method` tinyint(1) unsigned NOT NULL COMMENT 'Payment Method 1=web 2=mobile 3=theater', 
`paymentgateway_id` int(10) unsigned NOT NULL COMMENT 'Payment Gateway ID', 
`payment_type` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT '0 = Cash 1=Credit Card', 
`status` tinyint(1) unsigned NOT NULL COMMENT 'Status 0=provisional 1=booked 2=canceled 3=auto canceld', 
`comment` text, 
`reservation_type` tinyint(1) unsigned NOT NULL COMMENT 'Reservation Type 0=complimentary 1=advamce booking 2=Mobile Booking, 3 - Theater Offline Booking', 
`complimentary_type` tinyint(1) unsigned NOT NULL COMMENT '0=none 1=loyalty rewards 2=marketing 3=promotional 4=show blocking 5=vip', 
`description` mediumtext NOT NULL COMMENT 'Complimentary Description', 
`title` varchar(10) DEFAULT NULL COMMENT 'Title', 
`fname` varchar(255) DEFAULT NULL COMMENT 'First Name', 
`lname` varchar(255) DEFAULT NULL COMMENT 'Last Name', 
`gender` tinyint(1) unsigned DEFAULT NULL COMMENT 'Gender 0=male 1=female', 
`dob` date DEFAULT '0000-00-00' COMMENT 'Date of Birth', 
`nic` varchar(10) DEFAULT NULL COMMENT 'NIC no', 
`address` text COMMENT 'Address Line 1', 
`city` varchar(255) DEFAULT NULL COMMENT 'City', 
`district` varchar(50) DEFAULT NULL COMMENT 'District ', 
`country` varchar(255) DEFAULT NULL COMMENT 'Country', 
`mobile` varchar(15) DEFAULT NULL COMMENT 'Mobile No', 
`contact_phone` varchar(15) DEFAULT NULL COMMENT 'Fixed Land Phone Number', 
`email` varchar(255) DEFAULT NULL COMMENT 'Email Address', 
`timer` int(4) unsigned NOT NULL, 
PRIMARY KEY (`id`), 
KEY `user_id_index` (`user_id`) 
) ENGINE=InnoDB AUTO_INCREMENT=555706 DEFAULT CHARSET=utf8 

표 사용자 :

CREATE TABLE users (id int(11) NOT NULL AUTO_INCREMENT, 
title varchar(100) NOT NULL, 
name varchar(255) NOT NULL DEFAULT '', 
last_name varchar(255) NOT NULL, 
username varchar(150) NOT NULL DEFAULT '', 
email varchar(100) NOT NULL DEFAULT '', 
password varchar(100) NOT NULL DEFAULT '', 
usertype varchar(25) NOT NULL DEFAULT '', 
block tinyint(4) NOT NULL DEFAULT '0', 
sendEmail tinyint(4) DEFAULT '0', 
registerDate datetime NOT NULL DEFAULT '0000-00-00 00:00:00', 
lastvisitDate datetime NOT NULL DEFAULT '0000-00-00 00:00:00', 
activation varchar(100) NOT NULL DEFAULT '', 
params text NOT NULL, 
gender varchar(6) NOT NULL, 
date_of_birth date NOT NULL, 
nic_no varchar(10) NOT NULL, 
address varchar(255) NOT NULL, 
city varchar(100) NOT NULL, 
district varchar(100) NOT NULL, 
mobile varchar(15) NOT NULL, 
subscribe_sms tinyint(1) NOT NULL, 
contact_phone varchar(15) NOT NULL, 
newsletter_subscribe tinyint(1) NOT NULL, 
PRIMARY KEY (id), 
UNIQUE KEY username (username), 
KEY usertype (usertype), 
KEY idx_name (name), 
KEY idx_block (block), 
KEY email (email)) 
ENGINE=InnoDB AUTO_INCREMENT=34265 DEFAULT CHARSET=utf8 
+2

당신이 우리의 출력을 보여줄 수 있습니다에 대한 아주 좋은 읽기'SHOW TABLE의 reservation','SHOW는 표 users'를 작성하고 당신이 여기에 게시 선택에서 EXPLAIN을 만드시겠습니까? (단지 select를 실행하지만 앞에서'EXPLAIN'이라는 단어로). – Konerak

+2

-1이기 때문에 최적화를 시도하지 않았습니다. 적어도'EXPLAIN'의 출력을 포함하고 https://dev.mysql.com/doc/refman/5.6/en/optimization.html에서 어떤 것들을 시도했는지 말하십시오. –

+1

'bx_date '의 데이터 타입은 무엇입니까? – Bridge

답변

3

먼저 나는이 같은 쿼리 재 작성합니다 :

SELECT r.*, u.username 
FROM 
`reservation` AS r 
INNER JOIN `users` AS u ON u.id = r.user_id 
WHERE 
r.bx_date = '2012-08-22' /* or use BETWEEN when you really have a range */ 
AND r.status='1' 
ORDER BY r.id desc 

내부 조인은 그냥 디 당신보다 fferent 문법이지만, 똑같습니다. 내 의견으로는,이 것은 오류가 발생하기 쉽고 눈 친화적이기 때문에 WHERE 절에서 조인과 분리하지 않아도됩니다.

bx_date 열의 유형이 DATE이므로 DATE() 함수를 사용하여 날짜를 다시 만들 필요가 없습니다. 일반적으로 열에 함수를 사용하면 해당 열에 색인이 사용되는 것을 방지 할 수 있습니다.

시작을 단순하게 유지하려면 조인에 자주 사용되거나 WHERE 절에 사용되는 열에 인덱스를 추가하기 만하면됩니다.

JOIN에 사용 된 열은 이미 기본 키이므로 암시 적으로 이미 색인이 있습니다.

이 같은 인덱스를 추가 할 수 있습니다

ALTER TABLE reservation ADD INDEX idx_reservation_bx_date (bx_date); /*if I remember correctly :) */ 

은 더 많은 정보 here를 참조하십시오.

복합 인덱스를 사용할 수도 있습니다. 복합 인덱스는 여러 열에 대한 인덱스입니다. 감사의 댓글에 제안 ypercube하는

UPDATE :

ALTER TABLE reservation ADD INDEX idx_reservation_bx_date_status (bx_date, status); /*if I remember correctly :) */ 

그런 다음 확인할 수는 어떤 색인 경우 또는 쿼리의 앞에서 EXPLAIN을 넣어 사용된다. 물론 지표가 좋은지 아닌지 측정, 측정 및 측정해야합니다. INSERT 및 UPDATES가 훨씬 느려지므로 오버 인덱싱 또한 좋은 생각이 아닙니다. 또 다른 규칙이

</UPDATE> 

입니다 -

SELECT SQL_NO_CACHE r.*, u.username 
FROM 
`reservation` AS r 
INNER JOIN `users` AS u ON u.id = r.user_id 
WHERE 
r.bx_date = '2012-08-22' /* or use BETWEEN when you really have a range */ 
AND r.status='1' 
ORDER BY r.id desc; 

: 인덱스가 쿼리를 건다 경우 반드시 어딘가에 캐시에없는 확인해야합니다, 그래서 그냥 이런 SQL_NO_CACHE하여 쿼리를 실행 테스트 확인하려면 테이블에 많은 행이있을 때 고유 값이 거의없는 열을 인덱싱하는 것은 좋지 않습니다.예약시 상태 열에는 4 개의 별개 값만 있습니다. 이 열에 색인을 추가하면 색인이 쓸모 없게됩니다. MySQL이 인덱스를 사용할 수 있기 때문에 인덱스 위치에 해당하는 실제 데이터를 찾기 위해 추가 조회를 수행해야하기 때문에 상황이 악화 될 수도 있습니다.

그것이 Use-the-index-Luke

+0

복합 인덱스를'(bx_date, status)'또는'(status, bx_date)'에 넣는 것이 좋습니다. –

+0

@ 그래, 좋은 생각이야. – fancyPants

+0

지원에 감사드립니다. – Techie

관련 문제