I read the other answers and thought I could write something shorter, but apparently not. At least I will address the main question and not swap in general and ssd vs. hdd...
These are real-life situations from my experience where swap has proven questionable. I will present the scenarios briefly and then expand on the pros and cons.
In case you do something silly like a fork-bomb in a terminal, it is much more preferable to have that script / terminal OOM-killed by the kernel rather than watching your X session and everything else become completely unresponsive.
- On a production MySQL server
If the available system memory is less than what the mysql instance needs (plus everything else on that system) then some live user data from a request may end up in swap. If the power is cut off at that time, chances are you will end up with an incorrect logical state of your application. Despite the server being able to restart without corruptions in the data layer, recovering from data loss may be very painful for you or your clients.
- On the front-end nodes of a web application
If a single node is handling more connections than it has memory for, and it is allowed to swap, all of the transactions will run much slower and the response time of the web application will be higher than acceptable. The web app will intermittently time out with 503 or 504 errors and there will be support cases to deal with.
Pros and cons
I know two ways to recover a system from a process that steals all your memory and swap in a reasonable amount of time.
- Shell in from another machine and kill the offending process. Obviously this is not always possible.
- The reset switch, which may be very unlucky depending on what you were doing at the time.
- Prepare for this scenario / harden your system (yeah, right..)
"Saving memory" by putting some not-often accessed bits on disk is not really a benefit. The system has to use CPU and DISK-IO to swap memory from/to disk, you don't want that. If the kernel worker [kswapd0] is in the list of top-five or top-three processes ranked by overall cpu-time used on your system, I think that is cause for concern. So reduce vm.swapiness to 0 or 1-5 with sysctl on your machine or disable swap altogether.
If you don't have enough memory in the first place, then ask your boss for a new laptop, buy your own or suffer from poor performance. You can also invest your time in optimizing the memory-usage of the offending applications and let me know what you think about the ROI of that in a decade or two ;)
There are no pros for having swap on a production MySQL server in my opinion. Needing swap means you don't know what the work load is. With swap, it will get slow and the application performance will be unacceptable.
Having swap may help you "gracefully" detect issues. Assuming you have monitoring in place this may be considered ok in same cases. In most cases the application will be too slow for comfortable use. If the frontend nodes are not horizontally scaled and the swap / memory is abused by some background report-like task, then the net result is the same or even worse. The response times will be too high.
So overall, you need to have some experience and goals for the system in question to make good desicions. Hopefully I have been clear about my negative perspective on swap, but in real life, I do have swap both on my desktop and production servers because there are benefits to having swap (such as detecting memory leaks, having alerts / time to act before services are killed, hibernation). Unless you can prove that swap ruins performance, it is safe to allocate some.
Does having a separate swap partition instead of a swap file change the situation?
Short answer is no.
Prompted by user10489's answer: *NIX-like OS:s don't have a separate hiberfile similar to what Windows uses?
This is not a question, this is statement with a question mark at the end. Windows has a "hidden system partition" and optional hiberfile. Linux uses swap partitions for hibernation or swap files which cannot be used for hibernation. Conceptually these partitions/files/hiberfiles fulfill the same purpose. The implementation details are pointless to compare for the purpose of answering the first question, if you ask me.