非常に大きなテーブルの正確な行数をカウントする最も速い方法は？

SELECT COUNT(*) FROM TABLE_NAMEテーブルに多数の行と多数の列があると遅くなると述べている記事を見つけました。

数十億行にもなるテーブルがあります（約15列です）。取得するためのより良い方法はありEXACTテーブルの行数のカウントは？

回答する前に、次の点を考慮してください。

• データベースベンダーに依存しないソリューションを探しています。MySQL、Oracle、MS SQL Serverをカバーしていれば問題ありません。しかし、データベースベンダーに依存しないソリューションが本当にない場合は、データベースベンダーごとに異なるソリューションを用意します。

• 他の外部ツールを使用してこれを行うことはできません。私は主にSQLベースのソリューションを探しています。

• データベース設計をこれ以上正規化できません。それはすでに3NFにあり、さらにその周りに多くのコードがすでに書かれています。

簡単な答え：

• データベースベンダーに依存しないソリューション=標準を使用する= COUNT(*)
• ありますおおよその SQL Serverソリューションはなく、スコープの外に= COUNT（*）を使用していません

ノート：

COUNT（1）= COUNT（*）= COUNT（主キー）念のため

編集：

SQL Serverの例（14億行、12列）

SELECT COUNT(*) FROM MyBigtable WITH (NOLOCK)
-- NOLOCK here is for me only to let me test for this answer: no more, no less

1回実行、5：46分、カウント= 1,401,659,700

--Note, sp_spaceused uses this DMV
SELECT
   Total_Rows= SUM(st.row_count)
FROM
   sys.dm_db_partition_stats st
WHERE
    object_name(object_id) = 'MyBigtable' AND (index_id < 2)

2回の実行、どちらも1秒未満、カウント= 1,401,659,670

2つ目は行数が少ない=間違っています。書き込みによって同じかそれ以上になります（削除はここでは時間外に行われます）

MySQLで断然最速の方法は次のとおりです。

SHOW TABLE STATUS;

行数（合計）を含むすべてのテーブルと、必要に応じて多くの追加情報をすぐに取得できます。

テーブルに多数の行と多数の列がある場合、SELECT COUNT（*）FROM TABLE_NAMEが遅くなるという記事を見つけました。

それはデータベースに依存します。たとえば、インデックスで行が有効か無効かを追跡し、インデックスのみのスキャンで行数を抽出できるようにすることで、カウントを高速化します。他のユーザーはそうせず、その結果、テーブル全体を訪問し、ライブ行を1つずつカウントする必要があります。巨大なテーブルではどちらも遅くなります。

一般に、クエリ最適化ツールやテーブル統計などを使用して適切な推定値を抽出できます。たとえば、PostgreSQLの場合、出力を解析してexplain count(*) from yourtable、行数のかなり適切な推定値を取得できます。それでは、2つ目の質問をさせていただきます。

数十億行にもなるテーブルがあります[約15列です]。テーブルの行数の正確な数を取得するより良い方法はありますか？

マジ？:-)あなたは本当に正確に意味します数十億行のテーブルから数をますか？本当によろしいですか？:-)

もし、あんたが 実際に実行するは、トリガーを使用して合計のトレースを保持できますが、実行する場合は並行性とデッドロックに注意してください。

テーブルの行数の正確な数を取得するより良い方法はありますか？

質問に簡単に答えるには、いいえ。

DBMSに依存しない方法が必要な場合は、 最速の方法は常に次のようになります。

SELECT COUNT(*) FROM TableName

一部のDBMSベンダーは、システムでのみ機能するより迅速な方法を備えている場合があります。これらのオプションのいくつかは、すでに他の回答に投稿されています。

COUNT(*) とにかく、DBMS（少なくともPRODに適したDB）によって最適化する必要があるため、最適化をバイパスしないでください。

サイドノートでは：
私はあなたの他のクエリの多くがためにも、あなたのテーブルサイズの終わりまでに長い時間がかかると確信しています。パフォーマンスの問題は、おそらくスキーマ設計について速度を考慮して考えることで対処する必要があります。変更するオプションではないとのことですが、10分以上のクエリもオプションではないことがわかるかもしれません。あなたはスピードを必要とするとき第三NFは、常に最善のアプローチではなく、レコードがない場合は、時々データが複数のテーブルに分割することができる持って一緒に格納されます。考えること...

このスクリプトは別のStackOverflowの質問/回答から入手しました。

SELECT SUM(p.rows) FROM sys.partitions AS p
  INNER JOIN sys.tables AS t
  ON p.[object_id] = t.[object_id]
  INNER JOIN sys.schemas AS s
  ON s.[schema_id] = t.[schema_id]
  WHERE t.name = N'YourTableNameHere'
  AND s.name = N'dbo'
  AND p.index_id IN (0,1);

私のテーブルには5億のレコードがあり、上記の結果は1ミリ秒未満で返されます。その間、

SELECT COUNT(id) FROM MyTable

39分52秒かかります！

それらは正確に同じ数の行を生成します（私の場合、正確に519326012）。

それが常に当てはまるかどうかはわかりません。

あなたはこのsp_spaceused（Transact-SQL）を試すことができます

現在のデータベースの行数、予約されているディスク領域、テーブル、インデックス付きビュー、またはService Brokerキューで使用されているディスク領域を表示するか、データベース全体で予約および使用されているディスク領域を表示します。

SQL Serverのエディションが2005/2008の場合、DMVを使用してテーブルの行数を計算できます。

-- Shows all user tables and row counts for the current database 
-- Remove is_ms_shipped = 0 check to include system objects 
-- i.index_id < 2 indicates clustered index (1) or hash table (0) 
SELECT o.name, 
 ddps.row_count 
FROM sys.indexes AS i 
 INNER JOIN sys.objects AS o ON i.OBJECT_ID = o.OBJECT_ID 
 INNER JOIN sys.dm_db_partition_stats AS ddps ON i.OBJECT_ID = ddps.OBJECT_ID 
 AND i.index_id = ddps.index_id 
WHERE i.index_id < 2 
 AND o.is_ms_shipped = 0 
ORDER BY o.NAME 

SQL Server 2000データベースエンジンの場合、sysindexesは機能しますが、近い将来に削除される可能性があるため、SQL Serverの将来のエディションでは使用しないことを強くお勧めします。

抜粋したサンプルコード：テーブルの行数をすばやく簡単に取得する方法

私が使う

select /*+ parallel(a) */  count(1) from table_name a;

私は回答した​​他の人ほどエキスパートではありませんが、テーブルからランダムな行を選択するために使用していた手順に問題がありましたが（あまり関連性がありません）、参照テーブルの行数を知る必要がありました。ランダムインデックスを計算します。従来のCount（*）またはCount（1）を使用しましたが、クエリが実行されるまで最大2秒かかる場合がありました。したがって、代わりに（ 'tbl_HighOrder'という名前のテーブルの場合）、次を使用しています：

Declare @max int

Select @max = Row_Count
From sys.dm_db_partition_stats
Where Object_Name(Object_Id) = 'tbl_HighOrder'

これはうまく機能し、Management Studioでのクエリ時間はゼロです。

ええと、5年遅れて、それが役立つかどうかわかりません：

私はノーを数えようとしていました。SQL Server Management Studioを使用したSQL Serverテーブルの行数数を増やし、オーバーフローエラーが発生した場合、以下を使用しました。

count_bigを選択（1）[DBNAME] FROM [DBO] [FactSampleValue]。

結果 ：

24296650578行

私はこの良い記事SQL Server–HOW-TOを見つけました：テーブルから正確な行数をすばやく取得しますmartijnh1、各シナリオのための良い要約を与えます。

特定の条件に基づいてカウントを提供する必要がある場合、これを拡張する必要があります。この部分がわかったら、この回答をさらに更新します。

それまでの間、記事の詳細は次のとおりです。

方法1：

クエリ：

SELECT COUNT(*) FROM Transactions 

コメント：

全表スキャンを実行します。大きなテーブルでは遅くなります。

方法2：

クエリ：

SELECT CONVERT(bigint, rows) 
FROM sysindexes 
WHERE id = OBJECT_ID('Transactions') 
AND indid < 2 

コメント：

行数を取得する高速な方法。統計に依存し、不正確です。

DBCC UPDATEUSAGE（データベース）WITH COUNT_ROWSを実行します。これは、大きなテーブルではかなりの時間がかかる可能性があります。

方法3：

クエリ：

SELECT CAST(p.rows AS float) 
FROM sys.tables AS tbl 
INNER JOIN sys.indexes AS idx ON idx.object_id = tbl.object_id and
idx.index_id < 2 
INNER JOIN sys.partitions AS p ON p.object_id=CAST(tbl.object_id AS int) 
AND p.index_id=idx.index_id 
WHERE ((tbl.name=N'Transactions' 
AND SCHEMA_NAME(tbl.schema_id)='dbo')) 

コメント：

SQL Management Studioが行をカウントする方法（テーブルプロパティ、ストレージ、行カウントを確認）。非常に高速ですが、それでもおおよその行数です。

方法4：

クエリ：

SELECT SUM (row_count) 
FROM sys.dm_db_partition_stats 
WHERE object_id=OBJECT_ID('Transactions')    
AND (index_id=0 or index_id=1); 

コメント：

迅速な（方法2ほど高速ではありませんが）操作であり、同様に重要で信頼性があります。

一般的に常に最速のソリューションがあるとは思いません。RDBMS/バージョンによっては、SELECT COUNT(*)より高速なオプションを使用するために特定の最適化を行っているものもあれば、単にテーブルスキャンを行うものもあります。2番目のセットのドキュメント/サポートサイトにアクセスする必要があります。おそらく、特定のクエリを作成する必要があります。通常は、何らかの方法でインデックスにヒットするクエリです。

編集：

スキーマとデータの分布に応じて機能する可能性のある考え方は次のとおりです。増加する値、増加する数値などのタイムスタンプや日付を参照するインデックス付きの列がありますか？次に、削除が発生しないと仮定して、最近の値（昨日の日付、最近のサンプルポイントでの最大ID値）までのカウントを保存し、それを超えてカウントを追加すると、インデックスで非常に迅速に解決できるはずです。 。もちろん、値とインデックスに非常に依存しますが、DBMSのほとんどすべてのバージョンに適用できます。

私はこの質問に遅れていますが、MySQLを使用して実行できることを以下に示します。私はここで私の観察を共有しています：

1) SELECT COUNT(*) AS TOTAL_ROWS FROM <TABLE_NAME>

結果の
行数：508534
コンソール出力：影響を受ける行：0見つかった行：1警告：0 1つのクエリの継続時間：0.125秒。
行数の多いテーブルではしばらく時間がかかりますが、行数は非常に正確です。

2) SHOW TABLE STATUS or SHOW TABLE STATUS WHERE NAME="<TABLE_NAME>"

結果
行数：511235
コンソール出力：影響を受けた行：0見つかった行：1警告：0 1クエリの継続時間：0.250秒概要：行数は正確ではありません。

3) SELECT * FROM information_schema.tables WHERE table_schema = DATABASE();

結果
行数：507806
コンソール出力：影響を受ける行：0見つかった行：48警告：0 1つのクエリの期間：1.701秒。
行数は正確ではありません。

私はMySQLやデータベースの専門家ではありませんが、非常に大きなテーブルの場合、オプション2または3を使用して、存在する行数の「公正なアイデア」を得ることができることを発見しました。

UIにいくつかの統計を表示するには、これらの行数を取得する必要がありました。上記のクエリで、合計行数が500,000を超えることがわかったので、正確な行数ではなく、「500,000行以上」のような統計情報を表示することにしました。

多分私は実際にはOPの質問に答えていませんが、そのような統計が必要な状況で私がしたことを共有しています。私の場合、おおよその行を表示することは許容できるので、上記はうまくいきました。

正確にはDBMSにとらわれないソリューションではありませんが、少なくともクライアントコードでは違いがわかりません...

1行と1つの整数フィールドN ¹だけを持つ別のテーブルTを作成し、実行するだけのINSERT TRIGGERを作成します。

UPDATE T SET N = N + 1

また、実行するDELETE TRIGGERを作成します。

UPDATE T SET N = N - 1

そのソルトに値するDBMSは、^2を超える操作のアトミック性を保証し、Nは常に正確な行数を含むため、次のように簡単に取得できます。

SELECT N FROM T

トリガーはDBMS固有ですが、Tから選択することはできません。サポートされているDBMSごとにクライアントコードを変更する必要はありません。

ただし、テーブルがINSERTまたはDELETEを集中的に使用する場合、特にINSERT / DELETEの直後にCOMMITを実行しない場合は、これによりスケーラビリティの問題が発生する可能性があります。

¹これらの名前は単なるプレースホルダーです-本番環境ではより意味のあるものを使用してください。

²つまり、読み取りと書き込みの両方が単一のSQLステートメントで行われている限り、Nへの読み取りと書き込みの同時トランザクションによってNを変更することはできません。

文字通り非常識な答えですが、なんらかのレプリケーションシステムがセットアップされている場合（10億行のシステムの場合はそうすることを望みます）、ラフな推定値（などMAX(pk)）を使用して、その値をスレーブの数で除算できます。複数のクエリを並行して実行します。

ほとんどの場合、次のような方法で、最良のキー（または私が推測する主キー）に基づいてスレーブ間でクエリを分割します（行/スレーブとして250000000を使用します）。

-- First slave
SELECT COUNT(pk) FROM t WHERE pk < 250000000
-- Ith slave where 2 <= I <= N - 1
SELECT COUNT(pk) FROM t WHERE pk >= I*250000000 and pk < (I+1)*250000000
-- Last slave
SELECT COUNT(pk) FROM t WHERE pk > (N-1)*250000000

しかし、必要なのはSQLだけです。なんとバスト。では、あなたがサドマゾだとしましょう。マスター（または最も近いスレーブ）では、おそらくこのためのテーブルを作成する必要があります。

CREATE TABLE counter_table (minpk integer, maxpk integer, cnt integer, slaveid integer)

したがって、スレーブでselectを実行するだけではなく、次のように挿入を行う必要があります。

INSERT INTO counter_table VALUES (I*25000000, (I+1)*250000000, (SELECT COUNT(pk) FROM ... ), @@SLAVE_ID)

スレーブがマスターのテーブルに書き込む際に問題が発生する可能性があります。あなたはもっともっと悲しいことをする必要があるかもしれません-つまり、創造的です：

-- A table per slave!
INSERT INTO counter_table_slave_I VALUES (...)

最後に、最初のスレーブに対して、レプリケーショングラフが通過するパスの最後に存在するスレーブが必要です。そのスレーブは、他のすべてのカウンター値を持ち、独自の値を持つはずです。しかし、完了するまでに行が追加されている可能性があるため、counter_tableに記録されている最大pkと現在の最大pkを補正する別の行を挿入する必要があります。

その時点で、総行数を把握するために集計関数を実行する必要がありますが、多くても「所有および変更しているスレーブの数」行で実行するため、簡単です。

スレーブに個別のテーブルがある状況では、次のことができます UNION必要なすべての行を取得ます。

SELECT SUM(cnt) FROM (
    SELECT * FROM counter_table_slave_1
      UNION
    SELECT * FROM counter_table_slave_2
      UNION
    ...
  )

または、少し気が狂って、データを分散処理システムに移行するか、データウェアハウジングソリューションを使用することもできます（これにより、将来、すばらしいデータ処理が可能になります）。

これは、レプリケーションが適切に設定されているかどうかに依存することに注意してください。プライマリボトルネックは永続的なストレージである可能性が最も高いため、不安定なストレージや、近隣のノイズが大きいデータストアの分離が不十分な場合、単一の待機よりも実行速度が遅くなる可能性があります。SELECT COUNT(*) ...

しかし、適切なレプリケーションがある場合、速度の向上は、スレーブの数または数に直接関係するはずです。実際、カウントクエリだけを実行するのに10分かかり、8つのスレーブがある場合、時間は数分未満に短縮されます。このソリューションの詳細を解決するのに1時間かかるかもしれません。

もちろん、この分散解法は行を削除して挿入できる少しの時間を導入するため、驚くほど正確な答えは得られませんが、同じインスタンスで行の分散ロックを取得して正確な数を取得することができますテーブル内の特定の瞬間の行の。

基本的にはSQLのみのソリューションで立ち往生しているため、実際にはこれは不可能に思われます。シャードされてロックされたクエリを複数のスレーブ間で即座に実行するメカニズムが提供されていないと思います。多分あなたがレプリケーションログファイルの制御を持っているなら...それは文字通りこの目的のためにスレーブをスピンアップすることを意味します、それはとにかく単一のマシンでカウントクエリを実行するよりも遅いでしょう。

2013年のペニーが2つあります。

場合挿入トリガーは、使用にあまりにも高価ですが、削除トリガーを与えることができ、自動インクリメントがありid、その後、一度テーブル全体をカウントし、カウント数などを記憶した後、last-countおよびlast-counted-id、

次に、毎日id > を数え、last-counted-idそれをlast-countに追加し、新しいを保存するだけlast-counted-idです。

削除されたレコードのID <=最終カウントIDの場合、削除トリガーは最終カウントをデクリメントします。

行が削除されない、自動インクリメントの主キー列を持つ典型的なテーブル構造がある場合、以下はレコード数を決定する最も速い方法であり、ほとんどのANSI準拠データベースにわたって同様に機能するはずです。

SELECT TOP(1) <primarykeyfield> FROM <table> ORDER BY <primarykeyfield> DESC;

私は、レコードカウントを含む、データの1秒未満の応答時間を必要とする数十億行を含むMS SQLテーブルを使用しています。同様のSELECT COUNT（*）を比較すると、処理に数分かかります。

SQLサーバーの場合、これを試してください

SELECT T.name, 
       I.rows AS [ROWCOUNT] 
FROM   sys.tables AS T 
       INNER JOIN sys.sysindexes AS I 
               ON T.object_id = I.id AND I.indid < 2 
WHERE T.name = 'Your_Table_Name'
ORDER  BY I.rows DESC 

id = Object_ID（ 'TableName'）およびindid <2であるsysindexesから行を選択します

いくつかの列にインデックスを付けます。これにより、オプティマイザはテーブルのフルスキャンではなく、インデックスブロックのフルスキャンを実行できるようになります。これにより、IOコストが大幅に削減されます。前後の実行計画を見てください。次に、壁時計の時間を双方向で測定します。

Oracleを使用している場合、これはどうですか（テーブルの統計が更新されていると想定）。

select <TABLE_NAME>, num_rows, last_analyzed from user_tables

last_analyzedは、統計が最後に収集された時刻を示します。

PostgreSQLの場合：

SELECT reltuples AS approximate_row_count FROM pg_class WHERE relname = 'table_name'

SQL Server 2016では、テーブルのプロパティを確認してから[ストレージ]タブを選択するだけで、行数、テーブルで使用されるディスク領域、使用されるインデックス領域などを取得できます。

多分少し遅れますが、これはMSSQLの他の人を助けるかもしれません

; WITH RecordCount AS（SELECT ROW_NUMBER（）OVER（ORDER BY COLUMN_NAME）AS [RowNumber] FROM TABLE_NAME）SELECT MAX（RowNumber）FROM RecordCount