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

行の存在を常に COUNTではなくEXISTSで確認する必要がある場合によく読んでいます。 しかし、最近のいくつかのシナリオでは、カウントを使用したときのパフォーマンスの改善を測定しました。 パターンは次のようになります。 LEFT JOIN ( SELECT someID , COUNT(*) FROM someTable GROUP BY someID ) AS Alias ON ( Alias.someID = mainTable.ID ) 私はSQL Serverの「内部」で何が起こっているのかを知る方法に精通していないので、私が行った測定に完全に意味のあるEXISTSの前例のない欠陥があるのではないかと思っていました（RISTが存在する可能性があります！）。 その現象についての説明はありますか？ 編集： 実行できる完全なスクリプトを次に示します。 SET NOCOUNT ON SET STATISTICS IO OFF DECLARE @tmp1 TABLE ( ID INT UNIQUE ) DECLARE @tmp2 TABLE ( ID …

35 sql-server  performance 

クエリの節のUSING（ではなくON）コンストラクトが、FROMSELECT一定の場合には、最適化の障壁を導入することがあります。 私はこのキーワードを意味します： 選択* から 参加b 使用した（A_ID） より複雑な場合にのみ。 コンテキスト：このコメントにこの質問。 私はこれをよく使いますが、これまでに気づいたことはありません。効果やリンクを示すテストケースに非常に興味があります詳細情報にます。私の検索努力は空っぽになりました。 完璧な答えは、表示するために、テストケースとなりUSING (a_id)、代替句に参加すると比較して劣った性能をON a.a_id = b.a_id- 場合はそれが実際に起こることができます。

35 postgresql  performance  optimization  join  select 

結果の検索に使用されるインデックスをテーブルに追加しました。ASCまたはDESCの順序で結果を表示しています。その列にはインデックスが必要ですか？そのテーブルにはさらに2つのインデックスがあります。その列にインデックスを作成するかどうかによって、パフォーマンスはどのように影響しますか？

35 mysql  performance  index  order-by 

PostgreSQLのドキュメントによるとVARCHAR、VARCHAR(n)との間にパフォーマンスの違いはありませんTEXT。 名前または住所列に任意の長さ制限を追加する必要がありますか？ 編集：だまされていない： すべての値が36文字の場合、char vs varcharを使用すると、インデックスルックアップは著しく高速になりますか このCHARタイプは過去の遺物であり、パフォーマンスだけでなく、アーウィンのような他の長所と短所も彼の驚くべき答えで述べています。

35 postgresql  performance  datatypes  varchar 

各SQLステートメントの後にGOステートメントを使用する理由は何ですか？GOはバッチの終了を通知し、ステートメントの評判を許可しますが、ステートメントごとにそれを使用する利点は何ですか。 声明のたびに多くのマイクロソフトのドキュメントなどが使用を開始したか、気づき始めたばかりかもしれません。 また、ベストプラクティスと見なされるものは何ですか？

34 sql-server  performance  t-sql  best-practices 

仮想Windows 2008 R2サーバーで実行されているSQL Server 2008 R2（10.50.1600）があります。CPUを1コアから4に、RAMを4 GBから10 GBにアップグレードした後、パフォーマンスが低下していることに気付きました。 私が見るいくつかの観察： 実行に5秒未満かかったクエリは、現在200秒以上かかっています。 CPUは、sqlservr.exeを原因として100に固定されています。 4.6百万行のテーブルでのselect count（*）は90秒以上かかりました。 サーバーで実行されているプロセスは変更されていません。唯一の変更点は、CPUとRAMを増やすことでした。 他のSQLサーバーには静的なページングファイルがあり、このサーバーはそれを独自に管理するように設定されています。 以前にこの問題に遭遇した人はいますか？ sp_BlitzErikごとに、私は走りました EXEC dbo.sp_BlitzFirst @SinceStartup = 1; これらの結果を与えてくれます。

33 sql-server  sql-server-2008-r2  performance  windows-server-2008-r2 

これは純粋に理論的な質問です。複数のサーバーにデプロイされたアプリケーションがあるとします。 ロードバランサー、 複数/スケーラブルなアプリケーションサーバー （単一の）データベースサーバー（現時点では） 最初の2つの部分では、何を探すべきかがわかります。しかし、データベースサーバーはどうでしょうか。どのようなハードウェアを探すべきですか？ CPU周波数はデータベースサーバーに関連していますか？ 複数のコアCPUが関連していますか？ RAMはCPUよりも重要ですか？ PS：選択したデータベースがMySQLまたはPostgreSQLであると仮定します。

33 mysql  postgresql  performance 

私にはかなり厄介な問題があります。メインデータベースエンジンとしてINNODBを使用し、冗長性のためにgalera-clusterを使用するために前者が必要なため、MyISAMを放棄します。 newbb_postテーブルをコピー（説明が続きます）という新しいテーブルにコピーnewbb_innopostし、InnoDBに変更しました。現在、テーブルには5,390,146それぞれエントリがあります。 新しく起動したデータベースでこれらの選択を実行すると（この時点でキャッシュは関係しません！）、データベースは次の結果を生成します（完全な出力は省略します。結果の並べ替えをデータベースに依頼しないことに注意してください）。 SELECT post.postid、post.attach FROM newbb_post AS post WHERE post.threadid = 51506; 。 。 | 5401593 | 0 | | 5401634 | 0 | + --------- + -------- + セット内の62510行（0.13秒） SELECT post.postid、post.attach FROM newbb_innopost AS post WHERE post.threadid = 51506; 。 。 | 5397410 | 0 | | 5397883 …

33 mysql  performance  innodb  myisam 

私の質問はこれに基づいています：https : //stackoverflow.com/q/35575990/5089204 そこで答えを出すために、次のテストシナリオを行いました。 テストシナリオ 最初にテストテーブルを作成し、100.000行を入力します。乱数（0から1000）は、乱数ごとに最大100行になるはずです。この番号はvarchar colに入れられ、XMLの値として使用されます。 次に、OPのような呼び出しを行います。.exist（）および.nodes（）を使用して、2番目の利点はわずかですが、両方とも5〜6秒かかります。実際に、呼び出しを2回行います。2回目はスワップされた順序で、検索パラメーターをわずかに変更し、フルパスではなく「// item」を使用して、キャッシュされた結果またはプランによる誤検知を回避します。 次に、XMLインデックスを作成し、同じ呼び出しを行います 今-本当に驚いたことは何ですか！- .nodesとの完全なパスがはるかに遅い（9秒）前よりもなく.exist()して、半秒までであるフルパスもダウン約0.10秒です。（一方.nodes()、短いパスの方が優れていますが、それでもはるかに遅れています.exist()） 質問： 私自身のテストをまとめると、XMLインデックスはデータベースを極端に破壊する可能性があります。それらは物事を非常に高速化できますが（s。edit 2）、クエリも遅くなります。それらがどのように機能するかを理解したいのですが... XMLインデックスを作成する必要があるのはいつですか？.nodes()インデックスを使用すると、インデックスを使用しない場合よりも悪くなるのはなぜですか？否定的な影響をどのように回避できますか？ CREATE TABLE #testTbl(ID INT IDENTITY PRIMARY KEY, SomeData VARCHAR(100),XmlColumn XML); GO DECLARE @RndNumber VARCHAR(100)=(SELECT CAST(CAST(RAND()*1000 AS INT) AS VARCHAR(100))); INSERT INTO #testTbl VALUES('Data_' + @RndNumber, '<error application="application" host="host" type="exception" message="message" > <serverVariables> <item name="name1"> …

32 sql-server  xml  performance  sql-server-2012 

ほとんどのテーブルでMySQL 5.6とInnoDBストレージエンジンを使用します。InnoDBバッファープールのサイズは15 GBで、Innodb DB +インデックスは約10 GBです。サーバーには32GBのRAMがあり、Cent OS 7 x64を実行しています。 約1,000万件以上のレコードを含む1つの大きなテーブルがあります。 24時間ごとにリモートサーバーから更新されたダンプファイルを取得します。ファイルはcsv形式です。私はそのフォーマットを制御できません。ファイルは最大750 MBです。MyISAMテーブルに行ごとにデータを挿入しようとしましたが、35分かかりました。 ファイルから10-12のうち1行につき3つの値のみを取得し、データベースで更新する必要があります。 このようなことを達成する最良の方法は何ですか？ これを毎日する必要があります。 現在、Flowは次のようになっています。 mysqli_begin_transaction ファイルを1行ずつ読み込む 各レコードを行ごとに更新します。 mysqli_commit 上記の操作を完了するには約30〜40分かかりますが、これを実行している間、他の更新が行われているため、 ロック待機タイムアウトを超過しました。トランザクションを再開してみてください アップデート1 を使用して新しいテーブルにデータを読み込みますLOAD DATA LOCAL INFILE。MyISAM 38.93 secでは、InnoDBでは7分5.21秒かかりました。それから私はやった： UPDATE table1 t1, table2 t2 SET t1.field1 = t2.field1, t1.field2 = t2.field2, t1.field3 = t2.field3 WHERE t1.field10 = t2.field10 Query OK, …

32 mysql  performance  mysql-5.6  update  myisam 

PostgreSQL v8.2.3を使用しています。 関係するテーブルがあります：EMPLOYEEとEMAILLIST。 Table 1: EMPLOYEE (column1, column2, email1, email2, column5, column6) Table 2: EMAILLIST (email) 2つのテーブルは、EMPLOYEE.EMAIL1またはEMPLOYEE.EMAIL2に一致するエントリがない場合、それらの行が返されるように結合されます。 SELECT employee.email1, employee.email2, e1.email IS NOT NULL AS email1_matched, e2.email IS NOT NULL AS email2_matched FROM employee LEFT JOIN emaillist e1 ON e1.email = employee.email1 LEFT JOIN emaillist e2 ON e2.email = employee.email2 …

32 performance  postgresql  index  query 

最適化しようとしているSQLクエリがあります。 DECLARE @Id UNIQUEIDENTIFIER = 'cec094e5-b312-4b13-997a-c91a8c662962' SELECT Id, MIN(SomeTimestamp), MAX(SomeInt) FROM dbo.MyTable WHERE Id = @Id AND SomeBit = 1 GROUP BY Id MyTable 次の2つのインデックスがあります。 CREATE NONCLUSTERED INDEX IX_MyTable_SomeTimestamp_Includes ON dbo.MyTable (SomeTimestamp ASC) INCLUDE(Id, SomeInt) CREATE NONCLUSTERED INDEX IX_MyTable_Id_SomeBit_Includes ON dbo.MyTable (Id, SomeBit) INCLUDE (TotallyUnrelatedTimestamp) 上記のとおりにクエリを実行すると、SQL Serverは最初のインデックスをスキャンします。その結果、189,703の論理読み取りと2〜3秒の時間がかかります。 @Id変数をインライン化してクエリを再度実行すると、SQL Serverは2番目のインデックスを検索します。その結果、論理読み取りは104回だけで、期間は0.001秒（基本的に瞬時）になります。 変数が必要ですが、SQLで適切なプランを使用する必要があります。一時的な解決策として、クエリにインデックスヒントを付けましたが、クエリは基本的に瞬時です。ただし、可能な場合はインデックスヒントから離れるようにします。私は通常、クエリオプティマイザーがその仕事をすることができない場合、何をすべきかを明示的に伝えることなくそれを支援するためにできること（またはやめること）があると思います。 …

32 sql-server  performance  execution-plan 

VMware内のSQL Server 2016ノードの仮想クラスターに一連の物理サーバーのプロビジョニングを開始しています。Enterprise Editionライセンスを利用します。 6つのノードのセットアップを計画していますが、CPUクロック速度とCPUコアカウントに関して、物理サーバーをプロビジョニングする理想的な方法については少し議論があります。 これは、トランザクション量と他のソフトウェア固有の要因の中で保存されているデータベースの数に大きく依存することを知っていますが、推奨される一般的な経験則はありますか？ たとえば、デュアル8コア、3.2 GHz物理サーバー（16コア）は、デュアル16コア、2.6 GHzサーバー（32コア）よりも優先されますか？ このタイプのトピックをさらに掘り下げたホワイトペーパーに出会った人はいますか？

30 sql-server  performance  clustering  vmware  hardware 

すべてのテーブルのプライマリキーにハッシュベースの生成されたIDを使用するレガシースキーマ（免責事項！）があります（多数あります）。このようなIDの例は次のとおりです。 922475bb-ad93-43ee-9487-d2671b886479 このアプローチを変更する可能性はありませんが、インデックスアクセスのパフォーマンスは低下します。これが無数にある理由は別として、多くのテーブルのすべてのid値が正確に36文字の長さであるにもかかわらず、列タイプはvarchar(36)でなく 、最適ではないように思われることが1つありchar(36)ます。 固定長に列の型を変更することだろうchar(36)任意の提供の重要なインデックスページなどあたりのエントリの数が非常に少ないの増加を超えて、インデックスのパフォーマンス上の利点？ つまり、固定長型を扱う場合、可変長型よりもpostgresの方がはるかに高速ですか？ わずかなストレージの節約については言及しないでください-列に変更を加えるために必要な手術と比較しても問題にはなりません。

30 postgresql  performance  index  varchar 

PostgreSQLサーバーの1つは、一定のデータストリームを受信する複数の（1〜3）データベースをホストしています。データは特に構造化されておらず、現在の時刻とその特定の瞬間のさまざまな観測データになります。データレートはかなり高いです。あるデータベースでは1日に約1ギガバイト、別のデータベースでは約10分の1になります。この率が上がるとは思わない。読み取りパフォーマンスは、はるかに低い優先度であり、現在許容されています。 ログにこのメッセージがあります： LOG: checkpoints are occurring too frequently (15 seconds apart) HINT: Consider increasing the configuration parameter "checkpoint_segments". 現在、この値は16に設定されていpgtuneます。 書き込みパフォーマンスを改善するために考慮すべき設定は何ですか？私は可能な限り安全に保つことを好むでしょう。入ってくるデータの量を考えると、データの大部分が無傷である限り、障害で最近のデータを失うことを受け入れることができます。 編集：今のところPostgreSQL 9.0を使用していますが、9.1にアップグレードする予定です。ハードウェアの詳細は掲載していませんが、その重要性は認識していますが、最終的には非常に多様なハードウェアを持つ複数のマシンでこの最適化を行う必要があります。ハードウェアが答えに不可欠な場合は、一般的な情報を教えてください。異なるハードウェア構成のマシンに答えを適用できます。

30 performance  postgresql