Refer to the film table of the Sakila database. This lab loads film with $100$ rows from Sakila Consequently, SELECI $*$ FROM film; generates too many characters to display in the zyLab environment However, statements with less output, such aS SELECT title FROM film; execute successfully.

This lab illustrates the use of indexes and EXPLAIN to optimize query performance. Refer to EXPLAIN documentation for information about EXPLAIN result columns.

Write and run seven SQL statements:

Explain the query SELECT $*$ FROM film WHERE title $=$ 'ALONE IRIP' ;

In the EXPLAIN result, column key is null, indicating no index is available for the query. Column rovs is $100,$ indicating all rows are read The query executes a table scan and is slow.

$2$ Create an indexidx$\_$title on the title column.

Explain the query of step $1$ again.

In the EXPLAIN result, column key has value $1dx\_$ titie, indicating the query uses the index on title Column rovs is $1,$ indicating only one table row is read. The query is fast

Explain the query SEIECT $*$ FROM FIIn WHERE title $>$ 'ALONE TRIP';

In the EXPLAIN result, column key is null, indicating the query does not use the $1dx\_$titie index. Column rovs is $100,$ indicating all rows are read Since the query has s in the WHERE clause rather than $=,$ the query executes a table scan and is slow.

Explain the query SELECT rating, count $(*)$ FROM film GROUP BY rating:

In the EXPLAIN result, column key is null, indicating no index is available for the query Column rovs is $100,$ indicating all rows are read. The query executes a table scan and is slow.

Create an index idx$\_$rating on the rating column.

Explain the query of step $5$ again.

In the EXPLAIN result, column key has value idx$\_$rating, indicating the query reads rating values from the index. The query uses an index scan, which is faster than a table scan $($step $5)$

For submit$-$mode testing, all seven statements must appear in Main.sql in the correct order