フリーランスエンジニアをしているrevenue-hackです! 普段はGo言語でバックエンドを中心にやっています〜 ↓登壇したときの資料です! より図を入れて詳しく書いております! 今回はデータベースの特にRDBの仕組み(アーキテクチャ)についてざっくり理解して、なにかに役立てようぜ〜 というような内容になります。 ↓記事はこちらに移しました!↓
![データベースの仕組み(アーキテクチャ)をざっくり理解する](https://cdn-ak-scissors.b.st-hatena.com/image/square/fbf55e58d74b08ba7cff704c48d8aac9df8644f0/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--zoMx90ae--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%2525E3%252583%252587%2525E3%252583%2525BC%2525E3%252582%2525BF%2525E3%252583%252599%2525E3%252583%2525BC%2525E3%252582%2525B9%2525E3%252581%2525AE%2525E4%2525BB%252595%2525E7%2525B5%252584%2525E3%252581%2525BF%252528%2525E3%252582%2525A2%2525E3%252583%2525BC%2525E3%252582%2525AD%2525E3%252583%252586%2525E3%252582%2525AF%2525E3%252583%252581%2525E3%252583%2525A3%252529%2525E3%252582%252592%2525E3%252581%252596%2525E3%252581%2525A3%2525E3%252581%25258F%2525E3%252582%25258A%2525E7%252590%252586%2525E8%2525A7%2525A3%2525E3%252581%252599%2525E3%252582%25258B%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3Arevenue-hack%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyLzEwY2M5OWNkNGYuanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
はじめに 再帰演習の定番である「ハノイの塔」をSQLで解きます。基本OracleのSQLで記述していますが、特別なことをしているわけではないので、再帰が使えるSQLであればすこしの手直しで簡単に書き換えらます。ということで最後にPostgreSQL版とMySQL版も載せています。 ハノイの塔の再帰アルゴリズム ハノイの塔には非常に有名な再帰記述アルゴリズムがあります。「複雑そうな動きも再帰で記述するとこんなに簡単になるんだよ」と言える代表格みたいなやつですね。 アルゴリズム等の詳しい解説に関しては下記のサイト等を参考にしてください。他にも「ハノイの塔」で検索すればたくさん出てくると思いますのでここでは簡潔に説明します。 ハノイの塔を攻略せよ まず上記のHANOI関数ですが、『第一引数(N)個のタイルの山を第二引数(ORIG)から第四引数(DEST)にまとめて移動する』ものであると考えてくだ
仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO
問題 こんなテーブル a があります。 create table a (id int, flag int); こんなふうにデータを入れて、 insert into a (id, flag) values (1, 1), (2, 1), (3, 0), (4, 0), (5, 1); こんなふうになっているとします。 select * from a; +----+------+ | id | flag | +----+------+ | 1 | 1 | | 2 | 1 | | 3 | 0 | | 4 | 0 | | 5 | 1 | +----+------+ なるべく単純な1つのSQLで、すべてのレコード数と、flag=1のレコード数と、flag=0のレコード数を取得せよ。 なお、サブクエリは使わないこと。 ヒント 集計を3つしたいので、こうなる? select count(????), c
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約?を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか?そのためにはまず現在どのようにクエリが実行さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く