WHERE句にあるサブクエリ時々見かけるんですが、対象のデータ件数が増えるにつれ速度低下のボトルネックになったり、後から追加された仕様に対応するため複雑な相関サブクエリが使われていて一見してなにをしているSQLなのかわからなくなったりしていることが経験上多い気がしています。 できる限りサブクエリをJOIN句に入れておくことで世の中が少し平和になったりしないかなと思いました。 対象条件の抽出
![WHERE句のサブクエリは大抵の場合テーブルJOINで代替できる - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/928e7db8bcf3cb3f55d9c6d41d6274fa75a51fd7/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9V0hFUkUlRTUlOEYlQTUlRTMlODElQUUlRTMlODIlQjUlRTMlODMlOTYlRTMlODIlQUYlRTMlODIlQTglRTMlODMlQUElRTMlODElQUYlRTUlQTQlQTclRTYlOEElQjUlRTMlODElQUUlRTUlQTAlQjQlRTUlOTAlODglRTMlODMlODYlRTMlODMlQkMlRTMlODMlOTYlRTMlODMlQUJKT0lOJUUzJTgxJUE3JUU0JUJCJUEzJUU2JTlCJUJGJUUzJTgxJUE3JUUzJTgxJThEJUUzJTgyJThCJTIwJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz02NzVkODg0ZmEwOTEwNjQ3MjA0NWM5YTNiNGYxYTEyYw%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwcm9iaXRhbiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9YmY0MmE2NTlmODVjMzg0Zjg2ZmJkNmRkOGRhMWQwNDE%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D8025ab7b1d29aa214505e5a4e5f9b2e0)
※10.3 stable リリースされてるので更新してみた。 MySql5.6+からマイグレーションする場合など、MariaDB5.5では動作しないケースが多々ありそうなので10.1「10.3」にしてみました。 公式yumリポジトリ追加 公式のCentOS7x64のMariaDB10.3 Stableのリポジトリ情報 を追加します。 $ sudo yum update mariadb-server -y ~~略~~ base | 3.6 kB 00:00 epel | 3.2 kB 00:00 extras | 3.4 kB 00:00 mariadb-main | 2.9 kB 00:00 mariadb-maxscale | 2.4 kB 00:00 mariadb-tools | 2.9 kB 00:00 updates | 3.4 kB 00:00 (1/6): epel/x86_
mysqlのデフォルトの限界に引っかかる。varchar(255)とかのutf8のカラムがあると、utf8mb4は4byte文字なので、256 x 4 で767を超える。 innodb_file_format = Barracuda innodb_file_format_max = Barracuda この二つは、innodb_large_prefixを有効にする為に必要。 対応順序 1 my.cnf修正 2 mysqld restart 3 (railsなどアプリ側でmigrateなど行うアプリケーションの場合は、migrate時にrow_formatを指定するように修正) ActiveSupport.on_load :active_record do module ActiveRecord::ConnectionAdapters class AbstractMysqlAdapter d
結論としてはinnodbテーブルの全データ量だそうです。 ここ最近はデータベースサーバのリプレースの案件の担当をしているのですが、サーバのサイジングをしていてふと、「どれくらいメモリあれば足りるんだろう」と疑問に思いました。 よく「サーバの全メモリの50%から70%くらい」とか「80%」くらいとか言われますが、それはどちらかというとスワップしないための限界値を示すものであって、理想値ではないですよね。それでいろいろ調べてみたところ、なかなか日本語で良いまとめがなかったので、まとめてみようと思います。 目次 そもそもinnodb_buffer_poolとは? 使用状況を確認する(SHOW ENGINE INNODB STATUSでの計測) 適切なinnodb_buffer_pool_sizeは?(チューニング方法) そもそもinnodb_buffer_poolとは? InnoDB maint
I have a busy database with solely InnoDB tables which is about 5GB in size. The database runs on a Debian server using SSD disks and I've set max connections = 800 which sometimes saturate and grind the server to halt. The average query per second is about 2.5K. So I need to optimize memory usage to make room for maximum possible connections. I've seen suggestions that innodb_buffer_pool_size sho
それほどDBに詳しくないアプリエンジニアが何かトラブった時にすぐさま行動して問題把握できるようになる情報を列挙しておきます。 開発時、障害時の対処療法やちょっとした定期監視方法などを対象にしています。 抜本的な対策などはインフラエンジニアさんにお任せしたほうがいいと思います。 DBはいろんな意味でこわいんでできれば触りたくないです>< 事前確認 MySQLサーバーのシステム設定値を確認しておく 以下のようにサーバーのシステム設定値を確認できます。 mysql> SHOW GLOBAL VARIABLES; # ワイルドカード(%)を用いた絞り込み mysql> SHOW GLOBAL VARIABLES LIKE 'performance_schema%'
https://github.com/rackerhacker/MySQLTuner-perl MySQLTunerはMySQLのチューニングを診断してくれるアプリケーションです。 基本的なパフォーマンスチューニングのヒントをわかりやすく表示してくれます。 MySQLのチューニング設定に不安な方や、はじめてMySQLをさわる方は試してみると良いでしょう。 ライセンスはGNU GPLで無料で使えます。 検証環境 CentOS 6.3(64bit) MySQL 5.5.28 MySQL 5.5をインストール MySQL 5.5をインストールします。 # wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm # wget http://ftp.jaist.ac.jp/pub/Linux/Fedora/epel/6/x86
しわっす!DBA 兼オペレーションエンジニア兼タスクマネージャやってる riywo です。何のネタを書こうかなぁと考えたのですが、正直ネタを仕込む時間もなかったので僕がいつもやってることをさらっと紹介するということで勘弁して下さい>< MySQL がおかしい! 03:14 hidek: なんかエラー出まくってるんだけど! 03:14 zigorou: MySQL と通信してるとこっぽい 03:15 riywo: 見ます こんなやりとりは皆さん日常茶飯事ですよね?ね?ね?こんな時に、DB に責任を持つものとして真っ先に対応するのが僕らの仕事です。でも、じゃあ具体的にこのあと何をしましょう?既にサービスはエラーだらけで一刻を争う状態です。 (対応開始) まずはエラーメッセージ 今回の様な場合はアプリのエラーログにどばっと MySQL に関するエラーが出ているでしょう。まずはそれを見ることが始ま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く