WordPress の高速化 – その3 (MySQL のデータベース エンジンを変更) | COMPNET
前々回の記事、前回の記事と WordPress の反応を改善する方法を探ってきた。 PHP のコードの実行を高速化する XCache をインストールしたり、WordPress のページ表示の反応を良くする WP Super Cache プラグインを追加したりした。 確かに、これらの方策によって多少なりとも改善した気がしないでもないが、正直なところ思ったほどの効果は得られたと言えない。 しかしながら、もっと根本的な設定を見直すことで、大きく改善することができた。 それは WordPress の記事や設定などの各種データを保管する MySQL の設定にあった。 WordPress で使っている MySQL は default-storage-engine の値が InnoDB になっている。 MySQL をインストールしたときのインストール ウィザードで「Multifunctional Dat
RailsエンジニアのためのSQLチューニング速習会 (2015/12/10 19:30〜)
新機能 バウチャーによるイベント管理機能をリリースしました。協賛企業の社員や関係者のイベント参加を円滑にすることに活用いただけます。詳しくはヘルプページをご覧ください。 新機能 connpass APIに新しく、所属グループを取得できるAPIやユーザーの参加イベントAPIを追加しました。各APIの詳細な仕様や利用方法につきましては、 APIリファレンス をご確認ください。またAPI利用希望の方は connpassのAPI利用について をご覧ください。 お知らせ 2024年9月1日より、connpassではスクレイピングを禁止し、利用規約に明記しました。以降の情報取得にはconnpass APIをご利用ください。APIご利用についてはヘルプページをご確認ください。
ORMのパフォーマンス最適化
これは明らかに遅く非効率だ。この問題はEager Loadingというテクニックを使うことで解決できる。もし最初の注文クエリの一部として後で必要となる顧客とのアソシエーションをすべてロードしておけば、Customerに対するアクセスはただのプロパティへのアクセスになる。こうすれば後のデータベースクエリは不要になり、N+1問題も起こらない。 LightSpeedでは、そのEager Load設定をTrueに変更することで（もしくは手書きコードのエンティティにEagerLoadAttributeを適用することで）、アソシエーションのEager Loadを可能にする。Eager Loadされるアソシエーションをもつエンティティをクエリすると、LightSpeedは追加のSQLを生成して、‘プライマリ’エンティティと同じように関連したエンティティを取得する。 Order.Customerアソシエー
N+1問題 / Eager Loading とは - Rails Webook
N+1問題とは SQLクエリが 「データ量N + 1回 」走ってしまい、取得するデータが多くなるにつれて（Nの回数が増えるにつれて）パフォーマンスを低下させてしまう問題です。 次のように、何度もクエリが走ってしまい、その度に0.1msほどかかってしまってます。 Processing by PostsController#index as HTML Post Load (0.2ms) SELECT "posts".* FROM "posts" User Load (0.2ms) SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT 1 [["id", 1]] User Load (0.1ms) SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT 1 [["id",
N+1問題は1+N問題 - Qiita
N+1というからほわっつ？ってなって、1+Nって言われると理解しやすいと思った。 このページ非常にわかりやすい。 http://www.techscore.com/blog/2012/12/25/railsライブラリ紹介-n1問題を検出する「bullet」/ 上のページでいう、PrefectureとShopが一対多の関係になっているときに、Shopの方から、eachの中でshop.prefecture.name みたいにすると、shopの数だけprefecture探すSQL文が発行されることになる。 このページ（参考）では、N+1問題をシンプルに、「全レコードの取得に一つ＋各レコード分だけ SQL を発行してしまう問題」と定義していて、要はただこれだけの問題だと感じた。 例えば100万レコードあったら100万回SQL発行されるのかって考えると、さすがにだれでもやばみ感じると思う。 実際にサ
1日に100万レコード増える場合のテーブル設計
MySQL（マイエスキューエル）は、TCX DataKonsultAB社などが開発するRDBMS（リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。 PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。
クエリ実行計画 - Wikipedia
クエリ実行計画（くえりじっこうけいかく）とは、ユーザが発行した問い合わせに基づきデータベース管理システム (DBMS) が内部的に生成する情報であり、これによりDBMSの行うデータ処理がプログラム的に表される。[注釈 1] DBMSはクエリ実行計画の生成にあたりクエリ最適化の処理を行い、最も効果的に処理できると判断されたクエリ実行計画を問い合わせから導き出す。 クエリ実行計画はDBMSがその機能を実現するための内部的な情報に過ぎないが、ユーザがチューニングを行うとき手がかりとなる情報を提供するために、多くのDBMSが実行計画の表示機能を提供する。 例としてApache Derbyの実行計画を以下に示す。 Statement Name: null Statement Text: SELECT Country FROM Countries WHERE Region = 'Central Ame
Database tuning - Wikipedia
This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Database tuning" – news · newspapers · books · scholar · JSTOR (December 2008) (Learn how and when to remove this message) Database tuning describes a group of activities used to optimize and homogenize
限界までMySQLを使い尽くす!!
どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値（16MBなど）に設定しておいて、必要に応じて大きな対を使うと良いだろう。 データベースの個数 データベースオブジェクトの個数に制限はない。データベースオブジェクトは
スロークエリの分析 — Let's Postgres
NTT オープンソースソフトウェアセンタ 板垣 貴裕 スロークエリ (時間のかかるSQL) を発見するまでの手順を解説します。スロークエリ分析と改善は以下の流れで行うことになります。この記事では主に 1. のスロークエリの特定方法について解説します。2.については『スロークエリの改善』を参考にしてください。 どのSQLが遅いのかを見つける。 そのSQLがなぜ時間がかかるのかを判断する。 設定パラメータ、SQL、スキーマなどを改善する。 着目したSQLの性能を再測定し、2. から繰り返す。 着目したSQLのチューニングが完了したら、他のボトルネックを探すため 1. から繰り返す。 スロークエリの見つけ方 スロークエリを見つけるには、大きく分けて統計情報ビューを使う方法と、サーバログを使う方法の2つがあります。統計情報ビューを使う方法は PostgreSQL 8.4 以降でしか利用できませんが
)
分割 (データベース) - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "分割" データベース – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2019年1月) データベースの分割（ぶんかつ、英: Partitioning）は、データベースを複数の部分に分割することである。 この分割は管理しやすさ、性能、可用性などの向上を理由として行われるのが一般的である。パーティション化とも呼ばれ、分割された各部分をパーティションと呼ぶ。 最もよくあるものは、分散データベースでの分割である。各パーティションは複数のノードに分散配置され、ユーザーはそれぞれのノードでローカルにトランザクションを実施できる。これは、可用性とセキ
)
Shard (database architecture) - Wikipedia
This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Shard" database architecture – news · newspapers · books · scholar · JSTOR (March 2021) (Learn how and when to remove this message) A database shard, or simply a shard, is a horizontal partition of data
クエリ最適化 - Wikipedia
クエリ最適化（クエリさいてきか、英: query optimization）は、多くのデータベース管理システム (DBMS) の持つ機能であり、クエリ（データに対する問い合わせ）を実行する最も効率的な方法を決定する。クエリオプティマイザ (query optimizer) とも言う。クエリオプティマイザは、入力されたクエリについて考えられるクエリ実行計画群を評価し、どれが最も効率的か決定する。コストに基づいたクエリオプティマイザでは、個々の計画のコストを見積もり、最もコストの低い計画を選ぶ。コストはクエリ実行時コストであり、入出力(I/O)操作数、CPU時間、その他から決定する。評価されるクエリ実行計画群は、可能なアクセス経路（例えば、インデックス検索、シーケンシャル検索）と結合アルゴリズム（例えば、ソートマージ結合、ハッシュ結合、入れ子ループ）の組み合わせから生成される。探索空間は入力さ
データ完全性 - Wikipedia
データ完全性（データかんぜんせい、英: Data integrity）は、情報処理や電気通信の分野で使われる用語であり、データが全て揃っていて欠損や不整合がないことを保証することを意味する。データインテグリティとも。すなわち、各種操作（転送、格納、検索）が行われる際にデータがひとまとめで扱われ、目的とする操作に対して期待されるデータ品質を維持する。簡単に言えば、データ完全性とは、データが一貫していて正しく、アクセス可能であることを保証するものである。 関係データベースにおけるデータ完全性とは、データベース内のデータの正確性や妥当性を指す。 多くの関係データベース管理システム (RDBMS) では、データベース内のデータ完全性を保証するために一意性制約やCHECK制約、あるいはエンティティ間に参照整合性を保つための制約などを設ける機能がある。 参照整合性とは、女Aと男Bが夫婦であるならば女A
リレーションの正規化 - Wikipedia
この記事には複数の問題があります。改善やノートページでの議論にご協力ください。 脚注による出典や参考文献の参照が不十分です。脚注を追加してください。（2023年9月） ほとんどまたは完全に一つの出典に頼っています。（2023年9月） 出典検索?: "関係の正規化" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL 関係の正規化（かんけいのせいきか）は、関係データベース (リレーショナル・データベース) において、関係（リレーション）を正規形と呼ばれる形式に準拠させることにより、データの一貫性の維持と効率的なデータアクセスを可能にする関係設計を導くための方法である。正規形には様々なものが存在するが、いずれにせよ、正規化を行うことにより、データの冗長性と不整合が起きる機会を減らすことができる。 多くの関係デ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL :: MySQL 8.4 Reference Manual :: 10 Optimization