Azure Synapse Analytics での専用 SQL プール (旧称 SQL DW) 用のベスト プラクティスBest practices for dedicated SQL pool (formerly SQL DW) in Azure Synapse Analytics

この記事には、専用 SQL プール (旧称 SQL DW) のデプロイで最適なパフォーマンスを実現するのに役立つベスト プラクティスがまとめられています。This article is a collection of best practices to help you to achieve optimal performance from your dedicated SQL pool (formerly SQL DW) deployment. この記事の目的は、基本的なガイダンスをいくつか提供し、注目すべき重要な領域を強調することです。The purpose of this article is to give you some basic guidance and highlight important areas of focus.

一時停止とスケールでコストを削減するReduce cost with pause and scale

一時停止とスケーリングを通じてコストを削減する方法については、コンピューティングの管理に関するページを参照してください。For more information about reducing costs through pausing and scaling, see the Manage compute.

統計を管理するMaintain statistics

列の統計を自動的に検出して作成するように、専用 SQL プール (旧称 SQL DW) を構成できます。Dedicated SQL pool (formerly SQL DW) can be configured to automatically detect and create statistics on columns. オプティマイザーによって作成されたクエリ プランの有効性は、使用可能な統計によって決まります。The query plans created by the optimizer are only as good as the available statistics.

ご使用のデータベースに対して AUTO_CREATE_STATISTICS を有効にし、クエリで使用されている列の統計が確実に最新の状態になるように、統計を毎日または読み込みのたびに更新することをお勧めします。We recommend that you enable AUTO_CREATE_STATISTICS for your databases and keep the statistics updated daily or after each load to ensure that statistics on columns used in your queries are always up to date.

すべての統計を更新するのに時間がかかりすぎる場合は、統計を頻繁に更新する必要がある列を限定することをお勧めします。If you find it is taking too long to update all of your statistics, you may want to try to be more selective about which columns need frequent statistics updates. たとえば、新しい値が毎日追加される日付列を更新します。For example, you might want to update date columns, where new values may be added, daily.

ヒント

結合に使用されている列、WHERE 句で使用されている列、および GROUP BY に含まれている列に関する統計を更新すると、最も大きなメリットが得られます。You will gain the most benefit by having updated statistics on columns involved in joins, columns used in the WHERE clause and columns found in GROUP BY.

テーブル統計の管理CREATE STATISTICSUPDATE STATISTICS に関するページも参照してください。See also Manage table statistics, CREATE STATISTICS, and UPDATE STATISTICS.

DMV を使用して、クエリを監視および最適化するUse DMVs to monitor and optimize your queries

専用 SQL プール (旧称 SQL DW) には、クエリの実行を監視するために使用できる DMV がいくつか用意されています。Dedicated SQL pool (formerly SQL DW) has several DMVs that can be used to monitor query execution. DMV を使用したワークロードの監視に関するページでは、実行中のクエリの詳細を確認する方法の詳細な手順が説明されています。The Monitor your workload using DMVs article details step-by-step instructions on how to look at the details of an executing query.

これらの DMV でクエリをすばやく見つけるには、クエリで LABEL オプションを使用すると便利です。To quickly find queries in these DMVs, using the LABEL option with your queries can help.

DMV を使用したワークロードの監視LABELOPTIONsys.dm_exec_sessionssys.dm_pdw_exec_requestssys.dm_pdw_request_stepssys.dm_pdw_sql_requestssys.dm_pdw_dms_workersDBCC PDW_SHOWEXECUTIONPLANsys.dm_pdw_waits に関するページも参照してください。See also Monitor your workload using DMVs, LABEL, OPTION, sys.dm_exec_sessions, sys.dm_pdw_exec_requests, sys.dm_pdw_request_steps, sys.dm_pdw_sql_requests, sys.dm_pdw_dms_workers, DBCC PDW_SHOWEXECUTIONPLAN, and sys.dm_pdw_waits.

新しい製品の機能強化でクエリのパフォーマンスを調整するTune query performance with new product enhancements

INSERT ステートメントをバッチにグループ化するGroup INSERT statements into batches

INSERT ステートメントで小さなテーブルに 1 回だけ読み込む場合や、検索を定期的に再読み込みする場合は、INSERT INTO MyLookup VALUES (1, 'Type 1') などのステートメントで、ニーズに十分応えることができます。A one-time load to a small table with an INSERT statement or even a periodic reload of a look-up may perform well for your needs with a statement like INSERT INTO MyLookup VALUES (1, 'Type 1').

ただし、1 日を通して数千や数百万行を読み込む必要がある場合、シングルトンの INSERT だけでは対応できない可能性があります。However, if you need to load thousands or millions of rows throughout the day, you might find that singleton INSERTS just can't keep up. 代わりに、ファイルに書き込み、定期的に別のプロセスを利用してそのファイルを読み込むプロセスを作成します。Instead, develop your processes so that they write to a file and another process periodically comes along and loads this file.

INSERT に関するページも参照してください。See also INSERT.

PolyBase を使用して、データの読み込みとエクスポートをすばやく実行するUse PolyBase to load and export data quickly

専用 SQL プール (旧称 SQL DW) では、Azure Data Factory、PolyBase、BCP など、さまざまなツールを使用したデータの読み込みとエクスポートがサポートされています。Dedicated SQL pool (formerly SQL DW) supports loading and exporting data through several tools including Azure Data Factory, PolyBase, and BCP. パフォーマンスが重要でない少量のデータについては、どのツールでもニーズに十分応えることができます。For small amounts of data where performance isn't critical, any tool may be sufficient for your needs. ただし、大量のデータを読み込んだり、エクスポートしたりする場合や、高速なパフォーマンスが必要な場合は、PolyBase が最適な選択肢です。However, when you are loading or exporting large volumes of data or fast performance is needed, PolyBase is the best choice.

PolyBase はシステムの分散型という性質を活用するように設計されており、他のツールよりも速く大量のデータを読み込んだり、エクスポートしたりします。PolyBase is designed to leverage distributed nature of the system and will load and export data magnitudes faster than any other tool. PolyBase の読み込みは、CTAS または INSERT INTO を使用して実行できます。PolyBase loads can be run using CTAS or INSERT INTO.

ヒント

CTAS を使用すると、トランザクション ログが最小限に抑えられ、データを一番速く読み込むことができます。Using CTAS will minimize transaction logging and the fastest way to load your data.

Azure Data Factory では PolyBase の読み込みもサポートされ、CTAS と同様のパフォーマンスを実現できます。Azure Data Factory also supports PolyBase loads and can achieve similar performance as CTAS. PolyBase では、Gzip ファイルなど、さまざまなファイル形式をサポートしています。PolyBase supports a variety of file formats including Gzip files.

注意

gzip テキスト ファイルを使用する場合にスループットを最大限引き上げるには、ファイルを 60 個以上に分割して、読み込みの並列処理を最大化してください。To maximize throughput when using gzip text files, break up files into 60 or more files to maximize parallelism of your load. 全体のスループットを引き上げるには、データを同時に読み込むことを検討してください。For faster total throughput, consider loading data concurrently.

データの読み込みPolyBase の使用ガイド専用 SQL プールの読み込みパターンと戦略Azure Data Factory を使用したデータの読み込みAzure Data Factory を使用したデータ移動CREATE EXTERNAL FILE FORMATCreate table as select (CTAS) に関するページも参照してください。See also Load data, Guide for using PolyBase, Dedicated SQL pool loading patterns and strategies, Load Data with Azure Data Factory, Move data with Azure Data Factory, CREATE EXTERNAL FILE FORMAT, and Create table as select (CTAS).

外部テーブルを読み込んで、クエリを実行するLoad then query external tables

外部テーブルとも呼ばれる Polybase は、最も高速にデータを読み込むことができますが、クエリには適していません。While Polybase, also known as external tables, can be the fastest way to load data, it is not optimal for queries. Polybase テーブルで現在サポートされているのは、Azure BLOB ファイルと Azure Data Lake ストレージのみです。Polybase tables currently only support Azure blob files and Azure Data Lake storage. このファイルには、それをバックアップするためのコンピューティング リソースがありません。These files do not have any compute resources backing them.

つまり、専用 SQL プールではこの作業をオフロードできないため、データを読み取るには、ファイルを tempdb に読み込んで、ファイル全体を読み取る必要があります。As a result, dedicated SQL pool cannot offload this work and therefore must read the entire file by loading it to tempdb in order to read the data. したがって、このデータに対して複数のクエリを実行する場合は、データを一度読み込んで、クエリがローカル テーブルを使うように指定することをお勧めします。Therefore, if you have several queries that will be querying this data, it is better to load this data once and have queries use the local table.

PolyBase の使い方ガイドも参照してください。See also Guide for using PolyBase.

ハッシュで大規模なテーブルを分散させるHash distribute large tables

既定では、テーブルはラウンド ロビン分散です。By default, tables are Round Robin distributed. そのため、ユーザーはテーブルの分散方法を決定することなくテーブルの作成を簡単に開始できます。This makes it easy for users to get started creating tables without having to decide how their tables should be distributed. ラウンド ロビン テーブルは一部のワークロードでは十分なパフォーマンスを示しますが、多くの場合、分散列を選択すると、パフォーマンスが大幅に向上します。Round Robin tables may perform sufficiently for some workloads, but in most cases selecting a distribution column will perform much better.

列で分散したテーブルのパフォーマンスがラウンド ロビン テーブルをはるかに上回る最も一般的な例としては、2 つの大規模なファクト テーブルが結合されている場合が挙げられます。The most common example of when a table distributed by a column will far outperform a Round Robin table is when two large fact tables are joined.

たとえば、orders テーブルが order_id で分散されており、transactions テーブルも order_id で分散されている場合に、orders テーブルを transactions テーブルに order_id で結合すると、このクエリはパススルー クエリになり、データの移動処理が行われなくなります。For example, if you have an orders table, which is distributed by order_id, and a transactions table, which is also distributed by order_id, when you join your orders table to your transactions table on order_id, this query becomes a pass-through query, which means we eliminate data movement operations. 手順が減るため、クエリは高速になります。Fewer steps mean a faster query. また、データの移動の減少もクエリの高速化に貢献します。Less data movement also makes for faster queries.

ヒント

分散テーブルを読み込む場合は、受信データを分散キーで並べ替えないでください。読み込みが遅くなります。When loading a distributed table, be sure that your incoming data is not sorted on the distribution key as this will slow down your loads.

分散列を選択した場合にパフォーマンスが向上するしくみや、CREATE TABLE ステートメントの WITH 句で分散テーブルを定義する方法の詳細については、次のリンクを参照してください。See the following links for more details on how selecting a distribution column can improve performance as well as how to define a distributed table in the WITH clause of your CREATE TABLE statement.

テーブルの概要テーブル分散テーブル分散の選択CREATE TABLECREATE TABLE AS SELECT に関するページも参照してください。See also Table overview, Table distribution, Selecting table distribution, CREATE TABLE, CREATE TABLE AS SELECT.

パーティション分割しすぎないようにするDo not over-partition

データをパーティション分割すると、パーティション切り替えを利用してデータを管理したり、パーティションを除外してスキャンを最適化したりできるため、有用ですが、パーティションが多すぎると、クエリの速度が低下する場合があります。While partitioning data can be effective for maintaining your data through partition switching or optimizing scans by with partition elimination, having too many partitions can slow down your queries. 多くの場合、高い粒度でパーティション分割する戦略は、SQL Server では効果的ですが、専用 SQL プール (旧称 SQL DW) では効果的ではありません。Often a high granularity partitioning strategy, which may work well on SQL Server may not work well in dedicated SQL pool (formerly SQL DW).

パーティションが多すぎると、各パーティションの行数が 100 万を下回る場合に、クラスター化列ストア インデックスの効果が減少する可能性もあります。Having too many partitions can also reduce the effectiveness of clustered columnstore indexes if each partition has fewer than 1 million rows. 専用 SQL プールでは、バックグラウンドでデータを 60 個のデータベースにパーティション分割します。そのため、パーティションが 100 個あるテーブルを作成すると、実質的にはパーティションが 6000 個になることに留意してください。Keep in mind that behind the scenes, dedicated SQL pool partitions your data for you into 60 databases, so if you create a table with 100 partitions, this actually results in 6000 partitions.

ワークロードはそれぞれに異なるため、パーティション分割を試して、自分のワークロードに最適な数を判断することをお勧めします。Each workload is different so the best advice is to experiment with partitioning to see what works best for your workload. SQL Server の場合よりも粒度を下げることを検討してください。Consider lower granularity than what may have worked for you in SQL Server. たとえば、日単位ではなく、週単位や月単位のパーティションを使用します。For example, consider using weekly or monthly partitions rather than daily partitions.

テーブル パーティションに関するページも参照してください。See also Table partitioning.

トランザクション サイズを最小限に抑えるMinimize transaction sizes

トランザクションで INSERT、UPDATE、DELETE ステートメントを実行して、失敗した場合は、ロールバックする必要があります。INSERT, UPDATE, and DELETE statements run in a transaction and when they fail they must be rolled back. ロールバック時間が長くならないようにするには、できる限りトランザクション サイズを最小限に抑えます。To minimize the potential for a long rollback, minimize transaction sizes whenever possible. そのためには、INSERT、UPDATE、DELETE ステートメントを複数に分割します。This can be done by dividing INSERT, UPDATE, and DELETE statements into parts.

たとえば、INSERT に 1 時間かかると予測される場合は、可能であれば、INSERT を 4 つに分割すると、それぞれの実行時間は 15 分になります。For example, if you have an INSERT that you expect to take 1 hour, if possible, break up the INSERT into four parts, which will each run in 15 minutes. CTAS、TRUNCATE、DROP TABLE、空のテーブルへの INSERT など、特殊な最小ログ記録のケースを活用すると、ロールバックのリスクが軽減されます。Leverage special Minimal Logging cases, like CTAS, TRUNCATE, DROP TABLE, or INSERT to empty tables, to reduce rollback risk.

ロールバックを回避するもう 1 つの方法としては、データ管理のためのパーティション切り替えなど、メタデータのみの操作を使用します。Another way to eliminate rollbacks is to use Metadata Only operations like partition switching for data management. たとえば、DELETE ステートメントを実行して、テーブル内の order_date が 2001 年 10 月のすべての行を削除する代わりに、月単位でデータをパーティション分割し、該当するデータを含むパーティションを別のテーブルの空のパーティションに切り替えします (ALTER TABLE の例を参照してください)。For example, rather than execute a DELETE statement to delete all rows in a table where the order_date was in October of 2001, you could partition your data monthly and then switch out the partition with data for an empty partition from another table (see ALTER TABLE examples).

パーティション分割されていないテーブルについては、DELETE を使用する代わりに、CTAS を使用して、テーブルに保持するデータを書き込むことを検討してください。For unpartitioned tables, consider using a CTAS to write the data you want to keep in a table rather than using DELETE. CTAS にかかる時間が同じ場合でも、トランザクション ログが最小限に抑えられ、必要なときにすばやく取り消すことができるため、CTAS は非常に安全に実行できる操作です。If a CTAS takes the same amount of time, it is a much safer operation to run as it has minimal transaction logging and can be canceled quickly if needed.

トランザクションの概要トランザクションの最適化テーブル パーティションTRUNCATE TABLEALTER TABLECreate table as select (CTAS) に関するページも参照してください。See also Understanding transactions, Optimizing transactions, Table partitioning, TRUNCATE TABLE, ALTER TABLE, and Create table as select (CTAS).

クエリ結果のサイズを縮小するReduce query result sizes

この手順は、大きなクエリ結果によって発生するクライアント側の問題を回避するのに役立ちます。This step helps you avoid client-side issues caused by large query result. クエリを編集して、返される行の数を減らすことができます。You can edit your query to reduce the number of rows returned. クエリ生成ツールによって、各クエリに "上位 N" 構文を追加することができます。Some query generation tools allow you to add "top N" syntax to each query. また、クエリ結果を一時テーブルに CETAS を行ってから、ダウンレベル処理に PolyBase エクスポートを使用することもできます。You can also CETAS the query result to a temporary table and then use PolyBase export for the downlevel processing.

できる限り最小の列サイズを使用するUse the smallest possible column size

DDL を定義するときに、データをサポートする最小のデータ型を使用すると、クエリのパフォーマンスが向上します。When defining your DDL, using the smallest data type that will support your data will improve query performance. この方法は、CHAR 列と VARCHAR 列では特に重要です。This approach is particularly important for CHAR and VARCHAR columns.

列の最長の値が 25 文字の場合は、列を VARCHAR(25) として定義します。If the longest value in a column is 25 characters, then define your column as VARCHAR(25). すべての文字列を既定の長さで定義しないようにします。Avoid defining all character columns to a large default length. さらに、VARCHAR で済む場合は、NVARCHAR を使用せずに、列を VARCHAR として定義します。In addition, define columns as VARCHAR when that is all that is needed rather than use NVARCHAR.

テーブルの概要テーブルのデータ型CREATE TABLE に関するページも参照してください。See also Table overview, Table data types, CREATE TABLE.

一時的なデータには一時的なヒープ テーブルを使用するUse temporary heap tables for transient data

データを一時的に読み込む際は、ヒープ テーブルを使用すると、プロセス全体が高速になる場合があります。When you are temporarily landing data, you may find that using a heap table will make the overall process faster. さらに変換を実行する前で、ステージングにのみデータを読み込んでいる場合は、ヒープ テーブルにデータを読み込むほうが、クラスター化列ストア テーブルにデータを読み込むよりも高速になります。If you are loading data only to stage it before running more transformations, loading the table to heap table will be much faster than loading the data to a clustered columnstore table.

さらに、テーブルを永続記憶域に読み込むよりも、データを一時テーブルに読み込んだ方が読み込み速度が大幅に向上します。In addition, loading data to a temp table will also load much faster than loading a table to permanent storage. 一時テーブルは、"#" で始まり、作成元のセッションからしかアクセスできないため、一部のシナリオでしか動作しません。Temporary tables start with a "#" and are only accessible by the session that created it, so they may only work in limited scenarios.

ヒープ テーブルは、CREATE TABLE の WITH 句で定義します。Heap tables are defined in the WITH clause of a CREATE TABLE. 一時テーブルを使用する場合は、その一時テーブルの統計も必ず作成してください。If you do use a temporary table, remember to create statistics on that temporary table too.

一時テーブルCREATE TABLECREATE TABLE AS SELECT に関するページも参照してください。See also Temporary tables, CREATE TABLE, CREATE TABLE AS SELECT.

クラスター化列ストア テーブルを最適化するOptimize clustered columnstore tables

クラスター化列ストア インデックスは、専用 SQL プールにデータを格納する最も効率的な方法の 1 つです。Clustered columnstore indexes are one of the most efficient ways you can store your data in dedicated SQL pool. 既定では、専用 SQL プールのテーブルは、クラスター化された ColumnStore として作成されます。By default, tables in dedicated SQL pool are created as Clustered ColumnStore. 列ストア テーブルに対するクエリのパフォーマンスを最大限に引き出すには、セグメントの質が高いことが重要です。To get the best performance for queries on columnstore tables, having good segment quality is important.

行を列ストア テーブルに書き込む際にメモリ負荷が発生すると、列ストア セグメントの質が低下する可能性があります。When rows are written to columnstore tables under memory pressure, columnstore segment quality may suffer. セグメントの質は、圧縮後の行グループに含まれる行の数を使って判断できます。Segment quality can be measured by number of rows in a compressed Row Group. クラスター化列ストア テーブルのセグメントの質を検出して向上させる詳細な手順については、テーブル インデックスに関するページの「列ストア インデックスの品質の低さの原因」を参照してください。See the Causes of poor columnstore index quality in the Table indexes article for step-by-step instructions on detecting and improving segment quality for clustered columnstore tables.

列ストア セグメントの質を高めることが非常に重要であるため、中規模または大規模リソース クラスのユーザー ID を使用してデータを読み込むことをお勧めします。Because high-quality columnstore segments are important, it's a good idea to use users IDs that are in the medium or large resource class for loading data. 低いデータ ウェアハウス ユニットを使用すると、大きいリソース クラスを読み込みユーザーに割り当てることになります。Using lower data warehouse units means you want to assign a larger resource class to your loading user.

通常、テーブルあたりの行数が 100 万を超え、各専用 SQL プール テーブルが 60 個にパーティション分割されるまで、列ストア テーブルは圧縮された列ストア セグメントにデータをプッシュしません。そのため、経験上、テーブルの行数が 6,000 万を超えない限り、列ストア テーブルはクエリにとってメリットがありません。Since columnstore tables generally won't push data into a compressed columnstore segment until there are more than 1 million rows per table and each dedicated SQL pool table is partitioned into 60 tables, as a rule of thumb, columnstore tables won't benefit a query unless the table has more than 60 million rows. 6,000 万行未満のテーブルについては、列ストア インデックスを作成してもメリットがありません。For table with less than 60 million rows, it may not make any sense to have a columnstore index. また、デメリットもありません。It also may not hurt.

さらに、データをパーティション分割する場合は、クラスター化列ストア インデックスの恩恵を受けるには、各パーティションに 100 万行が必要なことを考慮に入れる必要があります。Furthermore, if you partition your data, then you will want to consider that each partition will need to have 1 million rows to benefit from a clustered columnstore index. テーブルに 100 個のパーティションがある場合に、クラスター化列ストアの恩恵を受けるには、少なくとも 60 億行必要です (60 個のディストリビューション "100 個のパーティション" 100 万行)。If a table has 100 partitions, then it will need to have at least 6 billion rows to benefit from a clustered columns store (60 distributions 100 partitions 1 million rows).

この例でテーブルに 60 億行もない場合は、パーティションの数を減らすか、代わりにヒープ テーブルを使用することを検討してください。If your table does not have 6 billion rows in this example, either reduce the number of partitions or consider using a heap table instead. 列ストア テーブルの代わりに、ヒープ テーブルとセカンダリ インデックスを使用してパフォーマンスが向上するかどうかを試してみる価値もあります。It also may be worth experimenting to see if better performance can be gained with a heap table with secondary indexes rather than a columnstore table.

ヒント

列ストア テーブルに対してクエリを実行する場合は、必要な列のみを選択すると、クエリの実行速度が向上します。When querying a columnstore table, queries will run faster if you select only the columns you need.

テーブル インデックス列ストア インデックス列ストア インデックスの再構築に関するページもご覧ください。See also Table indexes, Columnstore indexes guide, Rebuilding columnstore indexes

大きなリソース クラスを使用して、クエリのパフォーマンスを向上させるUse larger resource class to improve query performance

専用 SQL プールでは、クエリにメモリを割り当てる方法としてリソース グループが使用されます。Dedicated SQL pool uses resource groups as a way to allocate memory to queries. 既定では、ディストリビューションごとに 100 MB のメモリが与えられる小規模リソース クラスにすべてのユーザーが割り当てられます。Out of the box, all users are assigned to the small resource class, which grants 100 MB of memory per distribution. 常に 60 個のディストリビューションが存在し、各ディストリビューションに最低 100 MB が割り当てられるため、システム全体のメモリの割り当ての合計は 6,000 MB (6 GB 弱) です。Since there are always 60 distributions and each distribution is given a minimum of 100 MB, system wide the total memory allocation is 6,000 MB, or just under 6 GB.

大規模な結合やクラスター化列ストア テーブルへの読み込みなど、特定のクエリについては、割り当てるメモリを増やすと効果的です。Certain queries, like large joins or loads to clustered columnstore tables, will benefit from larger memory allocations. 純粋なスキャンなどのクエリでは、効果はありません。Some queries, like pure scans, will yield no benefit. 一方で、より大きなリソース クラスを利用すると、コンカレンシーが減ります。そのため、すべてのユーザーをより大きなリソース クラスに移行する前に、この影響を考慮する必要があります。However, utilizing larger resource classes reduces concurrency, so you will want to take this impact into consideration before moving all of your users to a large resource class.

ワークロード管理用のリソース クラス」も参照してください。See also Resource classes for workload management.

小さいリソース クラスを使用して、コンカレンシーを増やすUse Smaller Resource Class to Increase Concurrency

ユーザー クエリの遅延が長いと感じている場合は、ユーザーが大きなリソース クラスで実行しており、コンカレンシー スロットを大量に使用していることが原因で、他のクエリがキューに配置されている可能性があります。If you notice that user queries seem to have a long delay, it could be that your users are running in larger resource classes and are consuming many concurrency slots causing other queries to queue up. ユーザー クエリがキューに配置されているかどうかを確認するには、 SELECT * FROM sys.dm_pdw_waits を実行して、行が返されるかどうかを確認します。To see if users queries are queued, run SELECT * FROM sys.dm_pdw_waits to see if any rows are returned.

ワークロード管理用のリソース クラス」、sys.dm_pdw_waits に関するページも参照してください。See also Resource classes for workload management, sys.dm_pdw_waits.

その他のリソースOther resources

一般的な問題と解決方法については、 トラブルシューティング に関する記事もご覧ください。Also see our Troubleshooting article for common issues and solutions.

この記事で目的のトピックが見つからなかった場合は、ページの左側にある [Search for docs] を使用して、すべての Azure Synapse ドキュメントで検索を実行してみてください。If you didn't find what you are looking for in this article, try using the "Search for docs" on the left side of this page to search all of the Azure Synapse documents. Azure Synapse の Microsoft Q&A 質問ページは、他のユーザーや Azure Synapse 製品グループに質問を投稿できる場所です。The Microsoft Q&A question page for Azure Synapse is a place for you to post questions to other users and to the Azure Synapse Product Group. Microsoft では、このフォーラムを積極的に監視し、お客様からの質問に他のユーザーや Microsoft のスタッフが回答しているかどうかを確認しています。We actively monitor this forum to ensure that your questions are answered either by another user or one of us.

Stack Overflow で質問したい方のために、Azure Synapse Stack Overflow フォーラムも用意しています。If you prefer to ask your questions on Stack Overflow, we also have an Azure Synapse Stack Overflow Forum.

Azure Synapse のフィードバック ページを使用して、機能に関するご要望を是非お寄せください。Please use the Azure Synapse Feedback page to make feature requests. 要望の追加や他の要求への投票は、機能の優先順位を決める際に役立ちます。Adding your requests or up-voting other requests really helps us prioritize features.