MySQL：转换数据类型和排序规则对存储数据的影响

关于这一点，我有一个一般性的问题。当在之前插入大量数据时，我们多次希望更改字段或排序规则的数据类型。考虑这些情况：

将

varchar

排序规则从

utf8\u general\u ci

转换为

latin1\u swedish\u ci

：据我所知，第一个具有多字节字符，第二个具有单字节字符。此转换是否正确操作存储的记录？这种转换是否会减少现有数据量（可能是50%）

将

int（10）

转换为

smallint（5）

：数据量是否正确减少到50%

或者例如：

int（10）

to

unsigned int（10）

-

text

to

varchar（1000）

-

varchar（20）

to

char（10）

很明显，这些操作可以提高效率、减少数据量和

假设我有一个包含1000000条记录的表。我想知道这样做是否会对存储的数据产生不良影响，或者是否会使涉及此表的未来插入和选择的性能降低

更新：
当我谈到将utf8编码字符集更改为拉丁语时，我字段的值当然是英语（很明显，如果有日语，它们将丢失）。有了这个假设，我要问的是结果表的大小和性能

将

varchar

排序规则从

utf8\u general\u ci

转换为

latin1\u swedish\u ci

：据我所知，第一个具有多字节字符，第二个具有单字节字符。此转换是否正确操作存储的记录？这种转换是否会减少现有数据量（可能是50%）

排序规则仅仅是用于字符串比较的顺序，它（几乎）与用于数据存储的字符编码无关。我这样说几乎是因为排序规则只能用于某些字符集，所以更改排序规则可能会强制更改字符编码

如果修改了字符编码，MySQL将正确地将值重新编码到新字符集，无论是从单字节编码到多字节编码，还是从多字节编码到新字符集。请注意，对于该列来说过大的任何值都将被截断

如果新的字符类型是可变长度的，并且在新编码中使用的字节数比以前少，那么表的大小当然会减少

将

int（10）

转换为

smallint（5）

：数据量是否正确减少到50%

无论显示宽度如何，

INT

和

SMALLINT

分别占用4和2个字节：因此，表的大小将相应减小

或者例如：

int（10）

to

unsigned int（10）

-

text

to

varchar（1000）

-

varchar（20）

to

char（10）

• INT

  占用4个字节，与是否签名无关，因此不会有任何更改

• TEXT

  和

  VARCHAR（1000）

  都占用L+2字节（其中L是值的长度，以字节为单位），因此不会有任何更改

• VARCHAR（20）

  占用L+1字节（其中L是值的字节长度），而

  CHAR（10）

  占用10×w字节（其中w是字符集中最大长度字符所需的字节数），因此可能会有变化，但这取决于存储的实际值和使用的字符编码

注意，根据存储引擎的不同，表大小的减少可能不会立即发布到文件系统

将

varchar

排序规则从

utf8\u general\u ci

转换为

latin1\u swedish\u ci

：据我所知，第一个具有多字节字符，第二个具有单字节字符。此转换是否正确操作存储的记录？这种转换是否会减少现有数据量（可能是50%）

排序规则仅仅是用于字符串比较的顺序，它（几乎）与用于数据存储的字符编码无关。我这样说几乎是因为排序规则只能用于某些字符集，所以更改排序规则可能会强制更改字符编码

如果修改了字符编码，MySQL将正确地将值重新编码到新字符集，无论是从单字节编码到多字节编码，还是从多字节编码到新字符集。请注意，对于该列来说过大的任何值都将被截断

如果新的字符类型是可变长度的，并且在新编码中使用的字节数比以前少，那么表的大小当然会减少

将

int（10）

转换为

smallint（5）

：数据量是否正确减少到50%

无论显示宽度如何，

INT

和

SMALLINT

分别占用4和2个字节：因此，表的大小将相应减小

或者例如：

int（10）

to

unsigned int（10）

-

text

to

varchar（1000）

-

varchar（20）

to

char（10）

• INT

  占用4个字节，与是否签名无关，因此不会有任何更改

• TEXT

  和

  VARCHAR（1000）

  都占用L+2字节（其中L是值的长度，以字节为单位），因此不会有任何更改

• VARCHAR（20）

  占用L+1字节（其中L是值的长度，单位为