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

データベースのコンテキストでは、最適化とは、クエリオプティマイザが効率的な物理実行プランを選択するプロセスを指します。

3
MySQL InnoDB page_cleaner設定は最適ではない可能性があります
mysqld.logでこのメモを確認します。 [Note] InnoDB: page_cleaner: 1000ms intended loop took 15888ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.) このようなことについてここで言及されているようです: 「同期インデックスを実行中」のMySQLインスタンスのストール 私の質問は、このメモがログに記録された場合、どのようなアクションが実行されるべきかということです。 MySQLおよびOSバージョン: mysql-community- server- 5.7.9 -1.el7.x86_64 centos-release-7-1.1503.el7.centos.2.8.x86_64 実行SHOW変数は「%InnoDBの」のような。提案されているように: innodb_page_cleaners | 1

6
ストアドプロシージャの実行が突然遅くなる
SQL Server 2000で発生している問題を理解しようとしています。中程度のトランザクションWebサイトでありsp_GetCurrentTransactions、customerIDを受け入れるストアドプロシージャと2つの日付があります。 現在、日付と顧客に応じて、このクエリは0〜1000行の任意の行を返すことができます。 問題:私たちが経験したことはExecution Timeout Expired、特定のクライアントがそのストアドプロシージャを実行しようとすると、突然(通常または同様の)多くのエラーが発生することです。そのため、クエリを調べてSSMSで実行すると、30秒かかることがわかります。したがって、ストアドプロシージャを再コンパイルすると、-bang-が300ミリ秒で実行されます。 私はこれについてDBAに話しました。彼は、ストアドプロシージャを作成したときにデータベースがクエリプランを作成したと言っています。彼は、そのパラメーターセットには良い計画であると言いましたが、特定のパラメーターセットをスローすると、そのデータに最適なプランではなくなるため、実行が遅くなります。 私に提示されたオプションは、問題のクエリをストアドプロシージャから、実行ごとに作成された実行プランを持つ動的SQLに戻すことです。 これは私に一歩後退したような気がし、これを回避する方法があるに違いないと感じています。この問題に対処する他の方法はありますか? ありとあらゆる回答を歓迎します。

3
MySQLはなぜこの順序で強制的にインデックスを無視するのですか?
私は実行しEXPLAINます: mysql> explain select last_name from employees order by last_name; +----+-------------+-----------+------+---------------+------+---------+------+-------+----------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-----------+------+---------------+------+---------+------+-------+----------------+ | 1 | SIMPLE | employees | ALL | NULL | NULL | NULL | NULL | …

3
SQL Serverカーディナリティヒント
カーディナリティの推定値をSQL Serverオプティマイザー(任意のバージョン)に「注入」する方法はありますか? すなわち、Oracleのカーディナリティのヒントに似たものです。 私のモチベーションは、クエリオプティマイザーは本当にどれくらい良いのかという記事に基づいています。[1]、彼らは悪い計画の選択に対するカーディナリティ推定量の影響をテストします。したがって、複雑なクエリに対して正確にカーディナリティを「推定」するようにSQL Serverに強制できれば十分です。 [1] Leis、Viktor、et al。「クエリオプティマイザーはどれほど優れていますか?」 VLDB Endowment 9.3(2015):204-215の議事録。

1
列のインデックスを作成するときに、このsqliteクエリがはるかに遅いのはなぜですか?
(偽の)人の名前を含む、それぞれ50,000行の2つのテーブルを持つsqliteデータベースがあります。両方のテーブルに共通する名前(名前、ミドルネームのイニシャル、姓)がいくつあるかを調べる簡単なクエリを作成しました。 select count(*) from fakenames_uk inner join fakenames_usa on fakenames_uk.givenname=fakenames_usa.givenname and fakenames_uk.surname=fakenames_usa.surname and fakenames_uk.middleinitial=fakenames_usa.middleinitial; 主キー以外にインデックスがない場合(このクエリとは無関係)、すぐに実行されます。 [james@marlon Downloads] $ time sqlite3 generic_data_no_indexes.sqlite "select count(*) from fakenames_uk inner join fakenames_usa on fakenames_uk.givenname=fakenames_usa.givenname and fakenames_uk.surname=fakenames_usa.surname and fakenames_uk.middleinitial=fakenames_usa.middleinitial;" 131 real 0m0.115s user 0m0.111s sys 0m0.004s しかし、各テーブルの3つの列にインデックスを追加する場合(全部で6つのインデックス): CREATE INDEX `idx_uk_givenname` ON `fakenames_uk` (`givenname` ) //etc. …

2
インデックス付き日時列を使用したMySQLパフォーマンスの問題
次の問題を約1時間解決しようとしましたが、それでも解決できませんでした。 さて、テーブルがあります(MyISAM): +---------+-------------+------+-----+-------------------+----------------+ | Field | Type | Null | Key | Default | Extra | +---------+-------------+------+-----+-------------------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | http | smallint(3) | YES | MUL | 200 | | | elapsed | float(6,3) | NO | | …

4
良い、悪い、または無関心:WHERE 1 = 1
redditに関するこの質問を踏まえて、クエリをクリーンアップして、クエリのどこに問題があるのか​​を指摘しました。最初にコンマを使用しWHERE 1=1、クエリの変更を簡単にするため、クエリは通常、次のようになります。 SELECT C.CompanyName ,O.ShippedDate ,OD.UnitPrice ,P.ProductName FROM Customers as C INNER JOIN Orders as O ON C.CustomerID = O.CustomerID INNER JOIN [Order Details] as OD ON O.OrderID = OD.OrderID INNER JOIN Products as P ON P.ProductID = OD.ProductID Where 1=1 -- AND O.ShippedDate Between '4/1/2008' And '4/30/2008' And P.productname …

4
結合は実行時にwhere節に最適化されていますか?
このようなクエリを作成すると... select * from table1 t1 join table2 t2 on t1.id = t2.id SQLオプティマイザーは、それが正しい用語であるかどうかはわかりませんが、それを... select * from table1 t1, table2 t2 where t1.id = t2.id 基本的に、SQL ServerのJoinステートメントはsqlを書くための簡単な方法ですか?それとも、実際に実行時に使用されますか? 編集:私はほとんど常に、そしてほとんど常にJoin構文を使用します。私は何が起こるのか興味があります。

4
数百万行の狭いテーブルでクエリのパフォーマンスを向上させることは可能ですか?
現在、クエリの完了に平均2500msかかっています。私のテーブルは非常に狭いですが、4,400万行あります。パフォーマンスを改善するためにどのようなオプションが必要ですか、またはこれは得られるほど良いですか? クエリ SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats] WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31'; テーブル CREATE TABLE [dbo].[Heartbeats]( [ID] [int] IDENTITY(1,1) NOT NULL, [DeviceID] [int] NOT NULL, [IsPUp] [bit] NOT NULL, [IsWebUp] [bit] NOT NULL, [IsPingUp] [bit] NOT NULL, [DateEntered] [datetime] NOT NULL, CONSTRAINT [PK_Heartbeats] PRIMARY KEY CLUSTERED ( [ID] …

5
この2000万件のレコードビューをより速くクエリするにはどうすればよいですか?
検索機能では、検索する必要があるすべてのテーブルのレコードを含むビューを使用しています。ビューには、ほぼ2000万件のレコードがあります。このビューに対する検索には時間がかかりすぎています。 このビューのパフォーマンスを改善するためにどこを調べるべきですか? ビューの大まかな定義は次のとおりです。13のテーブルと約30のフィールドが含まれます。 CREATE VIEW [dbo].[v_AllForSearch] AS SELECT FT.firstField AS [firstField] , FT.fld_primary AS [fld_primary] , FT.fld_thirdField AS [thirdField] , FT.fld_fourthField AS [fourthField] , ISNULL(ST.[fld_firstSearchField],'') AS [firstSearchField] , ISNULL(TT.[fld_thirdSearch],'') AS thirdSearch , ISNULL(TT.[fld_fourthSearch],'')AS fourthSearch , ISNULL(TT.[fld_fifthSearch],'')AS fifthSearch , ISNULL(FRT.[fld_sixthSearch],'') As [sixthSearch] , ISNULL(FRT.[fld_seventhSearch],'') AS [seventhSearch] , ISNULL(FRT.[fld_eightSearch],'')AS [eightSearch] , ISNULL(FIT.[fld_nineSearch],'') …

5
SQL Serverに、記述されたクエリ条件を強制的に実行しますか?
私はSQL Server 2008 R2を使用していますが、この疑似クエリ(SP)があります: select ... from ... WHERE @LinkMode IS NULL AND (myColumn IN (...very long-running query...)) ... ... 問題は、クエリを実行するのに非常に長い時間がかかること@LinkMode=2です。 お気づきのように、@ LinkModeがnullの場合にのみ長時間実行クエリを実行する必要がありますが、ここではそうではありません。私の場合、@ LinkMode = 2! ただし、次のように変更すると: select ... from ... WHERE 1=2 AND (myColumn IN (...very long time exeted query...)) ... ... SP は高速で実行されます。 以前に、オプティマイザーが条件の順序を最適化できることを聞いたことがあります。 だから私は尋ねる: オプティマイザが別のルートを選択した場合でも、次のことを確認するよりも高速なのは何=nullですか?私が意味する、私はそのチェックが考えるif a==nullあるずっと速く、他の長いクエリを実行するよりも... どのように私がすることができます強制、私はそれ(同じ順序)書いたとして、クエリを実行するために、SQL …

5
大きなテーブルでLEFT JOINを使用して非常に遅いSELECTを最適化する方法
私は何時間もグーグルで独学で解決策を探していましたが、運がありませんでした。ここではいくつかの同様の質問を見つけましたが、この場合は見つかりませんでした。 私のテーブル: 人(〜1000万行) 属性(場所、年齢、...) 人と属性の間のリンク(M:M)(〜40M行) フルダンプ〜280MB 状況:person_idいくつかの場所(location.attribute_value BETWEEN 3000 AND 7000)、性別(gender.attribute_value = 1)、生まれた年(bornyear.attribute_value BETWEEN 1980 AND 2000)、目の色(eyecolor.attribute_value IN (2,3))から すべての個人ID()を選択しようとしています。 これは私の魔女が3〜4 分かかったクエリです。最適化したい: SELECT person_id FROM person LEFT JOIN attribute location ON location.attribute_type_id = 1 AND location.person_id = person.person_id LEFT JOIN attribute gender ON gender.attribute_type_id = 2 AND gender.person_id = person.person_id …

1
部分的にカバーする範囲の述語の優先度推定
現時点では、ヒストグラムステップを部分的にカバーする範囲述部のカーディナリティをSQL Serverがどのように評価するかを理解しようとしています。 インターネット上で、ステップ内統計値の基数推定で、私は同様の質問に出くわし、Paul Whiteはそれに対してかなり興味深い答えを出しました。 Paulの答えによれば、述語> =および>のカーディナリティーを推定するための式(この場合、少なくとも120のカーディナリティー推定モデルにのみ興味があります)は次のとおりです。 >の場合: Cardinality = EQ_ROWS + (AVG_RANGE_ROWS * (F * (DISTINCT_RANGE_ROWS - 1))) > =の場合: Cardinality = EQ_ROWS + (AVG_RANGE_ROWS * ((F * (DISTINCT_RANGE_ROWS - 1)) + 1)) TransactionDate列と '20140614'から '20140618'までの日時の範囲を使用して、範囲の述語に基づいてAdventureWorks2014データベースの[Production]。[TransactionHistory]テーブルでこれらの式の適用をテストしました。 この範囲のヒストグラムステップの統計は次のとおりです。 式に従って、次のクエリの基数を計算しました。 SELECT COUNT(1) FROM [AdventureWorks2014].[Production].[TransactionHistory] WHERE [TransactionDate] BETWEEN '20140615 00:00:00.000' AND '20140616 00:00:00.000' …

2
DBCC FREEPROCCACHEもDBCC FREESYSTEMCACHE( 'SQL Plans')もCACHESTORE_SQLCPメモリを解放するために何もしません
CACHESTORE_SQLCP SQLプランは、数日後に38 GBを超えます。 「アドホックワークロード用に最適化」オプションをオンにして既に実行しています。(Entity Frameworkとカスタムレポートにより、多くのアドホックが作成されます!) マルチAZミラーリングを使用するAWS RDS上のSQL Server 2016 SE 3.00.2164.0.v1 実行すると: DBCC FREESYSTEMCACHE('SQL Plans'); または DBCC FREEPROCCACHE または DBCC FREESYSTEMCACHE ('SQL Plans') WITH MARK_IN_USE_FOR_REMOVAL または DBCC FREESYSTEMCACHE ('ALL') WITH MARK_IN_USE_FOR_REMOVAL; それをクリアしていないようです: SELECT TOP 1 type, name, pages_kb FROM sys.dm_os_memory_clerks ORDER BY pages_kb desc type name pages_kb CACHESTORE_SQLCP SQL Plans …

1
SQL Server 2016のSUBSTRING()を含む述語の見積もりの​​変更?
SUBSTRING()または他の文字列関数を含む述語のカーディナリティを推定する方法に関するSQL Server 2016の変更に関するドキュメントまたは調査はありますか? 私が尋ねている理由は、互換モード130でパフォーマンスが低下したクエリを見て、SUBSTRING()の呼び出しを含むWHERE句に一致する行数の推定値の変更に関係した理由です。クエリの書き換えで問題を修正しましたが、SQL Server 2016のこの領域の変更に関するドキュメントを誰かが知っているかどうか疑問に思っています。 デモコードは次のとおりです。このテストケースでは推定値は非常に近いものですが、精度はデータによって異なります。 テストケースでは、compatレベル120ではSQL Serverは推定にヒストグラムを使用しているように見えますが、compatレベル130ではSQL Serverはテーブルの10%が固定されていると仮定しています。 CREATE DATABASE MyStringTestDB; GO USE MyStringTestDB; GO DROP TABLE IF EXISTS dbo.StringTest; CREATE TABLE dbo.StringTest ( [TheString] varchar(15) ); GO INSERT INTO dbo.StringTest VALUES ( 'Y5_CLV' ); INSERT INTO dbo.StringTest VALUES ( 'Y5_EG3' ); INSERT INTO dbo.StringTest VALUES ( 'ZY_NE' …

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.