ad3e04e50357a1e758fc#_reference-a1b4100c3771c36dfbe6

SELECT COUNT(*) INTO before_count FROM table1; ... INSERT INTO table1 ...; ... SELECT COUNT(*) - brefore_count INTO registered_count FROM table1; なにかTABLEへの追加処理をしてますが、意図通りにできたかどうか、前後で COUNT(*)をとって、その差分を報告させようとしています。 複数のプロジェクトの複数のオーナーのコードで見かけたので、こんな初級アンチパターンも共有しときます。 なにがまずいの? COUNTは、シーケンシャル・スキャンしないと出てこない値なのです。アンチパターンでは、テーブル全体が対象ですから、主キーインデクスを総なめです。小さいテーブルのうちはいいのですが、運用の1000万行を越えるような巨大テーブルだと、主キーインデック

[n314]

“主キーインデックスだけでもGB単位になります。” 今ためしに2^24 だけinsertしてみたら、372MBだった。count(*)は1.5秒で、16777216件あってもちょっと待てばいいぐらいの速度っていうのも逆に問題だね。

[mikage014]

“RDBMS にとって生きているTABLEの COUNT() は本質的に重いのです。巨大テーブルでは極力回避してください。 使うときは結果/中間結果を小さくしてから適用です。”

[tzkoba]

postgresの場合、インデックスオンリースキャンもVacuumされてることが前提で意図通りに動かないこともある。

[katsuren]

レコード存在チェックでcountしたりたまに見かけるのでほんとにこれは気をつけたほうが良いポスグレだけじゃなくてMySQLも同じ