varcharサイズが 2 の累乗のフィールドを使用するよりも、別の数値を使用する方が効率的ですか? SQL Server のデフォルトは 50 であるため、いいえと考えています。
ただし、フィールドのサイズを 2 の累乗にすると、偶数バイトに相当し、コンピューターはビットとバイトで処理されるため、フィールドのサイズを 2 の累乗にする方が効率的であると聞いたことがあります (ただし、確認したことはありません)。
では、フィールドは として宣言されていますvarchar(32)かvarchar(64)、それよりも実際にメリットがありvarchar(50)ますか?
いいえ。
他のいくつかの用途では、2 の累乗サイズの構造体を使用する利点がいくつかあります。これは主に、別の 2 の累乗サイズの構造体内に適切な (2 の累乗) 数のこれらを収めることができるためです。ただし、これは DB フィールドサイズには当てはまりません。
VARCHAR に関連する唯一の 2 のべき乗サイズは、varchar (または一部の SQL ダイアレクトでは TEXT/BLOB) の正確なタイプに関するものです。256 未満の場合は、1 バイトを使用して長さを示すことができます。65536 (64KB) 未満の場合、2 バイトで十分です。3 バイトで 16777216 (16MB) まで動作し、4 バイトで 4294967296 (4GB) まで動作します。
また、どちらも n+1 バイトのストレージを必要とするため、VARCHAR(50)は と同じくらい高価であると主張できます。VARCHAR(255)
もちろん、それは Unicode について考える前のことです...
私たちはオタクであり、それが私たちの仕事であるため、人々はvarcharフィールドに2の累乗を選択するといつも思っていました。少なくとも私はいつもそうしてきました。
一般的にSQLの場合は？いいえ。特定の実装については、おそらく。
何が効率的かは、仕様 (SQL は単なる仕様) によって決まるのではなく、特定の DBMS でどのように実装されるかによって決まります。
特定の最大長を使用することで得られる唯一の具体的な利点は、VARCHAR. 255 を超える最大長では、各行に値の長さを格納するために追加のバイトが必要になります (256^2 以上の長さの場合は追加の 2 バイトなど)。
特定のデータベースの実装に依存しますが、そうなるとは思いません。通常、文字数の計算は実行しないため、パフォーマンスには影響しません。スペースのみです。