指定し、ハッシュインデックスはこのバケットの中に格納されていくことになります。このバケットカウントと性能への影響について少しまとめてみたいと思います。必要となり、バケットカウントに指定した分のメモリは格納しているデータの件数にかかわらず確保されることになります。累乗のサイズで取得されるため、適当な数値を入れても近い累乗値に丸められます。テーブル作成後にインデックス定義を含めたテーブル定義を変更することができませんので、サイズを変えたい場合にはテーブルを再作成する必要があるため、設計時のどれくらいのデータを格納するかを考慮したうえで設定をする必要があります。メモリの制限となるようですので設計ではこれを上限として考える必要もありますが。2014単一のテーブルに対してデータを挿入する場合などは、バケットのサイズが性能に大きく影響してくるようです。以下のようなテーブルとストアドプロシージャを作成してみます。これによりディスク書き込みが抑制されますのでデータ作成を高速に行えます。処理時間を計測してみたいと思います。以下のバケットカウントは実運用では設定しないと思われる小さい値を設定しています。1バケット8バイトですので、実際の運用では大きめなバケットサイズを設定しても消費メモリはそれほど多くありませんので、実際に使用される際にはかなり大き目なサイズを設定してもメモリ消費の影響は少ないと思います。バケットカウントバケットの利用メモリ処理時間1,0248KB5:344,09632KB0:328,19264KB0:1516,384128KB0:081,048,5768MB0:01同一のクエリを使用してデータを挿入していますが、バケットカウントによって処理時間に大きく差が出てきていますね。細かな挙動までは確認ができていないのですが、ハッシュインデックスのバケットのサイズが不足し、バケット内のメンテナンスが必要となった分のオーバーヘッドでしょうか。時の性能には影響するのではと思っています。チューニングの考慮点となりそうですね。チューニング等をメインにしていますが、本ブログで情報発信している内容に関することでしたら対応できます。お仕事のご相談がありましたらTwitterfacebookやブログのコメントでご連絡いただけると幸いです。ブログにコメント頂いた内容は私が承認しない限り表示されません。本ブログでは自宅の検証環境を使って勉強したことを投稿しています。製品を使用した検証となっています。受賞させていただきました。本ブログの内容は個人的に検証したものとなり、検証結果を含め記載している内容を保証するものではありません。(2015/3/21~)最後まで飲み切れず...。体験記の連載をさせていただきました。