目录
1、优化数据大小
设计我们的表以最小化它们在磁盘上的空间。 这可以通过减少写入磁盘和从磁盘读取的数据量来带来巨大的改进。 较小的表通常需要较少的主内存,而它们的内容在查询执行期间被主动处理。 表数据的任何空间减少也会导致可以更快处理的更小的索引。
MySQL 支持许多不同的存储引擎(表类型)和行格式。 对于每个表,我们可以决定使用哪种存储和索引方法。 为我们的应用程序选择合适的表格格式可以大大提高性能。
Table Columns
- 尽可能使用最有效(最小)的数据类型。 MySQL 有许多专门的类型可以节省磁盘空间和内存。 例如,尽可能使用较小的整数类型来获得较小的表。 MEDIUMINT 通常是比 INT 更好的选择,因为 MEDIUMINT 列使用的空间减少了 25%。
- 如果可能,将列声明为 NOT NULL。 通过更好地使用索引并消除test表每个值是否为 NULL 的开销,它使 SQL 操作更快。 我们还可以节省一些存储空间,每列一位。 如果我们的表中确实需要 NULL 值,请使用它们。 只需避免在每列中允许 NULL 值的默认设置。
Row Format
-
默认情况下,使用 DYNAMIC 行格式创建 InnoDB 表。要使用 DYNAMIC 以外的行格式,请配置 innodb_default_row_format,或在 CREATE TABLE 或 ALTER TABLE 语句中显式指定 ROW_FORMAT 选项。
紧凑的行格式系列(包括 COMPACT、DYNAMIC 和 COMPRESSED)减少了行存储空间,但代价是增加了某些操作的 CPU 使用率。如果我们的工作负载是典型的受缓存命中率和磁盘速度限制的工作负载,它可能会更快。如果是受 CPU 速度限制的罕见情况,它可能会更慢。
当使用可变长度字符集(例如 utf8mb3 或 utf8mb4)时,紧凑的行格式系列还优化了 CHAR 列存储。当 ROW_FORMAT=REDUNDANT 时,CHAR(N) 占用 N × 字符集的最大字节长度。许多语言可以主要使用单字节 utf8 字符编写,因此固定的存储长度通常会浪费空间。使用紧凑的行格式系列,InnoDB 通过去除尾随空格为这些列分配 N 到 N × 字符集的最大字节长度范围内的可变存储量。最小存储长度为 N 字节,以便在典型情况下进行就地更新。
-
要通过以压缩形式存储表数据来进一步最小化空间,请在创建 InnoDB 表时指定 ROW_FORMAT=COMPRESSED,或在现有 MyISAM 表上运行 myisampack 命令。 (InnoDB 压缩表是可读可写的,而 MyISAM 压缩表是只读的。)
-
对于 MyISAM 表,如果我们没有任何可变长度列(VARCHAR、TEXT 或 BLOB 列),则使用固定大小的行格式。 这更快,但可能会浪费一些空间。
Indexes
- 表的主索引应尽可能短。 这使得每一行的识别变得容易和高效。 对于 InnoDB 表,主键列在每个二级索引条目中都是重复的,因此如果我们有许多二级索引,短主键可以节省大量空间。
- 仅创建提高查询性能所需的索引。 索引有利于检索,但会减慢插入和更新操作。 如果我们主要通过搜索列组合来访问表,请在它们上创建单个复合索引,而不是为每列创建单独的索引。 索引的第一部分应该是最常用的列。 如果从表中选择时总是使用很多列,则索引中的第一列应该是重复次数最多的列,以获得更好的索引压缩。
- 如果很可能一个长字符串列在第一个字符上具有唯一前缀,最好只索引这个前缀,使用 MySQL 支持在列的最左侧创建索引。 更短的索引更快,不仅因为它们需要更少的磁盘空间,还因为它们还可以在索引缓存中提供更多的命中,从而减少磁盘查找。
Joins
- 在某些情况下,将经常扫描的表拆分为两个可能是有益的。 如果它是动态格式的表,则尤其如此,并且可以使用较小的静态格式表,以便在扫描表时找到相关行。
- 在具有相同数据类型的不同表中声明具有相同信息的列,以加快基于相应列的连接。
- 保持列名简单,以便我们可以在不同的表中使用相同的名称并简化连接查询。 例如,在名为 customer 的表中,使用 name 列名而不是 customer_name。 要使我们的名称可移植到其他 SQL 服务器,请