ありがとう、さようなら PEAR::DB
この記事はGMOペパボ Advent Calendar 2017の13日目の記事です。 最近まで取り組んでいたこととして、10年以上ペパボを支えてきたサービスの一部Webアプリケーションにおいて、PEAR::DBの使用をやめて、PDOの使用に変更するというものがありました。 この記事では、取り組みの動機や、どのようなアプローチを採ったのか、また、そこから得られた知見などを紹介します。おそらく、相応に老舗であるPHPアプリケーションでしか、PEAR::DBと向き合う機会はないと思われますので、万人向けの記事ではないことを予めお断りしておきます。 動機と背景 まずはじめに、PEAR::DBとPDOについて、簡単に触れたうえで、今回の取り組みの動機と背景について整理します。 PEAR::DBとは PEAR::DBとは、PEARで提供されているデータベース抽象化のためのライブラリです。PEARのサ
Reli を使った PHP 7.x/8.x サービスの計測｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
Reli を使った PHP 7.x/8.x サービスの計測 こんにちは。やまゆです。 サービスをリリースするにあたり、事前のシナリオテスト・負荷試験はなくてはならない項目です。 そこで主に API ごとの成功率、レイテンシ（リクエストしてからレスポンスが返ってくるまでの時間）、レスポンスサイズなどを計測し、想定されるユーザー数でも快適に遊べることを保証できるように改善を加えていきます。 改善の際、重くない部分をチューニングしてもほとんど効果が出ないので、「この API のどの部分（関数）に時間がかかっているのか？」を知ることが重要です。 それらを実際に動作している環境で計測し、可視化することを「プロファイリング」と呼ぶことがあります。 これは、ターゲットとする機能の実行時間について、「このメソッドに何秒かかった」や「全体の x % がこのメソッドで消費されている」などを確認するための仕組み
SQLの達人への道: MySQLでの高速・効率的クエリ作成術 - Qiita
概要 この記事では、MySQLでのSQLクエリのパフォーマンスを最大限に引き出すための効率的な書き方を解説します。アプリケーションの応答速度を向上させることは、ユーザーエクスペリエンスの大幅な改善に直結します。この記事を通じて、初心者から中級者のデータベース管理者や開発者は、SQLクエリの基本から高度な最適化テクニックまで、幅広い知識を習得できることを目指しています。 MySQL 8.0での検証を基にしていますが、その他のバージョンでの動作は保証されません。この記事は継続的に更新されます。 主な内容 このセクションでは、検証データの作成手順を含め、インデックスの利用、JOIN操作の最適化、サブクエリとビューの利用、クエリキャッシュの活用など、効率的なクエリの書き方について解説します。 検証データの作成 MySQLサーバーへの接続方法から始め、テスト用データベースとテーブルの作成、ダミーデー
MySQL 8.0 への移行が完了しました ～さようなら全ての MySQL 5.7～ - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。クラウド運用チームの飯塚です。 私たちは cybozu.com 本番環境の MySQL を昨年末から順次 8.0 系へアップグレードしており、前回の定期メンテナンスにおいて全てのインスタンスのアップグレードを完了しました。この記事では、私たちが MySQL 8.0 への移行に取り組んだ理由と必要になった対応について紹介します。 なぜ MySQL 8.0 へ移行したのか GTID-based レプリケーションにおける制限の緩和 再起動時に AUTO_INCREMENT のカウンタが巻き戻る問題の解消 実際に対応が必要だった MySQL 8.0 の変更点 utf8mb4 の照合順序のデフォルト値の変更 SQL_CALC_FOUND_ROWS と FOUND_ROWS() が deprecated に Connector/J のメタデータ取得処理の性能低下 sys.innodb_lo
All Aboutの基幹DBのMySQLバージョンを5.7から8.0に上げた話 - オールアバウトTech Blog
こんにちは。株式会社オールアバウト エンジニアの@hideです。 私たちのチームでは、2022年3〜6月にかけて、オールアバウトの基幹DB（All Aboutの記事やガイドの情報が格納してあるDB）のMySQLバージョンを5.7から8.0に上げる対応を実施しました。 当記事ではその際の移行手順や実際の作業を通して得た知見をまとめます。 これからシステムのMySQLバージョンを上げたいと思っている方の参考になれば幸いです。 環境情報 MySQLバージョンアップの動機について セキュリティ担保のため All Aboutのリアーキテクチャに向けた準備 移行作業の振り返りと得た学び 1. MySQL8の変更点を確認 2. 影響範囲の洗い出し 3. 各アプリのテストケースを作成 4. ステージング環境で動作テストを実施して問題点の洗い出し＋エラーの解消 MySQL8で削除されたSQLモードに起因する
A5:SQL Mk-2 から SSHトンネルを利用して MySQL へ接続する
※A5:SQL Mk-2はGitHubのプライベートリポジトリで開発されているためソースコードを参照することはできません。 このページでは A5:SQL Mk-2 から SSHトンネルを利用して MySQL へ接続する手順を示します。 例えば、よくあるレンタルサーバーは外部からMySQLに直接接続出来る設定になっていることは稀ですが、SSHトンネルを介せば接続出来ることがあります。 また、自宅から会社の公開されているSSHサーバーにアクセスし、そこを経由してMySQLサーバーに接続することも出来ます。 Version 2.7までの場合でCygwin経由で接続する古い資料を参照したい場合はこちらにあります。 ケース１（SSHサーバーとMySQLサーバーが同じサーバーである場合） このケースはSSHサーバーとMySQLサーバーが同じサーバーに導入されている場合です。例えば、自宅からレンタルサー
MySQLでNOT NULLかつデフォルト値を指定しているカラムへのNULLでのUPDATE時の挙動と厳格モードによる挙動の変化 | DevelopersIO
MySQLでNOT NULLかつデフォルト値を指定しているカラムへのNULLでのUPDATE時の挙動と厳格モードによる挙動の変化 ローカルのMySQLでは特定のカラムアップデート時にエラーが発生するが、他の環境ではエラーが発生しないということが起きました。原因が分かるまで少し手こずったので、その内容と再現方法を書き残しておきます。 エラーとその解決方法 状況 NOT NULLかつデフォルト値を設定したTINYINTカラム(カラムAとする)を含むテーブルに対して、カラムAに対応した値にNULLを設定して1行アップデートを実行。環境Aでは実行成功し、環境Bではエラーが出て実行に失敗。 環境A: Aurora MySQL 5.7.12互換 sql_mode: 0(モードの設定なし) 環境B: MySQL 5.7.30 (mysql: 5.7) sql_mode: STRICT_TRANS_TAB
SELECT文をタイムアウト強制終了させる「MAX_EXECUTION_TIME」使ってる？ - なからなLife
この記事はMySQL Casual Advent Calendar 2017 - Qiitaの9日目のエントリとなります。 実行が長引いたSELECT文を強制終了させるヤーツ MySQL5.6まで、正常に処理が進んでいて遅いSELECTをタイムアウトさせるシステム変数はありませんでした。 正常に処理が進んでいない時のパラメータだと lock_wait_timeout：メタデータロック取得待ち innodb_lock_wait_timeout：レコードロック取得待ち がありました。 正常に処理が進んでいるけど、厳密には「処理中」ではないときに効くパラメータだと net_read_timeout：クライアントからサーバに送り込んだデータの読み込み時間 net_write_timeout：サーバからクライアントへのデータの書き戻し時間 がありました。 他にも、アイドルタイムアウト系で inter
SQLでインフラ管理？ IaSQLを試してみた | DevelopersIO
中山です 今日は、twitterで見かけたIaSQLなるサービスを試したので紹介してみたいと思います。 IaSQLとは IaSQLとは、インフラの状態をPostgreSQLで管理管理できるSaaSです。 IaSQL Why IaSQL メリットとしては以下の3点が挙げられていました。 Import existing cloud infrastructure Connect an AWS account to a hosted IaSQL DB to automatically backfill the database with your existing cloud resources. No need to redefine or reconcile existing infrastructure. The definitive state of your cloud IaSQL's
MySQLでDBとテーブルのサイズを確認するSQL - Qiita
SELECT table_schema, sum(data_length) /1024/1024 AS mb FROM information_schema.tables GROUP BY table_schema ORDER BY sum(data_length+index_length) DESC; SELECT table_name, engine, table_rows AS tbl_rows, avg_row_length AS rlen, floor((data_length+index_length)/1024/1024) AS allmb, #総容量 floor((data_length)/1024/1024) AS dmb, #データ容量 floor((index_length)/1024/1024) AS imb #インデックス容量 FROM information_s
システム基盤 AtlasBase®｜BIPROGY株式会社
企業情報 企業情報トップ BIPROGYについて トップメッセージ 会社概要 5分でわかるBIPROGY Purpose,Principles Vision2030・経営方針（2024-2026） コーポレートブランド グループ会社 拠点所在地 組織図 役員一覧 企業理念 企業行動憲章 役職員行動規範 PDF 調達・購買に関する指針等について BIPROGYグループのAI倫理指針 PDF BIPROGYグループの歴史 BIPROGYの企業活動 サステナビリティ 広告宣伝活動 イベント／セミナー 出版物 デジタルメディア BIPROGY TERASU 別ウィンドウで開く BIPROGYバドミントンチーム 東京ディズニーランド「エレクトリカルパレード・ドリームライツ」 東京ディズニーシー「フォートレス・エクスプロレーション」 BIPROGYの技術・研究活動 技術への取り組み BIPROGY総合
MySQL のサブクエリって、ほんとに遅いの？ | DevelopersIO
こんにちは、みかみです。 今日のクラスメソッドのAWSおみくじ、RDS（t1.micro）でしたー！（昨日は Aurora！＠＠ｖ はじめに 前職＠アプリ開発時、MySQL のクエリチューニングをさせていただく機会がありました。 ユーザー入力のキーワードで全文検索 → 見つかったレコードを返すのですが、所要時間、約3分。。 Apache タイムアウトして画面真っ白。。。（泣きそうでした＞＜。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリの
RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
【SQL server】デッドロックの調査方法 - 小物SEのメモ帳
デッドロック発生に際し、分析時の確認の仕方について紹介します。 エラーログやSQL Plofilerなどで調査可能ですが、個人的には拡張イベントがお勧めです。デフォルト設定であれば、拡張イベントの「system_health」でデッドロック情報は取得しているので、事後で確認する際に便利です。 拡張イベントで採取されたデータはデフォルトであれば以下のようにログファイル格納先と同様の場所にありますので、ダブルクリックして開きます。 尚、ファイル形式での拡張イベント「system_health」は、5MB：4世代しかデフォルトで残らないため、事後で確認可能とはいえデッドロック発生後は速やかに本ファイルを退避しておく方がよいでしょう。 上部のメニューで「フィルター」を選択し、以下のようにフィルタします。 フィールド 演算子 値 name = xml_deadlock_report 表示されたイベン
拡張イベントを使ってスロークエリを探す | SQLServer大好き
拡張イベントを利用して、スロークエリを調査します。 拡張イベントはSQLServer2008から利用できます。 拡張イベントの登録 実行完了までに2秒以上掛かっているクエリを取得します。 ・G:\work\ExtendedEvents_logフォルダを用意します。 ・下記のクエリを実行します。 MSSQL2008用 --2008 拡張イベントの登録 CREATE EVENT SESSION [slowquery_report_2sec] ON SERVER ADD EVENT sqlserver.rpc_completed( ACTION(sqlserver.client_hostname,sqlserver.database_id,sqlserver.sql_text,sqlserver.username) WHERE ([duration]>(2000))), ADD EVENT sq
SQL Serverの利用時に遅いクエリを特定する方法 | intra-mart Developer Site
1. SQL Server Profilerを利用したSQLトレース ここでは、SQL Server上で実行されているSQLをトレースして、一定時間以上処理を実行していたクエリをリストアップする方法をご紹介します。SQLトレースを実行するには、SQL Serverに付属しているイベントキャプチャツール SQL Server Profilerを利用します。 SQL Server Profilerの実行はSQL Serverに負荷を与えるため、運用環境では利用しないでください。検証環境のSQL Server上で実行してください。 SQL Server Profilerの詳細については、Microsoft社のドキュメントを参照してください。 手順1. SQL Server Profilerの起動 1. SQL Server Profilerを起動します。 SQL Server Managemen
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CakePHP3でのクエリビルダ記法まとめ[QueryBuilder/QueryExpression]![CakePHP3でのクエリビルダ記法まとめ[QueryBuilder/QueryExpression]](https://cdn-ak-scissors.b.st-hatena.com/image/square/026d51dfd392c81e1845aa6d923567f7f6c8e68b/height=288;version=1;width=512/https%3A%2F%2Fwww.ritolab.com%2Fimages%2Fposts%2F67%2Fthumbnail.png)
RDS から mysqldump するときのお作法 - AR ホームベーカリー
Loading...
SQL Server でデッドロックを検知する方法