SQLの達人への道: MySQLでの高速・効率的クエリ作成術 - Qiita
データベースとテーブルの作成 テスト用のデータベースtestdbを作成し、パフォーマンスチューニングを検証するためのcompanyおよびpersonテーブルを定義します。 CREATE DATABASE testdb; USE testdb; CREATE TABLE company ( company_id INT AUTO_INCREMENT PRIMARY KEY, company_name VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE person ( person_id INT AUTO_INCREMENT PRIMARY KEY, company_id INT, person_name VARCHAR(255) NOT NULL, email VARCH
閉包テーブル (Closure Table) に順序を持たせソートした結果を取得する - Qiita
はじめに 対象となる読者 ツリー構造のデータを RDB で扱うために閉包テーブル (Closure Table) を検討している人 閉包テーブルで順序を保持する方法を探している人 この記事を読んだ後できるようになること 閉包テーブルで順序を保持する方法がわかります 閉包テーブルから深さ優先探索 (前順・先行順・前置順・行きがけ順) でソートした結果を取得できます この方法を採用する場合に注意すべき点がわかります この記事を書いたときの環境 DB: PostgreSQL 9.6.1 なぜ閉包テーブル (Closure Table) を採用しようと思ったか 今まではツリー構造のデータを扱うときに入れ子集合 (Nested Set) を採用することが多かったのですが、このモデルの問題はノードを挿入するために隙間を開ける必要があり、挿入するノードの right より大きい left or/and
PhpStormとXdebugでステップ実行 ①ステップ実行するための設定 - Qiita
概要 Xdebugを使ってみたので、分かったことや分からないままのことをまとめました。 (2021/8/18追記：Xdebugはコードリーディングが辛いときに利用したくらいで、記事を投稿した時期以降は利用していません。コードを読むのに慣れてくるとXdebugが無くてもなんとかなります。Xdebugを利用すると動作が遅くなることがあるので、導入の際には十分検討してください。) ※設定については、Dockerを利用している前提で説明します。 PhpStormの機能については、PhpStormでステップ実行するならどんな環境でも参考になると思います。 (InteliJについて書かれた記事も参考にしたので、JetBrainsのIDEを利用しているなら大体同じかもしれません) Dockerについて この一連の記事が分かりやすいので参考にしてください。 【Docker Compose】設定内容を1行ず
MySQLパフォーマンスチューニング -my.cnfの見直し- - Qiita
※RDSは使っていません。 負荷を見てみる DBサーバーの負荷状況を見てみます。 当時の監視ツールの画像がないのですが、以下の状況でした。 LA(Load Average)が突き抜けている リクエスト数は「常識的に考えて」それほどでもない メモリの使用量にあまり変化がない swapはしていない ストレージ容量を結構食っている WEBサーバーから見れば、処理待ちのままプロセスが処理されていない典型的なパターンだったと思います。 DBサーバーとしては、LAに対し、メモリの使用量があっていないように思われました。 仮説 上記の状態から、仮説を立てます。 スロークエリ が頻発しているのではないか メモリ が正しく割り当てられていないのではないか 各種ログ の設定が適切ではないのではないか 仮説を検証することで、対策をしていきます。 設定を見直す 上記の仮説の設定は、MySQLの設定ファイルである「
MySQLの文字コードとCollation - Qiita
まずMySQLの文字コードですが絵文字のみでなく、JIS X 0213の第3・4水準漢字の 一部にUTF8 4バイト文字があり（まぁまず使われないと思いますが）、 MySQLの文字コードはこれからはutf8mb4一択のようです。 charsetは、サーバ、クライアント、サーバー/クライアント感の接続、データベース、、テーブル、カラムで個別に指定でき、 問題を起こさないようにするには、すべて揃えたほうが無難であります。 character_set_server=utf8mb4 character_set_client=utf8mb4 character_set_connection=utf8mb4 character_set_database=utf8mb4 character_set_results=utf8mb4
さよなら本番サーバー - Qiita
とあるSESの現場では本番リリースの時期が近づいてきており、僕を含めた数人のエンジニアは間に合いそうもない残作業の開発を進めたり、本番で使うためのデータの整備を本番サーバー内で行ったりしていた。ほとんどがその案件のために集められたメンバーだったため特に和気あいあいとするでもなく、エアコンの風の音が響く小さなオフィスの片隅で静かに作業をしていた。 業務上のやりとりもRedmineで行われており、声を発するのもたまにメンバー同士で話をしたり、クライアントから電話がかかってきた時だけ。その日もメールで通知が届いてきており、確認してみるとRedmineで僕が関係しているチケットにコメントが届いているという通知だった。 通知のURLをクリックしてRedmineのチケットを確認してみる。 それによると一旦本番サーバー上に存在するデータの中の一部の主要データをCSV形式で送ってほしいという依頼だった。無
サービス稼働中にMySQLでALTER TABLEしたら Waiting for table metadata lock が溢れて死んだ - Qiita
サービス稼働中にMySQLでALTER TABLEしたら Waiting for table metadata lock が溢れて死んだMySQL ALTER TABLEすると以下のような挙動でカラム変更されるようです 他のセッションからのREADを許可し、WRITEをブロック 新しいtable定義の一時テーブルを作成 一時tableに元tableのデータをすべてコピー 一時tableを元table名にリネームして元tableを削除 ブロックされていたWRITE系クエリを反映 全コピしてるので、ALTER TABLEを実行する時にどでかいtableのサイズの場合は長い時間WRITEがブロックされるので注意が必要です。 ALTER TABLEを実行した環境 上記を踏まえた上で、以下のようなテーブルにALTER TABLEを実行してカラム追加する事にした レコード数はちょっとしかない READ
ソシャゲエンジニアの自分が開発に必須だなと思った知識（MySQL編） - Qiita
この記事の目的 自分は、とある会社様の元でソシャゲの API 開発をさせていただいています。 ソシャゲは、リリース時やイベント時などに集中アクセスされやすく、負荷軽減の知識がない状態で開発を行ってしまうと、運用時に緊急メンテ祭りになりやすいジャンルかなと思っています。 これまで培ってきた MySQL の知識ですが、脳内メモリ量の関係上、暗記できないのでメモしておこうというのが主目的です。 ここ数年ほどソシャゲ開発しかしていないため、偏っている感がある内容ですのでご注意ください。 概要 ストレージエンジンは InnoDB。メインで扱っている MySQL バージョンは 5.6。 記事の内容ですが、これらのキーワードを見て、おおよそ分かる方は読む必要はないかと思います。 インデックス系 クラスタインデックス カバリングインデックス EXPLAIN で注意するべき値 トランザクション系 MVCC
dockerコンテナからローカル上のmysqlに接続する(docker ver17.06以降) - Qiita
諸事情によりローカルに作ったmysqlにdockerコンテナから接続する必要があったので調べました。 2022/01/27追記 Docker desktop4.3.0において、記事で紹介しているdocker.for.win.localhostとdocker.for.mac.localhost両方ともは非推奨になりました。（なぜかwindowsのリリースノートもmac用のDNSが乗ってますが……） https://docs.docker.com/desktop/windows/release-notes/#docker-desktop-430 https://docs.docker.com/desktop/mac/release-notes/#docker-desktop-430 今後は変わりに以下のDNSにアクセスすれば良いとのことなので、記事は適宜読み替えるようおねがいします。macもw
丁寧すぎるDocker-composeによるrails5 + MySQL on Dockerの環境構築(Docker for Mac) - Qiita
丁寧すぎるDocker-composeによるrails5 + MySQL on Dockerの環境構築(Docker for Mac)RubyMySQLDockerdocker-composeRails5 はじめに Dockerの勉強も兼ねてrailsのアプリをコンテナに作ろうとしたが環境構築にアホみたいに時間がかかった。 Dockerもrailsも（もはや初歩的なコマンドすら）不慣れなプログラマを救いたいので、手順を書きます。 あとDockerはこれからrailsエンジニアになる人が合わせて使えるようになっておけばスキルとして加点になるので（新しめの技術なので供給量的にも）、勉強のきっかけになればと。 この手順すらめんどくさいと思った方へ(2019-02-04追記) 何もない状態からrailsサーバーとMySQLのコンテナを立ててくれるシェル ※真面目に作りを意識しながらやった方が今後応
Docker で MySQL コンテナーがなぜか起動できない問題 - Qiita
Ubuntu 上でなぜか MySQL コンテナーが起動せず、ハマりました。ワークアラウンドをメモしておきます。 再現環境 Ubuntu 16.04.2 LTS 64bit (on Vagrant) 現象 以下のような docker-compose.yml を作成して、 docker-compose up -d db で起動しようとしても、 Exit 1 で終了してしまいます。 version: '2' services: db: image: mysql:5.6 ports: - "3302:3306" environment: - TZ=JST-9 - MYSQL_USER=foo - MYSQL_PASSWORD=foo - MYSQL_ROOT_PASSWORD=foo - MYSQL_DATABASE=foo volumes: - ~/foobar/db/mysql/dump/:/
複数列indexの順序と選択性 - Qiita
複数列indexの順序を決める時にどういう順番で並べますかっていうと 選択性の高い列から並べるのが原則 それじゃ、最近のDBでセオリー通りのindexとそうじゃない順序のindexでどれくらい差が出るもんなの、というのを単純なケースで試してみる DB:MariaDB 10.0.11 OS:Ubuntu 14.04 マシン:thinkpad t440p(ssd) テーブルとindex テーブルとテストは前回も使用したのを流用する http://qiita.com/k_o_gj/items/a663692c3389ec7cc29d CREATE TABLE event_test( id BIGINT AUTO_INCREMENT, event_id INT NOT NULL DEFAULT 0, user_id INT NOT NULL DEFAULT 0, status INT NOT NU
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
