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倍遅くなるってやばいぞということで報告してくれた担当者と同じテストを自分でも実施してみると再現性があり、それが以下のどの
TablePlus、MySQLやPostgreSQL, SQL Serverをサポートしたデータベースマネージャーアプリ「TablePlus for iOS」をリリース。
TablePlusがMySQLやPostgreSQL, SQL Serverをサポートしたデータベースマネージャーアプリ「TablePlus for iOS」をリリースしています。詳細は以下から。 MacとWindowsのクロスプラットフォームに対応したデータベースマネージャーアプリ「TablePlus」を開発＆販売しているシンガポールのTablePlus Inc,は現地時間2019年06月24日、予告していたとおりiOS向けのデータベースツール「TablePlus for iOS」を新たにリリースしたと発表しています。 The recent generation of iPad Pro models was considered as a great step forward from the previous iPad generations with a better design,
InnoDBのREPEATABLE READにおけるLocking Readについての注意点
本日は、MySQL Casual Advent Calendar 2013の20日目である。というわけでカジュアルに小ネタを紹介しよう。 MVCC - Multi Version Concurrency Controlご存知の通り、InnoDBはMVCCを実装している。そのため、分離レベルがREPEATABLE READの場合には、行にロックをかけることなく、一貫した読み取りが可能になっている。 もし、あるトランザクションT1開始後に、別のトランザクションT2によって同じ行が書き換えられてしまった場合には、T1はロールバックセグメントにある古いバージョンの値を読み取ることができるので、T1内で実行したSELECTは常にT1開始時点のデータを参照することができるのである。大事なのでもう一度言うが、REPEATABLE READにおける単純なSELECTでは行ロックは必要ない。 Lost Up
MySQLの「Sending data」はクライアントへのデータ転送ではない・・・ - 私の歴史と今
MySQLのshow processlistで「Sending data」と表示されている処理はデータ転送だと思っていたが、そうではなかった・・・。先入観って恐ろしい。 今日はサーバが重かったので調べてみたらすべてのコネクションが「Sending data」となっており、処理に3分以上かかっていた。slow queryのログを見ると「limit 1」の検索ばかり。転送なんてあっという間のはず。と思って調べてみたら「Sending data」はクライアントへのデータ転送ではなかった。 「This is quite a misleading status. It should be called "reading and filtering data".」 → http://stackoverflow.com/questions/10347193/what-does-it-mean-when-
なぜMySQLのサブクエリは遅いのか。
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
SQL改善によるパフォーマンス向上 - mic_footprints
事例 実際にアプリケーション開発を行っていて、検索機能を実装していたときに超絶重い検索ロジックに出会いました。 その対処をSQL文の改善で行なったので紹介します。 データ構造 環境 MySQL 4.1 mysql> DESCRIBE users; +-------+-------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------+-------------+------+-----+---------+----------------+ | id | int(11) | | PRI | NULL | auto_increment | | name | varchar(40) | YES | | | | +-------+-------
我故意没有穿内裤坐公车让,少妇洗澡作爱,色妺妺免费影院
我故意没有穿内裤坐公车让,少妇洗澡作爱,色妺妺免费影院,亚洲欧洲无码专区AV,成年无码专区在线蜜芽TV,亚洲人成人77777网站,日本BBWBBW高潮BBW,久久99精品久久久久久婷婷,少妇按摩推油舒服到高潮连连,撕开奶罩揉吮奶头完整版
MySQLではIN句とサブクエリの組み合わせはインデックスが効かない！？
な、なんと person_diaryはインデックスが適用されずにフルスキャンされ（１行目のkeyがNULL） 逆にpersonはid列に設定してあるプライマリキーが適用される(2行目のkeyがPRIMARY) という二つの謎な現象が発生しました。 そもそもpersonはnameカラムに対してLIKE検索しているのに、id列のプライマリキーが効いちゃうのは全く納得いきません。なぜ、どうしてこんなことが起こるのでしょう？ 原因 私がMySQLに期待していた動きとしては ①サブクエリを実行してperson.idのリストをメモリ中に作成 ②person.person_idに張られているインデックスを使って検索 というところでした。 期待通りに動いてくれなかったのには二つのMySQLの特性が関係していました。 特性① サブクエリを含むSQLは外側から先に実行される MySQLの場合、サブクエリを含む
Facebook、Twitter、PayPal、LinkedInのMySQL担当者は、MySQLをどう使い、何を課題だと考えているか～MySQL Connect 2013
Facebook、Twitter、PayPal、LinkedInのMySQL担当者は、MySQLをどう使い、何を課題だと考えているか～MySQL Connect 2013 Facebook、Twitter、PayPal、LinkedInのMySQL担当エンジニアが集まり、それぞれの社内のMySQL利用状況、課題、これから期待する新機能などを語ったパネルディスカッションが、9月21日から23日までサンフランシスコで開催されたMySQLのイベント「MySQL Connect」の3番目の基調講演として行われました。 世界でもっともヘビーなMySQLユーザーといえる4社は、MySQLについてどのようなことを考えているのか、基調講演の内容をダイジェストで紹介しましょう。 Current MySQL Usage Models and Future Developments ──── まずはそれぞれの所
バイナリログ(mysql-bin)の運用について - メモとかそんな感じなやつ
サーバ運用における基本的な監視にディスクの容量監視があります。 ディスクの使用率が100%になるとサービスに影響がでるのはもちろんですが、 サーバ管理者として100%になるまで気が付かないと恥ずかしかったりします。 (落ちた原因はなんだよ！！！ → デ、ディスクの使用率が100%です(///)ってなる) なのでだいたい90%を閾値にディスクの使用率監視をしているのですが、 アラートを検知してそれがMySQLの動いてるサーバだとバイナリログの肥大化を疑います。 バイナリログは更新系のログが記録されますが、放っておくと際限なく増えるので ディスク逼迫の原因になってしまいます。 ので不要なログは定期的に削除したりしますが、そのまとめ。 expire_logs_days my.cnfに [mysqld] expire_logs_days=10と設定したり、set global で mysql> s
MySQLにおける10の最適化設計 - 憂鬱なプログラマの形而上学
MySQLさて、ここでコーヒーブレークして、MySQLの最適化について考えてみたいと思います。MySQLデータベース分散処理では、SQLを複数のサーバーやテーブルへと分散する方法についてご紹介させて頂きましたが、こちらは主に、個々のDBサーバーの最適化について考えてみたいと思います。大きくわけると、MySQLにおいては、以下のことがポイントになるかなと思います。（レプリケーションなどの分散系は他でさんざん触れているのでここでは割愛します）重要だと思う順番に列挙します。１．とにかく分析。できるだけ実際に近いデータでEXPLAINの結果を見たり、slow-queryを分析します。また、CPUの使用状況として、vmstatなどで、できるだけ常にiowaitが0近い状態にします。MySQLは癖が強いので、特に慣れていない人はセオリー通りにいかないことは結構あると思います。ですので、実際の分析を何よ
MySQLのトランザクションを考えてみますた « Fosters Technical Blog
◆トランザクション分離レベル READ UNCOMMITTED 唯一ダーティリードができるレベル。 READ COMMITTED ダーティリードが発生しない。 REPEATABLE READ ダーティもノンリピータブルもファントムも発生しない。 参照ロックはかからない。 SERIALIZABLE ダーティもノンリピータブルもファントムも発生しない。 参照ロックもかかる。 ◆ダーティリード(Dirty Read) ダーティペア、ダーティハリー・・・ ダーティという言葉は良くない意味なのね。 トランザクションＡで更新を行い、未コミット状態でも トランザクションＢでその値を参照できる。 テーブル「TAB1」のカラム「COL1」は「0」とする トランザクションＡ トランザクションＢ START TRANSACTION START TRANSA
MySQL を使ってトランザクション分離レベルの違いを試す
MySQL を使ってトランザクション分離レベルの違いと、それによって何が起こるかを確認する。 確認用のテーブルを作る。 mysql> create database test; Query OK, 1 row affected (0.00 sec) mysql> create table users( -> id integer primary key, -> name varchar(32) not null -> ); Query OK, 0 rows affected (0.01 sec) mysql> desc users; +-------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+-------------+----
MySQL ユーザのホストをワイルドカードで指定してもlocalhostは含まれない
MySQL ユーザのホストをワイルドカードで指定してもlocalhostは含まれない 2012-02-04 MySQLをインストールしたので、とりあえずワイルドカードでホスト名を指定してテスト用のユーザを作成。 mysql> show databases; +-------+ | Database | +-------+ | information_schema | | hoge | | mysql | | performance_schema | | test | +-------+ 5 rows in set (0.00 sec) mysql> grant select on hoge.* to testuser@'%' identified by 'password'; Query OK, 0 rows affected (0.07 sec) mysql> select host,u
SELECTなのにテーブルにロックが掛かる！〜InnoDBトランザクションにおけるINSERT INTO SELECT FROMの罠〜 - XOOPS専門-株式会社RYUS
SELECTなのにテーブルにロックが掛かる！〜InnoDBトランザクションにおけるINSERT INTO SELECT FROMの罠〜 カテゴリ : 技術全般 2010-10-14 19:37 MySQLのInnoDBはトランザクションが使えたり、行ロックが使えたりして、データの整合性の点でMyISAMに比べて優れています。 業務系アプリになると、データの整合性が重視されることも多く、トランザクションを使うことも増えます。 今回、そのトランザクションを使っていて、思いもよらないクエリがきっかけで、テーブルにロックが掛かってハマりました。 テーブル構造はこのような感じ...。 CREATE TABLE `working` ( `id` int(11) NOT NULL AUTO_INCREMENT, `col` int(11) NOT NULL DEFAULT '0', PRIMARY K
InnoDBで行ロック/テーブルロックになる条件 - (ﾟ∀ﾟ)o彡 sasata299's blog
2009年11月22日16:29 MySQL InnoDBで行ロック/テーブルロックになる条件 MySQL にはよく使われるストレージエンジンとして MyISAM と InnoDB がありますが、違いの一つとしてロックの挙動が挙げられます。MyISAM はテーブルロック、InnoDB は行ロックが掛かるというのは有名な話じゃないかと。 ただ、最近知ったのですが、InnoDB だとしても必ずしも行ロックになるわけではなく、テーブルロックになる場合もあるようですね。。このことについて手元の MySQL 5.1.26RC で簡単ですが検証してみます。サンプルとして使うテーブルはこちら。 CREATE TABLE `lock_sample` ( `id` int(11) NOT NULL AUTO_INCREMENT, `c1` int(11) NOT NULL, `c2` int(11) NOT
『Sqlで一回のＩnsert文で複数のデータを一括登録する』
本を買わずに解決するWeb制作の小技 ホームページ作成でちょっとしたことを参考書を買わずに解決する方法をPHP CSS Webデザイン jQuery Flashを中心に便利な技をまとめていきます！現在、長野県長野市の制作会社でWeb作成中！ 1000件のデータを一回づつinsertを発行すると 遅くなるので良い方法がないか調べていたら 良い方法を発見 MySQL AB :: MySQL 4.1 リファレンスマニュアル :: 5.2.10 IN データをためて一括で登録させる。 // アップデートするデータを「$i_page」に累積させる $i_page .= "('$lid', '$ldate', '$lcount'),"; // 「$i_page」の最後の一文字を除去 $i_page = substr($i_page ,0, -1); mysql_query("INSERT INTO p
[ヅ] MySQL の root パスワード忘れた！ (2006-07-06)
Debian GNU/Linux Sarge にて MySQL 4.1 の root パスワードを忘れたのでパスワードを再設定。 まず、MySQL サーバを停止。 次に、パスワード無しアクセスできるようにオプションで指定して、MySQL サーバを起動 (Debian の /etc/init/mysql にオプションが渡せない？ ので 本体の /usr/bin/mysqld_safe を直接起動する)。 # /etc/init.d/mysql stop # /usr/bin/mysqld_safe --user=root --skip-grant-tables & mysql クライアントからパスワードを変更。 # mysql -u root Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connect
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
