タグ

ブックマーク / gihyo.jp (34)

  • 第134回 DDLと暗黙的なコミットについて | gihyo.jp

    皆さんはMySQLを開発に利用している時に、カラム追加や変更を同時に行いたい場面によく出くわすと思います。特に、Webアプリケーションフレームワークなどで用意されているデータベーススキーマのマイグレーションツール等を利用している時に、マイグレーション途中で失敗して中途半端に適用されてしまう、なんてことがあるかもしれません。 マイグレーションが中途半端に適用されてしまった場合、マイグレーションツールでは簡単に元に戻せず、スキーマの復旧のためにmysqlでログインして手作業で復旧するはめになってしまって困った経験がある方もいるかも知れません。そういうアトミック性が欲しい時は、トランザクションを利用して…と、考えると思いますが、これは実は上手くいきません。 今回はその理由である「暗黙的なコミット」について解説していきたいと思います。 検証環境 今回は、第125回 phpMyAdminでDocke

    第134回 DDLと暗黙的なコミットについて | gihyo.jp
  • 第131回 mysqldumpslowを使ってスロークエリログを解析してみる | gihyo.jp

    皆さんはスロークエリログを活用していますでしょうか。今回はこの連載でも第7回 スロークエリーログを使って遅いクエリを収集するや第113回 anemoeaterを使ってスローログを可視化してみるで紹介させていただいた、スロークエリログ関連のお話となります。 今回は、mysqldumpslowという、スロークエリログをもっと便利にするコマンドラインツールについて紹介していきます。mysqldumpslowという字面を見ると、mysqldumpでじっくりと時間をかけてダンプファイルを取ってきてくれると思い浮かべるかもしれませんが、全くの別物なので注意しましょう。 検証環境 今回の検証環境は、第125回 phpMyAdminでDockerで建てたMySQLにアクセスするで記載したdocker-composeを利用して作成します。手元で簡単に試せるように、githubの筆者のレポジトリにサンプルコー

    第131回 mysqldumpslowを使ってスロークエリログを解析してみる | gihyo.jp
  • 第130回 クエリをプロファイリングしてみる | gihyo.jp

    mysql> SHOW PROFILE SOURCE; +--------------------------------+----------+---------------------------+----------------------+-------------+ | Status | Duration | Source_function | Source_file | Source_line | +--------------------------------+----------+---------------------------+----------------------+-------------+ | starting | 0.000092 | NULL | NULL | NULL | | Executing hook on transaction | 0.0

    第130回 クエリをプロファイリングしてみる | gihyo.jp
  • 第61回 いよいよ連載6年目、MySQL Database Service本格展開開始、PostgreSQLのリリース情報とイベント情報 | gihyo.jp

    この記事は開催前に執筆しており、実施状況をお伝えすることができませんので、次回にご報告したいと思いますが、簡単なメモと公開される発表スライド資料・ビデオへのリンクを、OSSコンソーシアムのWebサイトにも掲載しておきます。ビデオの公開は一部の内容になる可能性があります。 [MySQL]2020年8月の主な出来事 2020年8月はMySQLの製品リリースはありませんでした。8月27日にはMySQL 8.0へのバージョンをテーマにしたセミナーとして、KDDIでのMySQL 8.0導入事例紹介があり、MySQLサポートチームの奥野氏などが登壇した、オンラインのイベントMySQL Day Virtual Event in Japanが開催されています。 7月にリリースされたMySQL 8.0.21に関するMySQL開発チームやコミュニティチームのブログのリストはMySQLチームのブログにてご紹介し

    第61回 いよいよ連載6年目、MySQL Database Service本格展開開始、PostgreSQLのリリース情報とイベント情報 | gihyo.jp
  • 第45回 Linuxカーネルのコンテナ機能 ― cgroupの改良版cgroup v2[6] | gihyo.jp

    昨年12月に前回の記事を書いて以来、世の中の状況がすっかり変わってしまいました。 筆者も4月以降はほとんど会社に出勤することなく、自宅で仕事をしています。自宅の物置のように使っていたスペースを片付け、少しずついろいろなものを買い揃え、自宅でもまずまず快適な環境で仕事ができるようになりました。同様に、これを機に自宅でも快適に仕事ができるようにいろいろと買い揃えた方も多いのではないでしょうか。残念ながら、自宅の環境が快適になったからと言ってこの記事の公開ペースが速くなるということはありませんが。:-p さて、年末に書いた記事ではケーパビリティの話を3回に渡って説明しました。今回はそのケーパビリティシリーズの前に紹介していたcgroup v2の話題に戻って、その機能を紹介していきたいと思います。 cgroup v2とCPUコントローラ この連載の第37回で書いたように、cgroup v1は自由度

    第45回 Linuxカーネルのコンテナ機能 ― cgroupの改良版cgroup v2[6] | gihyo.jp
  • 第56回 MySQLの高可用性構成案、PostgreSQLのかなり気の早い新バージョン情報 | gihyo.jp

    連載第55回でご紹介したMySQL InnoDB ReplicaSetは、従来型のレプリケーションの運用管理の効率を向上させることに主眼をおいて開発されているパッケージです。データの複製は非同期レプリケーションとなり、データベースの自動フェイルオーバー機能もないため、高可用性構成しては物足りない面もあります。 MySQL InnoDB Clusterで利用されているグループ・レプリケーションはコミットされたトランザクションが他のノードに複製されることが保証できるため、高可用性を求める場合にはより適切な選択肢となります。参照時のノード間のデータ整合性は設定により変更できます。ただし、グループ・レプリケーションの要件にはGTID(Global Transaction IDentifier)や行ベースのバイナリログが含まれているほか、制約事項のひとつとしては利用可能なストレージエンジンがInno

    第56回 MySQLの高可用性構成案、PostgreSQLのかなり気の早い新バージョン情報 | gihyo.jp
  • 新世代のコードエディタ「Visual Studio Code」を大活用!:新刊ピックアップ

    エンジニアにとってのテキストエディタは,料理人にとっての包丁のようなもの。コーディングはもちろん,設定ファイルやデータを編集したり,人によってはメールや報告書などの文書をエディタ上で書くという方もいらっしゃるかもしれません。日々のプログラミングにIDE(Integrated Development Environment,統合開発環境)を使うとしても,エディタをまったく使わずに仕事ができるかといえば……なかなか難しいのではないでしょうか。 歴史あるVimEmacsをはじめとして,世の中にはさまざまなエディタがあります。秀丸エディタやサクラエディタも定番ですね。もちろん,Windowsにはじめから付属している「メモ帳」だってりっぱなエディタです。そんな中で,近年注目されているエディタに「Visual Studio Code」(⁠以下,VSCode)があります。 Visual Studio

    新世代のコードエディタ「Visual Studio Code」を大活用!:新刊ピックアップ
  • 第117回 MySQL 8.0のオプティマイザーヒント | gihyo.jp

    MySQLでは、オプティマイザーヒントを使用してオプティマイザーを制御することで、実行計画を変更することができます。このオプティマイザーヒントはステートメントに適用できるため、ステートメント単位で最適化が可能になります。MySQL 5.7とそれ以降から使用可能です。 今回は、MySQL 8.0から追加されたオプティマイザーのヒントを主に紹介したいと思います。 オプティマイザーヒント構文 オプティマイザーのヒントは/*+ ... */をステートメント内に記述します。SELECT、UPDATEやDELETEなどのDMLのキーワードの後にヒントを記述します。ヒントの内容をパーサーが認識して処理します。以下のように記載します。 mysql> SELECT /*+ hint */ ... mysql> UPDATE /*+ hint */ ... 指定したヒントが有効か確認するには、EXPLAIN後

    第117回 MySQL 8.0のオプティマイザーヒント | gihyo.jp
  • 第114回 MySQL 8.0から使えるさまざまな権限について | gihyo.jp

    MySQLには、さまざまな操作や動作レベルにおいて適用される権限があります。それらは権限レベルによって分けられています。権限レベルについては、以前の記事 第69回 MySQLの権限レベルについてをご参照ください。 また権限の管理方法として、MySQL 5.7とそれ以前までは、静的権限のみで管理されていました。MySQL 8.0からは動的権限が追加されました。静的権限はすでにサーバに組み込まれた権限であり、動的権限はほとんどのものがサーバ起動時に定義されます。中にはプラグインやコンポーネントをインストールすることによって定義されるものもあります。 今回は、MySQL 8.0から追加された権限について紹介したいと思います。MySQLは2020/01/10現在最新のMySQL 8.0.18を使用しています。 静的権限 MySQL 8.0から新たに追加された権限はCREATE ROLEとDROP

    第114回 MySQL 8.0から使えるさまざまな権限について | gihyo.jp
  • 第112回 知っておくと便利になるかもしれない小技 | gihyo.jp

    今回はMySQLを利用するうえで、知っていると便利になるかもしれないちょっとした小技をいくつか紹介しようと思います。なお、利用するMySQLのバージョンは8.0.18、OSはCentOS 7を利用しています。 STRAIGHT_JOINの位置 第97回 JOIN_ORDERを使ってJOINの順番を決めるにて、バージョン8.0以降ではJOIN_ORDERヒント句を用いてJOINの順番を決めるやり方と、バージョン5.7とそれ以前ではINNER JOINに限り、STRAIGHT_JOINを用いて駆動表を選択することができることを紹介しました。 みなさんはこのSTRAIGHT_JOINを記述するやり方が複数あるのはご存知でしょうか? 1つ目の記述は、INNER JOINの記述をSTRAIGHT_JOINに書き直すやり方です。たとえば、第97回で利用した下記クエリを参考にしてみましょう。 mysql

    第112回 知っておくと便利になるかもしれない小技 | gihyo.jp
  • 第110回 Invisible Indexesを使って気軽にチューニングを始めてみる | gihyo.jp

    使用されず役に立たないインデックスを定義するのは、SQLアンチパターンの1つ「インデックスショットガン」として知られています。使用されていないインデックスを定義するのは、ディスク容量を圧迫して、さらに更新コストも掛かるという良いこと無しな状態です。 ただ実際には、あなたが使用されていないインデックスを見つけたとしても、安易にドロップするのは非常に危険です。ドロップするのは時間がかかりませんが、インデックスを再構築するまでには時間がかかります。 もしも万が一そのインデックスが使用されているクエリが存在するとしたら、その時点から障害につながってしまう可能性があります。ドロップはしたくないけど、使わないようにして影響を確認したい……、今回はそんな時に便利なMySQL 8.0の新機能「Invisible Indexes」を使ってインデックスを外した時の影響を調べてみましょう。 検証環境 今回はDo

    第110回 Invisible Indexesを使って気軽にチューニングを始めてみる | gihyo.jp
  • 第109回 主キーを必須にさせる | gihyo.jp

    MySQLはバージョン8.0.13からsql_require_primary_keyというオプションが追加されました。このオプションを追加することで、作成するテーブルに主キー(プライマリキー)をつけなければ作成できないような制限を入れることができます。今回はこのオプションについて説明していきます。なお、検証環境はCentOS 7、MySQL 8.0.18になります。 sql_require_primary_keyについて sql_require_primary_keyは、my.cnfなどの設定ファイルに設定するか、SET構文を用いて設定することができます。設定はSELECT構文でシステム変数を確認するか、SHOW VARIABLES構文で確認できます。 mysql> SELECT @@sql_require_primary_key; +---------------------------

    第109回 主キーを必須にさせる | gihyo.jp
  • 第108回 MySQLのコスト見積もりを調整する | gihyo.jp

    MySQLでは実行計画を生成するために、コストモデルを採用しています。オプティマイザーは実行計画を生成するために、さまざまなオペレーションからコストを見積もります。その際にベースとなる推定値が、mysqlデータベースのserver_costとengine_costテーブルに格納されていています。MySQL 5.6とそれ以前はコストパラメータの値は定数としてハードコードされていましたが、MySQL 5.7とそれ以降からはコストパラメータの値を変更することが可能になりました。 今回はMySQL 8.0.17を使用して、コスト見積もりを調整する方法について紹介したいと思います。 server_costテーブル server_costは、一般的なサーバー操作のオプティマイザーの見積もりが格納されているテーブルです。SELECTしてみると、以下のようになっています。 mysql >SELECT *

    第108回 MySQLのコスト見積もりを調整する | gihyo.jp
  • 第590回 Windows/macOS/Linuxで使える仮想マシン管理ツール『multipass』 | gihyo.jp

    multipassはWindows/macOS/Linuxで使える仮想マシン管理ツールです。特にUbuntuサーバーのインストールされた仮想マシンを気軽に用意したい時に、その効果を発揮します。今回は「オンプレミスで動くなんちゃってAWS EC2」的に利用できるmultipassのかんたんな使い方を紹介しましょう。 LXDのようなインターフェースを備えたCLIツール multipassはCanonicalが開発している、Windows/macOS/Linuxで使える仮想マシン管理ツールです。まだ「ベータ版」という扱いではあるものの、次のような機能を備えており、気軽にUbuntuがインストールされたサーバーインスタンスを構築できるのが特徴です。 CLIをメインにしたUI コマンド1つで仮想マシンを作成&起動できる 仮想マシンの作成・起動・停止・削除に加えて、ログインやファイルのやり取りもコマン

    第590回 Windows/macOS/Linuxで使える仮想マシン管理ツール『multipass』 | gihyo.jp
  • 第8回(最終回) まとめ――SQLから逃げない! | gihyo.jp

    記事は、『Software Design 2019年8月号』の第2特集「ゲームを題材に学ぶ 内部構造から理解するMySQL」をWeb掲載用に再編集したものです。 記事のテーマを、より基的なところから丁寧に解説した『SQLの苦手を克服する データの操作がイメージできれば誰でもできる』が2019年8月26日に発売されました。記事と併せてご活用ください。 SQLはボトルネックか? 筆者はチューニングの仕事に携わることが多いのですが、その経験からシステムで一番ボトルネックになりやすいのがRDBMSSQL)だと断言できます。筆者の20年以上のキャリアの中で、途中で廃れてしまったり、流行りだしたりといった言語は数知れずあります。しかし、SQLは使われ続けていますから、SQLが最も息が長いと言えますし、今でも一番シェアが高いと言えるでしょう。それにもかかわらず、SQLの理解は進んでいません。

    第8回(最終回) まとめ――SQLから逃げない! | gihyo.jp
  • 第106回 Docker Composeを使って便利にMySQLを利用してみる | gihyo.jp

    DockerMySQLを利用する方法に関しては、以前第5回 Dockerで複数バージョンのMySQLを開発環境に用意するで紹介させていただきました。大分間が空いてしまいましたが、今回はDocker Composeというオーケストレーションツールを作って実際にアプリケーションを開発する際に便利にMySQLを活用していきたいと思います。 検証環境 今回はmacOS Mojave(10.14.6)上で、Docker Desktop for mac(2.1.0.3)を利用して検証を行っています。WindowsでもDocker Desktopがインストールできる環境であれば同様に実行することができると思います。Linuxを利用している場合には、dockerパッケージのインストールとpip install docker-composeなどを利用してdocker-composeを追加でインストールする

    第106回 Docker Composeを使って便利にMySQLを利用してみる | gihyo.jp
  • 第5回 DB側でやること、アプリ側でやることを見極めよう | gihyo.jp

    記事は、『Software Design 2019年8月号』の第2特集「ゲームを題材に学ぶ 内部構造から理解するMySQL」をWeb掲載用に再編集したものです。 記事のテーマを、より基的なところから丁寧に解説した『SQLの苦手を克服する データの操作がイメージできれば誰でもできる』が2019年8月26日に発売されました。記事と併せてご活用ください。 「JOINDBサーバの負荷が高くなる」は当か? 「⁠JOINは複雑なので、単純なSQLに分割してぐるぐる系で取得すれば、処理が遅くなったとしても、DBサーバの負荷は減る」と考えているエンジニアが実際に存在します。前回解説したとおり、SQLのオーバーヘッドの大きさをイメージできれば、「⁠そんなことはない」と理解できたかもしれませんが、さらに深く理解するために、稿ではJOINを分割したときと、JOINしたときの違いを見てみましょう。

    第5回 DB側でやること、アプリ側でやることを見極めよう | gihyo.jp
  • 第4回 NoSQLとSQLの使いどころを知ろう | gihyo.jp

    記事は、『Software Design 2019年8月号』の第2特集「ゲームを題材に学ぶ 内部構造から理解するMySQL」をWeb掲載用に再編集したものです。 記事のテーマを、より基的なところから丁寧に解説した『SQLの苦手を克服する データの操作がイメージできれば誰でもできる』が2019年8月26日に発売されました。記事と併せてご活用ください。 「NoSQLRDBMSより高速」は当か? NoSQLが登場したころ(あるいは、今でも⁠)⁠、「⁠NoSQLRDBMSに比べて20倍高速」などというホワイトペーパーが出たりすることがあり、「⁠20倍」という表現が独り歩きすることがよくありました。この倍率については、レコード長やページサイズ、その他もろもろのチューニング項目をどうするかで、いかようにも変化しますからほぼ意味がないうえ、実際のシステムでそれほどの差が出ることはありませ

    第4回 NoSQLとSQLの使いどころを知ろう | gihyo.jp
  • 第105回 MySQLでドローンを飛ばしてみる | gihyo.jp

    去年のクリスマスに第87回 MySQLでケーキを焼いてみるという記事を発表させていただきました。その後ご縁がありまして8月29日から8月31日まで開催されていたBuilderscon 2019の前夜祭で発表を行ってきました。Buildersconでよく言われることは「ブログを書くまでがBuilderscon」という話がされます。 今回はそのブログに代わりまして、Buildersconで学んだことを利用してMySQLでドローンを飛ばしてみようと思います。この記事では実際にドローンを飛ばす記事となります。この記事を追試される場合には、ドローンを飛ばす際の法律などに注意して飛ばしましょう。 また、落下や破損などで怪我をする可能性も普段の記事と比べて高いので、周りをよく見て注意をして安全を確認して行いましょう。 参考にさせていただいた発表 今回の道普請便りの発端としては、同じくBuildersco

    第105回 MySQLでドローンを飛ばしてみる | gihyo.jp
  • 第102回 MySQLのROLE[その1] | gihyo.jp

    MySQL 8.0の新機能の1つにROLEというものが追加されました。 ROLEの追加によって、同じ権限を持つユーザーの作成や権限の管理がやりやすくなりました。他のRDBMSを利用した経験がある人にとっては馴染みのある機能かも知れません。今回は、MySQL 8.0で追加されたROLEの機能について確認していきます。 なお、実行環境はCentOS7、MySQLは8.0.17を利用しています。 ROLEの説明 MySQLの公式ドキュメントによると、ROLEは名前のついた権限の集合というふうに書かれています。従来のユーザーアカウントのように、この名前付きの権限の集合(以下、ROLE)には権限を与えたり、剥奪したりすることが可能です。たとえば、ユーザーAにロールA'を与えたとします。このA'のロールをユーザーBにも付与した場合、ユーザーAとユーザーBは同じ権限を持っている状態になります。以下の内容

    第102回 MySQLのROLE[その1] | gihyo.jp