Lambat? Jangan Panik: Checklist Sederhana Troubleshooting Database untuk Developer dan DBA Pemula

Lambat? Jangan Panik: Checklist Sederhana Troubleshooting Database untuk Developer dan DBA Pemula

Di dunia pengembangan aplikasi, hanya ada dua jenis database: yang belum lambat, dan yang sudah terbukti lambat. Ketika halaman mulai loading tak berujung dan API mulai timeout, pertanyaan besarnya bukan "siapa yang salah", tetapi "apa langkah pertama yang harus diambil untuk mencari biang keladinya."

Hari itu, saya sedang menikmati kopi di kantor. Tenang. Tidak ada notifikasi. Tiba-tiba, group chat mulai ramai. "Aplikasi lemot." "Gambar tidak muncul." "Ada error timeout." Saya buka dashboard, melihat grafik CPU server database—meroket seperti harga bitcoin di tahun 2017. Lalu detak jantung saya ikut naik.

Ini cerita yang akrab bagi siapa pun yang pernah mengelola database. Performa turun, panik naik. Tangan gemetar di atas keyboard, membuka tab query acak, menjalankan perintah tanpa tahu apa yang dicari. Semakin cepat bertindak, semakin kacau hasilnya.

Maka, mari kita buat kesepakatan di sini: saat database lambat, duduklah dulu. Saya serius. Ambil napas. Perlambat. Karena menyentuh database dalam keadaan panik sama dengan menyiram bensin ke api. Checklist ini dibuat untuk mencegah itu.

Ikuti langkah-langkah ini, urut. Jangan loncat-loncat.

Langkah 1: Pastikan Itu Database, Bukan Hal Lain

Sebelum menyalahkan database, pastikan bahwa database memang pelakunya. Kadang yang lambat adalah jaringan, aplikasi, atau bahkan browser pengguna.

Cek cepat: Buka terminal, jalankan ping ke server database. Lihat latency. Jika tinggi, mungkin jaringan. Jika normal, lanjut.

Cek aplikasi: Coba jalankan query sederhana langsung dari console database, lewat tool seperti phpMyAdmin, DBeaver, atau command line. Jika query sederhana itu cepat, kemungkinan besar masalah di aplikasi (kode, koneksi, atau logika).

Cek resource server: Login ke server database, jalankan top atau htop. Lihat CPU, memory, dan load average. Kalau CPU 99%, itu database. Kalau memory habis, mungkin ada kebocoran. Kalau IO wait tinggi, mungkin disk bermasalah.

Checklist awal ini untuk memastikan kita tidak buang waktu mengejar hantu di tempat yang salah.

Langkah 2: Identifikasi Query Bermasalah

Jika sudah yakin masalah ada di database, langkah selanjutnya adalah mencari siapa yang biang kerok. Database menjalankan ribuan query per detik. Pasti ada satu atau dua yang menghabiskan sumber daya paling banyak.

Di sinilah kita butuh log atau monitor query.

• MySQL: Aktifkan slow query log. Set threshold misalnya 2 detik. Nanti semua query yang jalan lebih dari 2 detik akan tercatat. Atau gunakan SHOW FULL PROCESSLIST untuk melihat query yang sedang berjalan.
• PostgreSQL: Aktifkan parameter log_min_duration_statement. Atau gunakan ekstensi pg_stat_statements untuk melihat statistik query.
• SQL Server: Gunakan Query Store atau DMV seperti sys.dm_exec_query_stats.
• MongoDB: Aktifkan profiler dengan db.setProfilingLevel(1).

Dari sini, kita akan mendapat daftar query yang patut dicurigai: yang paling sering dieksekusi, yang paling lama, atau yang paling banyak membaca data.

Contoh kasus: Dulu saya menemukan satu query SELECT dengan 6 JOIN yang dijalankan ribuan kali per menit. Padahal data yang dikembalikan hanya 10 baris, tapi cara bacanya membuat database harus menggabungkan jutaan baris. Itu biang keroknya.

Langkah 3: Analisis Execution Plan

Setelah menemukan query mencurigakan, sekarang saatnya membedahnya. Execution plan adalah peta bagaimana database menjalankan querymu—table mana yang dibaca duluan, indeks mana yang dipakai, berapa banyak baris yang diproses.

Cara dapat execution plan:

• MySQL: EXPLAIN SELECT ...
• PostgreSQL: EXPLAIN (ANALYZE, BUFFERS) SELECT ...
• SQL Server: SET SHOWPLAN_XML ON atau langsung dari SSMS klik "Display Estimated Execution Plan".

Yang perlu dicari di execution plan:

• Full table scan (tanpa indeks) pada tabel besar → merah.
• Nested loop yang memproses jutaan baris → hati-hati.
• Penggunaan temporary table atau filesort → bisa jadi penyebab lambat.
• Estimasi vs aktual—kadang database salah tebak jumlah baris, lalu pilih strategi yang salah.

Execution plan seperti laporan keuangan: semua jawaban ada di sana, tapi butuh latihan membacanya. Jangan menyerah di langkah ini. Pelajari satu per satu.

Langkah 4: Cek Indeks

Penyebab nomor satu query lambat: tidak pakai indeks. Atau pakai indeks yang salah.

Indeks di database seperti indeks di buku. Mau cari kata "troubleshooting" di buku 500 halaman? Indeks akan langsung kasih tahu halamannya. Tanpa indeks, kamu harus baca satu per satu.

Hal-hal yang perlu dicek soal indeks:

• Apakah kolom yang dipakai di WHERE, JOIN, ORDER BY, dan GROUP BY sudah diindeks?
• Apakah urutan kolom di indeks sudah sesuai dengan query? Indeks (A, B) tidak akan optimal untuk query yang hanya mencari kolom B.
• Apakah ada indeks duplikat atau tidak terpakai? (Buang yang tidak perlu, karena indeks mempercepat baca tapi memperlambat tulis).
• Apakah indeks sudah selective? Indeks pada kolom dengan sedikit nilai unik (misal: status "Y/T") tidak terlalu membantu.

Tool seperti pg_stat_user_indexes di PostgreSQL atau sys.dm_db_index_usage_stats di SQL Server bisa menunjukkan indeks mana yang jarang dipakai.

Langkah 5: Cek Konfigurasi Database

Kadang query sudah optimal, indeks sudah pas, tapi database tetap lambat. Mungkin konfigurasinya salah.

Parameter yang paling sering mempengaruhi performa:

• Buffer pool / cache size: MySQL (innodb_buffer_pool_size), PostgreSQL (shared_buffers). Jika terlalu kecil, database akan terus-menerus baca dari disk, yang ribuan kali lebih lambat dari RAM.
• Connection pool: Terlalu banyak koneksi bisa membuat database kewalahan. Atur batasnya sesuai kemampuan server.
• Memory settings lain: sort buffer, join buffer, temp table size. Jangan asal gedein, karena bisa saling rebut.
• Checkpoint / WAL settings: Di PostgreSQL, jika terlalu sering checkpoint, disk akan sibuk menulis.

Ini area yang butuh pemahaman lebih dalam. Untuk pemula, fokus dulu ke buffer pool dan batas koneksi. Itu sudah cukup untuk 80% kasus.

Langkah 6: Cek Hardware dan OS

Database tidak hidup di awan (meskipun di cloud, tetap ada server fisik di bawahnya). Hardware berpengaruh.

Yang perlu dicek:

• Disk I/O: Gunakan iostat di Linux. Jika await atau svctm tinggi, disk lambat. Mungkin perlu upgrade ke SSD.
• Memory: Apakah ada swapping? Jalankan free -m, lihat used swap. Jika >0, RAM kurang.
• CPU: Apakah ada proses lain yang berebut? Bisa jadi ada backup berjalan pas jam sibuk.
• Network: Cek dengan netstat atau iftop. Apakah ada traffic berlebihan?

Kadang solusinya bukan optimalisasi query, tapi upgrade RAM atau ganti SSD. Tapi pastikan dulu, jangan asal beli hardware baru.

Langkah 7: Pertimbangkan Beban dan Pola Akses

Database lambat bukan berarti ada yang rusak. Mungkin memang beban sedang tinggi. Misalnya:

• Jam sibuk: Setiap jam 10 pagi, laporan otomatis dijalankan semua divisi.
• Batch job: Ada proses malam yang molor sampai pagi.
• Traffic spike: Lagi viral, pengguna 10x lipat.

Jika ini penyebabnya, strateginya berbeda: optimasi bisa tetap dilakukan, tapi solusi jangka panjang mungkin perlu replikasi, read replica, sharding, atau caching.

Tapi untuk level pemula, cukup tahu dulu bahwa beban tinggi itu wajar, dan tidak selalu butuh "perbaikan".

Checklist Ringkas (Simpan di Meja)

Saya buatkan ringkasan untuk ditempel di meja:

1. Verifikasi target: Benar masalah di database? Cek jaringan, resource server, query sederhana.
2. Cari query lambat: Slow query log, processlist, pg_stat_statements, dsb.
3. Baca execution plan: Apakah pakai indeks? Ada full scan? Nested loop gila-gilaan?
4. Cek indeks: Apakah sudah tepat? Apakah ada yang kurang?
5. Tinjau konfigurasi DB: Buffer pool, koneksi, memory settings.
6. Lihat hardware dan OS: Disk I/O, memory, CPU, network.
7. Pertimbangkan beban normal: Apakah ini jam sibuk? Ada batch?
8. Jika semua gagal: Catat, dokumentasi, minta bantuan senior. Tidak apa-apa.

Yang Jangan Dilakukan Saat Database Lambat

Saya ingin menutup bagian ini dengan daftar larangan, karena pengalaman saya: saat panik, kita cenderung melakukan hal bodoh.

• Jangan restart database tanpa data. Kadang masalah muncul lagi setelah restart, dan kamu kehilangan kesempatan melihat penyebabnya (karena semua processlist dan log sementara hilang). Restart hanya jika benar-benar darurat.
• Jangan asal nambah indeks. Setiap indeks memperlambat write. Kalau asal tancep, aplikasi bisa makin lambat karena proses insert/update jadi berat.
• Jangan ubah konfigurasi di file tanpa backup. Backup dulu file konfigurasi. Kalau salah, kamu bisa balik.
• Jangan kill query secara acak. Bisa jadi query yang kamu kill itu proses penting. Lihat dulu konteksnya.
• Jangan panik dan lapor atasan tanpa data. "Database lemot" laporan tidak berguna. "Database CPU 95% karena 5 query lambat, ini daftarnya" lebih baik.

Saya pernah, karena panik, menjalankan perintah DROP TABLE di database produksi. Untungnya itu coba-coba di lab. Tapi trauma itu membuat saya menulis checklist ini.

Kesimpulan Sementara

Troubleshooting database adalah proses detektif. Ada korban (pengguna yang nunggu loading), ada TKP (server database), ada saksi (log dan metrik), dan ada tersangka (query atau konfigurasi).

Tugas kita bukan menghakimi, tapi mencari fakta. Ikuti urutannya. Jangan lompat. Karena setiap langkah memberi petunjuk untuk langkah berikutnya.

Dan ingat: database yang sehat tidak pernah benar-benar sehat selamanya. Ia seperti tanaman—perlu dirawat, dipupuk, kadang dipangkas. Tapi dengan checklist ini, kamu punya alat untuk merawatnya tanpa panik.

Dengan checklist yang jelas dan langkah-langkah terstruktur ini, Anda tidak lagi menebak-nebak di kegelapan saat database merangkak. Masalah performa, serumit apa pun, bisa diurai satu per satu—selama Anda tahu di mana harus mulai melihat dan kapan harus mengambil tindakan.

Tanya Jawab: Ngobrol Santai Soal Database

Q: Aku baru pertama kali megang database produksi. Tiba-tiba lemot. Apa yang paling aman dilakukan?
A: Pertama, jangan panik. Kedua, jangan restart. Ketiga, jalankan langkah 1-3 di checklist. Kalau mentok di langkah 4, minta bantuan senior. Aman itu bukan berarti tidak melakukan apa-apa, tapi melakukan hal yang tepat dengan risiko minimal. Slow query log dan execution plan tidak akan merusak apa pun. Mulai dari sana.

Q: Tool apa yang wajib dipasang di server database untuk monitoring?
A: Untuk pemula, cukup built-in tools: slow query log, SHOW PROCESSLIST, dan EXPLAIN. Kalau mau yang lebih ramah mata, bisa pakai pgAdmin (PostgreSQL), MySQL Workbench, atau DBeaver (universal). Untuk monitoring real-time, coba Prometheus + Grafana nanti setelah lebih pede. Tapi jangan kebanyakan tool dulu—malah bingung.

Q: Kapan waktu yang tepat untuk nambah indeks?
A: Setelah kamu menemukan query lambat, dan execution plan menunjukkan full table scan, dan kolom yang dicari memang layak diindeks (selektif, sering dipakai), maka saatnya nambah indeks. Tapi ingat: tambah indeks = tambah beban saat insert/update. Jadi jangan asal.

Q: Database lemot tapi setelah restart jadi normal. Kenapa?
A: Kemungkinan ada query boros yang menumpuk di cache atau memory. Restart membersihkan itu, tapi tidak menyelesaikan masalah. Gejalanya akan muncul lagi. Cari penyebabnya dengan slow query log. Jangan jadikan restart sebagai solusi permanen.

Q: Aku lihat CPU 100%, tapi tidak ada query lambat. Apa mungkin?
A: Mungkin. Cek apakah ada proses lain di server selain database (backup, cron job, aplikasi lain). Bisa juga karena konfigurasi—misalnya, thread pool terlalu besar. Atau bisa juga karena indeks terlalu banyak sehingga proses insert berat. Gunakan top untuk lihat proses mana yang makan CPU.

Q: Apa bedanya optimize query dan optimize database?
A: Optimize query fokus ke satu atau beberapa query tertentu: nulis ulang, tambah indeks, ubah struktur. Optimize database fokus ke konfigurasi, hardware, dan arsitektur secara keseluruhan. Pemula mulai dari optimize query dulu. Itu dampaknya besar dan risikonya kecil.

Q: Aku takut merusak data. Gimana cara aman troubleshooting?
A: Jika memungkinkan, lakukan di lingkungan staging atau development dulu. Jika tidak punya staging, gunakan read replica untuk analisis. Kalau terpaksa di produksi, lakukan hanya SELECT dan EXPLAIN—jangan INSERT, UPDATE, DELETE, atau ALTER tanpa persetujuan tim. Dan selalu backup sebelum ubah apa pun.

Q: Checklist ini berlaku untuk semua jenis database?
A: Prinsipnya sama, tapi tool-nya beda. MySQL dan PostgreSQL punya cara berbeda dalam melihat slow query dan execution plan. Tapi konsep dasarnya—cari query lambat, baca execution plan, cek indeks, cek konfigurasi—berlaku universal. Sesuaikan dengan database yang kamu pakai.

Slow? Don't Panic: A Simple Database Troubleshooting Checklist for Beginner Developers and DBAs

In the world of application development, there are only two types of databases: those that aren't slow yet, and those that have proven themselves to be slow. When pages start loading endlessly and APIs begin timing out, the big question isn't "who's to blame," but "what's the first step to find the culprit."

That day, I was enjoying coffee at the office. Peaceful. No notifications. Suddenly, the group chat started buzzing. "App is slow." "Images aren't loading." "Timeout error." I opened the dashboard, looked at the database server's CPU graph—it was skyrocketing like Bitcoin in 2017. Then my heart rate followed suit.

This is a familiar story for anyone who's ever managed a database. Performance drops, panic rises. Hands tremble over the keyboard, opening random query tabs, running commands without knowing what you're looking for. The faster you act, the more chaotic the result.

So, let's make a pact here: when the database is slow, sit down first. I'm serious. Take a breath. Slow down. Because touching a database in a panic is like pouring gasoline on a fire. This checklist was created to prevent that.

Follow these steps, in order. Don't jump around.

Step 1: Make Sure It's the Database, Not Something Else

Before blaming the database, make sure the database is actually the culprit. Sometimes it's the network, the application, or even the user's browser that's slow.

Quick check: Open a terminal, run ping to the database server. Check latency. If it's high, it might be the network. If normal, continue.

Check the application: Try running a simple query directly from the database console, via a tool like phpMyAdmin, DBeaver, or the command line. If that simple query is fast, the problem is likely in the application (code, connections, or logic).

Check server resources: Log into the database server, run top or htop. Look at CPU, memory, and load average. If CPU is at 99%, it's the database. If memory is exhausted, there might be a leak. If IO wait is high, the disk might be problematic.

This initial checklist ensures we don't waste time chasing ghosts in the wrong place.

Step 2: Identify Problematic Queries

Once you're sure the problem is with the database, the next step is to find who the troublemaker is. Databases run thousands of queries per second. There's bound to be one or two consuming the most resources.

This is where we need query logs or monitors.

• MySQL: Enable the slow query log. Set a threshold, e.g., 2 seconds. Any query running longer than 2 seconds will be logged. Or use SHOW FULL PROCESSLIST to see currently running queries.
• PostgreSQL: Enable the log_min_duration_statement parameter. Or use the pg_stat_statements extension to see query statistics.
• SQL Server: Use the Query Store or DMVs like sys.dm_exec_query_stats.
• MongoDB: Enable the profiler with db.setProfilingLevel(1).

From this, we'll get a list of suspicious queries: the most frequently executed, the slowest, or those reading the most data.

Example case: I once found a SELECT query with 6 JOINs being executed thousands of times per minute. Even though it only returned 10 rows, the way it read data forced the database to combine millions of rows. That was the culprit.

Step 3: Analyze the Execution Plan

After finding the suspicious query, it's time to dissect it. The execution plan is a map of how the database runs your query—which table is read first, which indexes are used, how many rows are processed.

How to get an execution plan:

• MySQL: EXPLAIN SELECT ...
• PostgreSQL: EXPLAIN (ANALYZE, BUFFERS) SELECT ...
• SQL Server: SET SHOWPLAN_XML ON or directly from SSMS, click "Display Estimated Execution Plan".

What to look for in an execution plan:

• Full table scan (without an index) on a large table → red flag.
• Nested loops processing millions of rows → be cautious.
• Use of temporary tables or filesort → could be the cause of slowness.
• Estimate vs actual—sometimes the database misestimates the number of rows and chooses the wrong strategy.

The execution plan is like a financial report: all the answers are there, but it takes practice to read it. Don't give up at this step. Learn it one piece at a time.

Step 4: Check Indexes

The number one cause of slow queries: not using an index. Or using the wrong index.

An index in a database is like an index in a book. Looking for the word "troubleshooting" in a 500-page book? The index will immediately tell you the page number. Without an index, you'd have to read page by page.

Things to check regarding indexes:

• Are the columns used in WHERE, JOIN, ORDER BY, and GROUP BY indexed?
• Is the column order in the index appropriate for the query? An index (A, B) won't be optimal for a query that only searches on column B.
• Are there duplicate or unused indexes? (Discard unnecessary ones, because indexes speed up reads but slow down writes).
• Is the index selective? An index on a column with few unique values (e.g., status "Y/N") isn't very helpful.

Tools like pg_stat_user_indexes in PostgreSQL or sys.dm_db_index_usage_stats in SQL Server can show which indexes are rarely used.

Step 5: Check Database Configuration

Sometimes queries are optimal, indexes are right, but the database is still slow. Maybe the configuration is wrong.

Parameters that most often affect performance:

• Buffer pool / cache size: MySQL (innodb_buffer_pool_size), PostgreSQL (shared_buffers). If too small, the database will constantly read from disk, which is thousands of times slower than RAM.
• Connection pool: Too many connections can overwhelm the database. Set limits according to server capacity.
• Other memory settings: sort buffer, join buffer, temp table size. Don't just increase them arbitrarily; they might compete for resources.
• Checkpoint / WAL settings: In PostgreSQL, if checkpoints happen too often, the disk will be busy writing.

This area requires deeper understanding. For beginners, focus on the buffer pool and connection limits first. That's enough for 80% of cases.

Step 6: Check Hardware and OS

Databases don't live in the cloud (even in the cloud, there's a physical server underneath). Hardware matters.

What to check:

• Disk I/O: Use iostat on Linux. If await or svctm is high, the disk is slow. Maybe an SSD upgrade is needed.
• Memory: Is there swapping? Run free -m, check used swap. If >0, RAM is insufficient.
• CPU: Are there other processes competing? Maybe a backup is running during peak hours.
• Network: Check with netstat or iftop. Is there excessive traffic?

Sometimes the solution isn't query optimization, but a RAM upgrade or switching to SSD. But be sure first; don't just buy new hardware.

Step 7: Consider Load and Access Patterns

A slow database doesn't always mean something is broken. Maybe the load is just high. For example:

• Peak hours: Every day at 10 AM, automated reports run for all departments.
• Batch jobs: A nightly process overruns into the morning.
• Traffic spike: Going viral, users increase 10x.

If this is the cause, the strategy is different: optimization can still help, but long-term solutions might involve replication, read replicas, sharding, or caching.

But for a beginner level, just know that high load is normal, and it doesn't always require "fixing."

Concise Checklist (Keep on Your Desk)

Here's a summary to stick on your desk:

1. Verify the target: Is it really a database problem? Check network, server resources, simple queries.
2. Find slow queries: Slow query log, processlist, pg_stat_statements, etc.
3. Read the execution plan: Is it using indexes? Full scans? Insane nested loops?
4. Check indexes: Are they appropriate? Any missing?
5. Review DB configuration: Buffer pool, connections, memory settings.
6. Check hardware and OS: Disk I/O, memory, CPU, network.
7. Consider normal load: Is this peak time? Any batch jobs?
8. If all else fails: Document, log, ask a senior for help. It's okay.

What NOT to Do When the Database is Slow

I want to close this section with a list of don'ts, because from experience: when we panic, we tend to do stupid things.

• Don't restart the database without data. Sometimes the problem reappears after a restart, and you lose the chance to see the cause (because all process lists and temporary logs are gone). Restart only in a real emergency.
• Don't randomly add indexes. Every index slows down writes. If you add them carelessly, the application could get slower because insert/update processes become heavy.
• Don't change configuration in the file without a backup. Back up the config file first. If you make a mistake, you can revert.
• Don't kill queries randomly. The query you kill might be an important process. Check the context first.
• Don't panic and report to your boss without data. "Database is slow" is a useless report. "Database CPU at 95% due to 5 slow queries; here's the list" is better.

I once, in a panic, ran a DROP TABLE command on a production database. Luckily it was just experimentation in a lab. But that trauma led me to write this checklist.

Temporary Conclusion

Database troubleshooting is a detective process. There's a victim (users waiting for loading), a crime scene (the database server), witnesses (logs and metrics), and suspects (queries or configurations).

Our job isn't to judge, but to find facts. Follow the order. Don't skip steps. Because each step provides clues for the next.

And remember: a healthy database is never truly healthy forever. It's like a plant—it needs care, fertilizer, and occasional pruning. But with this checklist, you have the tools to care for it without panicking.

With this clear checklist and structured steps, you'll no longer be guessing in the dark when your database crawls. Performance problems, no matter how complex, can be unraveled one by one—as long as you know where to start looking and when to take action.

Q&A: Casual Chat About Databases

Q: I'm handling a production database for the first time. Suddenly it's slow. What's the safest thing to do?
A: First, don't panic. Second, don't restart. Third, run steps 1-3 from the checklist. If you get stuck at step 4, ask a senior for help. "Safe" doesn't mean doing nothing; it means doing the right thing with minimal risk. Slow query logs and execution plans won't damage anything. Start there.

Q: What tools are essential to install on a database server for monitoring?
A: For beginners, built-in tools are enough: slow query log, SHOW PROCESSLIST, and EXPLAIN. If you want something more visual, try pgAdmin (PostgreSQL), MySQL Workbench, or DBeaver (universal). For real-time monitoring, consider Prometheus + Grafana later when you're more confident. But don't overload on tools at first—it'll just confuse you.

Q: When is the right time to add an index?
A: After you've found a slow query, and the execution plan shows a full table scan, and the columns being searched are indeed worth indexing (selective, frequently used), then it's time to add an index. But remember: adding an index increases the load during inserts/updates. So don't do it arbitrarily.

Q: The database was slow, but after a restart, it's normal. Why?
A: Possibly there were resource-heavy queries accumulating in cache or memory. Restarting clears that, but doesn't solve the problem. The symptoms will return. Find the cause using the slow query log. Don't make restarting a permanent solution.

Q: I see 100% CPU usage, but no slow queries. Is that possible?
A: Yes. Check if there are other processes on the server besides the database (backups, cron jobs, other applications). It could also be a configuration issue—for example, a thread pool that's too large. Or too many indexes making inserts heavy. Use top to see which process is consuming CPU.

Q: What's the difference between optimizing a query and optimizing the database?
A: Optimizing a query focuses on one or a few specific queries: rewriting, adding indexes, changing structure. Optimizing the database focuses on configuration, hardware, and overall architecture. Beginners should start with query optimization. It has a big impact with low risk.

Q: I'm afraid of corrupting data. How can I troubleshoot safely?
A: If possible, do it in a staging or development environment first. If you don't have a staging environment, use a read replica for analysis. If you must work on production, only perform SELECT and EXPLAIN—no INSERT, UPDATE, DELETE, or ALTER without team approval. And always back up before changing anything.

Q: Does this checklist apply to all types of databases?
A: The principles are the same, but the tools differ. MySQL and PostgreSQL have different ways of viewing slow queries and execution plans. But the core concepts—find slow queries, read the execution plan, check indexes, check configuration—are universal. Adapt them to the database you're using.