タグ付けされた質問 「temporary-tables」

これは非常に多くの神話と相反する見解を持つ領域のようです。 それでは、SQL Serverのテーブル変数とローカル一時テーブルの違いは何ですか？

452 sql-server  t-sql  temporary-tables 

ここで、一時テーブルとテーブル変数、およびSQL ServerのパフォーマンスとSQL Server 2008に対する影響についての記事を見て、 2005年に示された結果と同様の結果を再現することができました。 10行のみでストアドプロシージャ（以下の定義）を実行すると、テーブル変数バージョンは一時テーブルバージョンを2回以上実行します。 プロシージャキャッシュをクリアし、両方のストアドプロシージャを10,000回実行してから、さらに4回実行するプロセスを繰り返しました。以下の結果（バッチあたりのミリ秒単位の時間） T2_Time V2_Time ----------- ----------- 8578 2718 6641 2781 6469 2813 6766 2797 6156 2719 私の質問は次のとおりです。テーブル変数バージョンのパフォーマンスが向上する理由は何ですか？ 調査を行いました。例：パフォーマンスカウンターを見る SELECT cntr_value from sys.dm_os_performance_counters where counter_name = 'Temp Tables Creation Rate'; どちらの場合も、一時オブジェクトは、最初の実行後にキャッシュされていることを確認し、予想通り呼び出しごとではなく、再びゼロから作成しました。 同様に、トレースAuto Stats、SP:Recompile、SQL:StmtRecompileこれらのイベントのみ（の最初の起動時に一度発生することを示しているプロファイラのイベント（下のスクリーンショット）を#tempテーブルストアドプロシージャ）および他の9,999の実行は、これらのイベントのいずれかを上げていません。（テーブル変数バージョンはこれらのイベントを取得しません） ストアドプロシージャの最初の実行のわずかに大きいオーバーヘッドは、全体的な大きな違いを説明することはできませんが、プロシージャキャッシュをクリアして両方のプロシージャを1回実行するのに数ミリ秒しかかからないため、統計または再コンパイルが原因である可能性があります。 必要なデータベースオブジェクトを作成する CREATE DATABASE TESTDB_18Feb2012; GO USE TESTDB_18Feb2012; CREATE TABLE NUM ( n …

37 sql-server  temporary-tables 

ユーザーが現在遅いと感じるサイト（Moodle）を運営しています。私は、ディスク上に一時テーブルを作成するMySQLの問題を突き止めたと思います。created_tmp_disk_tablesMysql Workbenchサーバー管理で変数を見ると、その数は約50テーブル/秒で増加します。1日の使用後、created_tmp_disk_tables> 100kです。また、メモリは解放されていないようです。システムがほとんど使用できなくなり、MySQLを再起動するまで、使用量は増加し続けます。私はほぼ毎日それを再起動する必要があり、利用可能なメモリの約30〜35％を使用して開始し、80％で1日を終了します。 データベースにblobがなく、クエリを制御できないため、クエリを最適化することもできません。Percona Confirguration Wizardも使用しましたを使用して構成ファイルを生成しましたが、my.iniでも問題は解決しませんでした。 ご質問 MySQLがディスク上に一時テーブルを作成しないようにするには、何を変更すればよいですか？変更する必要がある設定はありますか？もっとメモリを投入する必要がありますか？ MySQLがメモリを使い果たすのを止めるにはどうすればよいですか？ 編集 slow_queriesログを有効にすると、クエリのSELECT GET_LOCK()ログが遅いことがわかりました。クイック検索の結果、PHP構成で永続的な接続が許可されていたことがわかりました（mysqli.allow_persistent = ON）。これをオフにしました。これにより、MySQLがメモリを消費する割合が減少しましたが、一時テーブルはまだ作成されています。 また、key_buffer sizeが十分に大きいことも確認しました。変数を見ましたkey_writes。これはゼロでなければなりません。そうでない場合、key_buffer_size.I have zero key_readsand zeroを増やすkey_writesので、key_buffer_sizeが十分に大きいます。 私は増加tmp_table_sizeし、max-heap-table-sizeテーブルがメモリに収まることができないことを示すことがありcreated_tmp_disk_tablesの増加として1024Mに。これで解決しませんでした。 参照：http : //www.mysqlperformanceblog.com/2007/08/16/how-much-overhead-is-caused-by-on-disk-temporary-tables/ 編集2 sort_merge_passesSHOW GLOBAL STATUS出力で1秒あたりの数が多い場合は、sort_buffer_size値を増やすことを検討できます。私はsort_merge_passes1時間で2つ持っていたので、sort_buffer_size十分に大きいと考えています。 参照：Mysqlマニュアル sort_buffer_size 編集3 @RolandoMySQLDBAの提案に従って、ソートバッファーと結合バッファーを変更しました。結果は下の表に表示されていますが、created_tmp_tables_on_diskまだ高いと思います。値を変更しcreated_tmp_tables_on_disk、1日（8時間）後にチェックして平均を計算した後、mysqlサーバーを再起動しました。他の提案はありますか？ある種のコンテナに収まらないものがあるように思えますが、それが何であるかを判断することはできません。 +---------------------+-------------+-------------+--------------------+ | Tmp_table_size, | Sort_buffer | Join_buffer | No of created | | max_heap_table_size | | | tmp_tables …

27 mysql  performance  windows  database-tuning  temporary-tables 

ストアドプロシージャの一時テーブルのvarchar(255)すべてのvarcharフィールドに使用することについて、妻の仕事について議論があります。基本的に、一方のキャンプは定義が変更されても常に機能するため255を使用し、もう一方のキャンプは潜在的なパフォーマンス向上のためにソーステーブルのサイズを維持したいと考えています。 パフォーマンスキャンプは正しいですか？他に影響はありますか？彼らはSQL Serverを使用しています。

16 sql-server  performance  datatypes  temporary-tables 

どういうわけか、数十年前に、データベースで始まるテーブルが作成されました#。オブジェクトエクスプローラーでは、アプリのデータベースの下に表示されますが、ではありませんtempdb。何らかの理由で、Azureはこのようなデータベースをインポートしません。 ドロップしたり、名前を変更したり、操作したりすることはできません。オブジェクトエクスプローラーからの削除、スクリプトドロップ、GUIからの名前変更を試みましたが、いずれも機能しませんでした。 SQL 2008 R2を使用しています。 drop table [*app*].[dbo]."#OBSOLETE"; Database name '*app*' ignored, referencing object in tempdb. Msg 3701, Level 11, State 5, Line 1 Cannot drop the table '#OBSOLETE', because it does not exist or you do not have permission. exec sp_rename "dbo.#OBSOLETE", "dbo.obsolete" Msg 15225, Level 11, State 1, …

13 sql-server  sql-server-2008-r2  temporary-tables 

MySQLの再帰ストアドプロシージャを使用してという一時テーブルを生成してid_listいますが、フォローアップ選択クエリでそのプロシージャの結果を使用する必要があるためDROP、プロシージャ内で一時テーブルを使用できません... BEGIN; /* generates the temporary table of ID's */ CALL fetch_inheritance_groups('abc123',0); /* uses the results of the stored procedure in the WHERE */ SELECT a.User_ID FROM usr_relationships r INNER JOIN usr_accts a ON a.User_ID = r.User_ID WHERE r.Group_ID = 'abc123' OR r.Group_ID IN (SELECT * FROM id_list) GROUP BY …

13 mysql  stored-procedures  memory  temporary-tables 

SQL Serverは、ストアドプロシージャ内で作成された一時テーブルをキャッシュし、プロシージャが終了してその後実行されるときにそれらの名前を変更するだけです。私の質問は、tempdbスペースがいつ解放されるかに関するものです。手順の最後でテーブルが切り捨てられることを読みました。これはセッションごとに処理されることをコメントで読んでおり、クリーンアップが必要かどうかについての質問がMSDNで回答されています。しかし、同じセッションで2回実行されない場合はどうでしょうか？ また、テーブルが範囲外になるとその領域を解放するバックグラウンドガベージコレクションプロセスがあることも聞いたことがあります。 それを作成するストアドプロシージャの最後で一時テーブルを切り捨てると、逆の期待にもかかわらず、truncateステートメントが使用されていない場合よりも、テーブルがtempdbでデータ用に使用するスペースがより速く解放されるようです。どうして？ そのような切り捨てステートメントを使用するかどうかの相対的なパフォーマンスへの影響はどうなりますか？SNAPSHOT分離を使用する場合、tempdbにストレスがかかることがよくあります。tempdbで使用されているスペースをできるだけ大きなtempテーブルからできるだけ早く解放すると、tempdbの不必要な増大を防ぐことができると思います。この潜在的なスペース節約は、パフォーマンスを犠牲にして実現されるでしょうか？ 以下に、問題を再現するためのコードを示します（主に@TheGameiswarから、いくつかの変更を加えたものです）。 SET NOCOUNT ON; GO ALTER PROC usp_test AS BEGIN IF object_id('tempdb..#temp') IS NOT NULL DROP TABLE #temp SELECT * INTO #temp FROM [dbo].[Event_28] -- This is a table with 15313 rows, using 35648 KB according to sp_spaceused --SELECT SUM(user_object_reserved_page_count) AS [user object pages used] …

12 sql-server  stored-procedures  tempdb  temporary-tables  truncate 

SQL Server 2005には次の問題があります。いくつかの行をテーブル変数に挿入しようとすると、一時テーブルを使用した同じ挿入に比べて時間がかかります。 これは、テーブル変数に挿入するコードです DECLARE @Data TABLE(...) INSERT INTO @DATA( ... ) SELECT .. FROM ... これは、一時テーブルに挿入するコードです CREATE #Data TABLE(...) INSERT INTO #DATA( ... ) SELECT .. FROM ... DROP TABLE #Data 一時テーブルにはキーもインデックスもありません。選択部分は2つのクエリで同じであり、選択によって返される結果の数は〜10000行です。選択を単独で実行するのに必要な時間は約10秒です。 一時テーブルバージョンの実行には最大10秒かかり、5分後にテーブル変数バージョンを停止する必要がありました。 クエリは一時テーブルへのアクセスを許可しないテーブル値関数の一部であるため、テーブル変数を使用する必要があります。 テーブル変数バージョンの実行計画 一時テーブルバージョンの実行計画

12 sql-server-2005  performance  temporary-tables 

テーブル変数に値を格納するストアドプロシージャがあります。これらの値を選択し、プロシージャが呼び出されたときにそれらを返します。 これらの戻り値を別のテーブル変数に設定しようとしていますが、わかりません。 ストアドプロシージャ ALTER PROCEDURE [dbo].[GetOrSetDomainId] @DomainName varchar(50), @DomainUrl varchar(50) AS BEGIN DECLARE @DomainId bigint; DECLARE @NumberOfRwos bigint; DECLARE @DomainHistory TABLE ( DomainId bigint, HasHistory bit, ServerOnline bit, DatabaseOnline bit, ServerPerformance bigint, DatabasePerformance bigint, SoldTickets bigint ) SELECT @NumberOfRwos = COUNT(Id) FROM DomainData WHERE DomainName = @DomainName OR DomainUrl = …

12 sql-server  t-sql  stored-procedures  temporary-tables 

次の単純なMCVEについて考えてみます。 SET STATISTICS IO, TIME OFF; USE tempdb; IF OBJECT_ID(N'tempdb..#t1', N'U') IS NOT NULL DROP TABLE #t1; CREATE TABLE #t1 ( r int NOT NULL ); IF OBJECT_ID(N'tempdb..##t1', N'U') IS NOT NULL DROP TABLE ##t1; CREATE TABLE ##t1 ( r int NOT NULL ); IF OBJECT_ID(N'dbo.s1', N'U') IS NOT NULL …

11 sql-server  sql-server-2016  temporary-tables 

最近TechNetで読んだ一時テーブルに関するドキュメントについて質問があります。そのページの一時テーブルセクションの4番目の段落は、次のようになります。 名前付き制約を使用して一時テーブルが作成され、一時テーブルがユーザー定義のトランザクションのスコープ内で作成される場合、一時テーブルを作成するステートメントを実行できるのは一度に1人のユーザーだけです。たとえば、ストアドプロシージャが名前付きの主キー制約を持つ一時テーブルを作成する場合、そのストアドプロシージャを複数のユーザーが同時に実行することはできません。 私は、インデックス化された一時テーブルを使用する少数のストアドプロシージャを大幅に利用する環境で作業しており、ユーザーが次の処理が始まる前に実行が完了するのを待たなければならないという問題に遭遇したことはありません。それが今後も続くことを願っていますが、この警告が適切に理解されていないと問題になる可能性があることを懸念しています。 具体的には、次の点については不明です。 これはグローバル一時テーブルにのみ適用されますか、それともローカル一時テーブルにも適用されますか？（後者の場合のように）セッションの外部に表示されないテーブルが別のセッションの同時実行を妨げるのは奇妙に思われます。 「名前付き制約」とは何ですか？すべての制約に名前が付いているわけではありませんか（システムで生成された場合でも）。これは、ユーザー定義のエイリアスを持つ制約を参照していますか？これは私には言い回しのように思えます。 「複数のユーザー」は実際には複数のセッションを意味しますか？これらの手順は、単一のサービスアカウントを使用してアプリケーションから呼び出されるため、スクリプトへの呼び出しの99.9％はその単一のアカウントによってDBに対して行われます（そして、管理者がバックエンドでときどき呼び出す可能性があるのではないかと心配しています）。サービスアカウントが複数のセッションで同時にsprocを実行できる場合、この問題は私の目的には当てはまりません。

9 sql-server  stored-procedures  temporary-tables 

多くのPHP / MySQL Webサイト（フォトギャラリー）をホストしているDebian Linuxサーバーでは、のような「多数の」ファイルがある場合があります/tmp/#sql_6405_58.MYD。 たとえば、今日： [2012-12-15 15:18:11] /tmp/#sql_6405_6.MYD : 88MB [2012-12-15 15:18:11] /tmp/#sql_6405_3.MYD : 22MB [2012-12-15 15:18:11] /tmp/#sql_6405_4.MYD : 138MB [2012-12-15 15:18:11] /tmp/#sql_6405_10.MYD : 88MB ... [2012-12-15 15:18:11] /tmp/#sql_6405_9.MYD : 15MB [2012-12-15 15:18:11] /tmp/#sql_6405_65.MYD : 49MB [2012-12-15 15:18:11] /tmp/#sql_6405_44.MYD : 69MB （同時に59ファイル、6GB以上の場合...はい/ tmpの大きなファイルを監視します） 残念ながら、/tmpと同じパーティション上に/あり、一時的にWebサーバーが壊れ/ます。その後、ファイルが消え、サーバーは通常の状態に戻ります。 すべてのファイル名は#sql_6405_*.MYDパターンに従います。どのMySQL操作が非常に多くの一時ファイルを意味するのかを理解したいと思います。このサーバーには約2000のデータベースがあります。どのデータベースが関係しているかを知ることは可能ですか？

9 mysql  myisam  temporary-tables 

質問の要点：実際のストアドプロシージャは、一時テーブルキャッシュを実装する唯一のメカニズムですか、それともsp_executeSQL/ などのシステムストアドプロシージャsp_executeもそれらを利用しますか？ 私はDBAではないので、少しだけ言葉を使ってください。私たちのアプリケーションは、プロファイラーから、sp_prepexec実行sp_prepareとの両方のシステムプロシージャであるすべてのSQLを実行する準備済みステートメントを送信しますsp_execute。私がやろうとしているのは、一時テーブルのキャッシュから利益を得ているかどうかを判断することです。 このガイドをobject_id（）と一緒に使用して動作を調べています https://sqlkiwi.blogspot.com/2012/08/temporary-tables-in-stored-procedures.html 次に、このブログ投稿のポイント3は、EXECは一時テーブルキャッシュを使用できないことを示していますが、sp_executeSQLができるかどうかは省略しています：http : //blogs.msdn.com/b/turgays/archive/2013/09/18/exec-vs- sp-executesql.aspx クライアント経由で送信されたクエリでは、単純な一時テーブルを作成しました。 DECLARE @foo int; -- set by JDBC, unused but required to force a prepared statement SELECT 1 AS id INTO #tmp SELECT OBJECT_ID('tempdb..#tmp'); プロファイラーで、私は見ることができます： declare @p1 int set @p1=NULL exec sp_prepexec @p1 output,N'@P1 int',N'declare @foo INT = @P1 SELECT 1 …

8 sql-server  stored-procedures  dynamic-sql  temporary-tables  prepared-statement 

この特定のケースでは、以下で説明しようとしますが、テーブル変数を使用すると、テーブル変数を使用しない場合よりもパフォーマンスが向上します。 理由を知りたいのですが、可能であれば、テーブル変数を削除します。 これは、テーブル変数を使用したクエリです。 USE [BISource_UAT] GO set statistics io on SET STATISTICS TIME ON SET NOCOUNT ON; DECLARE @OrderStartDate DATETIME = '15-feb-2015' DECLARE @OrderEndDate DATETIME = '28-feb-2016' DECLARE @tmp TABLE ( strBxOrderNo VARCHAR(20) ,sintReturnId INT ) INSERT INTO @tmp SELECT strBxOrderNo ,sintReturnId FROM TABLEBACKUPS.dbo.tblBReturnHistory rh WHERE rh.sintReturnStatusId in ( 3 …

8 sql-server  sql-server-2014  query-performance  temporary-tables  table-variable 

私は現在、やや問題のあるストアドプロシージャを調整しようとしています。実行に関連するコストの大部分は、いくつかのXMLを解析して一時テーブルに解析することに起因することに気付きました。問題のSQLは次のとおりです。 CREATE TABLE #ChangeSet ( RemarkTypeID TINYINT NOT NULL PRIMARY KEY, RemarkText VARCHAR(2500) NOT NULL, ListingID INT NOT NULL ) INSERT INTO #ChangeSet (RemarkTypeID, RemarkText, ListingID) SELECT T.c.value('@RemarkTypeID[1]','tinyint') AS RemarkTypeID, T.c.value('@RemarkText[1]','varchar(2500)') AS RemarkText, @ListingID FROM @RemarksXml.nodes('/Remarks[1]/Remark') AS T(c) また、あなたは構文解析されているXMLの構造のいくつかの考えを持っています： <Remarks> <Remark xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" RemarkID="211767" DateTimeCreated="1991-11-19T10:43:50" DateTimeModified="1992-01-01T10:43:50" RemarkTypeID="8" RemarkText="aaaWasher,Dryer,Refriger,Microwav" /> <Remark xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" …

8 sql-server  xml  temporary-tables