Exhibit: mysql> EXPLAIN SELECT FROM City Where CountryCode = 'USA'\G ***********************1.row************************ id: 1 select_type: SIMPLE table: City type: ALL possible_keys: NULL key: NULL

Question

Options

• AA. if it is possible for you to include any indexes in your query
• BB. whether there are any indexes on the tables that you are querying
• CC. if there are any indexes that may be used to solve this query
• DD. whether there are any indexes in your query

• A
  88% (30)
• B
  3% (1)
• C
  6% (2)
• D
  3% (1)

Explanation

Option A is correct because possible_keys reveals which indexes MySQL identified as candidates it could apply when executing the query - specifically based on the columns referenced in the WHERE, JOIN, and ORDER BY clauses. In this output, possible_keys: NULL tells you there are no indexes MySQL could potentially leverage for the CountryCode = 'USA' filter, which directly caused the full table scan (type: ALL across 4,079 rows).

Option B is wrong because possible_keys is not a general inventory of all indexes on the table - a table could have many indexes, but none relevant to a specific query, making them invisible here. Option C is the sneaky distractor: it sounds accurate, but possible_keys lists candidates MySQL considered, not indexes it will actually use - that's what the key column is for (the index MySQL chose). Option D is wrong because "indexes in your query" is meaningless phrasing; indexes are on tables, not written into queries.

Memory tip: Think of possible_keys as MySQL's shortlist of applicants for the job, and key as the hired index - a NULL in possible_keys means no applicants even showed up, so a full table scan is the fallback.

No community discussion yet for this question.