エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
MySQLのwait_timeout
データベースやWebサーバーは、実際に稼働してから問題が多発します。 データ量が増えてきたり、アクセ... データベースやWebサーバーは、実際に稼働してから問題が多発します。 データ量が増えてきたり、アクセスが増えてきたらまずレスポンスの問題が発生するでしょう。 経験のあるエンジニアがいれば、十分なテストを行ってから稼働するわけですが、なかなかそうもいきません。 今回のテーマはMySQLのwait_timeoutの設定です。 なぜハマってしまうかというと、グローバル変数のwait_timeoutがそのまま個々のセッションのwait_timeoutになるとは限らないからです。 結論からいいますと、 プロセス生成時にグローバル変数のinteractive_timeoutかwait_timeout が、セッション変数のwait_timeout に反映されます。 そして、どちらが反映されるかは、mysqlのAPI呼出し時に対話型クライアントの定義かどうかできまります。 MySQLサーバーと、サーバ接続