Jak zoptymalizować poniższe zapytanie?

Question

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 - zarezerwowana data.

Wykonanie tego zapytania zajmuje więcej niż 8 sekund. Mam ponad 500 000 rekordów w tabeli rezerwacji i 40 000 rekordów w tabeli użytkowników.

Nie dokonałem żadnej optymalizacji w tabelach bazy danych. Nic w ogóle. Tylko PKs. Jak mogę zoptymalizować to zapytanie? Jakie są opcje, aby zwiększyć wydajność tej bazy danych.

Dzięki

rezerwacja Tabela:

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 

użytkowników Tabela:

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 

Answer 1

pierwsze chciałbym przepisać kwerendy tak:

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 

wewnętrznej JOIN jest po prostu a di składni niż twoja, ale robi to samo. Moim zdaniem ten jest mniej podatny na błędy i bardziej przyjazny dla oka, ponieważ nie trzeba rozdzielać w klauzuli WHERE, co jest złączeniem, a co nie.

Ponieważ kolumna bx_data jest typu DATE, nie jest potrzebna funkcja DATE(), aby ponownie ustawić datę. Ogólnie użycie funkcji na kolumnie zapobiega używaniu indeksu (jeśli istnieje w tej kolumnie).

Aby wszystko było proste, zacznij od dodania indeksów do kolumn często używanych do łączenia lub używanych w klauzulach WHERE.

W twoim przypadku kolumny używane dla JOIN są już kluczami podstawowymi, więc niejawnie mają już indeks.

Możesz dodać indeks tak:

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

Aby uzyskać więcej informacji przeczytaj here.

Można również użyć indeksów złożonych, są to indeksy w wielu kolumnach.

UPDATE Dzięki ypercube sugerują w komentarzach:

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

Następnie można sprawdzić, czy i co indeks jest używany przez kładąc EXPLAIN przed zapytaniu. I oczywiście musisz mierzyć, mierzyć i mierzyć, czy indeks jest dobry, czy nie. Nadindeksowanie również nie jest dobrym pomysłem, ponieważ INSERTY i AKTUALIZACJE stają się znacznie wolniejsze. Aby sprawdzić, czy indeks laczy zapytanie trzeba upewnić się, że nie znajduje się w pamięci podręcznej gdzieś, więc po prostu przetestować wykonać zapytanie z SQL_NO_CACHE jak ten:

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; 

-

</UPDATE> 

Inną zasadą jest , że nie jest dobrym pomysłem indeksowanie kolumn, które mają bardzo mało różnych wartości, gdy tabela zawiera wiele wierszy.Twoja kolumna statusu w rezerwacji ma tylko 4 różne wartości. Dodanie indeksu do tej kolumny powoduje, że indeks jest bezużyteczny. Może nawet gorzej, ponieważ MySQL może używać indeksu, a następnie musi wykonać dodatkowe wyszukiwanie, aby znaleźć rzeczywiste dane odpowiadające pozycji indeksu.

Bardzo dobry odczyt o to Use-the-index-Luke