TiDB Cloudで外部キー制約のチェックをGLOBALスコープでオフにしても、引き続きチェックが走る [TiDB Cloud Dedicated]
やりたかったこと「外部キー制約のチェックをオフにしたい」 TiDB Cloudでの性能試験時にインサートのクエリが遅くなっており、実行計画を見ると外部キー制約のチェックで4秒ほど時間を使っていることがわかりました。 TiDBにおいて外部キー制約によってインサートが遅くなる理由については以下の記事で紹
Category
performance
7 articles
外部キー制約によるインサートの性能劣化はNewSQLの意外な欠点
NewSQLの代表的な欠点「レイテンシー」 NewSQLの欠点としてよく上がるのが「レイテンシー」です。 これは分散DBである程度強いデータ整合性を達成しようと思うと、仕方ない話なのかなと思います。 構造的にも納得できます。 意外な欠点「外部キー制約で性能劣化する」「外部キー制約が使えない」 多少レ
7億行のテーブルにパーティション導入することでdelete文の速度が4.7倍高速化した
はじめに 今回は、7億行ものデータ行を持つテーブルの日付カラムにパーティションを導入することで、delete文が高速になるかどうかを検証しました。 また、検証対象テーブルのファイルグループを、デフォルトでデータが格納されるPRIMARY以外にすることで、さらに高速化の効果が得られるかについても調査し
テーブルパーティションの性能改善事例集
事例: 4億行のテーブルに対してselectクエリ実行した場合 4億行で比較したところ、7秒かかるクエリが1秒まで短縮された https://www.youtube.com/watch?v=fN4Qa8g 事例: 20億行のテーブルに対して、selectを実行した場合 20億行のテーブルに対して、s
JOOQのbulk update, batch update, for文でのupdateはどれくらいの速度差があるのか？
目次 1. はじめに 3. jOOQとは 5. 1万件のレコードをjOOQでアップデートする際の性能 7. おわりに 1. はじめに みなさんDBのデータ更新をする際になんとなくupdateしてませんか？ 実は数万件単位のupdateをする際に、愚直にupdateするのとbulk updateするの
正規表現のコンパイルをメモ化すると若干速くなるらしいのでローカル環境で検証してみた
はじめに 「Effective Java 第3版」の第2章の項目6に「不必要なオブジェクトの生成を避ける」という内容のものがあり、そこで正規表現のコンパイルはクラス変数にキャッシングした方がパフォーマンスを大幅に改善できるとのことが書いてあったので、実際に試して確認してみました。 検証環境 条件は以
[SQL Server] 行ロックを取りすぎるとテーブルロックに変わる
ロックエスカレーションとは SQL Serverには注意すべき挙動として、ロックエスカレーションというものがあります。 ロックエスカレーションとは、あるテーブルに対して行ロックを取得しすぎた場合に、代わりにテーブルロックを取得する挙動です。 ロックエスカレーションの発生条件 具体的には、以下のいずれ