Understanding Indexing
What is the primary purpose of creating an index on a table column in a relational database?
- To speed up read queries by enabling faster lookups
- To increase available storage capacity
- To simplify adding new columns
- To automatically encrypt the data
- To force sequential scans for all queries
Trade-offs of Indexes
Which of the following is a potential downside of adding indexes to a database table?
- Indexes make write operations, such as INSERT and UPDATE, slower
- Indexes cause the database to lose data on restart
- Indexes are limited to numeric columns only
- Indexes disable foreign key constraints
- Indexes always improve performance regardless of query type
Materialized Views Purpose
What is the main advantage of using a materialized view over a simple (non-materialized) view?
- Results are precomputed and stored, allowing faster retrieval
- Materialized views update in real-time with every data change
- They reduce overall disk space usage
- They are always more accurate than regular queries
- They automatically handle connection pooling
Refreshing Materialized Views
After updating the underlying table, what must be done to ensure a materialized view reflects the latest data?
- Manually refresh the materialized view with a command
- Drop and recreate the table
- Wait for the auto sync that occurs every second
- Disconnect and reconnect to the database
- Run OPTIMIZE TABLE on the original table
Use of Connection Pooling
Why is connection pooling beneficial for applications that interact with a relational database?
- It reuses database connections to reduce the overhead of opening new ones
- It forces transactions to complete faster
- It encrypts database traffic automatically
- It increases the number of tables that can be joined
- It disables sequential scans internally
Caching and Performance
How can caching frequently accessed data in RAM improve database performance?
- It allows faster retrieval of common queries, reducing load on the database
- It enables foreign key indexing
- It automatically optimizes all SQL queries
- It increases the physical size of the database file
- It disables the use of materialized views
Application-Level Optimization
Which SQL query writing practice is recommended for performance optimization?
- Avoid using SELECT * by specifying needed columns
- Always use subqueries without indexing
- Write queries with maximum OFFSETs possible
- Use views only for data insertion
- Prefer SELECT all statements for consistency
Understanding Views
What is a key characteristic of a simple (non-materialized) view in a database?
- It stores only the query, not the result; executing it runs the underlying query each time
- It automatically caches results in RAM for all reads
- It requires manual refresh after every update
- It cannot be joined with other tables
- It is optimized only for write operations
Counter-Questions in Performance Debugging
When diagnosing slow performance in a relational database, what is a helpful counter-question to ask?
- Are the performance issues occurring mostly during reads, writes, or both?
- Is the database version above 10.0?
- Are there at least 10 tables in the schema?
- Was the data last imported using CSV?
- Are queries always executed at midnight?
Read vs. Write Trade-offs
What is a common consequence of implementing features that improve read performance, like materialized views or indexes?
- Write operations may become slower or require additional maintenance
- Tables will automatically shrink in size
- Database queries become case-insensitive
- No additional disk space is required
- All old data is automatically archived