Background
I'm working on a website for a movie theather chain currently located in four different cities (might expand in the future). They use the same, single-database website for all cities, which means I have to have a column in certain tables which holds the ID of the city that each row belongs to.
Right now I have three different tables:
Cinemas
- Contains each city's cinema (ID and name).Movies
- Contains all movies that has been/will be shown at the cinema.Showtimes
- Contains all showtimes for all movies in all cities.
The structure of the Showtimes
table is the following:
Column Name | Column Type | Description
--------------+--------------+---------------
ID | BIGINT | (Primary) Unique ID for each showtime (perhaps unnecessary?)
CinemaID | TINYINT | Foreign key bound to Cinemas.ID
MovieID | BIGINT | Foreign key bound to Movies.ID
Showtime | DATETIME | At what date and time the movie will show
(will contain multiple rows for each movie, i.e. one row for each showtime)
How this table will be used
A user of the website must be able to:
View all current/upcoming movies and showtimes (sorted by date) in the selected city.
Example query (backend):
SELECT MovieID, Showtime FROM Showtimes WHERE CinemaID = ? ORDER BY Showtime
Select a single movie and view all showtimes for that specific title only (in the selected city).
Example query:
SELECT Showtime FROM Showtimes WHERE CinemaID = ? AND MovieID = ? ORDER BY Showtime
Select a single day and view all movies and showtimes for that day only (in the selected city).
Example query:
SELECT MovieID, Showtime FROM Showtimes WHERE CinemaID = ? AND (Showtime BETWEEN [date 12:00 AM] AND [date 12:00 PM])
So naturally I decided that I needed to create indexes for the columns.
Problem
What I'm having trouble with is deciding/determining how to index the columns properly. One index for each column seems quite expensive[1] [2] so I started looking into composite indexes, which seems to be the right choice but also led to even more confusion.
From my understanding (based on what I've read) you should add the columns to the index by order of selectivity, making the most selective (I'm guessing that means the most unique/with the most cardinality?) column the first in the composite index[3] (in my case that would be the Showtime
column). The only problem with that is that the index can only be used by the database if the first column is included in the search query[4] [5], which it currently isn't in either of my queries.
Question
What kind of index(es) should I apply to my columns in order to cover all usage scenarios? (the last scenario may be omitted, but the first two are required)
Should I use a composite index on all columns, for some columns, or do I need a separate index for each column?
This table is updated at most a few times per week to add new showtimes.
Footnotes
1 MySQL indexes - what are the best practices?
2 Indexing every column in a table
3 How important is the order of columns in indexes? (question)
4 How important is the order of columns in indexes? (#2 top-voted answer)