Wie kann ich unter Abfrage optimieren?

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 - gebuchter Termin.

Es dauert mehr als 8 Sekunden, um diese Abfrage auszuführen. Ich habe mehr als 500.000 Datensätze in der Reservierungstabelle und 40.000 Datensätze in der Benutzertabelle.

Ich habe keine Optimierung für meine Datenbanktabellen durchgeführt. Gar nichts. Nur PKs nur. Wie kann ich diese Abfrage optimieren? Welche Möglichkeiten gibt es, um die Leistung dieser Datenbank zu erhöhen?

Dank

Tischreservierung:

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 

Tabelle Benutzer:

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

Zuerst würde ich die Abfrage wie folgt umschreiben:

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 

Der JOIN INNER ist nur ein Di andere Syntax als Ihre, aber es macht dasselbe. Meiner Meinung nach ist dies weniger fehleranfällig und augenfreundlicher, da Sie in der WHERE-Klausel nicht trennen müssen, was ein Join ist und was nicht.

Da die Spalte bx_date vom Typ DATE ist, brauchen Sie die Funktion DATE() nicht, um erneut ein Datum daraus zu machen. Im Allgemeinen verhindert die Verwendung einer Funktion in einer Spalte die Verwendung eines Indexes (falls in dieser Spalte vorhanden).

Um die Dinge zu Beginn einfach zu halten, fügen Sie einfach Indizes zu Spalten hinzu, die häufig für Joins verwendet werden oder in WHERE-Klauseln verwendet werden.

In Ihrem Fall sind die für die JOIN verwendeten Spalten bereits Primärschlüssel, daher haben sie implizit bereits einen Index.

Sie können einen Index wie folgt hinzu:

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

Für weitere Informationen lesen here.

Sie können auch zusammengesetzte Indizes verwenden, dies sind Indizes für mehrere Spalten.

UPDATE Dank der in den Kommentaren vorschlagen ypercube:

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

Sie können dann prüfen, ob oder welche Index, indem eine EXPLAIN vor Ihrer Anfrage verwendet. Und natürlich müssen Sie messen, messen und messen, ob ein Index gut ist oder nicht. Überindizierung ist auch keine gute Idee, da INSERTS und UPDATES viel langsamer werden. Um herauszufinden, ob ein Index Ihrer Anfrage fastens müssen Sie sicherstellen, dass es nicht irgendwo im Cache, also nur testen Sie Ihre Abfrage mit SQL_NO_CACHE wie folgt auszuführen:

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> 

Eine weitere Regel ist , dass es keine gute Idee ist, Spalten zu indizieren, die sehr wenige unterschiedliche Werte haben, wenn die Tabelle viele Zeilen enthält.Ihre Statusspalte in der Reservierung hat nur 4 verschiedene Werte. Durch Hinzufügen eines Index für diese Spalte wird der Index unbrauchbar. Es kann sogar noch schlimmer werden, da MySQL den Index verwenden und dann eine zusätzliche Suche durchführen muss, um die tatsächlichen Daten zu finden, die der Indexposition entsprechen.

Eine sehr gute Lese darüber Use-the-index-Luke ist