タグ付けされた質問 「performance」

の必要性を誇張する（もちろん私見）多くの記事がありますinnodb_file_per_table。を使用するとinnodb_file_per_table、個々のテーブルをより適切に制御できるはずです。各テーブルを個別にバックアップするようにします。ただし、パフォーマンスを向上させるという主張には疑問があります。 私のテストでは、性能の差はないinnodb_file_per_tableとibdata160ギガバイトのデータベースのために。もちろん、通常のクエリを使用した簡単なテストであり、実際の複雑なクエリでは状況が異なる場合があります（これがこの質問をした理由です）。64ビットLinuxは、ext4大きなファイルを効果的に処理できます。 ではinnodb_file_per_table、より多くのディスクI / O操作が必要です。そして、これは複雑なJOINsとFOREIGN KEY制約で重要です。 テーブルスペースはsingleで共有されibdataます。個別のテーブル専用のテーブルスペースがディスクスペースを節約する方法 もちろん、を使用して各テーブルのテーブルスペースを解放する方が簡単ALTERですが、それでも（テーブルロックを伴う）高価なプロセスです。 QUESTION： DOESはinnodb_file_per_tablemysqlののより良いパフォーマンスに影響を持っていますか？はいの場合、なぜですか？

26 mysql  performance  innodb  linux 

照合はクエリ速度に影響を与えますか？照合順序によってテーブルのサイズは変わりますか？ 推奨される照合となる可能性のあるすべての言語（たとえば、Googleの場合）をサポートする必要があるWebサイトを構築する場合はどうすればよいですか？ などの文字を保存する必要があり日本語ます。ウェブサイトでの検索somethingではsóméthíng入力のために戻る必要があり、大文字と小文字を区別しない必要があります。 どれが最良の選択であるかをどのようにして知ることができますか？このケースに適した照合はどれですか？

25 performance  sql-server  collation 

PostgresSQL 9.2を実行していますが、約6,700,000行の12列の関係があります。これには3D空間にノードが含まれ、各ノードはユーザー（作成者）を参照します。どのユーザーがいくつのノードを作成したかを照会するには、次のことを行います（詳細を追加explain analyze）。 EXPLAIN ANALYZE SELECT user_id, count(user_id) FROM treenode WHERE project_id=1 GROUP BY user_id; QUERY PLAN --------------------------------------------------------------------------------------------------------------------------- HashAggregate (cost=253668.70..253669.07 rows=37 width=8) (actual time=1747.620..1747.623 rows=38 loops=1) -> Seq Scan on treenode (cost=0.00..220278.79 rows=6677983 width=8) (actual time=0.019..886.803 rows=6677983 loops=1) Filter: (project_id = 1) Total runtime: 1747.653 ms ご覧のとおり、これには約1.7秒かかります。これは、データの量を考えるとそれほど悪くはありませんが、これを改善できるかどうかは疑問です。ユーザー列にBTreeインデックスを追加しようとしましたが、これは何の助けにもなりませんでした。 代替案はありますか？ 完全を期すために、これはすべてのインデックスを備えた完全なテーブル定義です（外部キーの制約、参照、トリガーはありません）。 Column …

24 postgresql  performance  index  group-by  count 

PostgreSQL 9.2のアイドル接続について尋ねたこの質問に対するコメントによると、いくつかのコミットされていないトランザクション（これらのアイドル接続の一部に関連している可能性があります）はパフォーマンスの問題を引き起こす可能性があります。 コミットされていないトランザクションがあるかどうかを判断する良い方法は何ですか（接続している接続がアイドル状態かどうかを知る方法がある場合のボーナスポイント）。 どうもありがとう！

24 postgresql  database-design  performance 

私はこの議論の両側で多くを読みました：生のクエリではなくストアドプロシージャのみを使用することで得られるパフォーマンスの大幅な向上はありますか？私は特にSQL Serverに興味がありますが、ありとあらゆるデータベースに興味があります。

23 sql-server-2008  performance 

ソフトウェア開発者および意欲的なDBAとして、SQL Serverデータベースを設計するときにベストプラクティスを取り入れようとしています（ソフトウェアがSQL Serverの上に置かれる時間の99％）。開発前および開発中に可能な限り最高の設計を行います。 ただし、他のソフトウェア開発者と同様に、機能、バグ、および変更/作成されたデータベースオブジェクトを必要とする要件の変更が追加されています。 私の質問は、クエリのチューニングはプロアクティブかリアクティブですか？言い換えれば、コード/データベースの大幅な変更の数週間後、クエリのパフォーマンスをチェックし、それに基づいてチューニングするために1日だけを確保する必要がありますか？それが実行されているように見える場合であっても大丈夫？ または、平均以下のパフォーマンスはデータベースチェックであり、ことわざにある黒板に戻るべきであることに注意する必要がありますか？ クエリのチューニングには多くの時間がかかる可能性があり、データベースの初期設計によっては、メリットが最小限になる場合があります。私は受け入れられている手口について興味があります。

23 performance  query  performance-testing 

彼らが見たとき、誰かが私が使用して見て、提案されたテーブルを作成するための私のDDLコードをレビューしてたVARCHAR(256)私がすべきことを、私は最初の名前または何のような、かなり小さいことが予想されるテキストのフィールドを常にだけ使用VARCHAR(MAX)し、リンクを使用する理由は何もなく、varchar型（最大）。私はそれを読みましたが、2005年に焦点を当てていたため、日付があり、すべてのテキストフィールドで1行あたり最大2GBを割り当てる可能性を実際に正当化するようには思われませんでした。 パフォーマンス、ストレージなどの観点から、VARCHAR(MAX)最新バージョンのSQL Serverで使用するか、より小さな特定のタイプを使用するかを決定するにはどうすればよいですか？（例：2008、2012、2014）

22 sql-server  database-design  performance  datatypes  varchar 

現在、主に多くのテーブルで実行されているINSERT、DELETE、UPDATEステートメントの数が多いため、クエリキャッシュから多数の無効化が発生しているMySQLデータベースで作業しています。 私が判断しようとしているのは、これらのテーブルに対して実行されているSELECTステートメントにクエリキャッシュを使用できるようにすることの利点があるかどうかです。それらは非常に迅速に無効化されるため、これらのテーブルのSELECTステートメントでSQL_NO_CACHEを使用することが最良の方法であると思われます。 頻繁な無効化のオーバーヘッドは価値がありますか？ 編集：以下のユーザー@RolandoMySQLDBAのリクエストに応じて、MyISAMおよびINNODBに関する情報を以下に示します。 InnoDB データサイズ：177.414 GB インデックスサイズ：114.792 GB テーブルサイズ：292.205 GB MyISAM データサイズ：379.762 GB インデックスサイズ：80.681 GB テーブルサイズ：460.443 GB 追加情報： バージョン：5.0.85 query_cache_limit：1048576 query_cache_min_res_unit：4096 query_cache_size：104857600 query_cache_type：ON query_cache_wlock_invalidate：オフ innodb_buffer_pool_size：8841592832 24GBのRAM

22 mysql  performance  innodb  myisam  cache 

この質問は、データベース管理者のStack Exchangeで回答できるため、Stack Overflowから移行されました。 7年前に移行され ました。 SQL 2005に運用DBサーバーがあります。すべてはしばらく正常に動作しますが、数週間後、顕著なパフォーマンスの低下が見られます。SQL Serverを再起動するだけで、パフォーマンスが通常に戻ります。 背景： 1200以上のデータベース（ほとんどが単一テナント、一部がマルチテナント）を実行しています。マルチテナントのみへの移行について講義する前に、この構造を維持する正当な理由があります...... RAMは16 GBです。再起動後、SQL Serverが15 GBの使用量に戻るのにそれほど長くかかりません。 アクティブDB接続は約80の接続です-プロセスごとにWebサーバーごとに1つの接続プールがあることを考えると、かなり健全であると感じているため、接続リークの問題はありません。 ピーク時以外にいくつかのことを試しました。-DBCC DROPCLEANBUFFERS（チェックポイント付き）を実行して、データキャッシュをクリアします。効果はなく、RAM使用量もクリアされません）。-FREEPROCCACHEおよびFREESYSTEMCACHEを実行して、クエリプランとストアドプロシージャキャッシュをクリアします。無効。 明らかに、SQL Serverを再起動することは、アクティブな運用環境では理想的ではありません。何かが欠けています。他の誰かがこれを通過しますか？ 更新：April-28-2012 まだこの問題と戦っています。OSとの競合を排除するために、SQL Serverのメモリを10 GBに下げました。絞り込みに近づいていますが、次のステップからの助けが必要です。 SQL Serverを再起動した後、ページファイルが12.3 GBから12.5 GBの間でホバリングしていることがわかりました。それは数日間そのままです。合計サーバースレッドは850から930の間でハングアウトします-安定しており、終日一貫しています（sqlserverはトラフィックに応じて55から85の間で安定しています）。 次に、「イベント」があります。私はイベントが何であるかわからず、ログでそれを見ることができず、曜日またはそれが起こる時間に一貫したものを見ることはできませんが、突然ページファイルはすべて14.1または14.2のいずれかにジャンプしますGB、およびスレッドは1750〜1785の間にジャンプします。 これが発生したときにパフォーマンスをチェックすると、これらのスレッドのうち900以上がsqlserverです。したがって、sp_who2にアクセスして、これらのスレッドがどこから来ているのかを確認します。使用されている80個程度のdb接続があります。 だから.... SQLサーバー上のこれらの900個のスレッドの残りがどこにあるのか、そして彼らが何をしているのかを見つけることができるアイデアはありますか？ 更新：2012年6月1日 まだ問題と戦っています。まだこれを読んでいる人にとっては、スレッドが跳ね上がる問題は解決されています。これは、自動化されたComVaultバックアップソフトウェアが原因でした。現在のデータベースを単にバックアップするのではなく、もはや存在しないデータベースをバックアップしようとするスレッドを作成していました（以前のデータベースのリストを維持していました）。 しかし、問題はまだ残っており、毎週再起動する必要があります。Rackspaceチームと協力して、光を当てられるかどうかを確認します。

22 sql-server  sql-server-2005  performance  configuration 

パーコナとは？ MySQLとの違いは何ですか？ ストックMySQLからPerconaへの切り替え（またはアップグレード）をいつ検討する必要がありますか？ 状況にいくつかの仕様を追加するために、InnoDB（Perconaは多くの最適化を行っていると理解しています）をほぼ排他的に使用し、広範な外部キー制約といくつかのストアドプロシージャを使用します。 現在、MySQLはクエリの最適化が不十分であるため、3〜4の結合を超えるクエリはパフォーマンスを改善するためにSTRAIGHT結合で明示的に構築する必要があります。

22 mysql  performance  innodb  percona  percona-server 

この質問は、データベース管理者のStack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 一部のDBAがSQL Serverを非常に頻繁に、時には夜間でも再起動することに気付きました。メモリを解放するために、またはクエリを高速化するために、彼らがそれを行うと信じています。再起動後にクエリプランを再コンパイルする必要があることは知っていますが、それを含めて、このプラクティスに最終的なメリットがあるのではないかと考えています。 SQL Serverを毎日再起動すると、実行速度が向上するのは本当ですか？

22 sql-server  performance  maintenance 

私のアプリケーションは非常にデータベース集約型です。現在、MySQL 5.5.19を実行しており、MyISAMを使用していますが、InnoDBに移行中です。残っている唯一の問題は、チェックサムのパフォーマンスです。 私のアプリケーションはCHECKSUM TABLE、ピーク時に毎秒約500-1000 ステートメントを実行します。これは、クライアントGUIが変更のためにデータベースを絶えずポーリングしているためです（監視システムであるため、非常に応答性が高く、高速である必要があります）。 MyISAMには、テーブルの修正時に事前計算された非常に高速なライブチェックサムがあります。ただし、InnoDBにはそのようなものはありません。だから、非常にCHECKSUM TABLE遅いです。 テーブルの最終更新時間を確認できるようにしたいと考えています。残念ながら、これはInnoDBでも利用できません。テストでは、アプリケーションのパフォーマンスが大幅に低下することが示されているため、私は今立ち往生しています。 テーブルを更新するコードの行が多すぎるため、アプリケーションにロジックを実装してテーブルの変更を記録することは問題外です。 InnoDBテーブルの変更を検出する高速な方法はありますか？

22 mysql  performance  innodb 

LIKE演算子が現在のデータベースシステム（MySQLやPostgresなど）にどのように実装されているかを説明できますか？またはそれを説明するいくつかの参照を教えてください？ 素朴なアプローチは、各レコードを検査し、対象フィールドで正規表現または部分的な文字列の一致を実行することですが、これらのシステムがよりスマートに動作することを感じています。

22 mysql  postgresql  performance  full-text-search  pattern-matching 

最近、SQL Serverスタートアップトレースフラグ8048が含まれ、SQL Server 2008 R2システムでの重大なスピンロック競合の問題が解決されました。 パフォーマンス値がトレースフラグ8048（NUMAノードごとからコアごとにクエリメモリ付与戦略を促進する）、トレースフラグ8015（SQL Serverは物理NUMAを無視する）、またはSUMA（インターリーブされた十分に均一なメモリアクセス、一部のNUMAマシンのBIOSオプション）。 トレースフラグ8048 http://blogs.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus -numa-node-may-need-trace-flag-8048.aspxごとに表示 トレースフラグ8015 http://blogs.msdn.com/b/psssql/archive/2010/04/02/how-it-works-soft-numa-io-completion-thread-lazy-writer-workers-and-memory -nodes.aspx システムのワークロードの詳細、問題のあるシステムからのメトリックの収集、介入後のシステムからのメトリックの収集。 トレースフラグ8048は「修正」でしたが、それが最良の修正でしたか？SQL Serverは、トレースフラグ8015により物理NUMAを無視しても同じことを達成できますか？メモリをインターリーブするようにBIOSを設定して、NUMA動作ではなくSMP動作のSUMA動作をサーバーに残してはどうですか？ 平和！tw：@sql_handle システムについて：-4 hexコアXeon E7540 @ 2.00GHz、ハイパースレッド-128 GB RAM-WS2008R2-MSSQL 2008 R2 SP2-maxdop 6 ワークロードについて：-2つのレポートアプリケーションサーバーから駆動される1000のバッチスケジュール/キューレポート。-3種類のバッチ：毎日、毎週、毎月-SQL Serverへのすべてのレポートアプリケーションサーバー接続は、単一のサービスアカウントとして作成されます-最大レポート同時実行数= 90 問題のあるシステムに関する主な調査結果：-Perfmonから、15秒間隔--システムは95％〜100％のCPU使用率のまま--SQL Serverのバッファーページ検索<10000 /秒 待機およびスピンロックDMVから、5分間隔 高いCMEMTHREADウェイターと待機時間 高いSOS_SUSPEND_QUEUEスピンとバックオフ Bob Dorrのトレースフラグ8048に関するCSSエンジニアブログの投稿は、NUMAノードごとに8コアを超えるシステムがクエリメモリ許可のボトルネックにより同様の症状に陥ることがあることを示しています。トレースフラグ8048は、戦略をNUMAノードごとではなくコアごとに変更します。 介入 -T8048を設定してMSSQLを再起動しました。違いはすぐに明らかになりました。バッファページの検索速度は100万を超え、1秒あたり800万に急上昇しました。以前は24時間で完了できなかった問題のあるバッチワークロードが、4時間未満で完了しました。トレースフラグ8048の修正値の検証の一部として、調査や介入の焦点では​​ない別のバッチワークロードが提出されました（そして、その望ましくない副作用が最小限であることを確認しました）。このレポートバッチは、以前2時間で完了しました。トレースフラグ8048を設定すると、レポートバッチは約20分で完了しました。 ナイトリーETLにもメリットがありました。ETL時間は約60分から40分に短縮されました。 いくつかの場所から情報を集めて、高度なレポートキューイング、ハードウェアスレッドカウントを超える同時レポートカウント、および結合されたすべてのレポートの単一ユーザーアカウントが、ワーカースレッドのプレッシャーによって1つのNUMAノードにプレッシャーをかけると推測します同じユーザーアカウントの次の着信接続要求に対して不利になります。この時点で、次のNUMAノードはほぼ瞬時にいくつかの接続を取得します。各NUMAノードは、クエリメモリ許可のボトルネックを強調する可能性が高くなります。 クエリメモリ許可のためにさらにレーンを開くと、ボトルネックが解消されました。しかし、費用はわかりません。Bob DorrのCSS投稿により、トレースフラグ8048で追加のメモリオーバーヘッドがあることが明らかになりました。単一ページアロケータ領域内のオーバーヘッドは、MSSQL 2008 R2の最大サーバーメモリによって管理されていますか？もしそうなら、システムはバッファプールキャッシュにあるデータベースページの数が少ないと思います。そうでない場合、最大サーバーメモリを下げる必要がありますか？

21 sql-server-2008-r2  performance  memory  numa 

SQLダンプがあり、かなり大きく（411 MB）、サーバーAにインポートするのに10分かかりました。ワークステーションBに同じインポートを行うと、インポートに8時間（pipeviewer）の見積もり（40分で31 MBをインポートしました） ）したがって、これはファクター53の方が遅くなります。 仕様： Server A: MySQL Version: 5.5.30-1.1 (Debian) 2 GB RAM 1 core QEMU Virtual CPU version 1.0 - cpu MHz: 3400.020 Workstation B: MySQL Version: 5.5.41-MariaDB-1ubuntu0.14.04.1 14 GB RAM 4 cores Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz - cpu MHz: 1600.000 mysql / maria構成は、ストック構成です。 昨日、ワークステーションでMariaDBに切り替えましたが、MariaDBの前は統計がさらに悪化していました。 ワークステーション上のすべてのデータベースをすでに削除しました-違いはありません。 …

21 mysql  performance