SSL/TLSは、HTTPと組み合わせられることが多いですが、MySQLにもSSL経由の接続オプションがあるように、本来はプロトコルと独立して適用可能なものです1。
どうやってTLS通信に入る？
「最初からSSL/TLSの通信路しか用意しない」という手段を別にすれば、何かしらの方法でSSLありとなしの通信を区別する必要があります。
HTTPSでは、HTTPが80番ポートを使うのに対して、HTTPSでは443番を使うようにしてあるので、区別は明らかです。
ただ、ポート番号をSSL/非SSLで2倍消費していくと大変というような事情もあって、同じポートでまずは平文で接続を行い、プロトコル内のコマンドの1つにSSL導入の役割を持たせて、それで切り替える、というような手法があります。これがSTARTTLSです。
STARTTLSの利点・欠点
STARTTLSでは、すでに標準化しているポートで、「SSLあり/なしを同じように待ち受けられる」という点がメリットとなります。
一方で、SSLへのアップグレードまでは平文で通信が行われるため、そこで第三者が妨害すれば平文のまま通信が行われてしまう、というデメリットがあります（最初からSSL通信が行われる場合、鍵を解読できない中間者の介入は接続失敗となり、以降の通信は続きません）。
実例
FTPS
FTPS2では、あまり「STARTTLS」と銘打たれることはありませんが、「Explicitモード」といって、ふつうにFTPで接続してからAUTHコマンドでSSL接続に切り替えるようになっています。別にFTPS用ポートを開いておく「Implicitモード」は、正式なRFCに載らないこととなりました。
なお、多くの場合、FTPクライアント側の設定で、SSL接続に失敗した場合「そのまま平文のFTPを続ける」か「接続しない」かを選ぶことができるようになっています。
SMTPでのSTARTLS
STARTTLSの実装としていちばん有名なのが、SMTPに対して適用するものです。最近はSTARTTLSが使えるように設定されたメールサーバも多く、GmailでもTLSなしで届いたメールには壊れた鍵のアイコンが出るようになっています。
もともと、SMTPが「シンプルメール転送プロトコル」の略であるように、メールの送信は「バケツリレー式」と呼ばれるような、幾つものサーバを経由したものでした。これでは1ホップだけTLSをかけたところで、全体のセキュリティ向上にはあまり資さないものでした。
ただ、インターネット上ではバケツリレー式でなく、直接受信アドレスのあるサーバに接続するのが一般的となってきたことなどもあり、比較的地位が向上している感はあります。
ただ、ホップ間の暗号化という制約はそのままなので、サーバ～サーバ間のDKIMや、ユーザー間でのS/MIMEなど、より上位からの暗号技術適用も依然として有用です。