Execution plans
A plan describes how a database intends to execute a statement. Use it to explain work, not to hunt for a universally “bad” operator.
Scans and searches
A table scan reads the table’s rows; an index search uses an indexed path to narrow work. A scan can be appropriate for a small table or a query needing most rows. SQLite EXPLAIN QUERY PLAN shows high-level choices.
Join methods
Other engines expose nested loops, hash joins and merge joins. Their suitability depends on row counts, ordering and available memory. SQLite’s display is simpler and should not be mistaken for a SQL Server execution plan.
Estimates and actuals
Estimated plans use statistics to predict row counts. In engines with actual plans, compare estimates with observed rows. Large differences can explain poor choices. An estimated cost is not elapsed time.
Sorts and bottlenecks
Look for avoidable sorts, repeated scans, spills and unexpectedly large intermediate results. Measure representative workloads. This tiny practice dataset teaches plan reading, not production speed comparisons.