The one habit that separates this from guesswork. What to measure, and WHY THE FIRST THING EVERYBODY SUSPECTS IS ALMOST NEVER IT.
Performance work divides cleanly into two activities: measuring, and guessing with confidence. The second is far commoner and it produces changes that are defensible, expensive, and unrelated to the problem.
THE FIRST THING EVERYBODY SUSPECTS IS RESOURCE: NOT ENOUGH MEMORY, NOT ENOUGH CPU, NOT ENOUGH HARDWARE. It is almost never that. An EBS system that was fast last month and is slow today is running on the same hardware, so unless something measurable changed in the load, the resource is not the variable.
WHAT IT USUALLY IS: ONE STATEMENT WHOSE PLAN CHANGED — Lesson 8 — ONE SESSION BLOCKING OTHERS, OR ONE JOB DOING FAR MORE WORK THAN ANYBODY REALISED. All three are specific, findable, and invisible to any conversation about capacity.
SO MEASURE WHERE THE TIME GOES BEFORE PROPOSING ANYTHING. Not whether the machine is busy — where the time is spent. A system at 90% CPU and a system at 10% CPU waiting on locks are both "slow" and they need opposite responses, and the second one gets worse if you add hardware.
AND THE COST OF GUESSING IS NOT ONLY THE WASTED CHANGE. Adding memory takes a window and a purchase; adding an index changes every plan that touches that table; restarting fixes it for an hour and destroys the evidence. Each one buys a plausible story that stops anybody looking further, and the problem returns next month with a team that now believes it has already been addressed.
THE HABIT IS ONE SENTENCE: BE ABLE TO NAME THE EVIDENCE FOR EVERY CHANGE YOU PROPOSE. "This statement accounts for forty percent of database time" is a reason. "The server looks under-specified" is a suspicion, and Lesson 12 asks for findings written the first way for exactly this reason.