タグ

関連タグで絞り込む (7)

タグの絞り込みを解除

mysqlに関するmizdraのブックマーク (11)

  • MySQL 5.7 から 8.0 にしたらテストが激遅になった - Qiita

    この記事は、株式会社カオナビ Advent Calendar 2023 の3日目です。 はじめに 株式会社カオナビの高橋(@kunit)です。 今回は MySQL バージョンアップ(5.7 -> 8.0) で起きた問題とそれに対してどのように対処したのかを書いていこうと思います。 何が起きたのか MySQL 5.7 から 8.0 にバージョンアップをするにあたって、CI およびローカル環境でテストができるように MySQL 8.0 のイメージを作成し、それをつかって各機能の担当者にテストを開始してもらっていたのですが、以下のような事が起きました。 接続を MySQL 5.7 から 8.0 に切り替えただけでテストの時間が3倍くらいかかるようになった そこを変更するだけで3倍遅くなるってやばいぞということで報告してくれた担当者と同じテストを自分でも実施してみると再現性があり、それが以下のどの

    MySQL 5.7 から 8.0 にしたらテストが激遅になった - Qiita

  • MySQLのutf8mb4と戦った話 - Uzabase for Engineers

    皆様こんにちは、NewsPicksエンジニアの米澤です。 先日 2023/03/30は、こちらでアナウンスしていた通り、サービスの停止を伴うシステムメンテナンスを実施させて頂きました。 NewsPicksをご利用頂いている皆様には、ご迷惑おかけいたしました。 今回はこのメンテナンスの中で行われたDBテーブルのmigrationについてお話ししたいと思います。 ことの始まり やったこと 方針決め utf8mb4に対応していないテーブルを調べる migrationを作成する 影響範囲を調べる 開発環境でリハーサルを行う メンテナンスの日 最後に ことの始まり NewsPicksではバグの検知にBugSnagを利用しています。 ある時、BugSnagにこんなエラーが通知されてきました。 org.springframework.orm.hibernate4.HibernateJdbcExcepti

    MySQLのutf8mb4と戦った話 - Uzabase for Engineers
    mizdra
    mizdra 2023/05/01
    リンク

  • Docker コンテナの起動を待つ - MySQL の使い方 - [GitHub Actions]

    概要 Docker コンテナを扱う際に起動を待ちたいケースは多々あると思います。 この記事では MySQL コンテナを例に3パターンと、 Docker ではないのですが MySQL の場合プレインストールもされているので併せて紹介します。 TL;DR 長々と説明していますが重要なポイントはこの2つです。 Docker コンテナのヘルスチェック CLI から起動する場合は until や docker compose up -d --wait で待機 プレインストール GitHub ホストランナーには MySQL や PostgreSQL がインストールされています。 最初は無効化されているので sudo systemctl start postgresql.service で有効化します。 すぐに使える状態になるので起動時間は最速です。 jobs: pre-installed: runs-

    Docker コンテナの起動を待つ - MySQL の使い方 - [GitHub Actions]
    mizdra
    mizdra 2022/11/08
    --health-cmd なるほど
    リンク

  • 我々(主語が大きい)は何故MySQLで外部キーを使わないのか

    外部キー便利!!! MackerelではPostgreSQLで外部キーあり そのレコードがあることが保証される 各テーブルのidにアプリケーションレベル(Mackerelの場合Scala)で型付けをするとなお便利 MemberID型、MonitorID型 → idで誤ったテーブルを引くとかがない 本日のスキーマ CREATE TABLE `member` ( `id` INTEGER unsigned NOT NULL auto_increment, `earned_item_count` INTEGER unsigned NOT NULL DEFAULT 0, `name` VARCHAR(191) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARACTER SET utf8mb4; CREATE TABLE `item`

  • 第9回　pt-query-digestを使って遅いクエリーを発見する | gihyo.jp

    遅いクエリーの調査をしてみようとして、実運用環境でスロークエリーログを出力してみたところ、思っていたよりもたくさん出力されていしまい、もはや何が起こっているのかわからなくなってしまうことはありませんか？ スロークエリーログにいくら有益な情報が入っているとはいえ、数が多くなってしまうと一個一個確認していくのには気が遠くなるような時間と根気が必要となってしまいます。せっかくのIT技術を使っているのに人手による努力はなるべく避けたいものです。ということで大変なスロークエリーログの集計はPCやサーバにやってもらうことにしましょう。 そこで今回は、PERCONA社が公開しているPercona Toolkitのうちの、MySQLのクエリーから統計を取って教えてくれるpt-query-digestというコマンドツールについて説明をしていきます。 デモンストレーション環境 今回使用する環境は第7回　スロー

    第9回　pt-query-digestを使って遅いクエリーを発見する | gihyo.jp
    mizdra
    mizdra 2021/07/31
    リンク

  • MySQL の order by と index - まるまるこふこふ

    MySQLの order by と index の仕組みがわからなくなったので調査。 前提の自分の仮定 MySQLは降順インデックスをサポートしないので order by desc にインデックスを使用できない (user_id, point)という複合インデックスがあれば、where user_id = ? order by point ascというクエリはインデックスを最大限に使用できる 準備 MySQLのバージョンは 5.1.61 CREATE TABLE `sample` ( `id` int(10) unsigned NOT NULL, `user_id` int(10) unsigned NOT NULL, `point` int(10) unsigned NOT NULL, PRIMARY KEY (`id`), KEY `i1` (`user_id`,`point`) )

    MySQL の order by と index - まるまるこふこふ

  • Index Hintの使いどき - Qiita

    通知が多すぎて担当日を見逃してしまい、大遅刻。ごめんなさい！ Index Hintとは MySQLにはIndex Hint機能が実装されています。 ドキュメントから引用すると、こんな具合の構文ですが、要は使うINDEXを指定することができます。 tbl_name [[AS] alias] [index_hint_list] index_hint_list: index_hint [, index_hint] ... index_hint: USE {INDEX|KEY} [FOR {JOIN|ORDER BY|GROUP BY}] ([index_list]) | IGNORE {INDEX|KEY} [FOR {JOIN|ORDER BY|GROUP BY}] (index_list) | FORCE {INDEX|KEY} [FOR {JOIN|ORDER BY|GROUP BY}]

    Index Hintの使いどき - Qiita

  • [MySQL]WHERE句とORDER BY句の両方が使われている場合のINDEX

    INDEXを追加することでWHERE句でのレコードの絞り込みが速くなることは、SQLを少しでも学んだことのある人なら当たり前に知っていることだと思う。 システムを運用していく期間が長くなればなるほどレコード数は膨大になり、WHERE句で絞り込んだとしても結果として返されるレコード数が多くなってしまうこともある。 単純に絞り込んだ結果を並び順関係なく出力させる場合は問題ないが、WEBシステムやアプリなどでは、登録された日付が近いもの順でソートしたい場合や、IDが若い順でソートしたい場合など、出力結果をソートしたい場合が多々ある。 そんな時はクエリにORDER BY句を記述することで対処することがあると思うが、実はこのORDER BY句によるソートがボトルネックの原因になってしまうことがある。 WHERE句で指定しているカラムにINDEXが張ってある場合以前の記事で利用したsampleテーブル

    [MySQL]WHERE句とORDER BY句の両方が使われている場合のINDEX

  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.3.1 MySQL のインデックスの使用の仕組み

    インデックスは特定のカラム値のある行をすばやく見つけるために使用されます。 インデックスがないと、MySQL は関連する行を見つけるために、先頭行から始めてテーブル全体を読み取る必要があります。 テーブルが大きいほど、このコストが大きくなります。 テーブルに問題のカラムのインデックスが含まれている場合、MySQL はすべてのデータを調べる必要なく、データファイルの途中のシークする位置をすばやく特定できます。 これはすべての行を順次読み取るよりはるかに高速です。 ほとんどの MySQL インデックス (PRIMARY KEY、UNIQUE、INDEX、および FULLTEXT) は B ツリーに格納されます。 例外: 空間データ型のインデックスは R ツリーを使用します。MEMORY テーブルはハッシュインデックスもサポートします。InnoDB は FULLTEXT インデックスの逆のリスト

  • MySQL :: Other MySQL Documentation

    This page provides additional documentation. There's even more available on these extra pages: Archives: the documentation archives About: information about MySQL documentation and the MySQL documentation team MySQL Server Doxygen Documentation Title HTML Online

  • MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.3.6 マルチカラムインデックス

    MySQL は複合インデックス (つまり、複数のカラムに対するインデックス) を作成できます。 インデックスは最大 16 カラムで構成できます。 特定のデータ型では、カラムのプリフィクスにインデックスを設定できます (セクション8.3.5「カラムインデックス」を参照してください)。 MySQL では、インデックスで、すべてのカラムをテストするクエリーまたは最初のカラム、最初の 2 つのカラム、最初の 3 つのカラムというようにテストするクエリーにマルチカラムインデックスを使用できます。 インデックス定義の正しい順序でカラムを指定する場合、単一の複合インデックスにより、同じテーブルへの複数の種類のクエリーを高速化できます。 マルチカラムインデックスは、インデックス設定されたカラムの値を連結して作成された値を格納する行である、ソート済みの配列とみなすことができます。 複合インデックスの代わりに

  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.